|
Size: 3452
Comment:
|
Size: 4716
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 62: | Line 62: |
In the example above, only one key (of 4 or 5 created) is exported for a user. Sometimes it might be desirable to only export a specific key into a keytab file, but we generally just omit the `-e KEY_TYPE` parameter and export all keys to the keytab file. You can view keys stored in a keytab by doing `sudo klist -k /etc/keytabs/KEYTAB_FILE`. To make daemons properly kinit/aklog as the user you created for them, use ``k5start`` command. Many examples of how to use it are already found in our /etc/init.d/ scripts. Important options include `-U` (which kinits as the first principal found in the keytab file, without the need to explicitly name a principal), -f (which specifies the keytab file to kinit from), and -K MINUTES (which re-news the ticket after MINUTES, so that daemons can run for long periods of time). To give $DAEMON the actual permission in AFS space, for most common actions, `fs setacl DIR $DAEMON read` or `write` are good. All subdirectories that get created within the toplevel directory for which you give permissions, will inherit all the permissions. = Listing and setting quotas = To list volume quota, run{{{ fs lq DIR }}} To set volume quota in 1-kilobyte blocks, run{{{ fs sq DIR -max SIZE }}} |
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: