Download Administrative Advice for UNIX

Administrative Advice for UNIX
R. C. Haight
The material presented here is based on the author’s experiences and opinions. Nevertheless, it
may prove useful. The material on phototypesetting was contributed by D. W. Smith.
1. ADMINISTRATOR’S ROAD MAP
Getting started as a UNIX† system administrator is hard work. There are no real shortcuts to a
working knowledge of the system. You will need time for reading, study and hands-on
experimenting. Don’t commit yourself to ‘‘going live’’ with your system until you have had two
weeks to teach yourself your job, and get the initial hardware quirks ironed-out.
Don’t consign the Setting Up UNIX document to oblivion after your initial system ‘‘gen’’. In
addition to needing it again whenever you add/change equipment, you will find that it contains
valuable material about system tuning (buffers, clist s, etc.) that appears nowhere else.
As an administrator, you should be familiar with a lot of the distributed documentation. The
Internals, Operations, and Administration papers from Documents for UNIX should all be studied,
as well as the Introduction, How to Get Started , and most of the entries of the UNIX User’s
Manual. In that manual, you should pay special attention to: acct ∗(1M), chmod (1), chown(1),
config(1M), cpio(1), date(1), df (1), du(1), ed (1), env (1), find (1), fsck (1M), kill (1), mail (1),
mkdir (1), mkfs(1M), ncheck (1M), ps(1), rm(1), rmdir (1), shutdown(1M), stty(1), su(1),
sync(1M), time(1), volcopy(1M), wall (1M), who(1), and write(1) in Section 1; all of Section 4;
acct (5) in Section 5; and crash(8) and vaxops(8) in Section 8.
2. SYSTEM CAPACITY
The figures below are approximations based on our experience over several years:
Hardware Configuration
PDP-11/23; 256K-byte memory; 2 RL01 disks*
PDP-11/34; 256K-byte memory with cache;
2 RL01 disks*
PDP-11/45; 248K-byte memory; RP03 disk*
Above with RP06 (RP04, RP05) disk*
Above with memory cache
PDP-11/70; 512K-byte memory;
RP06 (RP04, RP05) disks*
(2 or more drives)
Above with 768K-byte memory and
a disk drive (or fixed-head disk)
set aside for the root file system
VAX-11/780; 1M-byte memory;
at least 3 RP06 disks*
* Or equivalent.
See Setting Up UNIX for the list of supported hardware options.
†
UNIX is a Trademark of Bell Laboratories.
Number of
Simultaneous
Users
4
8
16
20
25
32
40
48
2
Administrative Advice for UNIX
3. DISK FREE SPACE
Making files is easy under UNIX. It has been said that the only standard thing about all UNIX
systems is the message-of-the-day telling users to clean up their files. Administratively, both free
disk blocks and free inodes (UNIX talk for file headers) can be a problem. If the free inode count
falls below 100, the system spends most of its time rebuilding the free inode array. If a file system
runs out of space, the system prints ‘‘no-space’’ messages and does little else. To avoid problems,
the following start-of-day free counts should be maintained:
•
•
•
The file system containing /tmp (temporary files):
— 16-user system: 1,500 free blocks.
— 40-user system: 3,000 free blocks.
The file system containing /usr:
— 3,000 to 6,000 free blocks, depending on load.
Other user file systems:
— 6% to 10% free, depending on user habits (3,000 blocks minimum).
This brings up an associated problem: how big should file systems be? Our preference is to set
aside space on each drive for a copy of root/swap and use the rest of the pack for a single file
system. However, if you have user groups that fight over disk space, it may be better to split
them up arbitrarily (i.e., divide a pack into more than one file system). Warning: if you set up
different disk drives with differing cylinder partitions between file systems, it will probably lead to
an operations goof someday.
4. A VERY FEW WORDS ABOUT SYSTEM TUNING
•
•
•
•
•
As shipped, UNIX has no programs with the text-bit mode set (see chmod (1)). The top
contenders for the t -bit are nroff and troff followed (generally) by the larger phases of the C
compiler (including the assembler and loader). The t -bit is only meaningful with pure text
programs (ld (1) options -i or -n). Don’t overdo it, and keep t -bit programs in the root file
system.
File system reorganization (described below) can help throughput, but at the expense of
down time. If you do it when your users are all asleep, it can help.
If you use normal shutdown and filesave.u procedures, the file system check program
(fsck (1M), -S option) will help keep the disk free list in reasonable order.
Try to keep disk drive usage balanced. If you have over 20 users, the root file system (/bin,
/tmp, /etc, and swap) deserves a drive of its own.
If you have a noisy modem (poorly executed do-it-yourself null-modem) or a disconnected
modem cable, UNIX will spend a lot of CPU time trying to get it logged in. A random check
of systems uncovers a lot of this going on.
5. WHY YOU MUST HAVE A SPARE DISK DRIVE
•
•
Without a spare disk drive, the system will be down when a drive is down.
Without a spare drive, it is difficult to reorganize file systems or to restore user files.
6. DISK PACKS
•
•
Buy only fully ECC correctable packs and test them.
If a pack develops uncorrectable errors, recondition it, or get rid of it.
RP06 disk packs used with UNIX need not be totally error-free, but must be ‘‘flag-free’’. The term
flag-free means that there should be no unrecoverable ECC (Error Correcting Code) errors.
Technically, proper ECC handling can recover from 11-bit error bursts. However, we hear that the
length of bursts can grow as a pack ages. We recommend that no pack that has more than 8-bit
error bursts be accepted. For the PDP-11, the following explanation may help (paraphrased from
a DEC source).
In reading the formatter printout, ECC correctable errors are identified by the headings ‘‘DATA
Administrative Advice for UNIX
3
ERROR DURING WRITE CHECK.’’ Error-register values are printed below the message. The two
registers of interest are RPER1 and RPEC2. A RPER1 value of 1000000 indicates ECC (no other
bits on). The RPEC2 register describes the bit span of the error. For example, RPEC2=003774
means that there was an unacceptable 9-bit (binary 0000011111111100) error burst;
RPEC2=000240 is an acceptable 3-bit span (0000000010100000there may be zero bits mixed in).
If such acceptable errors account for all ‘‘unrecoverable’’ errors reported (and there aren’t too
many of them), then you have a flag-free pack.
On the VAX, even this scant information was not available, so we have written our own formatter
(it tells its tale in English); see rp6fmt (8). We plan to make this program available in the future
(along with other UNIX-oriented diagnostics) for the PDP-11 as well.
7. PROTECTING USER FILES
Users, especially inexperienced ones, occasionally remove their own files. Open files are sometimes
lost when the system crashes. Once in a great while, an entire file system will be destroyed
(picture a disk controller that goes bad and writes when it should read). Here is a suggested file
backup procedure:
•
•
•
Each day, copy all user file systems to backup packs. Keep these packs 3 to 5 days before
re-using them.
Once a week, copy each file system to tape. Keep weekly tapes for 8 weeks.
Keep bi-monthly tapes ‘‘forever’’ (they should be re-copied once a year).
The most recent weekly tapes should be kept off premises. The other tapes should be in a fireproof safe, if you can afford one.
When UNIX goes down, active files can get scrambled. Your users will not want to start the day
over every time your system fails. In addition to good backup, you must have file-system patching
expertise available (on-site or on-call). If you ever re-boot the system for general use without
checking out the file systems, terrible things will happen (we once had five duplicate entries on a
file-system free list−this ruined over 100 new files in just three days). Study fsck (1M) and
crash(8), as well as FSCK-The UNIX/TS File System Check Program.
8. UNIX FILE SYSTEM BACKUP PROGRAMS
The following backup programs are distributed:
•
•
•
Dump/restor : This is a familiar tape-based system that has been used for several years. Full
dumps are usually taken when the dump program warns that an incremental dump will run
to more than one reel.
Find/cpio: UNIX is distributed in cpio format. The -cpio option of the find command has
made it time-competitive with dump/restor . However, it does not produce a ‘‘perfect’’
restore from a full dump plus incremental dump (new and changed files are OK, but file
removal information is lost). Because of this, full dumps should be taken fairly often
(weekly/bi-weekly). Cpio is the only program listed here that makes system-independent
copies. It can be used to move files between various versions of UNIX/RT and UNIX, and
can be used in system conversion.
Volcopy: physical file system copying to disk or tape. For those who can afford a spare
drive, volcopy to disk provides convenient file restore and quick recovery from disk disasters
(remember the spare drive). Tape volcopy provides good long-term backup because the file
system can be read-in fairly quickly, mounted, and browsed over. Disk and tape volcopy are
generally used together for short- and long-term backup. Volcopy can also be used for full
dumps with either dump/restor or cpio/find .
The table below summarizes attributes of these programs. The file system size is 65,500 blocks in
all cases; times are in minutes; judgements are subjective.
4
Administrative Advice for UNIX
Full dump time
Incremental dump time
Full restore time
Incremental restore time
Ease of restoring:
one file
a directory
scattered files
full restore
Needs tape drive
Needs spare file system
(only when restoring)
Needs spare disk drive
(two CPUs can share)
Maintains pack/tape labels
Handles multi-reel tape
512 blocks per record
Interactive
(i.e., ties up console)
May require separate
ID space
dump/restor
40
6
40(?)
8
find/cpio
40
7
80
10
volcopy (disk)
2
−
2
−
volcopy (tape)
15
−
15
−
fair
poor
poor
fair
yes
fair
fair
poor
fair
yes
good
good
good
very good
no
fair
good
good
good
yes
no
no
−
yes
−
no
yes
1,10
−
no
yes
1,10
yes
yes
−
88
−
yes
yes
10
no(?)
yes
yes
yes
no
no
no*
no
* Blocks per record are cut to 22 without separate I/D space.
We strongly recommend the spare disk drive: as explained in Section 5 above, the speed and
convenience of volcopy are by no means the only advantage of a spare drive.
9. CONTROLLING DISK USAGE
If your UNIX system is a success, you will soon run out of disk space:
•
During the considerable delay before you can get more drives, you will need to control usage:
— Try to maintain the start-of-day counts recommended above. Watch usage during the
day by executing the df command regularly.
— The du(1) command should be executed (after hours) regularly (e.g., daily) and the
output kept (in an accessible file) for later comparison. In this way you can spot users
who are rapidly increasing their disk usage.
— The find (1) can be used to locate inactive (or large) files. Example:
find / −mtime +90 −atime +90 −print >somefile
•
•
records in ‘‘somefile’’ the names of files neither written nor accessed in the last 90 days.
Of course, this works best if you are super-user.
You will also have to balance usage between file systems. To do this you will have to move
user directories. Users should be taught to accept file system name changes (and to
program around them−preferably ahead of time). The user’s login directory name (available
in the shell variable HOME ) should be utilized to minimize path name dependencies. User
groups with more extensive file system structures should set up a shell variable to refer to
the file system name (e.g.: FS ).
The find (1) and cpio(1) commands can be used to move user directories and to manipulate
the file system tree. The following sequence is useful (it moves, via magnetic tape, the
directory trees userx and usery from file system filesys1 to file system filesys2 where,
presumably, more space is available):
Administrative Advice for UNIX
5
cd /filesys1
find userx usery −cpio /dev/rmt0
cd /filesys2
mkdir userx usery
chown userx userx
chown usery usery
cpio −idmB </dev/rmt0
#
Make sure new copy is OK
#
Change userx and usery login directories in the /etc/passwd file
rm −rf /filesys1/userx /filesys1/usery
When moving more than one user in this way:
— Keep users with common interests in the same file system (they may have linked files).
— Move groups of users who may have linked files with a single cpio (otherwise linked
files will be unlinked and duplicated).
10. REORGANIZING FILE SYSTEMS
The procedure for moving users described above can be expanded to provide a way to reorganize
whole file systems. Reorganization can improve system response time. This is particularly true of
the root file system (which must be reorganized with all other file systems unmounted) and /usr .
Unfortunately, reorganization of large file systems is slow.
11. KEEPING DIRECTORY FILES SMALL
Directories larger than 5K bytes (320 entries) are very inefficient because of file system
indirection. A UNIX user once complained that it took the system ten minutes to complete the
login process; it turned out that his login directory was 25K bytes long, and the login program
spent that time fruitlessly looking for a non-existent .profile file. A large /usr/mail or
/usr/spool/uucp directory can also really slow the system down. The following will ferret out such
directories:
find / −type d −size +10 −print
Removing files from directories does not make the directories get smaller (the empty directory
entries are available for reuse). The following will ‘‘compact’’ /usr/mail (or any other directory):
mv /usr/mail /usr/omail
mkdir /usr/mail
chmod 777 /usr/mail
cd /usr/omail
find . −print | cpio −plm . . /mail
cd . .
rm −rf omail
12. ADMINISTRATIVE USE OF ‘‘CRON’’
The program cron(1M) is useful in the administration of the system; it can be used to:
•
•
Turn off the programs in directory /usr/games during prime time.
Run programs off-hours:
— accounting;
— file system administration;
— long-running, user-written shell procedures (using the su(1) command), for example:
su − userx userx shell arg . . .
6
Administrative Advice for UNIX
13. WATCH OUT FOR FILES AND DIRECTORIES THAT GROW
•
•
Accounting files:
— /usr/adm/wtmplogin information;
— /usr/adm/pacct process accounting; gets big quickly.
Other files:
— /usr/lib/cronlogstatus log of commands executed by cron(1M);
— /usr/spool spooling directory for line printers, uucp(1C), etc., and whose sub-directories
should be compacted as described above.
14. ALLOCATING RESOURCES TO USERS
A prospective user should obtain connect-time and file-space authorization through appropriate
channels. Once this is done, the user should apply for a login by providing the following
information to the ‘‘system administrator’’:
•
•
•
•
User’s name.
Suggested login name (not more than 8 characters, beginning with a lower-case letter).
Relationships to other users (this influences the choice of the file system).
Estimate of required file space (this also influences the choice of the file system).
Users should be forced to have passwords (not more than 8 characters long, but more than 5, and
not in Webster’s Unabridged); passwd (5) explains how to do that.
15. THE MATTER OF ACCOUNTING AND USAGE
You should run the accounting programs even if you do not ‘‘bill’’ for service. Otherwise, your
users’ habits (especially bad habits) will be a mystery to you. Accounting information can also
help you find performance bottlenecks, unused logins, bad phone lines, etc.
16. DIAL LINE UTILIZATION
If prime-time dial line utilization gets much over 70%, users will start to encounter busy signals
when dialing in. This, in turn, will lead to ‘‘line hogging’’. The only solutions are to get a larger
(another) machine, or to get rid of users. Manual policing will help some, but ‘‘automatic’’
policing will be invariably subverted by users.
17. ‘‘BIRD-DOGGING’’
When the system is busy (lines busy and/or slow response), someone should determine why this is
so. The who(1) command lists the people logged in. The ps(1) command shows what they are
doing. (The /etc/whodo command combines the output of who and ps.) Unfortunately, ps
operates from heuristics that can consistently fail to report certain processes in a busy system.
That is, one must be careful about hanging up an apparently inactive line. The acctcom(1M)
command can read the shell accounting file /usr/adm/pacct backwards from the most recent
entry. It will print entries for selected lines or login names.
18. 300/1,200-BAUD TERMINALS
Don’t use upper-case-only terminals. Get full-duplex, full-ASCII terminals. Hardware horizontal
tabbing is very desirable, because it increases output speed and lowers system overhead. A fair
proportion of your terminals should provide for correspondence-quality hard-copy output to take
advantage of the UNIX word-processing capabilities; see term(7).
19. LINE PRINTERS
Most line printers are troublesome and impose considerable overhead on the system. Most also
lack hardware tabs, character overstrike capability, etc. A printer that will work over an
asynchronous link (DC1/DC3 protocol required) may be the best bet.
Administrative Advice for UNIX
7
20. SECURITY
The current UNIX is not tamper-proof. You can’t keep people from ‘‘breaking’’ the system, but
you can usually detect that they have done so. The following command will mail (to root) a list
of all ‘‘set user ID’’ programs owned by root (super-user):
find / −user root −perm −4100 −exec ls −l { } \; | mail root
Any surprises in root ’s mail should be investigated. Related advice:
•
•
•
•
•
Change the super-user password regularly. Don’t pick obvious passwords (choose 6-to-8
character nonsense strings that combine alphabetics with digits or special characters).
If you have dial ports and do not require passwords, you are courting trouble.
The chroot(1M) ans su(1) commands are inherently dangerous, as are group passwords;
consider removing them from ‘‘production’’ systems.
Login directories, .profile files, and files in /bin, /usr/bin, /lbin, and /etc that are writable
by others than their respective owners are security weak spots; police your system regularly
against them.
Remember, no time-sharing system with dial ports is really secure. Don’t keep top-secret
stuff on the system.
21. COMMUNICATING WITH YOUR USERS
The directory /usr/news and the news(1) command are provided as a way to get brief
announcements to your users. More pressing items (one-liners) can be entered in the /etc/motd
(message of the day) file; motd and (new to the user) news are announced at login time.
To reach users who are already logged in, use the wall (1M) (write all) command. Don’t use wall
while logged-in as super-user, except in emergencies.
The /usr/news directory should be cleaned out every few weeks so that nothing older than, say,
three months is ever found there. The motd file should be cleaned out daily.
We have found that, on most systems, a file in /usr/news will reach 50% of the users within a day
and over 80% of the users within a week.
22. TROUBLESHOOTING
It would be easy to write a book on this topic. The following are some of the key items:
a. Dealing with the hardware service contractor:
•
•
•
•
•
Before you take out a hardware service contract (with DEC or with someone else), be
sure that the contractor agrees to get along with the UNIX software (‘‘It’s the
hardware,’’ says you; ‘‘It’s the software,’’ says the hardware service contractor).
Keep on top of problems. For instance, DEC has a problem-aging priority scheme.
Find out about any such scheme that your contractor may have, and make them
prove that it is being followed. Remember that an unreported problem is getting no
priority at all. If a problem persists, escalate it up your contractor’s local
management chain; it may also be effective to complain to your contractor’s sales
representative.
If you are serious about service to your users, you should have an extended-period
service contract (e.g., 16 hours/day, 6 days/week). Arrange for preventive
maintenance, non-critical repair, and add-on installation work to be done before or
after prime time.
If you have a service contract, learn the details. In particular, make sure that
preventive maintenance is scheduled in advance and that it is completed.
Ask the hardware service contractor to provide and maintain a ‘‘site log’’. You will
8
Administrative Advice for UNIX
•
•
•
•
b.
have to work on the log, as well.
Make sure that your hardware vendor (as well as your hardware service contractor, if
the two are different) agrees to the presence of non-DEC equipment on your system
(even if you have none to start with).
Run error logging. Keep console sheets. Make sure error messages are shown to your
contractor’s Customer Engineers.
Take core dumps after system crashes and interpret results for Customer Engineers.
Keep down-time records and make sure that your hardware service contractor knows
about them.
Dealing with the telephone services vendor:
You are most apt to have telephone problems when you rearrange or add equipment. You
may also have occasional central office, trunking, and modem failures:
•
•
c.
Be specific with repair operators: tell them that the trouble involves data equipment.
If your first call fails to get results, ask for the ‘‘supervisor’’ on the second call, and, if
necessary, escalate further to get the problem solved.
Some obvious problem areas:
•
•
•
•
Disk Drives−Over 50% of your problems are likely to be related to the disk
subsystem. As mentioned earlier, the way to keep your system up is to have a spare
disk drive. Remember:
— Preventive maintenance of disk drives is very important.
— Make sure that the Customer Engineers who service your hardware see the
error-logging printouts and console error messages produced by UNIX (and that
they understand them).
— Disk failure can ruin a UNIX file system. The only defense is to make a
complete, daily file backup! (See Protecting User Files above.)
— Many administrators believe the the RP04 disk drives fail more often than
RP06s and take longer to fix.
Dial Ports−In this area, as well as in the area of synchronous data interfaces, there is
room for finger-pointing among all your vendors. Check for obvious things:
— Is the system in ‘‘multi-user’’ mode?
— Is the /etc/inittab file OK?
— Are any cables loose (both ends)?
— In some telephone offices, trunk-hunting is based on 10-number groups.
Hunting between such groups can fail independently of anything else.
The possibilities for trouble are many. The ‘‘decision table’’ below attempts to
describe some alternatives; it is meant primarily for users of DH11/DZ11 asynchronous
devices. If you are unfamiliar with the format, (vertical) Rule 3 reads: ‘‘If line rings
and ring light shows and computer does not answer and switching the modem solves
the problem, then it is likely to be a telephone company problem; also, busy out that
line.’’
Early experience with the DZ11 has been poor. Several different problems have
cropped up including bad line units and a stuck interrupt bit that crashes the system.
Don’t install DZs without giving them the full diagnostic treatment.
Synchronous Ports−High-speed synchronous interface devices are even more trouble
than dial equipment. The following is a list of potential trouble spots:
— Your UNIX software.
— Your interface device (e.g., DQS11B).
— Cable to your modem.
— Your modem.
— The communications line.
Administrative Advice for UNIX
•
9
— Other modem.
— Other cable.
— Other interface device.
— Other system’s software.
Think of the finger-pointing possibilities. The best defense is a good line monitor.
Power Supply Modules−There are a lot of them, and they do fail, more or less
regularly. Hard failure can be detected at the console; voltage drift is tougher.
Failure of the FP11 (floating-point unit) power supply can be slow to fix, because
Customer Engineers are likely to work back from the far end of the ‘‘bus’’, taking a
long time to find the problem.
Asynchronous Line Problems
Rules:
1 2 3 4 5 6 7 8 9 0
Condition:
Line rings
Ring light shows on telephone console
Computer answers
Login message received on terminal
Switching modem solves problem
User can login
Telephone console shows data received
Problem affects whole DH/DZ (up to 16 lines)
N
−
−
−
−
−
−
−
Y
N
−
−
−
−
−
−
Y
Y
N
−
Y
−
−
−
Y
Y
N
−
N
−
−
−
Y
Y
Y
N
Y
−
−
−
Y
Y
Y
N
N
−
−
−
Y
Y
Y
Y
−
N
Y
Y
Y
Y
Y
Y
−
N
Y
N
Y
Y
Y
Y
−
N
N
−
Y
Y
Y
Y
−
Y
−
−
−
−
X
−
X
−
−
X
−
X
−
−
X
−
X
−
X
−
−
X
−
−
X
−
X
−
X
−
−
X
−
X
−
−
X
−
−
−
X
−
−
−
X
−
X
X
−
−
−
−
Diagnosis and/or Action:
No problem
PDP-11 hardware problem likely
Telephone problem likely
May be a problem with user’s terminal
Busy out bad line(s)
23. DATASET OPTIONS
The following dataset options seem to work with UNIX:
The 801C-L1 (Auto-Call Unit):
Jumpers:
E2 to E3
E6 to E5
Options:
Y, X, T, B,
ZG, ZP, G,
R, ZT
Switches
S1
S2
S3
S4
(0
=
=
=
=
= open, 1= closed, i.e., side next to number is down):
1000[1] (Bracketed switches are missing on some models.)
0101
11010
11[00]
The 212A-L1 (1,200-baud full-duplex):
Options:
E, ZF, YF, YC,
YG, YJ, YK,
S, V, A, T, ZH,
W, YP, YR
10
Administrative Advice for UNIX
Switches:
S1 =
S2 =
S3 =
S5 =
[0]001
110001000
11110000
00
24. NULL MODEM WIRING
Improperly wired null modems can cause spurious interrupts, especially at higher baud rates. A
single bad modem on a 9,600-baud line can waste 15% of your CPU power. The following
(symmetrical) wiring plan will prevent such problems:
pin 1 to 1
pin 2 to 3
pin 3 to 2
strap pin 4 to 5 in the same plug
pin 6 to 20
pin 7 to 7
pin 8 to 20
pin 20 to 6 and 8
ground unused pins
25. 113D, 103J DATA SET PROBLEMS
The DH11 and DJ11 multiplexers normally have a jumper connecting pin 25 to pin 4 (request to
send), thus asserting pin 25 when the line is opened. This jumper should be removed for any lines
connected to 113Ds or 103Js (also applies to 103Js with 801s).
26. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES
Read this section if you plan to use the phototypesetting software of UNIX.
Phototypesetter.
manufactured by:
The
phototypesetter
Wang Graphic Systems, Inc.
Executive Drive
Hudson, NH 03051
and
fonts
currently
supported
by
UNIX
are
(603-889-8550)
The phototypesetter is an on-line C/A/T System 1 with a high-speed turret. The external paper
tape reader on the typesetter is not needed, because the typesetter is connected to the PDP-11
CPU via a DR11C.
PDP 11/45 Only. The following modification (developed by DEC Field Service) should be
made to the DR11C (without this modification, the system may crash when the typesetter is
powered down): ‘‘Add two 390-ohm resistors−from E-18 pin 6 to ground, and from E-18 pin 3 to
ground. Put a piece of insulating tubing over the leads so that they do not short out the ‘etch’
runs that they cross.’’
Fonts. There are eight fonts that are normally used, as shown in the table below. The first three
of the these provide the most-often used (serif) typeface. The last three are used when a sansserif typeface is desired. The fourth font contains a number of Greek characters and mathematical
symbols; see NROFF/TROFF User’s Manual by J. F. Ossanna. The fifth font is useful for
typesetting text that you wish to look like terminal or printer output, e.g., for examples of
programs. Wang Graphic Systems, Inc. offers a variety of other fonts. For troff to be able to use
these fonts, corresponding font tables must be built and compiled into the directory /usr/lib/font.
Administrative Advice for UNIX
11
Name
BT Times Roman
Times Italic
Times Bold
BT PI Font #4 Special Characters
BT PI Font #6 Constant Width
Geneva (Helvetica) Regular
Geneva (Helvetica) Regular Italic
Geneva (Helvetica) Medium
Part Number
802-016A
802-013A
802-014A
829-021B
829-046A
803-032B
803-033B
803-034B
Troff Name
R
I
B
S
CW
G or H
GI or HI
GM or HM
Other fonts for which the source font tables are supplied are:
Name
Boston Condensed
News Condensed
Century Schoolbook Expanded
Century Schoolbook Italic
Century Bold Italic
Century Schoolbook
Futura (Utica) Demibold
Text Greek
Geneva Light
Geneva Light Italic
Palatino
Palatino Bold
Palatino Italic
Stymie Bold
Stymie Medium Italic
Stymie Medium
Troff Name
BC
C
CE
CI
CK
CS
FD or UD
GR
L
LI
PA
PB
PI
SB
SI
SM
Paper and Chemicals. The phototypesetter ‘‘prints’’ onto photo-mechanical paper, which can
be obtained from a photographic supply house and is specified as:
•
Kodak Ektamatic Paper, Grade S, Type 2250, 8 in.×150 ft., Spec. 175 (or equivalent).
Also obtainable from such a supply house are the chemicals for the developing process:
•
•
Kodak Ektamatic A10 Activator (or equivalent).
Kodak Ektamatic S40 Stabilizer (or equivalent).
These chemicals should be ordered in 9.5-liter (2.5-gallon) containers for the circulator.
Developer. A Kodak Ektamatic Processor Model 214K (or equivalent) is used to process the
paper from the typesetter. A light-proof box attached to the 214K (to hold the output cassette
from the typesetter) is called an ‘‘Autofeeder’’ and can be obtained from:
Peripheral Graphics, Inc.
Andover Industrial Center
York Street
Andover, MA 01810
(617-475-9005)
Circulator and Dryer. A circulator and a paper dryer, as well as a shelf for the dryer can be
obtained from:
Mohr Enterprises
8015 North Ridgeway Ave.
Skokie, IL 60076
(312-674-8890)
12
Administrative Advice for UNIX
The needed parts are:
• ME-8
Mohrflow: circulator to increase the usability of the chemicals.
Mohrdry: dryer for the photo-mechanical paper.
Dryer Extension: shelf to support the dryer; it connects to the circulator cabinet.
• ME-5
•
Also obtainable from Mohr Enterprises are cleaners for the developer and circulator. Such
cleaning is needed every 2 to 4 weeks, depending on the volume of work:
•
•
R-53 Mohrchem Activator Cleaner Concentrate.
R-57 Mohrchem Stabilizer Cleaner Concentrate.
Each quart bottle makes 9.5 liters (2.5 gallons) of reusable cleaner to clean the tubing, rollers, and
tray of the developer and circulator. Equivalent cleaners can also be obtained elsewhere.
June 1980