To: RedHat Development Mailing List <redhat-devel-list@redhat.com>
Subject: MASSIVE headaches with new >100 GIDs in RH6.0
Date: Thu, 19 Aug 1999 17:49:28 +1000
From: Tony Nugent <Tony.Nugent@usq.edu.au>

I *really* need an answer to this from someone at RedHat.

RH6.0 introduces a new set of GIDs in /etc/group which includes 101
(console) and 102 (utmp).

Not to mention other weirdness such as "user" xfs (group "xfs") which
has been given the honour of uid.gid = 100.233 (huh???)

This seeming simple issue has now hit us here in the face pretty hard,
and we are facing some BIG logistical problems as a result.  We are
not at all impressed.  (In fact, I've mentioned this before in a
previous message to this list).

The problem is that we have, for a _long_ time, been using GID 101 =
"staff" and 102 = "students" (103 = "postgrad" etc).  This is on
_dozens_ (hundreds?) of unix client boxes, and more than a dozen
heavily used unix servers.  We have a mixed environment here - sun,
hp, solaris, linux (mostly intel, a few alpha and sparc), alpha
(dec/tru64), etc.  (And hundreds of windows boxes of course, but this
issue is of little concern here with samba - thank goodness! :)

The problem is that the server boxes are doing some heavy-duty
NIS'ing, SAMBA file serving and NFS exporting of home and other
"teaching subject related" directories (eg, from our linux web
server).  If the GIDs and UIDs don't match at each end, then you get
permission denied for any writes.  OUCH!  Especially for home
directories.

There are several solutions to this problem...

1 - change the GIDs (and some UIDs) on *every* new RH6.0 installation or
    upgrade.  (Messy and very inconvenient).

2 - make the server boxes export specific directories with specific
    ownerships.  (Tricky at best, especially on some of the non-linux
    boxes.  I assume that the ugidd daemon is now "defunct", but we
    don't want to start running that anyway).

3 - change all the user account GIDs on all our boxes here to get them
    out of the 100-199 range.  (Ugly and painful... eg, ever tried
    doing this for several hundred users with NIS+ over several
    domains on sparc server boxes running solaris?  It's not much
    fun).

Our inclination is to go with option 3 - change all the user GID
numbers everywhere, once and for all.

However, before we do this, we NEED to know:

- will RH6.1 change all the system-used GIDs to a range _below_ 100?
  If so, what will these changes be?

  IMHO, this is the BEST solution.  (Hrrmph - it shouldh't have
  happened in the first place, see below).  If this back-peddle is in
  the wind, then it's only RH6.0 installs that we will need to worry
  about.

- what GID and UID range will redhat PROMISE not to "invade" and cause
  hassles in the future?  (The xfs values that are used make me
  "nervous"...)

  For example, if we change all the 101's to, say, 111 or 201, what is
  the guarantee that sometime in the future these numbers won't be
  used so we have to go through this pain again?

- if we go with option 1, it will mean doing something like this after
  *each* install that we do here:

  find / -gid 101 -exec chgrp 201 {} \;
  perl -spi -e 's,:101:,:201:,' /etc/group
  (similar thing to /etc/passwd)

  Question is... will doing this break anything?  For example, are
  these GIDs hard-coded into any important system utilities?  (They
  shouldn't be - that would be a very bad thing indeed - but I have to
  ask this anyway).


Why the decision was taken to use GID's (and some UIDs) above 100 for
system-related "users" is beyond me - a very bad and short-sighted
decision, with no real consideration of the consequences of doing
this.  Especially when there are dozens of GID numbers available below
100.  (So RedHat -- consider yourselves very severely chastised :)

The essence of upgrading should be - in most cases - to embrace the
"principle of least suprise".  (Exceptions to the rule, of course...
nice suprises are always welcome:) 

Don't get me wrong - I really like redhat distributions, but doing
fundamental things like this without much consideration of the
implications for everyone else leaves a very bad taste in my mouth.


One last point... I have never seen a CHANGES file that lists the
changes between redhat distributions.  If one exists, can someone tell
me the URL?  If no such documentation exists, then it should.


I earnestly await a reply (privately or publically) from one of the
good folks from RedHat to let me know of the best path to take to
solve this problem we have here.  Hopefully this suprise - or anything
similar - will never happen again.

Thanks.

Cheers
Tony
 -=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
  Tony Nugent <Tony.Nugent@usq.edu.au>           <linux@usq.edu.au>
  Computer Systems Officer                       Faculty of Science
  University of Southern Queensland, Toowoomba Oueensland Australia
 -=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-

-- 
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null