David Halik wrote:
Anyone who relies on identical UIDs (or user names) across systems is
off his head, even staying with Linux.
I'd have to disagree, we've been doing this in Solaris for years. Not
That follows from actions by the system administrator to make it so.
only is it useful in large user enviroments, it's necessary when dealing
with NFS and a centralized auth system. I manage a user base of around
50,000 active accounts at a state university. Without a system wide
unified namespace, there is no accountability for front-end user
machines and NFS that are accessed by multiple OS's and different
services. I can't have id joesmith being 12345 on one system and 23456
on other, and still 55555 on a third. What if mysql is 23456 randomly?
joesmith logs in an now has access to anything owned by mysql on the
other system. Add with the fact that we have multiple departments using,
Linux, Solaris, BSD, and a mainframe, all with centalized auth, we need
the backends to be synced as well.
That's why sysadmins might make it so. NFS should not require it.
When I looked at this some time ago (I think prior to RHL 6) NFS could
be configured to map UIDs.
For example, install a new default Tikanga, the first user account
will be 500. Do it with Debian, it will be 1000.
Only if installing off the cd. We use LDAP and install based off of a
Did you see the word "default?"
global namespace so that services are the same everywhere. It really
makes things much more simple, especially with clustering and an NFS
backend. It is not difficult at all to install with existing user
accounts and start adding new ones in the proper order. YP anyone?
User names can be important, but don't rely on system accounts matching.
UIDs are important for security within one system, but not externally.
Sure, they're not as important extenernally when there is no centralized
auth/NFS system. Not the case here.
Where one has shared filesystems where UIDs are visible across
systems, then it's the system administrator's (I'm looking at you,
David) responsibility to arrange the mapping.
Exacatly, which we already do with LDAP. Hence my interest in whether or
not nfsnobody needs a significant uid. :) We're adding in our RHEL5
servers to LDAP.
I don't think I'd add system accounts to LDAP
I recall when 99 was the common UID for nobody, and it was used by
Apache and then some others and then too many and they got split out,
and then -1 was introduced and then -2.
The numbers are unimportant, what matters is your rules about who
reads/writes what.
Well nfsnobody's uid can't be completely insignificant or why make it
-2? Why nobody+1? That's the question I was getting at. I just assume
I thought nobody was -1; I see it's still 99. Debian has nobody=-2.
make it nobody+1, as long as it doesn't need to be the highest user.
That's all I'm wondering.
Thanks for the input, I appreciate it.
-Dave
I was reading
http://spectralmud.org/cgi-bin/dwww/usr/share/doc/base-passwd/users-and-groups.txt.gz
and found this:
If root-squashing is in use over NFS, root access from the client is
performed as user nobody on the server.
which we should both know. Root's files appear remotely under this UID
and, probably, it should be a 32-bit number.
So long as there's no collision, its value is unimportant.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
rhelv5-list mailing list
rhelv5-list@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-list
