AFS Userguide: Tokens
When you login to a Unix computer, you establish your identity to that computer using your local username and local password for that particular computer (all of the machines run by Leland Systems use your SUNet ID and its password for your local username and password). When you enter your username, you are claiming to the computer that you are the person entitled to use that computer identity; and when you enter your password correctly, you are validating your claim. The computer accepts that you are who you claim to be and it lets you login.
Now, when you login, you think of your identity in words -- your computer identity is your username. Although the computer always displays your identity information in words (your username), the computer really thinks about you in terms of the number it has associated with your username -- this number is called your user id (uid).
Your user id is local to each individual computer and allows that particular computer to give you access to your files -- as long as those files are within diskspace that that particular computer controls (e.g. files in /tmp). This local user id is not sufficient to identify you to a distributed network file system like AFS, so you also have an AFS user id. On machines run by Leland Systems, your local user id is always the same as your AFS user id, but if you use a computer run by someone else, this may not be true, whether or not your usernames are identical.
The combination of your AFS user id and its associated password (which is your SUNet ID password) identify you to the AFS filesystem. Once you've authenticated, AFS creates a service ticket for you, which is cached on local disk on the machine you've logged into. This service ticket is called a token, and it confirms your identity to AFS, so it doesn't have to ask you to identify yourself each time you try to do anything on the file system. This token lasts for 25 hours, but will be destroyed when you log out, whether it has expired or not.
- Long Running Jobs
If you need to run a compute job that will take longer than 25 hours, you'll need to keep your token longer than normal. If your token expires, your job may not be able to read its input data set or write its output file, or it may look like a runaway job and be killed by the anti-runaway script we run on all the Leland cluster machines. To keep your job running, you'll need to use a program called keeptoken, which has the following syntax:
[paste the command that keeptoken suggests]
You'll only need to specify the username if your local and AFS usernames are not the same (this will not be the case for leland cluster machines). See
man keeptokenfor more information.
- Staying logged-In for a long time and resuming sessions
If you remain logged-in to a computer for over 25 hours you may find that the computer won't let you write to your own files, won't let you download email, etc. This is because your token has expired, or you may have lost network connection or been timed out. Run
and enter your password to reauthenticate yourself to AFS.
Alternatively, you can note what system you login to and then use the following sequence of commands:
- kinit;aklog [put in your SUNetID password again when prompted]
- [paste the command that keeptoken suggests]
You can then "detach" from the screen session and "reattach" at any time.
To detach, press:
- CTRL-a, d
Then you can just exit or reattach.
To reattach, make sure you login to the same system and then use this command:
- screen -rdA
For more information on how to use screen, run:
- man screen
Using this method, you can run a job that will have AFS access for up to a week. As the week comes to a close, you can just run kinit;aklog again in the screen session to extend AFS access for another seven days.
- Logging in via rlogin or rsh
The standard rlogin and rsh programs authenticate you to the local machine only, not to AFS. This means that you won't be able to access any restricted files in AFS. To remedy this, run
and enter your password to authenticate yourself to AFS.
The alternative is to use klogin ("kerberized rlogin"). If you are connecting to a Leland Systems machine, this will work -- provided that you are logging in from a machine which provides kerberized outbound connections. You'll need to run kinit;aklog first on the machine you want to klogin from to establish your kerberos identity.