AFS top tips & questions

Introduction

This page is intended to be an executive summary for users wishing to just plug'n'play with AFS. It is not intended to be an introduction to AFS, and users are advised to read other documentation first - see "Documentation for Users and Computing Staff", for example. (Note that in the example commands below, some "folding" of lines may have occurred if you have a narrow browser window - all commands starting with "%" or the continuation prompt should be entered on a single line.)

The Top Tips

How do I see what access permissions a directory has?
```
    % fs listacl -dir  <directory>
    
```
(See the listacl manual page for more info.)
How do I change access permissions on a file?
You can't restrict access to an individual file - access permissions (ACLs) are per-directory. Any files within a particular directory have the same access constraints - which are inherited at directory creation time (but can be changed subsequently). Note that access permission to a file will change if it is moved to another directory with a different ACL.
(See the "Directory Level Access Control" section in the User Guide for more info.)
How do I change access permissions on a directory?
Use "fs setacl" - for example:
```
    % fs setacl -dir <directory> -acl <username>:<groupname> rl 
    
```
This gives permissions (read & list) for group <groupname> to <directory> (or "." for current working directory).
(See the setacl manual page for more info.)
How do I interpret ACL permissions?
Directory permissions are:
- l (lookup) permission:
  Required in order to search or list directories, and access sub-directories
- i (insert) permission:
  Required in order to create files and immediate sub-directories
- d (delete) permission:
  Required in order to remove files and subdirectories
- a (administer) permission:
  Required in order to change the ACL
File permissions are:
- r (read) permission:
  Required in order to read the contents of files in the directory, and to get file details (long listing)
- w (write) permission:
  Required in order to modify the contents of files in the directory and to use the 'chmod' command.
- k (lock) permission:
  required in order to run programs that issue system calls to lock files in the directory.
(See the "AFS ACL Permissions" section in the User Guide for more info.)
Can I still use Unix file permissions?
Yes, but they don't behave in quite the same way. Mode bits on directories are ignored, and only the user set of mode bits are used for files - these can be used to grant or deny read and/or write access to everyone. Note that this only applies to files in AFS filespace.
(See the "How AFS Uses the UNIX Mode Bits" section in the User Guide for more info.)
How do I create a local group?
```
    % pts creategroup -name <myusername>:<groupname>
    % pts adduser -user <username(s)> -group <groupname>
    
```
This creates a group <groupname>, and adds <username(s)> to it. (Note that a group can contain users and/or machines.)
(See the creategroup and the adduser manual pages for more info.)
How do I set up a long-running job?
Note that short term jobs (within the lifetime of normal credentials - currently 16 hours) will just work.
For medium term jobs (more than 16 hours, and less than 1 month), use krenew (see the man page for more info). This ability will need to be requested in the first instance via the Support Form. Once support have made the necessary change, you can then set up longer running jobs as follows:
Get credentials into a seperate credentials cache by doing:
```
	 export KRB5CCNAME=/tmp/mykerbcred 
```
You can substitute a different filename in /tmp if you wish!
You then need to run kinit as follows:
```
	kinit -r30day
```
Run the job with 'krenew '. See krenew manpage for more details.
```
	krenew -k /tmp/mykerbcred -t <jobname>
```
For long term jobs (greater than 1 month), additional admin is required - this ability will need to be requested via the Support Form.
How do I log on to Sun servers?
Some Sun servers (for example, salamander) are not yet fully AFS-enabled, and so - although your AFS directory is available, it may not be immediately accessible.
If, on logging-on to a Sun, you see:
```
    Could not chdir to home directory... : Permission denied
    /usr/openwin/bin/xauth:  timeout in locking authority file .../.Xauthority
    Sun Microsystems Inc.   SunOS 5.9   Generic May 2002
    bash: .../.bash_profile: Permission denied
    
```
You will need to explicitly request a Kerberos ticket and AFS token:
```
    % kinit
    Password for user@INF.ED.AC.UK:
    % aklog
    %
    
```
- you can then check this with the "tokens" command. You can now either continue to work normally (you will need to source your .bash_profile to get your usual environment aliases, etc), or log out and back in again (your Kerberos ticket and AFS token will persist, so subsequent login should proceed normally).
How To Run A cron Job
You can add "HOME=/tmp/..." as the first line of your cron job to stop the RedHat cron daemon trying to access your AFS home directory (which will fail if your AFS tokens have expired, or cron is not running as you).
How To Use Secure Shell Public Keys
Remote access via ssh can fail if the local ssh daemon can't read your .ssh directory. This can be solved by creating a "private" subdir of .ssh, and then making .ssh world-readable ("system:anyuser rl", and then moving the key material stuff into private (which remains private) and then making symbolic links from their original location. You can't simply make .ssh world-readable, as it may also contain private key material which must be kept secret.
Note that the example below only handles the 'common' private key files. You should ensure that all private keys have been moved to the private directory before giving access to your .ssh directory. (Note also that the " \ " below is the continuation-prompt, $PS2, and may differ in your environment.)
```
    % cd ~/.ssh
    % mkdir private
    % fs setacl -clear -dir private -acl system:administrators all $USER all
    % for A in identity id_dsa id_rsa config known_hosts
      \ do 
      \ [ -f $A ] && mv $A private
      \ ln -s private/$A
      \ done
    % fs setacl ~/.ssh system:anyuser rl
    % fs setacl ~ system:anyuser l
    
```

For further information on any of the above topics, see the relevant documentation.