On 11/14/2012 09:18 PM, Derek Belcher wrote:
Rich, thank you so much for your help, where do I send the beer?
So here are the new steps that I am testing out and seem to work in my
test environment:
cd /usr/lib64/dirsrv/slapd-my-ldap/
./db2ldif -n userRoot -a /var/tmp/mydb.ldif
chmod 755 /var/tmp/mydb.ldif
This shouldn't be necessary as long as the file is owned by the server user.
./ldif2db.pl <http://ldif2db.pl> -v -D "cn=directory manager" -w
****** -i /var/tmp/mydb.ldif -s dc=company,dc=net
reinitialize consumers
reinitialize winsync
Does this look right? Better to be paranoid then to do something crazy
in production.
Yes
On Wed, Nov 14, 2012 at 9:15 PM, Rich Megginson <[email protected]
<mailto:[email protected]>> wrote:
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 <http://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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
