The prop system is ATN's way of ensuring that user information is homogenous across the different systems in the DCI namespace. At the heart of this system is a database containing default information on users: their userid, uid, gid, gecos field, home directory, and default shell. Using the propclient tool in conjunction with a local configuration file, this system will update your local password files with the information housed in the database. To use the system, create a /etc/prop.cfg file on your local machine. An example file can be found at /afs/isis.unc.edu/@sys/etc/prop.cfg. Copy this file to your /etc directory and customize it to your system (instructions on how to do that are contained in the file itself). Then run the propclient as root and it will automatically update the password files on your local system.
To invoke the propclient, use the command:
There are five basic components of the prop.cfg file.
Lets take a look at an example prop.cfg file:
# prop.cfg propagation configuration file # Blank lines and lines beginning with a hash are ignored :post /usr/sbin/pwconvHere you see an example of a post-processing command. The this system uses a shadow password file, each time the password file is rebuilt, the shadow file also needs to be updated. The form of a post-processing command looks like
:post <command line>
You can have multiple post processing commands, is so, the commands will be executed in a first in first out manner. Warning: If you have not run the pwconv before, but want to use it in the prop system, make sure you run pwconv by hand before running propclient. Running pwconv for the first time through propclient can destroy any local passwords, including root's.
# First, users to be added. # local users; root, bin, etc, that # are not listed in users file, are added # with a full /etc/passwd-style entry. :passwd root:!:0:0::/:/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: lpd:!:9:4294967294::/: guest:!:100:100:Be our guest!:/home/guest: supman:*:102:7::/:/bin/ksh nobody:!:4294967294:4294967294::/:Here is a list of all local users that you want to be included in the new passwd file. Note that when the propclient rewrites the password file, it pulls the entries for the accounts from the prop.cfg file, not the original /etc/passwd file. Make sure that there are no passwords in this file if you are using a shadow password file.
Next we'll look at how we can add individual DCI users to a system in the prop.cfg file.
# individual users to be added from the prop/users file # should be listed alone. If there are individual users # to deny access (who otherwise would be granted access # by the categories listed below), a minus sign should be # placed before the username. NOTE: If you list a username # listed twice in the users file, the first one listed will # be used. Substitutions listed here will take priority over # any category substitutions. godehn jan chris sh->/usr/local/bin/bash dir->/export/home/chrisNotice how you can overide attributes stored in the database for the users. Here chris wants to use the bash shell instead if the korn shell, which is his default shell stored in the database. The syntax for making a substitions is as follows:
One the same line as the userid you would like to make the substition for, enter the following construct: substition->value, if you would like to make more than one substition for a users, separate the constructs with a space. Valid substitions include:
If you would like to add groups of people, see below for how to work with categories.
# Categories to be allowed access should be listed with # an @ sign preceding. Categories to be denied access # should have a minus sign preceding. @ALL means to allow # access by default. If a user belongs to # a category allowed # access (or ALL implicitly) *and* a category denied access, # the user will be denied access. Thus, categories with a minus # sign should be considered "stigma" categories, and only people # who should be denied access should be added to those categories. # -@NOLOGIN # @ALL @ISISNotice that substitions work the same with categories as they do with individual users.
Valid categories include:
# Next, groups. Since groups have no categories, # all groups are added unless specifically denied # below. Syntax is similar to the individual # syntax above; i.e., below can be listed /etc/group # entries or group names preceeded by a minus. # Note when giving an /etc/group-style line that # propclient will strip out usernames it did not add to the # new /etc/passwd file processed above. :group system:!:0:nuucp,root staff:!:1:socs,sbnet,operator,tapesvs bin:!:2:root,bin sys:!:3:root,bin,sys adm:!:4:bin,adm uucp:!:5:nuucp,uucp mail:!:6:postmstr,harris security:!:7:bcl,bwj,root,cutler,harris,postmstr cron:!:8:root printq:!:9: audit:!:10:root ecs:!:28: nobody:!:4294967294:lpd,nobody # End of prop.cfgFor the groups selection, you should delete the groups that are in the sample prop.cfg file and paste in the contents of you group file.
Once, you have the prop system in place, you should not edit your /etc/passwd or /etc/group files, instead make changes to your /etc/prop.cfg file and run the propclient.
Each time the propclient is run, it makes a backup of the pre-existing file: /etc/passwd.last and /etc/group.last. If something bad or unexpected happens, you can recontruct with these files.
Maintained by: email@example.com
Last Updated: Aug 19, 1998