I've seen a few tickets and changes come past with relation to the new
python installer, and how it works differently to setup-ds.pl. The main
one has been around the behaviour of supporting directories and
The reason for the abscence of many features is not because lib389 is
not complete, but to highlight where ns-slapd is deficient.
In systemd and containers it is expected that resources are created on
demand by the application. You should not make any assumptions about
the state of your environment at start up, expecting it to be reset at
As a result, having setup-ds.pl create things like
/var/log/dirsrv/slapd-<instance> or anything else (/var/run/dirsrv) for
example can not be relied upon. We have to assume they *do not exist*.
Lib389 intentionally *does not* create these supporting directories. If
they are missing it is the responsibility of ns-slapd to create them at
runtime, with the appropriate permissions.
When you are making changes to ns-slapd and lib389 the only thing that
we can rely on existing is the content of /etc/dirsrv/slapd-
instancename. Everything else *must* be created at startup by ns-slapd
so that we can work in this stateless model.
Please keep this in mind as we make changes, and I'll be trying to keep
an eye out on it during reviews. lib389's only job is to take user
input and define dse.ldif. Everything else is up to ns-slapd.
Hi Simo and Alex,
It's come to my attention that there are some discussions underway for
new features being designed for IPA and 389ds. However these are
happening away from the 389-ds mailing lists.
Given that I am still a core team member, and no longer a staff member
at Red Hat, it would be excellent if these discussions could be brought
into the open - We are an open community and we should act like it,
rather than keeping this topics inside of Red Hat.