#47565 upgrade to 1.3.2.2 causes error with Content Sync plugin
Closed: wontfix None Opened 10 years ago by rmeggins.

After upgrade to 1.3.2.2, starting the server:

    Oct 16 13:42:35 xxxxx ns-slapd[4205]: [16/Oct/2013:13:42:35
    -0700] - Entry "cn=Content Synchronization,cn=plugins,cn=config" --
    attribute "nsslapd-plugin-depends-on-named" not allowed
    Oct 16 13:42:36 xxxxx ns-slapd[4205]: [16/Oct/2013:13:42:36
    -0700] dse - Could not load config file [dse.ldif]
    Oct 16 13:42:36 xxxxx ns-slapd[4205]: [16/Oct/2013:13:42:36
    -0700] dse - Please edit the file to correct the reported problems and
    then restart the server.

F20 - upgraded from 1.3.1.11 to 1.3.2.0 then 1.3.2.1 then 1.3.2.2

I performed a local 389-ds-base RPM build from master and upgraded my previous packages on F18, and I also encountered these errors. The problem is that the "extensibleObject" objectclass isn't present in the Content Sync Plug-in config entry in my dse.ldif:

{{{
dn: cn=Content Synchronization,cn=plugins,cn=config
objectclass: top
objectclass: nsSlapdPlugin
cn: Content Synchronization
nsslapd-pluginpath: libcontentsync-plugin
nsslapd-plugininitfunc: sync_init
nsslapd-plugintype: object
nsslapd-pluginenabled: off
nsslapd-plugin-depends-on-named: Retro Changelog Plugin
nsslapd-pluginid: ID
nsslapd-pluginversion: PACKAGE_VERSION
nsslapd-pluginvendor: VENDOR
nsslapd-plugindescription: DESC
}}}

If I manually add "objectclass: extensibleObject", my DS instance starts up fine.

The dse.ldif template in the source tree does have the "extensibleObject" objectclass present for the Content Sync Plug-in. This means things will work properly for new instances. Upgraded instances will not work properly though, as the 50contentsync.ldif update file does not include "extensibleObject":

{{{
dn: cn=Content Synchronization,cn=plugins,cn=config
objectclass: top
objectclass: nsSlapdPlugin
cn: Content Synchronization
nsslapd-pluginpath: libcontentsync-plugin
nsslapd-plugininitfunc: sync_init
nsslapd-plugintype: object
nsslapd-pluginenabled: off
nsslapd-plugin-depends-on-named: Retro Changelog Plugin

these will be replaced when the server loads the plugin

nsslapd-pluginId: ID
nsslapd-pluginVersion: PACKAGE_VERSION
nsslapd-pluginVendor: VENDOR
nsslapd-pluginDescription: DESC
}}}

Thanks to Rich for his review! Pushed to the following branches:

master - bf1203a
389-ds-base-1.3.2 - 8bfefb6

This patch doesn't fix the problem. After upgrading from 1.3.0.8 to 1.3.2.3 I still get this error message. When replacing the new
dse.ldif
file with the one before the upgrade, the dirsrv starts w/o any error messages.
If it helps, I could provide a diff file. There is no problem info in it as it's a test on a VM

Replying to [comment:10 spuhler]:

This patch doesn't fix the problem. After upgrading from 1.3.0.8 to 1.3.2.3 I still get this error message. When replacing the new
dse.ldif
file with the one before the upgrade, the dirsrv starts w/o any error messages.
If it helps, I could provide a diff file. There is no problem info in it as it's a test on a VM

I would like to see the diff to see if your content sync plug-in entry has the extensibleObject objectclass present.

Were you upgrading by installing the RPM? The %post phase of the RPM install should run "setup-ds.pl -u", which will process the upgrade scriptlet that is responsible for updating the dse.ldif file.

diff dse.ldif before an after the upgrade
dse.diff

attached is the diff file.

I seems, the %post does run the script, but returns errors. This may be the problem.
I am going to attache that output as well.

Metadata Update from @nkinder:
- Issue set to the milestone: 1.3.2.3

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/902

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata