389-users August 2024

389-users@lists.fedoraproject.org

10 participants
6 discussions

dsconf idempotency
by Marco Favero 07 Dec '25

07 Dec '25

Hello, I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.… to manage my 389ds instances. I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency. For example, if I run the first time in a new fresh installation ``` dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=off ``` it returns 0 and the output *Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see: *There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry* and the exit status is 1. Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort). Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`. So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined) If you have any other hints to address this problem could let me know. Thank you very much Kind Regards Marco

4 4

Help with dblib bdb2mdb
by Alessio 02 Sep '24

02 Sep '24

Hello. I was trying to migrate from bdb to mdb I use this command dsctl instanceName dblib bdb2mdb What I get at the end is: ... WAR The "nsslapd-ldapimaprootdn" setting is obslolete ... For LDAPI configuration, "nsslapd-rootdn" is used instead ... Backends importation 100% Error: 97 - 1 - 53 - Server is unwilling to perform - [] - Unauthenticated binds are not allowed And I don't understand if the operation was successful because dsctl -j instanceName healthcheck still report that "BDB is still used as backend" Any hint would be appreciated. Thanks

2 5

Password policies and replication service accounts
by tdarby＠arizona.edu 26 Aug '24

26 Aug '24

I encountered a problem with replication service accounts in the process of moving my one remaining very old (1.9.x) 389ds system to the new container. This is likely a misunderstanding on my part about how password policies work, so I'd appreciate any insights on this. This system has two MMR instances and an ou=Accounts containing thousands of user accounts. It uses a global password policy for the user accounts (there's no subtree policy on ou=Accounts). As I did with a previous migration to 3.x, I created a new ou, ou=Services,ou=Accounts, to hold the service accounts for replication. When I tried to do the initial replication, it failed because the source instance couldn't authenticate to the destination instance. I was seeing weird messages like "inappropriate authentication", etc. It occurred to me that maybe the issue had to do with the fact that this system had a global policy set whereas the previous system was not using a global policy. I tried removing the global policy and adding a subtree policy instead to ou=Accounts and that solved the problem. So, questions: - Is there a way to have a global password policy but not have it apply to a particular ou? - It appears that setting a subtree policy on an ou (ou=Accounts), does not inherit to a subtree of that tree (ou=Services). Is that right? - It's not clear to me what actually causes the global policy to be active. Does it become active simply by changing any of its password attributes in cn=config?

3 5

Help building rpm for Oracle Linux 9
by Antonis Kopsaftis 26 Aug '24

26 Aug '24

Hello, I'm trying to build the rpm packages for 389 directory server from source on an Oracle Linux 9 x64 server following the instructions from the page: https://www.port389.org/docs/389ds/development/building.html I have zero experience in building rpms. The steps that i followed are: 1) download source tarball (either 389-ds-base-2.5.2.tar.bz2 <https://github.com/389ds/389-ds-base/releases/download/389-ds-base-2.5.2/38…> and 389-ds-base-2.4.6.tar.bz2 <https://github.com/389ds/389-ds-base/releases/download/389-ds-base-2.4.6/38…>) 2) untar tarball (in folder /usr/local/src/) 3) install dependencies with the command: dnf install `grep "^BuildRequires" rpm/389-ds-base.spec.in | awk '{print $2}' | sed -e "s/%{python3_pkgversion}/3/"` 4) Try to make the rpms with the command: SKIP_AUDIT_CI=1 make -f rpm.mk rpms After running the above command, the compiles finished successfully but the rpm building fails. The error is the following: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- .... ============================================================================ Testsuite summary for dirsrv 1.0 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ make[4]: Leaving directory '/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD/389-ds-base-2.4.6' make[3]: Nothing to be done for 'check-local'. make[3]: Leaving directory '/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD/389-ds-base-2.4.6' make[2]: Leaving directory '/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD/389-ds-base-2.4.6' make[1]: Leaving directory '/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD/389-ds-base-2.4.6' + RPM_EC=0 ++ jobs -p + exit 0 Processing files: 389-ds-base-2.4.6-202408240939.el9.x86_64 error: File must begin with "/": %{bash_completions_dir}/ds-replcheck Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.Cs058a + umask 022 + cd /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD + cd 389-ds-base-2.4.6 + DOCDIR=/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + export LC_ALL=C + LC_ALL=C + export DOCDIR + /usr/bin/mkdir -p /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + cp -pr LICENSE /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + cp -pr LICENSE.GPLv3+ /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + cp -pr LICENSE.openssl /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + cp -pr README.jemalloc /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/doc/389-ds-base + RPM_EC=0 ++ jobs -p + exit 0 Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.Mp5ir0 + umask 022 + cd /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILD + cd 389-ds-base-2.4.6 + LICENSEDIR=/usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/licenses/389-ds-base + export LC_ALL=C + LC_ALL=C + export LICENSEDIR + /usr/bin/mkdir -p /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/licenses/389-ds-base + cp -pr COPYING.jemalloc /usr/local/src/389-ds-base-2.4.6/rpmbuild/BUILDROOT/389-ds-base-2.4.6-202408240939.el9.x86_64/usr/share/licenses/389-ds-base + RPM_EC=0 ++ jobs -p + exit 0 RPM build errors: File must begin with "/": %{bash_completions_dir}/ds-replcheck make: *** [rpm.mk:140: rpms] Error 1 [root@dsdev 389-ds-base-2.4.6]# -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The same error occur with the 2.5.2 version of the sources. At first the procedure ended with a different error, but i manage to overcome it by installing the rpm-build package. Regards, Antonis Kopsaftis --

2 2

Performance issue with 2.4.5
by Shilen Patel 07 Aug '24

07 Aug '24

Hello! I have a cluster of VMs running 1.3.10 that I’m migrating to new VMs running 2.4.5. The data is identical as there is replication set up. I have a suffix (ou=groups,dc=example,dc=edu) that has 1 million group objects of objectClass groupOfNames. A search that uses directory manager that tries to retrieve all group DNs of a user is significantly slower in 2.4.5 than it was in 1.3.10. After restarting the directory, the initial query is always slow since I assume the data is being cached. But afterwards, I see the following: 1.3.10: [07/Aug/2024:11:01:28.227539168 -0400] conn=486373 op=1 SRCH base="ou=groups,dc=example,dc=edu" scope=2 filter="(member=uid=testuser,ou=people,dc=example,dc=edu)" attrs="distinguishedName" [07/Aug/2024:11:01:28.230320235 -0400] conn=486373 op=1 RESULT err=0 tag=101 nentries=85 etime=0.003013701 2.4.5: [07/Aug/2024:15:00:57.583606411 +0000] conn=1288 op=1 SRCH base="ou=groups,dc=example,dc=edu" scope=2 filter="(member=uid=testuser,ou=people,dc=example,dc=edu)" attrs="distinguishedName" [07/Aug/2024:15:01:17.012764161 +0000] conn=1288 op=1 RESULT err=0 tag=101 nentries=85 wtime=0.000255898 optime=19.429163009 etime=19.429411947 You can see from the logs that 2.4.5 is significantly slower for the same query that returns the same data. From the client perspective, when you factor in network latency/etc, it’s about 60 times slower. But based on those logs, it’s about 6000 times slower. I ran db2index just in case that would help but it didn’t. The cache settings are the same in both environments. Any ideas on how to improve the performance here? Thanks! - Shilen

2 2

container 3.1.1: BDB is failing to recover from hard shutdown
by tdarby＠arizona.edu 05 Aug '24

05 Aug '24

I have a test instance with two 2.5 container instances replicating. I took one down, but not gracefully, and restarted it using the 3.1.1 container. It showed that it was recovering the RUV and then died 60 seconds after container start. I've tried to restart it several times and it continually fails after 60 seconds. I've never seen a 389ds instance fail to recover so this is alarming: Here's what I see in the logs: [02/Aug/2024:23:40:08.164519017 +0000] - INFO - main - 389-Directory/3.1.1 B2024.213.0201 starting up [02/Aug/2024:23:40:08.167190043 +0000] - INFO - main - Setting the maximum file descriptor limit to: 65535 [02/Aug/2024:23:40:08.324281525 +0000] - INFO - PBKDF2_SHA256 - Based on CPU performance, chose 2048 rounds [02/Aug/2024:23:40:08.328414518 +0000] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [02/Aug/2024:23:40:08.334434881 +0000] - NOTICE - bdb_start_autotune - found 126976000k physical memory [02/Aug/2024:23:40:08.336991774 +0000] - NOTICE - bdb_start_autotune - found 101486140k available [02/Aug/2024:23:40:08.340297223 +0000] - NOTICE - bdb_start_autotune - total cache size: 29477568512 B; [02/Aug/2024:23:40:08.343560343 +0000] - NOTICE - bdb_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Aug/2024:23:40:50.311047857 +0000] - INFO - slapi_vattrspi_regattr - Because pwdpolicysubentry is a new registered virtual attribute , nsslapd-ignore-virtual-attrs was set to 'off' [02/Aug/2024:23:40:50.367322989 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding the replication changelog RUV, this may take several minutes... [02/Aug/2024:23:41:06.202467004 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUVs - Rebuilding replication changelog RUV complete. Result 0 (Success) (dies here and the container exits)

5 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2024