The issue is a regression that happened between 1.3.6.1 and 1.3.6.2 If a plugin init function calls slapi_register_plugin (e.g. Schema Compat or NIS-plugin) then it creates entries like:
dn: cn=nis-server-plugin-betxn_postop,cn=plugins,cn=config cn: nis-server-plugin-betxn_postop objectClass: top objectClass: extensibleObject nsslapd-pluginType: betxnpostoperation nsslapd-pluginInitfunc: nis_plugin_init_betxn_postop nsslapd-pluginprecedence: 50 nsslapd-pluginId: nis-plugin nsslapd-pluginVersion: 0.56.1 (betxn support available and enabled by default) nsslapd-pluginVendor: redhat.com nsslapd-pluginDescription: NIS Server Plugin creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config
The impact of such entries should be minor but it may prevent DS startup (RHBZ 1444431)
Problem can be reproduced with those package (RHEL/Fedora)
389-ds-base-1.3.6.3-4.fc26.x86_64 FAILED 389-ds-base-1.3.6.2-2.fc26.x86_64 FAILED 389-ds-base-1.3.6.1 (up to 910a7ad + 9fd3cff) FAILED 389-ds-base-1.3.6.1-7.el7.x86_64 FAILED 389-ds-base-1.3.6.1-3.el7.x86_64 FAILED
hostname
Contains weird entries like
dn: cn=nis-server-plugin-betxn_postop,cn=plugins,cn=config dn: cn=nis-server-plugin-internal-postop,cn=plugins,cn=config dn: cn=nis-server-plugin-postop,cn=plugins,cn=config dn: cn=schema-compat-plugin-betxn_postop,cn=plugins,cn=config dn: cn=schema-compat-plugin-betxn_preop,cn=plugins,cn=config dn: cn=schema-compat-plugin-extop-preop,cn=plugins,cn=config dn: cn=schema-compat-plugin-internal-postop,cn=plugins,cn=config dn: cn=schema-compat-plugin-postop,cn=plugins,cn=config dn: cn=schema-compat-plugin-preop,cn=plugins,cn=config
Metadata Update from @tbordaz: - Custom field component adjusted to Plugins - Custom field origin adjusted to IPA - Custom field type adjusted to defect
Attaching a tentative fix but it has NOT been tested yet. <img alt="0001-Ticket-49230-slapi_register_plugin-creates-config-en.patch" src="/389-ds-base/issue/raw/files/daf059ca6b5791e50a37866387bccf0c21ae9a563f5326db08d06d31ca75e854-0001-Ticket-49230-slapi_register_plugin-creates-config-en.patch" />
Metadata Update from @tbordaz: - Issue assigned to tbordaz
Seems like a good idea, but there is no "add_entry" flag in plugin_setup().
Why not alter new_plugin_entry to make the dep of the entry as needed, and then to check if we actually need to add the entry?
Under what conditions does this duplication occur? Isn't there a flag that can be put on plugin entries that makes them "hidden" in cn=config somehow?
Thanks William for looking at the patch. You are right, the 'add_entry' flag was set as 'unused' by https://pagure.io/389-ds-base/issue/49193
int plugin_setup(Slapi_Entry *plugin_entry, struct slapi_componentid *group, slapi_plugin_init_fnptr p_initfunc, int add_entry __attribute__((unused)), char *returntext)
I actually think this flag should be used to not systematically create the plugin entry
Metadata Update from @tbordaz: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1444431
Metadata Update from @tbordaz: - Custom field reviewstatus adjusted to review
@tbordaz - Shouldn't __attribute__((unused)) now be removed from the prototype?
__attribute__((unused))
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to review (was: ack)
Thanks for your review and advice. I agree prototype should be changed. Attaching a new patch
One last thing. I don't see how this patch fixes anything. We now check the flag to create the entry, but in every case we set that flag anyway:
ldap/servers/slapd/tools/pwenc.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/plugin.c: if((rc = plugin_setup(entry, 0, 0, 1, returntext)) != LDAP_SUCCESS){ ldap/servers/slapd/config.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/config.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/configdse.c: retval = plugin_setup(e, 0, 0, 1, returntext);
One last thing. I don't see how this patch fixes anything. We now check the flag to create the entry, but in every case we set that flag anyway: ldap/servers/slapd/tools/pwenc.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/plugin.c: if((rc = plugin_setup(entry, 0, 0, 1, returntext)) != LDAP_SUCCESS){ ldap/servers/slapd/config.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/config.c: if (plugin_setup(e, 0, 0, 1, returntext)) ldap/servers/slapd/configdse.c: retval = plugin_setup(e, 0, 0, 1, returntext);
Whoops, I found the one place where we don't set it:
ldap/servers/slapd/plugin.c: rc = plugin_setup(e, group_identity, initfunc, 0, returntext);
Nevermind...
@tbordaz Did you attach the new patch ....? I can't see it :(
ohoh !! sorry I forgot to attach it
<img alt="0002-Ticket-49230-slapi_register_plugin-creates-config-en.patch" src="/389-ds-base/issue/raw/files/4867f4d36bbe4bf17fdae2b4eb711aa65944d3decc834208ebfab2cda3eef8b3-0002-Ticket-49230-slapi_register_plugin-creates-config-en.patch" />
Thanks Thierry, ack!
Push to master , thanks Mark and William
git push origin master Counting objects: 6, done. Delta compression using up to 8 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 884 bytes | 0 bytes/s, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git@pagure.io/389-ds-base.git a771800..8e367dd master -> master
Metadata Update from @tbordaz: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Thierry I just branched 1.3.6 - can you cherry-pick your fix to 389-ds-base-1.3.6? Thanks!
Thanks Mark for the head up
git push origin 389-ds-base-1.3.6
Counting objects: 6, done. Delta compression using up to 8 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 883 bytes | 0 bytes/s, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git@pagure.io/389-ds-base.git e086b83..64ff837 389-ds-base-1.3.6 -> 389-ds-base-1.3.6
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/2289
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.