Athena 9 Private Workstation Owner's Guide

Introduction

Some members of the community also have "private" Athena workstations in their offices or other private areas. These are, by default, configured like workstations in public clusters. They have the same access to Athena services, and logging into these workstations is identical to logging into a workstation in a public cluster. This private workstation may be shared by a few users in the department (for example, a few graduate students working with the same faculty member).

A workstation designated for private use can be configured to provide additional services to those users who log into it, either directly (at the keyboard) or from a remote site. With these software configuration changes, the workstation becomes a customized private workstation. You can configure the software on your workstation to allow remote logins, to personalize the workstation, add software, and to restrict access to the workstation's services.

NOTE: It is against the Athena Public Facilities Rules of Use to customize any public Athena workstation. If you are not sure about the status of a particular workstation, check with your manager, department head, or other appropriate authority.

This document is intended for workstation owners who want to customize and provide ongoing care for their private Athena workstations. This document is not intended to be an introduction to the Athena system. There are several free introductory documents available at the CopyTech Center in 11-004 or see our web site: http://web.mit.edu/olh/.

Athena Support

Hardware Problems: Athena Hardware Hotline

Unless you are a Minimal Standard Athena (zero-cost) customer, you should still use the Hardware Hotline to make service calls. They also handle problems relating to Athena facilities such as the workstations and printers in the public clusters. They can be contacted as follows:

During their business hours, the hotline often uses a pager dispatch system. If you're asked to leave a voice-mail message, provide the information requested, including a phone number where you can be reached. A hotline staffer will be paged, and will contact you as soon as they can.

You should contact the Athena Hardware Hotline if you want to report:

• problems with printers or workstations in public clusters;
  
• Athena hardware that appears to be broken or malfunctioning;
  
• malfunctioning workstations and system crises, such as crashes or hangs;
  
• problems with an Athena machine that you suspect is most likely the result of a problem with the physical parts of the device;
  
• hardware stolen from a cluster (in this case, also call Campus Police at 253-1212).
  

• your name, department, and telephone number
  
• the location of the machine with the problem
  
• the hostname of the machine
  
• the system type (e.g., Sun SPARCstation 5 or SGI O2)
  
• the serial number of the CPU (usually located on the back of the CPU)
  
• any error messages visible on the screen
  

Software Problems: Athena User Consultants

