On 06/28/2012 02:41 PM, Rich Megginson wrote: > On 06/28/2012 01:15 PM, Wes Hardin wrote: >> To preface this, my issue began after upgrading from 1.2.5.x to 1.2.10.4 about a >> month ago, but I did not immediate recognize the severity at that time. >> >> Upon upgrading, it was discovered that replication had ceased to replicate. I >> got a message saying the "suffix was not enabled". I assume(d) this meant >> replication was not enabled for the suffix and that I needed to enable it. From >> the 389-console, the "Enable Replica" box was checked and the Replica Role was >> "Single Master." I couldn't see any reason for the sudden failure and the >> continued resistance against my attempts to synchronize my consumers. >> Eventually, I unchecked "Enable Replica" and (automatically) deleted all my >> replication agreements. I re-enabled the replica and began recreating all my >> agreements. Replication resumed normal operation. >> >> It wasn't until today that I realized the problem still exists. I rebooted my >> single master yesterday and today found that replication had stopped again. I >> exported all my agreements to an LDIF then nuked and rebuilt all my replication >> settings as I'd done after the upgrade. Replication resumed. Just to test my >> theory, I then restarted the server again and once again broke replication. >> Luckily I was prepared this time and was quickly able to recover. >> >> Here are some messages showing the rejected attempt to replicate. The first is >> an update, the second is an initialize. Both seem to indicate replication is >> not enabled despite evidence to the contrary. >> >> [28/Jun/2012:08:35:37 -0500] NSMMReplicationPlugin - Replication agreement for >> agmt="cn=ausldap001" (ausldap001:389) could not be updated. For replication to >> take place, please enable the suffix and restart the server >> >> [28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - Total update aborted: >> Replication agreement for "agmt="cn=mfnldap002" (mfnldap002:389)" can not be >> updated while the replica is disabled >> [28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - (If the suffix is disabled >> you must enable it then restart the server for replication to take place). >> >> I have noticed that I have a lot of entries whose DNs include escaped >> characters, which I don't remember seeing before. That is, \3D instead of '=' >> or \2C instead of ','. For example: >> >> dn: cn=replica,cn=dc\3Dmaxim-ic\2C dc\3Dcom,cn=mapping tree,cn=config >> objectClass: nsDS5Replica >> objectClass: top >> nsDS5ReplicaRoot: dc=maxim-ic,dc=com >> nsDS5ReplicaType: 3 >> nsDS5Flags: 1 >> nsDS5ReplicaId: 7777 >> nsds5ReplicaPurgeDelay: 604800 >> cn: replica >> nsState:: YR4AAAAAAADogOxPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== >> nsDS5ReplicaName: 240eb382-c13b11e1-bf5ef100-4e39c57a >> nsds5ReplicaChangeCount: 0 >> nsds5replicareapactive: 0 >> >> But based on the following link, I guess that's to be expected. >> >> http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format >> >> There also seems to be some inconsistency in how my root is referenced. >> Sometimes it has a space between the two domain components, sometimes it does >> not. You can actually see that in the example above. The DN value has a space, >> the nsDS5ReplicaRoot value has no space. >> >> I'm rather inexperienced in the management of LDAP. My upgrade from 1.2.5 to >> 1.2.10 was just a simple "yum upgrade". I hadn't seen the link about about the >> DN format or any other upgrade guide. I'm fully willing to allow that I failed >> to take some required step at the time of the upgrade. >> >> Many thanks in advance for any help you can provide. > Sorry about that. Yes, the problem is the spaces in the DNs. For > example, you should have > > dn: cn=replica,cn=dc\3Dmaxim-ic\2Cdc\3Dcom,cn=mapping tree,cn=config > > instead of > > dn: cn=replica,cn=dc\3Dmaxim-ic\2C dc\3Dcom,cn=mapping tree,cn=config > > Yes, it looks like the upgrade did not fix the DNs. Thanks Rich, that did it. It was a little easier said then done though. Attempts to rename didn't work, so I ended up deleting cn=dc\3Dmaxim-ic\2C dc\3Dcom,cn=mapping tree,cn=config (and its child) and then realized I didn't know how to recreate it. That was a little exciting. But I tested restarting the service and it looks happy. Thanks again! /* Wes Hardin */ UNIX/Linux Systems Administrator, IT Engineering Support Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
