From 376cdb84e9ad97523c868ed52b7997b1fd7e5d3d Mon Sep 17 00:00:00 2001 From: "William F. Jolitz" Date: Tue, 7 May 1991 21:40:49 -0800 Subject: [PATCH] 386BSD 0.1 development Work on file usr/othersrc/share/doc/smm/01.setup/common/3.t Work on file usr/othersrc/share/doc/smm/01.setup/common/4.t Work on file usr/othersrc/share/doc/smm/01.setup/common/6.t Work on file usr/othersrc/share/doc/smm/01.setup/common/renohints.t Co-Authored-By: Lynne Greer Jolitz Synthesized-from: 386BSD-0.1 --- .../share/doc/smm/01.setup/common/3.t | 717 +++++++++ .../share/doc/smm/01.setup/common/4.t | 1353 +++++++++++++++++ .../share/doc/smm/01.setup/common/6.t | 646 ++++++++ .../share/doc/smm/01.setup/common/renohints.t | 824 ++++++++++ 4 files changed, 3540 insertions(+) create mode 100644 usr/othersrc/share/doc/smm/01.setup/common/3.t create mode 100644 usr/othersrc/share/doc/smm/01.setup/common/4.t create mode 100644 usr/othersrc/share/doc/smm/01.setup/common/6.t create mode 100644 usr/othersrc/share/doc/smm/01.setup/common/renohints.t diff --git a/usr/othersrc/share/doc/smm/01.setup/common/3.t b/usr/othersrc/share/doc/smm/01.setup/common/3.t new file mode 100644 index 0000000000..395cca0813 --- /dev/null +++ b/usr/othersrc/share/doc/smm/01.setup/common/3.t @@ -0,0 +1,717 @@ +.\" Copyright (c) 1980, 1986, 1988 The Regents of the University of California. +.\" 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. +.\" +.\" @(#)3.t 6.8 (Berkeley) 4/17/91 +.\" +.ds lq `` +.ds rq '' +.ds RH "Upgrading a 4.2BSD or \*(Ps System +.ds CF \*(DY +.LP +.nr H1 3 +.nr H2 0 +.bp +.LG +.B +.ce +3. UPGRADING A 4.2BSD OR \*(Ps SYSTEM +.sp 2 +.R +.NL +.PP +This section describes the procedure for upgrading a 4.2 or \*(Ps +system to \*(4B. This procedure may vary according to the version of +the system running before conversion. +If you are upgrading from 4.2BSD, +begin by reading the ``Bugs Fixes and Changes in \*(4B'' document to +see what has changed since the last time you bootstrapped the system. +If you have local system modifications to the +kernel to install, look at the document +``Changes to the Kernel in \*(4B'' to get an idea of how +the system changes will affect your local modifications. +.if \n(Th \{\ +If you are converting from a +System V system, some of this section will still apply (in particular, +the filesystem conversion). However, many of the system configuration +files are different, and the executable file formats are completely +incompatible. +.\} +.PP +If you are running 4.2BSD or \*(Ps, upgrading your system +involves replacing your kernel and system utilities. +Binaries compiled under \*(Ps will work without recompilation +under \*(4B, though they may run faster if they are recompiled. +.if \n(Th \{\ +When converting from 4.2BSD, most local programs will have to be recompiled, +as there are a number of incompatibilities between 4.3BSD +and the vendor-supplied 4.2BSD. +.\} +.if \n(Vx \{\ +Binaries compiled under 4.2BSD will probably work without recompilation, +but it is a good idea to recompile and relink because of the many changes +in header files and libraries since 4.2BSD. +4.1BSD binary images can also run unchanged under \*(4B +but only when the system is configured to include the +``4.1BSD compatibility mode.''* +.FS +* With ``4.1BSD compatibility mode'' +system calls from 4.1BSD are either emulated or safely ignored. +There are only two exceptions: programs that read directories or use +the old jobs library will not operate properly. However, while 4.1BSD +binaries will execute under \*(4B +it is \fBSTRONGLY RECOMMENDED\fP that the programs be recompiled under +the new system. +.FE +.\} +.PP +The easiest upgrade path from 4.2BSD or \*(Ps +(depending on your file system configuration) +is to build +new root and \fI/usr\fP file systems on unused partitions, +then copy or merge site specific files +into their corresponding files on the new system. +All user file systems can be retained unmodified, +except that the new \fIfsck\fP should be run +before they are mounted (see below). +.PP +Section 3.1 lists the files to be saved as part of the conversion process. +Section 3.2 describes the bootstrap process. +Section 3.3 discusses the merger of the saved files back into the new system. +Section 3.4 provides general hints on possible problems to be +aware of when converting from 4.2BSD to \*(4B. +.NH 2 +Files to save +.PP +The following list enumerates the standard set of files you will want to +save and suggests directories in which site-specific files should be present. +This list will likely be augmented with non-standard files you +have added to your system. +If you do not have enough space to create parallel +file systems, you should create a \fItar\fP image of the +following files before the new file systems are created. +In addition, it is +\fBSTRONGLY\fP advised that you do a full dump before rebuilding the file +system to guard against missing something the first time around. +.DS +.TS +l c l. +/.cshrc \(dg root csh startup script +/.login \(dg root csh login script +/.profile \(dg root sh startup script +/.rhosts \(dg for trusted machines and users +/dev/MAKEDEV \(dd in case you added anything here +/dev/MAKEDEV.local * for making local devices +/etc/disktab \(dd in case you changed disk partition sizes +/etc/fstab \(dg disk configuration data +/etc/ftpusers \(dg for local additions +/etc/gateways \(dg routing daemon database +/etc/gettytab \(dd getty database +/etc/group * group data base +/etc/hosts \(dg for local host information +/etc/hosts.equiv \(dg for local host equivalence information +/etc/networks \(dg for local network information +/etc/passwd * user data base +/etc/printcap \(dg line printer database +/etc/protocols \(dd in case you added any local protocols +/etc/rc * for any local additions +/etc/rc.local * site specific system startup commands +/etc/remote \(dg auto-dialer configuration +/etc/services \(dd for local additions +/etc/syslog.conf * system logger configuration +/etc/securettys * for restricted list of ttys where root can log in +/etc/ttys * terminal line configuration data +/etc/ttytype * terminal line to terminal type mapping data +/etc/termcap \(dd for any local entries that may have been added +/lib \(dd for any locally developed language processors +/usr/dict/* \(dd for local additions to words and papers +/usr/hosts/MAKEHOSTS * for local changes +/usr/include/* \(dd for local additions +/usr/lib/aliases \(dd mail forwarding data base +/usr/lib/crontab * cron daemon data base +/usr/lib/font/* \(dd for locally developed font libraries +/usr/lib/lib*.a \(dg for locally libraries +/usr/lib/lint/* \(dd for locally developed lint libraries +/usr/lib/sendmail.cf * sendmail configuration +/usr/lib/tabset/* \(dd for locally developed tab setting files +/usr/lib/term/* \(dd for locally developed nroff drive tables +/usr/lib/tmac/* \(dd for locally developed troff/nroff macros +/usr/lib/uucp/* \(dg for local uucp configuration files +/usr/man/manl * for manual pages for locally developed programs +/usr/msgs \(dg for current msgs +/usr/spool/* \(dg for current mail, news, uucp files, etc. +/usr/src/local \(dg for source for locally developed programs +/sys/conf/HOST \(dg configuration file for your machine +/sys/conf/files.HOST \(dg list of special files in your kernel +/*/quotas \(dg file system quota files +.TE +.sp +\(dg\|Files that can be used from 4.2BSD or \*(Ps without change. +\(dd\|Files that need local modifications merged into \*(4B files. +*\|Files that require special work to merge and are discussed +in section 3.3. +.DE +.NH 2 +Installing \*(4B +.PP +.if \n(Vx \{\ +\fBNote\fP: The \*(4B release contains only Tahoe filesystems and executable +images. +In order to bring up \*(4B on a VAX, it is necessary to extract the sources +on a VAX, compile and install. +Most of the files listed above are found in /usr/src/sys/vaxdist +as well as in their standard locations on the distribution tape +so that the root and /usr images need not be extracted from the tape. +The following sections describe the procedure for installing \*(4B +on the Tahoe. +For a VAX system, the starting root and /usr filesystems can be created +by building and installing executables using alternate filesystems. +.\} +The next step is to build a working \*(4B system. +This can be done by following the steps in section 2 of +this document for extracting the root and /usr file systems +from the distribution tape onto unused disk partitions. +If you have a running 4.2BSD or \*(Ps system, +you can also do this by using +.IR dd (1) +to copy the \*(lqmini root\*(rq filesystem onto one disk partition, +then use it to load the \*(4B root filesystem as in chapter 2. +The root filesystem dump on the tape could also be extracted directly, +although this will require an additional file system check after booting \*(4B +to convert the new root filesystem. +The exact procedure chosen will depend on the disk configuration +and the number of suitable disk partitions that may be used. +If there is insufficient space to load the new root and \fI/usr\fP +filesystems before reusing the existing partitions, +it is \fBSTRONGLY\fP advised that you make full dumps of each filesystem +on magtape before beginning. +It is also desirable to run file system checks +of all filesystems to be converted to \*(4B before shutting down. +If you are running a system older than 4.2BSD, you will have to +dump and restore your file systems; see section 2.1 for some hints. +In either case, this is an excellent time to review your disk configuration +for possible tuning of the layout. +Section 4.2 and \fIconfig\fP(8) are required reading. +.PP +To ease the transition to new kernels, +the 4.3BSD and \*(4B +bootstrap routines pass the identity of the boot device +through to the kernel. +The kernel then uses that device as its root file system. +Thus, for example, if you boot from \fI/dev/\*(Dk1a\fP, +the kernel will use \*(Dk1a as its root file system. +If \fI/dev/\*(Dk1b\fP is configured as a swap partition, +it will be used as the initial swap area, +otherwise the normal primary swap area (\fI/dev/\*(Dk0b\fP) will be used. +The \*(4B bootstrap is backward compatible with 4.2BSD and \*(Ps, +so you can replace your old bootstrap if you use it +to boot your first \*(4B kernel. +.PP +Once you have extracted the \*(4B system and booted from it, +you will have to build a kernel customized for your configuration. +If you have any local device drivers, +they will have to be incorporated into the new kernel. +See section 4.1.3 and ``Building 4.3BSD UNIX Systems with Config.'' +.PP +If converting from 4.2BSD, \*(Ps, or the CCI 1.21 release, your old +file systems must be converted. +.if \n(Vx \{\ +The standard disk partitions in \*(4B are the same as those +in 4.2BSD and \*(Ps, +except for those on the DEC UDA50; see section 4.3.2 for details. +.\} +If you've modified the partition +sizes from the original BSD or CCI ones, and are not already using the +\*(4B disk labels, you will have to modify the default disk partion +tables in the kernel. Make the necessary table changes and boot +your custom kernel \fBBEFORE\fP trying to access any of your old +file systems! After doing this, if necessary, the remaining filesystems +may be converted in place by running the \*(4B version of +.IR fsck (8) +on each filesystem and allowing it to make the necessary corrections. +The new version of \fIfsck\fP is more +strict about the size of directories than the version supplied with 4.2BSD. +Thus the first time that it is run on a 4.2BSD file system, +it will produce messages of the form: +.DS +.if \n(Vx \{\ +\fBDIRECTORY ...: LENGTH\fP xx \fBNOT MULTIPLE OF 512 (ADJUSTED)\fP +.\} +.if \n(Th \{\ +\fBDIRECTORY ...: LENGTH\fP xx \fBNOT MULTIPLE OF 1024 (ADJUSTED)\fP +.\} +.DE +Length ``xx'' will be the size of the directory; +it will be expanded to the next multiple of +.if \n(Vx \{\ +512 +.\} +.if \n(Th \{\ +1024 +.\} +bytes. +The new \fIfsck\fP will also set default \fIinterleave\fP and +\fInpsect\fP (number of physical sectors per track) values on older +file systems, in which these fields were unused spares; this correction +will produce messages of the form: +.DS +\fBIMPOSSIBLE INTERLEAVE=0 IN SUPERBLOCK (SET TO DEFAULT)\fP* +\fBIMPOSSIBLE NPSECT=0 IN SUPERBLOCK (SET TO DEFAULT)\fP +.DE +.FS +* The defaults are to set \fIinterleave\fP to 1 and +\fInpsect\fP to \fInsect\fP; +.if \n(Vx \{\ +this is correct on many drives. +Notable exceptions are the RM80 and RA81, +where npsect should be set to +one more than nsect. +This affects only performance (and in the case +of the RA81, at least, virtually unmeasurably). +.\} +.if \n(Th \{\ +this is correct on all drives supported on the CCI. +.\} +.FE +File systems that have had their interleave and npsect values +set will be diagnosed by the old \fIfsck\fP as having a bad superblock; +the old \fIfsck\fP will run only if given an alternate superblock +.if \n(Vx \{\ +(\fIfsck \-b32\fP), +.\} +.if \n(Th \{\ +(\fIfsck \-b16\fP), +.\} +in which case it will re-zero these fields. +The \*(4B kernel will internally set these fields to their defaults +if fsck has not done so; again, the +.if \n(Vx \{\ +\fI\-b32\fP +.\} +.if \n(Th \{\ +\fI\-b16\fP +.\} +option may be +necessary for running the old \fIfsck\fP. +.PP +In addition, \*(4B removes several limits on file system sizes +that were present in both 4.2BSD and 4.3BSD. +The limited file systems +continue to work in \*(4B, but should be converted +as soon as it is convenient +by running \fIfsck\fP with the \fI\-c\fP option. +If no file systems have been so converted, +the sequence \fIfsck \-p \-c\fP will update all of them, +fix the interleave and npsect fields, +and fix any incorrect directory lengths +all at once. +The new unlimited file system formats are treated as read-only +by older systems. +A second \fIfsck \-c\fP, however, will +reconvert the new format to the old if none of the static limits +of the old file system format have been exceeded. +The new file systems are otherwise +compatible between 4.2BSD, \*(Ps, and \*(4B, +though running a \*(4B file system under older systems +may cause more of the above +messages to be generated the next time it is \fIfsck\fP'ed on \*(4B. +.NH 2 +.if \n(Th \{\ +Merging your files from 4.2BSD into \*(4B +.\} +.if \n(Vx \{\ +Merging your files from 4.2 or 4.3BSD into \*(4B +.\} +.PP +When your system is booting reliably and you have the \*(4B +root and /usr file systems fully installed you will be ready +to continue with the next step in the conversion process, +merging your old files into the new system. +.PP +If you saved the files on a \fItar\fP tape, extract them +into a scratch directory, say /usr/convert: +.DS +\fB#\fP \fImkdir /usr/convert\fP +\fB#\fP \fIcd /usr/convert\fP +\fB#\fP \fItar xp\fP +.DE +.PP +The data files marked in the previous table with a dagger (\(dg) +may be used without change from the previous system. +Those data files marked with a double dagger (\(dd) have syntax +changes or substantial enhancements. +You should start with the \*(4B version and carefully +integrate any local changes into the new file. +Usually these local modifications can be incorporated +without conflict into the new file; +some exceptions are noted below. +The files marked with an asterisk (*) require +particular attention and are discussed below. +.PP +If you have any homegrown device drivers in /dev/MAKEDEV.local +that use major device numbers reserved by the system you +will have to modify the commands used to create the devices or alter +the system device configuration tables in /sys/\*(mC/conf.c. +Otherwise /dev/MAKEDEV.local can be used without change +from 4.2 or \*(Ps. +.PP +System security changes require adding several new ``well-known'' groups +to /etc/group. +The groups that are needed by the system as distributed are: +.DS +.TS +l c. +name number +_ +wheel 0 +daemon 1 +kmem 2 +sys 3 +tty 4 +operator 5 +bin 10 +.TE +.DE +Only users in the ``wheel'' group are permitted to \fIsu\fP to ``root''. +Most programs that manage directories in /usr/spool +now run set-group-id to ``daemon'' so that users cannot +directly access the files in the spool directories. +The special files that access kernel memory, /dev/kmem +and /dev/mem, are made readable only by group ``kmem''. +Standard system programs that require this access are +made set-group-id to that group. +The group ``sys'' is intended to control access to kernel sources, +and other sources belong to group ``bin.'' +Rather than make user's terminals writable by all users, +they are now placed in group ``tty'' and made only group writable. +Programs that should legitimately have access to write on user's terminals +such as \fItalkd\fP and \fIwrite\fP now run set-group-id to ``tty''. +The ``operator'' group controls access to disks. +By default, disks are readable by group ``operator'', +so that programs such as \fIdf\fP can access the file system +information without being set-user-id to ``root''. +The +.IR shutdown (8) +program is executable only by group operator +and is setuid to root so that members of group operator may shut down +the system without root access. +.PP +Several new users have also been added to the group of ``well-known'' users +in /etc/passwd. +The current list is: +.DS +.TS +l c. +name number +_ +root 0 +daemon 1 +operator 2 +games 7 +uucp 66 +nobody 32767 +.TE +.DE +The ``daemon'' user is used for daemon processes that +do not need root privileges. +The ``operator'' user-id is used as an account for dumpers +so that they can log in without having the root password. +By placing them in the ``operator'' group, +they can get read access to the disks. +The ``uucp'' login has existed long before \*(4B, +and is noted here just to provide a common user-id. +The password entry ``nobody'' has been added to specify +the user with least privilege. The ``games'' user is a pseudo-user +that controls access to game programs. +.PP +After installing your updated password file, +you must run \fImkpasswd\fP\|(8) to create the \fIndbm\fP +password database. +Note that \fImkpasswd\fP is run whenever \fIvipw\fP\|(8) is run. +.PP +The format of the cron table, /usr/lib/crontab, has been changed +to specify the user-id that should be used to run a process. +The userid ``nobody'' is frequently useful for non-privileged programs. +.PP +Some of the commands previously in /etc/rc.local have been +moved to /etc/rc; +several new functions are now handled by /etc/rc, /etc/netstart +and /etc/rc.local. +You should look closely at the prototype version of these files +and read the manual pages for the commands contained in it +before trying to merge your local copy. +Note in particular that \fIifconfig\fP has had many changes, +and that host names are now fully specified as domain-style names +(e.g, monet.Berkeley.EDU) for the benefit of the name server. +.PP +The C library and system binaries on the distribution tape +are compiled with new versions of +\fIgethostbyname\fP and \fIgethostbyaddr\fP which use +the name server, +.IR named (8). +If you have only a small network and are not connected +to a large network, you can use the distributed library routines without +any problems; they use a linear scan of the host table \fI/etc/hosts\fP +if the name server is not running. +If you are on the DARPA Internet or have a large local network, +it is recommend that you set up +and use the name server. +For instructions on how to set up the necessary configuration files, +refer to ``Name Server Operations Guide for BIND''. +Several programs rely on the host name returned by \fIgethostname\fP +to determine the local domain name. +.PP +If you want to compile your system to use the +host table lookup routines instead of the name server, you will +need to modify /usr/src/lib/libc/Makefile according to the instructions there +and then recompile all of the system and local programs (see section 6.6). +Next, you must run \fImkhosts\fP\|(8) to create the \fIndbm\fP +host table database from \fI/etc/hosts\fP. +.PP +The format of /etc/ttys has changed, see \fIttys\fP\|(5) +for details. +It now includes the terminal type and security options that were previously +placed in /etc/ttytype and /etc/securettys. +.PP +There is a new version of \fIsyslog\fP that uses a more generalized +facility/priority scheme. +This has changed the format of the syslog.conf file. +See \fIsyslogd\fP\|(8) for details. +\fISyslog\fP now logs kernel errors, +allowing events such +as soft disk errors, filesystem-full messages, and other such error messages +to be logged without slowing down the system +while the messages print on the console. +It is also used by many of the system daemons +to monitor system problems more closely, for example +network routing changes. +.PP +If you are using the name server, your \fIsendmail\fP configuration +file will need some minor updates to accommodate it. +See the ``Sendmail Installation and Operation Guide'' and the sample +\fIsendmail\fP configuration files in /usr/src/usr.lib/sendmail/cf. +The sendmail.cf's supplied with this release are alleged to be +``generic'', but have only really seen use at Berkeley. In particular +there are two points to watch out for. First, all host names in the +sendmail.cf itself must be fully qualified names. Second, the +sendmail.cf's assume you have a /usr/lib/sendmail that was compiled +with the resolver library (i.e., not hosttables). This is necessary +to canonicalize unqualified names into fully-qualified names (e.g., +foo -> foo.bar.com). Using these .cf files with a host table can +probably be done, but it will be difficult. +Be sure to regenerate your sendmail frozen configuration file after +installation of your updated configuration file with the command +\fI/usr/lib/sendmail -bz\fP. +The aliases file, +/usr/lib/aliases has also been changed to add certain well-known addresses. +.PP +The spooling directories saved on tape may be restored in their +eventual resting places without too much concern. Be sure to +use the `p' option to \fItar\fP so that files are recreated with the +same file modes: +.DS +\fB#\fP \fIcd /usr\fP +\fB#\fP \fItar xp msgs spool/mail spool/uucp spool/uucppublic spool/news\fP +.DE +.PP +The following two sections contain additional notes concerning +changes in \*(4B that affect the installation of local files; +be sure to read them as well. +.NH 2 +Hints on converting from 4.2BSD to \*(4B +.PP +This section summarizes the most significant changes between +4.2BSD and 4.3BSD, particularly those that are likely to +cause difficulty in doing the conversion. +It does not include changes in the network; +see chapter 5 for information on setting up the network. +.PP +The mailbox locking protocol has changed; +it now uses the advisory locking facility to avoid concurrent +update of users' mail boxes. +If you have your own mail interface, be sure to update its locking protocol. +.PP +The kernel's limit on the number of open files has been +increased from 20 to 64. It is now possible to change this limit almost +arbitrarily (there used to be a hard limit of 30). The standard I/O library +autoconfigures to the kernel limit. +Note that file (``_iob'') entries may be allocated +by \fImalloc\fP from \fIfopen\fP; +this allocation has been known to cause problems with programs +that use their own memory allocators. +This does not occur until after 20 files have been opened +by the standard I/O library. +.PP +\fISelect\fP can be used with more than 32 descriptors +by using arrays of \fBint\fPs for the bit fields rather than single \fBint\fPs. +Programs that used \fIgetdtablesize\fP as their first argument to \fIselect\fP +will no longer work correctly. +Usually the program can be modified to correctly specify the number +of bits in an \fBint\fP. +Alternatively the program can be modified to use an array of \fBint\fPs. +There are a set of macros available in \fI\fP to simplify this. +See +.IR select (2). +.PP +Old core files will not be intelligible by the current debuggers +because of numerous changes to the user structure +and because the kernel stack has been enlarged. +The \fIa.out\fP header that was in the user structure is no longer present. +Locally-written debuggers that try to check the magic number +will need modification. +.PP +\fIFind\fP now has a database of file names, +constructed once a week from \fIcron\fP. +To find a file by name only, +the command \fIfind name\fP will look in the database for +files that match the name. This is much faster than +\fIfind / \-name name \-print\fP. +.PP +Files may not be deleted from directories having the ``sticky'' (ISVTX) bit +set in their modes +except by the owner of the file or of the directory, or by the superuser. +This is primarily to protect users' files in publicly-writable directories +such as \fI/tmp\fP and \fI/usr/tmp\fP. +All publicly-writable directories should have their ``sticky'' bits set +with ``chmod +t.'' +.PP +The include file \fI\fP has returned to \fI/usr/include\fP, +and again contains the definitions for the C library time routines of +\fIctime\fP\|(3). +.PP +The \fIcompact\fP and \fIuncompact\fP programs have been supplanted +by the faster \fIcompress\fP. +If your user population has \fIcompact\fPed files, you will want +to install \fIuncompact\fP from /usr/src/old/compact. +.PP +The configuration of the virtual memory limits has been simplified. +A MAXDSIZ option, specified in bytes in the machine configuration file, +may be used to raise the maximum process region size from +the default of 17Mb to 32Mb or 64Mb. +The initial per-process limit is still 6Mb, +but can be raised up to MAXDSIZ with the \fIcsh limit\fP command. +.PP +Some \*(4B binaries will not run with a 4.2BSD kernel because +they take advantage of new functionality in \*(4B. +One noticeable example of this problem is \fIcsh\fP. +.if \n(Th \{\ +Also, most terminal \fIioctl\fP operations are incompatible +between \*(4B and the vendor-supplied versions of 4.2BSD. +.\} +.PP +If you want to use \fIps\fP after booting a new kernel, +and before going multiuser, you must initialize its name list +database by running \fIps \-U\fP. +.NH 2 +Hints on converting from 4.3BSD to \*(4B +.PP +The largest visible change between 4.3BSD to \*(4B +(other than the addition of support for the Tahoe processor) +is the addition of support for disk labels. +This facility allows each disk or disk pack to contain all geometry +information about the disk and the partition layout for the disk. +Disk labels are supported on all disk types on the Tahoe machines, +and on hp and ra/rd disks on the VAX. +See section 2.1.6 as well as +.IR disklabel (8) +and +.IR disklabel (5). +Installation of this facility requires use of the new kernel and device +drivers, bootstraps and other standalone programs, +/etc/disktab, +.if \n(Vx \{\ +.IR bad144 (8V), +.\} +.IR newfs (8), +and probably other programs. +.PP +The bootstrap programs have been fixed to work on MicroVAX IIs +and VAXstation II's with QVSS (VS II) or QDSS (GPX) displays; +the kernel includes support for these displays, courtesy of Digital +Equipment Corp. +In order to install the bootstrap on RD52/53/54 disks with +.IR disklabel (8), +the new /etc/disktab must be used, +or the block 0 bootstrap must be explictly listed as /usr/mdec/rdboot +(\fInot\fP raboot). +.\} +.PP +The order in which daemons are started by /etc/rc and /etc/rc.local +has changed, and network initialization has been split into /etc/netstart. +Look at the prototype files, and modify /etc/rc.local as necessary; +c.f. section 5.6.1. +.PP +\*(4B includes the Olson +timezone implementation, which uses timezone and daylight-savings-time +rules loaded from files in /etc/zoneinfo; see +.IR ctime (3) +and +.IR tzfile (5). +.PP +The type of the +.IR sprintf (3S) +function has been changed from \fIchar *\fP in 4.2BSD and 4.3BSD +to \fIint\fP as in the proposed ANSI C standard and in System V. +Programers are discouraged from using the return value from +.I sprintf +until this change is ubiquitous. +Fortunately, the previous return value from +.I sprintf +was essentially useless. +.PP +The ownership and modes of some directories have changed. +The \fIat\fP programs now run set-user-id ``root'' instead of ``daemon.'' +Also, the uucp directory no longer needs to be publicly writable, +as \fItip\fP reverts to privileged status to remove its lock files. +After copying your version of /usr/spool, you should do: +.DS +\fB#\fP \fIchown \-R root /usr/spool/at\fP +\fB#\fP \fIchown \-R uucp.daemon /usr/spool/uucp\fP +\fB#\fP \fIchmod \-R o\-w /usr/spool/uucp\fP +.DE +.PP +The MAKEHOSTS file has moved from /usr/hosts to /usr. +.PP +The source versions of the manual pages have been moved from +/usr/man/man[1-8] to /usr/src/man, /usr/src/new/man, and /usr/src/local/man. +Local manual pages should be moved into their respective source code +directories, or into /usr/src/local/man/man[1-8], and Makefiles changed to +install the formatted manual pages into /usr/local/man/cat[1-8]. The shell +script /usr/man/manroff calls nroff with the standard manual arguments. An +example of installing a manual page might be: +.DS +\fB#\fP \fI/usr/man/manroff example.2 > example.0\fP +\fB#\fP \fIinstall -o bin -g bin -m 444 example.0 /usr/local/man/cat2\fP +.DE +.PP +Whatever else is left is likely to be site specific or require +careful scrutiny before placing in its eventual resting place. +Refer to the documentation and source code +before arbitrarily overwriting a file. diff --git a/usr/othersrc/share/doc/smm/01.setup/common/4.t b/usr/othersrc/share/doc/smm/01.setup/common/4.t new file mode 100644 index 0000000000..e8a6bc55b2 --- /dev/null +++ b/usr/othersrc/share/doc/smm/01.setup/common/4.t @@ -0,0 +1,1353 @@ +.\" Copyright (c) 1980, 1986, 1988 The Regents of the University of California. +.\" 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 6.6 (Berkeley) 4/17/91 +.\" +.de IR +\fI\\$1\fP\|\\$2 +.. +.ds LH "Installing/Operating \*(4B +.nr H1 4 +.nr H2 0 +.ds CF \*(DY +.ds RH "System setup +.bp +.LG +.B +.ce +4. SYSTEM SETUP +.sp 2 +.R +.NL +.PP +This section describes procedures used to set up a \*(Mc 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. +.if \n(Vx \{\ +.NH 2 +Creating UNIX boot media +.PP +The procedures for making the various UNIX boot media are described in this +section. If you have an 8200 or 11/780, you will need to make a floppy. +For an 11/730, you will need to make a cassette. For an +8600, you will need to make a console RL02 pack. +.PP +The boot command files are all set up for booting off of the first +UNIBUS or MASSBUS. If you are booting off of a different UNIBUS +or MASSBUS, you will need to modify the boot command files appropriately. +.NH 3 +Making a UNIX boot console RL02 pack +.PP +If you have an 8600 you will want to create a +.UX +boot console RL02 pack by adding some files to your current DEC +console pack, using +\fIarff\fP\|(8). +If you do not want to modify your current DEC console pack, you may +make a copy of it first using +\fIdd\fP\|(1). +This pack will make standalone system operations such as +bootstrapping much easier. +.PP +First change into the directory where the console RL02 +information is stored: +.DS +\fB#\fI cd /sys/consolerl\fR +.DE +then set up the default boot device. +If you have an RK07 as your primary root do: +.DS +\fB#\fI cp defboo.hk defboo.com\fR +.DE +If you have a drive on a UDA50 (e.g. an RA81) as your +primary root do: +.DS +\fB#\fI cp defboo.ra defboo.com\fR +.DE +If you have a second vendor +UNIBUS storage module as your primary root do: +.DS +\fB#\fI cp defboo.up defboo.com\fR +.DE +Otherwise: +.DS +\fB#\fI cp defboo.hp defboo.com\fR +.DE +The final step in updating the console RL02 pack is: +.DS +\fB#\fI make update\fR +.DE +More copies of this console RL02 pack can be made using +.IR dd (1). +.NH 3 +Making a UNIX boot floppy +.PP +If you have an 8200 or 11/780 you will want to create a +.UX +boot floppy by adding some files to a copy of your current DEC +console floppy, using either +.IR flcopy (8) +or +.IR dd \|(1), +and using +.IR arff \|(8). +This floppy will make standalone system operations such as +bootstrapping much easier. +.PP +First change into the directory where the console floppy +information is stored: +.DS +\fB#\fI cd /sys/floppy\fR +.DE +then set up the default boot device. +If you have an RK07 as your primary root do: +.DS +\fB#\fI cp defboo.hk defboo.cmd\fR +.DE +If you have a drive on a UDA50 (e.g. an RA81) as your +primary root do: +.DS +\fB#\fI cp defboo.ra defboo.cmd\fR +.DE +If you have a second vendor +UNIBUS storage module as your primary root do: +.DS +\fB#\fI cp defboo.up defboo.cmd\fR +.DE +If you have a drive on a KDB50 as your primary root do: +.DS +\fB#\fI cp defboo.kra defboo.cmd\fR +.DE +Otherwise: +.DS +\fB#\fI cp defboo.hp defboo.cmd\fR +.DE +On an 11/780, +if the local configuration requires any changes in restar.cmd +or defboo.cmd (e.g., for interleaved old-style memory controllers see +defboo.MS780C-interleaved), +these should be made now. +The following command will then copy your DEC local console floppy, +updating the copy appropriately. +.DS +\fB#\fI make update\fR +\fBChange Floppy, Hit return when done.\fP +(waits for you to put clean floppy in console) +\fBAre you sure you want to clobber the floppy?\fI yes\fR +.DE +More copies of this floppy can be made using +.IR flcopy (8). +.PP +On an 8200, copy any of the DEC diagnostic floppies +by placing the source in console drive 1 and the destination +in console drive 2, then: +.DS +.\" XXX be sure to put /dev/csa? in root fs, or makedev first +\fB#\fI dd if=/dev/csa1 of=/dev/csa2 bs=400k\fR +\fB1+0 records in\fP +\fB1+0 records out\fP +.DE +Next remove all but the first few files, leaving only those +that lead up to ``boot58.exe'' (as well as boot58.exe itself). +It is a good idea to remove +the original floppy from drive 1 first. +.DS +\fB#\fI arff tmf /dev/csa2\fR +\&...(should list something like ``fg81.ve0'', followed by ``boot58.exe''; +then a series of files that may be deleted)...\fP +\fB#\fI arff dmf /dev/csa2\fR files to delete from previous list +.DE +Finally, add UNIX boot files: +.DS +\fB#\fI arff rmf /dev/csa2 boot format copy *boo.cmd\fR +.DE +Put the new boot floppy in drive 1. To make copies of this floppy, +use the same +.I dd +command shown above. +.NH 3 +Making a UNIX boot cassette +.PP +If you have an 11/730 you will want to create a +.UX +boot cassette by adding some files to a copy of +your current DEC console cassette, using +\fIflcopy\fP\|(8) and \fIarff\fP\|(8). +This cassette will make standalone system operations such as +bootstrapping much easier. +.PP +First change into the directory where the console cassette +information is stored: +.DS +\fB#\fI cd /sys/cassette\fR +.DE +then set up the default boot device. +If you have an IDC storage module as your primary root do: +.DS +\fB#\fI cp defboo.rb defboo.cmd\fR +.DE +If you have an RK07 as your primary root do: +.DS +\fB#\fI cp defboo.hk defboo.cmd\fR +.DE +If you have a drive on a UDA50 as your primary root do: +.DS +\fB#\fI cp defboo.ra defboo.cmd\fR +.DE +Otherwise: +.DS +\fB#\fI cp defboo.up defboo.cmd\fR +.DE +To complete the procedure place your DEC local +console cassette in +drive 0 (the drive at front of the CPU); +the following command will then copy it, +updating the copy appropriately. +.DS +\fB#\fI make update\fR +\fBChange Floppy, Hit return when done.\fP +(waits for you to put clean cassette in console drive 0) +\fBAre you sure you want to clobber the floppy?\fI yes\fR +.DE +More copies of this cassette can best be made using +.IR dd (1). +.\} +.NH 2 +Kernel configuration +.PP +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''. +.NH 3 +Kernel organization +.PP +As distributed, the kernel source is in a +separate tar image. The source may be physically +located anywhere within any file system 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. +.PP +The directory /sys/sys +contains the mainline machine independent +operating system code. +Files within this directory are conventionally +named with the following prefixes: +.DS +.TS +lw(1.0i) l. +init_ system initialization +kern_ kernel (authentication, process management, etc.) +quota_ disk quotas +sys_ system calls and similar +tty_ terminal handling +ufs_ file system +uipc_ interprocess communication +vm_ virtual memory +.TE +.DE +.PP +The remaining directories are organized as follows: +.DS +.TS +lw(1.0i) l. +/sys/h machine-independent include files +/sys/conf site configuration files and basic templates +/sys/kdb machine-independent part of the kernel debugger +/sys/net protocol-independent, but network-related code +/sys/netimp IMP support code +/sys/netinet DARPA Internet code +/sys/netns Xerox NS code +/sys/stand machine-independent standalone code +/sys/tahoe Tahoe-specific mainline code +/sys/tahoealign Tahoe unaligned-reference emulation code +/sys/tahoedist Tahoe distribution files +/sys/tahoeif Tahoe network interface code +/sys/tahoevba Tahoe VERSAbus device drivers and related code +/sys/tahoemath Tahoe floating point emulation code +/sys/tahoestand Tahoe standalone device drivers and related code +/sys/vax VAX-specific mainline code +/sys/vaxbi VAX BI device drivers and related code +/sys/vaxdist VAX distribution files +/sys/vaxif VAX network interface code +/sys/vaxmba VAX MASSBUS device drivers and related code +/sys/vaxstand VAX standalone device drivers and boot code +/sys/vaxuba VAX UNIBUS device drivers and related code +.TE +.DE +.PP +Many of these directories are referenced through /usr/include with +symbolic links. For example, /usr/include/sys is a symbolic +link to /sys/h. The system code, as distributed, is totally +independent of the include files in /usr/include. This allows +the system to be recompiled from scratch without the /usr file +system mounted. +.NH 3 +Devices and device drivers +.PP +Devices supported by UNIX are implemented in the kernel +by drivers whose source is kept in +.if \n(Vx \{\ +/sys/vax, /sys/vaxbi, /sys/vaxuba, or /sys/vaxmba. +.\} +.if \n(Th \{\ +/sys/tahoe or /sys/tahoevba. +.\} +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 file system, made by the +.IR 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. +.PP +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 /newdev directory. +.if \n(Vx \{\ +For instance, if your machine has a single DZ11, a single +DH11, a single DMF32, an RM03 disk, an EMULEX UNIBUS SMD disk controller, an +AMPEX 9300 disk, and a TE16 tape drive you would do: +.\} +.if \n(Th \{\ +For instance, if your machine has a single VIOC terminal +multiplexor, two CDC 340 megabyte Winchester drives, and +a single Cipher tape drive you would do: +.\} +.DS +\fB#\fP \fIcd /\fP +\fB#\fP \fImkdir newdev\fP +\fB#\fP \fIcp dev/MAKEDEV newdev/MAKEDEV\fP +\fB#\fP \fIcd newdev\fP +.if \n(Vx \{\ +\fB#\fP \fIMAKEDEV dz0 dh0 dmf0 hp0 up0 ht0 std LOCAL\fP +.\} +.if \n(Th \{\ +\fB#\fP \fIMAKEDEV vx0 dk0 dk1 cy0 std LOCAL\fP +.\} +.DE +Note the ``std'' argument causes standard devices +such as \fI/dev/console\fP, the machine console, +.if \n(Vx \{\ +\fI/dev/floppy\fP, +the console floppy disk interface for the 11/780 and 11/785, and +\fI/dev/tu0\fP and \fI/dev/tu1\fP, the console cassette interfaces +for the 11/750 and 11/730, +.\} +to be created. +.PP +You can then do +.DS +\fB#\fP \fIcd /\fP +\fB#\fP \fImv dev olddev ; mv newdev dev\fP +\fB#\fP \fIsync\fP +.DE +to install the new device directory. +.NH 3 +Building new system images +.PP +The kernel configuration of each UNIX system is described by +a single configuration file, stored in the \fI/sys/conf\fP 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'', +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/conf +directory. +.PP +The configured system image ``vmunix'' should be +copied to the root, and then booted to try it out. +It is best to name it /newvmunix so as not to destroy +the working system until you're sure it does work: +.DS +\fB#\fP \fIcp vmunix /newvmunix\fP +\fB#\fP \fIsync\fP +.DE +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 \fI/genvmunix\fP 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 \fI/vmunix\fP before going into multiuser operation. +A systematic scheme for numbering and saving old versions +of the system may be useful. +.NH 2 +Disk configuration +.PP +This section describes how to layout file systems to make use +of the available space and to balance disk load for better system +performance. +.NH 3 +Initializing /etc/fstab +.PP +.if \n(Vx \{\ +Change into the directory /etc and copy the appropriate file from: +.DS +fstab.rm03 +fstab.rm05 +fstab.rm80 +fstab.ra60 +fstab.ra80 +fstab.ra81 +fstab.rb80 +fstab.rp06 +fstab.rp07 +fstab.rk07 +fstab.up160m (160MB up drives) +fstab.hp400m (400MB hp drives) +fstab.up (other up drives) +fstab.hp (other hp drives) +.DE +to the file /etc/fstab, i.e.: +.DS +\fB#\fI cd /etc\fR +\fB#\fI cp \fIfstab.xxx\fP fstab\fR +.DE +.PP +This will set up the default information about the usage of disk +partitions, which we see how to update more below. +.\} +.if \n(Th \{\ +The names of the disks on \*(4B all use the basename \fIdk\fP, +unlike other systems on the Tahoe. +Unfortunately, the console processor reads the file \fI/etc/fstab\fP +and expects disk names that indicate the type of disk drive. +Therefore, the first line in \fI/etc/fstab\fP is a dummy line +to satisfy the console processor: +.DS +/dev/fsd0a:/:xx:1:1 +.DE +If your root disk is a type other than \fIfsd\fP, +edit \fI/etc/fstab\fP to change the first device +to the appropriate type. +.\} +.NH 3 +Disk naming and divisions +.PP +Each physical disk drive can be divided into up to 8 partitions; +UNIX typically uses only 3 or 4 partitions. +For instance, on an \*(Dn, +the first partition, \*(Dk0a, +is used for a root file system, a backup thereof, +or a small file system like, /tmp; +the second partition, \*(Dk0b, +is used for paging and swapping; and +the third partition, \*(Dk0\*(Pa, +holds a user file system. +.if \n(Vx \{\ +On an RM05, the first three partitions +are used as for the \*(Dn, and the fourth partition, \*(Dk0h, +holds the /usr file system, including source code. +.\} +.if !\n(Th \{\ +.PP +The disk partition sizes for a drive are based on a +set of four prototype partition tables; c.f. \fIdiskpart\fP\|(8). +The particular +table used is dependent on the size of the drive. +The ``a'' partition is the same size across all drives, +15884 sectors. The ``b'' partition, used for paging and +swapping, is sized according to the total space on the disk. +For drives less than about 400 megabytes the partition +is 33440 sectors, while for larger drives the partition size +is doubled to 66880 sectors. The ``c'' partition is always +used to access the entire physical disk, including the space +at the back of the disk reserved for the bad sector +forwarding table. If the disk is larger than about 250 megabytes, +an ``h'' partition is created with size 291346 sectors, and +no matter whether the ``h'' partition is created or not, the +remainder of the drive is allocated to the ``g'' partition. +Sites that want to split up the ``g'' partition into several +smaller file systems may use the ``d'', ``e'', and ``f'' +partitions that overlap the ``g'' partition. The default +sizes for these partitions are 15884, 55936, and the remainder +of the disk, respectively*. +.FS +* These rules are, unfortunately, not evenly applied to all +disks. \fI/etc/disktab\fP, and the pack label or driver tables, +give the final word; consult section 4 of the manual, and +read /etc/disktab, for more information. +.FE +.PP +The disk partition sizes for DEC RA60, RA80, and RA81 have +changed since 4.2BSD. If upgrading from 4.2BSD, +you will need to decide if you want +to use the new partitions or the old partitions. If you +desire to use the old partitions, you will need to label your packs +as `racompat', or create your own by updating +/etc/disktab. Any +other partition sizes that were modified at your site will +require the same consideration; +if the device driver does not support pack labels, you will have to +update its compiled-in tables as well. +.\} +.PP +The space available on a disk varies per device. The amount of space +available on the common disk partitions is listed in the following table. +Not shown in the table are the partitions of each drive devoted +to the root file system and the paging area. +Many other partitions are listed in the standard partitions, +but most of them are not useful. +Note that the standard partition tables usually list several alternative +ways to divide a disk, but that only nonoverlapping partitions may be used +on any one disk. +.DS +.TS +center; +l l n l n. +Type Name Size Name Size +_ +.if \n(Vx \{\ +rk07 hk?g 13 Mb +rm03 hp?g 41 Mb +rp06 hp?g 145 Mb +rm05 hp?g 80 Mb hp?h 145 Mb +rm80 hp?g 96 Mb +ra60 ra?g 78 Mb ra?h 96 Mb +ra80 ra?g 96 Mb +ra81 ra?g 257 Mb ra?h 145 Mb +rb80 rb?g 41 Mb rb?h 56 Mb +rp07 hp?g 315 Mb hp?h 145 Mb +up300 up?g 80 Mb up?h 145 Mb +up330 up?g 90 Mb up?h 145 Mb +up400 hp?g 216 Mb hp?h 145 Mb +up160 up?g 106 Mb +.\} +.if \n(Th \{\ +xfd dk?c 225 Mb dk?g,h 112 Mb +eagle dk?c 301 Mb +fsd dk?c 106 Mb +.\} +.TE +.DE +.if \n(Vx \{\ +.LP +Here up300 refers to either an AMPEX or CDC 300 megabyte disk on a +MASSBUS or UNIBUS disk controller, up330 refers to either an AMPEX +or FUJITSU 330 megabyte disk on a MASSBUS or UNIBUS controller, +up160 refers to a FUJITSU 160 megabyte disk +on the UNIBUS, and up400 refers to a FUJITSU Eagle 400 megabyte +disk on a MASBUS or UNIBUS disk controller. ``hp'' should be +substituted for ``up'' above if the disk is on the MASSBUS. +Consult the manual pages for the specific controllers for other +supported disks or other partitions. +.PP +Each disk also has a paging area, typically 16 megabytes, and +a root file system of 7.5 megabytes. +.\} +.if \n(Th \{\ +.PP +Each disk also has a paging area and a root file system of between 10 and 30 +Megabytes apiece. +.\} +.\" XXX check +The distributed system binaries occupy about 34 megabytes +.\" XXX check +while the major sources occupy another 32 megabytes. +.if \n(Vx \{\ +This overflows dual RK07, dual RL02 and single RM03 systems, +but fits easily on most other hardware configurations. +.\} +.if \n(Th \{\ +This is unlikely to +overflow even the smallest Tahoe configurations. +.\} +.PP +Be aware that the disks have their sizes +measured in disk sectors (usually 512 bytes), while the UNIX file +system blocks are variable sized. All user programs report +disk space in kilobytes and, where needed, disk sizes are always +specified in units of +sectors. The /etc/disktab file used in labelling disks and making file systems +specifies disk partition sizes in sectors; the default sector size +(DEV_BSIZE as defined in /sys/h/param.h) +may be overridden with the ``se'' attribute. +.if \n(Th \{\ +All SMD disks on Tahoe currently use a sector size of 512 bytes. +.\} +.NH 3 +Layout considerations +.PP +There are several considerations in deciding how +to adjust the arrangement of things on your disks. +The most important is making sure that there is adequate space +for what is required; secondarily, throughput should be maximized. +Paging space is an important parameter. +The system, as distributed, sizes the configured +paging areas each time the system is booted. Further, +multiple paging areas of different size may be interleaved. +.if \n(Vx \{\ +Drives smaller than 400 megabytes have swap partitions of 16 megabytes +while drives larger than 400 megabytes have 32 megabytes. These +values may be changed to get more paging space by changing +the label (or, if labels are unsupported, +the appropriate partition table in the disk driver). +.\} +.PP +Many common system programs (C, the editor, the assembler etc.) +create intermediate files in the /tmp directory, +so the file system where this is stored also should be made +large enough to accommodate +most high-water marks; if you have several disks, it makes +sense to mount this in a ``root'' (i.e. first partition) +file system on another disk. +All the programs that create files in /tmp take +care to delete them, but are not immune to rare events +and can leave dregs. +The directory should be examined every so often and the old +files deleted. +.PP +The efficiency with which UNIX is able to use the CPU +is often strongly affected by the configuration of disk controllers. +For general time-sharing applications, +the best strategy is to try to split the root file system (/), system binaries +(/usr), the temporary files (/tmp), +and the user files among several disk arms, and to interleave +the paging activity among several arms. +.PP +It is critical for good performance to balance disk load. +There are at least five components of the disk load that you can +divide between the available disks: +.DS +1. The root file system. +2. The /tmp file system. +3. The /usr file system. +4. The user files. +5. The paging activity. +.DE +The following possibilities are ones we have used at times +when we had 2, 3 and 4 disks: +.TS +center doublebox; +l | c s s +l | lw(5) | lw(5) | lw(5). + disks +what 2 3 4 +_ +/ 0 0 0 +tmp 1 2 3 +usr 1 1 1 +paging 0+1 0+2 0+2+3 +users 0 0+2 0+2 +archive x x 3 +.TE +.PP +The most important things to consider are to +even out the disk load as much as possible, and to do this by +decoupling file systems (on separate arms) between which heavy copying occurs. +Note that a long term average balanced load is not important; it is +much more important to have an instantaneously balanced +load when the system is busy. +.PP +Intelligent experimentation with a few file system arrangements can +pay off in much improved performance. It is particularly easy to +move the root, the +/tmp +file system and the paging areas. Place the +user files and the +/usr +directory as space needs dictate and experiment +with the other, more easily moved file systems. +.NH 3 +File system parameters +.PP +Each file system is parameterized according to its block size, +fragment size, and the disk geometry characteristics of the +medium on which it resides. Inaccurate specification of the disk +characteristics or haphazard choice of the file system parameters +can result in substantial throughput degradation or significant +waste of disk space. As distributed, +file systems are configured according to the following table. +.DS +.TS +center; +l l l. +File system Block size Fragment size +_ +/ 8 kbytes 1 kbytes +usr 4 kbytes 1 kbytes +users 4 kbytes 1 kbytes +.TE +.DE +.PP +The root file system block size is +made large to optimize bandwidth to the associated +disk; this is particularly important since the +/tmp directory is normally part of the root file or a similar filesystem. +The large block size is also +important as many of the most heavily used programs +are demand paged out of the /bin directory. The +fragment size of 1 kbyte is a ``nominal'' value to use +with a file system. With a 1 kbyte fragment size +disk space utilization is about the same +as with the earlier versions of the file system. +.PP +The usr file system would like to use a 4 kbyte block size +with 512 byte fragment size in an effort to get high performance +while conserving the amount of space wasted by a large fragment +size. However, the tahoe disk controllers require a minimum +block size of 1 Kbyte. Space compaction +has been deemed important here because the source code +for the system is normally placed on this file system. +If the source code is placed on a separate filesystem, +use of an 8 kbyte block size with 1 kbyte fragments might +be considered for improved performance when paging from \fI/usr\fP binaries. +.PP +The file systems for users have a 4 kbyte block +size with 1 kbyte fragment size. These parameters +have been selected based on observations of the +performance of our user file systems. The 4 kbyte +block size provides adequate bandwidth while the +1 kbyte fragment size provides acceptable space compaction +and disk fragmentation. +.PP +Other parameters may be chosen in constructing file +systems, but the factors involved in choosing a block +size and fragment size are many and interact in complex +ways. Larger block sizes result in better +throughput to large files in the file system as +larger I/O requests will then be performed by the +system. However, +consideration must be given to the average file sizes +found in the file system and the performance of the +internal system buffer cache. The system +currently provides space in the inode for +12 direct block pointers, 1 single indirect block +pointer, and 1 double indirect block pointer.* +.FS +* A triple indirect block pointer is also reserved, but +not currently supported. +.FE +If a file uses only direct blocks, access time to +it will be optimized by maximizing the block size. +If a file spills over into an indirect block, +increasing the block size of the file system may +decrease the amount of space used +by eliminating the need to allocate an indirect block. +However, if the block size is increased and an indirect +block is still required, then more disk space will be +used by the file because indirect blocks are allocated +according to the block size of the file system. +.PP +In selecting a fragment size for a file system, at least +two considerations should be given. The major performance +tradeoffs observed are between an 8 kbyte block file system +and a 4 kbyte block file system. Because of implementation +constraints, the block size / fragment size ratio can not +be greater than 8. This means that an 8 kbyte file system +will always have a fragment size of at least 1 kbytes. If +a file system is created with a 4 kbyte block size and a +1 kbyte fragment size, then upgraded to an 8 kbyte block size +and 1 kbyte fragment size, identical space compaction will be +observed. However, if a file system has a 4 kbyte block size +and 512 byte fragment size, converting it to an 8K/1K +file system will result in significantly more space being +used. This implies that 4 kbyte block file systems that +might be upgraded to 8 kbyte blocks for higher performance should +use fragment sizes of at least 1 kbytes to minimize the amount +of work required in conversion. +.PP +A second, more important, consideration when selecting the +fragment size for a file system is the level of fragmentation +on the disk. With an 8:1 fragment to block ratio, storage fragmentation +occurs much sooner, particularly with a busy file system running +near full capacity. By comparison, the level of fragmentation in a +4:1 fragment to block ratio file system is one tenth as severe. This +means that on file systems where many files are created and +deleted, the 512 byte fragment size is more likely to result in apparent +space exhaustion because of fragmentation. That is, when the file +system is nearly full, file expansion that requires locating a +contiguous area of disk space is more likely to fail on a 512 +byte file system than on a 1 kbyte file system. To minimize +fragmentation problems of this sort, a parameter in the super +block specifies a minimum acceptable free space threshold. When +normal users (i.e. anyone but the super-user) attempt to allocate +disk space and the free space threshold is exceeded, the user is +returned an error as if the file system were really full. This +parameter is nominally set to 10%; it may be changed by supplying +a parameter to \fInewfs\fP(8), or by updating the super block of an +existing file system using \fItunefs\fP\|(8). +.PP +In general, unless a file system is to be used +for a special purpose application (for example, storing +image processing data), we recommend using the +values supplied above. +Remember that the current +implementation limits the block size to at most 8 kbytes +and the ratio of block size / fragment size must be 1, 2, 4, or 8. +.PP +The disk geometry information used by the file system +affects the block layout policies employed. The file +/etc/disktab, as supplied, contains the data for most +all drives supported by the system. Before constructing +a file system with \fInewfs\fP\|(8) +you should label the disk (if it has not yet been labeled, +and the driver supports labels). +If labels cannot be used, you must instead +specify the type of disk on which the file system resides; +\fInewfs\fP then reads /etc/disktab instead of the pack label. +This file also contains the default +file system partition +sizes, and default block and fragment sizes. To +override any of the default values you can modify the file, +edit the disk label, +or use an option to \fInewfs\fP. +.NH 3 +Implementing a layout +.PP +To put a chosen disk layout into effect, you should use the +.IR newfs (8) +command to create each new file system. +Each file system must also be added to the file +/etc/fstab +so that it will be checked and mounted when the system is bootstrapped. +.PP +As an example, consider a system with \*(Dn's. On the first \*(Dn, \*(Dk0, +we will put the root file system in \*(Dk0a, and the /usr +file system in \*(Dk0\*(pa, which has enough space to hold it and then some. +The /tmp directory will be part of the root file system, +as no file system will be mounted on /tmp. +If we had only one \*(Dn, we would put user files +in the \*(Dk0\*(pa partition with the system source and binaries. +.PP +If we had a second \*(Dn, we would place \fI/usr\fP in \*(Dk1\*(Pa. +We would put user files in \*(Dk0g, calling the file system /a. +We would also interleave the paging +between the 2 \*(Dn's. To do this we would build a system configuration +that specified: +.DS +config vmunix root on \*(Dk0 swap on \*(Dk0 and \*(Dk1 +.DE +to get the swap interleaved, and \fI/etc/fstab\fP would then contain +.DS +/dev/\*(Dk0a:/:rw:1:1 +/dev/\*(Dk0b::sw:: +/dev/\*(Dk0g:/a:rw:1:2 +/dev/\*(Dk1b::sw:: +/dev/\*(Dk1g:/usr:rw:1:2 +.DE +We would keep a backup copy of the root +file system in the \fB\*(Dk1a\fP disk partition. +Alternatively, that partition could be used for \fI/tmp\fP. +.PP +To make the /a file system we would do: +.if \n(Th \{\ +.ds Dn eagle +.\} +.DS +\fB#\fP \fIcd /dev\fP +\fB#\fP \fIMAKEDEV \*(Dk1\fP +\fB#\fP \fIdisklabel -wr \*(Dk1 \*(Dn "disk name"\fP +\fB#\fP \fInewfs \*(Dk1\*(Pa\fP +(information about file system prints out) +\fB#\fP \fImkdir /a\fP +\fB#\fP \fImount /dev/\*(Dk1\*(Pa /a\fP +.DE +.NH 2 +Configuring terminals +.PP +If UNIX is to support simultaneous +access from directly-connected terminals other than the console, +the file \fI/etc/ttys\fP (\fIttys\fP\|(5)) must be edited. +.if \n(Vx \{\ +.PP +Terminals connected via DZ11 interfaces are conventionally named \fBttyDD\fP +where DD is a decimal number, the ``minor device'' number. +The lines on dz0 are named /dev/tty00, /dev/tty01, ... /dev/tty07. +By convention, all other terminal names are of the form \fBtty\fPCX, where +C is an alphabetic character according to the type of terminal multiplexor +and its unit number, +and X is a digit for the first ten lines on the interface +and an increasing lower case letter for the rest of the lines. +C is defined for the number of interfaces of each type listed below. +.DS +.TS +center box; +c c c c +c c c c +l c n n. +Interface Number of lines Number of +Type Characters per board Interfaces +_ +DZ11 see above 8 10 +DMF32 A-C,E-I 8 8 +DMZ32 a-c,e-g 24 6 +DH11 h-o 16 8 +DHU11 S-Z 16 8 +pty p-u 16 6 +.TE +.DE +.\} +.if \n(Th \{\ +.PP +Terminals connected via VIOC-X interfaces are conventionally named tty\fIDD\fP +where \fIDD\fP is a hexadecimal number, the ``minor device'' number. +The first digit is the multiplexor unit number, and the second digit +is the line number. +For VIOC's with fewer than 16 connectors, the missing unit numbers are unused. +.PP +Terminals connected using 16 port MPCC interfaces are conventionally named +tty\fICD\fP where \fIC\fP is a single upper-case letter and \fID\fP is a +single hexidecimal digit. The upper-case letter is the multiplexor unit +number (with \fIA\fP being mpcc 0) and the hexidecimal digit is the port +number on that unit. +.\} +.PP +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. +.if \n(Vx \{\ +(For example, use ``cd /dev; MAKEDEV dz1'' to make the special files +for the second DZ11.) +.\} +.if \n(Th \{\ +(For example, use ``cd /dev; MAKEDEV vx1'' to make the special files +for the second VIOC.) +.\} +Then, enable the appropriate lines of /etc/ttys by setting the ``status'' +field to \fBon\fP (or add new lines). +Note that lines in \fI/etc/ttys\fP are one-for-one with entries +in the file of current users (\fI/etc/utmp\fP), +and therefore it is best to make changes +while running in single-user mode +and to add all of the entries for a new device at once. +.if \n(Th \{\ +.PP +To add mpcc controllers, and additional step is required. At boot time, +the firmware for each mpcc controller must be downloaded. The program +\fI/etc/dlmpcc\fP must therefore be invoked from \fI/etc/rc.local\fP. +The file \fI/etc/mpcctab\fP describes each mpcc controller and is used +by \fI/etc/dlmpcc\fP to determine how many mpcc's are on the system. +See \fImpcc\fP(4) and \fIdlmpcc\fP(8) for more information. +.\} +.PP +The format of the /etc/ttys file is completely new in 4.3BSD. +Each line in the 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 /etc/init should startup to service the line +(or \fBnone\fP if the line is to be left alone), +the terminal type (found in /etc/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). 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 +.DS +tty00 "/etc/getty std.9600" vt100 on secure # mike's office +.DE +The std.9600 parameter provided +to /etc/getty is used in searching the file /etc/gettytab; it specifies +a terminal's characteristics (such as baud rate). +To make custom terminal types, consult +.IR gettytab (5) +before modifying /etc/gettytab. +.PP +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, +.if \n(Vx \{\ +you must either wire back the signals so that +the carrier appears to always be present, or show in the system +configuration that carrier is to be assumed to be present +with \fIflags\fP for each terminal device. See +.IR dh (4), +.IR dhu (4), +.IR dz (4), +.IR dmz (4), +and +.IR dmf (4) +for details. +.\} +.if \n(Th \{\ +you must wire back the signals so that +the carrier appears to always be present. For further details, see +.IR vx (4), +.IR mpcc (4), +and +.IR dlmpcc (8). +.\} +.PP +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 +.DS +ttyp0 none network +.DE +(Note, the fourth field is not needed here.) +.PP +When the system is running multi-user, all terminals that are listed +in /etc/ttys as \fBon\fP 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 \fBoff\fP and +then send a hangup signal to the \fIinit\fP process, by doing +.DS +\fB#\fP \fIkill \-1 1\fP +.DE +Terminals can similarly be enabled by changing the status field +from \fBoff\fP to \fBon\fP and sending a hangup signal to \fIinit\fP. +.PP +Note that if a special file is inaccessible when \fIinit\fP tries +to create a process for it, init will log a message to the +system error logging process (/etc/syslogd) +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. +.PP +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. +.PP +While it is possible to use truly arbitrary strings for terminal names, +the accounting and noticeably the +\fIps\fP\|(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 +\fIps\fP\|(1) +uses based on these conventions will then break down and \fIps\fP will +run MUCH slower. +.NH 2 +Adding users +.PP +The procedure for adding a new user is described in \fIadduser\fP(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. +.PP +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. +.NH 2 +Site tailoring +.PP +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 +.DS +/etc/netstart +.DE +The first lines in /etc/netstart use a variable to set the hostname, +.DS +hostname=\fImysitename\fP +/bin/hostname $hostname +.DE +to define the value returned by the +.IR gethostname (2) +system call. If you are running the name server, your site +name should be your fully qualified domain name. Programs such as +.IR getty (8), +.IR mail (1), +.IR wall (1), +and +.IR uucp (1) +use this system call so that the binary images are site +independent. +.NH 2 +Setting up the line printer system +.PP +The line printer system consists of at least +the following files and commands: +.DS +.TS +l l. +/usr/ucb/lpq spooling queue examination program +/usr/ucb/lprm program to delete jobs from a queue +/usr/ucb/lpr program to enter a job in a printer queue +/etc/printcap printer configuration and capability data base +/usr/lib/lpd line printer daemon, scans spooling queues +/etc/lpc line printer control program +/etc/hosts.lpd list of host allowed to use the printers +.TE +.DE +.PP +The file /etc/printcap is a master data base describing line +printers directly attached to a machine and, also, printers +accessible across a network. The manual page +.IR printcap (5) +describes the format of this data base 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. +.PP +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 +.IR 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 +.I lpq +program shows the contents of spool +queues on both the local and remote machines. +.PP +To configure your line printers, consult the printcap manual page +and the accompanying document, ``4.3BSD Line Printer Spooler Manual''. +A call to the +.I lpd +program should be present in /etc/rc. +.NH 2 +Setting up the mail system +.PP +The mail system consists of the following commands: +.DS +.TS +l l. +/bin/mail old standard mail program, described in \fIbinmail\fP\|(1) +/usr/ucb/mail UCB mail program, described in \fImail\fP\|(1) +/usr/lib/sendmail mail routing program +/usr/spool/mail mail spooling directory +/usr/spool/secretmail secure mail directory +/usr/bin/xsend secure mail sender +/usr/bin/xget secure mail receiver +/usr/lib/aliases mail forwarding information +/usr/ucb/newaliases command to rebuild binary forwarding database +/usr/ucb/biff mail notification enabler +/etc/comsat mail notification daemon +.TE +.DE +Mail is normally sent and received using the +.IR mail (1) +command (found in /usr/ucb/mail), +which provides a front-end to edit the messages sent +and received, and passes the messages to +.IR 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 /usr/lib/sendmail.cf, to +process each piece of mail. +Local mail is delivered by giving it to the program /bin/mail +that adds it to the mailboxes in the directory /usr/spool/mail/\fIusername\fP, +using a locking protocol to avoid problems with simultaneous updates. +After the mail is delivered, the local mail delivery daemon /etc/comsat +is notified, which in turn notifies +users who have issued a ``\fIbiff\fP y'' command that mail has arrived. +.PP +Mail queued in the directory /usr/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. +.PP +To set up the mail facility you should read the instructions in the +file READ_ME in the directory /usr/src/usr.lib/sendmail and then adjust +the necessary configuration files. +You should also set up the file /usr/lib/aliases for your installation, +creating mail groups as appropriate. Documents describing +.IR sendmail 's +operation and installation are also included in the distribution. +.NH 3 +Setting up a UUCP connection +.PP +The version of \fIuucp\fP included in \*(4B is a greatly +enhanced version of the one originally distributed with 32/V*. +.FS +* The \fIuucp\fP included in this distribution is the result +of work by many people; we gratefully acknowledge their +contributions, but refrain from mentioning names in the +interest of keeping this document current. +.FE +The enhancements include: +.IP \(bu 3 +support for many auto call units and dialers +in addition to the DEC DN11, +.IP \(bu 3 +breakup of the spooling area into multiple subdirectories, +.IP \(bu 3 +addition of an \fIL.cmds\fP file to control the set +of commands that may be executed by a remote site, +.IP \(bu 3 +enhanced ``expect-send'' sequence capabilities when +logging in to a remote site, +.IP \(bu 3 +new commands to be used in polling sites and +obtaining snap shots of \fIuucp\fP activity, +.IP \(bu 3 +additional protocols for different communication media. +.LP +This section gives a brief overview of \fIuucp\fP +and points out the most important steps in its installation. +.PP +To connect two UNIX machines with a \fIuucp\fP 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. +.PP +You should first read the paper in the UNIX System Manager's Manual: +``Uucp Implementation Description''. +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. +.PP +The \fIuucp\fP support is located in three major directories: +/usr/bin, +/usr/lib/uucp, +and /usr/spool/uucp. +User commands are kept in /usr/bin, +operational commands in /usr/lib/uucp, +and /usr/spool/uucp is used as a spooling area. +The commands in /usr/bin are: +.DS +.TS +l l. +/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 \fIuusend\fP) +/usr/bin/uudecode binary file decoder (for \fIuusend\fP) +/usr/bin/uulog scans session log files +/usr/bin/uusnap gives a snap-shot of \fIuucp\fP 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 +.TE +.DE +The important files and commands in /usr/lib/uucp are: +.DS +.TS +l l. +/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 \fIuucp\fP protocol daemon +/usr/lib/uucp/uuclean cleans up garbage files in spool area +/usr/lib/uucp/uuxqt \fIuucp\fP remote execution server +.TE +.DE +while the spooling area contains the following important files and directories: +.DS +.TS +l l. +/usr/spool/uucp/C. directory for command, ``C.'' files +/usr/spool/uucp/D. directory for data, ``D.'', files +/usr/spool/uucp/X. directory for command execution, ``X.'', files +/usr/spool/uucp/D.\fImachine\fP directory for local ``D.'' files +/usr/spool/uucp/D.\fImachine\fPX directory for local ``X.'' files +/usr/spool/uucp/TM. directory for temporary, ``TM.'', files +/usr/spool/uucp/LOGFILE log file of \fIuucp\fP activity +/usr/spool/uucp/SYSLOG log file of \fIuucp\fP file transfers +.TE +.DE +.PP +To install \fIuucp\fP on your system, +start by selecting a site name +(shorter than 14 characters). +A \fIuucp\fP 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 \fIuucp\fP, group \fIdaemon\fP. +.PP +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 \fIuucp\fP daemon on another machine. +For example, our L.sys file looks something like: +.DS +adiron Any ACU 1200 out0123456789- ogin-EOT-ogin uucp +cbosg Never Slave 300 +cbosgd Never Slave 300 +chico Never Slave 1200 out2010123456 +.DE +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 \fIuucp\fP daemon, \fIuucico\fP, +to search for any available auto-call unit in L-devices. +Our L-dialcodes file is of the form: +.DS +ucb 2 +out 9% +.DE +while our L-devices file is: +.DS +ACU cul0 unused 1200 ventel +.DE +Refer to the README file in the \fIuucp\fP source directory +for more information about installation. +.PP +As \fIuucp\fP operates it creates (and removes) many small +files in the directories underneath /usr/spool/uucp. +Sometimes files are left undeleted; +these are most easily purged with the \fIuuclean\fP program. +The log files can grow without bound unless trimmed back; +\fIuulog\fP maintains these files. +Many useful aids in maintaining your \fIuucp\fP installation +are included in a subdirectory UUAIDS beneath /usr/src/usr.bin/uucp. +Peruse this directory and read the ``setup'' instructions also located there. diff --git a/usr/othersrc/share/doc/smm/01.setup/common/6.t b/usr/othersrc/share/doc/smm/01.setup/common/6.t new file mode 100644 index 0000000000..3b8067219c --- /dev/null +++ b/usr/othersrc/share/doc/smm/01.setup/common/6.t @@ -0,0 +1,646 @@ +.\" Copyright (c) 1980, 1986, 1988 The Regents of the University of California. +.\" 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. +.\" +.\" @(#)6.t 6.5 (Berkeley) 4/17/91 +.\" +.de IR +\fI\\$1\fP\|\\$2 +.. +.ds LH "Installing/Operating \*(4B +.nr H1 6 +.nr H2 0 +.ds RH "System Operation +.ds CF \*(DY +.bp +.LG +.B +.ce +6. SYSTEM OPERATION +.sp 2 +.R +.NL +.PP +This section describes procedures used to operate a \*(4B UNIX system. +Procedures described here are used periodically, to reboot the system, +analyze error messages from devices, do disk backups, monitor +system performance, recompile system software and control local changes. +.NH 2 +Bootstrap and shutdown procedures +.PP +In a normal reboot, the system checks the disks and comes up multi-user +without intervention at the console. +Such a reboot +can be stopped (after it prints the date) with a ^C (interrupt). +This will leave the system in single-user mode, with only the console +terminal active. +It is also possible to allow the filesystem checks to complete +and then to return to single-user mode by signaling \fIfsck\fP(8) +with a QUIT signal (^\\). +.if \n(Th \{\ +.PP +If booting from the console command level is needed, then the command +.DS +\fB#>\fP\|fb +.DE +will boot from the default device. +.PP +You can boot a system up single user by doing +.DS +\fB#>\fP\fI\|p23 2.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fb\fP +.DE +.PP +Other possibilities are: +.DS +\fB#>\fP\fI\|p23 3.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fb\fP +.DE +to do a full bootstrap, or +.DS +\fB#>\fP\fI\|p23 3.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fr /boot\fP +.DE +to run the bootstrap without performing self-tests and +reloading microcode; it can be used after a full bootstrap has been done +once. +.\} +.if \n(Vx \{\ +.PP +If booting from the console command level is needed, then the command +.DS +\fB>>>\fP\fIB\fP +.DE +will boot from the default device. +On an 8600, 8200, 11/780, or 11/730 the default device is +determined by a ``DEPOSIT'' +command stored on the console boot device in the file ``DEFBOO.CMD'' +(``DEFBOO.COM'' on an 8600); +on an 11/750 the default device is determined by the setting of a switch +on the front panel. +.PP +You can boot a system up single user +on an 8600, 780, or 730 by doing +.DS +\fB>>>\fP\fIB xxS\fP +.DE +where \fIxx\fP is one of HP, HK, UP, RA, or RB. +The corresponding command on an 11/750 is +.DS +\fB>>>\fP\fIB/2\fP +.DE +On an 8200, use +.DS +\fB>>>\fP\fIB/R5:800\fP +(node and memory test values) +\fBBOOT58>\fP \fI@\fPXX\fISBOO.CMD\fP +.DE +.PP +For second vendor storage modules on the +UNIBUS or MASSBUS of an 11/750 you will need to +have a boot prom. Most vendors will sell you +such proms for their controllers; contact your vendor +if you don't have one. +.PP +Other possibilities are: +.DS +\fB>>>\fP\fIB ANY\fP +.DE +or, on an 8200, +.DS +\fB>>>\fP\fIB/R5:800\fP +\fBBOOT58>\fP\fI@ANYBOO.CMD\fP +.DE +or, on an 11/750 +.DS +\fB>>>\fP\fIB/3\fP +.DE +.\} +These commands boot and ask for the name of the system to be booted. +They can be used after building a new test system to give the +boot program the name of the test version of the system.* +.FS +* Additional bootflags are used when a system is configured with +the kernel debugger; consult \fIkdb\fP(4) for details. +.FE +.PP +To bring the system up to a multi-user configuration from the single-user +status, +all you have to do is hit ^D on the console. The system +will then execute /etc/rc, +a multi-user restart script (and /etc/rc.local), +and come up on the terminals listed as +active in the file /etc/ttys. +See +\fIinit\fP\|(8) +and +\fIttys\fP\|(5) for more details. +Note, however, that this does not cause a file system check to be performed. +Unless the system was taken down cleanly, you should run +``fsck \-p'' or force a reboot with +\fIreboot\fP\|(8) +to have the disks checked. +.PP +To take the system down to a single user state you can use +.DS +\fB#\fP \fIkill 1\fP +.DE +or use the +\fIshutdown\fP\|(8) +command (which is much more polite, if there are other users logged in) +when you are running multi-user. +Either command will kill all processes and give you a shell on the console, +as if you had just booted. File systems remain mounted after the +system is taken single-user. If you wish to come up multi-user again, you +should do this by: +.DS +\fB#\fP \fIcd /\fP +\fB#\fP \fI/etc/umount -a\fP +\fB#\fP \fI^D\fP +.DE +.PP +Each system shutdown, crash, processor halt and reboot +is recorded in the system log +with its cause. +.NH 2 +Device errors and diagnostics +.PP +When serious errors occur on peripherals or in the system, the system +prints a warning diagnostic on the console. +These messages are collected +by the system error logging process +.IR syslogd (8) +and written into a system error log file +\fI/usr/adm/messages\fP. +Less serious errors are sent directly to \fIsyslogd\fP, +which may log them on the console. +The error priorities that are logged and the locations to which they are logged +are controlled by \fI/etc/syslog.conf\fP. See +.IR syslogd (8) +for further details. +.PP +Error messages printed by the devices in the system are described with the +drivers for the devices in section 4 of the programmer's manual. +If errors occur suggesting hardware problems, you should contact +your hardware support group or field service. It is a good idea to +examine the error log file regularly +(e.g. with the command \fItail \-r /usr/adm/messages\fP). +.NH 2 +File system checks, backups and disaster recovery +.PP +Periodically (say every week or so in the absence of any problems) +and always (usually automatically) after a crash, +all the file systems should be checked for consistency +by +\fIfsck\fP\|(1). +The procedures of +\fIreboot\fP\|(8) +should be used to get the system to a state where a file system +check can be performed manually or automatically. +.PP +Dumping of the file systems should be done regularly, +since once the system is going it is easy to +become complacent. +Complete and incremental dumps are easily done with +\fIdump\fP\|(8). +You should arrange to do a towers-of-hanoi dump sequence; we tune +ours so that almost all files are dumped on two tapes and kept for at +least a week in most every case. We take full dumps every month (and keep +these indefinitely). +Operators can execute ``dump w'' at login that will tell them what needs +to be dumped +(based on the /etc/fstab +information). +Be sure to create a group +.B operator +in the file /etc/group +so that dump can notify logged-in operators when it needs help. +.PP +More precisely, we have three sets of dump tapes: 10 daily tapes, +5 weekly sets of 2 tapes, and fresh sets of three tapes monthly. +We do daily dumps circularly on the daily tapes with sequence +`3 2 5 4 7 6 9 8 9 9 9 ...'. +Each weekly is a level 1 and the daily dump sequence level +restarts after each weekly dump. +Full dumps are level 0 and the daily sequence restarts after each full dump +also. +.PP +Thus a typical dump sequence would be: +.br +.ne 6 +.KS +.TS +center; +c c c c c +n n n l l. +tape name level number date opr size +_ +FULL 0 Nov 24, 1979 jkf 137K +D1 3 Nov 28, 1979 jkf 29K +D2 2 Nov 29, 1979 rrh 34K +D3 5 Nov 30, 1979 rrh 19K +D4 4 Dec 1, 1979 rrh 22K +W1 1 Dec 2, 1979 etc 40K +D5 3 Dec 4, 1979 rrh 15K +D6 2 Dec 5, 1979 jkf 25K +D7 5 Dec 6, 1979 jkf 15K +D8 4 Dec 7, 1979 rrh 19K +W2 1 Dec 9, 1979 etc 118K +D9 3 Dec 11, 1979 rrh 15K +D10 2 Dec 12, 1979 rrh 26K +D1 5 Dec 15, 1979 rrh 14K +W3 1 Dec 17, 1979 etc 71K +D2 3 Dec 18, 1979 etc 13K +FULL 0 Dec 22, 1979 etc 135K +.TE +.KE +We do weekly dumps often enough that daily dumps always fit on one tape. +.PP +Dumping of files by name is best done by +\fItar\fP\|(1) +but the amount of data that can be moved in this way is limited +to a single tape. +Finally if there are enough drives entire +disks can be copied with +\fIdd\fP\|(1) +using the raw special files and an appropriate +blocking factor; the number of sectors per track is usually +a good value to use, consult \fI/etc/disktab\fP. +.PP +It is desirable that full dumps of the root file system be +made regularly. +This is especially true when only one disk is available. +Then, if the +root file system is damaged by a hardware or software failure, you +can rebuild a workable disk doing a restore in the +same way that the initial root file system was created. +.PP +Exhaustion of user-file space is certain to occur +now and then; disk quotas may be imposed, or if you +prefer a less fascist approach, try using the programs +\fIdu\fP\|(1), +\fIdf\fP\|(1), and +\fIquot\fP\|(8), +combined with threatening +messages of the day, and personal letters. +.NH 2 +Moving file system data +.PP +If you have the resources, +the best way to move a file system +is to dump it to a spare disk partition, or magtape, using +\fIdump\fP\|(8), use \fInewfs\fP\|(8) to create the new file system, +and restore the file system using \fIrestore\fP\|(8). +Filesystems may also be moved by piping the output of \fIdump\fP +to \fIrestore\fP. +The \fIrestore\fP program uses an ``in-place'' algorithm that +allows file system dumps to be restored without concern for the +original size of the file system. Further, portions of a +file system may be selectively restored using a method similar +to the tape archive program. +.PP +If you have to merge a file system into another, existing one, +the best bet is to +use \fItar\fP\|(1). +If you must shrink a file system, the best bet is to dump +the original and restore it onto the new file system. +If you +are playing with the root file system and only have one drive, +the procedure is more complicated. +If the only drive is a Winchester disk, this procedure may not be used +without overwriting the existing root or another partition. +What you do is the following: +.IP 1. +GET A SECOND PACK, OR USE ANOTHER DISK DRIVE!!!! +.IP 2. +Dump the root file system to tape using +\fIdump\fP\|(8). +.IP 3. +Bring the system down. +.IP 4. +Mount the new pack in the correct disk drive, if +using removable media. +.IP 5. +Load the distribution tape and install the new +root file system as you did when first installing the system. +Boot normally +using the newly created disk file system. +.PP +Note that if you change the disk partition tables or add new disk +drivers they should also be added to the standalone system in +\fI/sys/\*(mCstand\fP, +and the default disk partition tables in \fI/etc/disktab\fP +should be modified. +.NH 2 +Monitoring System Performance +.PP +The +.I systat +program provided with the system is designed to be an aid to monitoring +systemwide activity. The default ``pigs'' mode shows a dynamic ``ps''. +By running in the ``vmstat'' mode +when the system is active you can judge the system activity in several +dimensions: job distribution, virtual memory load, paging and swapping +activity, device interrupts, and disk and cpu utilization. +Ideally, there should be few blocked (b) jobs, +there should be little paging or swapping activity, there should +be available bandwidth on the disk devices (most single arms peak +out at 20-30 tps in practice), and the user cpu utilization (us) should +be high (above 50%). +.PP +If the system is busy, then the count of active jobs may be large, +and several of these jobs may often be blocked (b). If the virtual +memory is active, then the paging demon will be running (sr will +be non-zero). It is healthy for the paging demon to free pages when +the virtual memory gets active; it is triggered by the amount of free +memory dropping below a threshold and increases its pace as free memory +goes to zero. +.PP +If you run in the ``vmstat'' mode +when the system is busy, you can find +imbalances by noting abnormal job distributions. If many +processes are blocked (b), then the disk subsystem +is overloaded or imbalanced. If you have several non-dma +devices or open teletype lines that are ``ringing'', or user programs +that are doing high-speed non-buffered input/output, then the system +time may go high (60-70% or higher). +It is often possible to pin down the cause of high system time by +looking to see if there is excessive context switching (cs), interrupt +activity (in) and per-device interrupt counts, +or system call activity (sy). Cumulatively on one of +our large machines we average about 60-100 context switches and interrupts +per second and about 70-120 system calls per second. +.PP +If the system is heavily loaded, or if you have little memory +for your load (2M is little in most any case), then the system +may be forced to swap. This is likely to be accompanied by a noticeable +reduction in system performance and pregnant pauses when interactive +jobs such as editors swap out. +If you expect to be in a memory-poor environment +for an extended period you might consider administratively +limiting system load. +.NH 2 +Recompiling and reinstalling system software +.PP +It is easy to regenerate the system, and it is a good +idea to try rebuilding pieces of the system to build confidence +in the procedures. +The system consists of two major parts: +the kernel itself (/sys) and the user programs +(/usr/src and subdirectories). +The major part of this is /usr/src. +.PP +The three major libraries are the C library in /usr/src/lib/libc +and the \s-2FORTRAN\s0 libraries /usr/src/usr.lib/libI77 and +/usr/src/usr.lib/libF77. In each +case the library is remade by changing into the corresponding directory +and doing +.DS +\fB#\fP \fImake\fP +.DE +and then installed by +.DS +\fB#\fP \fImake install\fP +.DE +Similar to the system, +.DS +\fB#\fP \fImake clean\fP +.DE +cleans up. +.PP +The source for all other libraries is kept in subdirectories of +/usr/src/usr.lib; each has a makefile and can be recompiled by the above +recipe. +.PP +If you look at /usr/src/Makefile, you will see that +you can recompile the entire system source with one command. +To recompile a specific program, find +out where the source resides with the \fIwhereis\fP\|(1) +command, then change to that directory and remake it +with the Makefile present in the directory. +For instance, to recompile ``date'', +all one has to do is +.DS +\fB#\fP \fIwhereis date\fP +\fBdate: /usr/src/bin/date.c /bin/date\fP +\fB#\fP \fIcd /usr/src/bin\fP +\fB#\fP \fImake date\fP +.DE +this will create an unstripped version of the binary of ``date'' +in the current directory. To install the binary image, use the +install command as in +.DS +\fB#\fP \fIinstall \-s date -o bin -g bin -m 755 /bin/date\fP +.DE +The \-s option will insure the installed version of date has +its symbol table stripped. The install command should be used +instead of mv or cp as it understands how to install programs +even when the program is currently in use. +.PP +If you wish to recompile and install all programs in a particular +target area you can override the default target by doing: +.DS +\fB#\fP \fImake\fP +\fB#\fP \fImake DESTDIR=\fPpathname \fIinstall\fP +.DE +.PP +To regenerate all the system source you can do +.DS +\fB#\fP \fIcd /usr/src\fP +\fB#\fP \fImake clean; make depend; make\fP +.DE +.PP +If you modify the C library, say to change a system call, +and want to rebuild and install everything from scratch you +have to be a little careful. +You must insure that the libraries are installed before the +remainder of the source, otherwise the loaded images will not +contain the new routine from the library. The following +sequence will accomplish this. +.DS +\fB#\fP \fIcd /usr/src\fP +\fB#\fP \fImake clean\fP +\fB#\fP \fImake depend\fP +\fB#\fP \fImake build\fP +\fB#\fP \fImake installsrc\fP +.DE +The \fImake clean\fP removes any existing binary or object files in the source +trees to insure that everything will be recompiled and reloaded. The \fImake +depend\fP recreates all of the dependencies. See \fImkdep\fP(1) for +further details. The \fImake build\fP compiles and installs the libraries +and compilers, then recompiles the libraries and compilers and the remainder +of the sources. The \fImake installsrc\fP installs all of the commands not +installed as part of the \fImake build\fP. +.if \n(Th \{\ +This will take approximately 10 +hours on a reasonably configured Tahoe. +.\} +.NH 2 +Making local modifications +.PP +Locally written commands that aren't distributed are kept in /usr/src/local +and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, +and /bin to correspond to the distribution tape (and to the manuals that +people can buy). People using local commands should be made aware that +they aren't in the base manual. Manual pages for local commands should be +installed in /usr/src/local/man and installed in /usr/local/man/cat[1-8]. +The \fIman\fP(1) command automatically finds manual pages placed in +/usr/local/man/cat[1-8] to facilitate this practice. +.NH 2 +Accounting +.PP +UNIX optionally records two kinds of accounting information: +connect time accounting and process resource accounting. The connect +time accounting information is stored in the file \fI/usr/adm/wtmp\fP, which +is summarized by the program +.IR ac (8). +The process time accounting information is stored in the file +\fI/usr/adm/acct\fP after it is enabled by +.IR accton (8), +and is analyzed and summarized by the program +.IR sa (8). +.PP +If you need to recharge for computing time, you can develop +procedures based on the information provided by these commands. +A convenient way to do this is to give commands to the clock daemon +.I /etc/cron +to be executed every day at a specified time. This is done by adding +lines to \fI/usr/adm/crontab\fP; see +.IR cron (8) +for details. +.NH 2 +Resource control +.PP +Resource control in the current version of UNIX is more +elaborate than in most UNIX systems. The disk quota +facilities developed at the University of Melbourne have +been incorporated in the system and allow control over the +number of files and amount of disk space each user may use +on each file system. In addition, the resources consumed +by any single process can be limited by the mechanisms of +\fIsetrlimit\fP\|(2). As distributed, the latter mechanism +is voluntary, though sites may choose to modify the login +mechanism to impose limits not covered with disk quotas. +.PP +To use the disk quota facilities, the system must be +configured with ``options QUOTA''. File systems may then +be placed under the quota mechanism by creating a null file +.I quotas +at the root of the file system, running +.IR quotacheck (8), +and modifying \fI/etc/fstab\fP to show that the file system is read-write +with disk quotas (an ``rq'' type field). The +.IR quotaon (8) +program may then be run to enable quotas. +.PP +Individual quotas are applied by using the quota editor +.IR edquota (8). +Users may view their quotas (but not those of other users) with the +.IR quota (1) +program. The +.IR repquota (8) +program may be used to summarize the quotas and current +space usage on a particular file system or file systems. +.PP +Quotas are enforced with +.I soft +and +.I hard +limits. When a user first reaches a soft limit on a resource, a +message is generated on his/her terminal. If the user fails to +lower the resource usage below the soft limit the next time +they log in to the system the +.I login +program will generate a warning about excessive usage. Should +three login sessions go by with the soft limit breached the +system then treats the soft limit as a +.I hard +limit and disallows any allocations until enough space is +reclaimed to bring the user back below the soft limit. Hard +limits are enforced strictly resulting in errors when a user +tries to create or write a file. Each time a hard limit is +exceeded the system will generate a message on the user's +terminal. +.PP +Consult the auxiliary document, ``Disc Quotas in a UNIX Environment'' +and the appropriate manual entries for more information. +.NH 2 +Network troubleshooting +.PP +If you have anything more than a trivial network configuration, +from time to time you are bound to run into problems. Before +blaming the software, first check your network connections. On +networks such as the Ethernet a +loose cable tap or misplaced power cable can result in severely +deteriorated service. The \fInetstat\fP\|(1) program may be of +aid in tracking down hardware malfunctions. In particular, look +at the \fB\-i\fP and \fB\-s\fP options in the manual page. +.PP +Should you believe a communication protocol problem exists, +consult the protocol specifications and attempt to isolate the +problem in a packet trace. The SO_DEBUG option may be supplied +before establishing a connection on a socket, in which case the +system will trace all traffic and internal actions (such as timers +expiring) in a circular trace buffer. This buffer may then +be printed out with the \fItrpt\fP\|(8C) program. Most of the +servers distributed with the system accept a \fB\-d\fP option forcing +all sockets to be created with debugging turned on. Consult the +appropriate manual pages for more information. +.NH 2 +Files that need periodic attention +.PP +We conclude the discussion of system operations by listing +the files that require periodic attention or are system specific: +.de BP +.IP \fB\\$1\fP +.br +.. +.TS +center; +lb a. +/etc/fstab how disk partitions are used +/etc/disktab default disk partition sizes/labels +/etc/printcap printer data base +/etc/gettytab terminal type definitions +/etc/remote names and phone numbers of remote machines for \fItip\fP(1) +/etc/group group memberships +/etc/motd message of the day +/etc/passwd password file; each account has a line +/etc/rc.local local system restart script; runs reboot; starts daemons +/etc/inetd.conf local internet servers +/etc/hosts host name data base +/etc/networks network name data base +/etc/services network services data base +/etc/hosts.equiv hosts under same administrative control +/etc/syslog.conf error log configuration for \fIsyslogd\fP\|(8) +/etc/ttys enables/disables ports +/usr/lib/crontab commands that are run periodically +/usr/lib/aliases mail forwarding and distribution groups +/usr/adm/acct raw process account data +/usr/adm/messages system error log +/usr/adm/wtmp login session accounting +.TE diff --git a/usr/othersrc/share/doc/smm/01.setup/common/renohints.t b/usr/othersrc/share/doc/smm/01.setup/common/renohints.t new file mode 100644 index 0000000000..c747d7e41c --- /dev/null +++ b/usr/othersrc/share/doc/smm/01.setup/common/renohints.t @@ -0,0 +1,824 @@ +.\" Copyright (c) 1990 The Regents of the University of California. +.\" 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. +.\" +.\" @(#)renohints.t 6.4 (Berkeley) 4/17/91 +.\" +.\" format with "tbl renohints.t | troff -ms" +.\" +.ds lq `` +.ds rq '' +.ds Bs BSD +.ds 4B 4.3\*(Bs-Reno +.ds Ps 4.3\*(Bs-tahoe +.de SM \" smaller +\s-1\\$1\s0\\$2 +.. +.de Pn \" pathname +\f(CW\\$1\fP\\$2 +.. +.de Li \" literal +\f(CW\\$1\fP\\$2 +.. +.de I \" italicize first arg +\fI\\$1\fP\^\\$2 +.. +.de Xr \" manual reference +\fI\\$1\fP\^\\$2 +.. +.de Fn \" function +\fI\\$1\fP\^()\\$2 +.. +.ds Vx VAX +.bd S B 3 +.TL +Hints on Upgrading a 4.3BSD System to \*(4B +.br +August 16, 1990 +.AU +Michael J. Karels +.AI +Computer Systems Research Group +Department of Electrical Engineering and Computer Science +University of California, Berkeley +Berkeley, California 94720 +(415) 642-7780 +.de IR +\\fI\\$1\|\\fP\\$2 +.. +.ds Ux \s-1UNIX\s0 +.PP +This set of notes is intended to highlight changes in \*(4B +that will affect installation on existing systems +and to point out areas of the documentation that should be examined +before and while installing this system. +It augments and partially updates +\fIInstalling and Operating \*(Ps \*(Ux* on the \*(Vx\fP\|\(dg +.FS +*\*(Ux is a registered trademark of AT&T in the USA and other countries. +.FE +.FS +\(dg\*(Vx is a trademark of Digital Equipment Corporation. +.FE +and/or +\fIInstalling and Operating \*(Ps \*(Ux on the Tahoe.\fP +Those documents are still largely correct in describing the initial bootstrap +using a \*(4B boot tape (section 2). +However, because of the rearrangement of the file systems +and other changes, the details of the upgrade procedure (section 3) +have changed substantially. +It is suggested that section 3 be used as a guide for which configuration +files to save, but that these hints and the on-line examples and documents +be used to determine the correct location and format of the configuration +files. +.PP +If you are running 4.3\*(Bs rather than \*(Ps, +the comments on upgrading 4.3\*(Bs in the accompanying +\fIInstalling and Operating \*(Ps \*(Ux ...\fP +document should be examined closely before reading the rest of this +document. +Most of the changes and procedures described there are still valid, +such as the installation of disk labels, +but they will not be described here. +.PP +Not all of the documentation is provided in printed form, but all +of it is available in electronic form in the +.Pn /usr/src/share/doc +and +.Pn /usr/src/man +directories on the distribution tape. +.NH 1 +Installation overview +.PP +If you are running 4.2\*(Bs, 4.3\*(Bs or \*(Ps, upgrading your system +involves replacing your kernel and system utilities. +In general, there are three possible ways to install a new \*(Bs distribution: +(1) boot directly from the distribution tape, use it to load new binaries +onto empty disks, and then merge or restore any existing configuration files +and filesystems; +(2) use an existing 4.2\*(Bs or later system to extract the root and +.Pn /usr +filesystems from the distribution tape, +boot from the new system, then merge or restore existing +configuration files and filesystems; or +(3) extract the sources from the distribution tape onto an existing system, +and to use that system to cross-compile and install \*(4B. +For this release, the second alternative is strongly advised if at all possible, +with the third alternative reserved as a last resort. +In general, older binaries will continue to run under \*(Bs, +but there are many exceptions that are on the critical path +for getting the system running. +Ideally, the new system binaries (root and +.Pn /usr +filesystems) should be installed on spare disk partitions, +then site-specific files should be merged into them. +Once the new system is up and fully merged, the previous root and +.Pn /usr +filesystems could be reused. +Other existing filesystems can be retained and used, +except that (as usual) the new \fIfsck\fP should be run +before they are mounted. +.PP +It is \fBSTRONGLY\fP advised that you make full dumps of each filesystem +before beginning, especially any that you intened to modify in place +during the merge. +It is also desirable to run file system checks +of all filesystems to be converted to \*(4B before shutting down. +This is an excellent time to review your disk configuration +for possible tuning of the layout. +Most systems will need to provide a new filesystem for system use +mounted on +.Pn /var +(see below). +However, the +.Pn /tmp +filesystem can be an MFS virtual-memory-resident filesystem, +potentially freeing an existing disk partition. +(Additional swap space may be desirable as a consequence.) +See +.Xr mfs (8). +.NH 1 +Installation summary +.PP +The recommended installation procedure includes the following steps. +The order of these steps will probably vary according to local needs. +.IP \(bu +Extract root and +.Pn /usr +filesystems from the distribution tapes. +.IP \(bu +Extract kernel and/or user-level sources from the distribution tape +if space permits. +This can serve as the backup documentation as needed. +.IP \(bu +Configure and boot a kernel for the local system. +This can be delayed if the generic kernel from the distribution +supports sufficient hardware to proceed. +.IP \(bu +Build a skeletal +.Pn /var +filesystem (see +.Xr mtree (8). +.IP \(bu +Merge site-dependent configuration files from +.Pn /etc +and +.Pn /usr/lib +into the new +.Pn /etc +directory. +Note that many file formats and contents have changed; see section 3.2 +of this document. +.IP \(bu +Copy or merge files from +.Pn /usr/adm , +.Pn /usr/spool , +.Pn /usr/preserve , +.Pn /usr/lib , +and other locations into +.Pn /var . +.IP \(bu +Merge local macros, dictionaries, etc. into +.Pn /usr/share . +.IP \(bu +Merge and update local software to reflect the system changes. +.IP \(bu +Take off the rest of the morning, you've earned it! +.NH 1 +Summary of changes +.PP +The following sections summarize system changes that should be reviewed +before attempting to install the system. +.NH 2 +Filesystem organization +.PP +The most immediately obvious change in \*(4B is the reorganization +of the system filesystems. +Users of certain recent vendor releases have seen this general organization, +although \*(4B takes the reorganization a bit further. +The directories most affected are +.Pn /etc , +which now contains only system configuration files; +.Pn /var , +a new filesystem containing per-system spool and log files; and +.Pn /usr/share, +which contains most of the text files shareable across architectures +such as documentation and macros. +System administration programs formerly in +.Pn /etc +are now found in +.Pn /sbin +and +.Pn /usr/sbin . +Various programs and data files formerly in +.Pn /usr/lib +are now found in +.Pn /usr/libexec +and +.Pn /usr/libdata , +respectively. +Administrative files formerly in +.Pn /usr/adm +are in +.Pn /var/account +and, similarly, log files are now in +.Pn /var/log . +The directory +.Pn /usr/ucb +has been merged into +.Pn /usr/bin , +and the sources for programs in +.Pn /usr/bin +are split into +.Pn /usr/src/usr.bin +and +.Pn /usr/src/pgrm . +Other source directories parallel the destination directories; +.Pn /usr/src/etc +has been greatly expanded, and +.Pn /usr/src/share +is new. +The source for the manual pages, in general, are with the source +code for the applications they document. +Manual pages not closely corresponding to an application program +are found in +.Pn /usr/src/man . +The manual page +.Xr hier (7) +has been updated and made more detailed; +it is included in the printed documentation. +You should review it to familiarize yourself with the new layout. +.NH 2 +/etc +.PP +The +.Pn /etc +directory now contains nearly all of the host-specific configuration +files. +Note that some file formats have changed, +and those configuration files containing pathnames are nearly all affected +by the reorganization. +See the examples provided in +.Pn /etc +(installed from +.Pn /usr/src/etc ) +as a guide. +The following table lists some of the local configuration files +whose locations and/or contents have changed. +.DS I .3i +.TS +l l l +lfC lfC l. +4.3BSD and Earlier 4.3BSD-Reno Comments +_ _ _ +/etc/fstab /etc/fstab new format; see below +/etc/inetd.conf /etc/inetd.conf pathnames of executables changed +/etc/printcap /etc/printcap pathnames changed +/etc/syslog.conf /etc/syslog.conf pathnames of log files changed +/etc/ttys /etc/ttys pathnames of executables changed +/etc/passwd /etc/master.passwd new format; see below +/usr/lib/sendmail.cf /etc/sendmail.cf changed pathnames +/usr/lib/aliases /etc/aliases may contain changed pathnames +/etc/*.pid /var/run/*.pid + +.T& +l l l +lfC lfC l. +New in 4.3BSD-Tahoe 4.3BSD-Reno Comments +_ _ _ +/usr/games/dm.config /etc/dm.conf configuration for games (see \fIdm\fP\|(8)) +/etc/zoneinfo/localtime /etc/localtime timezone configuration +/etc/zoneinfo /usr/share/zoneinfo timezone configuration + +.T& +l l l +lfC lfC l. + New in 4.3BSD-Reno Comments +_ _ _ + /etc/man.conf lists directories searched by \fIman\fP\|(1) + /etc/kerberosIV Kerberos directory; see below +.TE +.DE +.NH 2 +/root +.PP +The home directory of the user ``root'' +is now +.Pn /root +rather than +.Pn / . +The file +.Pn /.profile +is still used when the system comes up in single-user mode, +although +.Pn /.profile +is normally a link to +.Pn /root/.profile . +.NH 2 +Block devices and the root filesystem +.PP +The buffer cache in the kernel is now organized as a file block cache +rather than a device block cache. +As a consequence, cached blocks from a file +and from the corresponding block device would no longer be kept consistent. +The block device thus has little remaining value. +Three changes have been made for these reasons: +(1) block devices may not be opened while they are mounted, +and may not be mounted while open, so that the two versions of cached +file blocks cannot be created, +(2) filesystem checks of the root now use the raw device +to access the root filesystem, and +(3) the root filesystem is initially mounted read-only +so that nothing can be written back to disk during or after modification +of the raw filesystem by +.I fsck . +The root filesystem may be made writable while in single-user mode +with the command +.Li "mount -u /" . +(The mount command has an option to update the flags on a mounted filesystem, +including the ability to upgrade a filesystem from read-only to read-write.) +.NH 2 +Mtree +.PP +A new utility, +.Xr mtree (8), +is provided to build and check filesystem hierarchies +with the proper contents, owners and permissions. +Scripts are provided in +.Pn /etc/mtree +(and +.Pn /usr/src/etc/mtree ) +for the root, +.Pn /usr +and +.Pn /var +filesystems. +Once a filesystem has been made for +.Pn /var , +.I mtree +should be used to create a directory hierarchy there. +.NH 2 +Shadow password files +.PP +The password file format and location have changed in order to protect +the encrypted passwords stored there. +The actual password file is now stored in +.Pn /etc/master.passwd . +The hashed dbm password files do not contain encrypted passwords, +but contain the file offset to the entry with the password in +.Pn /etc/master.passwd +(which is readable only by root). +Thus, the +.Fn getpwnam +and +.Fn getpwuid +functions will no longer return an encrypted password string to non-root +callers. +An old-style passwd file is created in +.Pn /etc/passwd +by the +.Xr vipw (8) +and +.Xr mkpasswd (8) +programs. +See also +.Xr passwd (5). +.NH 2 +Kerberos +.PP +The Kerberos authentication server from MIT (version 4) +is included in this release. +See \fIkerberos\fP\|(1) for a general, if MIT-specific, +introduction. +If it is configured, +.Xr login (1), +.Xr passwd (1), +.Xr rlogin (1) +and +.Xr rsh (1) +will all begin to use it automatically. +The file +.Pn /etc/kerberosIV/README +describes the configuration. +Each system needs the file +.Pn /etc/kerberosIV/krb.conf +to set its realm and local servers, +and a private key stored in +.Pn /etc/kerberosIV/srvtab +(see +.Xr ext_srvtab (8)). +The Kerberos server should be set up on a single, physically secure, +server machine. +Users and hosts may be added to the server database manually with +.Xr kdb_edit (8), +or users on authorized hosts can add themselves and a Kerberos +password upon verification of their ``local'' (passwd-file) password +using the +.Xr register (1) +program. +.PP +Note that by default the password-changing program +.Xr passwd (1) +changes the Kerberos password, which must exist. +The +.Li \-l +option to +.Xr passwd (1) +changes the ``local'' password if one exists. +.PP +Note that Version 5 of Kerberos will be released soon, +and that Version 4 will probably be replaced at that time. +.NH 2 +Make and Makefiles +.PP +This release uses a completely new version of the +.I make +program derived from the +.I pmake +program developed by the Sprite project at Berkeley. +It supports existing makefiles, although certain incorrect makefiles +may fail. +The makefiles for the \*(4B sources make extensive use of the new +facilities, especially conditionals and file inclusion, and are thus +completely incompatible with older versions of +.I make +(but nearly all of the makefiles are now trivial!). +The standard include files for +.I make +are in +.Pn /usr/share/mk . +There is a README file in +.Pn /usr/src/share/mk . +.PP +Another global change supported by the new +.I make +is designed to allow multiple architectures to share a copy of the sources. +If a subdirectory named +.Pn obj +is present in the current directory, +.I make +descends into that directory and creates all object and other files there. +We use this by building a directory hierarchy in +.Pn /usr/obj +that parallels +.Pn /usr/src . +We then create the +.Pn obj +subdirectories in +.Pn /usr/src +as symbolic links to the corresponding directories in +.Pn /usr/obj . +(Both of these steps are automated; the makefile in the +.Pn /usr/src +directory has an example of a target (``shadow'') which builds +the object file system, and ``make obj'' in a directory +including the standard \*(Bs rules in its Makefile makes the +.Pn obj +links in the current directory and recursively in the normal subdirectories.) +We have one +.PN /usr/obj +hierarchy on the local system, and another on each +system that shares the source filesystem. +.NH 2 +lex, yacc +.PP +New versions of +.Xr lex (1) +(``flex'') and +.Xr yacc (1) +(``zoo'') +have replaced their AT&T-derived predecessors. +These should be installed early on if attempting to cross-compile \*(4B +on another system. +Note that the new +.Xr lex +program is not completely backward compatible with historic versions of +.Xr lex , +although it is believed that all documented features are supported. +.NH 2 +NFS +.PP +Network filesystem access is available in \*(4B. +An implementation of the Network File System (NFS) was contributed +by Rick Macklem of the University of Guelph. +Its use will be fairly familiar to users of other implementations of NFS. +See the manual pages +.Xr mount (8), +.Xr mountd (8), +.Xr fstab (5), +.Xr exports (5), +.Xr nfsd (8) +and +.Xr nfsiod (8). +The format of +.Pn /etc/fstab +has changed from previous \*(Bs releases +to a blank-separated format to allow colons in pathnames. +Tahoe users should note that older versions of the CCI console processor +PROMs are annoyed at this change; placing the line +.DS +.ft C +/dev/xfd0a:/: / ufs xx 1 1 +.ft P +.DE +at the beginning of +.Pn /etc/fstab +(where \fIxfd\fP is replaced +by the appropriate console processor name for the boot disk) +may placate the CP. +Otherwise, automatic boots after power-up will fail with messages +about problems in +.Pn /etc/fstab , +culminating in suppresion of ``auto-file mount.'' +This is a problem only if automatic reboots fail. +.NH 2 +Automounter +.PP +An implementation of an auto-mounter daemon, +.I amd, +was contributed by Jan-Simon Pendry of the +Imperial College of Science, Technology & Medicine. +See the source directory, +.Pn /usr/src/usr.sbin/amd +and its +.Pn doc +and +.Pn text +subdirectories for further information. +.NH 2 +POSIX terminal interface +.PP +The \*(4B system uses the IEEE P1003.1 (POSIX.1) terminal interface +rather than the previous \*(Bs terminal interface. +The new interface has nearly all of the functionality of the old interface, +extending the POSIX interface as necessary. +Both the old +.I ioctl +calls and old options to +.Xr stty (1) +are emulated. +This emulation is expected to be removed in a future release, so +conversion to the new interface is encouraged. +.NH 2 +POSIX job control +.PP +The POSIX.1 job control interface is implemented in \*(4B. +A new system call, +.Fn setsid , +is used to create a job-control session consisting of a single process +group with one member, the caller, which becomes a session leader. +Only a session leader may acquire a controlling terminal. +This is done explicitly via a +.Sm TIOCSCTTY +.FN ioctl +call, not implicitly by an +.Fn open +call. +The call fails if the terminal is in use. +Programs that allocate controlling terminals (or pseudo-terminals) +require modification to work in this environment. +Versions of +.I xterm +are provided for releases X11R4 and X10R4 in +.Pn /usr/src/contrib/xterm . +New library routines are available for allocating and initializing +pseudo-terminals and other terminals as controlling terminal; see +.Pn /usr/src/lib/libutil/pty.c +and +.Pn /usr/src/lib/libutil/login_tty.c . +.PP +The POSIX job control model formalizes the previous conventions +used in setting up a process group. +Unfortunately, this requires that changes be made in a defined order +and with some synchronization that were not necessary in the past. +Older job control shells (csh, ksh) will generally not operate correctly +with the new system. +.NH 2 +Other POSIX changes +.PP +Most of the other kernel interfaces have been changed to correspond +with the POSIX.1 interface, although that work is not quite complete. +See the relevant manual pages, perhaps in conjunction with the IEEE POSIX +standard. +.PP +Many of the utilities have been changed to work as described in draft 9 +of the POSIX.2 Shell and Utilities document. +Additional changes are certain in this area. +.NH 2 +ISO OSI networking +.PP +\*(4B provides some support for the ISO OSI protocols CLNP, +TP4, and ES-IS. +User level libraries and processes +implement the application protocols such as FTAM and X.500; +these are available in ISODE, +the ISO Development Environment by Marshall Rose, +which is available via anonymous FTP +(but is not included on the distribution tape). +.PP +Kernel support for the ISO OSI protocols is enabled with the ISO option +in the kernel configuration file. +The +.Xr iso (4) +manual page describes the protocols and addressing; +see also +.Xr clnp (4), +.Xr tp (4) +and +.Xr cltp (4). +The OSI equivalent to ARP is ESIS (End System to Intermediate System Routeing +Protocol); running this protocol is mandatory, however one can manually add +translations for machines that do not participate by use of the +.Xr route (8) +command. +Additional information is provided in the manual page describing +.Xr esis (4). +.NH 2 +Revised route command +.PP +The command +.Xr route (8) +has a new syntax and a number of new capabilities: +it can install routes with a specified destination and mask, +and can change route characteristics such as hop count, packet size +and window size. +.NH 2 +New sockaddr format +.PP +The format of the +.I sockaddr +structure (the structure used to describe a generic network address with an +address family and family-specific data) +has changed from previous releases, +as have the address family-specific versions of this structure. +The +.I sa_family +family field has been split into a length, +.IR sa_len , +and a family, +.IR sa_family . +System calls that pass a +.I sockaddr +structure into the kernel (e.g. +.Fn sendto +and +.Fn connect ) +have a separate parameter that specifies the +.I sockaddr +length, and thus it is not necessary to fill in the +.I sa_len +field for those system calls. +System calls that pass a +.I sockaddr +structure back from the kernel (e.g. +.Fn recvfrom +and +.Fn accept ) +receive a completely filled-in +.I sockaddr +structure, thus the length field is valid. +Because this would not work for old binaries, +the new library uses a different system call number. +Thus, most networking programs compiled under \*(4B are incompatible +with older systems. +.PP +Although this change is mostly source and binary compatible +with old programs, there are three exceptions. +Programs with statically initialized +.I sockaddr +structures +(usually the Internet form, a +.I sockaddr_in ) +are not compatible. +Generally, such programs should be changed to fill in the structure +at run time, as C allows no way to initialize a structure without +assuming the order and number of fields. +Also, programs with use structures to describe a network packet format +that contain embedded +.I sockaddr +structures also require modification; a definition of an +.I osockaddr +structure is provided for this purpose. +Finally, programs that use the +.Sm SIOCGIFCONF +ioctl to get a complete list of interface addresses +need to check the +.I sa_len +field when iterating through the array of addresses returned, +as not all of the structures returned have the same length +(in fact, this is nearly guaranteed by the presence of link-layer +address structures). +.NH 2 +/dev/fd +.PP +The directory +.Pn /dev/fd +contains special files +.Pn 0 +through +.Pn 63 +which, when opened, duplicate the corresponding file descriptor. +The names +.Pn /dev/stdin +.Pn /dev/stdout +.Pn /dev/stderr +refer to file descriptors 0, 1 and 2. +See +.Xr fd (4) +for more information. +.NH 2 +Ktrace +.PP +A system-call tracing facility is provided in \*(4B +that records all of the system calls made by a process or group of processes +and their outcomes. +The facility is restricted to root until certain privilege tests can +be put into place. +See +.Xr ktrace (1) +and +.Xr kdump (1). +.KS +.NH 1 +Example script for copying files to /var +.PP +The following commands provide a guide for copying spool and log files from +an existing system into a new +.Pn /var +filesystem. +At least the following directories should already exist on +.Pn /var : +.Pn output , +.Pn log , +.Pn backups +and +.Pn db . +.LP +.DS +.nf +.ft CW +SRC=/oldroot/usr + +cd $SRC; tar cf - msgs preserve | (cd /var && tar xpf -) + +# copy $SRC/spool to /var +cd $SRC/spool +tar cf - at mail rwho | (cd /var && tar xpf -) +tar cf - ftp mqueue news secretmail uucp uucppublic | \e + (cd /var/spool && tar xpf -) + +# everything else in spool is probably a printer area +mkdir .save +mv at ftp mail mqueue rwho secretmail uucp uucppublic .save +tar cf - * | (cd /var/spool/output && tar xpf -) +mv .save/* . +rmdir .save + +cd /var/spool/mqueue +mv syslog.7 /var/log/maillog.7 +mv syslog.6 /var/log/maillog.6 +mv syslog.5 /var/log/maillog.5 +mv syslog.4 /var/log/maillog.4 +mv syslog.3 /var/log/maillog.3 +mv syslog.2 /var/log/maillog.2 +mv syslog.1 /var/log/maillog.1 +mv syslog.0 /var/log/maillog.0 +mv syslog /var/log/maillog + +# move $SRC/adm to /var +cd $SRC/adm +tar cf - . | (cd /var/account && tar xpf -) +cd /var/account +rm -f msgbuf +mv messages messages.[0-9] ../log +mv wtmp wtmp.[0-9] ../log +mv lastlog ../log +.DE +.KE -- 2.20.1