|
Size: 975
Comment:
|
Size: 2050
Comment: Creating a new user
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
| * `/afs/hcoop.net/usr/USERNAME/home`, USERNAME's home directory | * `/afs/hcoop.net/usr/$USERNAME/home`, `$USERNAME`'s home directory |
| Line 23: | Line 23: |
= Creating a new user = We follow the convention that Kerberos users for daemons are named `$DAEMON/$HOST`, where `$DAEMON` is the name of the daemon (for instance, the name of its `/etc/init.d` file) and `$HOST` is the primary fully-qualified domain name for the host where the daemon runs. To add the Kerberos principal for a daemon, run:{{{ addprinc -randkey -policy host $DAEMON/$HOST}}} AFS users exist separately from Kerberos principals. To add the AFS user for a daemon to which you want to assign UID `$UID`, run:{{{ pts createuser -name $DAEMON.$HOST -id $UID}}} Note the period, not slash, between `$DAEMON` and `$HOST`. The `-id $UID` can be omitted if you want a randomly-generated UID. "keytab" files smooth the way to running daemons that run with AFS privileges. An access-protected local file contains a user's credentials, and daemons read these files on starting up in order to authenticate. To create a keytab for a daemon, run:{{{ ktadd -k /etc/keytab/$DAEMON.keytab -e "des3-hmac-sha1:normal rc4-hmac:normal" $DAEMON/$HOST}}} |
Basic Architecture
Using the shared filesystem involves a combination of LDAP, Kerberos, and OpenAFS. DavorOcelic might fill in more information here. 
File conventions
The /afs tree contains shared filesystems. /afs/hcoop.net (symlinked from /afs/hcoop as well) is our piece of the AFS-o-sphere. Subdirectories include:
/afs/hcoop.net/usr, the home of home directories
/afs/hcoop.net/usr/$USERNAME/home, $USERNAME's home directory
/afs/hcoop.net/common/etc, the home of non-platform-specific fun stuff like DomTool
Connecting to AFS from an HCoop server
I found this handy summary of the commands that must be run:
On our servers, it seems sufficient to run: