head	1.4;
access;
symbols;
locks; strict;
comment	@# @;


1.4
date	99.08.20.21.00.55;	author jfoster;	state Exp;
branches;
next	1.3;

1.3
date	99.06.28.13.31.06;	author ajfox;	state Exp;
branches;
next	1.2;

1.2
date	99.03.02.14.41.49;	author jfoster;	state Exp;
branches;
next	1.1;

1.1
date	99.03.02.14.30.29;	author jfoster;	state Exp;
branches;
next	;


desc
@First checkin of the Guide
@


1.4
log
@replaced with redirect up to acs
@
text
@i<html>
<head>
<meta http-equiv=refresh content="10; URL=../LockerGuide.html">
<meta name="robots" value="noLockerGuide">
<meta name="acsfix" value="www-redirect">
<title>The MIT Academic Computing web site has moved!</title>
</head>
<body bgcolor="#ffffff">
<DIV align="center">
<H3>The Academic Computing web site has moved!</H3>
<P>
The new URL for this page is:<BR>
<a href="http://web.mit.edu/acs/LockerGuide.html">http://web.mit.edu/acs/LockerGuide.html</a>
</P>
<P>Please change your bookmarks or contact maintainers of linking pages.
</P>
<P>
If you are not redirected automatically within 10 seconds, please click on the link above.
</DIV>
</body>
</html>

@


1.3
log
@updated to relfect Athena 8.3 system types
@
text
@d1 10
a10 1080
<TITLE>Course Locker Maintenance Guide</TITLE>

<H1>Course Locker Maintenance Guide</H1>
<HR>
<H2>Table of Contents</H2>

<UL>
<UL>
<A HREF="LockerGuide.html#HDR1.0">1.0  Introduction</A>
<BR>
<A HREF="LockerGuide.html#HDR1.1">1.1  Topics Covered</A>
<BR>
<A HREF="LockerGuide.html#HDR1.2">1.2  How to use this document</A>
<BR>
<A HREF="LockerGuide.html#REF13865">1.3  Terms and Definitions</A>
<BR>
<A HREF="LockerGuide.html#HDR1.4">1.4  Conventions</A>
<BR>
<A HREF="LockerGuide.html#HDR1.5">1.5  Other sources of Information</A>
<BR>
<A HREF="LockerGuide.html#REF27312">2.0  General Information</A>
<BR>
<A HREF="LockerGuide.html#HDR2.1">2.1  What are lockers used for?</A>
<BR>
<A HREF="LockerGuide.html#HDR2.2">2.2  What are some limitations to lockers?</A>
<BR>
<A HREF="LockerGuide.html#HDR2.3">2.3  What are the different types of lockers?</A>
<BR>
<A HREF="LockerGuide.html#REF15197">3.0  Maintaining a Course Locker</A>
<BR>
<A HREF="LockerGuide.html#HDR3.1">3.1  Quota</A>

<UL>
<A HREF="LockerGuide.html#HDR3.1.1">3.1.1  How to determine your quota usage</A>
<BR>
<A HREF="LockerGuide.html#HDR3.1.2">3.1.2  Finding where the quota is being used</A>
<BR>
<A HREF="LockerGuide.html#HDR3.1.3">3.1.3  How to clean out old files and directories</A>
<BR>
<A HREF="LockerGuide.html#HDR3.1.4">3.1.4  What is this OldFiles directory?</A>
<BR>
<A HREF="LockerGuide.html#HDR3.1.5">3.1.5  Getting More Quota</A>
</UL>

<A HREF="LockerGuide.html#HDR3.2">3.2  Access Control</A>

<UL>
<A HREF="LockerGuide.html#HDR3.2.1">3.2.1  Introduction to AFS file Permissions</A>
<BR>
<A HREF="LockerGuide.html#HDR3.2.2">3.2.2  The default access control list</A>
<BR>
<A HREF="LockerGuide.html#HDR3.2.3">3.2.3  Listing the acl on directories</A>
<BR>
<A HREF="LockerGuide.html#HDR3.2.4">3.2.4  Changing acls</A>
</UL>

<A HREF="LockerGuide.html#REF34956">3.3  Managing Executables</A>

<UL>
<A HREF="LockerGuide.html#HDR3.3.1">3.3.1  Introduction to binary directories</A>
<BR>
<A HREF="LockerGuide.html#HDR3.3.2">3.3.2  Configuring Executables</A>
<BR>
<A HREF="LockerGuide.html#HDR3.3.3">3.3.3  Source Code</A>
<BR>
<A HREF="LockerGuide.html#HDR3.3.4">3.3.4  Removing Binaries for Obsolete Platforms</A>
<BR>
<A HREF="LockerGuide.html#HDR3.3.5">3.3.5  Dealing with Operating Systems Upgrades</A>
</UL>

<A HREF="LockerGuide.html#HDR3.4">3.4  Other types of Files and Directories</A>
<BR>
<A HREF="LockerGuide.html#REF39471">4.0  Technical Information</A>
<BR>
<A HREF="LockerGuide.html#HDR4.1">4.1  AFS</A>

<UL>
<A HREF="LockerGuide.html#HDR4.1.1">4.1.1  About AFS</A>
<BR>
<A HREF="LockerGuide.html#HDR4.1.2">4.1.2  Groups and AFS </A>
<BR>
<A HREF="LockerGuide.html#HDR4.1.3">4.1.3  The @@sys link</A>
</UL>

<A HREF="LockerGuide.html#REF14356">4.2  The New Binary Directory Convention</A>

<UL>
<A HREF="LockerGuide.html#HDR4.2.1">4.2.1  Why we decided to change conventions</A>
<BR>
<A HREF="LockerGuide.html#HDR4.2.2">4.2.2  $ATHENA_SYS and $ATHENA_SYS_COMPAT</A>
<BR>
<A HREF="LockerGuide.html#HDR4.2.3">4.2.3  athdir</A>
<BR>
<A HREF="LockerGuide.html#HDR4.2.4">4.2.4  Using a shared directory for scripts</A>
</UL>

<A HREF="LockerGuide.html#HDR5.0">5.0  Course Locker Re-use Policy</A>
<BR>
<A HREF="LockerGuide.html#REF32604">6.0  Answers to Frequently Asked Questions</A>
</UL>
</UL>



<HR><!-- This file was created with the fm2html filter.The filter is
copyright Norwegian Telecom Research andwas programmed by Jon Stephenson
von Tetzchner.  --><H3><A NAME="HDR1.0">1.0 Introduction</A></H3>

