We should implement this sooner than later, setting milestone to 1.4.1

While working on this I found there were selinux issues with using a directory under /dev/shm, filed this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1737550

While working on this I found there were selinux issues with using a directory under /dev/shm, filed this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1737550

This is fixed in:

selinux-policy-3.14.3-29.el8
selinux-policy-targeted-3.14.3-29.el8

We still have an outstanding issue on master branch with the new bdb code, where it puts everything into the db-home-dir:

https://pagure.io/389-ds-base/issue/50755

Issue linked to Bugzilla: Bug 1780842

https://pagure.io/389-ds-base/pull-request/50959

Commit 96c8abba relates to this ticket

Commit de9f26ac relates to this ticket

Commit 335b6de1 relates to this ticket

Hey @mreynolds, I'm trying to set this up and I have some issues.

First, nsslapd-db-home-directory is not set in cn=config by default. But the directories are created:

[root@server-f32 ds]# ls -laR /dev/shm/
/dev/shm/:
total 4
drwxrwxrwt. 3 root   root    80 Apr  3 05:34 .
drwxr-xr-x. 5 root   root   380 Apr  3 05:33 ..
drwxrwx---. 3 root   root    60 Apr  3 05:34 dirsrv
-rw-------. 1 dirsrv dirsrv  32 Apr  3 05:34 sem.slapd-server-f32.stats
/dev/shm/dirsrv:
total 0
drwxrwx---. 3 root   root   60 Apr  3 05:34 .
drwxrwxrwt. 3 root   root   80 Apr  3 05:34 ..
drwxrwx---. 2 dirsrv dirsrv 40 Apr  3 05:34 slapd-server-f32
/dev/shm/dirsrv/slapd-server-f32:
total 0
drwxrwx---. 2 dirsrv dirsrv 40 Apr  3 05:34 .
drwxrwx---. 3 root   root   60 Apr  3 05:34 ..

If I revert https://pagure.io/389-ds-base/c/de9f26a, then it is set, but the instance fails to start (also note the misformatted error message):

[03/Apr/2020:05:34:31.204801473 +0000] - ERR - bdb_version_write - Could not open file "%s" for writing Netscape Portable Runtime %d (%s)
 - /dev/shm/dirsrv/slapd-server-f32/DBVERSION[03/Apr/2020:05:34:31.209123265 +0000] - ERR - mkdir_p - /dev/shm/dirsrv/slapd-server-f32: error -5966 (Access Denied.)
[03/Apr/2020:05:34:31.213323921 +0000] - CRIT - bdb_start - Can't start because the database directory "/dev/shm/dirsrv/slapd-server-f32" either doesn't exist, or is not accessible
[03/Apr/2020:05:34:31.217530628 +0000] - ERR - ldbm_back_start - Failed to init database, err=-1 BDB0092 Unknown error: -1
[03/Apr/2020:05:34:31.221676634 +0000] - ERR - plugin_dependency_startall - Failed to start database plugin ldbm database
[03/Apr/2020:05:34:31.228612730 +0000] - CRIT - dblayer_setup - dblayer_init failed
[03/Apr/2020:05:34:31.233137443 +0000] - ERR - ldbm_back_start - Failed to setup dblayer

Finally, after chowning /dev/shm/dirsrv to dirsrv user I'm able to start the instance.

I also had to increase the default 64M /dev/shm size in container, otherwise I'd get errors about not enough space:

[03/Apr/2020:05:45:04.923618795 +0000] - ERR - no_diskspace - No enough space left on device (/dev/shm/dirsrv/slapd-server-f32) (63991808 bytes); at least 1771674009 bytes space is needed for db region files
[03/Apr/2020:05:45:04.927831885 +0000] - ERR - ldbm_back_start - Failed to init database, err=28 No space left on device

So maybe we should add a check in the installer that there is reasonably enough memory, so we won't get a borked instance right after its creation?

After VM instance is rebooted, directories are recreated with the correct permissions.
But this error message is logged:

[03/Apr/2020:06:21:59.823167185 -0400] - ERR - bdb_version_write - Could not open file "%s" for writing Netscape Portable Runtime %d (%s)
 - /dev/shm/dirsrv/slapd-ci-vm-10-0-138-196/DBVERSION[03/Apr/2020:06:22:00.439789711 -0400] - INFO - slapd_daemon - slapd started.  Listening on All Interfaces port 389 for LDAP requests

