This section describes procedures used to set up a 4.4BSD UNIX system. These procedures are used when a system is first installed or when the system configuration changes. Procedures for normal system operation are described in the next section.
This section briefly describes the layout of the kernel code and how files for devices are made. For a full discussion of configuring and building system images, consult the document ``Building 4.3BSD UNIX Systems with Config'' (SMM:2).
As distributed, the kernel source is in a separate tar image. The source may be physically located anywhere within any filesystem so long as a symbolic link to the location is created for the file /sys (many files in /usr/include are normally symbolic links relative to /sys). In further discussions of the system source all path names will be given relative to /sys.
The kernel is made up of several large generic parts:
sys main kernel header files
kern kernel functions broken down as follows
init system startup, syscall dispatching, entry points
kern scheduling, descriptor handling and generic I/O
sys process management, signals
tty terminal handling and job control
vfs filesystem management
uipc interprocess communication (sockets)
subr miscellaneous support routines
vm virtual memory management
ufs local filesystems broken down as follows
ufs common local filesystem routines
ffs fast filesystem
lfs log-based filesystem
mfs memory based filesystem
nfs Sun-compatible network filesystem
miscfs miscellaneous filesystems broken down as follows
deadfs where rejected vnodes go to die
fdesc access to per-process file descriptors
fifofs IEEE Std1003.1 FIFOs
kernfs filesystem access to kernel data structures
lofs loopback filesystem
nullfs another loopback filesystem
portal associate processes with filesystem locations
specfs device special files
umapfs provide alternate uid/gid mappings
dev generic device drivers (SCSI, vnode, concatenated disk)
The networking code is organized by protocol
net routing and generic interface drivers netinet Internet protocols (TCP, UDP, IP, etc) netiso ISO protocols (TP-4, CLNP, CLTP, etc) netns Xerox network systems protocols (IDP, SPP, etc) netx25 CCITT X.25 protocols (X.25 Packet Level, HDLC/LAPB)
A separate subdirectory is provided for each machine architecture
hp300 HP 9000/300 series of Motorola 68000-based machines hp code common to both HP 68k and (non-existent) PA-RISC ports i386 Intel 386/486-based PC machines luna68k Omron 68000-based workstations news3400 Sony News MIPS-based workstations pmax Digital 3100/5000 MIPS-based workstations sparc Sun Microsystems SPARCstation 1, 1+, and 2 tahoe (deprecated) CCI Power 6-series machines vax (deprecated) Digital VAX machines
Each machine directory is subdivided by function; for example the hp300 directory contains
include exported machine-dependent header files hp300 machine-dependent support code and private header files dev device drivers conf configuration files stand machine-dependent standalone code
Other kernel related directories
compile area to compile kernels conf machine-independent configuration files stand machine-independent standalone code
Devices supported by UNIX are implemented in the kernel by drivers whose source is kept in /sys/<architecture>/dev. These drivers are loaded into the system when included in a cpu specific configuration file kept in the conf directory. Devices are accessed through special files in the filesystem, made by the mknod(8) program and normally kept in the /dev directory. For all the devices supported by the distribution system, the files in /dev are created by the /dev/MAKEDEV shell script.
Determine the set of devices that you have and create a new /dev directory by running the MAKEDEV script. First create a new directory /newdev, copy MAKEDEV into it, edit the file MAKEDEV.local to provide an entry for local needs, and run it to generate a /newdevdirectory. For instance,
# cd / # mkdir newdev # cp dev/MAKEDEV newdev/MAKEDEV # cd newdev # MAKEDEV sd0 pt0 std LOCAL
You can then do
# cd / # mv dev olddev ; mv newdev dev # sync
The kernel configuration of each UNIX system is described by a single configuration file, stored in the /sys/<architecture>/conf directory. To learn about the format of this file and the procedure used to build system images, start by reading ``Building 4.3BSD UNIX Systems with Config'' (SMM:2), look at the manual pages in section 4 of the UNIX manual for the devices you have, and look at the sample configuration files in the /sys/<architecture>/conf directory.
The configured system image kernel should be copied to the root, and then booted to try it out. It is best to name it /newkernel so as not to destroy the working system until you are sure it does work:
# cp kernel /newkernel # sync
If UNIX is to support simultaneous access from directly-connected terminals other than the console, the file /etc/ttys (see ttys(5)) must be edited.
To add a new terminal device, be sure the device is configured into the system and that the special files for the device have been made by /dev/MAKEDEV. Then, enable the appropriate lines of /etc/ttys by setting the ``status'' field to on (or add new lines). Note that lines in /etc/ttys are one-for-one with entries in the file of current users (see /var/run/utmp), and therefore it is best to make changes while running in single-user mode and to add all the entries for a new device at once.
Each line in the /etc/ttys file is broken into four tab separated fields (comments are shown by a `#' character and extend to the end of the line). For each terminal line the four fields are: the device (without a leading /dev), the program /sbin/init should startup to service the line (or none if the line is to be left alone), the terminal type (found in /usr/share/misc/termcap), and optional status information describing if the terminal is enabled or not and if it is ``secure'' (i.e. the super user should be allowed to login on the line). If the console is marked as ``insecure'', then the root password is required to bring the machine up single-user. All fields are character strings with entries requiring embedded white space enclosed in double quotes. Thus a newly added terminal /dev/tty00 could be added as
tty00 "/usr/libexec/getty std.9600" vt100 on secure # mike's office
Dialup terminals should be wired so that carrier is asserted only when the phone line is dialed up. For non-dialup terminals, from which modem control is not available, you must wire back the signals so that the carrier appears to always be present. For further details, find your terminal driver in section 4 of the manual.
For network terminals (i.e. pseudo terminals), no program should be started up on the lines. Thus, the normal entry in /etc/ttys would look like
ttyp0 none network
When the system is running multi-user, all terminals that are listed in /etc/ttys as on have their line enabled. If, during normal operations, you wish to disable a terminal line, you can edit the file /etc/ttys to change the terminal's status to off and then send a hangup signal to the init process, by doing
# kill -1 1
Note that if a special file is inaccessible when init tries to create a process for it, init will log a message to the system error logging process (see syslogd(8)) and try to reopen the terminal every minute, reprinting the warning message every 10 minutes. Messages of this sort are normally printed on the console, though other actions may occur depending on the configuration information found in /etc/syslog.conf.
Finally note that you should change the names of any dialup terminals to ttyd? where ? is in [0-9a-zA-Z], as some programs use this property of the names to determine if a terminal is a dialup. Shell commands to do this should be put in the /dev/MAKEDEV.local script.
While it is possible to use truly arbitrary strings for terminal names, the accounting and noticeably the ps(1) command make good use of the convention that tty names (by default, and also after dialups are named as suggested above) are distinct in the last 2 characters. Change this and you may be sorry later, as the heuristic ps(1) uses based on these conventions will then break down and ps will run MUCH slower.
The procedure for adding a new user is described in adduser(8). You should add accounts for the initial user community, giving each a directory and a password, and putting users who will wish to share software in the same groups.
Several guest accounts have been provided on the distribution system; these accounts are for people at Berkeley, Bell Laboratories, and others who have done major work on UNIX in the past. You can delete these accounts, or leave them on the system if you expect that these people would have occasion to login as guests on your system.
All programs that require the site's name, or some similar characteristic, obtain the information through system calls or from files located in /etc. Aside from parts of the system related to the network, to tailor the system to your site you must simply select a site name, then edit the file
/etc/netstart
hostname=mysitename /bin/hostname $hostname
You will also need to edit /etc/netstart to do the network interface initialization using ifconfig(8). If you are not sure how to do this, see sections 5.1, 5.2, and 5.3. If you are not running a routing daemon and have more than one Ethernet in your environment you will need to set up a default route; see section 5.4 for details. Before bringing your system up multiuser, you should ensure that the networking is properly configured. The network is started by running /etc/netstart. Once started, you should test connectivity using ping(8). You should first test connectivity to yourself, then another host on your Ethernet, and finally a host on another Ethernet. The netstat(8) program can be used to inspect and debug your routes; see section 5.4.
The line printer system consists of at least the following files and commands:
/usr/bin/lpq spooling queue examination program /usr/bin/lprm program to delete jobs from a queue /usr/bin/lpr program to enter a job in a printer queue /etc/printcap printer configuration and capability database /usr/sbin/lpd line printer daemon, scans spooling queues /usr/sbin/lpc line printer control program /etc/hosts.lpd list of host allowed to use the printers
The file /etc/printcap is a master database describing line printers directly attached to a machine and, also, printers accessible across a network. The manual page printcap(5) describes the format of this database and also shows the default values for such things as the directory in which spooling is performed. The line printer system handles multiple printers, multiple spooling queues, local and remote printers, and also printers attached via serial lines that require line initialization such as the baud rate. Raster output devices such as a Varian or Versatec, and laser printers such as an Imagen, are also supported by the line printer system.
Remote spooling via the network is handled with two spooling queues, one on the local machine and one on the remote machine. When a remote printer job is started with lpr, the job is queued locally and a daemon process created to oversee the transfer of the job to the remote machine. If the destination machine is unreachable, the job will remain queued until it is possible to transfer the files to the spooling queue on the remote machine. The lpq program shows the contents of spool queues on both the local and remote machines.
To configure your line printers, consult the printcap manual page and the accompanying document, ``4.3BSD Line Printer Spooler Manual'' (SMM:7). A call to the lpd program should be present in /etc/rc.
The mail system consists of the following commands:
/usr/bin/mail UCB mail program, described in mail(1) /usr/sbin/sendmail mail routing program /var/spool/mail mail spooling directory /var/spool/secretmail secure mail directory /usr/bin/xsend secure mail sender /usr/bin/xget secure mail receiver /etc/aliases mail forwarding information /usr/bin/newaliases command to rebuild binary forwarding database /usr/bin/biff mail notification enabler /usr/libexec/comsat mail notification daemon
Mail queued in the directory /var/spool/mail is normally readable only by the recipient. To send mail that is secure against perusal (except by a code-breaker) you should use the secret mail facility, which encrypts the mail.
To set up the mail facility you should read the instructions in the file READ_ME in the directory /usr/src/usr.sbin/sendmail and then adjust the necessary configuration files. You should also set up the file /etc/aliases for your installation, creating mail groups as appropriate. For more informations see ``Sendmail Installation and Operation Guide'' (SMM:8) and ``Sendmail - An Internetwork Mail Router'' (SMM:9).
The version of uucp included in 4.4BSD has the following features:
This section gives a brief overview of uucp and points out the most important steps in its installation.
To connect two UNIX machines with a uucp network link using modems, one site must have an automatic call unit and the other must have a dialup port. It is better if both sites have both.
You should first read the paper in the UNIX System Manager's Manual: ``Uucp Implementation Description'' (SMM:14). It describes in detail the file formats and conventions, and will give you a little context. In addition, the document ``setup.tblms'', located in the directory /usr/src/usr.bin/uucp/UUAIDS, may be of use in tailoring the software to your needs.
The uucp support is located in three major directories: /usr/bin, /usr/lib/uucp, and /var/spool/uucp. User commands are kept in /usr/bin, operational commands in /usr/lib/uucp, and /var/spool/uucp is used as a spooling area. The commands in /usr/bin are:
/usr/bin/uucp file-copy command /usr/bin/uux remote execution command /usr/bin/uusend binary file transfer using mail /usr/bin/uuencode binary file encoder (for uusend) /usr/bin/uudecode binary file decoder (for uusend) /usr/bin/uulog scans session log files /usr/bin/uusnap gives a snap-shot of uucp activity /usr/bin/uupoll polls remote system until an answer is received /usr/bin/uuname prints a list of known uucp hosts /usr/bin/uuq gives information about the queue
/usr/lib/uucp/L-devices list of dialers and hard-wired lines /usr/lib/uucp/L-dialcodes dialcode abbreviations /usr/lib/uucp/L.aliases hostname aliases /usr/lib/uucp/L.cmds commands remote sites may execute /usr/lib/uucp/L.sys systems to communicate with, how to connect, and when /usr/lib/uucp/SEQF sequence numbering control file /usr/lib/uucp/USERFILE remote site pathname access specifications /usr/lib/uucp/uucico uucp protocol daemon /usr/lib/uucp/uuclean cleans up garbage files in spool area /usr/lib/uucp/uuxqt uucp remote execution server
/var/spool/uucp/C. directory for command, ``C.'' files /var/spool/uucp/D. directory for data, ``D.'', files /var/spool/uucp/X. directory for command execution, ``X.'', files /var/spool/uucp/D.machine directory for local ``D.'' files /var/spool/uucp/D.machineX directory for local ``X.'' files /var/spool/uucp/TM. directory for temporary, ``TM.'', files /var/spool/uucp/LOGFILE log file of uucp activity /var/spool/uucp/SYSLOG log file of uucp file transfers
To install uucp on your system, start by selecting a site name (shorter than 14 characters). A uucp account must be created in the password file and a password set up. Then, create the appropriate spooling directories with mode 755 and owned by user uucp, group daemon.
If you have an auto-call unit, the L.sys, L-dialcodes, and L-devices files should be created. The L.sys file should contain the phone numbers and login sequences required to establish a connection with a uucp daemon on another machine. For example, our L.sys file looks something like:
adiron Any ACU 1200 out0123456789- ogin-EOT-ogin uucp cbosg Never Slave 300 cbosgd Never Slave 300 chico Never Slave 1200 out2010123456
ucb 2 out 9%
ACU cul0 unused 1200 ventel
As uucp operates it creates (and removes) many small files in the directories underneath /var/spool/uucp. Sometimes files are left undeleted; these are most easily purged with the uuclean program. The log files can grow without bound unless trimmed back; uulog maintains these files. Many useful aids in maintaining your uucp installation are included in a subdirectory UUAIDS beneath /usr/src/usr.bin/uucp. Peruse this directory and read the ``setup'' instructions also located there.