#3967 enable SyncRepl plugin in DS
Closed: Fixed None Opened 10 years ago by pspacek.

Bind-dyndb-ldap version >= 4.0 will require SyncRepl (RFC 4533) support in DS. This is supported by DS plugin from version 1.3.2 but we have to enable it:

Requirements:

  • Enable cn=Content Synchronization,cn=plugins,cn=config
  • Enable cn=Retro Changelog Plugin,cn=plugins,cn=config
  • Configure Retro Changelog:

    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-attribute
    nsslapd-attribute: nsuniqueid:targetUniqueId

See https://fedorahosted.org/389/ticket/47388 and http://port389.org/wiki/Content_synchronization_plugin for all the gory details.


Nathan, just checking - is it safe to enable these plugins as proposed? Are there any considerable performance or memory implications?

Of course, the LDIF snippet should look like this:

dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
add: nsslapd-attribute
nsslapd-attribute: nsuniqueid:targetUniqueId

Replying to [comment:1 mkosek]:

Nathan, just checking - is it safe to enable these plugins as proposed? Are there any considerable performance or memory implications?

I don't know of any significant performance issues with enabling these plug-ins, though there will obviously be some overhead.

For the retro-changelog plug-in, you should configure trimming. By default, old changes are not trimmed, so the changelog will just grow. For details on setting the trimming behavior, see the description of nsslapd-changelogmaxage here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Retro_Changelog_Plug_in_Attributes.html

Good point. I think that 2 days are enough for our use case. The client (DNS server) should be connected all the time. Retro log will be necessary only after server crash or restart.

So the LDIF snippet once again:

dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
add: nsslapd-attribute
nsslapd-attribute: nsuniqueid:targetUniqueId
-
add: nsslapd-changelogmaxage
nsslapd-changelogmaxage: 2d
-

I found yet another requirement for bind-dyndb-ldap v4+:

  • create a working directory and make it writeable

E.g. if the working directory for BIND is /var/named and instance name specified in /etc/named.conf is ipa:

options {
    directory "/var/named"; // the default
...



dynamic-db "ipa" {                                                              
    library "ldap.so";
...

... then we have to create working directory /var/named/ipa/.

I don't think that we have to parse /etc/named.conf, we could create /var/named/ipa unconditionally.

Complete LDIF snippets are:

Enable Retro change log:

dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-
add: nsslapd-attribute
nsslapd-attribute: nsuniqueid:targetUniqueId
-
add: nsslapd-changelogmaxage
nsslapd-changelogmaxage: 2d
-

Enable SyncRepl:

dn: cn=Content Synchronization,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-

Ana, please work with Petr on this one, we should have all the information needed now.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

I applied the patch freeipa-akrivoka-0079-02-Enable-Retro-Changelog-and-Content-Synchronization-D.patch on top of commit b4ee7da. The result is that everything works if I do installation with DNS, but installation gets stuck if I do installation without DNS.

The last line in /var/log/ipaserver-install.log is

2013-11-15T08:20:48Z DEBUG args=/usr/bin/ldappasswd -h vm-210.idm.lab.eng.brq.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpo8aBLv -T /var/lib/ipa/tmpXtAK3s uid=admin,cn=users,cn=accounts,dc=ipa,dc=example

The operation gets stuck at this point and never finishes. It seems like deadlock in 389 DS.

Attached files ds.backtrace and packages.rpm-qa contains information from my test system. I'm able to reproduce it 100%, even with clean VM. I guess that this is not related to Ana's patch directly, but may be to some interaction between DS change log and IPA PWD plugin.

We have forgot to add following tweaks to DS configuration:

I will submit patch for this soon.

Additional fix pushed to master: 04627b7

The working directory will be created in bind-dyndb-ldap after all. Corresponding revert: c919363

Metadata Update from @pspacek:
- Issue assigned to pspacek
- Issue set to the milestone: FreeIPA 4.0 - 2013/12

7 years ago

Login to comment on this ticket.

Metadata