On 08/28/2012 12:50 PM, Rich Megginson wrote: > On 08/28/2012 11:31 AM, Wes Hardin wrote: >> When initializing a consumer, I get many messages similar to this: >> >> import userRoot: WARNING: Skipping entry >> "uid=davsmith,ou=win,ou=People,dc=maxim-ic,dc=com" which has no parent, >> ending at line 0 of file "(bulk import)" >> >> It is believed that all affected entries had been moved within the directory >> using a moddn change in the past few months (using Apache Directory Studio). >> I was just able to "break" another account by doing this same action and >> reinitializing my consumer. >> >> Move entry: >> #!RESULT OK >> #!CONNECTION ldap://dalldap001.maxim-ic.com:389 >> #!DATE 2012-08-28T12:01:56.870 >> dn: uid=test4phy,ou=People,dc=maxim-ic,dc=com >> changetype: moddn >> newrdn: uid=test4phy >> deleteoldrdn: 1 >> newsuperior: ou=bri,ou=People,dc=maxim-ic,dc=com >> >> Re-init: >> [28/Aug/2012:18:05:36 +0100] - import userRoot: WARNING: Skipping entry >> "uid=test4phy,ou=bri,ou=People,dc=maxim-ic,dc=com" which has no parent, >> ending at line 0 of file "(bulk import)" >> >> Moving the account back to it's original location and reinitializing the >> consumer again "fixes" it. The entry does not appear on the consumer until >> I reinitialize. >> >> If I remember correctly, in the past, I was not able to do a moddn (A few >> months back I moved from 1.2.5 to 1.2.10). Is moddn considered safe? > Yes. >> If I copy and paste the entry to the new location and delete the old entry >> manually, this works just fine. >> >> I also get one instance of this message on each initialize: >> >> import userRoot: WARNING: Skipping entry >> "nsuniqueid=2dca7101-594d11df-8622cf4b-918cdd63,uid=fxdtest,ou=chm,ou=People,dc=maxim-ic,dc=com" >> which has no parent, ending at line 0 of file "(bulk import)" >> >> This one really confuses me since nsuniqueid isn't an entry, it's an >> attribute. Even stranger is that the value of nsuniqueid in the error >> message does not match the current value: >> >> dn: uid=fxdtest,ou=chm,ou=People,dc=maxim-ic,dc=com >> createTimestamp: 20120827200045Z >> creatorsName: uid=whardin,ou=dal,ou=people,dc=maxim-ic,dc=com >> entrydn: uid=fxdtest,ou=chm,ou=people,dc=maxim-ic,dc=com >> entryid: 13315 >> hasSubordinates: FALSE >> modifiersName: uid=whardin,ou=dal,ou=people,dc=maxim-ic,dc=com >> modifyTimestamp: 20120827200214Z >> nsUniqueId: d2729e81-f08111e1-8cbef100-4e39c57a >> numSubordinates: 0 >> parentid: 5877 >> passwordGraceUserTime: 0 >> subschemaSubentry: cn=schema >> >> I have deleted and recreated this account in the past few days.The value of >> nsuniqueid in the error message appears to be the value of the now deleted >> entry. > > Right. It is a tombstone entry. We did have some problems early on in > 1.2.10 with replication and tombstone entries, but those should have > been fixed by 1.2.10.4. Was this 1.2.10.4 an upgrade from an earlier > version of 1.2.10? > >> >> These are the packages on the server, which is CentOS 5.7: >> 389-admin-1.1.29-1.el5.x86_64 >> 389-admin-console-1.1.8-1.el5.noarch >> 389-adminutil-1.1.15-1.el5.x86_64 >> 389-console-1.1.7-3.el5.noarch >> 389-ds-base-1.2.10.4-5.el5.x86_64 >> 389-ds-base-libs-1.2.10.4-5.el5.x86_64 >> 389-ds-console-1.2.6-1.el5.noarch >> >> The consumer is also CentOS 5.7, but slightly newer 389-ds: >> 389-admin-1.1.29-1.el5.x86_64 >> 389-admin-console-1.1.8-1.el5.noarch >> 389-adminutil-1.1.15-1.el5.x86_64 >> 389-console-1.1.7-3.el5.noarch >> 389-ds-base-1.2.10.13-1.el5.x86_64 >> 389-ds-base-libs-1.2.10.13-1.el5.x86_64 >> 389-ds-console-1.2.6-1.el5.noarch > Try this on your 1.2.10.4-5 system: > 1) stop dirsrv > 2) export your database to LDIF using db2ldif > 3) upgrade to the latest 1.2.10.14-1.el5 from epel-testing (yum update > --enablerepo=epel-testing 389-ds-base) on your system that is currently > using 1.2.10.4-5 > NOTE: I've pushed this package to Stable but it won't show up in the > mirrors for a couple of days > 4) import the database from your saved LDIF using ldif2db > 5) start dirsrv > 6) reinitialize the consumer
I found the latest packages in Koji and followed your instructions. This appears to have fixed my replication issues. I plan to force all my consumers to reinitialize today and will definitely report back if I find any further errors. Thanks for your help, Rich. -- /* Wes Hardin */ UNIX/Linux Systems Administrator, IT Engineering Support Office: +1 (972) 371-6909 | Mobile: +1 (972) 342-5679 Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com -- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