Okay this is weird. I recently fixed all of this as I ran into the same issue you did, and I had it working. I'll look into it...

https://pagure.io/389-ds-base/pull-request/51007

Commit 52e28942 relates to this ticket

This change is breaking FreeIPA in Docker containers on Rawhide in Azure Pipelines CI.
The reason is different, though: the failure is due to access denials:

Apr 20 07:17:01 master1.ipa.test systemd[1]: Starting 389 Directory Server IPA-TEST....
Apr 20 07:17:01 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:01.098652705 +0000] - ERR - slapd_system_isFIPS - Can not access /proc/sys/crypto/fips_enabled - assuming FIPS is OFF
Apr 20 07:17:01 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:01.100752219 +0000] - ERR - slapd_system_isFIPS - Can not access /proc/sys/crypto/fips_enabled - assuming FIPS is OFF
Apr 20 07:17:01 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:01.205521816 +0000] - INFO - main - 389-Directory/1.4.4.0 B2020.107.0000 starting up
Apr 20 07:17:01 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:01.206426022 +0000] - INFO - main - Setting the maximum file descriptor limit to: 1048576
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.053475357 +0000] - INFO - PBKDF2_SHA256 - Based on CPU performance, chose 2048 rounds
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.056675478 +0000] - INFO - bdb_config_upgrade_dse_info - create config entry from old config
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.060998107 +0000] - NOTICE - ldbm_back_start - found 1572864k physical memory
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.061546411 +0000] - NOTICE - ldbm_back_start - found 1094067k available
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.061894013 +0000] - NOTICE - ldbm_back_start - cache autosizing: db cache: 39321k
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.062476117 +0000] - NOTICE - ldbm_back_start - total cache size: 32212254 B;
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.062832919 +0000] - ERR - bdb_version_write - Could not open file "/dev/shm/dirsrv/slapd-IPA-TEST/DBVERSION" for writing Netscape Portable Runtime -5966 (Access Denied.)
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.063184222 +0000] - ERR - mkdir_p - /dev/shm/dirsrv/slapd-IPA-TEST: error -5966 (Access Denied.)
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.063510924 +0000] - CRIT - bdb_start - Can't start because the database directory "/dev/shm/dirsrv/slapd-IPA-TEST" either doesn't exist, or is not accessible
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.063840326 +0000] - ERR - ldbm_back_start - Failed to init database, err=-1 BDB0092 Unknown error: -1
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.064237029 +0000] - ERR - plugin_dependency_startall - Failed to start database plugin ldbm database
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.066451043 +0000] - CRIT - dblayer_setup - dblayer_init failed
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.067152448 +0000] - ERR - ldbm_back_start - Failed to setup dblayer
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.067595351 +0000] - ERR - plugin_dependency_startall - Failed to start database plugin ldbm database
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.067997854 +0000] - ERR - plugin_dependency_startall - Failed to resolve plugin dependencies
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.068399856 +0000] - ERR - plugin_dependency_startall - object plugin Roles Plugin is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.068758759 +0000] - ERR - plugin_dependency_startall - accesscontrol plugin ACL Plugin is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.069079661 +0000] - ERR - plugin_dependency_startall - preoperation plugin ACL preoperation is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.069396863 +0000] - ERR - plugin_dependency_startall - object plugin Class of Service is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.069715565 +0000] - ERR - plugin_dependency_startall - object plugin Views is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.070025967 +0000] - ERR - plugin_dependency_startall - betxnpreoperation plugin 7-bit check is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.070333469 +0000] - ERR - plugin_dependency_startall - preoperation plugin Account Usability Plugin is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.070644171 +0000] - ERR - plugin_dependency_startall - betxnpreoperation plugin Auto Membership Plugin is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.070978973 +0000] - ERR - plugin_dependency_startall - preoperation plugin deref is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.071370776 +0000] - ERR - plugin_dependency_startall - preoperation plugin HTTP Client is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.071698278 +0000] - ERR - plugin_dependency_startall - betxnpreoperation plugin Linked Attributes is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.072067981 +0000] - ERR - plugin_dependency_startall - betxnpreoperation plugin Managed Entries is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.072403383 +0000] - ERR - plugin_dependency_startall - object plugin Multimaster Replication Plugin is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.072737285 +0000] - ERR - plugin_dependency_startall - extendedop plugin whoami is not started
Apr 20 07:17:02 master1.ipa.test ns-slapd[302]: [20/Apr/2020:07:17:02.073329689 +0000] - ERR - plugin_dependency_startall - database plugin ldbm database is not started
Apr 20 07:17:02 master1.ipa.test systemd[1]: dirsrv@IPA-TEST.service: Main process exited, code=exited, status=1/FAILURE
Apr 20 07:17:02 master1.ipa.test systemd[1]: dirsrv@IPA-TEST.service: Failed with result 'exit-code'.
Apr 20 07:17:02 master1.ipa.test systemd[1]: Failed to start 389 Directory Server IPA-TEST..

