On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
<mzerqung@xxxxxxxxxxx> wrote:
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,
root is in /etc/passwd. What this means in practice is that as soon as
another user is added, the client machine has a forked copy of
/etc/passwd, and will no longer receive any changes to root's entry
either. But it's not like we change it much.
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,
Yeah. But admins can copy the user data to /etc/passwd, and that wins.
That seems fine to me.
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.
Hmm. Is there a reason you prefer that instead of an "equate but with
overrides" model?
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.
The problem is that I need daemon users to be added (and removed) even
*after* system installation. This can occur when simply upgrading, or
when switching trees, or when adding packages on top of a base tree.
THis is particularly useful in order to run 1000s of container
instances off the same /usr tree,
If your container tree is immutable, then I can see that working, but
do you see supporting dynamic changes to the container content? If so
it's the exact same situation with ostree.
Now maybe with containers you don't care about atomic upgrades, and
furthermore while you're running arbitrary %post code as root, at least
it'd be in a container and not actually operating live on your root
filesystem.
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).
Hmm...I'm going to reply to Martin on this point.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
