Ralph Shumaker wrote:
DJA wrote:
Ralph Shumaker wrote:
DJA wrote:
Ralph Shumaker wrote:
DJA wrote:
04:47:55 $ ls -lan /home/
total 20
drwxr-xr-x 5 0 0 4096 Oct 27 09:58 .
drwxr-xr-x 24 1000 0 4096 Nov 12 20:42 ..
drwx------ 19 501 501 4096 Jan 13 2005 dick
drwx------ 21 502 503 4096 Nov 12 02:19 gvl
drwx------ 52 500 500 4096 Nov 15 04:35 rafael
04:48:05 $
Yes. gvl has a UID matching SpecialGroup's GID. Why wouldn't gvl have
a UID of 502 and a GID of 502? Because SpecialGroup already has a GID
of 502. I would have set gvl's UID/GID to 504/504.
I would have also. I just was not thinking about that when I added it.
But the only time I ever see it is when I go to the Users and Groups
GUI. In normal use, why would you ever use -n (in ls -lan)?
My first clue was with NFS. I have a modest home LAN consisting normally
of four, and sometimes as many as six computers. Most all persistent
data is contained on one box (named Seven) which is a dedicated
NFS/Samba file server. All users (my wife and me, and a couple of VPN
users, plus some transient user space) have their own private storage
space in the file server's /home directory which is accessible from any
workstation (or VPN connection) via either NFS or Samba. There are also
some shared directories in /home (the /home/everyone/download directory
being the largest stack of Stuff).
What I found was that there were occasional problems when a user added
to Seven whose name was appropriately the same as a user on another box
(for example Ma-ah), did not have the same Group ID on both Seven and
Ma-ah. We ended up with odd permission problems when joeuser logged into
Ma-ah and tried to access something belonging to Seven's joeuser.
Apparently, NFS (and Samba?) were referencing users and groups by their
numerical names - which sometimes didn't match.
It was even probable that one might find, when browsing Seven from
Ma-ah, seven:/home/joeuser files with a user-group ownership of
joeuser-<locally unknown GID> (e.g. joeuser-504, where Ma-ah's joeuser's
UID-GID is 503-503) rather than joeuser-joeuser, as it is on Ma-ah.
Maybe that's technically okay, and maybe things have been fixed in
recent incarnations of NFS, but such inconsistencies still bug me.
Obviously, for a really big LAN, trying to keep UID-GID pairs sync'ed
might be a bit more tedious - even to the point of impracticality,
without using something IMAPish. Fortunately, I don't have that problem
so I can still afford to be anal.
Which is why I don't like the GUI tool's automatic numbering scheme.
BTW, I don't ever remember having this problem with RH9 and earlier.
RH9 is where I did it (on my PC, the special group with no user that is).
I have such groups also. But I always look at /etc/groups and
/etc/passwd to make sure that I am not creating a UID for a new user
which corresponds to the GID for userless group. That is, even though a
group has no corresponding user, I pretend it does.
I suppose I could have set up a UID along with the special GID, but I
did not want to create a user's home directory for it, although come to
think of it, that may have helped in other ways. Oh well. If I ever
care to deal with it, I will correct it all then.
You can fix it later, but it can be very tedious. To be sure you have
reconciled everything, you really need to search the entire drive (at
least for peace of mind). You never know when some clever app or system
utility will link a UID-GID pair such that changing that relationship
will cause mysterious problems with either a user or a group.
Having experienced just that was one reason I decided to pay more
attention to pairing UID's with GID's.
It's far easier to re-install when I can reformat all partition except
those I don't want to format. For a really simple setup, I have a
separate /home partition. When I want to upgrade my distro (e.g. FC1
-> FC4), I tell the installer to format all partitions except /home.
That way I still have all my users' stuff - including a reference to
their respective UID/GID.
If I have some apps I installed to /usr/local, I can tell the
installer not to format /home and /usr/local.
So, at this point, it seems that it would be a good idea to have /home
and /usr/local as separate partitions. And to be easily resizable, it
would be good to have them as LVMs.
My point exactly.
When reinstalling, you can tell the formatter to leave an LVM alone?
Agreeing with Carl: Yes.
When reinstalling, the distro being installed will know about the apps
you installed previously in /usr/local?
Usually. Of course there's always the horrors bemoaned by Mr. Stremler:
apps which scatter themselves all over the file system, including places
like /etc/<appname>. If you aren't careful about making sure those
config files get herded over to the new installation, some apps may not
work right even if their binaries on on the preserved partition(s).
If you have only one big partition then
o If your partition gets messed up bad, you lose *everything*[1].
o If your / (root) partition gets messed up bad, you lose
*everything*[1].
o When you do upgrades of your distro, you have to restore *all* data
and /home directories if you reformat [2].
o It's more difficult to reallocate space from over-allocated
directories to under-allocated directories (e.g. you just ran
out of space in /tmp because the latest distro upgrade needed
five more gigabytes in /usr ).
This last item sounds like a reason *for* one big partition. Or at the
very least, this last item sounds like an argument for resizable
partitions as opposed to solid partitions. Can an LVM span drives?
You don't always have control over how your drive is filled if
everything is on one partition. If you write a document in OOo which
fills the last available byte on /home/joeuser, only /home is affected
if /home is on its own partition. If /home just sits as a directory on
the same single partition as /tmp and /var/log then you've just written
to the last available byte on the hard drive and the next log entry or
cron job (dbupdate, makewhatis) stops everything except the platters.
--
Best Regards,
~DJA.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