This is with 1.4.4.0:

2020-04-20T07:11:54.7514625Z Installing dependencies:
2020-04-20T07:11:54.7515300Z  389-ds-base                       x86_64  1.4.4.0-1.fc33                            rawhide       1.8 M
2020-04-20T07:11:54.7516088Z  389-ds-base-libs                  x86_64  1.4.4.0-1.fc33                            rawhide       904 k
...

Note that the fix from issue 51008 does not help here because that only affects instances created with dscontainer.

The issue is most likely due to bdb dblayer code being called under dirsrv user already. The permissions in /dev/shm/dirsrv allow only root to create directories, according to the package: https://koji.fedoraproject.org/koji/fileinfo?rpmID=21199274&filename=/dev/shm/dirsrv

Information for file /dev/shm/dirsrv
Name    /dev/shm/dirsrv
Digest (sha256) 
Size    0
Modification time   Thu, 16 Apr 2020 17:45:40 UTC
User    root
Group   root
Mode    drwxr-xr-x
Flags   
RPM 389-ds-base-1.4.4.0-1.fc33.x86_64.rpm

@abbra, could it be related to selinux policy (https://pagure.io/389-ds-base/issue/49731#comment-614359)

@tbordaz no, this is F33 container in Docker on Ubuntu 16.04 host. No SELinux anywhere.

Okay thanks.

@mreynolds https://pagure.io/389-ds-base/pull-request/51007#request_diff configured container instance to keep using db_dir.
Later https://pagure.io/389-ds-base/pull-request/51010#request_diff reverted the setting to let dscontainer use /data/run.
Can the second change have contributed to the current failure ?

Another data point: it also fails outside of containers in a normal VM, according to https://github.com/freeipa/freeipa/pull/4552#issuecomment-616469248

@abbra, what user is creating the instance in your setup? Is it not root? Because during instance creation time is when we create /dev/shm/dirsrv/slapd-INSTANCE/. Then the bdb code should work fine, so I'm not sure how you are getting permission issues unless you are running dscreate as a non-root user. If it is a non-root user then that is something we can probably fix quite easily...

It is root, of course. We don't run dscreate, we use lib389 library directly but our code runs under root.

The code is here: https://pagure.io/freeipa/blob/master/f/ipaserver/install/dsinstance.py#_528, it works for years.

Attached is ipa-server-install log that has log lines provided by 389-ds installer:

However, a question I have (not related to the actual issue) how this supposed to work after machine restart? /dev/shm will be a clean one, with no directory there.

It is root, of course. We don't run dscreate, we use lib389 library directly but our code runs under root.
The code is here: https://pagure.io/freeipa/blob/master/f/ipaserver/install/dsinstance.py#_528, it works for years.

IPA setup code should be working...

It calls create_from_ags(), which calls _install_ds() which creates the db-home-directory, and a lot of other important directories, and sets permissions and ownerships. But it looks like we pass/ignore when we hit an OS error creating one of these directories (not sure why it's ignored), and all the possible failures are not logged.

So is it creating /dev/shm/dirsrv/slapd-INSTANCE or not? I suspect it is not.

If I provide a scratch build, or srpm, can you/someone run your tests again? I want to know why it can't create that directory before working on a fix.

However, a question I have (not related to the actual issue) how this supposed to work after machine restart? /dev/shm will be a clean one, with no directory there.

/dev/shm persists after reboots :-) Not sure about in containers though, but I would assume so ...

On my Fedora system /dev/shm is a tmpfs, so it is not persistent. I haven't made it that way myself, this is a default.

Hi @mreynolds
the issue can also be reproduced with the following scenario:
- ipa-server-install
- ipa-backup
- ipa-server-install --uninstall -U (/dev/shm/dirsrv/ is now empty)
- ipa-restore /path/to/backup.
Logs:

Preparing restore from /var/lib/ipa/backup/ipa-full-2020-04-20-13-10-01 on master.ipa.test
Performing FULL restore from FULL backup
Temporary setting umask to 022
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Unable to get connection, skipping disabling agreements: directory server instance is not running/configured
Stopping IPA services
Restoring files
Systemwide CA database updated.
Restoring from userRoot in IPA-TEST
ldif2db failed: 
Restoring from ipaca in IPA-TEST
ldif2db failed: 
Restarting GSS-proxy
Starting IPA services
Restoring umask to 18
CalledProcessError(Command ['/usr/sbin/ipactl', 'start'] returned non-zero exit status 1: "Existing service file detected!\nAssuming stale, cleaning and proceeding\nFailed to start Directory Service: CalledProcessError(Command ['/bin/systemctl', 'start', 'dirsrv@IPA-TEST.service'] returned non-zero exit status 1)\n")
The ipa-restore command failed. See /var/log/iparestore.log for more information

Hi @mreynolds
the issue can also be reproduced with the following scenario:
- ipa-server-install
- ipa-backup
- ipa-server-install --uninstall -U (/dev/shm/dirsrv/ is now empty)
- ipa-restore /path/to/backup.
Logs:
Preparing restore from /var/lib/ipa/backup/ipa-full-2020-04-20-13-10-01 on master.ipa.test
Performing FULL restore from FULL backup
Temporary setting umask to 022
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Unable to get connection, skipping disabling agreements: directory server instance is not running/configured
Stopping IPA services
Restoring files
Systemwide CA database updated.
Restoring from userRoot in IPA-TEST
ldif2db failed:
Restoring from ipaca in IPA-TEST
ldif2db failed:
Restarting GSS-proxy
Starting IPA services
Restoring umask to 18
CalledProcessError(Command ['/usr/sbin/ipactl', 'start'] returned non-zero exit status 1: "Existing service file detected!\nAssuming stale, cleaning and proceeding\nFailed to start Directory Service: CalledProcessError(Command ['/bin/systemctl', 'start', 'dirsrv@IPA-TEST.service'] returned non-zero exit status 1)\n")
The ipa-restore command failed. See /var/log/iparestore.log for more information

@frenaud - do you have the DS errors log from the failed start?

@frenaud - so this seems very strange to me what you are doing. If you uninstall the Directory Server instance it will remove /dev/shm/dirsrv/slapd-INST, but you must reinstall the instance for that directory to be recreated. So I don't know what the ipa backup/restore does, but if its not recreating the instance via lib389 or dscreate then I would expect /dev/shm/dirsrv/ to remain empty. If it's not recreating instance, but doing some kind of FS restore, then the backup process should also be checking for the nsslapd-db-home-directory attribute under cn=bdb,cn=config,cn=ldbm database,cn=plugins,cn=config , and backup that directory as well.

However, a question I have (not related to the actual issue) how this supposed to work after machine restart? /dev/shm will be a clean one, with no directory there.

/dev/shm persists after reboots :-) Not sure about in containers though, but I would assume so ...

