AFS
From FarmShare
(→Quota and Backup) |
m |
||
Line 64: | Line 64: | ||
Use "klist -f" and "tokens" for any troubleshooting. | Use "klist -f" and "tokens" for any troubleshooting. | ||
- | + | === grid engine integration === | |
We use AUKS and if you have your renewable TGT and AFS tokens, they will get saved and applied to your job when it runs. | We use AUKS and if you have your renewable TGT and AFS tokens, they will get saved and applied to your job when it runs. | ||
Revision as of 14:48, 29 August 2017
FarmShare no longer uses AFS for users' home directories, but AFS is still accessible on rice
systems.
Contents |
Authentication
Access to AFS requires valid Kerberos credentials and an AFS token. You can examine your current authentication status using the klist
and tokens
commands, and re-authenticate when necessary using the kinit
and aklog
commands. If you have trouble accessing files in AFS, try re-authenticating.
kinit && aklog
Tokens expire after 25 hours (the maximum Kerberos ticket lifetime in the stanford.edu
realm). You can renew your Kerberos credentials without having to re-authenticate if you do so before they expire, and then run aklog
to get a new token. Kerberos tickets are renewable daily, for up to 7 days.
kinit -R && aklog
See the man
pages for the klist
, tokens
, kinit
, and aklog
commands, as well as the Kerberos and AFS service documentation, for more information.
Quota and Backup
The default, per-user quota for AFS home directories is 5 GB, but you may have additional quota due to your enrollment in certain courses, and you can request additional quota (up to 20 GB total) with faculty sponsorship. AFS is backed up every night, and backups are kept for 30 days. The most recent snapshot of your AFS home directory is available in the .backup
subdirectory, and you can request recovery from older backups by submitting a HelpSU ticket.
automated status
In order to see your ticket and token status on login, you may want to add something like these lines to your .bashrc (or the equivalent for your preferred shell):
echo " === === === Your Kerberos ticket and AFS token status: === === ===" klist -5 -f | grep -2 krbtgt | grep Flags | xargs echo 'Kerberos:' tokens | grep AFS | xargs -0 echo 'AFS: '
You'll get output like this is you don't have the right ticket/token:
=== === === Your Kerberos ticket and AFS token status: === === === klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_45787_8xDfEP) Kerberos: AFS:
You'll get output like this if you do have the right credentials:
=== === === Your Kerberos ticket and AFS token status: === === === Kerberos: renew until 01/27/12 15:11:17, Flags: FRIA AFS: User's (AFS ID 45787) tokens for afs@ir.stanford.edu [Expires Jan 21 16:11]
commands
To obtain and cache Kerberos ticket-granting ticket:
kinit
To list cached Kerberos tickets:
klist
Next, you'll want to ensure you have a valid AFS token.
To obtain tokens for authentication to AFS:
aklog
To display the issuer's tokens:
tokens
Then you can just submit jobs to the resource manager, and the jobs will be able to read/write to/from your AFS directories, assuming your kerberos ticket is renewable and forwardable.
To submit a batch job to Grid Engine:
echo "sleep 3600" | qsub
A simple, complete example:
ssh corn kinit aklog echo "sleep 3600" | qsub
Use "klist -f" and "tokens" for any troubleshooting.
grid engine integration
We use AUKS and if you have your renewable TGT and AFS tokens, they will get saved and applied to your job when it runs.
keeping your tokens for more than 24hrs
If you're using cardinal/corn, you should use "keeptoken" per https://itservices.stanford.edu/service/afs/learningmore/tokens
'keeptoken' uses the 'krenew' command, you can read the script directly, it's /usr/local/bin/keeptoken on any corn
If you're submitting a job to the barleys (from the corns) you don't have to use keeptoken. The AUKS/SGE integration will handle the krenew/aklog process for you, but you should verify that you have renewable tickets and re-authenticate, if necessary, before submitting.
If you have have Kerberos credentials when you submit your job, the queuing system should:
- Store your credentials on a remote server at submission time - Renew those stored credentials while your job is waiting to run - Retrieve your credentials on the execution host before your job starts there - Renew your credentials on the execution host while the job is running
one user's experience
To keep your AFS permissions on corn for more than a day you need to do the following:
pagsh kinit;aklog screen keeptoken #and paste whatever prints out.
What this does is initialize a new AFS "pag", get a new renewable Kerberos TGT, then start up a krenew daemon to renew that new Kerberos TGT. This will keep AFS permissions for up to 7 days (the maximum renewable lifetime of a Kerberos ticket in the Stanford realm). You need to do this because when you log out, the logout scripts clean up your tickets/tokens. So you need to make a separate set of tickets/tokens that don't get deleted when you log out.
This is also written here: https://itservices.stanford.edu/?q=service/afs/learningmore/tokens
checking your quota
To check your AFS space quota, try
fs quota
or
/usr/bin/check-stanford-afs-quota
They output different formats. If you want to check your e-mail quota, you can log in to webmail and mouseover your name in the upper right corner. You can also look in the "Account status & storage quota" section of stanfordyou.stanford.edu
avoiding AFS problems
One way to avoid having AFS problems is to not use AFS! Just put all your files into your /farmshare/user_data directory instead of your AFS directory.