On Fri, 11.04.14 06:33, Colin Walters (walters@xxxxxxxxxx) wrote: > For the fedora-atomic work, the only not-in-Fedora package is > shadow-utils because it requires a patch, that still lives in my > walters/rpm-ostree COPR. > > Patch is linked from my post here: > http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html > > Also, some discussion in the glibc bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=16142 > > What I'd like to open is a discussion about whether /usr/lib/passwd > is the right thing long term. I think it'd be very useful to > support it short term, but it's not perfect. I am really not convinced that this is a good idea and will really fly. Having a fully static passwd file can't really work since admins must have the ability to change certain user attributes for certain system users. This is quite obvious for the root user, where the admin must be able to set the password, but applies to a lot of other cases too (for example, it is common practice to set passwords, shell, home dir for database users, for example for setting up rsync-based backup schemes, or to manipulate group membership for system users). Hence I strongly doubt that immutable, vendor-supplied password files can ever work. The goal here must be to declaratively *populate* the initial password file from some vendor-supplied table, but not to *equate* them, if you follow what I mean. Within the systemd project we have been working on a scheme we call "factory" where packages can drop in static descriptions in /usr/lib of stuff they need in /etc and /var to work properly. The idea is to then use this information automatically at boot if systemd finds /etc and /var empty to populate them. With that in place we can support schemes where a "factory reset" of the system can be easily done by simply flushing /etc and /var altogether and then repopulating it from this data. THis is particularly useful in order to run 1000s of container instances off the same /usr tree, where the instance-specific /etc and /var is created as needed when the container first boots up. These "factory" files would support pretty much two directives only: one to create system users/groups with specific parameters (with the numeric UID/GID possibly sourced off the stat() data of some other file in /usr, so that we can support suid/sgid binaries nicely), and another one to copy files that are strictly needed for boot into /etc). Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
