rc040203(a)freenet.de (Ralf Corsepius) writes:
> > My personal feeling (as a sysadmin and a packager) is that
> > something like this in %pre (not %post, if you want files owned by
> > the new user) is the Right Thing:
> > %pre
> > if ! id foo > /dev/null 2>&1 ; then
> > /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo
> > fi
> This does not solve the problem that users will have different UIDs on
> different machines.
Note the -r. We are talking about system accounts.
The '-r' makes only
* that the generated UID is in a certain range; the exact values are
unpredictable and it's highly probably that they differ on different
* that there is no expiration date for the account (that's why '-r'
should be used with fedora-usermgmt also)
I fail to see why system accounts should be shared across networks
why there is any need to force unique UIDs on them.
ok, some examples:
* 'vdr' and 'vdradmin' (from livna) are running on different hosts as
the 'vdr:video' user. Both share configuration files and data which is
exported by NFS
* some data in a shared filesystem which shall be read by apache only
but not by other users -> all affected machines will need the same
uid/gid for apache
* programs (e.g. milters) which are installed in chroot environments and
use unix-sockets as communication points. Access restrictions can be
installed easily with filesystem permissions when all chroots are
seeing the same user-uid pairs
* backup/copying between hosts; when user does not exist at the destination
yet, resulting files will be readable by the wrong user
* the 'owner' module of iptables requires predictable uids
* it is confusing and unesthetically when users are having different
IMO, system users must be local, only.
Yes; but they can access/own files on shared filesystems so all systems
should have the same view about them.
It is easy to create users with predictable uids and fedora-usermgmt
offers a simple method doing this. I am not aware of any drawbacks,
it solves the problem of unpredictable uids and without explicit
configuration it is transparent to users because it has the same
behavior as plain 'useradd' then. So I do not see reasons why it
should not be used.