I agree. Additionally, it will eventually make our lives easier once
we start altering something filesystem related as we won't have to
look for whatever scripting puts something somewhere (yes, I hate side
effects, and yes, been there, even with setup-ds.pl in my short
history). I'd rather have robust slapd than heavy scripting.
On Mon, Aug 13, 2018 at 1:49 AM William Brown <william(a)blackhats.net.au> wrote:
Hi there,
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
filesystem content.
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
possibly anytime.
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.
Thanks,
--
Sincerely,
William
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
--
Matúš Honěk
Associate Software Developer
Red Hat Czech