As you may have noticed, there are a couple of directories in your home directory that have been created to make it easier to protect and share files.
A place to put files that should be readable by anyone in the whole world. This includes .forward, .bashrc, .tcshrc, and similar files.
Files that should only be readable by the owner. This directory is not listable by anyone except the owner.
This is a copy of the entire home directory as it was when the last backup was taken (usually last night). This snapshot does not count against the user quota.
You should NOT delete any of these directories, especially not the Public directory which holds your shell settings. The settings need to be accessible before AFS is fully authenticated.
Make sure to read the section "Protecting files in your home directory"!!
AFS, Andrew File System, is a distributed file system that enables many computers all over the world to share files and data. AFS works mostly like a normal UNIX file system, with some exceptions. The most important of these are described in this introduction
Computers in AFS are grouped in AFS cells. Our cell, that contains all the computers on HPC2N, is named hpc2n.umu.se. Files in AFS are named /afs/cell_name/path and have the same names no matter where in the world you are. E.g. the file /afs/hpc2n.umu.se/home/m/maswan/Public/Hello is available with the same name from any computer in every AFS-cell in the whole world.
AFS uses Kerberos authentification for users. To be able to access your files you have to have a valid Kerberos ticket for AFS. You automatically get a ticket when you log in, but sometimes you may need to get one manually. One such case is when logging in with rsh or rlogin, where you can't bring the ticket with you to the new machine and have to get a new one. The ticket can also expire (normally after 25 hours).
To check if you have a valid ticket:
Command to get a new ticket:
kinit -f username
This does Kerberos authentification and gets an AFS ticket.
While it is rare, it can sometimes happen that you have a valid Kerberod ticket at the same time as an expired AFS token. You can check with:
If the AFS token has indeed expired, but the Kerberos ticket is still valid, you can refresh the AFS token with the command:
File protection in AFS is different from the normal UNIX file system. Every directory in AFS has an access control list (ACL) that determins who are allowed to do what with the files in that directory. There are seven different rights to the files in the directory that have their own letters:
|r||read||Read the files in the directory|
|l||list||See what files there are in the directory|
|i||insert||Create files in the directory|
|d||delete||Remove files in the directory|
|w||write||Modify the files in the directory|
|k||lock||Lock the files in the directory|
|a||administer||Make changes in the ACLs for the directory|
This is an example of a access control list:
lisa rlidwka system:administrators rlidwka system:anyuser l lotta rlidwk lisa:friends rl
The first line says that the owner (lisa in this example) has all rights. The second line gives the same rights to the special group system:administrators (the members of this group can always get any rights so there is no point removing those). The group system:anyuser is all users in the world, have only the right to list what files there are in the directory. The fourth line gives lotta all rights except the right to change the access control list. The last line gives the members in the user-created group lisa:friends the right to both list and read the files in the directory.
One important thing to remember is that when you create a directory the ACLs are inherited from the directory above, i.e. if you are in directory "otto" and do a mkdir "rupert", then "rupert" inherits the ACLs from "otto".
fs listacl directory
Shows the access contro list for the directory. listacl can be abbreviated as la.
fs setacl directory user/group rights
Gives a certain set of rights to a user/group. setacl can be abbreviated as sa.
fs setacl directory user/group none
Removes all rights for a user/group.
Shows all fs commands.
Only the owner section from the normal UNIX file permissions is used. It is used to indicate that certain files should have read, write or execute protection. That protection applies to all users that can access the file and not only the owner. The other two sections of the permissions field (group and other) are not used in AFS.
Every user can define own groups in AFS and give rights to the members in that group with access control lists. In the ACL example above lisa:friends was an example of a user defined group. User defined groups are always prefixed by the owners name followed by a colon.
pts creategroup owner:group
Creates a group. Owner is your user name. creategroup can be abbreviated as cg.
pts delete owner:group
Removes the group. delete can be abbreviated as del.
pts adduser user owner:group
Adds the user to the group. adduser can be abbreviated as ad.
pts removeuser user owner:group
Removes the user from the group. removeuser can be abbreviated as rem.
pts membership owner:group
Shows the members in the group. membership can be abbreviated as m.
Shows all pts commands.
There is a limit, quota, for the ammount of disk space a user can use. This limit is set by the system administrator. There is also a quick way to see how much quota you are using at the moment. HPC2N users normally get 500Mbyte when the account is created. If more space is needed, please send an email to support.
fs listquota directory
Shows the quota for the volume where the directory is located. Also shows how much of the quota that is currently used. listquota can be abbreviated as lq.
Every night we usually make a backup of your files to tape. At that time a snapshot of your home directory is made with the files as they were at that moment. This snapshot is available in the directory OldFiles in your home directory during the next day. That is, if you by mistake remove a file, you can restore that file yourself by copying the version from yesterday from OldFiles.
It is important to realize that the file protection in AFS is based on directories, and therefore it is impossible to have different levels of protection on different files in one directory. For example, you can't have a file that only you can read in a directory that is readable by everyone. Normally this isn't a problem, you just put the files in different directories. Sometimes this isn't possible, as in the case of your home directory.
In the home directory there exists several files that needs to be readable by everyone, like .bashrc, .cshrc, and others. If these aren't publicly readable rsh/rlogin and other things will break. But you also need secret files, like the file .rhosts that should only be readable by the user. This is solved by giving system:anyuser list access to the home directory and then putting files that need to be public in a directory that system:anyuser has the right to read and list files in (the ACL rl). Then symlinks are setup pointing the files from the non-readable (but listable) directory to the publicly readable directory for each file that needs to be readable. That way you are able to access the public files via the symlinks from the secret directory.
The need for system:anyuser to list things in your top-level home directory also means that any file you put there is also seen by anyone in the world. They can't read the file, only list it. This also applies to any directory created in the top-level home directory unless you explicitly remove the ACL entry for system:anyuser, (see "Access control lists" above for instructions).
There are three special directories in your home directory: Public, Private and OldFiles. See the first section for a description of them.
Note that to make this introduction as short as possible there are some simplifications of the real situation.