On Thu, Jul 10, 2014 at 02:41:14PM +0100, Colin Guthrie wrote: > I guess this is probably OK, but isn't it a bit counter intuitive? I > mean one of the reasons for sysuser is due to /etc/ being bootstrapped. > In this case I'd have thought that looking in /etc/ is a bit weird. This probably wouldn't be useful for the case when /etc is bootstrapped, like you say below.
> What if you create a tmpfiles snippet to create a > /etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles > before sysusers? I think that's a bit of an artificial problem. Like with everything else, the outcome depends on the ordering. What would happen if tmpfiles.d were to create a .service file in /etc/systemd/system? Anyway, in this specific case, I believe sysusers should run before tmpfiles, so it is possible to use tmpfiles to create files owned by users created by sysusers. > But then I do accept that when sysusers is used for non-bootstrapping > (i.e. just instead of the %pre useradd in RPM scripts and the like) it > might be something an administrator would want to override. That said, > AFAIK, there is no way to override this current with rpm scripts, so I > wonder if this is really something to bother supporting ongoing. Currently, even if you delete a user like this, there's no mechanism to prevent recreation on the next update of this or another unrelated package. So in some sense it is even worse, because with normal rpm scripts you are safe until this specific package is upgraded. But anyway, I find it very nice that the configuration loading mechanism is consistent between tools, and this inability to override sysusers is annoying. Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
