On Wed, 2005-09-07 at 11:11 +0200, Enrico Scholz wrote:
rc040203(a)freenet.de (Ralf Corsepius) writes:
>> > My personal feeling (as a sysadmin and a packager) is that doing
>> > 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
machines
Yes, but ... who cares? All that matters is using consistent ranges in
a
local network.
> I fail to see why system accounts should be shared across
networks and
> 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
Then these UID/GIDs probably better should be ordinary uids,
instead of
system-user ids.
* 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
To me this is a classical case of a customized network setup.
It's the
admin's responsibility to synchronize the uids.
I am doing the same with other dirs on my local network.
* 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
I can't comment on these.
* backup/copying between hosts; when user does not exist at the
destination
yet, resulting files will be readable by the wrong user
Yes, local network admin
responsibility.
* the 'owner' module of iptables requires predictable uids
I can't comment on this.
* it is confusing and unesthetically when users are having different
identities
Let me turn this coin around: You are trying to be stylish and seem
to
be trying to project your personal conventions to the public.
You are missing:
* These points are irrelevant in heterogenious networks. Each OS has
different conventions, so any convention is always somehow wrong and
requires hand-crafting.
* Using fixed uids unnecessarily restricts the number of available uids.
You will sooner or later face the problems of all fixed-table based
configuration approaches.
* There is nothing which prevents you to generate consistent uids in
your network.
> IMO, system users must be local, only.
Yes; but they can access/own files on shared filesystems so all systems
Depends on
your setup.
should have the same view about them.
I don't understand.
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.
Frankly speaking, I am no friend of fedora-usermgmt. To the same extent
it might help you, it interferes with my demands.
Ralf