|
Size: 2295
Comment:
|
Size: 3359
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ||<#FF8080> THESE INSTRUCTIONS ARE OBSOLETE. DO NOT USE THEM. || | |
| Line 5: | Line 4: |
| Using the shared filesystem involves a combination of LDAP, Kerberos, and OpenAFS. DavorOcelic might fill in more information here. :-) | Using the shared filesystem involves a combination of Kerberos and OpenAFS. |
| Line 11: | Line 10: |
| * `/afs/hcoop.net/usr`, the home of home directories * `/afs/hcoop.net/usr/$USERNAME/home`, `$USERNAME`'s home directory |
* `/afs/hcoop.net/user`, the home of home directories * `/afs/hcoop.net/user/U/US/$USERNAME`, `$USERNAME`'s home directory |
| Line 28: | Line 27: |
| Many Kerberos administration commands are run from a special shell. Enter it as root by running `sudo kadmin.local`. | All Kerberos administration commands are run from a special shell, called Kadmin. There are two variants of Kadmin: kadmin is the usual, remote version of the command which can be run on any machine; kadmin.local is the "local" version which can only be ran on the AFS fileserver (deleuze). Invoke kadmin.local as `sudo kadmin.local -p YOURUSERNAME_admin`. It is good to include "-p YOURUSERNAME_admin", or kadmin will "authenticate" as the first user it finds in the ticket cache, which may or may not be the username you expected. All the administrative commands would work anyway (since you ran kadmin.local), but an incorrect principal name would make various statistics incorrect (like name of principal who was adding/changing entries in the DB). To invoke kadmin, use `kadmin -p YOURUSERNAME_admin`. In normal course of action, kadmin asks for a password. This is impractical for automated scripts. As usual, instead of a password, you can also pass a keytab file. Our keytabs are saved in /etc/keytabs/ on each system, and they are readable by group 'wheel'. So administrators should be able to invoke 'kadmin' (use control shell) or kinit/k5start (impersonate any user) by supplying target user's key from a keytab, such as `kadmin -p domtool/deleuze -k -t /etc/keytabs/domtool.deleuze` . |
| Line 32: | Line 44: |
| 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. | We follow the convention that Kerberos users for daemons are named `$DAEMON`, where `$DAEMON` is the name of the daemon (for instance, the name of system user it runs as, or the name of its `/etc/init.d` file). ''Some daemons currently use DAEMON/HOST scheme, but this will be changed later and is not to be used for any new principals you create''. |
| Line 35: | Line 49: |
| addprinc -randkey -policy host $DAEMON/$HOST}}} | addprinc -randkey -policy service $DAEMON}}} |
| Line 38: | Line 52: |
| 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. |
pts createuser $DAEMON}}} |
| Line 44: | Line 57: |
| ktadd -k /etc/keytabs/$DAEMON.keytab -e "des3-hmac-sha1:normal rc4-hmac:normal" $DAEMON/$HOST}}} | ktadd -k /etc/keytabs/$DAEMON -e "des3-hmac-sha1:normal rc4-hmac:normal" $DAEMON chown $DAEMON:wheel /etc/keytabs/$DAEMON chmod 440 /etc/keytabs/$DAEMON }}} |
Basic Architecture
Using the shared filesystem involves a combination of Kerberos and OpenAFS.
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/user, the home of home directories
/afs/hcoop.net/user/U/US/$USERNAME, $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: