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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx/message/7H64IJ2LOTVQLUZXT7RB5H5OQDC24X6O/ -- Matúš Honěk Associate Software Developer Red Hat Czech _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/7UMRVPLPJOLC554U3TGOCZXA5RQOD7WG/
