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.whitney@xxxxxxx Sent from my Mac Book Pro > On May 2, 2017, at 9:01 AM, its-notify@xxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
