|
|
|
A cursory glance at the GID lists for each site (created by Neil) doesn't appear to throw up any ID clashes (other than a few in the 1-40 range, such as tty=lp=7, and other=lmadmin=games/staff=20. Where GID>40, there is only one clash: course=console=101).
Although there are some instances of different GIDs used for the same name, the bottom line is that any superset wouldn't have GID clashes for GID<40 & GID=101. However, it has been suggested that we make a clean start in DICE, and that GIDs should start at 10000. If this were to be the case, we'd need to change all relevant GIDs on legacy systems too, in order for DICE/legacy mounts to make sense...
A sensible compromise would seem to be that we keep most of the existing legacy GIDs but export only a useful subset to DICE - say at least the top 10 groups at each site:
| AI | CG | CS |
|---|---|---|
| staff | staff | misc |
| phd | pg_cog | local |
| other | local | lfcs_lec |
| mscs | ltg | cs_pg |
| dept | other | cs_lec |
| package | bin | cs_co |
| bin | hcrc_gst | lfcs_pg |
| guest | contrib | cs2 |
| ai4 | news | cs4 |
| dreamers | gen_gest | cs_ra |
- to avoid "cruft" we could change GIDs of chosen groups to the DICE-compatible range, and change group ownership of those group-owned files on legacy machines.
If we adopt the "export current GIDs into DICE" approach, we might want to re-name the GIDs to give them more Inf-meaningful names, although this may trip up some scripts if GID checks are for names not IDs (I've no idea how prevalent, or likely, this is).
We could still set up DICE accounts to use a primary (passwd) group of "people", even though we might not change group ownership of existing files. New files, however, would - presumably - be group-owned by "people" (with the corresponding global read access for everyone!). We could, perhaps, tweak this with the SGID-bit or umask value, or NFS mount options...
If we retain group "staff" (currently ID 10 at AI & CG, but 10 is "wheel" in DICE/Linux), is there a problem if all staff become members of group "wheel" under DICE? However, it seems more likely that we would change GID "staff" at AI & CG. If we go ahead and change GIDs under legacy (eg staff) will this break scripts that rely (if any do) on staff=10? We should be aware that any significant change of GIDs under legacy will necessitate disruption for all/most Informatics users!
It's a shame there isn't a ugidd for solaris. We could check mount options for Linux to preserve BSD semantics (inherit from directory).
Consequently, AI & CG will arrange to map GID 10 to GID 10010 for all files, whilst CS will decide how many of the staff-related groups to convert to the new staff GID. The GID changes will be arranged on a per-site basis (probably happening over a weekend - they don't need to happen at exactly the same time).
It was also agreed that a small group of additional (secondary) GIDs would be identified that could be converted to the DICE range, thus minimising confusion and disruption - and making use of the same "chgrp window" for the conversion of the staff GID (with the proviso that the number of groups converted to DICE be kept as small as possible).
However, the above constraint (minimum number of group conversions to DICE) raised the additional problem of how to deal with file-sharing via group ownership, since it is user membership of these groups that make this possible, rather than just group ownership of a file (the latter will, of course, still be the case in DICE, as files are to be NFS exported from current Solaris legacy servers, and will retain current user & group ownerships & permissions). Thus, for file-sharing via group ownership to work in DICE, the users must be members of the relevant groups (a more active position than just allowing numeric GIDs to be imported into DICE).
NOTE:
There will only be two primary groups (assigned via the passwd file/table entry), namely "people" & "pseudo" (this is to make jettisoning of groups easier at a later stage). Thus, any user logging-on to a DICE machine will be in group "people". However, additional secondary groups (assigned via the group file/table entry) will be available, and used for file-sharing. This method of file-sharing is different from the "nsu" method, since the former allows shared files to be located anywhere (usually in participating users' home directories), and the latter method usually has all files located in the pseudo-user's home directory.
It was this concern (user membership of secondary groups) that prompted the decision to include an extra number of (converted, re-numbered) groups in DICE, but it was agreed that the number of conversions should be kept to a minimum - there is no barrier to converting any additionally required groups at a later date. Consequently, it was agreed that a small number of the "most popular" groups should be identified at each site (with the emphasis on "number of members of a group" plus "number of group-owned files for that group", since a group may have several members but own very few files, and, conversely, may have few members, but own a large number of files).
There was some discussion about legacy GIDs, but it was felt that only necessary changes would be made here to convert (the few) groups that are to become new DICE ones (changing GID to DICE range). As much as possible, we are trying to leave the legacy world undisturbed. This includes the continued existence of groups that are still used (in the legacy world) for file-sharing, but haven't (yet) made it into DICE.
However, if users default to "people" in the DICE world, any file-sharing based on membership of this group will fail in the legacy world unless the "people" group exists there (which it does) and collaborating users belong to it. There are two solutions to this: change users' primary group to "people" and create a secondary (legacy) "staff" group, or create a secondary group "people" and add all users to it.
It was also observed that there is still a lot of scope for user confusion, and some effort must go into describing the effects of the change for users in both DICE & legacy worlds.
change all currently staff-GID-10-owned files (in legacy world) to the new GID, at a time to be arranged independently by each site
change all legacy-group-owned files to the new GID (in the legacy world), at a time to be arranged independently by each site
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
