389-users March 2022

389-users@lists.fedoraproject.org

18 participants
22 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

ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett 11 Dec '23

11 Dec '23

Hi all, We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this: [12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”) Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”. Has anyone seen this kind of thing before? This is 389ds running on CentOS7 as follows: 389-ds-base-1.3.9.1-10.el7.x86_64 Regards, Graham —

3 9

Plugin development licensing
by DUVERT Vincent 09 May '23

09 May '23

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directory…) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

2 2

passwordExpirationTime vs password admin
by Mike Wohlgemuth 01 Apr '22

01 Apr '22

Hi! We are running Red Hat Enterprise Linux release 8.3 with 389-ds-base-1.4.3.16-19.module+el8.4.0+11894+f5bb5c43.x86_64 installed. We have configured password expiration, and passwordExpirationTime is getting updated properly when the end user binds and changes the password, or when cn=directory manager changes the password. We have an API that is invoked to allow the users to change their password when they have forgotten it, so it cannot bind as the end user, but we also do not want it to have to bind as cn=directory manager. However, we haven't had any luck getting any other user to update passwordExpirationTime when updating the password. Looking at the code, it looks like password admins should be allowed to update passwordExpirationTime, but we have those configured and it's not working. Is there something we are missing? Thanks!

3 7

389DS + Ubuntu
by iyagomailru Alexander Yakovlev 01 Apr '22

01 Apr '22

Good afternoon. I installed 389-ds on Ubuntu. I need to use mdb instead of bdb. But the installed dconf utility does not contain the 'config' option: # dsconf usage: dsconf [-h] [-v] [-D BINDDN] [-b BASEDN] [-Z] instance {{backend,schema,healthcheck,plugin,memberof,usn,rootdn,whoami,referint} ... dsconf: error: the following arguments are required: instance Tell me what are the possible solutions, please.

6 10

version changes/updates
by Neel Karandikar 31 Mar '22

31 Mar '22

Hello At what point did the repo installation "stable/default" change from 1.4.4.17 to 2.0.x? I know this can depend on the variability of yum repos etc But today on ours I noticed that yum module info 389-directory-server -> stable/default is now pointing at v2.0.13 running Centos 8 stream we are currently running 1.4.4.16 and 1.4.4.17, with some test servers at 2.0.13 (as they auto upgraded with what was in our repo) I actually just want to know what versions of release notes I need to review, so I can see changes that might occur when I upgrade from 1.4.4.16 to 2.0.13. Thx! Neel

2 1

unconventional replication, alma 8 master to centos 7 slave: Unable to acquire replica: error: no such replica
by Lewis Robson 25 Mar '22

25 Mar '22

Hello all, i am working to do multi master with two different versions of OS (alma 8 and centos 7), this means that the 389 on alma 8 is using dsidm and cockpit and the 389 on centos 7 is using 389console with ldap commands. the alma 8 directory tree is how we want it to be, users inside, all working as expected. the 7 directory tree is the complete standard given when 389ds is setup. on the 7 machine (slave) I have the bind dn information of cn=replication manager,cn=config. This has been set up on the 8 mschine via cockpit in the replication agreement to connect with these credentials. an ldapsearch lets me connect with them and purposely typing the username or password wrong for the agreement gives a different error so im confident the account is okay. The error I see, when i try and initiliaze the agreement from the 8 cockpit view to the slave machine is: ERR - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=289 op=3 replica="unknown": Unable to acquire replica: error: no such replica Does anyone know anything that I could check for the error to get around this? Thankyou kindly.

3 10

Re: Netrgoups referenced in the SUDOers Group do not work
by Dudas Tibor ABRAXAS 25 Mar '22

25 Mar '22

Hi My SUDOers group works with a dedicated sudoUser given, but not if I reference a Netgroup with the User given there. Same for sudoHost. Works not: [cid:image002.png@01D83DF2.E1A952E0] Works: [cid:image003.png@01D83DF2.E1A952E0] The netgroups can be resolved on the 389ds client, though: [root@testldapclient01 ~]# getent netgroup ABX_user_test ABX_user_test ( ,axtsc,) [root@testldapclient01 ~]# getent netgroup ABX_server_test ABX_server_test (testldapclient01,-,-) (testldapclient01.mydomain.com,-,-) Changes in the SUDOers Group work only with some delay. Restart of sssd and relogin does not help. So it is a bit clumsy to test. Any help is highly appreciated. Thanks, Tibor

