We are running Red Hat Enterprise Linux release 8.3 with 389-ds-base-188.8.131.52-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?
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:
usage: dsconf [-h] [-v] [-D BINDDN] [-b BASEDN] [-Z]
dsconf: error: the following arguments are required: instance
Tell me what are the possible solutions, please.
At what point did the repo installation "stable/default" change from 184.108.40.206 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 220.127.116.11 and 18.104.22.168, 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 22.214.171.124 to 2.0.13.
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
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
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
My SUDOers group works with a dedicated sudoUser given, but not if I reference a Netgroup with the User given there.
Same for sudoHost.
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.
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
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)"
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!
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
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['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'
Any thoughts on what could be causing this?
[Micro Electronics Inc]
[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
389 Directory Server 2.1.1
The 389 Directory Server team is proud to announce 389-ds-base version 2.1.1
Fedora packages are available on Fedora 36 and Rawhide (f37)
<https://bodhi.fedoraproject.org/updates/FEDORA-2022-917bd01497> - Bodhi
The new packages and versions are:
Source tarballs are available for download at Download
Highlights in 2.1.1
* Bug and Security fixes
* Transition from BDB(libdb) to LMDB begun. BDB is still the default
backend, but it can be changed to LMDB for early testing.
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
There are no upgrade steps besides installing the new rpms
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
If you find a bug, or would like to see a new feature, file it in our
GitHub project: https://github.com/389ds/389-ds-base
* Bump version to 2.1.1
* Issue 5230 - Race condition in RHDS disk monitoring functions
* Issue 5193 - Incomplete ruv occasionally returned from ruv
* Issue 4970 - Add support for recursively deleting subentries
* Issue 4299 - UI - Add CoS funtionality (#5196)
* Issue 5225 - UI - impossible to manually set entry cache
* Issue 5186 - UI - Fix SASL Mapping regex test feature
* Issue 5221 - User with expired password can still login with
* Issue 5218 - double-free of the virtual attribute context in
persistent search (#5219)
* Issue 5214 - CI Test
* Issue 5197 - Build break in lib389 with INSTALL_PREFIX (#5198)
* Issue 5200 - dscontainer should use environment variables with
* Issue 5189 - memberOf plugin exclude subtree not cleaning up groups
* Issue 5051 - RFE - ADSync flatten tree (#5192)
* Issue 5188 - UI - LDAP editor - add entry and group types
* Issue 5184 - memberOf does not work correctly with multiple
* Issue 5162 - BUG - error on importing chain files (#5164)
* Issue 5186 - UI - Fix SASL Mapping regex validation and other
* Issue 5048 - Support for nsslapd-tcp-fin-timeout and
* Issue 5122 - dsconf instance backend suffix set doesn’t accept
backend name (#5178)
* Issue 5032 - Fix configure option in specfile (#5174)
* Issue 5176 - CI rewriter fails when libslapd.so.0 does not exist (#5177)
* Issue 5160 - BUG - x- prefix in descr-oid can confuse oid parser (#5161)
* Issue 5137 - RFE - improve sssd conf output (#5138)
* Issue 5102 - BUG - container may fail with bare uid/gid (#5140)
* Issue 5145 - Fix covscan errors
* Issue 4721 - UI - attribute uniqueness crashes UI when there are
* Issue 5155 - RFE - Provide an option to abort an Auto Member
* Issue 4299 - UI - Add Role funtionality (#5163)
* Issue 5050 - bdb bulk op fails if fs page size > 8K (#5150)
* Issue 5149 - Build failure on EL8 - undefined reference to `twalk_r’
* Issue 5142 - CLI - dsctl dbgen is broken
* Issue 4678 - Added test cases
Directory Server Development Team