/uns is a collection of installed software which is maintained and supported by UW CSE grad students, not by the department's system administrators. This document answers questions about /uns.
Author's foreword: As /uns coordinator, I wanted to collect a list of frequently-asked questions about /uns. However, hardly anyone has asked me any questions about /uns. Hence, this document is really a list of frequently-unasked questions - an "unFAQ," if you prefer.
Please send comments, additions, and corrections regarding the unFAQ to the /uns coordinator, unsadmin@cs.washington.edu.
Contents:
Here's how to start using /uns in three easy steps:
Examples implementing the above recommendations are available for Bourne Shell or C Shell. Note that, depending on the relative ordering of directories in your path, you can have /uns/bin shadow the supported binary directories or vice versa.
On Solaris, where /uns provides basic GNU tools such as
ls, cp, and so forth, you must add
/uns/gnu/bin to your path to take advantage of these tools.
If you use a department-supported version of Emacs but would like to take advantage of /uns's site-lisp directory, add the line
(load "/uns/share/emacs/site-lisp/config-and-add-path.el")to the top of your .emacs file to update your Emacs load path.
Additional incantations may be occasionally required for X programs that cannot find their X app-defaults, and for other strange situations. If in doubt about a particular package, contact its /uns maintainer.
Greg Badros has provided a detailed example with suggested /uns-friendly environment and elisp settings.
No. You only need to join the group if you want to install or maintain software in /uns.
The maintainer of a particular /uns package owns the files in that
package. To find her user name, locate one such file (generally in
/uns/bin or /uns/share/bin) and use 'ls -l' to see its
owner. To map a user name to an actual person, use the command
'finger -m userid@cs'. Note that our
department often maintains user accounts for some time after a user
leaves, so the package maintainer may no longer be here. If in doubt,
ask an older grad student about the maintainer's status.
If you find that a package is owned by the user unsadmin,
that doesn't mean that the /uns coordinator maintains the package!
Packages whose maintainers have left have their files transferred to
unsadmin after the maintainer's account is deleted.
If you care about a package which has been orphaned because the maintainer has left or has lost interest in it, consider joining the /uns package maintainers' group and taking over maintenance of the package yourself. Remember, /uns only works if we all do our part to keep it working!
Questions regarding specific packages in /uns should be directed to the package's maintainer.
Great! You'll need to join the /uns maintainers' group; send a join request to uns-request@cs.washington.edu.
New maintainers should also read the maintainers' unFAQ to learn about the installation guidelines for /uns software.
/uns is a collection of installed software which is maintained and supported by UW CSE grad students, not by the department's system administrators.
The /uns software repository is shared by most departmental UNIX machines through NFS. It provides a more convenient, more persistent alternative to installing shared packages in individual users' home directories. Anyone can use the software in /uns, and many grad students with UNIX desktops do so on a regular basis. Moreover, anyone who asks may join the group of /uns maintainers, who can install and maintain software in the /uns repository.
/uns has way too many packages to list here; check your local /uns partition to see what's installed.
/uns is run cooperatively by its users, in particular the 40+ members of the package maintainers' group. The /uns service remains usable primarily through the ongoing efforts of individual package maintainers.
The /uns coordinator (unsadmin@cs.washington.edu) is responsible for curating the collection of installed packages, adding people to the package maintainers' group, proselytizing new /uns users, and harassing the Lab about issues like disk space for the /uns partitions. The coordinator is nominated and elected to a one-year term by CSE graduate students at the annual elections held during spring quarter.
Aside from keeping an eye out for old or bogus software installations, the /uns coordinator generally stays out of the way of the package maintainers.
/uns-related news is posted to the CSE newsgroup uw-cs.apps.announce.uns, which is gated (in both directions) to the cs-apps-announce-uns@cs mailing list. Ideally, package maintainers are supposed to post/email to this group whenever they install, change, or upgrade software in /uns, but this rule seems to be honored mostly in the breach. Sometimes the maintainers send mail to uns@cs instead, though that list is officially only for maintainers.
Questions and complaints about /uns itself should be sent to the /uns coordinator or, if they are of general interest, posted to the newsgroup. Questions and complaints about a particular package in /uns should be sent to the package's maintainer.
When you're elected /uns coordinator, you can call it whatever you want.
Separate /uns partitions are maintained with binaries compiled for Linux x86 (2.2/glibc 2.1), FreeBSD (3.4), and Solaris (2.2.5/8.0). In addition, there is a single shared repository, mounted as /uns/share, which holds platform-independent files like scripts and Emacs Lisp code as well as transient /uns program state such as lock files.
If you're using a department-supported UNIX desktop on one of the above architectures, you should have an /uns partition mounted on your machine. For user-supported project machines, the machine's administrator chooses whether to mount the appropriate /uns partitions.
If you have a department-supported machine that doesn't run one of the above flavors of UNIX and doesn't have /uns, ask the /uns coordinator about creating an /uns partition for it.
There is a Windows /uns repository which can be mounted as a share. It provides numerous useful tools, mostly command-line oriented, as well as application archives that can be installed on Windows users' local machines.
To access the contents of the Windows repository, go to the share \\rfilesrv1\UNS. To add the /uns tools to your environment, copy (ctrl-drag) the shortcut "Start UNS environment" to your desktop and double-click to get a shell with the /uns environment.
For more information, see the file \\rfilesrv1\UNS\README or email the Windows /uns coordinator.
There is a separate /uns partition for the IWS x86 Linux servers (ceylon, fiji, sumatra, and tahiti). This partition is maintained by the IWS /uns coordinator.
The Lab is responsible for most of the policy on untrusted hosts (machines on which the owner, rather than the Lab, has root), including what mounts are allowed. Here's what you need to do to keep the /uns coordinator happy if you want to mount /uns:
uns, to be
consistent with the group numbering on supported machines. Your
mount points for /uns and /uns/share should be owned by this group
and (if possible) mounted with the grpid flag, so that any
files you write will be automatically chgrp'd to the /uns group.
nosuid,nodev to avoid mounting a huge security hole
along with your /uns partition.
Complaints about broken or incomplete packages in /uns should be directed
to the package's maintainer. If the maintainer
is gone, or the package is owned by unsadmin (which amounts
to the same thing), send mail to the list of all package maintainers at
uns@cs.washington.edu.
If you find that a package broke because part or all of it was removed from /uns, bug the /uns coordinator.
Package maintainers are encouraged but not required to build binaries for all /uns architectures. Sometimes, it doesn't make sense to install a package on all platforms; other times, a package may not build and/or may not be available in binary form for all platforms.
If you know how to get a package working on an architecture where it is not currently installed, your best bet is to join the maintainers' group and do the installation yourself.
Bug the package maintainer if possible; otherwise, talk to the /uns coordinator.
Note that older or duplicate packages in /uns may have been built with extra features not present in the "official" Lab-supported versions.
The enthusiasm for maintaining /uns on each platform is proportional to the number of package maintainers using that platform.
That said, if you find that something is broken on any /uns platform, you should still alert the package maintainer and/or the /uns coordinator. And of course, you can always perform necessary maintenance yourself.