Update 16 August 1994 by ccpaulh@monad.missouri.edu. Subject to change!
File: /LocalLibrary/Mizzou_Info/21_Procedures
This document was originally written for the MUEB cluster, it has been updated as the newer NeXT clusters were established.
Abstract: ªProceduresº introduces things one should know about the local MU ECE lab, how it is set up, what to do for ordinary operation & maintenance. If you have an immediate severe problem such as a down workstation, try the document ªTroubleShootingº in this same folder.
Contents:
Greg Johnson, 233 Heinkel Building, 882-2000, ccgreg@mizzou1.missouri.edu
Mahtaj Khamneian, Heinkel Building, 882-2000, ccmahtaj@mizzou1.missouri.edu
Paul Bohnencamp, Heinkel Building, 882-2000, ccpablo@mizzou1.missouri.edu
Mike Grannan, 314-542-3164; 314-542-3048 Fax, Mike_Grannan@next.com
NeXT, Inc, 111 West Port Plaza, Suite 600, St. Louis, MO 63146
RTFM!
Familiarize yourself with the documents in the folder /LocalLibrary/Mizzou_Info. These describe such things as access policies and system configuration.
Peruse the manuals that come with each NeXT:
The MU NeXT Users Group has a Listserv list, MUNUG. This is just getting started. It will accumulate questions and information of interest to MU NeXT users.
Usenet Network News hosts several discussion groups dealing with NeXT:
Ypu can also access these groups using /PublicApps/NewsGrazer. When you first start it up it won't know which news server to point at. Tell it to point at golf.ustores.edu.
The mizzou1/MIZZOU1 tape CC0321 contains the accumulated exchanges of comp.sys.next and subgroups, from its beginning in October 1988. To access this, enter the CMS command
vmtape mount cc0321 dsn next-l
The first file contains further information. To get it use: tapeos get (file 1
There is a list for NeXT Managers. FTP to stolaf.edu (130.71.128.8) in /pub/next-managers.
Campus Computing is an official NeXT Service Center. Repair Services has facilities to service NeXTs. Report defective equipment to Campus Computing Repair Services or to Greg Johnson. Greg has service equipment, service manuals, and procedures to deal with NeXT, Inc. The usual service technique is to take a working system and swap parts to identify the faulty component. Then we phone NeXT to obtain a "Service Request Order"; they ship a replacement part and we return the defective part.
There are special grounding straps and anti-static procedures to observe when working inside most computer devices, NeXT workstations in particular. Damage from static discharge often may not become apparent immediately. Don't mess with the insides if you don't have the proper equipment and training.
Old carpenter's rule: ªMeasure twice, saw once.º
Try whenever possible to manage files and other things from your own userid via appropriate permissions. If necessary su from your own id. Use root only as a last resort. Back up the original or working version before implementing a new version.
Powering off and powering on: All workstations are to be left on, unless there is advance knowledge that power will be cut off. The Power key is disabled for this reason. Pressing the Power key and then the Power Off button will merely logoff the user unless the user is root. To power off a workstation if the Power key has been disabled, press Command-~ (~ is in the upper left of the keypad). If a workstation is shut off or rebooted when files are open, the system will do a "fsck", checking the disk for possible discrepencies, and correcting minor ones. This takes a minute for the 105MB stations, six times as long for the 660MB server.
Booting a workstation: When a workstation comes up, it checks its own system first then looks for the network. If the network is not found, the workstation will show "localhost" on the login panel, instead of "muebnx--". If other workstations are functioning, check the physical ethernet with ªpingerº (described below) and try rebooting.
"No response from network configuration server":
You may see this message at boot time:
No response from network configuration server.
Type 'c' to start up computer without a network connection.
Do NOT type c!
Instead, wait. The system has tried to request NetInfo information from the server but got no immediate response. This message could even come on the server. The server may just be very busy with other requests. If the physical connection is solid, then eventually the server should respond to the request and the boot process will continue. So, usually don't type "c". While you wait, inspect the ethernet connection. Make sure the ethernet cable is not crimped. See if the server is up and functioning. If you do type "c", the system will come up without a network connection and the only IDs that can use it are the maintenance accounts root & me.
Debugging faulty ethernet connections: Ethernet cable must not be bent sharper than about a six-inch radius. Ethernet is a bus network, and is terminated by a resistor "terminator" at each end of the network. Each station must be connected via a T-connector, not plugged directly in. If either of the two terminators is off, or there is any gap at any point in the cable, then all network communication will fail.
To locate a faulty point in the cable, divide the network into smaller sets by moving the terminators. Use the "ping" command to quickly determine when the network is functioning.
The workstation hostnames are mostly consistent with their IP numbers. To see the correspondence issue the command "nidump bootptab /". It goes like this currently:
Any device that uses ethernet is manufactured with a unique Ethernet address. NetInfo keeps track of Ethernet ID's it has seen, and matches them with IP numbers and hostnames. If a new workstation is added to the network, NetInfo will increment to the next IP address and simply prompt for hostname to be assigned to the new system. This is all described in the NeXT Network and System Administration manual
There are several levels of security for the NeXT lab:
Hardware Password: Each workstation has an eprom-coded hardware password. It is possible to change this via the ROM monitor "P" command as described in the NeXT Network and System Administration manual, but you either need to know the existing one or must take apart the workstation and short certain pins on a certain chip. This protection prevents a user from taking over a workstation. In order to boot from any device except the standard one with the standard paramenters, you've got to have that hardware password.
Workstation local superuser accounts: Each workstation has a standard Unix "root" account. Also, account "me" is a member of the wheel group, which allows it to do almost as much as root can; it can su to root if that's not enough. Logging on a client workstation as root or me allows write access to all files stored on that workstation's disk.
Network superuser: The network has its own root account and password. You need this when adding or modifying network accounts, or when adding a new workstation to the network.
Alternate superusers: Rather than sharing the root account and its password, those users who are to be allowed root access are granted a special account with its own password, which has user number 0 and is thus equivalent to root.
Special groups: A userid may be associated with one or more groups. Each disk file has a group associated with it, and access permissions associated with that group. By convention, the group ªwheelº has access to most of the files that root can access. The group ªstaffccº gives access to Campus Computing staff. Other groups such as ªmath175º allow multiple users such as the graders in a course to access files while preventing other users from accessing them. Only the root user can establish groups.
Exported file systems: The server has two disk partitions, sd0a and sd0b. sd0a is the root partition and is primarily for system files such as /bin, /LocalAps, /NextApps, etc. sd0b is mounted on the root partition as /Users/1. It contains user home directories. Both partitions are exported read-write to just the stations in the lab, and read-only to others (in case we're ever hooked to a network). Standard Unix file permissions apply across this network. See file /etc/exports and the ªmountsº entry in NetInfo for each workstation.
All user accounts on the NeXT system should be network accounts, so that users can utilize any NeXT workstation (including the server head) for login. The exception is the ªmeº and ªrootº accounts associated with each individual NeXT workstation. These are local accounts that are shipped with the NeXT. They are to be used only for system maintenance, and not to be made available to any user.
Default groups should be assigned from the following:
These are set up much as for mizzou1/MIZZOU1. Instructors can designate courses as using the NeXT lab, and registration information can be used to determine what students are in each of these courses. This information consists of student number, name, and date of birth. Currently, Greg Johnson extracts this and transfers it to the NeXT. Use /usr/local/etc/nubatch to add such batches of users.
root can invoke the command: nustu
to add a new student user. They cannot modify or delete existing users. The command: stulist nnnnnn...
given the six-digit student number(s) will list enrollment information and any system info for the correspongin user.
The UserManager application in /NextApps, or the ªnuº command may be used by root users to add individual userids. The nu command is easier and less prone to wrong selections than the GUI menu! Here is the procedure for the UserManager menu:
At this time we have no proper backup mechanism. Instead, we are exploiting the few megabytes of extra space on each of the NextStations to back up locally-modified files stored on the Server.
No specific assignments of server directories to backups have yet been assigned. Let's start keeping a record here as we learn what needs to be done.
To keep these backup files from confusing users, make them hidden files (see file .hidden) or start their names with a period. This could be automated through cron.
If we want to save space in the backup, use tar and compress. For example, logon a NextStation as the ªmeº user for that station. This allows you to put files on the station's root directory.
tar -cvf /.LocalApps.backup /LocalApps
compress /.LocalApps.backup
File /LocalLibrary/Misc/Announcements.current links to file /usr/local/etc/Announcements.current . When modifying the Announcements, make sure that file has universal read permissions. If users can't read it, then no one's login (except root) will be accepted! Append old announcements to file `Announcements.old' in this same directory.