We have experienced the same thing. Sort of. On RHEL 5 the name with a space in the DN is permitted and is treated as a separate entry. In CentOS 7 it barfs and rejects the entry as a duplicate entry. We are figuring out how to cope with it during our transition to all CentOS 7 .
My guess is once we migrate completely off the legacy, we will be fine. Paul M. Whitney paul.whit...@mac.com Sent from my Mac Book Pro > On May 2, 2017, at 9:01 AM, its-not...@alfresco.com wrote: > > Hi, > > We have an old version of CentOS Directory Server running on RHEL5 hosts. > > This has been successfully replicating our LDAP directory to CentOS 6 hosts > running a version of 389: > > 389-ds-base-1.2.11.25-1.el6.x86_64 > 389-ds-1.2.2-1.el6.noarch > > We've recently wanted to replicate to a pair of CentOS 7 servers running: > > 389-ds-1.2.2-6.el7.noarch > 389-ds-base-1.3.5.10-18.el7_3.x86_64 > > Whilst we've had no problems with initialising the consumers, we're having > major problems with rename and delete actions for specific entries... > > I've identified the problem as a rogue space after a comma in many objects > DN's. Strangely, not all objects have this extra space! About 70% do and it's > enough to cause a major problem. > > An example would be: > uid=fblogs,cn=company,ou=People,dc=company, dc=com > with the space after dc=company, > rather than: > uid=fblogs,cn=company,ou=People,dc=company,dc=com > > My understanding is that LDAP should cope with either format. Unfortunately, > we're finding replication to our CentOS7 hosts doesn't cope with the > additional space. > > So, if we rename or remove an object from a group it's not updated correctly > on the CentOS 7 389 Slaves. > > i.e. > uid=fblogs,cn=company,ou=People,dc=company, dc=com leaves the company. We > remove him from all his groups and disable his account. This successfully > replicates to all Centos DS and RHEL6 389 instances. The change fails on the > CentOS 7 389. > > If we rename an entry to remove the space after the comma then we end up with > two entries on the CentOS 7 389 :( One with the space and one without. > Subsequent changes will correctly update the space free entry. > > The only way to re-align the directories (and remove changed / stale comma > space entries) is to re-initialise the CentOS 7 consumers :( > > I could REALLY use some help to get to the bottom of this issue. I know we're > trying to replicate to a new version of 389 but my feelings are that it > should be handling the comma space issue as it has in previous versions. If > this is a bug we'd be happy to help with getting it fixed ASAP. > > Thanks, > > Philip > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
