#50665 Upgrade of 389-ds-base can still remove replication agreements
Opened 4 months ago by omljud. Modified 16 days ago

The problem of replication agreement removal reported and fixed in #49946 isn't fully solved.

If more than one replication agreement has '>' (or '<', perhaps other characters) in the name, only the last one processed will remain after upgrading.
E.g. If there are agreements named like this:
"cn=host1 -> host2,cn=replica,cn=[some base],cn=mapping tree,cn=config"
"cn=host1 -> host2,cn=replica,cn=[some other base]..."
"cn=host1 -> host3,cn=replica,cn=[some base]..."
only "cn=host1 -> host3,cn=replica,cn=[some base]..." will survive an upgrade.

When reading dse.ldif, FileConn.pm uses Mozilla::LDAP::Utils::normalizeDN, which is implemented with Mozilla::LDAP::API::ldap_explode_dn.
ldap_explode_dn in OpenLDAP's libldap apparently returns NULL if fed with a dn containing (an unescaped) '>' or '<'.
The result from normalizeDN is used as a hash key when storing the entry. That means every replication agreement containing a troublesome character is getting the same key(the empty string) and they are overwriting one another. Only the last one processed remains.
Before the fix in #49946, the hash key problem led to an LDAP_ALREADY_EXISTS error for agreements following the first agreement and they would get tossed. The fix disabled the NULL check, and overwriting became a problem instead.

Both ldapmodify and the 389 Console GUI accepts an unescaped '>' when creating an agreement. I thought '>' was one of the special characters that had to be escaped when part of a dn. (Both methods also of course accepts a '\'-escaped '>', which avoids the problem. Perhaps at least the GUI should escape relevant special characters automatically.)

(Also ldap_explode_dn seems to be deprecated.)

FileConn seems to be unchanged in 1.4.2.2 so the problem likeley still persists there too.

Package Version and Platform

1.3.9.1-10.el7
Centos 7.7.1908

Steps to reproduce

  1. Create more than one replication agreement with '>' or '<' in the name.
  2. Upgrade or reinstall 389-ds-base.

Actual results

Only one replication agreement remains.

Expected results

All replication agreements should still be there.


Actually in 1.4.x we no longer use setup-ds.pl and the perl tools (although they are still available in the legacy-tools subpackage). All the perl stuff and console are deprecated and we are no longer maintaining them. Now in 1.4.x, it's all done via the new python CLI tools (dsctl, dsconf, and dscreate). With the new tools this issue should be non-existent - especially since we no longer run specific upgrade scripts in 1.4.x.

Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

4 months ago

@mreynolds it looks like they reference 1.3.9 here though. Saying this aren't we not using the pl upgrade scripts on that version either?

@mreynolds it looks like they reference 1.3.9 here though. Saying this aren't we not using the pl upgrade scripts on that version either?

My entire comment was regarding 1.4.x. We can look into this for 1.3.x, but the console is not going to be updated.

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.10

4 months ago

Metadata Update from @mreynolds:
- Issue priority set to: normal

16 days ago

Login to comment on this ticket.

Metadata