Lockers are used for many different things in the Athena Computing
Environment and many different people are responsible for maintaining,
upgrading, and supporting the contents of these lockers. This document
addresses some of the more common issues and questions surrounding the
maintenance of a particular type of locker used by academic
courses. Called course lockers, these lockers are used for storing files
used by courses including but not limited to handouts, data files, web
pages, and applications for students to run.<p>

<H3><A NAME="HDR1.1">1.1 Topics Covered</A></H3>

Since this document is intended for course locker maintainers, it
focuses on issues pertaining to course lockers. Some topics may apply to
lockers in general, but this document does not attempt to set the
standard for all types of lockers. <p>

<A HREF="LockerGuide.html#REF27312">Section 2.0 </A> provides some
basic background information about lockers in general and describes
appropriate and inappropriate uses of course lockers. This section is
useful for people who have never dealt with a locker before. <A
HREF="LockerGuide.html#REF15197">Section 3.0 </A> addresses the issues
of quota, access control, and locker configuration. <A
HREF="LockerGuide.html#REF39471">Section 4.0 </A> details some of the
technical issues behind the way course lockers are created, allocated,
and managed, and may be useful to more advanced locker
maintainers. Finally, <A HREF="LockerGuide.html#REF32604">Section 6.0
</A> addresses commonly asked questions in an easy-to-read and
understand format.<p>

<H3><A NAME="HDR1.2">1.2 How to use this document</A></H3>

If you are new to Athena and course lockers, you should probably read
through the introductory sections <A
HREF="LockerGuide.html#REF27312">Section 2.0 </A>and <A
HREF="LockerGuide.html#REF15197">Section 3.0 </A>for background
information about lockers. If you are simply looking for more details
about configuring a course locker or want to know why things are done a
certain way, read <A HREF="LockerGuide.html#REF39471">Section 4.0
</A>. Finally, if you simply want a quick answer to a specific question,
look for in the frequently asked questions list in <A
HREF="LockerGuide.html#REF32604">Section 6.0 </A>. If you do not see
the answer to your question here, please send email to <I>f_l@@mit.edu
and we will be glad to both answer it and update our FAQ list.</I><p>

<H3><A NAME="REF13865">1.3 Terms and Definitions</A></H3>

This document makes use of the following terms and commands.<p> <DL>

<DT> file server</DT>
<DD> In a distributed environment such as Athena, file
servers are machines which store files. The remote file system used by
most of the Athena environment, AFS, makes the files accessible to you
without you knowing which machine stores them.
</DD>

<DT> locker</DT>
<DD>
In the Athena environment, a locker is the name given to a
unit of disk space which is stored on a file server and is accessible
via the attach command.
<DD>

<DT> AFS </DT>
<DD>AFS is the specific remote file system software run on most
Athena file servers. AFS comes from The Transarc Corporation.
<DD>

<DT> quota</DT>
<DD>
Quota is a a term used to mean the amount of disk space
allocated. Under AFS, quota is allocated on a per-volume basis, meaning
that all the files and directories in a volume share the same quota
allocation. Most Athena lockers consist of a single volume and therefore
all files in a locker usually share the same quota allocation.
<DD>

<DT> file system</DT>
<DD>The term file system refers to the hierarchy of files
and directories starting from the root. Standard UNIX machines have a
local file system with the root at /. The root of the AFS hierarchy is
at /afs. Most athena lockers attach under /mit.
<DD>

<DT> volume </DT>
<DD>
Under AFS, disk space is broken up into cells and within
cells, volumes. MIT supports several cells, the two most familiar being
the Athena cell and the sipb cell. Within a cell, space is allocated and
managed in terms of something called volumes. The most important thing
for the average Athena user to know about a volume is that quota is
allocated on a per-volume basis.
</DD>

<DT> add </DT>
<DD>
add is a command local to the Athena environment which attaches
a locker and modifies the user's command and manual page search
paths. add makes it easy for Athena users to access software stored in
lockers. For more information see the add man page.
</DD>

<DT> attach </DT>
<DD>
attach is an Athena command used to access to locker. attach
figures out where the locker is stored in the remote file system and
makes a logical connection under /mit to the remote location.
</DD>

<DT> fs sa </DT>
<DD>
The AFS command fs sa is used to set the access control list
on a directory or directories. For more information type fs sa -help
</DD>

<DT> fs la </DT>
<DD>
The AFS command fs la allows you to list the access control
list on a directory or directories.
</DD>

<DT> find </DT>
<DD>
find is a standard UNIX command which searches for files or
directories according to specified criteria. It is useful for setting or
listing acls on an directory tree.
</DD>

<DT> rm </DT>
<DD>
rm is a standard UNIX command used to remove files permanently.
</DD>

<DT> delete </DT>
<DD>
delete is an Athena command which removes files
non-destructively. rm is forever; delete is not.
</DD>

<DT> undelete </DT>
<DD>
undelete is an Athena command which undoes a delete.
</DD>

<DT> purge </DT>
<DD>
purge is an Athena command which permanently removes files
marked for deletion by the delete command.
</DD>

<DT> mkdir </DT>
<DD>
mkdir is a UNIX command which creates a new directory.
</DD>

<DT> du </DT>
<DD>
du is a UNIX utility which summarizes the disk space used by a
directory hierarchy or hierarchies.  
</DD>
</DL>

<H3><A NAME="HDR1.4">1.4 Conventions</A></H3>

<UL> <LI><code>This is text that the user enters.</code><BR>

<LI><B>This is the name of a command which can be run at the shell
prompt.</B><BR> </UL>


The athena shell prompt athena% should not be typed.<p>

In an example which describes the syntax of a command, angle brackets
(&lt;&gt;) denote a required parameter and square brackets ([]) denote
optional parameters. In neither case should you actually type the
brackets.<p>

Many of the commands shown in this document expect to have a directory
name or names as parameters. In each case, directories may be named with
an absolute pathname, that is, starting with / at the top of the
hierarchy, or they may be relative to the current directory.<p>

<H3><A NAME="HDR1.5">1.5 Other sources of Information</A></H3>

This document does not cover every situation and issue surrounding
course lockers. If you have any questions particular to your locker,
feel free to contact the Faculty Liaison Office (f_l@@mit.edu, x3-0115,
N42-040), or the OLC consultants. To reach the consultant's office, type
<code>olc</code> at the athena% prompt or call x3-4435. <p>

The public mailing list locker-maintainers@@mit.edu is for announcements
and discussion relevant to people maintaining software in Athena
lockers.  You may add yourself to this list using blanche or listmaint,
or add the discuss archive to your .meetings file by typing

<pre>   am menelaus:/var/spool/discuss/locker-maintainers</pre>

