----- Original Message ----- > On Wed, 09.07.14 10:30, Miloslav Trmač (mitr@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
