Bug 2023056

GOST_YESCRYPT is not supported in RHEL anymore. It looks like 389-ds lacks removal of the configuration when a plugin gets disabled.

you can disable it manually with

# dsconf INFO-XXXXXX-PT plugin set GOST_YESCRYPT --enabled off

Unfortunatly this did not work. The configuration was rolled-back sundaymorning, now I tried upgrading, prior to the update I ran the command (successful) however after the update the issue persists. Removing the relevant seciton from the dse.ldif file 'solves' the issue, but it 'feels' wrong.

My understanding is that early centos 8.5 builds (1.4.3.23-2 and 1.4.3.23-7) contained invalid GOST_YESCRYPT password storage support. This support was completely removed in 1.4.3.23-10 (https://git.centos.org/rpms/389-ds-base/c/0381070f4db756c9771576582981e332aab5d141?branch=c8s-stream-1.4) with removal of config GOST plugin entry and GOST init plugin callback gost_yescrypt_pwd_storage_scheme_init.

So if an instance was created with early 8.5 builds, a plugin entry (dn: cn=GOST_YESCRYPT,cn=Password Storage Schemes,cn=plugins,cn=config) was created. Then the upgrade removed the init callback and startup fails.
A quick relief is by editing dse.ldif and removing cn=GOST_YESCRYPT,cn=Password Storage Schemes,cn=plugins,cn=config.

A fix is to remove that entry during upgrade.

(In reply to Arjen Heidinga from comment #2)
> Unfortunatly this did not work. The configuration was rolled-back
> sundaymorning, now I tried upgrading, prior to the update I ran the command
> (successful) however after the update the issue persists. Removing the
> relevant seciton from the dse.ldif file 'solves' the issue, but it 'feels'
> wrong.

Indeed even if a plugin is disabled, the server tries first to load its init function. If it fails to load it, plugin setup fails and server can not start.

I removed the GOST_YESCRYPT plugin lines from dse.ldif and the problem was solved. IPA is back again. I think that future upgrades should remove these lines from dse.ldif file.

Bug confirmed on CentOS Stream release 8
Workaround confirmed as working also :)

Fix pushed upstream => POST

Fixed in 389-ds-base-1.4.3.30-3.module+el8.7.0+15600+347cafc6 => MODIFIED

Build Tested: 389-ds-base-1.4.3.30-3.module+el8.7.0+15600+347cafc6.x86_64

# dsconf test plugin show entryuuid
dn: cn=entryuuid,cn=plugins,cn=config
cn: entryuuid
nsslapd-pluginDescription: none
nsslapd-pluginEnabled: on
nsslapd-pluginId: none
nsslapd-pluginInitfunc: entryuuid_plugin_init
nsslapd-pluginPath: libentryuuid-plugin
nsslapd-pluginType: betxnpreoperation
nsslapd-pluginVendor: none
nsslapd-pluginVersion: none
objectClass: top
objectClass: nsSlapdPlugin

# dsctl test stop
Instance "test" has been stopped

# mv /usr/lib64/dirsrv/plugins/libentryuuid-plugin.so /usr/lib64/dirsrv/plugins/libentryuuid-plugin.so.sav
# dsctl test start
Instance "test" has been started

Error logs:
[05/Aug/2022:12:17:20.026001169 -0400] - ERR - symload_report_error - Netscape Portable Runtime error -5977: /usr/lib64/dirsrv/plugins/libentryuuid-plugin.so: cannot open shared object file: No such file or directory
[05/Aug/2022:12:17:20.054125155 -0400] - ERR - symload_report_error - Could not open library "/usr/lib64/dirsrv/plugins/libentryuuid-plugin.so" for plugin entryuuid
[05/Aug/2022:12:17:20.056785832 -0400] - ERR - plugin_setup - "entryuuid" plugin in library "libentryuuid-plugin" not initialized and ignored

I can see the server is running even after restart, Marking it as VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds:1.4 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7552