All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
@(#)4.t 8.1 (Berkeley) 7/29/93
.Sh 1 "System setup"
This section describes procedures used to set up a \*(4B 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. .Sh 2 "Kernel configuration"
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). .Sh 3 "Kernel organization"
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
n /sys (many files in
n /usr/include are normally symbolic links relative to
n /sys ). In further discussions of the system source all path names will be given relative to
n /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
n /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 .Xr mknod (8) program and normally kept in the
n /dev directory. For all the devices supported by the distribution system, the files in
n /dev are created by the
Determine the set of devices that you have and create a new
n /dev directory by running the MAKEDEV script. First create a new directory
n /newdev , copy MAKEDEV into it, edit the file MAKEDEV.local to provide an entry for local needs, and run it to generate a
n /newdev directory. For instance, # cd / # mkdir newdev # cp dev/MAKEDEV newdev/MAKEDEV # cd newdev # MAKEDEV \*(Dk0 pt0 std LOCAL Note the ``std'' argument causes standard devices such as
n /dev/console , the machine console, to be created.
You can then do # cd / # mv dev olddev ; mv newdev dev # sync to install the new device directory. .Sh 3 "Building new system images"
The kernel configuration of each UNIX system is described by a single configuration file, stored in the
n /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
n /sys/<architecture>/conf directory.
The configured system image
n kernel should be copied to the root, and then booted to try it out. It is best to name it
n /newkernel so as not to destroy the working system until you are sure it does work: # cp kernel /newkernel # sync It is also a good idea to keep the previous system around under some other name. In particular, we recommend that you save the generic distribution version of the system permanently as
n /genkernel for use in emergencies. To boot the new version of the system you should follow the bootstrap procedures outlined in section 6.1. After having booted and tested the new system, it should be installed as
n /kernel before going into multiuser operation. A systematic scheme for numbering and saving old versions of the system may be useful. .Sh 2 "Configuring terminals"
If UNIX is to support simultaneous access from directly-connected terminals other than the console, the file
n /etc/ttys (see .Xr 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
n /dev/MAKEDEV . Then, enable the appropriate lines of
n /etc/ttys by setting the ``status'' field to on (or add new lines). Note that lines in
n /etc/ttys are one-for-one with entries in the file of current users (see
n /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
n /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
n /dev ), the program
n /sbin/init should startup to service the line (or none if the line is to be left alone), the terminal type (found in
n /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
n /dev/tty00 could be added as tty00 "/usr/libexec/getty std.9600" vt100 on secure # mike's office The std.9600 parameter provided to
n /usr/libexec/getty is used in searching the file
n /etc/gettytab ; it specifies a terminal's characteristics (such as baud rate). To make custom terminal types, consult .Xr gettytab (5) before modifying
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
n /etc/ttys would look like ttyp0 none network (Note, the fourth field is not needed here.)
When the system is running multi-user, all terminals that are listed in
n /etc/ttys as on have their line enabled. If, during normal operations, you wish to disable a terminal line, you can edit the file
n /etc/ttys to change the terminal's status to off and then send a hangup signal to the .Xr init process, by doing # kill -1 1 Terminals can similarly be enabled by changing the status field from off to on and sending a hangup signal to .Xr init .
Note that if a special file is inaccessible when .Xr init tries to create a process for it, .Xr init will log a message to the system error logging process (see .Xr 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
n /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
n /dev/MAKEDEV.local script.
While it is possible to use truly arbitrary strings for terminal names, the accounting and noticeably the .Xr 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 .Xr ps (1) uses based on these conventions will then break down and .Xr ps will run MUCH slower. .Sh 2 "Adding users"
The procedure for adding a new user is described in .Xr 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. .Sh 2 "Site tailoring"
All programs that require the site's name, or some similar characteristic, obtain the information through system calls or from files located in
n /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 The first lines in
n /etc/netstart use a variable to set the hostname, hostname=mysitename /bin/hostname $hostname to define the value returned by the .Xr gethostname (2) system call. If you are running the name server, your site name should be your fully qualified domain name. Programs such as .Xr getty (8), .Xr mail (1), .Xr wall (1), and .Xr uucp (1) use this system call so that the binary images are site independent.
You will also need to edit
n /etc/netstart to do the network interface initialization using .Xr 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
n /etc/netstart . Once started, you should test connectivity using .Xr ping (8). You should first test connectivity to yourself, then another host on your Ethernet, and finally a host on another Ethernet. The .Xr netstat (8) program can be used to inspect and debug your routes; see section 5.4. .Sh 2 "Setting up the line printer system"
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
n /etc/printcap is a master database describing line printers directly attached to a machine and, also, printers accessible across a network. The manual page .Xr 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 .Xr 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 .Xr 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 .Xr lpd program should be present in
n /etc/rc . .Sh 2 "Setting up the mail system"
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 |
n /usr/bin/mail ), which provides a front-end to edit the messages sent and received, and passes the messages to .Xr sendmail (8) for routing. The routing algorithm uses knowledge of the network name syntax, aliasing and forwarding information, and network topology, as defined in the configuration file
n /usr/lib/sendmail.cf , to process each piece of mail. Local mail is delivered by giving it to the program
n /usr/libexec/mail.local that adds it to the mailboxes in the directory
n /var/spool/mail/<username> , using a locking protocol to avoid problems with simultaneous updates. After the mail is delivered, the local mail delivery daemon
n /usr/libexec/comsat is notified, which in turn notifies users who have issued a ``biff y'' command that mail has arrived.
Mail queued in the directory
n /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
n /usr/src/usr.sbin/sendmail and then adjust the necessary configuration files. You should also set up the file
n /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). .Sh 3 "Setting up a UUCP connection"
The version of .Xr uucp included in \*(4B has the following features:
n L.cmds file to control the set of commands that may be executed by a remote site,
This section gives a brief overview of .Xr uucp and points out the most important steps in its installation.
To connect two UNIX machines with a .Xr 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
n /usr/src/usr.bin/uucp/UUAIDS , may be of use in tailoring the software to your needs.
The .Xr uucp support is located in three major directories:
n /var/spool/uucp . User commands are kept in
n /usr/bin, operational commands in
n /var/spool/uucp is used as a spooling area. The commands in
| /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 .Xr uucp on your system, start by selecting a site name (shorter than 14 characters). A .Xr 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 .Xr 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 .Xr 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 The first field is the name of a site, the second shows when the machine may be called, the third field specifies how the host is connected (through an ACU, a hard-wired line, etc.), then comes the phone number to use in connecting through an auto-call unit, and finally a login sequence. The phone number may contain common abbreviations that are defined in the L-dialcodes file. The device specification should refer to devices specified in the L-devices file. Listing only ACU causes the .Xr uucp daemon, .Xr uucico , to search for any available auto-call unit in L-devices. Our L-dialcodes file is of the form: ucb 2 out 9% while our L-devices file is: ACU cul0 unused 1200 ventel Refer to the README file in the .Xr uucp source directory for more information about installation.
As .Xr uucp operates it creates (and removes) many small files in the directories underneath
n /var/spool/uucp . Sometimes files are left undeleted; these are most easily purged with the .Xr uuclean program. The log files can grow without bound unless trimmed back; .Xr uulog maintains these files. Many useful aids in maintaining your .Xr uucp installation are included in a subdirectory UUAIDS beneath
n /usr/src/usr.bin/uucp . Peruse this directory and read the ``setup'' instructions also located there.