On Wed, Jul 09, 2014 at 10:30:27AM -0400, Miloslav Trmač wrote: > ----- Original Message ----- > > Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I > > wrote up a Change: > > > > https://fedoraproject.org/wiki/Changes/SystemdSysusers > > A move to something more declarative makes sense (whether in systemd or through some kind of long-expected declarative rpm facility doesn’t matter to me much.) > > The sysusers tool _really_ needs to use an existing API to manage the user database, though. As it is, the implementation > * validates names incorrectly > * breaks the configurable [UG]ID_MIN logic (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that is actually used and needed) > * is likely to break various readers software by not updating the shadow files > * doesn’t do any auditing. > We are currently already in a bad position by having two major implementations of maintaining the critical databases, we absolutely don’t want any more. > > At this point this means systemd-sysuers should either run the executables from shadow-utils, or link to libuser. (Or, I suppose, use accountsservice, but that ends up calling shadow-utils.). > > The plan is to have a single implementation, living around sssd. (Jakub knows more.) Either of two API points above are planned to use the sssd implementation, so can be relied on long-term. > Mirek The effort Mirek is talking about (a not-too-detailed design page can be found at [1]) aims at a) using the SSSD database primarily for user accounts and b) providing a rich DBus API. We actually started with b) because that's also usable and useful for remote (LDAP, AD, ..) users which SSSD already handles. The benefit of using the SSSD database would be the ability of use a richer set of attributes that the passwd file has. The API would be usable in a similar fashion accountsservice is now. Even though SSSD would be in the business of managing local users, I think the benefits of using SSSD are mostly for managing non-system accounts. So from this point of view, I don't see what systemd is doing as conflicting with what we plan on doing. One issue to keep in mind is that we planned on reverting the order of the NSS modules to "sss files". Given that systemd-sysusers would write to the files directly with the libc API, we need to sync the changes systemd-sysusers to SSSD database, otherwise we risk inconsistencies and there would also be an extra round-trip to nss_sss before reaching to nss_files. We /do/ plan on the syncing anyway, because some admins are still used to vipw their passwd databases and there are legacy scripts around, but still -- could we, when the SSSD interface is available, call out from systemd-sysusers to the SSSD, with some fallback for cases where SSSD is not running? Are there any plans on changing any of the shadow-utils commands to call out to systemd-sysusers when adding system users with either useradd (useradd -r) or libuser? btw I completely agree that even when we switch to using SSSD to manage local accounts, the system must still be usable (sans the extra attributes and the rich API..), if SSSD wasn't able to start for example. [1] https://fedorahosted.org/sssd/wiki/DesignDocs/UsrAccountMgmtConsolidation -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
