On 08/19/2014 03:05 PM, Shilen Patel wrote: > Hi Mark, > > So with this issue, I'm not adding a password at all to the entry. > See the LDIF in (2) below. No, I was referring to your first email, not this issue. Sorry I should of responded separately. > I'll open a ticket. For what issue? For the initialization issue I want you to grab the logging first. For the first issue(userpassword not being replicated), if you can reproduce it when only adding already hashed passwords, then please file a ticket with a reproducible testcase.
I hope that clears things up. Regards, Mark > > Thanks! > > -- Shilen > > From: Mark Reynolds <[email protected] <mailto:[email protected]>> > Reply-To: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Date: Tuesday, August 19, 2014 2:58 PM > To: "General discussion list for the 389 Directory server project." > <[email protected] > <mailto:[email protected]>>, Shilen Patel > <[email protected] <mailto:[email protected]>> > Subject: Re: [389-users] Replication error after initializing consumer > > Shilen, > > A few things, you should not be adding a prehashed password (e.g. > {SSHA}DMK4S6PK6+rKSLNOL1Hl01mVJmgGi5jH) - but that should not > break replication. Can you confirm that only prehashed passwords > are causing the issue? If so, please files a ticket with a > reproducible testcase: https://fedorahosted.org/389/newticket > > As for this replication issue, enabling replication logging might > provide more information: > > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/error-logs.html#error-logs-levels > > Then post the logging output back on this list. You should also > undo this logging level once you're done - as this logging level > can impact performance. > > Thanks, > Mark > > > On 08/19/2014 01:08 PM, Shilen Patel wrote: >> Hi, >> >> I'm not sure if this is related to my previous email, but I'm >> also seeing issues when adding an entry while a suffix on a >> consumer is being initialized. Again, I'm running 1.2.11.30. >> Here are the details: >> >> 1. Using the console, I started to initialize a suffix. >> >> [19/Aug/2014:17:46:35 +0100] NSMMReplicationPlugin - Beginning >> total update of replica "agmt="cn=test5toSing1" (consumerhost:636)". >> >> 2. While that was happening, I added an entry to the suffix on >> the master. >> >> dn: uid=shilen3,ou=people,ou=test,dc=duke,dc=edu >> changetype: add >> objectclass: top >> objectclass: person >> objectclass: inetorgperson >> objectclass: organizationalperson >> cn: test >> sn: test >> uid: shilen3 >> >> >> [19/Aug/2014:17:47:04 +0100] conn=155 op=1 ADD >> dn="uid=shilen3,ou=people,ou=test,dc=duke,dc=edu" >> [19/Aug/2014:17:47:04 +0100] conn=155 op=1 RESULT err=0 tag=105 >> nentries=0 etime=0 csn=53f37f89000000050000 >> >> 3. The init later finished. >> >> [19/Aug/2014:17:48:55 +0100] NSMMReplicationPlugin - Finished >> total update of replica "agmt="cn=test5toSing1" >> (consumerhost:636)". Sent 270 entries. >> >> At this point, the entry does exist on the consumer. Presumably >> it was added as part of the init. >> >> >> 4. However, the master still wants to send the ADD to the >> consumer. On the consumer, I have the following repeated every >> few seconds: >> >> [19/Aug/2014:17:48:54 +0100] conn=2002 op=56 ADD >> dn="uid=shilen3,ou=people,ou=test,dc=duke,dc=edu" >> [19/Aug/2014:17:48:54 +0100] conn=2002 op=56 RESULT err=53 >> tag=105 nentries=0 etime=0 csn=53f37f89000000050000 >> >> And on the master, I have this: >> >> [19/Aug/2014:17:48:58 +0100] NSMMReplicationPlugin - >> agmt="cn=test5toSing1" (consumerhost:636): Consumer failed to >> replay change (uniqueid 5d458a02-27c011e4-a066d327-58be45f0, CSN >> 53f37f89000000050000): Server is unwilling to perform (53). Will >> retry later. >> >> A cl-dump shows the following: >> >> changetype: add >> replgen: 53e0f14e000000050000 >> csn: 53f37f89000000050000 >> nsuniqueid: 5d458a02-27c011e4-a066d327-58be45f0 >> parentuniqueid: bcd34401-21ba11df-80799838-3cd697e9 >> dn: uid=shilen3,ou=people,ou=test,dc=duke,dc=edu >> change:: >> add: objectClass >> objectClass: top >> objectClass: person >> objectClass: inetorgperson >> objectClass: organizationalperson >> - >> add: cn >> cn: test >> - >> add: sn >> sn: test >> - >> add: uid >> uid: shilen3 >> - >> add: creatorsName >> creatorsName: cn=directory manager >> - >> add: modifiersName >> modifiersName: cn=directory manager >> - >> add: createTimestamp >> createTimestamp: 20140819164704Z >> - >> add: modifyTimestamp >> modifyTimestamp: 20140819164704Z >> - >> add: nsUniqueId >> nsUniqueId: 5d458a02-27c011e4-a066d327-58be45f0 >> - >> add: parentid >> parentid: 2 >> - >> add: entryid >> entryid: 277 >> - >> add: entrydn >> entrydn: uid=shilen3,ou=people,ou=test,dc=duke,dc=edu >> - >> >> >> If anyone has any thoughts on this one, that would be appreciated. >> >> Thanks! >> >> -- Shilen >> >> >> -- >> 389 users mailing list >> >> [email protected]https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