2 7

Running 389ds server in Kubernetes: Questions on certificate names and bootstrapping
by Johannes Kastl 24 Mar '22

24 Mar '22

Hi all, finally I had some time to try and get the 389ds server running in Kubernetes. As I am also still learning Kubernetes (and will be for the next few years, always something new to learn), I tried to get this into a helm chart. And: It works! > https://github.com/johanneskastl/389server-helm-chart/tree/main/charts/389s… This means, I can create a Kubernetes secret containing the DS_DM_PASSWORD and SUFFIX_NAME variables, and the pod running inside Kubernetes gets those values injected from the secret. I could connect to the server using the "cn=Directory Manager", i.e. I get an "No such object" response but no longer a "ldap_bind: Invalid credentials (49)" warning. There are three questions that I could not answer myself: 1. Does the docker container have any kind of bootstrapping mechanism included, i.e. I put some LDIF files somewhere and those get imported automatically? Or is the idea to just setup a working server, that the user can then put things into. And that state is being preserved in /data/? I guess it is the latter. 2. The choice of certificate/key naming is unfortunate, as Kubernetes secrets automatically contain a tls.key and tls.crt file. I can easily inject such a secret, but as 389ds is expecting server.key and server.crt, I guess those files would just be ignored. Right? Could this maybe be enhanced (not changed, to keep backwards compatibility)? That would make life in Kubernetes land easier. 3. The Dockerhub page say "Instances now support running dirsrv as non-root...". However I could not get it to run without root permissions. That might have been due to the "wrong" user I picked. So, before spending more time on debugging this, is this still supported? Which user/group should I pick to do that? Thanks in advance, and have a nice day everyone! Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 9

OpenLDAP import into 389 Directory Server failing
by Jason W. Lewis 24 Mar '22

24 Mar '22

After RHEL, etc dropped OpenLDAP, I’ve begun testing with 389 Directory Server. Currently, I’m trying to use openldap_to_ds to import slapd.d config and an LDIF export to import my old database into the new server. I’ve created a new instance in 389-ds named terminal-config. I’ve tried the following variations on the idea, all of which gave me the same results: * exported the LDIF from OpenLDAP 2.4 on Oracle Linux 7 and CentOS 6 servers. * Rewrote all files being imported to make sure they weren’t corrupt. * used relative and absolute path names to the files * Tried importing with a new instance (as mentioned above) and no instance at all * When using dscreate to make the new instance, I’ve tried setting it up differently (allowed sample entries and not, etc) No matter what I do, this is what I get when I try: [root@ldaptest ~]# openldap_to_ds terminal-config /root/slapd.d /root/terminals.ldif Examining OpenLDAP Configuration ... Traceback (most recent call last): File "/usr/sbin/openldap_to_ds", line 250, in <module> result = do_migration(inst, log, args, skip_overlays) File "/usr/sbin/openldap_to_ds", line 178, in do_migration config = olConfig(args.slapd_config, log) File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/config.py", line 305, in __init__ for db in dbs File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/config.py", line 305, in <listcomp> for db in dbs File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/config.py", line 112, in __init__ self.suffix = ensure_str(self.config[1]['olcSuffix'][0]) KeyError: 'olcSuffix' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/openldap_to_ds", line 257, in <module> log.error("Error: %s" % " - ".join(str(val) for val in msg.values())) AttributeError: 'str' object has no attribute 'values' [root@ldaptest ~]# Any thoughts on what could be causing this? -- [Micro Electronics Inc] Jason Lewis Systems Administrator jwlewis(a)microcenter.com<mailto:jwlewis@microcenter.com> | [signature_251198827] 614-777-2728 [Micro Center Secure Email] CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended exclusively for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you receive this message in error, please contact the sender by reply e-mail and destroy all copies of the original message and attachments. Thank you

4 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2022