in discuss.  (The archive may also be viewed from the SIPB WWW discuss
gateway: <a
href="http://www.mit.edu:8008/menelaus/locker-maintainers/">http://www.mit.edu:8008/menelaus/locker-maintainers/</a>).

<H3><A NAME="REF27312">2.0 General Information</A></H3>

<H3><A NAME="HDR2.1">2.1 What are lockers used for?</A></H3>

Course lockers are useful for storing all kinds of data related to an
academic course. Course lockers may contain web pages, handouts and
problem sets or problem set solutions for students to view on-line, or
they hold programs for students to run. Some people store data files in
lockers; others develop software specifically for a course and put it in
the locker for students to run. Lockers will store just about anything
subject to resource and security limitations; it's up to each locker
maintainer to decide what is appropriate. <p>

<H3><A NAME="HDR2.2">2.2 What are some limitations to
lockers?</A></H3>

Lockers are not totally secure and should not be used for storing
sensitive data such as grades or problem set solutions for upcoming
problem sets. We also have limited resources and creating lockers bigger
than 75-100 meg is problematic, and for technical reason we need to
impose a limit of about 100 meg for a single volume locker. Because of
this, lockers are not ideal for storing space-intensive data such as
sound and movies. In addition, course lockers are specifically for
course-related activities. They are not to be used for storing personal
or research-related files. Finally, course lockers are not intended to
used for student work space.  If you feel your students need more disk
space for course work than is available in the home directory space,
please contact the Faculty Liaison Office to discuss an extra allocation
for the duration of the course.<p>

<H3><A NAME="HDR2.3">2.3 What are the different types of
lockers?</A></H3>

In addition to course lockers, there are many other types of lockers on
Athena. A locker's type identifies it to the operations staff and also
determines where it lives in the file system hierarchy. The following
table describes other common locker types.<p>

<pre>
TABLE 1.  
---------------------------------------------------------------
<B>Type</B>      <B>Description</B>                 <B>Location in AFS hierarchy</B>  
---------------------------------------------------------------
system    system files                /afs/athena/system         
software  commercial software         /afs/athena/software       
user      home directories            /afs/athena/user           
project   Athena-related projects     /afs/athena/project        
dept      Departmental leased disk    /afs/athena/dept           
          space                                                  
org       Organizations within MIT.   /afs/athena/org            
          org lockers are typically                              
          used for web pages                                     
course    course locker allocations   /afs/athena/course         
urop      urop projects               /afs/athena/course/urop    
activity  Recognized MIT activities   /afs/athena/activity       
                                                                 
---------------------------------------------------------------
</pre>

<H3><A NAME="REF15197">3.0  Maintaining a Course Locker</A></H3>

<H3><A NAME="HDR3.1">3.1  Quota</A></H3>

Each volume in a course locker has been assigned a quota - a limit to
its size on disk. The following sections tell you how to view the quota
usage and how to clean out old files that are wasting space. <p>

<H4><A NAME="HDR3.1.1">3.1.1 How to determine your quota
usage</A></H4>

The AFS command fs lq (<B>F</B>ile <B>S</B>erver <B>L</B>ist <B>Q</B>uota) command displays the
quota allocated to and used by any locker. Since AFS quota is allocated
in terms of volumes and not lockers, fs lq is not guaranteed to list the
entire quota allocated a locker.  However, most course lockers consist
of a single volume, making the numbers returned by fs lq
accurate. </B><p>

The syntax of the fs lq command is<p>

<PRE>fs lq &lt;list of directories&gt; </PRE>

where &lt;list of directories&gt; is a space separated list of one or
more directory names. <A HREF="LockerGuide.html#REF33098">Example 1</A>
shows how to use fs lq to list the quota on the locker 25.678, if it
really existed, that is.<p>

<PRE><A NAME="REF33098">Example 1  Listing the quota on the 25.678 locker</A>
athena% attach 25.678
attach: /afs/athena.mit.edu/course/25/25.678 linked to /mit/25.678 
for file system 25.678
athena% fs lq /mit/25.678
Volume Name            Quota    Used     % Used   Partition
course.25.678          15000    13016      87%         82%
</PRE>

fs lq reports quota allocated and used in terms of kilobytes. This
example locker is using slightly more than 13 MB of a 15 MB
quota. (15000 KB = 15 MB). There will also be a warning indicator if the
percentage used is greater than 90%, The field labeled Partition refers
to the file server where this locker lives and is important only to
Athena operations.<p>

<H4><A NAME="HDR3.1.2">3.1.2  Finding where the quota is being used</A></H4>

Once you have determined how much quota your locker has used, you may
also want to figure out which files or directories are using the
quota. The du command returns the amount of disk space used by files or
directories. <A HREF="LockerGuide.html#REF18101">Example 2</A> shows
how to use du to compute how much space two directories are using.<p>

<PRE><A NAME="REF18101">Example 2  Using du to compute disk usage</A>
athena% cd /mit/25.678
athena% du -sk Fall94 Fall95
2345Fall94
8945Fall95
</PRE>

This indicates that the directory Fall94 is using 2.3 MB; Fall95 is using 8.9 MB. <p>

<H4><A NAME="HDR3.1.3">3.1.3  How to clean out old files and directories</A></H4>

Most lockers tend to grow continuously, but you can help this process by
cleaning out old and useless files periodically. While only you can know
if a particular file is old or not, there are several kinds of files
which can be created by programs as temporary or backup files and which
can be safely removed. <p>

<pre>
TABLE 2.  
--------------------------------------------------------------------------
<B>File Name</B>             <B>What Is It?</B>                                           
--------------------------------------------------------------------------
file~                 A file ending with a tilde (~) is an Emacs backup     
                      file.                                                 
file.o                Files ending with.o are object file from compiling.   
                      These files are used to build the actual executable.  
#*                    Files marked for deletion by delete program           
core                  Core files are information dumped by programs that    
                      die ungracefully. They tend to be very large.         
file.dvi, file.aux,   Files ending with.dvi,.aux, and.log are temporary     
file.log              files created by latex.                               
                                                                            
--------------------------------------------------------------------------
</pre>

<H4><A NAME="HDR3.1.4">3.1.4  What is this OldFiles directory?</A></H4>

As you start looking around a locker for files to clean up, you will
probably stumble across a directory named OldFiles. While it looks like
this directory contains duplicate information that may be eating up your
quota, it in fact does not affect the locker's quota at all. You can
think of OldFiles as a sort of on-line backup, containing the contents
of your locker as it existed yesterday. <p>

The OldFiles directory is extremely useful if you accidently delete a
file from the course locker. You can copy the file from the OldFiles
backup into the main locker as shown in <A
HREF="LockerGuide.html#REF37454">Example 3</A>.<p>

<PRE><A NAME="REF37454">Example 3  Copying a file from OldFiles</A>
athena% cd /mit/25.678
athena% /bin/rm myfile
<I>oops!</I>
athena% cp OldFiles/myfile./myfile
</PRE>

<H4><A NAME="HDR3.1.5">3.1.5  Getting More Quota</A></H4>

So, you have deleted everything you can think of and you're still
approaching 100% of your quota. In this case, send email to the Faculty
Liaisons (<I>f_l@@mit.edu</I>) and explain how much you think you need for
what locker and why you need it. We'll get back to you as soon as
possible.<p>

<H3><A NAME="HDR3.2">3.2  Access Control</A></H3>

The term access control refers to the mechanism which controls which
individuals or groups can access files and directories. In short, access
control lists, or acls for short, determine who can read files, who can
write files, and who cannot access files in a locker.<p>

<H4><A NAME="HDR3.2.1">3.2.1  Introduction to AFS file Permissions</A></H4>

Under AFS, file and directory access is managed by access control
lists. Unlike NFS, where individual files can have access control
permissions, the current version of AFS maintains acls on a
per-directory basis. These acls may be set for many individuals or
groups, and the acl on different directories may be completely
different. If the acl on a directory allows a person or persons read
access, then he, she, or they have read access to all the files in that
directory.<A HREF="LockerGuide.html#FN1">(1)</A><p>

Table 3 lists the seven types of permissions that can be given to users
or groups of users.<p>

<pre>
TABLE 3.  
----------------------------------------------------------------
<B>Right</B>  <B>Enables users to </B>                                          
----------------------------------------------------------------
r      read the contents of files in the directory                
l      list the names of files in the directory                   
i      insert files into the directory                            
d      delete files from the directory                            
w      write or modify files in the directory                     
k      lock (or modify the write-mode bit) of files in the direc  
       tory                                                       
a      administer or change the acl of the directory              
                                                                  
----------------------------------------------------------------
</pre>

     <p>

No rights imply any others; for example, a user with &quot;write&quot;
permission is not automatically given &quot;insert&quot; permission as
well.<p>

While this sounds complicated, there are four standard combinations of
access which are applied to course lockers. Table 4 lists these standard
combinations.<p>

<pre>
TABLE 4.  
---------------------------------------------------------------
<B>Combination</B>  <B>Shorthand </B>  <B>Meaning</B>                                 
---------------------------------------------------------------
rl           read        Read-only access. Users with rl         
                         access can read files and traverse      
                         directories, but cannot modify any      
                         thing.                                  
rlidwk       write       Write access. Users with rldwk access   
                         can create new files and delete and     
                         modify files, but cannot modify the     
                         access control list.                    
rlidwka      all         All access. Users with rlidwka access   
                         can do everything above plus changes    
                         the acls.                               
             none        No access.                              
                                                                 
---------------------------------------------------------------
</pre>

<H4><A NAME="HDR3.2.2">3.2.2  The default access control list</A></H4>

By default, course lockers are created with an acl that allows faculty,
TAs, and the faculty liaisons all access, and everyone else on Athena
read access. By convention, when the faculty liaisons create a new
course locker, we also create a group with the same name as the
locker. We put the Athena user ids of any current TAs, faculty members,
and other people who will be administering the locker into this group.
This group then gets all access to the locker. Therefore, adding or
deleting TAs to the access control list is as simple as modifying the
membership of a group. For more details about access control lists and
groups, see <A HREF="LockerGuide.html#REF32604">Section6.0 Answers to
Frequently Asked Questions</A>.<p>

<H4><A NAME="HDR3.2.3">3.2.3  Listing the acl on directories</A></H4>

The AFS command fs la (<B>F</B>ile <B>S</B>erver <B>L</B>ist <B>A</B>ccess) allows you to view
the acl on any directory. Type this command to view the acl set on a
directory or directories:<p>

<PRE>athena% fs la [<I>directory1 directory2 ...]</I>
</PRE>

where [directory1 directory2 ... ] is a space separated list of zero or
more directory names to be examined. (To see the current directory, the
directory list can be left out, making the command simply fs la.)<p>

<PRE>Example 4  Listing the ACL on a Course Locker 
athena% fs la /mit/25.678
Access list for /mit/25.678 is
Normal rights:
system:authuser rl
system:25.678 all
system:facdev all
system:expunge ld
joeuser all
</PRE>

The list contains pairs of users or groups, and their respective
permissions on that directory. In this example, because joeuser is the
owner of the locker, he has all access, as do members of the groups
25.678 and facdev. (The latter is a group consisting of all the faculty
liaisons.) system:authuser corresponds to anyone on Athena, meaning that
anybody with an Athena account can read and lookup files.<p>

<H4><A NAME="HDR3.2.4">3.2.4  Changing acls</A></H4>

The AFS command fs sa (<B>F</B>ile <B>S</B>erver <B>S</B>et
<B>A</B>ccess) allows you to change an acl on a directory if you already
have all access. The syntax of the fs sa command is as follows:<p>

<PRE>fs sa directory user-or-group acl
</PRE>

where user-or-group is either an Athena user id or the name of a group
proceeded by the string system:, e.g. system:facdev or
system:25.678. <p>

To set the acl on more than one directory, or to add more than one
user-or-group and acl pair, use the following command: <p>

<PRE>fs sa -dir dir1  -acl user-or-group1 acl1
Example 5  Setting the acl on more than one directory
athena% cd /mit/25.678
athena% fs sa -dir ProblemSets Handouts -acl system:anyuser read
Example 6  Adding multiple acls to a directory
athena% fs sa -dir WWW -acl joeuser write janeuser all
</PRE>

You may specify more directories and/or more user-or-group and acl
pairs. To set the acl on a directory hierarchy, you can use the find and
fs sa commands as in the following example.<p>

<PRE>Example 7  Using find to set the acl
athena% cd /mit/25.678/www
athena% find . -type d -exec fs sa {} -acl system:anyuser read \;
</PRE>

The syntax of find may be a little confusing, but you can get more help
from the find man page or from the olc consultants.<p>

The two most common reasons to change an acl in a course locker are to
make web pages accessible, and to limit access to the locker and/or
directory contents to a group of students in the course. In order for
web browsers to be able to access web pages, the directory containing
them must be readable by anyone as identified by the group
system:anyuser. Also, this group needs to be able to pass through to the
directory containing the web files.  To put it simply, the group needs
lookup access (The AFS l bit) on every directory above the directory
containing web pages.  <p>

<PRE><A NAME="REF21151">Example 8  Setting the ACL for a Web Pages Directory   </A>
athena% fs sa /mit/25.678 system:anyuser l
athena% fs sa /mit/25.678/www system:anyuser read
</PRE>

To limit access to a directory solely to students taking the course, you
need to remove the group system:authuser from the acl and add a group
corresponding to the students. Note that any subdirectories you
later create under this directory will inherit the modified acl.<p>

<PRE>Example 9  Inheriting an ACL from the parent directory
athena% cd /mit/25.678
athena% fs sa www system:anyuser read
athena% fs la www
Access list for www is
Normal rights:
  system:anyuser rl
  system:25.678 rlidwka
  system:expunge ld
  system:facdev rlidwka
  joeuser rlidwka
  system:authuser rl
athena% cd www
athena% mkdir handouts
athena% fs la handouts
Access list for www is
Normal rights:
  system:anyuser rl
  system:25.678 rlidwka
  system:expunge ld
  system:facdev rlidwka
  joeuser rlidwka
  system:authuser rl
Example 10  Limiting Access to Certain Students 
athena% fs sa -dir /mit/25.678/students \\
-acl system:authuser none system:25.678-students read
</PRE>

This command can be typed as a single line by omitting the backslash character.<p>

There is some magic which occurs to make the translation between the
syntax 25.678-students and system:25.678-students. For details, see <A
HREF="LockerGuide.html#REF39471">Section 4.0 Technical
Information</A>. This section also contains information on changing the
acl on all directories in a locker.<p>

For more help with file permissions, consult the online help
documentation under the topic Managing Your Account (Including AFS). (To
start olh, type help at the athena% prompt.) <p>

<H3><A NAME="REF34956">3.3 Managing Executables</A></H3>

Many instructors want to make executable programs available to students
via a course locker. Due to the nature of the Athena environment, this
is slightly more complicated than just plunking a binary into the
locker. The guidelines outlined here conform to the standards used by
Athena developers and make the course locker easy to maintain and course
software easy to use.  The <B>lockers</B> man page is the definitive
description of Athena locker organization conventions.<p>

<H4><A NAME="HDR3.3.1">3.3.1 Introduction to binary
directories</A></H4>

Historically, locker maintainers have used a separate directory to store
binaries for each supported platform, or workstation type. In the early
days of Athena, the supported platforms were Digital VAXstations and IBM
RTs; later platforms included Digital DECstations and IBM RISC/6000s.
Currently supported platforms are Sun SPARCstations and Ultras, and SGI
Indys and O2s. Until the introduction of the SGI Indys, the locker
configuration guidelines suggested a binary directory for each platform
named according to the value returned by the machtype command plus the
string bin. Thus, lockers could contain directories named vaxbin, rtbin,
sun4bin, decmipsbin, and rsaixbin, respectively. <p>

However, it became apparent that this naming scheme did not contain
enough information because sometimes a binary which ran on one version
of the operating system would not run under a different version. The new
naming scheme looks for binaries to be stored in a directory under 
<pre>
      arch/$ATHENA_SYS/bin
</pre>

where $ATHENA_SYS is a system-wide environment variable set to a
machine-specific value. This naming scheme is detailed in <A
HREF="LockerGuide.html#REF39471">Section 4.0 Technical Information</A>
and summarized in <a href="#table5">Table 5</a>. If you follow this
convention, students will be able to use the add command to quickly
access a program in a locker.<p>

<PRE><A NAME="REF14331">Example 11  Using Add to Access a Program </A>
athena% add 25.578
athena% myprog
</PRE>

This works because the add command knows how to find binaries configured
according to these conventions.  See the <B>add</B> man page for more
information.<p>

 <p>

<pre><A NAME="table5">
TABLE 5: Binary conventions

<B>Current Values (Athena 8.3)</B>
--------------------------------------------------
<B>Directory Name</B>     <B>Platform and Operating System</B>    
--------------------------------------------------
arch/sun4x_56/bin  Sun, Solaris 2.6
arch/sgi_65/bin    SGI, Irix 6.5
--------------------------------------------------

<B>Previous Values</B>
-------------------------------------------------------
<B>Directory Name</B>     <B>Platform and Operating System</B>    
-------------------------------------------------------
arch/sun4x_55/bin  Sun, Solaris 2.5
arch/sun4m_54/bin  Sun, Solaris 2.4
arch/sgi_63/bin    SGI O2, Irix 6.3  
arch/sgi_62/bin    SGI Indy, Irix 6.2
arch/sgi_53/bin    SGI Indy, Irix 5.3
arch/pmax_u14/bin  Digital DECstation, Ultrix 4.3
arch/rs_aix32/bin  IBM RISC/6000, AIX 3.2
-------------------------------------------------------
</pre>

System types for the SIPB-supported platforms <a
href="http://web.mit.edu/linux/www/">Linux-Athena</a> and <a
href="http://web.mit.edu/netbsd/www/">NetBSD-Athena</a> are currently
<code>i386_linux2</code> and <code>i386_nbsd1</code>, respectively.  
The Linux-Athena 5.2 release (still in beta at this writing) uses
<code>i386_linux3</code>.

<H4><A NAME="HDR3.3.2">3.3.2  Configuring Executables</A></H4>

There are two cases to consider when configuring executables. In the
first case, users run the program without any special environment
settings, or else are expected to set up the environment for
themselves. The second case are programs for which you want to set up
the environment for students before invoking the executable itself.<p>

The first case is simple; just put the executables into the directories
as described above and tell users to use add as in <A
HREF="LockerGuide.html#REF14331">Example 11</A>.<p>

 In the second case, the program installed in the binary directory will
actually be some sort of startup script which sets the environment and
then invokes the real binary. <A
HREF="LockerGuide.html#REF21156">Example 12</A> shows a simple startup
script that sets an environment variable, attaches an extra locker, and
then invokes a binary. For this example, the real binary has been
renamed to start with a capital letter so that the script and the binary
can co-exist in the same directory.  Note also that we use <A
HREF="LockerGuide.html#HDR4.2.3">athdir</A> to find the correct binary
directory.<p>

<PRE><A NAME="REF21156">Example 12  Using a Startup Script</A>
 #!/bin/csh -f
setenv TEMP /var/tmp
attach infoagents
set bindir=`athdir /mit/25.578`
exec $bindir/Myprog $*
</PRE>

If you have questions about writing startup scripts, please contact one
of the Faculty Liaisons for assistance.<p>

<H4><A NAME="HDR3.3.3">3.3.3  Source Code</A></H4>

If you have source code for a program or programs developed here at MIT
or elsewhere, we recommend that you install it in a subdirectory called
src. If you expect to build and install this code for more than one
platform, we also recommend the use of Imakefiles to simplify the
process. Imakefiles are beyond the scope of this document, but feel free
to contact the Faculty Liaison Office for assistance.<p>

<H4><A NAME="HDR3.3.4">3.3.4  Removing Binaries for Obsolete Platforms</A></H4>

With the passage of time, some platforms become obsolete and are no
longer supported in the Athena environment.  The following platforms are
no longer supported: Digital VAXstations, IBM RTs, Digital DECstations,
IBM RISC/6000s.  You may safely remove any of these binaries to free up
locker space and we encourage you to do so. These binaries would
typically be stored in directories named vaxbin, rtbin, decmipsbin, and
rsaixbin, respectively. <p>

<H4><A NAME="HDR3.3.5">3.3.5 Dealing with Operating Systems
Upgrades</A></H4>

One side effect of the new naming conventions for binary directories is
that locker maintainers must be aware of operating system
upgrades. These upgrades occur approximately once a year and are
announced as part of an <a href="http://web.mit.edu/olh/Release/">Athena
Release</a>; the ACS <a
href="http://web.mit.edu/acs/www/insider">Insider newsletter</a> also
announces upcoming releases. <p>

Whenever an operating system is upgraded, you should make sure that all
your binaries run correctly. At the very least, this requires that you
create a new link in your arch subdirectory for the new operating system
version (see <A HREF="#REF34956">3.3 Managing Executables</A>) and run each
program on a workstation running the new release. At the most, it will
require recompiling software for which you have sources or possibly
getting a new version from the vendor. ACS will be glad to help you in
this process.  We also have test workstations which you may use to set
up and check your binaries; contact f_l@@mit.edu for more information.<p>

During the summer of 1999 we will upgrade the operating system on SGIs
to Irix 6.5; Sun workstations will continue to run Solaris 2.6. The
corresponding system values are:

<pre>
	sun4x_56  Solaris 2.6
	sgi_65    Irix 6.5
</pre>

There are two different ways to set up new binary directories in a
course locker.  <p>

<ol>
  <li>
If all of your binaries work correctly under the new operating
system, you can just make the new directory a symbolic link to the old
one.

<PRE>Example 14  Creating a Symlink to the Old Binary Directory
athena% attach 25.578
athena% cd /mit/25.578/arch
athena% ln -s sun4x_55 sun4x_56
</PRE>

<li> If any of the binaries need to be rebuilt, you should create a
     separate directory for the new operating system.

<PRE>Example 15.1  Creating a New Binary Directory
athena% attach 25.578
athena% cd /mit/25.578/arch
athena% mkdir sgi_65
</PRE>

Note that if an old binary still runs under the new operating system,
you can just create a link to it in the new directory.<p>

<PRE>Example 15.2  Sharing Some Binaries between Operating System Versions 
athena% cd sgi_65
athena% ln -s ../sgi_63/prog1
</PRE>
</ol>

<H3><A NAME="HDR3.4">3.4  Other types of Files and Directories</A></H3>

If you have questions about configuring other types of files or
directories, please contact the Faculty Liaison Office. <p>

<H3><A NAME="REF39471">4.0  Technical Information</A></H3>

<H3><A NAME="HDR4.1">4.1  AFS</A></H3>

<H4><A NAME="HDR4.1.1">4.1.1  About AFS</A></H4>

For a thorough discussion of AFS, you should see the Athena document AC
14: Managing Your Athena Account and the SIPB document Inessential
AFS. These documents are available through the Athena online help (type
olh at the athena% prompt). This section covers only those topics
applicable to course lockers and leaves out many details.<p>

AFS is organized by units called cells. Within each cell, quota is
allocated in terms of volumes. Most of the entities we call lockers
consist of a single volume, though it is possible to have multi-volume
lockers. Volumes are mounted in the AFS file system hierarchy which
begins at /afs. Mount points appear to be directories in the afs
hierarchy. Everything in the Athena cell is located under
/afs/athena.mit.edu (/afs/athena for short), and all course volumes are
under /afs/athena/course. Thus, you do not have to attach a locker to
gain access to its contents, though we strongly recommend this for many
reasons.<p>

AFS supports different types of volumes: read-write volumes, read-only
volumes, and backup volumes. The directory OldFiles in your home
directory or course locker is simply a mount point to the backup volume
for the volume comprising the locker. (At least, the volume if the
locker consists of a single volume.) AFS manages quotas on a per-volume
basis rather than a per-user basis, so anyone with write access to a
volume can use up its quota allocation.<p>

<H4><A NAME="HDR4.1.2">4.1.2 Groups and AFS </A></H4>

AFS does not use Athena groups directly but rather maintains its own
database of groups and group members. When you create a new group or
make changes to an existing group, there is an automatic propagation of
the changes into the corresponding AFS group. AFS groups are used to set
access control lists and are identified by a system: prefix. Examples of
AFS groups are system:facdev, system:2.14, and
system:anyuser. system:anyuser is a special group that corresponds to
anyone using AFS whether or not he or she has an Athena user id, and
system:authuser is anyone who has authenticated themselves locally in
the Athena cell. This corresponds roughly to anyone on Athena.<p>

<H4><A NAME="HDR4.1.3">4.1.3  The @@sys link</A></H4>

AFS supports a special string which can be used in path names and
dynamically expands to a special value according to the machine
type. This @@sys string is sometimes used as a user convenience link in
configuring binaries or libraries. For example, you can make the file
path /mit/locker/bin evaluate to the correct binary directory for each
supported platform. In other words, /mit/locker/bin can point to the
correct SGI binary directory if the user is on an SGI, or the Sun binary
directory if he/she is using a Sun and so on. The command to set up this
link is shown in <A HREF="LockerGuide.html#REF38204">Example 16</A>.<p>


<PRE><A NAME="REF38204">Example 16  Using @@sys for binary directories</A>
athena% cd /mit/locker
athena% ln -s arch/@@sys/bin bin
</PRE>

This will only work if you configure the locker according to the
conventions outlined in this document in <A
HREF="LockerGuide.html#REF34956">Section 3.3 </A>, and should only be
used for convenience. The <B>add</B> command will not find a directory
named simply bin! You must follow the conventions outlined in <A
HREF="LockerGuide.html#REF14356">Section 4.2 </A><p>

Note: the string "@@sys" should never be used literally, except in making
symlinks as above.  See <A HREF="LockerGuide.html#HDR4.2.3">Section
4.2.3</A> on the <B>athdir</B> command for references in scripts,
makefiles, etc.

<H3><A NAME="REF14356">4.2 The New Binary Directory Convention</A></H3>

<H4><A NAME="HDR4.2.1">4.2.1 Why we decided to change
conventions</A></H4>

We used to have a convention of naming binary directories according to
the output from the machtype command: vaxbin, decmipsbin, rtbin, vaxbin,
and sun4bin. As the number of supported platforms grew, lockers became
unwieldy and cluttered with all these bin directories at the top
level. Furthermore, as Athena development was responsible for deciding
what the machtype command returned, the naming scheme was rather
arbitrary and did not support different operating system versions.<p>

<H4><A NAME="HDR4.2.2">4.2.2 $ATHENA_SYS and $ATHENA_SYS_COMPAT</A></H4>

The environment variable $ATHENA_SYS is set in the system-wide dotfiles
at login time; it is used by commands such as <B>add</B> to locate the
appropriate files for the system on which the user is currently working.
The value of $ATHENA_SYS matches the AFS value for the @@sys link and can
also be determined according to the output of the command machtype
-S:<p>

<PRE>athena% machtype -S
sun4m_53
</PRE>

When writing your own shell scripts, makefiles, etc., it is
recommended that you use <B>athdir</B> to locate machine-dependent files
(as described in the next section) rather than $ATHENA_SYS;
<B>athdir</B> is more reliable in case of new operating system releases
and changed locker conventions.<p>

The environment variable $ATHENA_SYS_COMPAT was introduced to help
lockers which have not yet been updated for a new operating system
continue to function until the maintainers have updated their arch
directory structure.  The system-wide dotfiles set $ATHENA_SYS_COMPAT
to a fallback list of @@sys values which are known to be generally
compatible with the current system; if the correct @@sys value isn't
supported by a locker, commands such as <B>add</B> and <B>athdir</B>
will attempt to use a value from this fallback list instead.  In this
case, the user may see a message like this:

<pre>
athena% add badlocker
add: warning: using compatibility for /mit/badlocker
</pre>

Note: compatibility is intended as a mechanism to keep lockers working
temporarily; it is not to be relied on as a substitute for updating
binary directories when operating systems are upgraded.  See <A
HREF="LockerGuide.html#HDR3.3.5">Section 3.3.5 Dealing with Operating
Systems Upgrades</A> for recommended procedures.

<H4><A NAME="HDR4.2.3">4.2.3  athdir</A></H4>

Along with the environment variable $ATHENA_SYS and the new locker
conventions, Athena introduced the athdir command. athdir can be used to
find any type of machine dependent directory in a locker. One common use
of athdir is to locate the machine-specific binary directory in a locker
as in <A HREF="LockerGuide.html#REF30372">Example 17</A>. As this
example shows, athdir recognizes both the old and new style directory
configurations.<p>

 athdir can be used in Makefiles and startup scripts as shown in <A
HREF="LockerGuide.html#REF38278">Example 18</A>. athdir takes many
options and is completely described on the athdir man page.<p>

<PRE><A NAME="REF30372">Example 17  The athdir command</A>
athena% attach frame; athdir /mit/frame
/mit/frame/arch/sun4m_53/bin
athena% attach sipb; athdir /mit/sipb
/mit/sipb/sun4bin


<A NAME="REF38278">Example 18  athdir in a Makefile</A>
LOCKER = &quot;/mit/25.578&quot;
BINDIR = `athdir $LOCKER`
INCLUDES = `athdir $LOCKER include`
LIBS = `athdir $LOCKER lib`
</PRE>

<H4><A NAME="HDR4.2.4">4.2.4  Using a shared directory for scripts</A></H4>

If you have many startup scripts or other programs which are actually
scripts and therefore can be shared between different machine types, you
may want to install them into a shared directory. You will still need
links in the machine-specific directories, but installing into a single
location makes it easier to maintain and update the script. The
recommended configuration for using a shared directory is<p>

<PRE>/mit/locker/arch/share/bin
</PRE>

For each shared script you must create a soft link from the
machine-specific binary directory to the shared installation
location. <A HREF="LockerGuide.html#REF15030">Example 19</A> shows you
how to do this.<p>

<PRE><A NAME="REF15030">Example 19  Sharing a startup script</A>
athena% attach 25.678
athena% cd /mit/25.678
athena% mkdir -p arch/share/bin
athena% cd arch/share/bin
athena% emacs myscript &amp;
<I>create the script here</I>
athena% chmod +x myscript
athena% cd../../sun4m_53/bin
athena% ln -s /mit/25.678/arch/share/bin/myscript
</PRE>

<H3><A NAME="HDR5.0">5.0  Course Locker Re-use Policy</A></H3>
d12 2
a13 7
Course lockers are re-used from semester to semester.  Locker 
owners/maintainers are advised that any files they leave behind in a 
course locker at the end of the semester may be deleted or re-used
by course staff who later inherit the locker.  At the end of the
semester you are responsible for saving any files that you wish to
keep, and for deleting anything which you do not wish to share
with subsequent course staff. 
d15 2
d18 4
a21 143
When an existing course locker is reused in later terms, we try to
notify the people already on the ACLs as a courtesy, but it is up
to new course staff to follow up with previous course staff
regarding the disposition of any existing files.  We are happy to
assist you with archiving existing files in an inherited locker,
and clearing out or archiving your own files at the end of the
term. 
</P>
<H3><A NAME="REF32604">6.0  Answers to Frequently Asked Questions</A></H3>

This section contains some answers to frequently asked questions about
course lockers. Answers which contain instructions and step-by-step
detail do not contain any explanation or reasons. For further
information you should consult the appropriate sections in this
document.<p>

<OL>
<LI>What does the error "add: warning: using compatibility for
/mit/xxx" mean?<p>

This means that the add command can't locate files according to the
current @@sys value for your platform, and is attempting to use a
fallback value supplied by $ATHENA_SYS_COMPAT.  Most likely, there has
been an operating system upgrade, and the locker needs to have its
arch directory structure updated; see <A
HREF="LockerGuide.html#HDR3.3.5">3.3.5 Dealing with Operating Systems
Upgrades</A> for help.<p>

<LI>Why doesn't add find my SGI binaries?<p>

If the add command is returning an error such as &quot;Command not
found&quot;, your locker is probably not configured correctly.  Under
Athena 8.3, all SGI binaries should be put into a 
directory named according to the convention /mit/locker/arch/sgi_65/bin.
<p>

<LI>Where should I put executables for platform &lt;X&gt;?<p>

If you are setting up a new locker, the best thing is to follow the new
conventions for naming binary directories. <A
HREF="LockerGuide.html#table5">Table 5</A> lists the
directories and corresponding platforms.<p>

<LI>Where should I put my web pages?<p>

New course lockers are created with a directory named www at the top
level; you should place your web pages in this directory.  If such a
directory does not already exist, you will need to create it and then
set the access control list on the top level of the locker and www
directory as shown in <A HREF="LockerGuide.html#REF21151">Example
8</A>.<p>

<LI>What's the URL for the locker's web page?<p>

     The URL will follow the naming scheme
     <pre>
     http://web.mit.edu/locker/www/</pre>
     (assuming you name your top   
     level page index.html, and place it in the www directory of your
     locker). <p>

<LI>Is there any way to restrict access to my web pages to MIT?<p>

Yes, there is.  For more information, see <a href="http://web.mit.edu/cwis/tute/mitmostly2.html">http://web.mit.edu/cwis/tute/mitmostly2.html</a>.  <p>

<LI>Where can I get help with creating web pages?<p>

<a href="http://web.mit.edu/cwis/">CWIS</a> (Campus Wide Information
Systems) provides training, assistance, and a wealth of information
including a list of <a href="http://web.mit.edu/cwis/faq/">CWIS
Frequently Asked Questions</a> about web publishing at MIT.<p>

<LI>How can I get more quota for my locker?<p>

First make sure that you have removed any files and directories which
are no longer needed. Athena does not have unlimited resources! Once you
have done this, send an email request to f_l@@mit.edu stating what locker
needs the quota increase, how much more you need, and why you need it.
We will listen to each request, but because of resource limitations we
cannot grant every one.<p>

<LI>Last year the TA stored some files in his home directory. He left MIT; how can I get those files back?<p>

If you are fortunate, the TA's directory is still online. You can find out if this is the case by typing the command<p>

<PRE>athena% hesinfo username filsys
</PRE>

If this command does not return an error, the directory is still
online. In this case, send email to f_l@@mit.edu, telling us what files
you need to access.<p>

If the TA's directory has been deleted, we will need to restore from
tape. To do this, send email to f_l@@mit.edu giving us the TA's username
and files you need to recover.<p>

<LI>Last year students used a program in my course locker. Now
suddenly it says &quot;Command not found&quot; when I use add. What
happened?<p>


Are you using the recommended configuration for binary directories?
There was probably a new Athena release and an operating system
upgrade. You may be able to fix the problem simply by creating a
symbolic link, but contact the Faculty Liaisons for more
information. You may also want to read <A
HREF="LockerGuide.html#REF14356">Section 4.2 The New Binary Directory
Convention</A> and <A HREF="LockerGuide.html#HDR3.3.5">Section 3.3.5
Dealing with Operating Systems Upgrades</A>.  <p>

<LI>How can I find out what files recently changed in my
locker?<p>


The UNIX find command is useful for finding recently modified files. Go
to the top level of your locker and type the command<p>

<PRE>find . -mtype -&lt;n&gt; -print </PRE>

where &lt;n&gt; is the number of days since the files changed.<p>

You can also get a good idea of what changed recently by using the ls
-ltr command as shown in <A HREF="LockerGuide.html#REF32089">Example
20</A>.<p>

<PRE><A NAME="REF32089">Example 20 Using ls -ltr </A> athena% cd
/mit/25.678 athena% ls -ltr | tail -20 </PRE>

ls -ltr lists the files and directories in reverse order according to
modification date. By piping this command into tail, ls will list only
the last 20 modified files or directories<p>

</OL>



<hr>
This guide was written by Dorothy L. Bowe, and is now maintained by miscellaneous
Faculty Liaisons.  Please send any questions or comments to <a
href="mailto:f_l@@mit.edu">f_l@@mit.edu</a>. <p>
<!-- hhmts start -->
Last modified: Mon Jun 28 09:29:11 1999
<!-- hhmts end -->
@


1.2
log
@added Course Locker Re-use Policy section
@
text
@d746 1
a746 1
<B>Current Values (Athena 8.2)</B>
d751 1
a751 2
arch/sgi_62/bin    SGI Indy, Irix 6.2
arch/sgi_63/bin    SGI O2, Irix 6.3  
d760 2
d771 3
a773 3
<code>i386_linux2</code> and <code>i386_nbsd1</code>, respectively.  In
fall 1998, a new SIPB Linux-Athena platform is scheduled to be released
which will have system type <code>i386_linux3</code>.
d849 2
a850 4
During the summer of 1998 we will upgrade the operating system on each
of our supported platforms.  Sun workstations will move from Solaris 2.5
to Solaris 2.6; SGI Indys will move from Irix 5.3 to Irix 6.2.  In
addition, new SGI O2s will be installed with Irix 6.3.  The
d855 1
a855 2
	sgi_62    Irix 6.2 (SGI Indy)
	sgi_63    Irix 6.3 (SGI O2)
a857 10
For this release, Irix 6.3 was the only version available for the 02,
but it does not run on Indys; SGI is working on a unified version
which will run on both the 02 and the Indy in future.

Most programs will continue to run without modification, but some care
should be taken if you will be compiling programs on SGIs in the future.
While programs compiled on Indys running Irix 6.2 should run on O2s
running Irix 6.3, the reverse is not guaranteed.  That is, an Irix 6.3
binary may <B>not</B> run under Irix 6.2.<p>

d879 1
a879 1
athena% mkdir sgi_62
d886 2
a887 2
athena% cd sgi_62
athena% ln -s ../sgi_53/prog1
d1123 2
a1124 3
Athena 8.2, SGI O2 binaries should be put into a 
directory named according to the convention /mit/locker/arch/sgi_63/bin,
while Indy binaries should be found under /mit/locker/arch/sgi_62/bin.
d1232 1
a1232 1
Last modified: Wed Aug  5 18:14:53 1998
@


1.1
log
@Initial revision
@
text
@d97 3
a99 1
<A HREF="LockerGuide.html#REF32604">5.0  Answers to Frequently Asked Questions</A>
d134 1
a134 1
maintainers. Finally, <A HREF="LockerGuide.html#REF32604">Section 5.0
d149 1
a149 1
HREF="LockerGuide.html#REF32604">Section 5.0 </A>. If you do not see
d563 1
a563 1
groups, see <A HREF="LockerGuide.html#REF32604">Section5.0 Answers to
d1092 20
a1111 1
<H3><A NAME="REF32604">5.0  Answers to Frequently Asked Questions</A></H3>
@
