Computing Resources
Computing Resources
This page is the repository for sundry items of information relevant to
general computing on BooNE. If you have a question or problem that
isn't answered here, or a suggestion for improving this page or
the information on it, please mail boone-computing@fnal.gov
and we'll do our best to address any issues.
Some links on this page point to www.everything2.com, and are meant to give an idea about a concept or thing without necessarily wading through a whole website or technical manual. See the Everything FAQ for more details on this quirky and interesting information source.
BooNE members should have a FNALU account
(Obtaining
the right computer accounts). This will enable them to perform
general interactive computing on Sun Solaris, SGI IRIX and RedHat
Linux systems, and access batch computing facilities
on machines running the aforementioned OSs. In addition, on the 10th
floor of Wilson Hall at FNAL we have ~35 desktop
PCs of various ages and abilities running Fermi RedHat Linux.
They are all managed by an NIS server,
so any BooNE member may log into and (within the bounds of courtesy
and consideration) run applications on any machine. Many of the points
below apply specifically to the environment on BooNE's desktop PCs;
others are more general.
Two Unix utilities which may prove really useful to you are man
and info. Most UNIX applications are accompanied by one or
more man pages, and/or info files. For instance:
man xemacs
produces a (usually short) explanation of what the program is, what it
does and how to use it;
info xemacs
takes you into a world of hyperlinked information. Invoking info
without arguments gives a short introduction to using the program.
man info
is also a good, if slightly incestuous, thing to try, as is info
man or man man. The xemacs
editor also has a nice info interface (Follow the Info
(online docs) choice in the Help menu) and can
also be used for browsing man pages (Alt-x man RET
xemacs RET).
On the computers on WH/10/W, one may use either the KDE or GNOME
graphical desktop environment with X-Windows. Choose the
one you want with the switchdesk utility. Either invoke
at the command line with
switchdesk KDE
or
switchdesk GNOME
or invoke without arguments from an existing X session to get a graphical
chooser. Your choice will be honored the next time you start an
X session. Note this is not applicable to NIC terminals.
Kerberos (project home page or FNAL Strong Authentication
page) is an authentication system. The basic idea is that one can
authenticate oneself once on a local system, thereby obtaining credentials
enabling one to perform many other tasks on remote machines without
typing passwords and sending them over the network.
A Kerberos ticket-granting-ticket for a particular principal
(username) can be obtained one of four ways:
By logging in to a Kerberized machine at the text or graphical console;
If the password you use to log in matches your Kerberos password, you will be authenticated to Kerberos. If appilcable, you will also be given an AFS token (see below).
By using the kinit utility;
The kinit command takes a principal (eg user@FNAL.GOV: realm must be in caps) as an optional argument and expects a password to be typed in at the terminal. YOU SHOULD NOT DO THIS ON A REMOTE MACHINE: your password will go over the network as typed, quite possibly unencrypted. Encrypted or not, this practice is in violation of the FNAL Policy on Computing. The kinit utility on NIC terminals operates slightly differently: see the Using NIC terminals page for details.
With a CryptoCard;
This device looks like a credit-card-calculator, and is a one-time challenge/response system used for logging into Kerberized (aka strengthened) machines from non-strengthened machines. If you need one, see the Getting Computer Accounts page; if you need to know how to use it, read the CryptoCard Instructions. Use the ssh or telnet utility as usual, but hit enter when prompted for your password. DO NOT TRY TO GIVE YOUR KERBEROS PASSWORD: it will not work and you will be in violation of the computing policy (see above). You will then be given a challenge. Follow the instructions and type in the correct response.
With the kcron utility;
This is a utility that enables one to run batch or cron jobs that require AFS or Kerberos privileges. For more details, see section 10.3 of the FNAL Strong Authentication Manual.Once you have your tgt, you may log in to any other Kerberized machine that operates in the same realm (eg FNAL.GOV) without having to provide further authentication.
The klist utility will list all the tickets you have, when they first became valid and when they will expire.
klist -f
Will provide a little more information: see man klist for details.
Your tgt (and your associated AFS token, see below) has a finite lifetime. This varies from machine to machine, up to a realm-defined maximum. When your tgt expires, you may no longer use it to access other machines or execute restricted tasks on the current machine. If your ticket is renewable, you may renew it without entering a password up to the maximum renewable lifetime by using the -R option to kinit. If it is not, or the maximum renewable lifetime has expired, you must give your password to the kinit command in order to renew your ticket. This renewal is only valid on your local machine. If you need to have this new ticket validated to other machines to which you are currently logged on, execute:
k5push [user@]host
Be careful though: if you do this on a group account (eg e898), you may disrupt other users. It may be easier in these cases just to log out an back in again after renewing your ticket on the local host.
AFS
is a distributed file system, with files in the same directory hierarchy
possible residing on many different machines in a way transparent to
the user. A user obtains an AFS token (similar to, but currently different
than a Kerberos ticket), which has a finite
lifetime. Note that obtaining a Kerberos ticket for a particular username
should confer AFS privileges for the same user if the machine has been
configured properly. You can check what AFS tokens you have by typiing:
tokens
There is a FNAL web page describing the AFS
system in more detail. However, some of the more immediately useful
comands and functionality are described below.
Access to files in AFS is managed by Access Control Lists. A use or group of users is assigned privileges, thus:
l = list: get a directory listing
r = read: read file contents
i = insert: make new files
d = delete: delete existing files
w = write: write into or over existing files
k = lock: get file locks
a = admin: change ACLs
Other useful commands are:
/usr/afsws/bin/kpasswd
to change your AFS password (note the full path must be entered in order
to avoid confusion with the identically named program for changing
your kerberos password;
unlog
will delete your current AFS token
aklog
will obtain an AFS token for you based on your kerberos ticket, should
you have one which is vald.
klog [user]
will obtain an AFS token for the specified user, asking for your AFS (not
kerberos) password.
The fs command is extremely versatile, performing a number of functions.
fs help
will briefly explain them. Ones you may find yourself using fairly often
are:
fs listacl [dir]
fs la [dir]
This will allow you to see who is able to do what in the specified
(or current) directory .
Note that someone wishing to access a given directory must have at least l access for all directories above it (see .
fs listquota [dir]
fs lq [dir]
Obtain information about your usage of the AFS volume in which the specified (or current) directory is situated.
fs setacl [[-dir] dir] [[-acl] user access]...
fs sa [[-dir] dir] [[-acl] user access]...
Set the access on a given directory. The access is specified either as a string of the letters lridwka, or using the synonyms read (lr), write (lridwk), all (lridwka) or none.
Note that, although the ACL of a new directory is inherited from its parent, a change to the ACL of a directory will not be propagated to its daughters. Each directory must be changed separately if you wish to change the acecss on a whole hierarchy.
Another possible source of confusion is that, just because you explicitly removed access for bad-user from a particular directrory (fs sa . bad-user none) does not necessarily mean that he cannot now acess that directory. If he is a member of a group with certain access rights, he will continue to have those rights.
Examples
fs sa . group:teamA read friend all good-user write system:anyuser l bad-user none
find . -type d -print -exec fs sa \{\} new-user read \; # recursive access setting
It is noted above, but worth stating again, that UNIX permissions on files
in AFS space are almost completely ignored. The ACL controls per-directory
access for files and directories. A vanilla AFS area has the following
directories:
nt_files
private
public
The Mail, mail and private directories are created
with restricted access: these directories and any created under them are
readable only by yourself and the AFS administrators. Any files created here
are therefore protected from prying eyes. The public and nt_files
directories, however, have the same permissions as your home area:
Access list for /afs/fnal.gov/files/home/room0/jdoe is
Normal rights:
system:administrators rlidwka
system:anyuser rl
jdoe rlidwka
Any new directories created under your home area will also inherit these
permissions ie they are readable by anyone in the world with access to AFS.
This includes (for example), nsmail
or .mozilla or .netscape, where your Netscape or Mozilla
mail and web caches are kept by default. Applications are not, in general,
aware of AFS and what they must do to protect directories.
To see if you may be vulnerable, run the following command:
afsprotect -r
which will print a report of directories under $HOME which may not have the protected status you expect or would like.
afsprotect
without arguments will prompt to change each directory, whereas afsprotect -c will automatically protect your home directory and all directories flagged as having no group ("g") or other ("o") UNIX permissions but still readable by anyone.
Up to:
| Computing Information | BooNE Internal Page Index | BooNE Main Index | Fermilab At Work | Fermilab Main Page |
Chris Green <boone-computing@fnal.gov>, 5/30/02