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/
