----- Original Message -----
On Wed, 09.07.14 10:30, Miloslav Trmač (mitr(a)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