dev shm on any system is tmpfs Mark ....

After VM instance is rebooted, directories are recreated with the correct permissions.
But this error message is logged:
[03/Apr/2020:06:21:59.823167185 -0400] - ERR - bdb_version_write - Could not open file "%s" for writing Netscape Portable Runtime %d (%s)
- /dev/shm/dirsrv/slapd-ci-vm-10-0-138-196/DBVERSION[03/Apr/2020:06:22:00.439789711 -0400] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests

We probably need to put in dbhome as a systemd template for creation on boot, similar to what we do for some of the other instance files.

However, a question I have (not related to the actual issue) how this supposed to work after machine restart? /dev/shm will be a clean one, with no directory there.
/dev/shm persists after reboots :-) Not sure about in containers though, but I would assume so ...

dev shm on any system is tmpfs Mark ....

Yes, yes, I was not aware of some of Ludwig's changes, and when it appeared to remain exactly intact after a reboot I thought /dev/shm behaved differently then /tmp (tmpfs). I will now do the walk of shame and go to bed...

However, a question I have (not related to the actual issue) how this supposed to work after machine restart? /dev/shm will be a clean one, with no directory there.
/dev/shm persists after reboots :-) Not sure about in containers though, but I would assume so ...
dev shm on any system is tmpfs Mark ....

