scp and
ssh-agentat, batch, and
cron jobsOIT has replaced their aged UNIX detective class cluster with new machines for fall class use. The new systems, which are part of the Glue environment, will replace the detective cluster and WAM for class use. The new machines and environment are an improvement in many ways, but there are some differences to get used to in the way things work, summarized in this page.
Please mail me any questions you may have, and when you get access if you find problems or other issues please let me know so I can bring them to OIT's attention. Also I would be happy to have any comments on or suggestions about this document.
The new cluster is named the Grace cluster ("Glue Research and Academic Computing Environment"). There are four machines, two are SPARC running Solaris (these have four 1.6 GHz UltraSPARC IIIi processors and 16G memory), and the other two are AMD64 running Red Hat Enterprise Linux (these have four 2.4 GHz Opteron processors and 16G memory). There is also a fifth machine specifically for Oracle database use. There's a webpage with some information about the systems for instructors and students at http://www.grace.umd.edu/.
Note that insecure access (telnet and ftp)
to these systems is not possible; secure access (ssh,
slogin, scp) must be used instead.
tap
Glue uses a program called tap so users (students) can
get access to certain software without having to permanently modify
their dotfiles. Some software is not on the standard search path but
running tap modifies the user's path and environment to give access to
it for the duration of the current login session. For example,
mathematica isn't on the default search path, but it can be run after
typing tap mathematica. "tap" without any arguments
lists the applications available via this mechanism.
Java 1.5.0 is the default on the two Grace Solaris machines.
Running java on the two Grace Linux machines gives the Red Hat
default GNU Java. Sun Java 1.5.0 is available on the Linux
machines by typing tap java150.
Eclipse 3.1.0 is available by typing tap
eclipse.
Allegro Common Lisp is available on the two Grace Solaris
machines after typing tap allegro70, for
version 7.0. Allegro Common Lisp is only licenced for the two
Solaris hosts, and is not available on the two Grace Linux
machines, so just tell students to log in to
solaris.grace.umd.edu to use it.
.cshrc.mine in your home directory, which gets executed
upon every login (this is assuming the default shell tcsh
is used; use .bashrc.mine for bash).
"Disposable" class accounts for each course, which disappear at the
end of the semester, will not be used with these systems. Students,
faculty, instructors, and TAs can access the systems using their campus
Glue account. Anyone affilitated with the University can get a Glue
account online at http://www.oit.umd.edu/new/.
Those associated with a course will then get login permission on the
Grace machines when the faculty member or instructor requests class
access (see the last section below).
Faculty and instructors will no longer have to deal with student
password problems, login difficulties, etc.; since students will be
using their Glue accounts they would go to the OIT Help Desk for such
things (1400 CSS Building, x51500,
http://www.helpdesk.umd.edu/
). For courses which use these systems students also won't have to
set up their environment (.emacs file, aliases, etc.) every semester for
the separate account for every course as before.
Note that students may be using their Glue account for more than one
course, if they're taking multiple courses using the Grace cluster.
They won't need separate class accounts for each course as with the old
cluster, they'll just get additional separate disk space for each
course.
Glue uses the AFS file system. This will allow faculty, instructors,
and TAs to grant varying levels of access to directories to specific
lists of users, without having to get staff to create groups. (Users
can create and administer their own groups in AFS as needed.) Each
directory has an Access Control List (ACL) which can be manipulated to
control access. Of course, it requires learning the AFS commands if you
want to do these things, if you don't know them already; these are
described at
http://www.helpdesk.umd.edu/documents/1/1222. A few of the things
described in more detail on that page are:
Accounts
AFS and Kerberos
fs
listacl
fs
setacl
The systems use Kerberos for authentication. When a user logs in they
get a Kerberos ticket and an AFS token (used for file permission and
authentication) by the login process. These both expire after a day;
the command klist lists Kerberos tickets and the time they
expire, while command tokens lists AFS tokens and when they
expire.
When you request space for your class the following directory will be created (suppose this is for CMSC 123, Fall 2005, section 0101):
/afs/glue.umd.edu/class/fall05/cmsc/123/0101Under this several directories will be created (this chart is based on http://www.grace.umd.edu/instructors/filesystem.html):
| directory | student permissions | instructor permissions | purpose |
| .db/ | none | none | needed by Glue staff |
| public | read | read/write | place for instructor to post any materials for students to have access to |
| instructor | none | read/write | instructor's personal space |
| backup | read | read | holds a one-day-old copy of all the directories and subdirectories in this directory |
student/<loginID> |
read/write | read | individual students' AFS space for this course |
submit/<loginID> |
insert only | read | OIT's submit script writes files here |
There's a chart on the Grace website at http://www.grace.umd.edu/instructors/timeline.html indicating when after the semester is over student access to these directories will end, and when they're deleted.
As mentioned in the chart above, students are given extra disk space
for every course using the Grace cluster which they're registered for.
Instead of the disk space being in their home directory it's in the AFS
volume for that course. For example, a student whose login ID was
larry, taking CMSC 123, Fall 2005, section 0101 would get a directory
created named
/afs/glue.umd.edu/class/fall05/cmsc/123/0101/student/larry.
To avoid students having problems with quota in their home directories
you may want to tell them how how to create a symlink from their home
directory to this AFS space, and to cd there to do all their coursework
for your course.
Note that after a semester ends students can just use cp
if they want to save their work, by copying it from this location to
their regular Glue home directory tree.
Quota shouldn't be as much of an issue to deal with as on the old
detective cluster, because students will get extra quota for each
course, and any questions about quota would be between a student and
OIT. The AFS class account space which is created for a course has a
common quota rather than a per-user quota. fs lq
<directory name> will list the quota for
the AFS volume if you want to check on the quota being used by your
class space.
As mentioned above the AFS space for a course includes space and
directories already set up for project submission. The old submit
programwhich some faculty used, written by Dr. Purtilo, won't work on
these systems as it won't run under AFS. OIT has a simple submit shell
script installed as /usr/local/scripts/submit. To use it a
student just runs submit, and it prompts for the necessary
information. It leaves the submitted file (for example for CMSC 123,
Fall 2005, section 0101) in
/afs/glue.umd.edu/class/fall05/cmsc/123/0101/submit/<loginID>.
This script lacks some features, for example it doesn't identify late submissions, it doesn't keep a log of submissions made, and the only mechanism to cut off submissions as of a certain time is to change the access permissions for the directory (or to copy the submitted files elsewhere) at the desired time. Of course it's possible to copy and modify this script to add features and have your students run your version instead, or to set up your own directory for submission elsewhere and write your own project submission program entirely if preferred.
This should be pretty obvious to faculty and TAs, but could be
confusing for some students. There are two separate platforms with
access to the same filesystem: students can access their files when
logged in to one of the regular Glue machines (SPARC 64 bit), to the
Solaris Grace hosts (SPARC 64 bit), or to the Linux Grace hosts (AMD 64
bit). An executable for example compiled on one of the Linux hosts
won't run when logged in to the others, and vice versa. Students may
want to always log in to the same type of Grace host, or at least know
about the uname command to be able to tell which type of
Grace host they're logged in to.
Ira Gold will not be working closely with the new Cluster as he did with the old detective Cluster. Rather than emailing issues to him, problems can be reported using the "request" system- from the new machines (or from any Glue machine) run "request" and type in the description of the issue. This directs it to the sysadmins. If you can't log in to a Glue machine the request application is also available on the web at http://www.glue.umd.edu/cgi-script/request, or just send mail about the problem to request@glue.umd.edu. The procedure for requesting class account space is described below.
New Glue accounts are set up to autoforward email to the user's mail.umd.edu account. Instructors, TAs, or students who don't have a mail.umd.edu account, or who don't want their mail forwarded there (who want to read mail sent to their Glue account locally on Glue, or want to forward it to somewhere other than mail.umd.edu), can use OIT's request system (described right above) to ask that mail autoforwarding on their Glue account to mail.umd.edu be turned off.
If after that you want to forward email elsewhere, the .forward file should be put in an atypical location: if your account ID is "user" it would be placed in in /mail/user/.forward rather than in your home directory.
You can point students who are novices to mail forwarding to more detailed procedures on the mail forwarding specific to Glue on the Help Desk page http://www.helpdesk.umd.edu/os/unix/usage/410; this also explains to the student the format of the .forward file.
Printing should work similar to the old detective Cluster. Students need a print account to be able to print, meaning they will have to pay by the page. There is a pay-for-print printer in the A.V. Williams WAM lab, which is room 1120. To print there, use the queue name "avw". Examples of how to print different ways are below. For more information about obtaining a print account, see www.helpdesk.umd.edu/documents/0/184 .
| For printing duplex: |
qpr -x duplex -q avw <filenames>
|
| For printing single-sided: |
qpr -q avw <filenames>
|
| 2-up duplex printing: |
mpage -2ft -Pavw <filenames>
|
| 2-up single-sided printing: |
mpage -2f -Pavw <filenames>
|
The Kerberos tickets and AFS tokens used for authentication will
expire after a day. If you leave an xterm running for longer than that
your session won't have any permissions, but just run renew
and type your password to restore access.
If you have a long-running or background job which will take longer to
run than the duration of your Kerberos tickets and AFS tokens, OIT has
an autorenew command which will extend tickets and tokens
before they expire (man autorenew has a brief explanation).
scp and ssh-agent
Due to Kerberos authentication it's not possible to log in to Glue and
Grace machines without typing the password, even if you're running
ssh-agent on your local machine. You also can't remotely
scp files to or from Glue machines without typing the
password, for the same reason. However, you can run
ssh-agent and ssh-add on a Glue or Grace
machine and scp files in either direction, without typing the password,
by just running scp on the Glue or Grace host. This
requires typing your password once to log in to the Grace host and once
when running ssh-add on it, and then once every 25 hours
when you would need to run the renew command mentioned
above to renew your Kerberos tickets and AFS tokens.
at, batch, and cron jobs
Due to Kerberos authentication issues, users won't be able to run
at/batch/cron/ jobs on these
systems (you can run them, but since they wouldn't get any
authentication tickets they won't be able to access files). If there's
something which really has to be run as one of these types of jobs the
staff can set it up if you use the request system described above.
Request access for your course using the form at https://www.oit.umd.edu/new/classaccounts.
You have to have a Glue account yourself in order for the request to be processed, otherwise you won't be able to access the class space or do anything with it. If you don't have a Glue account already you can request one at http://www.oit.umd.edu/new. You can go ahead and request class access also; as soon as your Glue account is created your class access will be set up.
Typically within a day AFS class space will be automatically created for your course, and you and all enrolled students who have Glue accounts as of that time will be granted login access to the Grace cluster, and access to the AFS space for your course.
Students without Glue accounts will receive an automatic email (at their email address on file with the University) telling them to get a Glue account, and describing how.
Emphasize to your students that anyone who still doesn't have a Glue account should immediately request one at http://www.oit.umd.edu/new.
You'll receive an email confirming the accounts created (this also gives you the connection between the students on your roster, and their Glue accounts), plus listing those students who don't have Glue accounts.
As students add and drop the course (even if they do so before classe begin) they will automatically be added to or dropped from access to the course disk space and Grace access. You'll receive email letting you know about this as it occurs.
For your TAs to have access to the Grace systems and access to the class disk space they'll also need Glue accounts. Have them get Glue accounts and send you their Glue IDs, and use those to run the script addta described at http://www.grace.umd.edu/instructors/account.html in order to add them as TAs to the course.
Since students will be added to the class space on Grace and given access automatically when they add, there's really no reason to request class access too far in advance. A good time might be a few days to a week before classes begin. OIT probably won't set up class access much before then anyway.
The University says that only students registered for a course should be allowed to attend, however, there may be rare times when you want to give access to Grace, and to files created for your course, to a student who's not on the roster. There have been cases when a student has a long-running financial or other special situation which has to be cleared up before their registration will officially go through, but you want to have them participate and do coursework in the meantime. Other times, a faculty member may want one of their graduate students to sit in on and do coursework for part of the course they're teaching without actually enrolling. Although students who are enrolled in the course automatically get Grace access after you request space as described above, in order to manually give Grace access to someone who's not officially on the course roster you can run the addstudent script described at www.grace.umd.edu/instructors/account.html#ADDSTUDENT.
This is mostly an issue between students and OIT, but is described here because students may ask you about it, as it may interfere with a few students their getting class access to the systems.
In the past students could have separate IDs for their WAM account, Glue account, University directory (LDAP), etc., which makes things difficult in terms of directory authentication. OIT would also like to move to a uniform @umd.edu mail address which can reach everyone on campus, which is a problem when users have multiple IDs. The problem which arises with class account access when a student has different IDs is that the system has no way to tell what their Glue account ID is (i.e., in order to know which user to give access to). Therefore if any students on your roster have multiple campus computer IDs (WAM, Glue, LDAP, etc.; this doesn't refer to departmental login IDs) they can't be added to the class space or given login access, and instead of being added to the class they get an email telling them they first have to consolidate their IDs. If they ask you what this means, you can refer them to http://www.oit.umd.edu/middleware/id_merge, or tell them to contact the OIT Help Desk (1400 CSS Building, x51500, http://www.helpdesk.umd.edu ). Once they've taken care of this you will have to run addstudent described above to give them access.