On 05/02/2017 09: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... Can you be more specific? Errors? Logging? Steps to reproduce? > > 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. What is happening exactly? What is in the access and errors logs? > > 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. How exactly are you renaming the entry? > > The only way to re-align the directories (and remove changed / stale comma space entries) is to re-initialise the CentOS 7 consumers :( Are you saying that the same entry on the master is different on the consumer? The consumer has a space in the dn while the master does not? Please clarify. Thanks, Mark > > 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