Yes, yes, I was not aware of some of Ludwig's changes, and when it appeared to remain exactly intact after a reboot I thought /dev/shm behaved differently then /tmp (tmpfs). I will now do the walk of shame and go to bed...

No walk of shame here at all - The point of the dbhome there is that everying in dbhome is non-persistent IIRC. I remember reading the bdb docs to find that ... it's just we need a way to recreate those needed dirs on startup

I absolutely agree, all this investigations help for a better understanding of everyone.

@firstyear is right we need to recreate the db_home_dir. Only DS knows the owner of the db_env and where it will be located, how systemd could contribute here without stepping on bdb initialization.

I absolutely agree, all this investigations help for a better understanding of everyone.
@firstyear is right we need to recreate the db_home_dir.

Ludwig's patch recreates everything. I didn't realize it recreated /dev/shm/dirsrv, I thought it only did the instance directory. This was part of my confusion. Anyway @abbra also pointed out an issue with tmpfiles.d where we should add the db-home-dir. So I will being doing a patch at some point, but I still need to double check what is happening in @frenaud case...

@mreynolds
you can find logs here from our weekly test with fedora rawhide PR 4552.

@mreynolds, When ns-slapd access db home directory, it is running as 'dirsrv' (nsslapd-localuser). /dev/shm/dirsrv seems to be created by root with not the write right (drwxr-xr-x https://pagure.io/389-ds-base/issue/49731#comment-642947).
Could it be that on container the mask used by 'root' is not the expected one.

@mreynolds, When ns-slapd access db home directory, it is running as 'dirsrv' (nsslapd-localuser). /dev/shm/dirsrv seems to be created by root with not the write right

I don't think that's the problem, because /dev/shm/dirsrv/slapd-inst DOES have the correct permissions

We need to back this out :-( There is a lot of weird behaviors after reboots, and on debian and containers

We should just be creating the instance's db home directories right under /dev/shm, not /dev/shm/dirsrv But this requires modifying the selinux policy which can take a few releases to get done? So in the meantime we need to turn it off (just set it to db dir for now) :-(

We need to back this out :-( There are a lot of weird behaviors after reboots, and on debian and containers
We should just be creating the instance's db home directories right under /dev/shm, not /dev/shm/dirsrv But this requires modifying the selinux policy which can take a few releases to get done? So in the meantime we need to turn it off (just set it to db dir for now) :-(

https://pagure.io/389-ds-base/pull-request/51038

Temporarily set the db_home_dir to db_dir (effectively disabling it)

We may need an ldif for admins to apply to cn=config if they have this too ...

Commit 3ca89e31 relates to this ticket

Undo /dev/shm/dirsrv

Commit 3ca89e3 relates to this ticket

2ae260fb5..8fbdf92ac 389-ds-base-1.4.3 -> 389-ds-base-1.4.3

Reopened the bug (BZ#1780842) to create new selinux rules for

/dev/shm/slapd-*

Trying to use /dev/shm/dirsrv (created by the rpm as root) as a container in tmpfs is a bad idea, we should let the instances do what they are already doing at startup, but set the default location to /dev/shm/slapd-INST. This will resolve all the permission and access issues once the new selinux labels are in place.

@firstyear

We may need an ldif for admins to apply to cn=config if they have this too ...

What do you mean? A reversion ldif? This has not landed in RHEL yet, and its only been in one or two upstream/rawhide releases. I am going to do a new build now - I don't think we need to devise a backout process. It either works for Admin, or it does not, is how this appears to be working for people. So once I get a new build done we "should" be okay.

Okay, that's all good by me then :)

Undo /dev/shm/dirsrv

It's still present in https://pagure.io/389-ds-base/blob/master/f/ldap/admin/src/scripts/DSCreate.pm.in#_957
So when I use perl installer in a container (I know, I know), instance fail to start because of not enough space.

Commit c7da66eb relates to this ticket

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/2790

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.