Whether contacted on-line or in person, Athena Consultants can help with questions or problems with supported Athena software. They can also answer more general questions about Athena, such as locations of facilities or whom to contact with administrative questions. NOTE: The Athena Consultants support the public Athena Computing Environment only. They can try to help with private workstation issues, but you should check with your cluster manager or system administrator (if it's someone besides yourself) before customizing or rebooting the machine.

For Faculty and Teaching Assistants: Athena Faculty Liaisons

Maintaining Your Private Workstation

Becoming Superuser

There are two methods of becoming root:

• If you are not logged in already, you can log in with username "root" at the username/password prompt.
  
• If you are already logged in as yourself, you can become root with the su - command.
  

Note: If the workstation is already customized you will get the default password for public workstations and a warning, as shown in the example below, that the workstation has already been customized. Contact the owner or other users of the machine to find out the root password and what changes they have already made to the defaults.

 athena%  tellme root 
 Warning: This is a private workstation. It may not
 have the Athena root password.

 The Athena root password is default-root-password.

  athena% cd /
  athena% su - root
  Password:
  melonie.mit.edu#

Who Else is Logged In?

The who command will list all users currently on the machine, and can be run either as a user or superuser. You can zwrite any users and ask them to logout. Also, the shutdown command has provisions for notifying all logged-in users that the machine they are using is about to be shutdown. (See Zephyr on Athena for more on zwrite. Type man shutdown at the athena% prompt for more information about the shutdown command.)

From Public to Private

1. Edit /etc/athena/rc.conf to set the PUBLIC variable to false.
2. Change the root password.

Step 1: Set PUBLIC=false

  melonie.mit.edu# grep PUBLIC /etc/athena/rc.conf
  PUBLIC=true;    export PUBLIC    # Public workstation?

  melonie.mit.edu# /usr/athena/bin/emacs  /etc/athena/rc.conf

If you check the setting as before, PUBLIC should be set to false:

  melonie.mit.edu# grep PUBLIC /etc/athena/rc.conf
  PUBLIC=false;    export PUBLIC    # Public workstation?

Step 2: Changing the Root Password

Before changing the root password on your workstation, think of a good, unguessable password. You can read about the guidelines for choosing a good password at http://web.mit.edu/olh/Working/Working.html#passwd_choose.

Next, while you are logged in as root, run the passwd program. Since you are already the superuser, it will not ask you for the old password.

  melonie.mit.edu# /usr/athena/bin/passwd
  Running local password-changing program for root.  
  New password: new-password
  Re-enter new password: new-password
  passwd (SYSTEM): passwd successfully changed for root
  Updating /etc/shadow.local with new passwd entry.
  melonie.mit.edu# exit

Shutting Down and Rebooting Your Workstation

Shutting Down Your Workstation

A proper shutdown of a workstation has two steps:

• Halting the operating system
• Then shutting off the power

CAUTION: Do not turn off the workstation until you have halted it. Turning off workstation power before the machine is halted can have several bad effects, including ruining the disk drive with a permanent loss of much or all of its data.

Use the halt command to halt a workstation (see man halt for details). Login as root and type:

  melonie.mit.edu# cd  /
  melonie.mit.edu# halt

Rebooting Your Workstation

"Soft" Reboots

Make sure no one else is logged in. Then become root with the su command, and type:

  melonie.mit.edu# cd  /
  melonie.mit.edu# reboot

"Hard" reboots

To perform a hard reboot on a Sun workstation, perhaps because the system does not respond to the keyboard, hold the Stop key (on the left side of the keyboard) and press the a key. (This may very well work, even if the keyboard is not doing anything else!) When the ok prompt appears, type boot.

(If you change your mind about booting after you type Stop a, you can type go at the ok prompt to return to your session. You may need to refresh your windows:

  athena% xrefresh

If you encounter any trouble, please contact an Athena Consultant (253-4435) or report the problem to the Athena Hardware Hotline (253-1410).

Booting your workstation single user mode

On a Sun, type boot -s at the ok prompt to boot in single user mode. On a Linux box there are two methods. If you see a lilo: prompt as you are booting up, typing linux single at the prompt and hitting enter will instruct the workstation to boot in single user mode. On newer workstations you should get a menu at boot time which will allow you to make this choice.

When you do this you'll be given a root shell without having to type your password. Since the system is not on the network, files in afs will be unavailable and many services will be turned off.

Backing Up and Restoring Your Files

The Athena document Working on Athena (AC-11), http://web.mit.edu/olh/Working/, covers the details of backing up files to removeable media. Please read those notes and establish a backup routine for your files.

TSM

At MIT, TSM runs as a client program on Athena workstations (as well as PCs and Macs) over MITnet to the mainframe-managed "tape farm" in W91. It is available to individual users (including students) and network administrators. TSM is intended for backup of files on your local disk, rather than for files stored on the network by AFS.

TSM offers storage under two different retention policies: backup and archive.

Backup

Backup is intended for short-term recovery of the current state of your directories and files after a data disaster (user mistake, machine crash, natural disaster, et cetera). When a new backup copy is made, it is considered active, and the previous copy is classed as inactive. In addition to the active version, the system will keep up to nine previous, inactive versions. This active (most recent) copy is kept indefinitely, while the inactive ones expire after 30 days and are deleted from server storage.

The first time you run a backup, you may specify which directories are to be maintained, and a full copy of those directories will be made. Subsequent backups are incremental, storing only the changes made since the previous backup. You may also register for the server's predefined schedules, to have full or incremental backups run each week.

TSM backup gives limited protection for deleted files, so you need to be careful. Suppose you delete some files (or subdirectories) from a directory for which you are maintaining backups. When you next make a backup of that directory, the system will notice the change and remove all of the inactive copies of those deleted files. The active copy of each deleted file is kept as a safety measure, but for only 60 more days. But after an accidental deletion of a needed file, you'd better recover the file within 2 months or it will be gone for good.

Archive

Archive is intended as long-term storage of particular files of historical interest. In contrast to backups: archives do not depend on the previous copy date; there is no limit on the number of previous versions stored; and instead of a fixed 60 days, you can specify an archive copy's expiration date (up to 1220 days, a little more than three years). Also, archive copies are not subject to the same comparison and removal of currently deleted files.

The document Backup for a Private Athena Workstation: Quick Guide for an Individual User, found at http://web.mit.edu/is/help/adsm/athena.html describes the ADSM utility in detail. Here are some points that may help you decide if ADSM is an appropriate tool for you.

• Cost: while the ADSM software is free, the backup service costs $7.50 a month per machine for all new accounts.
  
• Size of backup: A diskette can hold 1.4 Mb of data. Depending on what kind of data you are backing up, the compression tools available on Athena can reduce your files significantly. However, backing up a large amount of data will often still require quite a few diskettes.
  
• ADSM backup on Athena is appropriate for private workstations located in a securable area. It is not appropriate for use with workstations located in public clusters or open to public logins.
  
• Currently, TSM on Athena is available for Sun, Linux and SGI machines in the adsm locker.
  

Software Updates

Major Athena Releases are announced via the release-announce mailing listand Release Notes are made available before each release. The System Release Notes cover all the technical changes to the system, and the User Release Notes cover the user-visible changes, including any new software, or new versions of existing software.

To subscribe to the release-announce list visit the MIT mailman web interface at:

http://mailman.mit.edu/mailman/listinfo/release-announce

To see what version you currently have, look at the last line of the /etc/athena/version file:

  athena% tail -1 /etc/athena/version

  Athena Server (SUN4m) Version #.#.# update-time

Getting Athena Software Updates

Once you have done this, whenever a new release is available, a message will be displayed (the message is displayed in the console, if the workstation has had a chance to reactivate between logins, and at boot time):

  The workstation software version (8.2.13) does not match the version
  on the
  system packs (8.2.15).  A new version of software may be available.
  Please contact Athena Operations (x3-1410) to have your workstation
  updated.

Updating Your Workstation Manually

• a minor release: only the third field will change, as from 8.0.4 to 8.0.5.
  
• a major release: either the first or second fields will change, as from 7.4 to 7.5, or 7.7.6 to 8.0, or 8.1.7 to 8.2.
  

1. Login as root on the console.

   Make sure no one else is logged in (use who). Shutdown the X Window System by hitting Ctrl-p at the login screen. Then login as root.

   Note: If your workstation is running Linux or this is a minor release, skip to step 4. You do not need to switch from old to new system packs.

2. Detach the old packs. To detach whatever packs are currently attached,

     melonie.mit.edu# detach -a
   

3. Attach the new packs. To get the name of the correct packs, type:

     hesinfo hostname cluster
   

   then select the syslib in the line with the desired version number. For instance, an example from a Sun:
   

     melonie.mit.edu# hesinfo melonie cluster
     lpr cretaceous
     syslib athena-sun4sys-80 8.0
     syslib public-sunsys
     syslib athena-sun4sys-81 8.1
     syslib athena-sun4sys-82 8.2
   

   If you want to update to Athena version 8.2, choose the syslib in the last line and attach those packs:

     melonie.mit.edu# attach -O athena-sun4sys-82
   

   Note that "-O" above uses a capital letter "O" (i.e., not the number "0").

4. Start the update process:

     melonie.mit.edu# /etc/athena/update_ws
   

   This may ask you to press Return or prompt you for other information. The prompts should be self-explanatory.

5. Reboot the machine. After the update says it has updated the version number and another # prompt has appeared, type:

     melonie.mit.edu# reboot -q
   

When Updates Affect Customizations

To preserve customizations across an update, you can also create a file called /var/server/.private. The .private script (a /bin/sh shell script) runs after the mkserv scripts and further customizes the workstation. For example:

  #!/bin/sh
  echo "Running .private script..."
  echo
  cp -p /var/local/motd /etc/motd
  echo "*loginName: milano" >
  /etc/athena/login/Xlogin.local

These methods should ensure that your customizations are preserved; however, they may not cover all cases. Making regular backups of your whole workstation cannot be overemphasized.

Linux-Specific Update Problems

If an RPM that you installed has a dependancy, which would no longer be satisfied after an update, the update will fail. The easiest way to deal with this is to remove the offending RPM, if you notice an update fail, and then proceed with the Athena update. Finally, when you've successfully updated the machine, download and install an up to date version of the package you removed.

To find out which RPMs are installed that aren't part of the release, you can run:

 athena% /etc/athena/rpmupdate -np /dev/null /var/athena/release-rpms
 Erase package ImageMagick-devel
 Erase package ImageMagick-perl

Be careful! The -n is crucial to making sure you don't accidentally remove the extra packages.

To remove a package that you installed with RPM, you'll need to use the --erase option to rpm. For example:

  bash-2.05a# rpm --erase ImageMagick-devel ImageMagick-perl

Even if none of your extra packages cause errors, it's important to keep them up to date, and to check with the distributor periodically for more recent versions. The only packages that will ever update automatically are those which are part of the RedHat distribution. Even for these, you can't count on them updating; if RedHat renames the package, or replaces the functionality in other packages, you will be left with the old one.

Problems with Updating

  Athena Workstation (sun4) Version Update update-time
  Athena Workstation (sun4) Version #.#.# update-time
  Athena Server (sun4) Version Update update-time
  Athena Server (sun4) Version #.#.# update-time
  Athena Server (sun4) Version Update update-time
  Athena Server (sun4) Version #.#.# update-time

  This system is in the middle of an update.  Please contact Athena
  Operations at x3-1410. Thank you. -Athena Operations

Customizing Your Workstation via Software

Acquiring Personal Third Party Software

You can write to 3partysw@mit.edu with questions about third party software. You can see a list of the software already available on Athena at http://web.mit.edu/acs/www/whereruns.html.

Licensing Software

To initiate licensing, users should determine which product they want and should negotiate directly with vendor representatives over business terms and prices. You should always ask about academic discounts; many vendors offer these, but not all volunteer the information. Some vendors may be willing to pool individual MIT licenses into a discounted volume license or a site license. It is a good idea to ask about this as well.

It is strongly advised that users get a free evaluation copy of any software intended for use on Athena machines before committing to purchase. There are a number of known cases where third party software cannot be made to run on an Athena machine.

If the vendor does NOT require a signed license, users can license the software directly from the vendor. The users are responsible for honoring the license terms that come with the software ("shrink-wrap license").

If the vendor DOES require a signed license, users should make initial contact with the vendor representative and negotiate business terms as above. They should also get a copy of the proposed license from the vendor. This license should then be sent (along with the requisition and other accompanying paperwork) to be reviewed by an MIT intellectual property attorney. (Call 253-1348 for details.) Under no circumstances should MIT end-users sign licenses on their own.

Installing Third Party Software

• Determine the installation and type of install media (tape, CD-ROM, etc.) with the vendor. These instructions presuppose that installation is on the local hard disk of a workstation, or on a "local" server. This is the recommended and expected location for third party software on a private Athena workstation.
  
• You need access to the appropriate media device (tape, CD-ROM, etc.), either locally on the given machine or somewhere else on the network.
  

• Read and thoroughly understand all required installation steps. It is particularly important to check disk space and filesystem requirements. (These requirements are usually covered in the vendor-supplied installation instructions.) You can check the free disk space with the df -k command:
  

    athena% df -k
    Filesystem        kbytes     used    avail capacity Mounted on
    /dev/dsk/c0t3d0s0  30783    13584    14129   49%    /
    /dev/dsk/c0t3d0s5  57663    39122    12781   75%    /usr
    /proc                  0        0        0    0%    /proc
    /dev/dsk/c0t3d0s6 307982     7693   269499    3%    /var
    /dev/dsk/c0t3d0s3  46183    34277     7296   82%    /var/usr/vice
    AFS            9000000        0  9000000   0%     /afs
  

  On Suns, find the /var filesystem in the Mounted on column; the free local disk space is normally found under /var. The oldest Athena SPARCstations typically have about 200-300 Mb of free disk space, the newest Ultras, at least 3Gb. If you need more space, you can purchase an additional disk drive (see Configuring External Devices).

  SGIs do not have a separate /var partition; therefore, you have to use the root partition for this. There is, however, a /var subdirectory in the root partition.
  

• Attempt to read and write a scratch tape before using your tape drive to read a vendor tape for software installation. This gives you experience using the tape drive, and hopefully eliminates configuration problems when trying to read the vendor supplied tape.
  

• Because of the way Athena is designed, not all of the usual UNIX directories are writeable by default. If the installation allows you to choose an installation directory, a good choice is /var/name-of-software on Suns, since free local disk space on SPARCstations is normally under /var.
  
• Some installations require a certain installation directory. You may have to examine the instructions or the installation script itself to find this out. In some cases you may have to run it and see what happens.
  
• If the installation must be made into the directory /usr/local/name-of-software but /usr/local does not exist on your workstation, you can become root and create a link to it with the following commands (if /var/local already exists, skip the first command):
  

    melonie.mit.edu# mkdir /var/local
    melonie.mit.edu# cd /usr
    melonie.mit.edu# ln -s /var/local local
  

  This indirect approach is necessary on Suns because /usr is on a small partition on Athena machines and is overwritten by updates. This is not true, however, for SGIs, which provide a /usr/local. However, as releases may change it, it is best to avoid using it if at all possible.
  

• If the installation requires other specific directories, check if they are writeable. Refer to the document Working on Athena for information about directory permissions. Directories on your hard disk use UFS/NFS permissions, not AFS.
  

• If you cannot write to the required directory and it is not /usr/local, you probably need to do some additional configuring. It is not easy to give specific instructions to fix the problem, as the link method used above often does not work in other situations. It is best to get expert help from the software vendor in such situations. In order to resolve problems, they need to know how Athena machines differ from "standard" vendor configurations in as much relevant detail as possible. If you ask a "private_ws" question in OLC, they can help you or point you to the right expert help.
  

• A possible source of difficulty involves license servers in third party software. There can be a number of problems here. For instance, some vendors' license servers may lock files written to the /tmp or /usr/tmp directories. These directories are not always cleared on Athena machines under the same circumstances as "standard" vendor configurations, and as a consequence the license daemon can "die" at short time intervals as users log on and off the machine. As above, you may need expert help via OLC.
  

Installing software as superuser:

• Some installations do not run unless you are root, but this process is potentially dangerous. The installation process could inadvertently write over important files. It is usually safe to attempt an installation as an ordinary user (even if the installation instructions say you must be root). This usually lets you know what the installation is trying to do. It is wise to have everything important on the workstation backed up before you attempt this.
  

Installing RedHat packages on Linux workstations:

It's possible to install RPM packages on Linux workstations using rpm as you would on a non-Athena RedHat Linux system.

To do this, you will need to obtain the appropriate rpm file, become root, and then run:

  bash-2.05a# rpm -ivh some-package.i386.rpm
  Preparing...                ########################################### [100%]
     1:some-package           ########################################### [100%]

• Don't use the force options that rpm provides. If you don't respect the listed dependancies, your machine will have trouble taking updates in the future.
• If you want software that's distributed as part of the RedHat release, look for it under /afs/athena/system/rhlinux/. You'll need to find the appropriate RedHat release (check /etc/redhat-release), and you should check the updates directory to make sure you get the newest version of the package in question.
• It's up to you to keep extra software that you install up to date. Packages that are distributed by RedHat will usually be updated during Athena updates, but only if RedHat has provided a later version by the same name. This is especially important if what you installed is a network service, which has the potential to cause a security problem.
• Don't upgrade or rebuild your kernel out-of-sync from the Athena release, since doing so will usually cause AFS to stop functioning. A lot of software that suggests a kernel rebuild is also available as a loadable module. Ask the Athena Consultants for advice.

Setting Appropriate File Ownership and Permissions

Some Pre-login Defaults: Username and MOTD

Setting Default Login Username

As root, set the default login-screen username by putting a line of the form

*loginName: username

Suppressing the Pre-login MOTD

  *showMotd: off

Adding Your Own MOTD

  *motd2File: motd-filename

Getting Long Kerberos Tickets to Run Batch Jobs

  athena% kinit -l 1275m $user
  MIT Athena (melonie.mit.edu)
  Kerberos Initialization for "doughboy"
  Kerberos ticket lifetime (minutes): 1275
  Password: <enter your password here>
  athena% fsid -a
  fsid: doughboy mapped
  fsid: matlab mapped
  fsid: library mapped

If your job will take longer to run than the maximum Kerberos ticket lifetime, then, in general, you must make a copy of everything the program needs to use during the execution. That is, the software should not try to use anything out of any lockers, or by going through the AFS hierarchy; once your tickets have expired, the program can no longer read or write anything on a remote file system, and your program could die in some unexpected way. This depends on the filesystems your software attempts to contact during the run, since it is possible for owners of lockers to set up the protections such that users without tickets can access the files. Most third party software on Athena (such as MATLAB and Maple) does require that the user have tickets to start it, and many lockers require the user have valid tickets to read or write there.

Giving Users Access to Your Workstation

User Authorization

In order to limit local access to your machine, all you need to do is create the /etc/athena/access file as outlined below. In that file you can limit local login access to just yourself or or expand it to include other users.

In order allow remote access to your machine, you must run mkserv remote as outlined in the remote access section of this document. Then you can control that access with your /etc/athena/access file as outlined below.

/etc/athena/access

The file /etc/athena/access is used to control remote and local user access to the machine. This access file contains the list of authorized users, with the allowed login permissions for each user: whether local or remote or both. The file can also reference the pre-existing list of users in the /etc/passwd file. A sample /etc/athena/access file might look like this:

  ##########################################################################
  # /etc/athena/access for Joe User's workstation MELONIE.MIT.EDU
  joeuser     lr
  janeuser    lr
  # Don't let Badminton T. Guyerson  log in anymore!
  badguy      -- Sorry Badguy, you are not allowed to login here.
  *inpasswd   l  Access allowed from Joe User's office, not remotely.
  *           -- This is a private workstation. Questions to
  <joeuser@mit.edu>

Creating Local Accounts for Athena Users

Also note that Information Systems will not support local accounts for users who do not have Athena accounts. An experienced UNIX administrator who wishes to create, and be responsible for, such local accounts can refer to the man pages for useradd and access for some of the information they will need. The rest of this section concerns creating accounts for users who already have Athena accounts.

The procedure for creating a permanent local account involves two main tasks:

• adding a permanent password entry to the workstation's password file
  
• creating a permanent local directory with appropriate permissions
  

Otherwise, here are the steps:

1. Become root.

2. Check to see if the file /etc/passwd.local exists.

     ls /etc
   

   If it does not alredy exist, create it by making a copy of /etc/passwd.

      cp /etc/passwd /etc/passwd.local
   

3. Get the user's password entry from the Hesiod nameservice; add it to the local database.
   

     hesinfo username passwd >>
     /etc/passwd.local
   
     melonie.mit.edu# hesinfo cmonster passwd >>
     /etc/passwd.local
   

4. Create a local directory for the user in the /var directory. (Reboots and system updates do not affect directories in /var)
   

     mkdir /var/username
   
     melonie.mit.edu# mkdir /var/cmonster
   

5. Give the user ownership of the new directory.
   

     chown username /var/username
   
     melonie.mit.edu# chown cmonster /var/cmonster
   

6. If you want to keep the user's Athena AFS locker as his or her home directory, skip to step 7. To have the user's home directory default to the new local directory instead, change the home directory field in the /etc/password.local file. A password entry contains these fields:
   

     username:*:uid:gid:User
     name,Nickname,Office,WorkPhone#,HomePhone#:HomeDir:LoginShell
   

   In this case:

     cmonster:*:29999:101:Cookie Monster,Cookie,W20-105,5550733,
     :/mit/cmonster:/bin/csh
   

   replace /mit/cmonster with the directory created on the local disk in step 3:
   

     cmonster:*:29999:101:Cookie Monster,Cookie,W20-105,5550733,
     :/var/cmonster:/bin/csh
   

   When the user logs into this private workstation, the home directory is set according to the HomeDir field in the user's password entry, in this case, to /var/cmonster instead of /mit/cmonster. Note: even if the local directory is set here as the default home directory, the user's AFS locker will also be mounted at login.

7. When you have completed installing the account, the new local directory is empty. The user can now copy "dotfiles" from his or her Athena locker to this local account, or obtain default "dotfiles" from /usr/prototype_user:
   

     melonie.mit.edu# cp -r /usr/prototype_user
     /var/cmonster
   

8. If you have more local accounts to create, repeat this procedure until you have installed them all.
   

9. Next copy the .local backup passwd file to the active version:
   

     melonie.mit.edu# cp /etc/passwd.local /etc/passwd
   

   This step is needed because whenever your machine reactivates, /etc/passwd.local replaces /etc/passwd, the active version. If you had changed only /etc/passwd.local, your changes would not take effect until the next time your machine reactivated. Note that anyone who was currently logged in would have an entry in /etc/passwd, which would be eliminated when you do this cp command, which could have odd effects for them. That's one reason it's important to make sure that no one else is logged in during this process. (See Who Else is Logged In?)

Guidelines for Editing the passwd File

• The root entry should be the first line.
  
• There should be no empty lines.
  
• There should be no duplicate usernames.
  
• Remeber that changes to /etc/passwd are temporary; it is replaced by /etc/passwd.local at every reactivation or reboot.
  
• Use line return only at the end of each line. Do not use line return within an entry: each entry should be a single line.
  
• A long entry may appear to "line-wrap". That's okay.
  

Giving Users Remote Access

Using mkserv to Add Services

About mkserv

Of the more than 20 services that mkserv can create, most are used only by Athena operations staff. This document covers the remote access services (including telnet, ssh, and ftp) and the file server knfs.

Note: It is against Athena Rules of Use to perform these mkserv modifications on any public Athena workstation; it is intended for use only by private Athena workstation owners or private Athena cluster managers.

Note: It may take as long as 15 minutes or more for mkserv to run on the SGI. Do not stop mkserv in the middle of adding a service, be patient, adding some services just takes time on an SGI. Stopping the process could cause damage to your machine and should not be attempted.

Preparations for mkserv

  melonie.mit.edu# cat /var/server/.services
  remote 1.14

Before using mkserv for the first time, be sure that:

• the root password has been changed from the public default. (See Changing the Root Password.)
  
• the variable PUBLIC is set to false in the file /etc/athena/rc.conf. (See Set PUBLIC=false.)
  

• you must become root, and
  
• make sure that no one else is logged in (See Becoming Superuser.)
  

Using mkserv

  mkserv [-v] [ -service... ] [ service...]

For convenience, there are three special purpose services. They are:

• mkserv clean. Remove all previously specified services from a workstation.
  
• mkserv public. Remove all previously specified services from a workstation and change the PUBLIC variable in /etc/athena/rc.conf to true. Upon a reboot, the standard cleanup procedure in the workstation boot sequence detects that the machine is a public workstation and resets any changes in the configuration files.
  
• mkserv update. Ensure that all the binaries and configuration files match what is expected from the current Athena release.
  

Obtaining a srvtab or keytab

You can run the mkserv command before you have installed the srvtab, but you cannot use the service until it is installed.

To get a srvtab, fill out the servtab request form, and request a srvtab for your workstation. They will need to know your username, the machine name, and the type of service:

• For remote access, ask for an `rcmd' srvtab.
  
• For a fileserver, request an `rvdsrv' srvtab.
  
• If you already have one type and are requesting the other, be sure to tell them. They may give you special instructions for appending the new srvtab to your existing one, or they may tell you to replace the old one with the new.
  

As root, copy the srvtab from the specified location into /etc/athena/srvtab. (Some srvtab might belong in a different directory; the specific directory will be in the directions from the Accounts Consultants.)

Change the owner of the srvtab file to "root."

  melonie.mit.edu# cd /etc/athena
  melonie.mit.edu# chown root /etc/athena/srvtab

  melonie.mit.edu# chmod 400 /etc/athena/srvtab

  melonie.mit.edu# /usr/athena/bin/ksrvutil change -f
  /etc/athena/srvtab
  Principal: rcmd.melonie@ATHENA.MIT.EDU; version 1 
  Changing to version 2.
  Key changed.
  Old keyfile in /etc/athena/srvtab.old.

You can also create a Kerberos 5 keytab so your machine can accept Kerberos 5 connections. To create the keytab from the srvtab, type:

  melonie.mit.edu# /usr/athena/etc/ktutil
  ktutil: rst /etc/athena/srvtab
  ktutil: wkt /etc/krb5.keytab
  ktutil: exit

Using mkserv remote to Allow Remote Logins

When you run mkserv remote,

  melonie.mit.edu# mkserv remote
  Running /mit/mkserv/services/8.2/remote.add (1.14)

  Do you wish to restrict remote access to only those in /etc/passwd
  [no] ==>
  Do you wish to restrict all login access, remote and local, to only
  those in /etc/passwd [no] ==>
  Do you wish to allow users to use access_off to turn off remote
  access? [no] ==>
  Do you wish to require encrypted passwords on remote connections?
  [yes] ==>

The third question controls a privilege users are sometimes given. The fourth affects a network security option.

Finishing mkserv remote

  Do you wish to allow users to use access_off to turn off remote
  access? [no] ==>

The option works by setting the variable ACCESSON=true in /etc/athena/rc.conf. Once this is set, any user can give the command access_off, which prevents other users from logging in. (It won't affect users who are already logged in.) Any logged-in user can turn remote access back on with access_on, otherwise the exclusion remains in effect until everyone logs out and the machine does a full reactivation.

When accesson=false, access_off and access_on have no effect.

The pros and cons of this option should be weighed by each workstation owner, or discussed by the appropriate department or group.

The fourth question:

  Do you wish to require encrypted passwords on remote connections?
  [yes] ==>

At this point, mkserv remote finishes running...

  ssh host key already exists.
  Re-pointing root symlinks before synctree...
  Updating /var/server
  Updating root symlinks...
  ===> Remember to change the root password, if you have not
  already done so.
  Update finished.
  The service change requests will take effect upon the next reboot
  of the machine.
  /var/server has been used for the server specific files.
  Do not modify these files as they can be replaced during an update.
  melonie.mit.edu#

Keeping Unwanted Users Out

There are a significant number of users on Athena and non-Athena systems who probe around for remotely-accessible workstations to use when the dialup machines are overloaded. These people may think they are just using "spare" cycles, but in fact, their memory and other resource usage can cause demanding programs to freeze up and ruin the work of the legitimate users on the machine. Keeping such people off of your workstation is simply a matter of finding out who they are and excluding them.

Use the last program to find the list of recent users. For example, to see today's last three logins:

  athena% last -3
  cmonster   pts/4  melonie.mit.edu  Fri Jun  2    13:29
  still logged in
  elves      ttyp0  :0.0             Fri Jun  2    10:07 - 17:52
  (07:45)
  doughboy   pts/0  MACE.LCS.MIT.EDU Fri Jun  2    09:30 - 12:16
  (02:46)

The logfiles last uses are /var/adm/wtmpx on Sun workstations and /var/log/wtmp on Linux. As of Athena release 8.2, the logfiles are rolled by date: wtmpx is the current one, wtmpx.0 the one previous, et cetera, with wtmpx.10 the oldest. You can list the logfiles to see which one contains information for a particular day, and then point last to that file:

  athena% ls -ltr /var/adm/wtmpx*
  -rw-r--r--   1 root     other	     1488 Dec  5 16:50
  /var/adm/wtmpx.10
  -rw-r--r--   1 root     other	     2604 Dec  6 22:42
  /var/adm/wtmpx.9
  -rw-r--r--   1 root     other	    13764 Dec  7 22:16
  /var/adm/wtmpx.8
  -rw-r--r--   1 root     other	     1488 Dec  8 00:54
  /var/adm/wtmpx.7
  -rw-r--r--   1 root     other	     2976 Dec  9 20:55
  /var/adm/wtmpx.6
  -rw-r--r--   1 root     other	     2232 Dec 10 18:29
  /var/adm/wtmpx.5
  -rw-r--r--   1 root     other	     4836 Dec 11 10:47
  /var/adm/wtmpx.4
  -rw-r--r--   1 root     other	        0 Dec 12 03:32
  /var/adm/wtmpx.3
  -rw-r--r--   1 root     other	        0 Dec 13 03:32
  /var/adm/wtmpx.2
  -rw-r--r--   1 root     other	     2604 Dec 14 18:13
  /var/adm/wtmpx.1
  -rw-r--r--   1 root     other	     2232 Dec 15 18:19
  /var/adm/wtmpx.0
  -rw-r--r--   1 root     other	     1116 Dec 16 11:32 /var/adm/wtmpx

  athena% last -f /var/adm/wtmpx.8
  joeuser   ttyp0       :0.0              Mon Dec  7 16:50 - 22:16
  (05:25)
  reboot    system boot                   Mon Dec  7 16:40
  joeuser   ttyp0       :0.0              Mon Dec  7 16:28 - down
  (00:12)
  reboot    system boot                   Mon Dec  7 16:26
  joeuser   ttyp0       :0.0              Mon Dec  7 16:04 - 16:25
  (00:21)
  joeuser   ttyp0       :0.0              Mon Dec  7 15:56 - 16:03
  (00:07)
  reboot    system boot                   Mon Dec  7 15:53
  joeuser   ttyp0       :0.0              Mon Dec  7 12:07 - down
  (03:45)

  athena% foreach log (/var/adm/wtmpx*)
  foreach? last -f $log
  foreach? end

Setting up Applications Enabled by mkserv remote

Your workstation can receive secure telnet connections using Athena's Kerberized telnetd. This allows users to connect from another machine without sending their password over the net in the clear. To enable this secure feature, contact accounts@mit.edu and request a rcmd.host srvtab (substituting your machine name for host).

Once you obtain and install the srvtab file (see Obtaining a srvtab or keytab), you can reboot and test telnet; try to connect as permitted and non-permitted users.

ssh

After you run mkserv remote, sshd will be in place; you won't need to do anything else to serve ssh connections.

ftp

The file /etc/shells contains a list of the shell programs that your workstation will accept for ftp connections. (A shell is the program that provides your athena% prompt, interprets your commands and passes them along to the operating system.) An ftp user who uses a non-standard shell will be refused connection.

You can find out which shell a user is running from their hesiod information:

  hesinfo username passwd

  athena% hesinfo gscout passwd
  gscout:*:29998:101:Girl Scouts of America,,W20-105,5550733,
  :/mit/gscout:/afs/sipb/project/tcsh/tcsh

If a user's chosen shell is not listed in /etc/shells, you can:

• add their shell to the list in /etc/shells, or
  
• change /etc/passwd.local: edit the user's entry or add one, specifying a standard shell. (If you choose this option, see Creating Local Accounts for Athena Users for an example of adding a user's entry to this file.)
  

Anonymous ftp

Anonymous ftp allows any internet user to access certain directories on your workstation. When this is enabled, the ftp server will accept the username anonymous with any password (by convention, users should give their own hostname or username@hostname as a password.)

This can be a useful way of providing public access to some of your files, but it entails greater security risks to your machine, the files on it, and possibly even to the other machines in your cluster and to other Athena users. It is your responsibility to understand the risks involved, and to take the appropriate steps to maintain a high level of security. Allowing anonymous ftp also may also greatly increase net traffic and the load on your workstation.

The file /etc/ftpusers contains a list of usernames, one per line, that ftp will reject (for instance, root -- no one should ever be allowed to ftp into your workstation as root!). To enable anonymous ftp, edit that file to remove the entry for anonymous. Then you will need to do the following as root:

melonie.mit.edu# mknod /var/local/ftp/dev/zero c 13 12
melonie.mit.edu# chmod 666 /var/local/ftp/dev/zero

The directories and files to set up (as described in the man page for ftpd) are as follows:

* If you want to let others create directories and insert files into /var/local/ftp/pub set it to mode 777. Use mode 755 if you want to restrict other users to read-only access.

To set or change the ownership of a file or directory, use chown:

  chown owner file-or-directory

  chmod mode file-or-directory

As an example, the following will create the directory /var/local/ftp/etc, set its owner to root, and its permission mode to 555:

  melonie.mit.edu# cd /var/local/ftp
  melonie.mit.edu# mkdir etc
  melonie.mit.edu# chown root etc
  melonie.mit.edu# chmod 555

  melonie.mit.edu# where ls
  /usr/bin/ls

  melonie.mit.edu# cp /usr/bin/ls
  /var/local/ftp/bin/ls

In contrast, the files /var/local/ftp/etc/passwd and /var/local/ftp/etc/group should NOT be copies of the system's /etc/passwd or /etc/group files. Create dummy versions of these files, unwriteable and owned by root as shown above.

There is a CERT advisory Anonymous FTP Configuration Guidelines with more information about making anonymous ftp as secure as possible.

Running mkserv remote doesn't install the software you need to make your workstation an http server. Various on-line sites will let you download the necessary files and installation info. We recommend an MIT site, http://web.mit.edu/apache-ssl/www/. The apache-ssl locker contains software supported and recommended by the MIT Web Services group of MIT Information Systems for providing secure web servers, as well as contact information for advice and questions.

Creating an NFS Server: mkserv knfs

You may find it desirable to designate directories on your workstation as exportable filesystems. When you have done this:

• Remote users may attach that filesystem to their workstation to access files in it.
  
• You can backup your own filesystem.
  
• You can expand people's quotas and can have your own shareable lockers (i.e., to provide larger amounts of space for special projects).
  

What Kind of Fileserver is Best For You?

Most Athena lockers are stored on AFS fileservers, but running your own AFS server involves a great deal of managerial overhead. If you want to set your workstation up as a fileserver, it should be an NFS fileserver.

With NFS, you will have to maintain your own credentials file. For a small number of users, this is something you'll be able to handle on your own. However, if your proposed filesystem will be accessed by a large number of users, managing the necessary credentials files will create extra ongoing responsibility for you or your group. In this case, instead of setting up an NFS locker on your own workstation, you might find it preferable to ask the Faculty Liaisons (f_l@mit.edu) or Accounts (accounts@mit.edu) about getting an AFS locker on an Athena-administered server.

Running mkserv knfs

  thelonious.mit.edu# mkserv knfs

  Running /mit/mkserv/services/8.2/knfs.add (1.13)
  patching file `/usr/sbin/shutdown'

  Re-pointing root symlinks before synctree...
  Updating /var/server
  Updating root symlinks...
  Not linking /etc/athena/zshutdown_notify because the target was not
  a symlink.  Use -f to override.

  ===> Remember to get a srvtab with a 'rvdsrv.thelonious.mit.edu'
  key
  ===> Remember to set up a credentials file in /usr/etc
  ===> Remember to arrange the appropriate Moira entries for NFS
  service.

  Update finished.

  The service change requests will take effect upon the next reboot
  of the machine.

  /var/server has been used for the server specific files.
  Do not modify these files as they can be replaced during an update.

1. Contact accounts@mit.edu to request a srvtab for rvdsrv.host (substituting your machine name for host). When you receive it by e-mail, install it into /etc/athena/srvtab. (See Obtaining a srvtab or keytab for more details.)
   

2. If you want users to be able to use attach to get to lockers on your workstation, write to hesreq@mit.edu. You'll need to provide: hostname, partition (mount point), your chosen locker name, and whether the locker should be mounted read-only or read-write by default.
   

3. Set up a credentials file in /usr/etc. Or, if you will have a large number of users accessing the server, contact ops@mit.edu and ask them about registering your server to get the Athena credentials file on a regular basis. (See What Kind of Fileserver is Best For You? for alternatives.)
   

4. Add an entry to /etc/dfs/dfstab for each of the exported directories, e.g.:

     share -F nfs -o rw /var/proj
     share -F nfs -o ro /var/proj-ref
   

   For more about /etc/dfs/dfstab, see the discussion of Specifying nfs Access with dfstab.

5. Reboot the workstation.

  athena% /usr/sbin/showmount -e $host
  export list for melonie.mit.edu:
  /var (everyone)

Maintaining and Adding Hardware

Physical Security

Please note that if the equipment is not secured in an appropriate manner and if the equipment is stolen, your department is responsible for paying the $1000 insurance deductible.

Moving Your Athena Workstation

• Unlike most personal computers, which can easily tolerate power cycling, a workstation should have its operating system shut down via software prior to terminating the power ("powering down" the workstation).
  
• Moving a workstation from one network drop to another can cause that machine to fail to work and create disturbances that affect the entire MIT network.
  
• The Hardware Hotline staff needs to track the locations of the ever growing number of Athena workstations on campus in order to dispatch Field Service for repairsif they can't find the machines, they can't provide service.
  

If the move involves changing network drops (from one office to another or across a large room), see http://web.mit.edu/is/help/network/. You will need to provide the following information:

• on-site contact name and MIT phone number
  
• number of machines to be moved
  
• machine name(s)
  
• room number where machine(s) is now located
  
• room number where machine(s) will be relocated
  
• machine hardware type(s)
  
• type of network interface (UTP, AUI/thick, thin)
  
• machine name changes (if necessary)
  
• requested date of move
  

Environment Requirements

Climate

• The workstation should be away from heaters, photocopiers, and other sources of heat. It is also recommended that the workstation be protected against direct sunlight.
  
• Air should flow freely around your workstation. There should be at least 4 inches between the system vents and other objects. Similarly, there should be at least 4 inches between the monitor vents and other objects.
  
• Supplies (i.e., diskettes, tape cartridges, etc.) should be kept in an environment within the same temperature and humidity limits.
  

• Keep your work area as dust free as possible. For example, avoid installing the workstation near chalkboards.
  
• Athena policy forbids food and drink in public clusters. You have more discretion in your private workspace, but please keep in mind that no one is immune to causing spills and dropping crumbs, and take care to keep food and drink away from your workstation.
  

• Your workstation should be set up at least 30 inches from any source of electrical interference, such as other terminals or monitors, printers, electric pencil sharpeners, or other hardware that causes electromagnetic radiation (in or near labs).
  
• In order to reduce your workstation's exposure to static electricity and magnetized objects, it is recommended that your workstation be located away from high traffic areas (e.g., busy corridors) and away from filing cabinets and steel beams in walls.
  

There are several guidelines for setting up your environment to reduce strain and prevent injury. Please refer to the document Repetitive Strain Injuries (IS-13 -- To request a copy, send e-mail to sendpubs@mit.edu or call 253-5150; to read it online, open URL http://web.mit.edu/is/pubs/is-13 from a Web browser).

Configuring External Devices

Each SCSI device should have two connector jacks: one to connect to your workstation (or previous device in the chain) and another to allow a further device to link to it. The last device in the chain should have a SCSI terminator in its second connector. If you need to get a terminator, we recommend the slightly more expensive "force perfect terminator" version ("FPT").

The maximum length of a SCSI chain is 6 meters (18 feet). This is the standard length specified by the protocol, but vendors may have restrictions which limit the SCSI chain to less than 6 meters. To calculate the maximum length of external devices, be sure to include the length of the internal SCSI bus. If the length of the SCSI chain exceeds the maximum, you could lose data or have intermittent device problems.

An online copy of the Indy Workstation Owner's Guide can be found here, as can the O2 Hardware Reference Guide

Special note for Sun Ultras

Finding the SCSI ID codes (Sun)

Before you add a new device, you need to know which SCSI IDs are already in use. To determine the IDs of the SCSI devices, follow these steps:

Shut down the machine (Shutting Down Your Workstation), then type probe-scsi at the ok prompt:

  ok probe-scsi
  Target 3
    Unit 0  Disk  CONNER  CP30548  SUN0535B0CD9404PGPJ
  Target 6
    Unit 0  Removable  Read Only device  TOSHIBA
  XM-4101TASUNSLCD108404/18/94

This command gives a list of devices connected on the SCSI bus. Each separate SCSI ID number is listed after the word Target, followed by a description on the next line. In this case, the hard disk drive has SCSI ID 3 (Target 3), and the CD-ROM has ID 6 (Target 6).

Check the owner's manual for a device to set the SCSI ID for that device.

Creating the Device Files

• shut down and power off the machine and devices
  
• connect the devices to the SCSI chain
  
• power the machine and the devices on
  
• as the machine starts booting, hold the Stop key and type a
  
• type boot -r at the ok prompt
  

Preparing a New Hard Disk Drive (for Suns)

1. partition the blank disk
   
2. create a file system on it
   
3. make a file directory ("mount point") for it
   
4. edit some files that help manage attached devices

Partition the Disk

  melonie.mit.edu# format
  Searching for disks...done
  AVAILABLE DISK SELECTIONS:
         0. c0t0d0 <SEAGATE-ST42400N-0119 cyl 2604 alt 2 hd 19 sec 84>
            /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0
         1. c0t3d0 <SUN2.1G cyl 2733 alt 2 hd 19 sec 80>
            /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@3,0

c? = SCSI controller -- which SCSI chain
? = SCSI ID or "target" -- which device in the chain
d? = local unit number (For a disk drive this will be 0. In the case of a stacking CD-ROM device, each disk would have its own number.)

In this example, we want to partition the new Seagate drive at c0t0d0, listed as choice "0".

  Specify disk (enter its number): 0
  selecting c0t0d0

  FORMAT MENU:
          disk       - select a disk
          type       - select (define) a disk type
          partition  - select (define) a partition table
          current    - describe the current disk
          format     - format and analyze the disk
          repair     - repair a defective sector
          label      - write label to the disk
          analyze    - surface analysis
          defect     - defect list management
          backup     - search for backup labels
          verify     - read and display labels
          save       - save new disk/partition definitions
          inquiry    - show vendor, product and revision
          volname    - set 8-character volume name
          !<cmd>     - execute <cmd>, then return
          quit

  format> part
  PARTITION MENU:
          0      - change `0' partition
          1      - change `1' partition
          2      - change `2' partition
          3      - change `3' partition
          4      - change `4' partition
          5      - change `5' partition
          6      - change `6' partition
          7      - change `7' partition
          select - select a predefined table
          modify - modify a predefined partition table
          name   - name the current table
          print  - display the current table
          label  - write partition map and label to the disk
          !<cmd> - execute <cmd>, then return
          quit
  partition> modify

  Select partitioning base:
          0. Current partition table (original)
          1. All Free Hog
  Choose base (enter number) [0]? 1

  Part       Tag    Flag     Cylinders        Size            Blocks  
    0        root    wm       0               0         (0/0/0)
    0  
    1        swap    wu       0               0         (0/0/0)
    0  
    2      backup    wu       0 - 2603        1.98GB    (2604/0/0)
    4155984  
    3  unassigned    wm       0               0         (0/0/0)
    0  
    4  unassigned    wm       0               0         (0/0/0)
    0  
    5  unassigned    wm       0               0         (0/0/0)
    0  
    6         usr    wm       0               0         (0/0/0)
    0  
    7  unassigned    wm       0               0         (0/0/0)
    0

  Do you wish to continue creating a new partition
  table based on above table[yes]? [ret]
  Free Hog partition[6]? [ret]
  Enter size of partition `0' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]
  Enter size of partition `1' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]
  Enter size of partition `3' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]
  Enter size of partition `4' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]
  Enter size of partition `5' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]
  Enter size of partition `7' [0b, 0c, 0.00mb, 0.00gb]:
  [ret]

  Part       Tag    Flag     Cylinders        Size            Blocks  
    0        root    wm       0               0         (0/0/0)
  0  
    1        swap    wu       0               0         (0/0/0)
  0  
    2      backup    wu       0 - 2603        1.98GB    (2604/0/0)
  4155984  
    3  unassigned    wm       0               0         (0/0/0)
  0  
    4  unassigned    wm       0               0         (0/0/0)
  0  
    5  unassigned    wm       0               0         (0/0/0)
  0  
    6         usr    wm       0 - 2603        1.98GB    (2604/0/0)
  4155984  
    7  unassigned    wm       0               0         (0/0/0)
  0
  Okay to make this the current partition table[yes]?
  [ret]

Next, the partition table needs a name; "original" is often used. After that, you are finished with the partition sub-menu.

  Enter table name (remember quotes):
  "original"
  Ready to label disk, continue? yes
  partition> q

    [the FORMAT MENU is redisplayed]

  format> verify
  Primary label contents:
  Volume name = <        >
  ascii name  = <SEAGATE-ST42400N-0119 cyl 2604 alt 2 hd 19 sec
  84>
  pcyl        = 2606
  ncyl        = 2604
  acyl        = 2
  nhead       = 19
  nsect       = 84
  Part      Tag  Flag     Cylinders        Size          Blocks
    0       root  wm       0               0       (0/0/0)          0
    1       swap  wu       0               0       (0/0/0)          0
    2     backup  wu       0 - 2603        1.98GB  (2604/0/0) 4155984
    3 unassigned  wm       0               0       (0/0/0)          0
    4 unassigned  wm       0               0       (0/0/0)          0
    5 unassigned  wm       0               0       (0/0/0)          0
    6        usr  wm       0 - 2603        1.98GB  (2604/0/0) 4155984
    7 unassigned  wm       0               0       (0/0/0)          0
  format> q
  melonie.mit.edu#

Create a File System

  melonie.mit.edu# newfs /dev/dsk/c0t0d0s6
  newfs: construct a new file system /dev/rdsk/c0t0d0s6: (y/n)?
  y
  /dev/rdsk/c0t0d0s6:     4155984 sectors in 2604 cylinders of 19
  tracks, 84 sectors
          2029.3MB in 82 cyl groups (32 c/g, 24.94MB/g, 6208 i/g)
  super-block backups (for fsck -F ufs -o b=#) at:
   32, 51200, 102368, 153536, 204704, 255872, 307040, 358208, 409376,
  460544,
   511712, 562880, 614048, 665216, 716384, 767552, 818720, 869888,
  921056,
   972224, 1023392, 1074560, 1125728, 1176896, 1228064, 1279232,
  1330400,
   1381568, 1432736, 1483904, 1535072, 1586240, 1634336, 1685504,
  1736672,
   1787840, 1839008, 1890176, 1941344, 1992512, 2043680, 2094848,
  2146016,
   2197184, 2248352, 2299520, 2350688, 2401856, 2453024, 2504192,
  2555360,
   2606528, 2657696, 2708864, 2760032, 2811200, 2862368, 2913536,
  2964704,
   3015872, 3067040, 3118208, 3169376, 3220544, 3268640, 3319808,
  3370976,
   3422144, 3473312, 3524480, 3575648, 3626816, 3677984, 3729152,
  3780320,
   3831488, 3882656, 3933824, 3984992, 4036160, 4087328, 4138496,

Name Your Mount Point

  melonie.mit.edu# ls /

  melonie.mit.edu# mkdir /u00

  melonie.mit.edu# /etc/fsck /dev/rdsk/c0t0d0s6
  ** /dev/rdsk/c0t0d0s6
  ** Last Mounted on
  ** Phase 1 - Check Blocks and Sizes
  ** Phase 2 - Check Pathnames
  ** Phase 3 - Check Connectivity
  ** Phase 4 - Check Reference Counts
  ** Phase 5 - Check Cyl groups
  2 files, 9 used, 2013021 free (13 frags, 251626 blocks,  0.0%
  fragmentation)

Table Entries

Mapping the mount point with vfstab

The file /etc/vfstab maps the device to the mount point. Use your favorite text editor to add a line with that information. In this case, the added last line identifies the device /dev/dsk/c0t0d0s6 with the directory /u00.

  #device            device              mount          FS    fsck
  mount    mount
  #to mount          to fsck             point          type  pass  at
  boot  options
  #
  /proc              -                   /proc          proc  -     no
  -
  fd                 -                   /dev/fd        fd    -     no
  -
  /dev/dsk/c0t3d0s0  /dev/rdsk/c0t3d0s0  /              ufs   1     no
  -
  /dev/dsk/c0t3d0s6  /dev/rdsk/c0t3d0s6  /var           ufs   2     no
  -
  /dev/dsk/c0t3d0s5  /dev/rdsk/c0t3d0s5  /usr           ufs   3     no
  -
  /dev/dsk/c0t3d0s3  /dev/rdsk/c0t3d0s3  /var/usr/vice  ufs   5
  yes      -
  /dev/dsk/c0t3d0s1  -                   -              swap  -     no
  -
  /dev/dsk/c0t0d0s6  /dev/rdsk/c0t0d0s6  /u00           ufs   2
  yes      -

The file also sets things up so that fsck will run each time you reboot, to make sure the filesystem on the disk is okay. The vfstab man page contains more information about this file and its fields.

Specifying nfs Access With dfstab

If your new disk directory is going to be accessible through NFS (see Creating an NFS Server: mkserv knfs), then you need to add a line to the end of the file /etc/dfs/dfstab as well. Here is a version of the file with the appropriate last line for our example.

  #       place share(1M) commands here for automatic execution
  #       on entering init state 3.
  #
  #       share [-F fstype] [ -o options] [-d
  "<text>"] <pathname> [resource]
  #       .e.g,
  #       share  -F nfs  -o rw=engineering  -d "home dirs"
  /export/home2
  share -F nfs -o rw /u00

• the -F option takes a file-system type as its argument,
  
• the -o option indicates access (read-write, read-only, etc.), and
  
• the final argument is the resource's pathname.
  

Monitor Configuration on Linux Workstations

If at some point you want to use a different monitor, you'll also have to re-run this configuration step.

To run the configurator, you'll need to get a console login as root. At the xlogin screen (with the password box, and Athena logo), hit Ctrl-p until you get a text-mode login prompt, and login as root here.

Note that if Xwindows was never running on this machine, you may need to start the X Font Server before you can run the Xwindows configuration program. First, check if the server is already running like this:

bash# /sbin/service xfs status

bash# /sinb/service xfs start

Starting xfs:                           [OK]

Enabling Multi-Processor Support on Linux Workstations

To enable SMP, you will need to install an appropriate kernel. It must match the kernel you have already, in version, and you'll need to figure out the RedHat version to find the new one.

  bash-2.05a# rpm -q kernel
  kernel-2.4.18-10
  bash-2.05a# uname -a
  Linux red-herring.mit.edu 2.4.18-10 #1 Wed Aug 7 11:39:21 EDT 2002 i686 unknown
  bash-2.05a# cat /etc/redhat-release
  Red Hat Linux release 7.3 (Valhalla)

  /afs/athena/system/rhlinux/redhat-7.3-updates/RPMS/kernel-smp-2.4.18-10.i686.rpm

  /afs/athena/system/rhlinux/redhat-7.3/RedHat/RPMS/kernel-smp-2.4.18-10.i686.rpm

Once you have found the appropriate file, you will need to become root, with su, then install it by running:

  bash-2.05a# rpm -ivh /afs/athena/system/rhlinux/redhat-7.3-updates/RPMS/kernel-smp-2.4.18-10.i686.rpm
  Preparing...                ########################################### [100%]
     1:kernel-smp             ########################################### [100%]

Using a UPS to Prevent Hardware Problems

About UPSs

• An off-line UPS sits in parallel with your computer's line power. If the power fails, an off-line UPS switches on and supplies power to your computer.
  
• An on-line UPS sits in series with your line power. It is always working and does not need to switch on.
  

Characteristics of the UPS

WARNING: To test a UPS, DO NOT JUST UNPLUG IT FROM THE WALL. Unplugging the UPS from the wall breaks the connection to ground, and can cause a situation called a floating ground which can create a high voltage discharge when you plug the system back in (depending on how far the UPS ground is from the wall outlet ground). You could get a very nasty shock when you plug it back in. The easiest and safest way to test a UPS is plug it into a power strip and then plug that into the wall. You can then use the power switch on the power strip to simulate a power failure without loss of continuity to the ground.

Additional UPS Suggestions

Here are some other suggestions for using your UPS:

• Test the UPS occasionally to make sure the batteries are charging.
  
• Most UPSs are not designed to supply power during long power failures; they are designed to let you get past a power dip, or give you enough time to shut the system down cleanly. If power is out for more than a few minutes, shut your system down before you run out of UPS power.
  
• There is a lot of variation among UPSs. Choose a UPS with capacities and features appropriate to your system needs.
  

Send a comment on this page.