dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (01/10/89)
WRT postings: <230@cipher.UUCP>, <159@helios.UUCP>, <16302@iuvax.cs.indiana.edu>
Changing the User to Unix UID mappings is possible under SR9.7 & SR10 but there
are different procedures and different pit-falls.
SR9.7:
The file '/etc/passwd' has the mappings of user name to UID. This file
is created by '/etc/crpasswd' and it assigns new UID values sequentially.
Crpasswd also creates the '/etc/group' & '/etc/passwd.map' files, the latter
is a binary file of mappings from Aegis UIDs (Unique ID #) to Unix UIDs
(User ID #). The file '/etc/passwd' is a text file and may be edited with
any text editor. Once it has been edited, you must re-run /etc/crpasswd
to revalidate /etc/passwd.map, even if you only changed the shell field.
You may edit the Unix UID field in /etc/passwd and change it to a new value,
but after you rerun crpasswd there is one pit-fall that must be dealt with.
The file `node_data/acl_cache is a per-node cache of entries from passwd.map
and its contents may be made invalid by the change in /etc/passwd. Therefore
you should flush the acl_cache on each node that has files owned by the
changed user or had processes run by him. To be safe, flush the cache on all
nodes. To do this, run '/etc/flush_cache' and reboot the node. Note that
if User IDs were changed, it is NOT enough to just run '/etc/fix_cache' you
must run '/etc/flush_cache'. Do not run flush_cache any more often than you
have to because it will create orphaned ACL objects, you don't need to run
it if you are only changing the shell field of /etc/passwd.
SR10:
The registry system (rgy daemon) maintains all account information. There
are two different ways to change Unix UID values. The edrgy tool can be used
interactively to change UID values. A shell script could be written with a
'here document' to automate this process for changing several users. The tool
import_passwd can be used to read in a whole /etc/passwd file and change many
entries at one time. This can be used to import the passwd file from a foreign
system or to reload an edited copy of the Apollo /etc/passwd file. To indirectly
edit the Apollo passwd file, make a copy of the file, edit the copy, import the
copy with the copy contents favored. To make a copy of the file, use '/bin/cp' or
read the file with '/com/catf /etc/passwd > passwd.copy', do not use '/com/cpf'
as the file '/etc/passwd' is a type-manager object and 'cpf' will make an output
of the same type. You will also need to make a copy of /etc/group. Put the
edited version of passwd and the copy of group in a subdirectory and run
import_passwd with the -i & -f options. It would be a good idea to run it with
the -i & -c options first to check that only the desired names will be changed
and you havn't made any mistakes. WARNING, if you use this method, all imported
accounts will have the same organization field. If you don't use the 'org' field
then this will not be a problem, but if you use it, then this method may be more
trouble than its worth. I have NOT used this second method, in theory it should
work but I can't guarantee it. To be safe, make a backup copy of your registry
before you try it. (We use the 'org' field, and I can't risk loosing it, I did
all my UID changing on my SR9.7 registry & used cvtrgy.)
Once you have changed the User IDs in your registry you must run /etc/syncids on
every disk that has any files owned by the changed users. To be safe, run it on
all disks. See the manual "Managing {Aegis | BSD | SysV} System Software",
chapter 4 for more information about these procedures.
Dave Funk
University of Iowapaul@LEDZEP.CC.UMICH.EDU ('da Kingfish) (01/10/89)
The 9.7 and 10 nodes aren't on the same ring? Either generate the sr10 rgy from 9.7, or vice versa. Am I missing something here? We did the convert a long time ago (almost a year!!) and I can't remember the details. --paul
bernie@tessi.UUCP (Bernie Miller) (01/19/89)
In article <8901100250.AA00246@icaen.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU (David B. Funk) writes: >Changing the User to Unix UID mappings is possible under SR9.7 & SR10 but there >are different procedures and different pit-falls. /etc/fix_cache will rebuild the cache after it has been flushed. This avoids having to shut down and reboot the nodes on the network. This can be particularly useful on a large net using shared disk space. -Bernie