On 11/14/2012 05:04 PM, Derek Belcher wrote:
Rich,
"Not that I know of. What you will have to do is dump your database
to ldif and reload it, then reinitialize all of your replicas and
winsync agreements."
Does this mean that I do not have to stop replication?
So basically I would follow the following steps:
cd /usr/lib64/dirsrv/slapd-my-ldap/
./db2ldif -n userRoot -a /var/tmp/mydb.ldif
Yes
service dirsrv stop
Not required
Delete the database out of the GUI in the Configuration / data /
dc=company,dc=net
re-create the database dc=company,dc=net (userRoot)
No
./ldif2db -n userRoot -i /var/tmp/mydb.ldif
You can use ldif2db.pl while the server is running
service dirsrv start
See above
Then right click and reinitialize each sync agreement for the
multimasters and consumers
Yes
Also reinitialize the winsync agreement
Yes
Does this sound right? Not sure if I need to delete the database or
not, from what i am reading it looks like ldif2db will clobber the
existing entries in the database. Is this correct?
Yes.
Thanks -Derek
On Wed, Nov 14, 2012 at 1:59 PM, Derek Belcher
<jderekbelc...@gmail.com <mailto:jderekbelc...@gmail.com>> wrote:
Thank you for all of your help Rich. I have opened a ticket with
fedorahosted.org/389 <http://fedorahosted.org/389>
Ticket # 521
--Derek
On Wed, Nov 14, 2012 at 10:16 AM, Rich Megginson
<rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:
On 11/14/2012 08:56 AM, Derek Belcher wrote:
This master is bi-directionally syncing with my Active
Directory server. On the AD server, I have created a customer
filtered view for the time this started, 11/12/2014 between
1pm and 2pm, included all possible windows log sources and I
am not seeing any errors. I believe this is due to 389ds,
pulls and pushes updates, and AD is not really aware of 389ds.
Correct.
So I am thinking that the modrdn command is not able to make
the changes on the AD side? But if 389ds is pushing changes...
It should be, but AD is more restrictive of the types of
modrdn and entry move operations it will allow.
What is also interesting is that you can in AD "move" a users
to a different DN and 389ds will replicate that change to all
of its multi-masters and consumers. Just does not seem to
work when you do DN changes on the 389ds side and it pushes
to AD.
It should work - does this happen with any modrdn entry move
operation?
Is there a way to remove this offending entry in the change log?
Not that I know of. What you will have to do is dump your
database to ldif and reload it, then reinitialize all of your
replicas and winsync agreements.
Please file a ticket at https://fedorahosted.org/389 - this is
definitely a bug.
On Wed, Nov 14, 2012 at 9:22 AM, Rich Megginson
<rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:
On 11/14/2012 08:18 AM, Derek Belcher wrote:
Good morning Rich,
# rpm -q 389-ds-base
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
What does it say in the consumer access and errors log
for this change replay attempt?
Look in the consumer access log for 50a150a4000000020000,
see what the timestamp is, then look in the errors log at
around that timestamp.
Thank you
On Wed, Nov 14, 2012 at 8:58 AM, Rich Megginson
<rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:
On 11/13/2012 07:21 PM, Derek Belcher wrote:
Here is the error message that I am receiving in
/var/log/dirsrv/slap-xxxx/errors :
[13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin
- agmt="cn=sync001" (AD1.company.net:636
<http://AD1.company.net:636>): Consumer failed to
replay change (uniqueid
754ce981-e4d411e1-b828c127-7d7e145e, CSN
50a150a4000000020000): Server is unwilling to
perform. Will retry later.
Thanks again for your time.
rpm -q 389-ds-base
On Tue, Nov 13, 2012 at 5:38 PM, Derek Belcher
<jderekbelc...@gmail.com
<mailto:jderekbelc...@gmail.com>> wrote:
Good evening,
I am requesting some help from the community, I
have an issue that I can not seem to resolve.
Yesterday I committed a change on a users DN
and today I noticed replication issues in my
logs. The logs told me the uniqueid # and CSN #
So I used cl-dump to dump the changelog into a
file. Here are the results of what I grep'ed out:
[root@ds]# grep "50a150a4000000020000" -B2 -A13
/var/tmp/change.dump
changetype: modrdn
replgen: 4ff8a4c0000000010000
csn: 50a150a4000000020000
nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e
dn:
uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net
newrdn: uid=auser
deleteoldrdn: false
newsuperiordn:
ou=threatbb,ou=ops,ou=groups,dc=company,dc=net
change::
replace: modifiersname
modifiersname: cn=directory manager
-
replace: modifytimestamp
modifytimestamp: 20121112194019Z
-
So now that I know what entry
NSMReplicationPlugin is complaining about, I
don't know what to do in order to fix it and
get replication back on track.
I really appreciate any help on this matter,
Thank you
--
389 users mailing list
389-users@lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
