New Fedora 22 Change proposal: systemd-sysusers

[Miloslav Trmač]

----- Original Message -----
> On Wed, 09.07.14 10:30, Miloslav Trmač (mitr at redhat.com) wrote:
> > ----- Original Message -----
> > 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.
> 
> Yeah, because we dodn't want to intrdocue any new API we have carefully
> made sure that whenever we write pasword, group and shadow files we use
> existing APIs from glibc, more specifically putpwent(), putgrent(),
> putspent() and crypt_r().

> This is about creating system users, not normal users, hence using
> anything more fancy than glibc's native APIs is wrong.

I have already given examples where using a higher-level API would avoid mistakes _and_ make future changes easier; and none of the reasons offered convince me:

> This is not stuff
> which is supposed to land on an ActiveDirectory server or so. It's stuff
> we need to be able to recreate during earliest boot, before the first
> daemons start, where little else but the most basic file system is
> around. libuser is not useful for this kind of environment.

libuser is not configured to edit LDAP if a system is configured as an LDAP client (that functionality exists but usually is only used by admins’ scripts with custom config files); shadow-utils even can’t do it at all.  AFAIK both are quite usable in the environment described above.

> It appears to me that libuser unsuccessfully duplicates APIs from glibc,
> shadow-utils and other packages.

Yes, it only duplicates a glibc API if we ignore all the code that isn’t in glibc, including all the things that systemd-sysusers got wrong; and shadow-utils doesn’t have a C API so libuser doesn’t duplicate a shadow-utils API.

> I mean, it's quite weird to have both
> "passwd" and "lpasswd" around, and then complaining to me that we don't
> need multiple implementations. I mean, I really don't understand why
> there are two implementations of this in the first place!

I was not proposing to call the libuser command-line tools, so I don’t think they are relevant.  I agree it is not good that there are two implementations, and as I already wrote, there is a plan (and people assigned to it) to fix this.

> Also, note that with systemd we try to find solutions that work for most
> Linux distributions. libuser appears to be quite common on Fedora, but I
> am pretty sure that systemd is not the vehicle to make it standard on
> other distributions too, in particular via such a relatively auxiliary
> feature of systemd.

systemd has been happy to make so many different things de-facto standard that I can’t see this being an outlier.


> > As it is, the implementation
(Most discussed elsewhere in the thread.)

> > * breaks the configurable [UG]ID_MIN logic
> > (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
> > that is actually used and needed)
> 
> Well, this is something I really don't like.

I don’t like this either, but it is necessary and unavoidable.  “I don’t want” and “sorry” just isn’t good enough for real-world deployments; that can only get a distribution kicked off the candidate list.


> > 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.
> 
> Good! We just use glibc APIs for writing those files. If you want only
> one implementation, why not get rid of libuser, and stick to glibc? ;-)

Because the glibc API is not at all the right one.  (Way too low-level as systemd-sysusers has successfully demonstrated; impossible to add more fields; enshrines old bad design decisions, like having password expiration in 24-hour granularity.)  Considering the actual library name is completely irrelevant, having the new API written and maintained by people whose _primary occupation_ is to understand accounts and identities seems like a good enough reason to have it done by sssd maintainers, as a library included within that project.

And yes, the plan is to “get rid of libuser”, or rather to only have it a shim layer over the new sssd API.

> > 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.).
> 
> Sorry, I am not going to play your stacking game. This is supposed to be
> simple, work in a minimal early-boot environment, and use stuff that is
> commonly around on Linuxes, from embedded to servers. glibc APIs
> are. libuser is not.

I would be perfectly happy if it called shadow-utils.  That’s 200 kB total, and definitely “commonly around on Linuxes”.

Describing modularity, avoiding duplicate implementations, and keeping specialized knowledge private to specialized modules as a “stacking game” is not helping this discussion.

> > 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
> 
> I am sorry, but to make this very clear: sssd has not place in early
> boot or in smaller setups.

“Around sssd” doesn‘t mean “depending on a running sssd deamon”.  We are very aware of the need to set up and fix up enough of an environment to make it possible to even _start_ sssd.
    Mirek