University of Washington
Astronomy Department

Computing Resources for UW Astronomers

Please include your name, the name and location of your computer and a description of your problem in your request. Please use a descriptive subject. The Physics and Astronomy Computer Services Group handles all general astronomy help requests. You can track your help request to PACS online.

Your first stop when you have a computer question. The first three links

Make it a good one – at least eight characters, a mix of upper and lower case, include non-alpha characters. Don't write it down. Remember it. The same password authenticates you for use of the astro Linux desktops, astro mail, and access to the astro filesystems and printers from OSX and MS Windows. Change it by entering passwd from a Linux shell. Change it often – at least once every three months.

To set up your environment to work nicely with the Linux machines as well as the Suns, get the file ENV.tar from the downloads section of the LinuxUpdates site, untar in your home dir, and follow the instructions in ~/ENV/README. Undergrad accounts created since the beginning of 2002 already use these env files. The instructions are also available.

If you don't use the standard environment files, then you're on your own if anything breaks.

Is in . It is the same on all astro Linux desktops.

Use your home directory storage sparingly. Your shell environment files go here. Your ssh keys, too. Maybe a few small text documents. It is not for storing large quantities of data. It is not for high-throughput I/O (don't point your Condor jobs here). Use the directories designated for large, high throughput data storage for everything else.

Don't be surprised if you list the contents of /users and don't see much there; astro home directories are mounted under /users by each host on demand.

Access your home directory from OSX or MS Windows by mapping network drive:

//azazyel.astro.washington.edu/username.

As with /users, don't be surprised if you look under /net and don't see much. These directories are under the control of an automouter which mounts the referenced filesystem on demand.

All of our large filesystems are on RAID-5 volumes (any one disk in an array of many disks can fail without disrupting service or loosing data). Most of them are in an air conditioned computer room (B232) and are connected to backup power supplies. Most servers are connected to two gigabit ethernet circuits.

Q: What gets backed up?

A: All home directories, web, email, and ftp directories, Black Tower data directories (grads-1, incubus, succubus, defile, /net/projects, sdss, scone, pillan,cmr), etc. You can get a complete dump list here. Note that these are absolute paths, local to the fileservers in question. You can translate a familiar path from /net to an absolute-local path with a command like:

$ ypcat -k auto.astro.net | grep grads-1
grads-1 -rw,rsize=8192,wsize=8192 barkayal:/a1/PROJECTS/grads

Q: What doesn't get backed up?

A: Anything stored on the local disks on desktop Linux machines - this includes everything in /local on your computer and everything else on the local disk.

Project-specific fileservers. These include /net/mondo-1 and mondo-2, masmacho, rodin, and metate.

Q: Can I make my own backups of stuff you're not backing up?

A: Yes! You can use the tape and DVD drives on Daphne for this purpose. Free DVD+RW disks are available from the front office. Instructions are available on LinuxUpdates.

Q: How do I request restoration of files from backup?

A: Send mail to help@astro.washington.edu listing the full pathname of the files to recover (e.g. /net/grads-1/joebob/), and the date to which you'd like them restored (e.g. last Wednesday).

Q: When do you do backups? How long are they preserved?

A: One month. We have a lot of data to back up and not a lot of cash to buy tapes. Our dump cycle is one month long with backups Monday through Friday (20 runs total). Files sometimes survive on tape for six weeks or more, but don't count on it.

Q: When do you do full dumps? Incrementals?

A: We use a program called Amanda to manage our backups. Each time it runs, Amanda schedules some directories in the dump list to get full dumps and others to get incrementals. In a given dump cycle, Amanda attempts to preserve two full dumps for every entry in the dump list. Amanda attempts to dump every entry in the dump list every time it runs - either a full or incremental dump.

Q: Do you store a full dump archive off site in case of disaster?

A: No. We do not have the ability to make a full dump of our main fileservers. It would consume at least 30 tapes and take about a week to complete. Our tapes are stored in the computer room, right next to the tape library and fileservers. They should be stored in a different building, or at least a different room. If you want to volunteer to shuttle the tapes between locations, contact PACS.

Also, the dump list changes every week as directories are added and removed from our servers. Our backup system creates a new dump list every weekend and, typically, several dozen changes are made from the previous week's list.

Q: Why are there so many entries in the dump list? Why don't you have just a single entry for each server?

A: Our backup software does not support having a single backup span multiple tapes. Consequently, we have to break our backups into smaller chunks. Currently, the chunk size is 35GB - any directory with more than 35GB of data will be broken into two or more chunks. Another limitation of our backup scheme is its inability to back up files in the branch node directories. For example, /a1/FOO contains two subdirectories /a1/FOO/small with 10GB of data and /a1/FOO/large with 30GB of data. Our backup system would dump small and large separately, but any files in /a1/FOO would be missed. We have a second routine that backs up these files, but the list of files to dump is only updated once a week - so be aware!

Q: Anything else I should know about?

A: Disk list entries containing spaces or strange characters will not be backed up.

If a file changes as it is being read by Amanda, it will not be backed up. This happens occasionally with files being written by Condor jobs or other processes which do substantial file I/O at night when the backups run.

Backups begin at 7:30 p.m., Monday though Friday and tend to take eight to ten hours to complete. This means that any data you create and destroy in a single day is probably not on tape. Email messages received and deleted on the same day are a good example of this sort of problem.

The department mail server is mail.astro.washington.edu. Mail is accessible using most standard email client software that supports the IMAP protocol. Instructions are available for Pine, Mozilla, Eudora, and OSX Mail. Check out the Email HOWTO and LinuxUpdates.

You can also use the web mail interface. BEWARE! Taking more than a few minutes to compose a message can cause the webmail session with the server to timeout and you will loose everything you have entered. Compose long messages with your favorite editor (emacs, vi, pico, etc.) and attach the text to your email message.

You can access your saved mail in the directory /mail/username.

For important information about SPAM or threatening email, please see the UW Computing Security webpage.

Get print queue status HERE

Learn more about the print queuing system HERE.

All general astro users (everyone but the undergrads) are entitled to personal web and ftp directories for the purpose of sharing their work with others. Find your web directory at:

All files uploaded via anonymous ftp will be owned by user "smith" and associated with group "astro" and have perms 664. Please remember to remove files you've uploaded. Ftp access is anonymous only - this prevent the transmission of passwords as clear text.

If you don't have a web or ftp directory and would like one, send mail to webmaster@astro.washington.edu.

Before moving any astronomy department computer equipment, notify PACS (help@astro) with the name and current location of the equipment and the intended new location. PACS will let you know if you can move the gear immediately, or if you must wait until they've made system-level preparations (changing IP addresses, etc.). Once you receive the go-ahead from PACS, you are responsible for transporting the gear to its new location. Contact PACS if there is any question about how to physically connect your computer to the network.

Before moving any gear other than your desktop workstation contact Tom Quinn (trq@astro.washington.edu) for guidance.

Contact PACS at help@astro.washington.edu for hardware support. If your workstation is a Dell PC less than three years old, you can contact Dell directly for hardware repairs. The Dell tech support info is available here. Even if you handle the problem yourself, please keep PACS informed. If your system isn't a newer Dell unit, chances are PACS will have to call the C&C Computer Maintenance Group to handle the repair. Be prepared to provide a UW budget number to pay for the work.

The Condor scheduler lists most machines online at the moment. Run /net/condor/bin/condor_status to see the list. The machines with names from the Seven Dwarves or Scoobie Doo belong to the undergrads.

The undergrad systems use a separate authentication system and separate home directories from the general astro system. Accounts on the undergrad systems are available to faculty and grad students upon request.

Folks requiring lots of CPU power should use the Condor Scheduler instead of firing up interactive jobs on several machines. Docs are available here:

http://www.astro.washington.edu/condor/Condor_expls/CondorIDL.html

http://www.astro.washington.edu/reschke/SystemDocs/Condor/

Graphical reports of the state of the Condor pool are available here:

http://www.astro.washington.edu/condor/Desktop/stats

Undergrads must restrict their Condor jobs to the undergrad computers.

UW Astronomy Home Page