Carnegie Mellon
SCS logo
Computer Science Department
home
syllabus
staff
schedule
lecture
projects
homeworks
 
 

15-410 AFS space


Beforehand

If you are getting AFS permission errors before your personal volume has been created, try this:
% aklog cs.cmu.edu
% pts createuser $USER@andrew.cmu.edu -cell cs.cmu.edu
% aklog cs.cmu.edu

Note! This step by itself will not create an AFS volume for you. If a course announcement has not been made indicating that your AFS volume has been created, please do not send an inqury to the course staff, especially if the access_scratch program directs you not to.

Location

Your AFS volume for 15-410 is located at /afs/cs.cmu.edu/academic/class/15410-s24/usr/$USER. Since this volume is in the CS cell, you will need to use cross-cell authentication. Luckily, this is easy. Whenever you log in to an Andrew machine, or use kinit to get new tickets, run aklog cs.cmu.edu. You may wish to arrange that this command is executed each time you log in.

I deleted my files--Help!!

Your backup AFS volume is a snapshot of your live volume, taken some time around midnight. So if it's noon and you just deleted an important file, you might be in luck. If it's Fall of 2006 and your username is xyzzy, then:

  1. The true name of your regular AFS volume is /afs/cs.cmu.edu/academic/class/15410-f06-users/xyzzy
  2. Your backup AFS volume is therefore /afs/.cs.cmu.edu/.BACKUP/academic/class/15410-f06-users/xyzzy

You will need to edit the pathname as appropriate...note that the backup pathname contains two more dots than the pathname of your regular volume. Also note that symbolic links in your backup volume point to live volumes, so the mygroup/ symbolic link in your backup volume will point to your group's live volume (the one you just deleted the file from) and you will need to manually construct the pathname to your group's backup volume.

AFS problems

If you have permission problems with your AFS space, please try the program we have developed to diagnose them:

% /afs/cs.cmu.edu/academic/class/15410-s24/pub/access_scratch

DO NOT SEND US MAIL saying "I am having trouble accessing my AFS space". You must always provide us with a detailed explanation of the problem, such as a transcript of your session showing what you tried. Of course, you should not mail us the transcript; as with anything else, you should place it in a location where we can access it and tell us where that is.

If access_scratch does fix things for you, its output should give you a clue as to what you could do in the future to avoid the trouble.

Please note that AFS, like anything else, may break from time to time. If you receive errors such as Connection timed out or No such device, please wait at least one hour before contacting course staff--these outages frequently resolve themselves (or are resolved by elves). In the other direction, once two hours have gone by, please send us mail.

AFS layout

Inside your volume you will see multiple directories. With a few exceptions, these are your hand-in directories (p0, p1, ... are for projects; hw0, hw1, etc. are for homeworks). We have provided two directories for you to use while you are preparing your assignments:

REPOSITORY
You may place a CVS or PRCS repository here for Project 0 and/or Project 1 if you wish.
scratch
You may organize this directory tree any way you find convenient.
You should probably not prepare your work in your hand-in directories, since that would preclude you having a "safe" turned-in version while making changes to a version under (perish the thought!) last-minute development.

Avoid non-Unix File-Transfer Tools

Any time you move 410-related files around with non-Unix utilities such as WinSCP or SftpDrive you will probably regret it. Here's why.

If you use a non-Unix file-transfer tool to copy a file from one part of your AFS space to another, any time you copy an executable program file it will probably stop being executable. This is because on Windows files are considered executable when the file's name ends in .EXE, but on Unix any file of any name is executable as a function of its permission bits. If you drag a file from a window showing part of your AFS space to another window showing a different part of your AFS space, the file will flow onto your Windows machine, merrily losing its executable bits, and then flow back into your AFS space a pale shadow of its former self.

How should you move files around? The best way is probably to use standard Unix shell-prompt commands (cp, tar, etc.).

Accessing your CS AFS space via scp or sftp

If you try to use scp or an SFTP client to access your 15-410 AFS space, you may get a "Permission denied" message. The problem is that your client program, speaking some small subset of the gigantic SSH protocol suite, is presenting your Andrew password to an Andrew Linux machine, which is turning it into an authentication token for the Andrew AFS cell. But that token isn't enough to get access to your files in the CS AFS cell. Luckily it's easy to inform your SSH process on the Andrew machine to parlay your Andrew-side authentication into CS-side authentication.

scp

If your Andrew account already has a ~/.ssh/rc file, then you should have enough understanding of ssh to merge in our file (see below), so do so.

Otherwise, try this command. If it asks you to overwrite something, then--oops--you do already have an ssh rc file, so answer "no" and do the merge.

cp -pi /afs/cs.cmu.edu/academic/class/15410-s24/pub/dotssh-slash-rc ~/.ssh/rc

If this works, you should need to do it only once.

sftp

If your Andrew username is de0u (which is unlikely), you can try something like:

sftp -s /afs/cs.cmu.edu/academic/class/15410-s24/bin/410-sftp-server de0u@linux.andrew.cmu.edu:/afs/andrew/usr/de0u/

(you will need to invoke sftp this way every time).

Using your CS AFS space as a remote CVS repository

Some students doing development on a non-Andrew machine (which we cannot in general support) have reported permission problems when they try to use ssh to access revision-control repositories contained in their 410 AFS space. The problem is that the ssh server on the Andrew Linux machine you contact gets AFS tokens for the Andrew AFS cell before executing the command you specify, but it doesn't know you will need tokens for the CS AFS cell.

We have received a report that the following will enable CVS over ssh.

export CVS_SERVER='aklog cs.cmu.edu;cvs'

This instructs CVS client programs (on your personal machine) to request the Andrew Linux machine providing access to your repository to run the indicated sequence of commands; the first will acquire CS AFS tokens and the second will run the CVS protocol.


[Last modified Wednesday September 01, 2021]