1 .\" Copyright (c) 1980, 1986, 1988 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" @(#)4.t 8.1 (Berkeley) 7/29/93
35 .ds LH "Installing/Operating \*(4B
40 This section describes procedures used to set up a \*(4B UNIX system.
41 These procedures are used when a system is first installed
42 or when the system configuration changes. Procedures for normal
43 system operation are described in the next section.
44 .Sh 2 "Kernel configuration"
46 This section briefly describes the layout of the kernel code and
47 how files for devices are made.
48 For a full discussion of configuring
49 and building system images, consult the document ``Building
50 4.3BSD UNIX Systems with Config'' (SMM:2).
51 .Sh 3 "Kernel organization"
53 As distributed, the kernel source is in a
54 separate tar image. The source may be physically
55 located anywhere within any filesystem so long as
56 a symbolic link to the location is created for the file
60 are normally symbolic links relative to
62 In further discussions of the system source all path names
63 will be given relative to
66 The kernel is made up of several large generic parts:
69 sys main kernel header files
70 kern kernel functions broken down as follows
71 init system startup, syscall dispatching, entry points
72 kern scheduling, descriptor handling and generic I/O
73 sys process management, signals
74 tty terminal handling and job control
75 vfs filesystem management
76 uipc interprocess communication (sockets)
77 subr miscellaneous support routines
78 vm virtual memory management
79 ufs local filesystems broken down as follows
80 ufs common local filesystem routines
82 lfs log-based filesystem
83 mfs memory based filesystem
84 nfs Sun-compatible network filesystem
85 miscfs miscellaneous filesystems broken down as follows
86 deadfs where rejected vnodes go to die
87 fdesc access to per-process file descriptors
88 fifofs IEEE Std1003.1 FIFOs
89 kernfs filesystem access to kernel data structures
90 lofs loopback filesystem
91 nullfs another loopback filesystem
92 portal associate processes with filesystem locations
93 specfs device special files
94 umapfs provide alternate uid/gid mappings
95 dev generic device drivers (SCSI, vnode, concatenated disk)
98 The networking code is organized by protocol
101 net routing and generic interface drivers
102 netinet Internet protocols (TCP, UDP, IP, etc)
103 netiso ISO protocols (TP-4, CLNP, CLTP, etc)
104 netns Xerox network systems protocols (IDP, SPP, etc)
105 netx25 CCITT X.25 protocols (X.25 Packet Level, HDLC/LAPB)
108 A separate subdirectory is provided for each machine architecture
111 hp300 HP 9000/300 series of Motorola 68000-based machines
112 hp code common to both HP 68k and (non-existent) PA-RISC ports
113 i386 Intel 386/486-based PC machines
114 luna68k Omron 68000-based workstations
115 news3400 Sony News MIPS-based workstations
116 pmax Digital 3100/5000 MIPS-based workstations
117 sparc Sun Microsystems SPARCstation 1, 1+, and 2
118 tahoe (deprecated) CCI Power 6-series machines
119 vax (deprecated) Digital VAX machines
122 Each machine directory is subdivided by function;
123 for example the hp300 directory contains
126 include exported machine-dependent header files
127 hp300 machine-dependent support code and private header files
129 conf configuration files
130 stand machine-dependent standalone code
133 Other kernel related directories
136 compile area to compile kernels
137 conf machine-independent configuration files
138 stand machine-independent standalone code
140 .Sh 3 "Devices and device drivers"
142 Devices supported by UNIX are implemented in the kernel
143 by drivers whose source is kept in
144 .Pn /sys/<architecture>/dev .
145 These drivers are loaded
146 into the system when included in a cpu specific configuration file
147 kept in the conf directory. Devices are accessed through special
148 files in the filesystem, made by the
150 program and normally kept in the
153 For all the devices supported by the distribution system, the
156 are created by devfs.
158 Determine the set of devices that you have and create a new
160 directory by mounting devfs.
161 .Sh 3 "Building new system images"
163 The kernel configuration of each UNIX system is described by
164 a single configuration file, stored in the
165 .Pn /sys/<architecture>/conf
167 To learn about the format of this file and the procedure used
168 to build system images,
169 start by reading ``Building 4.3BSD UNIX Systems with Config'' (SMM:2),
170 look at the manual pages in section 4
171 of the UNIX manual for the devices you have,
172 and look at the sample configuration files in the
173 .Pn /sys/<architecture>/conf
176 The configured system image
178 should be copied to the root, and then booted to try it out.
179 It is best to name it
181 so as not to destroy the working system until you are sure it does work:
183 \fB#\fP \fIcp kernel /newkernel\fP
186 It is also a good idea to keep the previous system around under some other
187 name. In particular, we recommend that you save the generic distribution
188 version of the system permanently as
190 for use in emergencies.
191 To boot the new version of the system you should follow the
192 bootstrap procedures outlined in section 6.1.
193 After having booted and tested the new system, it should be installed as
195 before going into multiuser operation.
196 A systematic scheme for numbering and saving old versions
197 of the system may be useful.
198 .Sh 2 "Configuring terminals"
200 If UNIX is to support simultaneous
201 access from directly-connected terminals other than the console,
208 To add a new terminal device, be sure the device is configured into the system
209 and that the special files for the device exist in
211 Then, enable the appropriate lines of
213 by setting the ``status''
214 field to \fBon\fP (or add new lines).
217 are one-for-one with entries in the file of current users
220 and therefore it is best to make changes
221 while running in single-user mode
222 and to add all the entries for a new device at once.
226 file is broken into four tab separated
227 fields (comments are shown by a `#' character and extend to
228 the end of the line). For each terminal line the four fields
230 the device (without a leading
234 should startup to service the line
235 (or \fBnone\fP if the line is to be left alone),
236 the terminal type (found in
237 .Pn /usr/share/misc/termcap ),
238 and optional status information describing if the terminal is
239 enabled or not and if it is ``secure'' (i.e. the super user should
240 be allowed to login on the line).
241 If the console is marked as ``insecure'',
242 then the root password is required to bring the machine up single-user.
243 All fields are character strings
244 with entries requiring embedded white space enclosed in double
246 Thus a newly added terminal
250 tty00 "/usr/libexec/getty std.9600" vt100 on secure # mike's office
252 The std.9600 parameter provided to
253 .Pn /usr/libexec/getty
254 is used in searching the file
256 it specifies a terminal's characteristics (such as baud rate).
257 To make custom terminal types, consult
262 Dialup terminals should be wired so that carrier is asserted only when the
263 phone line is dialed up.
264 For non-dialup terminals, from which modem control is not available,
265 you must wire back the signals so that
266 the carrier appears to always be present. For further details,
267 find your terminal driver in section 4 of the manual.
269 For network terminals (i.e. pseudo terminals), no program should
270 be started up on the lines. Thus, the normal entry in
276 (Note, the fourth field is not needed here.)
278 When the system is running multi-user, all terminals that are listed in
280 as \fBon\fP have their line enabled.
281 If, during normal operations, you wish
282 to disable a terminal line, you can edit the file
284 to change the terminal's status to \fBoff\fP and
285 then send a hangup signal to the
289 \fB#\fP \fIkill \-1 1\fP
291 Terminals can similarly be enabled by changing the status field
292 from \fBoff\fP to \fBon\fP and sending a hangup signal to
295 Note that if a special file is inaccessible when
297 tries to create a process for it,
299 will log a message to the
300 system error logging process (see
302 and try to reopen the terminal every minute, reprinting the warning
303 message every 10 minutes. Messages of this sort are normally
304 printed on the console, though other actions may occur depending
305 on the configuration information found in
306 .Pn /etc/syslog.conf .
308 Finally note that you should change the names of any dialup
310 where ? is in [0-9a-zA-Z], as some programs use this property of the
311 names to determine if a terminal is a dialup.
313 While it is possible to use truly arbitrary strings for terminal names,
314 the accounting and noticeably the
316 command make good use of the convention that tty names
317 (by default, and also after dialups are named as suggested above)
318 are distinct in the last 2 characters.
319 Change this and you may be sorry later, as the heuristic
321 uses based on these conventions will then break down and
323 will run MUCH slower.
326 The procedure for adding a new user is described in
328 You should add accounts for the initial user community, giving
329 each a directory and a password, and putting users who will wish
330 to share software in the same groups.
332 Several guest accounts have been provided on the distribution
333 system; these accounts are for people at Berkeley,
334 Bell Laboratories, and others
335 who have done major work on UNIX in the past. You can delete these accounts,
336 or leave them on the system if you expect that these people would have
337 occasion to login as guests on your system.
338 .Sh 2 "Site tailoring"
340 All programs that require the site's name, or some similar
341 characteristic, obtain the information through system calls
342 or from files located in
344 Aside from parts of the
345 system related to the network, to tailor the system to your
346 site you must simply select a site name, then edit the file
352 use a variable to set the hostname,
354 hostname=\fImysitename\fP
355 /bin/hostname $hostname
357 to define the value returned by the
359 system call. If you are running the name server, your site
360 name should be your fully qualified domain name. Programs such as
366 use this system call so that the binary images are site
369 You will also need to edit
371 to do the network interface initialization using
373 If you are not sure how to do this, see sections 5.1, 5.2, and 5.3.
374 If you are not running a routing daemon and have
375 more than one Ethernet in your environment
376 you will need to set up a default route;
377 see section 5.4 for details.
378 Before bringing your system up multiuser,
379 you should ensure that the networking is properly configured.
380 The network is started by running
382 Once started, you should test connectivity using
384 You should first test connectivity to yourself,
385 then another host on your Ethernet,
386 and finally a host on another Ethernet.
389 program can be used to inspect and debug
390 your routes; see section 5.4.
391 .Sh 2 "Setting up the line printer system"
393 The line printer system consists of at least
394 the following files and commands:
398 /usr/bin/lpq spooling queue examination program
399 /usr/bin/lprm program to delete jobs from a queue
400 /usr/bin/lpr program to enter a job in a printer queue
401 /etc/printcap printer configuration and capability database
402 /usr/sbin/lpd line printer daemon, scans spooling queues
403 /usr/sbin/lpc line printer control program
404 /etc/hosts.lpd list of host allowed to use the printers
410 is a master database describing line
411 printers directly attached to a machine and, also, printers
412 accessible across a network. The manual page
414 describes the format of this database and also
415 shows the default values for such things as the directory
416 in which spooling is performed. The line printer system handles
417 multiple printers, multiple spooling queues, local and remote
418 printers, and also printers attached via serial lines that require
419 line initialization such as the baud rate. Raster output devices
420 such as a Varian or Versatec, and laser printers such as an Imagen,
421 are also supported by the line printer system.
423 Remote spooling via the network is handled with two spooling
424 queues, one on the local machine and one on the remote machine.
425 When a remote printer job is started with
427 the job is queued locally and a daemon process created to oversee the
428 transfer of the job to the remote machine. If the destination
429 machine is unreachable, the job will remain queued until it is
430 possible to transfer the files to the spooling queue on the
433 program shows the contents of spool
434 queues on both the local and remote machines.
436 To configure your line printers, consult the printcap manual page
437 and the accompanying document, ``4.3BSD Line Printer Spooler Manual'' (SMM:7).
440 program should be present in
442 .Sh 2 "Setting up the mail system"
444 The mail system consists of the following commands:
448 /usr/bin/mail UCB mail program, described in \fImail\fP\|(1)
449 /usr/sbin/sendmail mail routing program
450 /var/spool/mail mail spooling directory
451 /var/spool/secretmail secure mail directory
452 /usr/bin/xsend secure mail sender
453 /usr/bin/xget secure mail receiver
454 /etc/aliases mail forwarding information
455 /usr/bin/newaliases command to rebuild binary forwarding database
456 /usr/bin/biff mail notification enabler
457 /usr/libexec/comsat mail notification daemon
460 Mail is normally sent and received using the
464 which provides a front-end to edit the messages sent
465 and received, and passes the messages to
468 The routing algorithm uses knowledge of the network name syntax,
469 aliasing and forwarding information, and network topology, as
470 defined in the configuration file
471 .Pn /usr/lib/sendmail.cf ,
472 to process each piece of mail.
473 Local mail is delivered by giving it to the program
474 .Pn /usr/libexec/mail.local
475 that adds it to the mailboxes in the directory
476 .Pn /var/spool/mail/<username> ,
477 using a locking protocol to avoid problems with simultaneous updates.
478 After the mail is delivered, the local mail delivery daemon
479 .Pn /usr/libexec/comsat
480 is notified, which in turn notifies users who have issued a
481 ``\fIbiff\fP y'' command that mail has arrived.
483 Mail queued in the directory
485 is normally readable only by the recipient.
486 To send mail that is secure against perusal
487 (except by a code-breaker) you should use the secret mail facility,
488 which encrypts the mail.
490 To set up the mail facility you should read the instructions in the
491 file READ_ME in the directory
492 .Pn /usr/src/usr.sbin/sendmail
493 and then adjust the necessary configuration files.
494 You should also set up the file
496 for your installation, creating mail groups as appropriate.
497 For more informations see
498 ``Sendmail Installation and Operation Guide'' (SMM:8) and
499 ``Sendmail \- An Internetwork Mail Router'' (SMM:9).
500 .Sh 3 "Setting up a UUCP connection"
504 included in \*(4B has the following features:
506 support for many auto call units and dialers
507 in addition to the DEC DN11,
509 breakup of the spooling area into multiple subdirectories,
513 file to control the set
514 of commands that may be executed by a remote site,
516 enhanced ``expect-send'' sequence capabilities when
517 logging in to a remote site,
519 new commands to be used in polling sites and
520 obtaining snap shots of
524 additional protocols for different communication media.
526 This section gives a brief overview of
528 and points out the most important steps in its installation.
530 To connect two UNIX machines with a
532 network link using modems,
533 one site must have an automatic call unit
534 and the other must have a dialup port.
535 It is better if both sites have both.
537 You should first read the paper in the UNIX System Manager's Manual:
538 ``Uucp Implementation Description'' (SMM:14).
539 It describes in detail the file formats and conventions,
540 and will give you a little context.
542 the document ``setup.tblms'',
543 located in the directory
544 .Pn /usr/src/usr.bin/uucp/UUAIDS ,
545 may be of use in tailoring the software to your needs.
549 support is located in three major directories:
553 .Pn /var/spool/uucp .
554 User commands are kept in
556 operational commands in
560 is used as a spooling area.
567 /usr/bin/uucp file-copy command
568 /usr/bin/uux remote execution command
569 /usr/bin/uusend binary file transfer using mail
570 /usr/bin/uuencode binary file encoder (for \fIuusend\fP)
571 /usr/bin/uudecode binary file decoder (for \fIuusend\fP)
572 /usr/bin/uulog scans session log files
573 /usr/bin/uusnap gives a snap-shot of \fIuucp\fP activity
574 /usr/bin/uupoll polls remote system until an answer is received
575 /usr/bin/uuname prints a list of known uucp hosts
576 /usr/bin/uuq gives information about the queue
579 The important files and commands in
585 /usr/lib/uucp/L-devices list of dialers and hard-wired lines
586 /usr/lib/uucp/L-dialcodes dialcode abbreviations
587 /usr/lib/uucp/L.aliases hostname aliases
588 /usr/lib/uucp/L.cmds commands remote sites may execute
589 /usr/lib/uucp/L.sys systems to communicate with, how to connect, and when
590 /usr/lib/uucp/SEQF sequence numbering control file
591 /usr/lib/uucp/USERFILE remote site pathname access specifications
592 /usr/lib/uucp/uucico \fIuucp\fP protocol daemon
593 /usr/lib/uucp/uuclean cleans up garbage files in spool area
594 /usr/lib/uucp/uuxqt \fIuucp\fP remote execution server
597 while the spooling area contains the following important files and directories:
601 /var/spool/uucp/C. directory for command, ``C.'' files
602 /var/spool/uucp/D. directory for data, ``D.'', files
603 /var/spool/uucp/X. directory for command execution, ``X.'', files
604 /var/spool/uucp/D.\fImachine\fP directory for local ``D.'' files
605 /var/spool/uucp/D.\fImachine\fPX directory for local ``X.'' files
606 /var/spool/uucp/TM. directory for temporary, ``TM.'', files
607 /var/spool/uucp/LOGFILE log file of \fIuucp\fP activity
608 /var/spool/uucp/SYSLOG log file of \fIuucp\fP file transfers
615 start by selecting a site name
616 (shorter than 14 characters).
619 account must be created in the password file and a password set up.
621 create the appropriate spooling directories with mode 755
626 If you have an auto-call unit,
627 the L.sys, L-dialcodes, and L-devices files should be created.
628 The L.sys file should contain
629 the phone numbers and login sequences
630 required to establish a connection with a
632 daemon on another machine.
633 For example, our L.sys file looks something like:
635 adiron Any ACU 1200 out0123456789- ogin-EOT-ogin uucp
636 cbosg Never Slave 300
637 cbosgd Never Slave 300
638 chico Never Slave 1200 out2010123456
640 The first field is the name of a site,
641 the second shows when the machine may be called,
642 the third field specifies how the host is connected
643 (through an ACU, a hard-wired line, etc.),
644 then comes the phone number to use in connecting through an auto-call unit,
645 and finally a login sequence.
647 may contain common abbreviations that are defined in the L-dialcodes file.
648 The device specification should refer to devices
649 specified in the L-devices file.
650 Listing only ACU causes the
654 to search for any available auto-call unit in L-devices.
655 Our L-dialcodes file is of the form:
660 while our L-devices file is:
662 ACU cul0 unused 1200 ventel
664 Refer to the README file in the
666 source directory for more information about installation.
670 operates it creates (and removes) many small
671 files in the directories underneath
672 .Pn /var/spool/uucp .
673 Sometimes files are left undeleted;
674 these are most easily purged with the
677 The log files can grow without bound unless trimmed back;
679 maintains these files.
680 Many useful aids in maintaining your
682 installation are included in a subdirectory UUAIDS beneath
683 .Pn /usr/src/usr.bin/uucp .
684 Peruse this directory and read the ``setup'' instructions also located there.
projects / FreeBSD / releng / 9.2.git / blob