BH02803P000_SCO_TCP_IP_Runtime_System_for_SCO_Unix_Systems_Users_and_Administrators_Guide_May92 BH02803P000 SCO TCP IP Runtime System For Unix Systems Users And Administrators Guide May92
BH02803P000_SCO_TCP_IP_Runtime_System_for_SCO_Unix_Systems_Users_and_Administrators_Guide_May92 BH02803P000_SCO_TCP_IP_Runtime_System_for_SCO_Unix_Systems_Users_and_Administrators_Guide_May92
User Manual: BH02803P000_SCO_TCP_IP_Runtime_System_for_SCO_Unix_Systems_Users_and_Administrators_Guide_May92
Open the PDF directly: View PDF 
.
Page Count: 231
| Download | |
| Open PDF In Browser | View PDF |
SCO®TCPIIP
Runtime System
for SCO®UNIX®Systems
User's and
Administrator's Guide
sca®TCP/IP
Runtitne Systetn
for sca UNIX System.s
®
®
User's and Administrator's Guide
© 1983-1992 The Santa Cruz Operation, Inc.
© 1980-1992 Microsoft Corporation.
© 1989-1992 UNIX System Laboratories, Inc.
All Rights Reserved.
No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor
translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the
copyright owner, The Santa Cruz Operation, Inc., 400 Encinal, Santa Cruz, California, 95060, U.S.A.
Copyright infringement is a serious matter under the United States and foreign Copyright Laws.
The copyrighted software that accompanies this manual is licensed to the End User only for use in
strict accordance with the End User License Agreement, which should be read carefully before commencing use of the software. Information in this document is subject to change without notice and
does not represent a commitment on the part of The Santa Cruz Operation, Inc.
SCO OPEN DESKTOP Software is commercial computer software and, together with any related
documentation, is subject to the restrictions on U.S. Government use as set forth below.
If this procurement is for a DOD agency, the following DFAR Restricted Rights Legend applies:
RESTRICTED RIGHTS LEGEND: Use, duplication or disclosure by the Government is subject to
restrictions as set forth in subpararaph (c)(1)(ii) of rights in Technical Data and Computer Software
Clause at DFARS 252.227-7013. Contractor/Manufacturer is The Santa Cruz Operation, Inc., 400
Encinal Street, Santa Cruz, CA 95060.
If this procurement is for a civilian government agency, the following FAR Restricted Rights Legend
applies:
RESTRICTED RIGHTS LEGEND: This computer software is submitted with restricted rights under
Government Contract No.
(and Subcontract No.
, if appropriate). It may not be
used, reproduced, or disclosed by the Government except as provided in Paragraph (g)(3)(i) of FAR
Clause 52.227-14 or as otherwise expressly stated in the contract. Contractor/Manufacturer is The
Santa Cruz Operation, Inc., 400 Encinal Street, Santa Cruz, CA 95060.
SCO, SCO Open Desktop, SCO and The Santa Cruz Operation, the SCO Open Desktop logo, and the
SCO logo are registered trademarks of The Santa Cruz Operation, Inc. in the USA and other countries.
All other brand and product names are or may be trademarks of, and are used to identify products
or services of, their respective owners.
seo TCP lIP is derived from Interactive Systems Corporation
SYSTEM V STREAMS TCPlIP, a joint development of ISC and Convergent Technologies.
Date: 15 May 1992
Document version: 1.2.0A
Preface
1
About this guide .........................................................................................................
Conventions used in this guide ...............................................................................
Reference pages ..........................................................................................................
Related reading ...........................................................................................................
1
3
3
4
Chapter 1
Networking and TCPIIP overview
5
How the network works .................................................................................................... 6
Designing or adding to your network .................................................................... 7
Common networking administration tasks .......................................................... 8
Introducing TCP/IP ............................................................................................................... 8
The Internet Protocol (IP) .......................................................................................... 9
The Transmission Control Protocol (TCP) ............................................................. 9
Other TCP lIP protocols ................................................................................. 10
TCP lIP end-user commands .................................................................................. 11
Configuring TCPIIP ............................................................................................................ 11
System name .............................................................................................................. 12
Driver type ................................................................................................................. 12
Interrupt vector ......................................................................................................... 12
1/ a base address ...................................................................................................... 12
Thick/ thin cable ....................................................................................................... 13
RAM buffer size and base address ......................................................................... 13
ROM base address ..................................................................................................... 13
Token Ring routing .................................................................................................. 13
Domain name ............................................................................................................ 14
IP address ................................................................................................................... 14
Broadcast address parameters ............................................................................... 16
netmask setting ..................... .................................................................................... 17
Gateway status .......................................................................................................... 17
TCP lIP over a SLIP or PPP serial line .................................................................... 17
tty line ................................................................................................................ 17
Source IP address ............................................................................................ 17
Destination IP address ................................................................................... 18
Baud rate .......................................................................................................... 18
SLIP netmask .................................................................................................... 18
Maintaining TCP/IP ........................................................................................................... 18
Adding hosts ............................................................................................................. 18
Table of contents
v
Configuring the name domain server ..................................................................
Setting up routing tables .........................................................................................
Establishing user equivalence ................................................................................
Setting up anonymous ftp ......................................................................................
Altering installation parameters ...........................................................................
Tuning kernel parameters .......................................................................................
Monitoring TCP/IP status .' .....................................................................................
Enabling remote printing ........................................................................................
18
18
19
19
19
19
19
20
Chapter 2
Logging in to a remote machine
21
The rlogin command .........................................................................................................
rlogin command-line options ................................................................................
Using a tilde in the text ...........................................................................................
The tel net program ............................................................................................................
telnet command-line options .................................................................................
22
22
23
23
24
Chapter 3
Transferring files between machines
25
The rcp command ..............................................................................................................
Copying files of other users ....................................................................................
Copying between remote machines .....................................................................
The ftp command ...............................................................................................................
Invoking ftp ...............................................................................................................
Connecting to another machine with ftp ............................................................
Transferring files with ftp .......................................................................................
Transferring files with a non-UNIX system .........................................................
Logging in automatically through the .netrc file ...............................................
Using anonymous ftp ..............................................................................................
ftp command options ..............................................................................................
25
26
26
27
27
27
28
29
29
30
30
Chapter 4
Running commands remotely with rcmd
31
Invokingrcmd .................................................................................................................... 31
Using shell metacharacters ............................................................................................. 32
rcmd command-line options ........................................................................................... 32
vi
Chapter 5
Sending mail across the network
33
Chapter 6
Other useful commands
35
Chapter 7
Network administration
37
Kernel configuration .........................................................................................................
Setting interface parameters ...........................................................................................
Creating a subnetwork .....................................................................................................
Network servers .................................................................................................................
Network databases ............................................................................................................
Establishing user equivalence ................................................................................
Setting up anonymous ftp ......................................................................................
Administering pseudo ttys .............................................................................................
Network tuning and troubleshooting ..........................................................................
STREAMS tuning .......................................................................................................
Active connections display ....................................................................................
netstat -a ...........................................................................................................
Descriptions of the display headings .........................................................
Interfaces ....................................................................................................................
netstat -i ............................................................................................................
Descriptions of the display headings .........................................................
Routing tables ...........................................................................................................
netstat -r ............................................................................................................
Descriptions of the display headings .........................................................
Statistics display .......................................................................................................
netstat -s ...........................................................................................................
Table of contents
37
41
41
42
43
43
44
46
47
47
49
49
50
50
50
50
51
51
52
52
53
vii
Chapter 8
Administering serial line communications
55
Administering SLIP ...........................................................................................................
CoI\figuring a SLIP connection ..............................................................................
Preparing to configure a SLIP connection ..................................................
Configuring a direct SLIP connection .........................................................
Configuring a dialup SLIP connection .......................................................
Configuring a SLIP /Ethemet or SLIP /Token-Ring gateway.................
Removing SLIP ................................................................................................
Troubleshooting SLIP configurations ...................................................................
Common problems with SLIP ......................................................................
Verifying serial cable connectivity ..............................................................
Troubleshooting problems with ping .........................................................
Troubleshooting problems with rlogin or telnet ......................................
More SLIP information ............................................................................................
Administering ppp ............................................................................................................
PPP compared to SLIP .............................................................................................
Configuring PPP .......................................................................................................
Preparing to configure PPP ..........................................................................
Configuring PPP with netconfig .................................................................
Adding PPP information to configuration files .......................................
Configuring a PPP /Ethernet or PPP /Token-Ring gateway ...................
Removing PPP .................................................................................................
Troubleshooting PPP ...............................................................................................
More PPP information .............................................................................................
55
56
56
56
58
60
61
61
62
62
63
64
64
64
65
65
66
66
68
69
70
70
72
Chapter 9
Configuring the BIND name server
73
The name service ...............................................................................................................
1'ypes of servers .................................................................................................................
Master servers ...........................................................................................................
Primary .............................................................................................................
Secondary .........................................................................................................
Caching-only servers ...............................................................................................
Remote servers ..........................................................................................................
Slave server ................................................................................................................
viii
73
74
74
74
74
75
75
75
Setting up your own domain .......................................................................................... 76
Internet .............................................................................................................. 76
BITNET ............................................................................•................................. 76
Boot file ....................................................................................................................... 76
Directory ........................................................................................................... 76
Primary master ................................................................................................ 77
Secondary master ........................................................................................... 77
Caching-only server ....................................................................................... 77
Forwarders ....................................................................................................... 78
Slave mode ....................................................................................................... 78
Remote servers ................................................................................................................... 78
Initializing the cache ........................................................................................................ 78
Standard files ...................................................................................................................... 79
Standard resource records ............................................................................................... 79
Separating data into multiple files ........................................................................ 80
Changing an origin in a data file ........................................................................... 81
The start of authority resource record (SOA) ...................................................... 81
The name server resource record (NS) ................................................................. 82
The address resource record (A) ............................................................................ 82
The host information resource record (HINFO) ................................................. 82
The well-known services resource record (WKS) .............................................. 83
The canonical name resource record (CNAME) ................................................. 83
The domain name pointer resource record (PfR) .............................................. 83
The mailbox resource record (MB) ........................................................................ 84
The mail rename resource record (MR) ................................................................ 84
The mailbox information resource record (MINFO) .......................................... 84
The mail group member resource record (MG) .................................................. 85
The mail exchanger resource record (MX) ........................................................... 85
Some sample files .............................................................................................................. 86
Caching-only server ................................................................................................. 86
Primary master server ............................................................................................. 86
Secondary master server ......................................................................................... 86
The /etc/resolv.conf file ......................................................................................... 87
root. cache ................................................................................................................... 87
named.local ................................................................................................................ 87
named.hosts ............................................................................................................... 88
named.rev .................................................................................................................. 89
Additional sample files .................................................................................................... 89
named.boot ................................................................................................................ 89
root. cache ................................................................................................................... 90
named.local ............................................................................... ................................. 90
Table of contents
ix
mynet-host.s.rev .......................................................................................................
mynet.soa ...................................................................................................................
Domain management .......................................................................................................
Starting the name server .........................................................................................
/etc/named.pid .........................................................................................................
/etc/hosts ..................................................................................................................
Reload .........................................................................................................................
Debugging ..................................................................................................................
More BIND information ...........................................................................................
91
91
91
91
92
92
92
93
93
Chapter 10
Gateways and routing
95
Runningrouted .................................................................................................................. 96
Running gated .................................................................................................................... 97
Sample configuration file ........................................................................................ 98
More gated information ................................................................................................. 101
Chapter 11
Configuring and using SNMP
103
Basic concepts ..................................................................................................................
The SNMP protocol .................................................................................................
SMI: Structure of Management Information .....................................................
MIB: the Management Information Base ...........................................................
Other concepts .................................................................................................................
Agents and management stations ......................................................................
Traps ..........................................................................................................................
Authentication ........................................................................................................
Overview of the seQ implementation .......................................................................
Configuring the SNMP agent .. .,....................................................................................
Using the SNMP commands ..........................................................................................
Using SNMP to correct problems .................................................................................
Obtaining remote system contacts .....................................................................
Removing an incorrect routing entry .................................................................
Marking an interface down ..................................................................................
Removing an incorrect ARP entry .......................................................................
More SNMP information ...............................................................................................
x
103
104
104
106
106
106
107
107
107
109
110
115
115
115
116
117
117
Chapter 12
Remote line printing
119
Installing and removing RLP ........................................................................................
How RLP works ................................................................................................................
Using RLP ..........................................................................................................................
seQ clients ...............................................................................................................
4.3BSD clients ...........................................................................................................
Setting up a client ............................................................................................................
Setting up a print server ................................................................................................
Deleting printcap entries ..............................................................................................
120
121
122
122
123
123
126
127
Chapter 13
Synchronizing clocks
129
Time synchronization protocol ....................................................................................
How the time daemon works ..............................................................................
Guidelines ................................................................................................................
Options .....................................................................................................................
Daily operation .......................................................................................................
Network time protocol ...................................................................................................
Important terms ......................................................................................................
Overview ..................................................................................................................
Guidelines ................................................................................................................
An example synchronization subnet ..................................................................
The NTP configuration file ....................................................................................
Configuration statements ...........................................................................
Example ntp.conf file .... "., ...........................................................................
The keys file ...................................................................................................
The clock. txt file ............................................................................................
The driftfile ....................................................................................................
Association modes ,......................................................................................
Address and mask facility ..........................................................................
Name resolution ...........................................................................................
Sample scenarios ....................................................................................................
Testing and tuning .................................................................................................
Query commands ...................................................................................................
Further examples ....................................................................................................
Troubleshooting ......................................................................................................
Running mixed synchronization subnets .........................................................
Table of contents
129
130
131
132
132
133
133
136
136
137
138
139
142
142
144
145
145
146
148
149
152
153
154
157
158
xi
Chapter 14
TCPIIP sendmail administration
159
sendmail and other mailers ..........................................................................................
Comparing send mail with delivermail .............................................................
Comparing sendmail with MMDF .......................................................................
Sendmail and the message-processing module (MPM) .................................
How sendmail works .....................................................................................................
Collecting messages ...............................................................................................
Delivering messages ..............................................................................................
Queueing for retransmission ...............................................................................
Return to sender .....................................................................................................
Editing the message header .................................................................................
Aliasing, forwarding and including mail ..........................................................
Aliasing ...........................................................................................................
Forwarding ....................................................................................................
Including ........................................................................................................
Queued messages ...................................................................................................
Configuring sendmail .....................................................................................................
Configuring a standard installation ...................................................................
Configuring a non-standard installation ...........................................................
The syntax ......................................................................................................
Rand 5 - rewriting rules ....................................................................
D - define macro ..................................................................................
C and F - define classes ......................................................................
M - define mailer .................................................................................
H - define header ................................................................................
o - set option .......................................................................................
T - define trusted users ......................................................................
P - precedence definitions .................................................................
The semantics ................................................................................................
Special macros, conditionals ............................................................
Special classes .....................................................................................
The left-hand side ...............................................................................
The right-hand side ............................................................................
Semantics of rewriting rule sets ......................................................
Mailer flags ..........................................................................................
The error" mailer .........................................................................................
1/
xii
160
160
160
161
162
162
163
163
163
164
164
164
164
164
165
165
165
167
167
167
168
168
168
169
169
169
169
170
170
172
172
172
174
174
175
Building a configuration file from scratch ..............................................
Purpose of the configuration table ..................................................
Relevant issues ....................................................................................
How to proceed ..................................................................................
Testing the rewriting rules: the -bt flag ..........................................
Building mailer descriptions ............................................................
Configuration options ...........................................................................................
Running sendmail ...........................................................................................................
Command line flags ...............................................................................................
Mailer flags ..............................................................................................................
Arguments ...............................................................................................................
Queue interval ..............................................................................................
Daemon mode ...............................................................................................
Forcing the queue .........................................................................................
Debugging ......................................................................................................
Trying a different configuration file ..........................................................
Changing the values of options .................................................................
Tuning .......................................................................................................................
Timeouts .........................................................................................................
Queue interval ..............................................................................................
Read timeouts ...............................................................................................
Message timeouts ...............................................................................
Forking during queue runs .........................................................................
Queue priorities ............................................................................................
Delivery mode ...............................................................................................
File modes ......................................................................................................
To suid or not to suid? .......................................................................
Temporary file modes ........................................................................
Should the alias database be writable? ..........................................
Administering sendmail ................................................................................................
System log ................................................................................................................
The mail queue ........................................................................................................
Forma t of sendmail queue files .................................................................
Forcing the queue .........................................................................................
sendmail configuration file ...................................................................................
The alias database ..................................................................................................
Rebuilding the alias database ....................................................................
Potential alias database problems .............................................................
List owners .....................................................................................................
Per-user forwarding (.forward files) ...................................................................
Table of contents
175
175
175
176
176
177
179
181
181
183
184
184
184
185
185
185
185
185
186
186
186
186
187
187
187
188
188
188
188
189
189
189
189
191
192
192
193
193
193
194
xiii
Special header lines ................................................................................................
Return-receipt-to: .........................................................................................
Errors-to: .........................................................................................................
Apparently-to: ...............................................................................................
Summary of support files .....................................................................................
More sendmail information .........................................................................................
194
194
194
194
195
196
Chapter 15
Helpful hints
197
Setting the broadcast address .......................................................................................
Problem with WD8003 card ...........................................................................................
Making remote backups ................................................................................................
Backing up files or filesystems ............................................................................
Restoring a backup .................................................................................................
Differences in sendmail implementations ...............................................................
Setting up user equivalence .........................................................................................
197
198
198
199
200
200
201
Chapter 16
Bibliography
203
Index
205
xiv
Preface
sca® TCP lIP is a set of protocols and programs used to interconnect computer networks and to route traffic among different types of computers. It provides the following key services:
• data transfer protocols that applications such as mail or sea NFS can use to
move data from machine to machine
• programs that allow the user to log in remotely to other computers on the
network, print remotely, transfer files, and perform other network-based
tasks
• protocols and programs that provide for network management and troubleshooting, such as the Simple Network Management Protocol (SNMP) and
the Berkeley Internet Name Domain (BIND) Server
About this guide
The sea yep/IP User's and Administrator's Guide provides functional descriptions of TCP lIP components and steps for TCP lIP configuration. Chapters 2
through 6 are intended for end users; chapters 7 through 15 are intended for
system administrators and others with an interest in the administration and
configuration of TCP/IP.
Chapter I, "Using and Administering TCP/IP," provides conceptual information about networking and how TCP lIP works, such as descriptions of the
Internet Protocol and a discussion of installation concepts. Chapter 1 also
gives you network planning ideas, and we strongly suggest that you read this
chapter before installing TCP lIP.
1
Preface
Chapter 2, "Logging into a remote machine," explains how to use the rlogin
and telnet commands to access another machine on the network.
Chapter 3, "Transferring files between machines," shows how you can use ftp
and rcp to move files from one networked machine to another.
Chapter 4, "Running commands remotely with rcmd," tells you how to run a
command on another machine from your machine.
Chapter 5, "Sending mail across the network," provides a brief introduction to
the mail command.
Chapter 6, "Other useful commands," lists several other user-level TCP lIP
commands you may find useful.
Chapter 7, "Administering TCP lIP," describes many of the basic TCP lIP
administration tasks, such as establishing user equivalence and adding
pseudo-ttys.
Chapter 8, "Administering serial line communications," describes serial line
communications over TCP lIP, including the SLIP and PPP protocols.
Chapter 9, "Configuring the BIND name server," shows how to configure the
Berkeley Internet Name Domain Server, a distributed host name and address
lookup system.
Chapter 10, "Gateways and routing," explains how to set up your system as a
gateway computer through use of gated and routed.
Chapter 11, "Configuring and using SNMP," describes the Simple Network
Management Protocol, a set of programs by which you can monitor and
troubleshoot your network.
Chapter 12, "Remote line printing:' describes how to enable remote printing
over TCP lIP.
Chapter 13, "Synchronizing clocks," explains the two time protocols you can
configure for use with your network.
Chapter 14, "Configuring sendmail," explains how to configure sendmail, one
of the mail routers supported by TCP lIP.
Chapter 15, "Helpful Hints," provides answers to several common troubleshooting questions.
The "Bibliography" describes related reading that provides further information about TCP lIP.
2
TCP/IP Administrator's Guide
Conventions used in this guide
This guide uses the following notational conventions:
bold
represents commands, command options, parameters in files,
data structures, and daemons
BOLD CAPS
represents parameters contained in files
italics
bold italics
represents files and directories
represent variables that you supply; for example, in the command argument path:pathname, the variable pathname is
replaced with an actual pathname when you type the command
()
represents special keys that you press; for example, (Ctrl)x
means to hold down the Control key and press the x key
simultaneously, then release them
Courier
represents system responses, excerpts from files, and programming examples
Reference pages
Reference pages, also called manual pages or man pages, are descriptive
pages for commands, daemons, and files, and other items related to a given
product. Reference pages can be viewed online using the man command. For
example, to get information about the tar command, you enter man tar at the
UNIX® system prompt.
Commands that have reference pages have one or more letters associated
with them, such as tar(C). The letters in parentheses tell you which reference
page section to look in to find information on that command. The letters also
tell you which product the command belongs to. For example, commands
with the (ADM) suffix are UNIX system administration commands. Commands with the (ADMN) suffix are TCP lIP administration commands. The following letters are relevant to TCP lIP:
C
UNIX system user-level commands
ADM
UNIX system administration commands
ADMN
TCP lIP network administration commands
ADMP
TCP lIP network protocols and drivers
SFF
TCP lIP network file formats
TC
TCP lIP user-level commands
3
Preface
For information on manual pages that have the (ADMN), (ADMP), (SFF), or
(TC) suffixes, for example rlogind(ADMN), refer to the sca TCP/IP Command's
Reference. For all other commands, check your sca UNIX System Vj386 User's
Reference for a list of manual page sections and their abbreviations.
Related reading
Refer to the other manuals in this set for more information on the various
aspects of TCP lIP:
• The sca TCP/IP Release and Installation Notes describe how to install TCP lIP
and provide the latest information on the product.
• The sca TCP/IP Command Reference describes all administrative and userlevel commands, daemons, and files associated with TCP lIP.
4
TCP/IP Administrator's Guide
Chapter 1
Networking and yep/IP overview
This chapter describes networking in general and TCP lIP in particular. After
you read this chapter, you will have a better understanding of the components that make up the TCP lIP package, and you can pick and choose
which components you want to configure. We strongly recommend that you
read this chapter before installing any networking software.
Networking, simply put, is connecting your computers together so they can
share information. Effective networking increases productivity by using computer resources, such as files, printers, and memory, more efficiently. A network puts the power of all of your system's hardware and software at your
fingertips.
Although there are many different types of networks, they fall into two general categories: local area networks (LANs) and wide area networks (WANs).
A LAN connects computers that are in the same office or in adjacent buildings.
All the computers on a LAN are connected to a single cable. A computer on a
LAN can communicate directly to any other computer on that LAN. One LAN
may also be connected to another LAN via a gateway computer.
A WAN connects computers that can be as close as several hundred feet to as
far as across the globe. These connections are made using phone lines and
sometimes satellite connections, if the distance is great enough. Sometimes a
computer must go through one or more computers, or gateways, to reach the
one with which it wants to communicate.
Most networks are a combination of local and wide area networks. Figure 1-1
displays a portion of a typical local area network. It includes several client
computers, a server computer, a printer that is accessible to any machine on
the network, an Ethernet TM cable connecting the machines, and a computer
running sea Open Oesktop®, which may be a client, a server, or both.
5
Networking and TCP/IP overview
Servers, often the most powerful computers on the network, store data that
they make available to clients, other machines on the network that have access
to the servers' resources. You can have one or more servers on a network, and
a machine can be both a client and server. For example, one machine can
serve personnel information while another serves sales data. Each machine is,
therefore, a server, but each may also be a client to the other machine's data.
Client 1
I
Client 2
Client 3
Local Area Network (Ethernet)
Open Desktop
Server
Printer
Figure 1·1 Sample network
How the network works
A network, in the physical sense, consists of cables or phone lines. These lines
connect the computers, and networking cards provide the means to talk
across them. However, a network is not useful unless it has programs on each
computer that let humans access the various computers on the network.
Computers on a network have agreed ways of communicating called protocols. Protocols dictate which signals computers use across cables, how they
tell one another that they have received information, and how they exchange
information.
6
How the network works
Protocols are more accurately termed protocol suites or protocol families.
This subtle shift in terminology reflects the fact that the communications functions are complex and are usually divided into independent layers, also called
levels. The protocol associated with each layer communicates with only the
layers immediately above and below it, and assumes the support of underlyinglayers.
In protocol suites, lower layers are closer to the hardware and higher layers
are closer to the user. The number of layers and tasks that the layers perform
depends on who defines them. TCP lIP has four software layers built on an
underlying hardware layer. Its model is shown in table 1-1:
Table 1·1 Tcpnp Model
Layer
Name
Task
4
Application
3
Transport
2
Network
1
Physical
Accesses the transport layer, and sends
and receives data
Provides communication protocols
between application programs and the
network layer
Takes care of communication between
software and hardware
Accepts and transmits data over the
physical network
Designing or adding to your network
Your machine may be a part of an entirely new network, or it may become a
machine on a network that already exists. In either case, you need to make
several decisions about your machine:
• With what other computers does it need to communicate?
• Will it serve as a client, a server, or both?
• Who will use this machine, and what sort of access do they need?
7
Networking and YCP/IP overview
Common networking administration tasks
After you decide how your machine fits into the network, you need to install
and configure the appropriate TCP lIP packages as described in the sca TCP/IP
Release and Installation Notes. You also need to update the networking files on
other machines so that they know of the new machine's existence. This configuration ensures, among other things, that:
• all machines on the network know each other's names and addresses
• individual users will have access to files and accounts on various machines
• electronic mail is routed correctly
• the network runs at peak efficiency
Common tasks that you will perform to ensure these goals include:
• installing and maintaining networking hardware and software
• assigning names and addresses to each computer and device on the network
• assigning names and identification numbers (IDs) to network users and
groups
• performing the commands required to share, remove, and restrict resources
• updating all appropriate networking files on your network's machines
Introducing TCPIIP
TCP lIP is the set of protocols and programs used to interconnect computer
networks and to route traffic among different types of computers. "TCP"
stands for Transmission Control Protocol, and "IP" stands for Internet Proto-
col. These protocols describe allowable data formats, error handling, message
passing, and communication standards. Computer systems that use TCP lIP
speak a common language, despite any differences in the hardware and software of the various machines.
Many large networks conform to these protocols, including the DARPA Internet (Defense Advanced Research Projects Agency Internet). A variety of
universities, government agencies, and computer firms are connected to an
internetwork that follows the TCP lIP protocols. Thousands of machines are
connected to this Internet, or network of networks. Any machine on the internet can communicate with any other. Machines on the internet are referred to
as hosts or nodes, and are defined by their internet (or IP) address. Defining an
internet address is described later in this section.
8
Introducing TCP/IP
TCP lIP provides the basis for many useful services, including electronic mail,
file transfer, and remote login. Electronic mail is designed to transfer short
text files. The file transfer application programs transfer very large files containing programs or data. They also provide security checks controlling file
transfer. Remote login allows users on one computer to log in at a remote machine and carry on an interactive session. The TCP/IP programs that facilitate
these services are described in detail later in this guide.
The Internet Protocol (IP)
The Internet Protocol, IP, defines a data delivery system wherein the sending
and receiving machines are not necessarily directly connected. IP splits data
into packets of a given size, which are then forwarded to the receiving machine via the network. These individual packets of data (often called
datagrams> are routed through different machines on the internet to the destination network and receiving machine. A particular set of data, such as a file,
can be broken up into several datagrams that are sent separately. When you
use IP to forward datagrams, individual datagrams mayor may not arrive,
and they probably will not arrive in the order in which they were sent. TCP
adds the reliability that IP lacks.
A datagram consists of header information and a data segment. The header
information routes and processes the datagram. Datagrams can be further
fragmented into smaller pieces, depending on the physical requirements of
the networks they cross. For example, when a gateway sends a datagram to a
network that cannot accommodate the datagram as a single packet, the
datagram must be split into pieces that are small enough for transmission.
The datagram fragment headers contain the information necessary to
reassemble the fragments into the complete datagram. Fragments do not
necessarily arrive in order; the software module implementing the IP protocol
on the destination machine must reassemble the fragments into the original
datagram. If any fragments are lost, the entire datagram is discarded.
The Transmission Control Protocol (Tep)
The Transmission Control Protocol, TCP, works with IP to provide reliable
delivery. It provides a means to ensure that the various datagrams making up
a message are reassembled in the correct order at their final destination and
that any missing datagrams are resent until they are correctly received.
The primary purpose of TCP is to avoid the loss, damage, duplication, delay,
or misordering of packets that can occur under IP. Also, security provisions
such as limiting user access to certain machines can be implemented through
TCP.
9
Networking and TCP/IP overview
TCP provides reliability using checksums (error detection codes) on the data,
sequence numbers in the TCP header, positive acknowledgment of data
received, and retransmission of unacknowledged data.
Other TCPIIP protocols
The protocols listed in Table 1-2 are provided as part of TCP lIP:
Table 1·2 Additional Tcpnp protocols
Protocol
Purpose
Address Resolution
Protocol (ARP)
Internet Control
Message Protocol (ICMP)
Point-to-Point
Protocol (ppp)
ARP translates between DARPA Internet and Ethernet addresses.
ICMP is an error-message and control protocol
used by TCP lIP.
PPP provides both synchronous and asynchronous network connections.
RARP translates between Ethernet and DARPA
Internet addresses.
Reverse Address
Resolution Protocol
(RARP)
Serial Line
Internet Protocol (SLIP)
Simple Mail Transport
Protocol (SMTP)
Simple Network
Management Protocol
(SNMP)
User Datagram
Protocol (UDP)
SLIP enables IP over serial lines.
SMTP is used by MMDF to send mail via TCP lIP.
SNMP is the protocol used to perform distributed network management functions via
TCP/IP.
UDP provides data transfer without many of the
reliable delivery capabilities of TCP. UDP is less
CPU-intensive than TCP, and is useful when
guaranteed data delivery is not of paramount
importance.
These protocols are described in further detail later in this guide.
10
Configuring TCP/IP
TCPIIP
end-user commands
Several TCP lIP commands, described in detail in chapters 2 through 6 of this
guide, provide end users with networking capabilities. Table 1-3 is a partial
list of these commands:
Table 1-3 Tcpnp commands
Command
Purpose
ftp
file transfer between machines running TCP lIP; these machines
mayor may not be running the same operating system
remote command execution on another UNIX machine
file copying between two UNIX machines
remote login on another UNIX machine
status display of local network machines
displays list of users logged on to local network machines
remote login on a machine running TCP lIP; these machines may
or may not be running the same operating system
rcmd
rcp
rlogin
ruptime
rwho
telnet
Configuring TCPIIP
This section provides information on software and hardware prompts you
need to answer as you configure TCP lIP. We strongly recommend that you
read and understand this section before you attempt to install your software.
Installation prompts include:
• system's host name and domain name
• Internet address(es) for each driver, adapter, or serial line
• broadcast address
• netmask
• gateway status
• hardware information, including interrupt vectors, base memory
addresses, RAM buffer sizes and base addresses, ROM base addresses, DMA
channels, and slot numbers
11
Networking and TCP/IP overoiew
System name
Your system name, or host name, should be unique on your network. It can
consist of lowercase letters and numbers, must begin with a letter, and should
be no longer than eight characters. mail and other programs use the system
name to identify the correct data destination. Here are some sample valid machine names: scosysv, tcpdev, account1.
Driver type
The driver is the software that allows your networking cards or hardware to
interact with TCP /IP. Each card, adapter, slip or ppp line that you use must be
uniquely associated with a particular device driver. You can install up to four
Ethernet cards of one type, up to two Token Ring adapters, and up to eight
serial line interfaces (four SLIP and four PPP), but you can only configure one
driver at a time. When you are prompted for the driver type, choose the type
you want to configure.
Interrupt vector
Each driver on your system, including those for network cards and SLIP lines,
must have its own interrupt vector, or IRQ. This vector must not be used by
any other device on the system. Refer to your networking hardware documentation to determine what vectors the hardware supports. In addition, the
hwconfig(ADM) and vedorsinuse(ADM) programs list the hardware already
installed on your system and what vectors are already in use, respectively.
Your networking hardware might be pre-configured to use a particular vector.
If you want to change this vector setting, you might also need to change the
physical jumper settings on the board or run a setup program provided with
the board.
A number of networking cards are pre-configured to use interrupt
vector 3. Your operating system has reserved IRQ3 for the sio (serial inputoutput) device. You can either disable this device during your netconfig session, or choose another vector.
NOTE
YO base address
Each hardware driver on your system that performs I/O (input/output) needs
a unique memory base address so that the system can locate it. This memory
address is a three- or four-digit hexadecimal number, must match the settings
on the board, and must not conflict with any other hardware on your system.
Valid base addresses are displayed when you configure your card.
12
Configuring rep/IP
Thick/thin cable
Some networking cards use thick, rather than thin, networking cable.
• Thin cable provides a direct connection to the network without the use of a
transceiver. Most installations use thin cable.
• Thick cable connects your networking card to a transceiver, which in tum
connects to the Ethernet cable.
RAM buffer size and base address
Several networking cards require a designated space in RAM to do buffering;
you need to specify this address (as a five-digit hexadecimal number) and, if
necessary, configure the buffer size.
NOTE The wdnsetup command is used to change these values for some
Western Digital cards. For more information on this command, see the
wdnsetup(ADM) manual page.
I
ROM base address
Several Token Ring cards need a designated space in ROM to store information; see your Token Ring card documentation for more information on available addresses.
Token Ring routing
Token Ring allows you to establish connections from your machine to others
on the local ring, or to those on another ring using a bridge. To access those
machines on another ring, you must enable Token Ring routing when you
configure your Token Ring adapters.
13
Networking and TCP/IP overview
Domain name
The MMDF mail router uses the domain name to route messages, such as mail,
from machine to machine. The domain name allows your network to fit into a
hierarchical network structure composed of commercial organizations
(.COM), educational institutions (.EDU), the government (.GOV), the military
(.MIL) or miscellaneous organizations (.ORC). Sample domain names are
sco.COM (the domain name used by seO) and berkeley.EDU (the domain
name used by the University of California at Berkeley).
Base your domain name choice on the following:
• If other machines on your network already use a domain name, use the
same name for the machine you are installing.
• If you are creating a new domain and want to use BIND to connect to the
outside world, you need to register the name with the appropriate network
(DARPA Internet, CSNET, or BITNET). To register a domain name, write to:
DON Network Information Center
Suite 200
14200 Park Meadow Drive
Chantilly, VA 22021
• If you are creating a new domain and might or might not eventually con-
nect to an outside network, use the name name.UUCP, where name is the
name of your company or organization.
• If you will never attach to a network outside your company, choose
company.COM.
IP address
The IP address identifies and differentiates your machine from all others on
the network. It consists of a 32-bit binary number that is usually displayed as
four octets expressed in decimal and separated by periods. You must have a
unique IP address for each machine on your network. In addition, if your machine serves as a router to another network, it contains two or more network
cards and belongs to two or more networks. In this case, you must assign each
card a unique IP address on the appropriate network.
NOTE The IP address differs from an Ethernet address in that it is
configurable. An Ethernet address is a 6-byte address that is unique to each
physical Ethernet card. This non-configurable address is assigned by the
card manufacturer.
14
Configuring TCP/IP
The IP address consists of two parts: a network address that identifies the network and a host address that identifies the particular host, or node. Table 1-4
shows an IP address in binary form, as binary octets, as decimal octets, and as
it appears in standard notation.
Table 1-4 IP address derivation
binary (32-bit)
100 00 10 0 10 0 0 1 1 1 1000 0 0 0 100 000 00 10
binary (octets)
10 0 0 0 10 0
1000 1111
0 0 0 0 0 0 10
0 0 0 0 0 0 10
decimal octets
132
147
2
2
IP address (in standard notation)
=132.147.2.2
Several classes of TCP lIP networks are available, each based on the number of
hosts a network needs. Network classes supported by sea are Class A, B, and
C. Use the smallest network class that can accommodate all of your network's
hosts. Most TCP lIP installations use Class C, but some larger installations
might need to use Class B.
Table 1-5 lists valid network addresses for each class:
Table 1-5 Internet address classes
Class
Available Hosts
per Network
A
16777216
65534
254
B
C
Reserved
Valid Address
Ranges
1.0.0.1 through 126.255.255.254
128.0.0.1 through 191.255.255.254
192.0.0.1 through 222.255.255.254
. 224.0.0.0 through 255.255.255.254
If you are connecting your machine. to a pre-existing network, the network
address (for Class A, the first octet; for Class B, the first two octets; and for
Class C; the first three octets) is the same as those of other machines on the
network. In this case, you need only concern yourself with creating a unique
host address.
If you are creating an entirely new network and you want to connect to the
DARPA Internet, you need to contact the Network Information Center to have
a network address assigned. The full address is shown earlier in the section
"Domain name". If you do not want to connect to an outside network, you
15
Networking and TCPjlP overview
can choose any network address as long as it conforms to the syntax shown
previously. In either case, once you determine the network address, you can
then create the unique host address.
When you determine the IP address, keep in mind the following:
• Each logical network must have its own network address.
• All hosts in a network must have the same network address.
• All hosts in a network must have unique host addresses.
• Do not use the following network addresses: 0 or 127 (Class A), 191.255
(Class B), 223.255.255 (Class C), or any of the addresses shown in the
Reserved class of Table 1-5.
Broadcast address parameters
All datagrams sent by TCP lIP move through all machines in the network path.
However, each host adapter ignores any packet that does not include that particular computer's IP address in the datagram header. Occasionally, you might
want to send a message to all machines on a particular network. To do so,
select a broadcast address for your machine. A broadcast address is one in
which the host portion of the IP address consists either of all O's or all 255's.
The configuration procedure prompts you to choose between the following
address schemes:
Table 1-6 Broadcast address schemes
Scheme
Example
Purpose
all zeroes
(decimal 0)
all ones
(decimal 255)
132.147.0.0
provides compatibility with 4.2BSD
systems
UNIX Operating System Standard
(RFC-919)
132.147.255.255
The addresses shown in the previous table are for a class B network, and are
shown as examples only. Your values will be different. If you are on a network that does not contain any machines running 4.2BSD UNIX or earlier BSD
versions, choose all ones. If such machines exist on your network, choose all
zeroes.
netmask setting
The netmask strips the network ID from the IP address, leaving only the host
ID. Each netmask consists of binary ones (decimal 255) to mask the network
ID and binary zeroes (decimal 0) to retain the host ID of the IP address. For
example, the default netmask setting for a Class B address is 255.255.0.0.
16
Configuring TCP/IP
NOTE Always use the default netmask that the installation program
prompts you for unless you are creating a subnet, a logical division of a
physical network. If you create a subnet, also mask the portion of the
address that indicates the subnet. For example, the netmask for a machine
on a Class B subnet is 255.255.255.0. For more information on creating subnets, see the chapter UNetwork administration" later in this guide.
Gateway status
A machine that has interfaces (cards or serial lines) to more than one network
may operate as a gateway between networks, by forwarding and redirecting
packets from one network to another.
When you configure a second card under TCP lIP, you are prompted to turn
this gateway behavior on or leave your machine in the default, non-gateway
behavior. If you do not make your machine into a gateway, it will continue to
receive packets on each network at the specified IP addresses, but will not forward packets between networks.
TCPIIP over a SUP or PPP serial line
The following prompts are relevant only to serial line drivers.
tty line
This line indicates what tty the SLIP line connects to.
• If you are connecting to COM1:, interrupt vector 4, enter ttylA.
• If you are connecting to COM2:, interrupt vector 3, enter ttylA.
• If you are connecting to a smart serial card, use the appropriate tty naming
convention.
Source IP address
The IP address for this host (this end of the serial line). For more information
on determining IP addresses, see "IP address" earlier in this chapter.
Destination IP address
The IP address for the remote host (the opposite end of the line).
Baud rate
The baud rate at which data is transmitted. The default is 9600.
17
Networking and rep/IP overview
SUPnetmask
A netmask for this SLIP line. For more information on netmasks, see the section "netmask setting" earlier in this chapter.
Maintaining TCPIIP
After you install TCP lIP, you may never need to alter the TCP lIP configuration again. However, there are some common tasks that occur if you want to
customize or add to your network. These are described briefly here and in
detail later in this guide.
Adding hosts
The fete/hosts file is a list of hosts on the network. Network library routines
and server programs use this file to translate between host names and Internet
addresses when the BIND (Berkeley Internet Name Domain) name server is
not being used.
To add a machine to the network, you must add an entry to all of the fete/hosts
files on the local network. Refer to the hosts(SFF) manual page for a description of the file format.
Configuring the name domain server
The Berkeley Internet Name Domain Server (BIND) provides a distributed
lookup system for host names and addresses. Enabling BIND overrides the
default network information file, fete/hosts. For more information, see the
chapter "Configuring the BIND name server" later in this guide.
Setting up routing tables
Routing tables provide the information needed to route packets to their destinations properly. For descriptions of several possible approaches to maintaining routing information, see the chapter "Gateways" later in this guide. In
addition, the chapter "Network administration" contains a section on obtaining information about the system routing tables.
18
Maintaining TCP/IP
Establishing user equivalence
You can control who has access to a machine through the network by establishing user equivalence within the /etc/hosts.equiv and .rhosts files. The rlogin,
rep, and rcmd commands use these files to verify access privileges. For information on how to use these files, see the section "Network databases" in the
chapter "Network administration" later in this guide. You can also refer to the
hosts.equiv(SFF) manual page for a description of the file format. A note in the
"Helpful Hints" chapter also discusses user equivalence.
Setting up anonymous ftp
You can set up a public ftp account on your system that allows remote users
to transfer files anonymously from restricted, public directories on your system. For information on the /etc/ftpusers file, and a description of how to set
up the public ftp account, refer to the section "Network databases" in the
chapter "Network administration" later in this guide.
Altering installation parameters
You can change many of the settings that you set during TCP lIP installation
by altering the appropriate system files (such as /etc/hosts and device driver
files) with a text editor or with an appropriate utility, such as netconfig, route,
or mkdev. The use of such files and utilities, which are documented in the
chapter "Network administration," is always preferable to reinstalling the
software.
Tuning kernel parameters
You may need to tune kernel parameters by increasing or decreasing
STREAMS buffers and other parameters used by TCP lIP. Several utilities,
including netstat, configure, and netconfig, help you fine-tune your system to
enhance networking performance. These utilities are described in the chapter
"Network administration."
Monitoring TCPIIP status
You can use the netstat command to display Internet connections, current
Internet activity, routing tables, and error messages, among other useful information. In addition, you can use the Simple Network Management Protocol
(SNMP) commands and utilities to further monitor and troubleshoot your network. For more information, see the chapter "Configuring and using SNMP
later in this guide.
19
Networking and TCP/IP overoiew
Enabling remote printing
You can enable the remote printing daemon, Ipd, to allow print jobs to be sent
over the network to remote printers, or to make a printer attached to your
computer available to the network. For information on Ipd and its associated
files, see the chapter "Remote line printing" later in this guide.
20
Chapter 2
Logging in to a remote machine
When you log in to a remote machine over the network, your terminal on the
local machine acts as if it were attached to the remote machine. No physical
connection is made-software simulates a physical line between your terminal and the remote machine.
Two commands, rlogin(TC) and telnet(TC), allow you to log in to a remote
machine. rlogin is very convenient because, when your system is set up properly, you do not have to enter your user name and password to log in to a
remote machine; however, rlogin only works when you are logging in to a
machine that is running a UNIX operating system. telnet is not quite as easy
to use, but it does not require any setup files and allows you to connect to machines running a variety of operating systems.
You can usually log in to a remote machine successfully using telnet, but you
will probably find it most convenient to set up your system so that you can
use rlogin when working with another UNIX system.
Once you invoke telnet or rlogin, these commands pass to the remote machine all the data that you input, and they display all output from that machine on your screen. When logged in remotely, you can use any command at
the command line that you would use when logged in directly, including
screen-oriented programs like vi(C). (You cannot use icons or perform other
graphics-oriented tasks on the remote machine.)
21
Logging in to a remote machine
The rlogin command
To log in to another machine running a UNIX operating system, use the rlogin
command with the name of the remote machine:
rlogin warwick
If system equivalence exists between your local machine and the remote machine (see the section "Establishing user equivalence" in Chapter 7 of this
guide) and you have an account on the remote machine, you are automatically logged in with the same user name that you are working with on the local
machine. If system equivalence does not exist, you are prompted for a password on the remote machine.
If you want the convenience of automatic login, you can ask the system
administrator on the remote machine to establish system equivalence, or you
can set up your own user equivalence by creating a .rhosts file in your home
directory on the remote machine (see the section "Establishing user
equivalence" in Chapter 7 of this guide, or the rhosts(SFF) manual page).
If your system is configured to allow it, you can log in to another machine
simply by entering the name of the remote machine on the command line,
without the rlogin command. For this to work, your system administrator
must create a link in the /usr/hosts directory for each remote machine, and you
must have this directory in your search path.
When you are finished with your work, log out from the remote machine to
end the remote terminal session and return to the machine from which you
started. rlogin tells you that the remote connection has been closed. If, for
some reason, you cannot end a remote session normally, type the rlogin
escape sequence of a tilde followed by a period 11-." on a line by itself. This
action aborts the remote session and returns you to the local machine.
rlogin command-line options
Some options you can specify when invoking rlogin are:
-ec
changes the escape character from tilde to the character you specify
-1
(lowercase "L") specifies the user name under which you want to log in
on the remote machine
-8
allows an 8-bit input data path at all times
Any option must follow the name of the remote machine on the command
line. These options are described in more detail in the rlogin(TC) manual
page.
22
TCP/IP User's and Administrator's Guide
The telnet program
NOTE After you run rlogin with the -8 option, you still need to specify 8-bit
stty settings for the rlogind daemon on the remote machine. Therefore,
after you log into the remote machine, execute the following command:
stty -istrip
You can run this command from the command line or from a startup file on
the remote machine (.profile for accounts using the Bourne or Korn shell and
.login for accounts using the C shell).
Using a tilde in the text
When you are logged in to a remote machine, you cannot normally type a
tilde at the beginning of a line because the tilde is the default escape character.
If you need to type a line that begins with a tilde, you must type two tildes
U--"
If you change the escape character with the -e option, you must type the new
escape character twice when you want it to appear at the beginning of a line.
The telnet program
telnet allows you to log in to a remote machine as rlogin does, but it is not as
convenient to use because it is designed to work with any operating system,
not only with a UNIX system. When using telnet, you always have to enter a
user name and password.
To log in to another machine, use the telnet command with the name of the
remote machine:
telnet warwick
telnet prompts for a user name and password on the remote machine. When
you see the prompt from the remote machine, you can enter commands.
When you log out from the remote machine, you end the remote terminal session and return to the machine from which you started. You can interrupt a
remote session at any time by entering the telnet escape character (Ctrl)-J on a
line by itself.
tel net provides a command mode from which you can control telnet operations; you can set options that define how your machine communicates with
another machine when you are logged in remotely. From command mode,
you can also connect and disconnect from a remote machine with the open
and close commands.
23
Logging in to a remote machine
To enter telnet command mode, give the telnet command without a machine
name. The telnet command prompt looks like this:
telnet>
At this prompt, you can enter any telnet command (enter 1 or see the
telnet(TC) manual page for a list of commands with descriptions). At any
time, the status command shows whether or not you are connected. to a
remote machine, the current option settings (if you are connected. to another
machine), and the current escape character. The quit command ends the
remote session and exits from telnet. You can abbreviate a command as long
as you enter enough characters to distinguish it from other telnet commands.
You can also enter command mode by entering the telnet escape character,
(Ctrl)-], while already logged in to a remote machine. The escape character
temporarily interrupts the remote login session and places you in command
mode so you can execute tel net commands. With most telnet commands,
you automatically exit command mode when the command finishes. With
some (such as 1), you need to press (Return) when the command finishes.
telnet command-line options
Some options you can specify when invoking telnet are:
-ec
changes the escape character from Ctrl-] to the character you specify
-I
(lowercase "L") specifies the user name under which you want to log in
on the remote machine
-8
allows an 8-bit input data path at all times
Any option must follow the name of the remote machine on the command
line. These options are described in more detail in the telnet(TC) manual
page.
24
TCP/IP User's and Administrator's Guide
Chapter 3
Transferring files between machines
Two commands, rep (remote copy) and ftp (file-transfer program), allow you
to transfer files between machines on the network. rep is very convenient
because you do not have to enter your user name and password for the
remote machine, and it allows you to copy an entire directory; however, rep
can only transfer files with a machine that is running a UNIX operating system, and you must have user or system equivalence with the remote machine.
ftp is not quite as easy to use, but it allows you to transfer files with machines
running a variety of operating systems, and it does not require user
equivalence. If you often work with another UNIX system, you will probably
find it most convenient to set up your system so that you can use rep.
The rep command
To use the rep command, the machine with which you want to transfer files
must be running a UNIX operating system, and you must have user or system
equivalence with the remote machine (see the section "Establishing user
equivalence" in Chapter 7 of this guide).
The syntax of the rep command is much like that of the UNIX ep command,
where you give the nalTle of the file to be copied and the location to which it
should be copied. The rep syntax is different from the ep syntax in that you
can precede either the source path or the destination path with a machine
name to specify files on a remote machine. You must separate the machine
name from the filename with a colon. The square brackets in this rep syntax
description show that the machine name is optional for both the source and
destination files:
rep [ma~hine:1directory... / filename [machine:1directory ... / filename
25
Transferring files between machines
You can use rep to copy from a local file to a remote file, or vice versa. For
example, to copy the file proposal from the directory /u/proj3/design on the machine warwick to the current directory on your local machine, enter:
rep warwiek:lulproj3/designlproposal proposal
As another example, you can copy your weekly report from your own status
directory on the local machine to the group status directory on the machine
warwick with:
rep lulperrylstatus/engr.09.29 warwiek:lulstafflslatus
To copy a directory, you must use the -r option. For example, to copy the
/u/proj3 directory from warwick with all its subdirectories and files to a subdirectory named proj3 in your current directory on the local machine, enter:
rep -r warwiek:lu/proj3 proj3
With the -r option, the destination must be a directory.
Copying files of other users
You can use the rep command only to access files and directories to which you
would ordinarily have access according to UNIX file permissions. rep verifies
file access permissions with the user name under which you are logged in on
the local machine. If you have user equivalence with another user on the
remote machine, you can access that user's files by specifying the user name
in the rep command line. For example, if you have user equivalence with
rsimpson on warwick, you can copy a file from that user's directory with:
rep rsimpson@warwiek:personallletter letter.rsimpson
Because the remote path for the file letter is not an absolute path, rep assumes
the path is relative to the specified user's home directory.
Copying between remote machines
With the rep syntax, if you specify a machine name for both the source and
destination files, you can copy a file between two remote machines without
first moving the file to your local machine. From your local machine blue, you
can use the following command to copy the file notes from your home directory on warwick to your home directory on ivy.
rep warwiek:notes ivy:notes
You must have user equivalence with your accounts on both remote machines.
See the rep(TC) manual page for alternate syntax and other details about this
command.
26
TCPjIP User's and Administrator's Guide
The ftp command
The ftp command
ftp transfers files between machines as rep does, but is not as simple to use
because it is designed to work with any operating system, not only with a
UNIX system. ftp has certain limitations compared with rep, but it also provides certain features that are not available with rep. For example, ftp provides the ability to copy both ASCII and binary files with a different operating
system and allows certain file-transfer privileges for a user who does not have
an account on a machine.
Invoking ftp
ftp is an interactive program with its own set of commands for accessing network files. To invoke ftp, enter the ftp command without any arguments.
You see the ftp prompt:
ftp>
At the ftp prompt, you can give any ftp command. Enter? for a list of available commands (see the ftp(TC) manual page for descriptions). When your
ftp command finishes processing, ftp displays its prompt again. You remain
in ftp command mode until you exit ftp with the quit command.
I
NOTE When you log in under a certain account name with this version of
ftp, the ftpd daemon checks the file /etc/shells to make sure that the account
uses a valid shell. The shell for that account must appear in /etc/shells, or
ftpd does not allow the user to login under ftp.
By default, ftp operates in verbose mode, displaying many messages about
how it performs your file-transfer requests. If you prefer not to see these extra
messages, you can toggle verbose mode offby entering the verbose command
at the ftp prompt. (The ftp examples in this chapter were created with verbose mode turned off.)
Connecting to another machine with ftp
From the ftp prompt, you can connect to another machine with the open command followed by the name of the remote machine:
ftp>
open warwick
Name (warwick:perry):
Password:
rsimpson
ftp>
27
Transferring files between machines
Press (Return) to use the default name shown in parentheses or enter a
different user name. Then, enter the appropriate password. In this example,
you can access the files belonging to rsimpson because you knew that person's
password.
When you no longer need the remote connection, use the ftp close command
to disconnect from the other machine and return to the ftp command line.
End the ftp session with the quit command.
Instead of using the open command from within ftp, you can directly establish a connection to a specific machine by giving the name of the remote machine with the ftp command:
ftp warwick
You can log in to the remote machine and transfer files exactly as with the
open command.
Transferring files with ftp
After you have logged in to a remote machine, you can copy a file from that
machine to your machine with the get command. Give the pathname of the
file you want to transfer from the other machine, followed by the destination
on your local machine. With your connection to warwick already established,
the following example shows how to list the directory to locate the file you
want to transfer and how to copy the file bugs.form from the remote machine
to your current directory.
ftp> Is lusrllocalllib/bugreport
bugs. form
formprint
forms.help
forms.msgs
ftp> get lusrllocal/liblbugreportlbugs.form bugs.form.new
ftp>
Use the put command to copy a file from your machine to the remote machine. For example, after you have edited the bug report form, use ftp to copy
your new version to warwick:
ftp> put bugs.form.new lusrllocal/liblbugreport
ftp>
28
TCP/IP User's and Administrator's Guide
The ftp command
Transferring files with a non-UNIX system
Different types of operating systems use different file formats. When ftp
transfers files to or from a non-UNIX system, it transfers them in ASCII mode
by default and automatically translates from one system's format to another
as appropriate. Use this default ASCII mode when transferring ASCII text files
with a non-UNIX system. If you want to transfer binary files with a non-UNIX
system, use ftp's binary mode, which copies data literally (without any translation). Switch to binary mode with the binary command; switch back to
ASCII mode with the ascii command.
In general, if you transfer a file and get unexpected results, try again in the
other mode.
When transferring files between 386 UNIX systems, both modes work properly for both ASCII and binary files because no translation is needed. Binary
mode works faster.
Logging in automatically through the .netrc file
ftp does not understand user equivalence as defined in the /etc/hosts.equiv and
.rhosts files. Instead, ftp uses the .netrc file in your home directory on the local
machine for login and startup information when connecting to a remote machine.
In the .netrc file, you can put your user name and password for each machine
that you want ftp to log in to automatically. When you try to connect to a machine, ftp searches .netrc for an entry for that particular machine. If login information exists, ftp automatically supplies your user name and password (if
you entered your password in the file) to the remote machine. If you did not
enter your password in the file, ftp prompts you for it.
Because the password is given in the .netrc file in normal, unencrypted text, if
you include your password, ftp requires that you set the permissions on the
file so that other people do not have access to it (permissions of 400 or 600). If
the file contains your password and is not protected properly, ftp aborts the
login process. See chmod(C) for more information on file permissions.
You can also define macros in the .netrc file. See netrc(SFF) for details about
this file.
29
Transferring files between machines
Using anonymous ftp
If the system administrator on the remote machine has set up a public ftp
account, you can transfer files within certain protected directories of the ftp
home directory without an account on a remote machine. To use this feature,
log in with the user name anonymous. This account has no password, but it is
customary to enter your user name at the password prompt.
ftp>
open grover
Name (warwick:perry): anonymous
Password:
ftp>
A public account has restricted file access, but can be very useful for exchanging public software or other information.
An error message saying that the anonymous user is unknown usually means
that the system administrator of the remote machine is not allowing public
access.
ftp command options
Several command options affect how ftp operates:
-v
specifies verbose mode (the default)
-d
specifies debug mode
-i
turns off prompting for multiple-file transfers (see the ftp prompt command)
-n
prevents automatic login when connecting to a remote machine (use the
ftp user command to log in manually)
-g
turns off expansion of UNIX filename wild cards (see the ftp glob command)
For more information on these options, see the ftp(TC) manual page.
30
TCP/IP User's and Administrator's Guide
Chapter 4
Running commands remotely with rcmd
Here are some reasons to
run commands on another machine:
• take advantage of some idle CPU time on the other machine
• share printers, hard disks, or other remote devices
• run software that resides on another machine
• find out information about the other machine
The rcmd(TC) command lets you send commands to a remote machine for
execution and receive the results locally. You do not have to log in to the
remote machine to use these commands. rcmd passes its standard input to
the remotely executed command, and returns standard output and standard
error from the remote command to your local system.
You cannot remotely run programs that depend on accessing the terminal
directly, such as vi(C), because rcmd reads from the terminal line by line,
whereas programs like vi use the terminal in raw mode, reading from the terminal character by character. To run a screen-oriented program on another
machine, you must use rlogin or telnet to log in to that machine remotely.
Invoking rcmd
To use rcmd, the remote machine on which you want to run commands must
be running a UNIX operating system, and you must have user or system
equivalence with that machine (see the section "Establishing user
equivalence" in Chapter 7 of this guide). Before executing the remote command, rcmd reads your shell startup file (.cshrc for C-shell users or .profile for
Bourne shell users) in your home directory on the other machine if the file
exists, so it can use any aliases you have defined on the other machine when
executing the command.
31
Running commands remotely with rcmd
For example, you can use rcmd to send files over the network to a printer connected to another UNIX system. The following example sends the file notes in
the current directory on the local machine to the default printer on warwick:
cat notes I rcmd warwick Ip
Using shell metacharacters
Shell metacharacters provide redirection II <" or ">", piping" I", process
control" &", and so on. You can use these special characters as part of the
command to be executed remotely as well as within the local rcmd command
syntax. When you want rcmd to pass the special character to the remote machine with the remote command, you must escape the special character's
meaning to the local machine with a double or single quotation mark (""" or
", ") or with a backslash "\ ". Any special character that is not escaped is
interpreted on the local machine.
As an example, suppose you want to get a list of the number of blocks in all
files and directories on the remote machine warwick, and you want to save the
output in the file /tmp/warwick.du on the remote machine. You could use the
following command:
rcmd warwick du \> Itmp/warwick.du
If you leave out the backslash before the redirection symbol, the file
/tmp/warwick.du is created on the local machine.
Refer to the csh(C) or sh(C) manual page for complete information about
escaping metacharacters on the command line.
rcmd command-line options
You can specify two options when invoking rcmd:
-1 user
(lowercase "L") specifies the user name under which you want to
execute the command. You must have user equivalence with that
user.
-n
makes the command's standard input /dev/null instead of rcmd's
standard input. This option also prevents rcmd from reading and
buffering standard input data.
Any option must follow the name of the remote machine on the command
line. These options are described in more detail in the rcmd(TC) manual page.
32
TCP/IP User's and Administrator's Guide
Chnpter 5
Sending mail across the network
If your system has a mail database for all users within your local network, you
can send mail to another user at your site simply by specifying the person's
user name with the mail command as described in your operating system
documentation. If your system's mail database does not let you send mail to
another person at your site with only the person's user name, you must follow
the user name with an at-sign and the name of the person's machine:
mail userOmachine
Suppose you want to send mail to someone further away, perhaps to a former
professor at the university you attended. To send mail across the wide-area
network, you must give the mail program some additional information: a
host name and the name of the domain in which the host exists.
A "host" is a machine connected to the network at which the person can
receive mail from other machines on the network. A "domain" is a set of machines usually grouped by geographic location, organization, or type of
activity (for example, EDU for educational machines, COM for machines in
commercial use, UK for machines in England). Ask the person to whom you
are trying to send mail for the host, domain, and user name you should use.
For example, if you want to send mail to Professor Shastraboul at the University of California at Berkeley, you would be told that the host name is ucbvax
and the domain name is Berkeley.EDU. If the professor's user name is shastra,
you can send your mail with a command like this:
mail shastra@ucbvax.Berkeley.EDU
Depending on the network connections between your site and the site to
which you want to send, and depending on how the mail systems are set up
at the two sites, you might not be able to use this syntax to send mail to certain remote sites. For more information, see the the mail chapter in your UNIX
System V User's Guide.
33
Sending mail across the network
For a description of options available with the mail command, see the mail (C)
manual page.
34
TCP/IP Users and Administrator's Guide
Chnpter 6
Other useful commands
You can find out certain information about other machines on the network
with these commands:
finger
provides information about the specified user
hostname displays the network name of the current machine
netstat
displays the status of the network
nslookup queries DARPA Internet domain name servers
ruptime
gives the status of machines on the local network
rwho
shows who is logged in to the local network
See the networking manual pages for more information on each of these commands.
35
Other useful commands
36
TCP/IP User's and Administrator's Guide
Chapter 7
Network administration
This chapter covers topics related to setting up and administering your
TCP lIP network. When you installed and configured your system, many of
these tasks were performed automatically by the netconfig(ADM) command
to configure a basic networked system. For more information on netconfig,
see the netconfig(ADM) manual page. If you want to customize your installation or troubleshoot your network, you should read this chapter.
Topics covered include modifying tunable kernel parameters, establishing
user equivalence, setting up anonymous ftp, and administering pseudo ttys.
In addition, if your network is not performing well, the section "Network tuning and troubleshooting" at the end of this chapter provides helpful suggestions.
1CernelconfiguraHon
Table 7-1 lists the tunable kernel parameters for this release of TCP/IP. These
parameters are configured by default to work efficiently in most situations.
However, if your system has an unusual configuration, you may need to tune
these parameters. Please read the descriptions that follow Table 7-1 before
you change any tunable kernel parameters. The following steps explain how
to change the parameters:
1. Determine the name of the file to edit by looking in the second column of
Table 7-1. The complete filename will be /ete/conf/pack.d/ plus the value
from the table. For example, to change the value of nb_sendkeepalives,
edit the file /ete/conf/pack.d/nb/spaee.e. Note that the directories in paek.d
only exist if they have been configured. For example, ppp will only appear
if PPP has been configured using netconfig.
37
Network administration
2. Make a backup copy of the file in case you need to restore the original
values later.
3. Using a text editor, such as vi, locate the line containing the variable and
change the supplied value. Where the current value is a constant that is
defined in a header file, do not edit the header file. Instead, replace the
constant with the new value. Where the parameter is boolean (that is,
either 0 or 1), change the current value to the opposite boolean value (for
example, change 0 to 1).
4. Relink
the
kernel
using
the
sysadmsh
System ¢ Configure ¢ Kernel ¢ Rebuild selection. Follow the prompts; respond y both
when asked if you want to have the new kernel boot by default and when
asked if you want to rebuild the kernel environment.
5. Boot the new kernel using the sysadmsh System ¢ Terminate selection to
shut the system down. Press (Return) when the reboot message is displayed.
NOTE Randomly changing these parameters can seriously harm your system. Make absolutely sure that you understand the implications of any
changes you make.
I
Table 7·1 Tunable kernel parameters
38
Parameter
File
Description
ahd1cmtu
icmp_answermask
ipforwarding
ipprovcnt
ipsendredirects
NB_NNAMETAB
NB_NREQ
NB_NSESSION
nb_sendkeepalives
pppmtu
slmtu
subnetsarelocal
tcpprintfs
tcp_recvspace
tcp_round_mss
tcp_ttl
udp_ttl
asyhl space.c
ip/space.c
ip/space.c
ip/space.c
ip/space.c
nb/space.c
nb/space.c
nb/space.c
nb/space.c
ppp I space.c
slip I space.c
ip/space.c
tcp I space.c
tcp I space.c
tcp I space.c
tcp I space.c
udp/space.c
asyhMTU
answer subnet mask requests
forwarddatagrams
# of IP interfaces
send ICMP redirects
# of NetBIOS names
# of NetBIOS Control Blocks NCBs
# of NetBIOS sessions
NetBIOS level keepalives on/off
PPPMTU
SLIPMTU
treat subnets as local
TCP checksum errors notice
TCP default receive window size
round MSS down to multiple of 1024
TCP default TTL
TCP default TTL
Default
296
0
0
16
0
64
64
64
0
296
296
1
1
4096
1
60
30
TCP/IP User's and Administrator's Guide
J(ernelconfi~ration
The following list describes how the variables affect TCP lIP and the cases in
which each variable needs to be changed.
ahdlcmtu, pppmtu, slmtu
Change these variables if a machine at the other end of a serial link has a
larger Maximum Transmission Unit (MTU) size which cannot be
changed. The MTU is the largest amount of data that can be transferred
across a given physical network. For LANs, the MTU is determined by
the network hardware. For WANs, the MTU is determined by the software.
pppmtu controls the Internet Engineering Task Force Point to Point Protocol. slmtu controls the SLIP (Serial Line IP) protocol.
icmp_answermask
Set to 1 (true) to cause the system to respond to ICMP subnet mask
requests. This variable is needed to support diskless workstations.
ipforwarding, ipsendredirects
Set these to 1 if this machine is to be used as a gateway. ipforwarding
controls whether the system will forward packets sent to it which are
destined for another system. When a packet is forwarded to another
system which could have been reached directly by the originating system, an ICMP redirect message will be sent to the originating system if
ipsendredirects is set to 1 (true).
The netconfig(ADM) utility also configures these values when drivers
(after the first one) are added. netconfig edits mtune in the /etc/conl/cl.d
directory. This netconfig feature usually makes it unnecessary to
change ipforwarding and ipsendredirects in the ip/space.c file.
ipprovcnt
Set to the number of IP interfaces you have, if you have more than network adapter cards used by IP.
NB_NSESSION, NB_NNAMET AB, NB_NREQ
These variables are respectively, the number of NetBIOS sessions, NetBIOS names and NetBIOS Control Blocks (NCBs) corresponding to the
LAN Manager Ix parameters MAXSESSIONS, NNCB_NAMES and NNCB.
If you increase anyone of those LAN Manager Ix parameters above the
TCP lIP default, you must change the corresponding TCP lIP parameter
accordingly. For example, if you want to increase the LAN Manager IX
parameter MAXSESSIONS to 128, you must also change NB_NSESSION
in nb/space.c to 128 and relink the kernel. Note that if you change the
defaults for NB_NSESSION in or NB_NREQ in nb/space.c, you should
also change NB_DFLTSSN andNB_DFLNCB in letc/default/nbconf to
correspond with the new TCP lIP NetBIOS driver values.
39
Network administration
nb_sendkeepalives
Set to 1 to turn on NetBIOS level keepalives. When turned on, NetBIOS
keepalives are sent periodically on dormant NetBIOS connections. NetBIOS keepalives are independent of TCP lIP keepalives, and are useful
for systems that do not use TCP lIP keepalives. This parameter is turned
offby default.
subnetsarelocal
Set to 1 to request the network adapter maximum packet size on TCP lIP
connections to local subnets. This is useful if the local network is made
up of links which have maximum packet sizes greater than or equal to
the local adapter. "ICMP Host Unreachable" is generated for local subnet routing failures. When this value is set to 0, the packet size is set to
576 bytes, as specified by RFC 1122.
tcpprintfs
If this parameter is set to 1, TCP/IP warning messages are printed to the
console. If the parameter is set to 0, the messages are not printed anywhere.
tcp_recvspace
This parameter affects the size of the TCP receive window. If you need a
faster TCP data-receive rate, increase tcp_recvspace. For example,
increase this parameter if your machine receives a lot of data from
remote sites.
The parameter is set to TCPWINDOW. Change TCPWINDOW's value by
changing the following line in /etc/conf/pack.d/tcp/space.c:
#define TCPWINDOW 4*1024
We recommend that you initially change the value to 24*1024. You cannot increase the value beyond 64*1024.
Increasing the receive window size can sometimes result in exhausting
other resources. After you increase the TCPWINDOW value, monitor
your STREAMS buffers, network card statistics, and protocol-specific
statistics. See "Network tuning and troubleshooting" (at the end of this
chapter) and the netstat(TC) manual page for information on monitoring
these resources.
tcp_round_mss
If this parameter is set to 1, the TCP/IP Maximum Session Size is
rounded down to the nearest multiple of 1024. Setting this parameter to
o prevents the round-down, letting you more effectively use the data
portion of a TCP segment. This potentially decreases the number of segments you need for transferring a given amount of data.
tcp_ttl, udp_ttl
Increase these parameters if you have an Internet connection with many
hops.
40
TCP/IP Users and Administrator's Guide
Creating a subnetwork
Setting interface parameters
All network interface drivers, including the loopback interface, require that
their host addresses be defined at boot time. This is done with
ifconfig(ADMN) commands included in the /etc/tcp shell script. These commands are initially set up based on information you supply during configuration with netconfig(ADM).
ifconfig(ADMN) also sets the netmask, broadcast address, and IP address at
boot time. If you want to change any of this information, you can edit /etc/tcp
(after making a backup copy of the file), then reboot your system. Instances in
which you may want to do so include:
• changing the netmask and broadcast address to make provisions for a subnetwork
• changing the broadcast address scheme from all ones to all zeroes, or vice
versa
• changing the IP address of the interface
Creating a subnetwork
In TCP lIP, the DARPA Internet support includes the concept of the subnetwork. This is a mechanism that enables several local networks to appear as a
single Internet network to off-site hosts. Subnetworks are useful because they
allow a site to hide the local topology, requiring only a single route in external
gateways. This also means that local network numbers may be locally administered.
To set up local subnetworks, you first need to know how much of the available address space is to be partitioned. The term Iladdress" is used here to
mean the Internet host part of the 32-bit address. Sites with a class A network
number have a 24-bit address space with which to work, sites with a class B
network number have a 16-bit address space; and sites with a class C network
number have an 8-bit address space. To define local subnets you must steal
some bits from the local host address space for use in extending the network
portion of the Internet address.
This reinterpretation of Internet addresses is done only for local networks. It is
not visible to off-site hosts. For example, if your site has a class B network
number, hosts on this network have an Internet address that contains the network number, 16 bits, and the host number, another 16 bits. To define 254
local subnets, each possessing at most 255 hosts, 8 bits may be taken from the
local part to be used for the subnetwork 10. (The use of subnets 0 and all-l's,
255 in this example, is discouraged to avoid confusion about broadcast
41
Network administration
addresses.) New network numbers are then constructed by concatenating the
original 16-bit network number with the extra 8 bits containing the local subnetwork number.
Network servers
In the UNIX system, most of the server programs are started by a super server,
called the "Internet daemon". The Internet daemon, /etc/inetd, acts as a master
server for programs specified in its configuration file, /etc/inetd.conf, listening
for service requests for these servers, and starting up the appropriate program
whenever a request is received. The configuration file includes lines containing:
• a service name (as found in /etc/services),
• the type of socket the server expects (for example, stream or dgram),
• the protocol used with the socket (as found in /etc/protocols),
• whether to wait for each server to complete before starting up another,
• the user name under which the server should run,
• the server program's name, and
• up to five arguments to pass to the server program
Some trivial services are implemented internally in inetd(SFF), and their
servers are listed as internal. For example, an entry for the file-transfer protocol server would appear as:
ftp
stream
tcp
nowait
root
/etc/ftpd
ftpd
Consult inetd(SFF) for more details on the format of the configuration file and
the operation of the Internet daemon.
42
TCP/IP Users and Administrator's Guide
Network databases
Network databases
Several data files are used by the network library routines and server programs. Most of these files are host independent and updated only rarely.
Table 7-2 lists the data files used:
Table 7·2 Network database files
File
Manual reference
/etc/hosts
/etc/networks
/etc/services
/etc/protocols
/etc/hosts.equiv
/etc/ftpusers
/etc/inetd.conf
hosts (SFF)
networks (SFF)
services (SFF)
protocols (SFF)
rshd(ADMN)
ftpd(ADMN)
inetd (ADMN)
Use
host names
network names
list of known services
protocol names
list of "trusted" hosts
list of "unwelcome" ftp users
list of servers started by inetd
The files distributed are set up for ARPANET or other Internet hosts. Local
networks and hosts should be added to describe the local configuration. Network numbers must be chosen for each Ethernet. For sites not connected to
the Internet, these can be chosen more or less arbitrarily; otherwise, the normal channels should be used for allocation of network numbers.
Establishing user equivalence
User equivalence allows a user on one machine to use rlogin to log into an
equivalent account on another machine without entering a password. You
need to modify several files to establish user equivalence: /etc/hosts.equiv,
.rhosts, and /etc/passwd.
To do so, ensure that entries for the affected user exist on both machines in the
following files:
• .rhosts and /etc/passwd, or
• /etc/hosts.equiv and /etc/passwd
In both cases, /etc/passwd must contain an entry for the user name from the
remote machine. If you add an entry to .rhosts for a particular account, then
user equivalence is established for that account only. If you add an entry in
/etc/hosts.equiv for a host name and an account on that host, then that account
has user equivalence for any account (except root). If the entry in
/etc/hosts.equiv has only the remote host name, then any user on that host has
user equivalence for all local accounts (except root). Such a host is considered
a "trusted host."
43
Network administration
NOTE Entries in /etc/hosts.equiv can create large holes in system security. Be
sparing in their use. In most circumstances, it is unwise to create entries
that allow all users on remote machines to access all accounts on your local
machine.
For example, suppose you have an account under the user name testl on machine admin. You want to establish user equivalence on the remote machine
systemb. The administrator for the machine systemb must create an account for
user name testl. They must also include the following entry in the file
/etc/hosts.equiv on systemb:
admin
testl
This gives user equivalence for all accounts except root to user testl on the machine systemb. Suppose that testl really only needed access to the account
testb on systemb. Then it would be better to remove the above entry from
/etc/hosts.equiv on systemb and use the following entry in the file .rhosts in the
home directory for testb:
admin
testl
Note that entries for .rhosts must include both the system name and the
account name. The file /etc/hosts.equiv does allow entries for the system name
only, as discussed earlier.
If there are entries in both .rhosts and /etc/hosts.equiv for the same machine or
machine/account combination, then the entry from /etc/hosts.equiv determines
the extent of user equivalence.
Setting up anonymous ftp
The ftp server included in the system provides support for an anonymous ftp
account. Because of the inherent security problems with such a facility, you
should read this section carefully if you want to provide such a service.
44
TCP/IP Users and Administrator's Guide
Network databases
An anonymous account is enabled by creating a user called ftp. When a client
uses the anonymous account, a chroot(ADM) system call is performed by the
server to restrict the client from moving outside that part of the filesystem
where the ftp home directory is located. Because a chroot call is used, certain
programs and files used by the server process must be placed in the ftp home
directory. Further, you must be sure that all directories and executable images
are unwritable. The following directory setup is recommended:
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
csh
cd ~ftp
chmod 555 .i chown ftp .i chgrp ftp .
mkdir bin etc pub sh1ib dey
chown root bin etc sh1ib dey
chmod 555 bin etc sh1ib dey
chown ftp pub
chmod 777 pub
cd bin
cp /bin/sh /bin/1s /bin/pwd .
chmod 111 sh ls pwd
cd .. /etc
cp /etc/passwd /etc/group
chmod 444 passwd group
cd .. /shlib
cp /shlib/1ibc_s .
cd ..
find /dev/socksys -print I cpio -dumpy .
When local users want to place files in the anonymous area, they must place
them in a subdirectory. In the setup here, the directory -ftp/pub is used.
Another issue to consider is the /etc/passwd file placed here. It can be copied
by users who use the anonymous account. They can then try to break the
passwords of users on your machine for further access. A good choice of
users to include in this copy might be root, daemon, uucp, and the ftpuser.
Aside from the problems of directory modes and such, the ftp server provides
a loophole for interlopers if certain user accounts are allowed. The file
/etc/ftpusers is checked on each connection. If the requested user name is
located in the file, the request for service is denied. It is suggested that this file
contain at least the following names:
uucp
root
Accounts with nonstandard shells should be listed in this file. Accounts
without passwords need not be listed in this file; the ftp server does not service these users.
45
Network administration
Administering pseudo ttys
When you install TCP lIP, the netconfig command allows you to modify the
number of pseudo ttys configured on your system. These pseudo ttys allow
outside machines to use telnet or rlogin to access TCP lIP on your machine. If
you want to remove these pseudo ttys, or add more to your system, after installing and configuring TCP lIP, use the sysadmsh(ADM) command:
1. Log in to the system as root and bring the system into system maintenance
mode.
2. Enter the following command at your prompt and press (Return):
sysadmsh
3. Select the following: System
¢
Hardware
4. Select Pseudo ttys from the point-and-pick list.
5. Enter 1 to add pseudo ttys, or 2 to remove pseudo ttys. If you are adding
pseudo ttys, continue with the next step. If you are removing pseudo ttys,
skip to step 7.
6. Enter a number of pseudo ttys to create and press (Return). If the number
is greater than the current system limit, you are asked if you want to
increase the limit. Enter y to increase the limit or n to cancel the increase.
Skip to step 8.
7. You return to the main menu. Enter q to quit.
8. Enter a number of pseudo ttys to remove and press (Return).
9. You are prompted to relink the kernel. Do so by entering y at the prompt.
I
NOTE If you do not relink the kernel now, the changes you made do not
take place, and you return to sysadmsh. You must then relink at a later
time to effect the changes.
10. The following message appears:
The UNIX Operating System will now be rebuilt.
This will take a few minutes. Please wait.
Root for this system build is I.
Do you want this kernel to boot by default? (yin)
Answery.
46
TCPIIP Users and Administrator's Guide
Network tuning and troubleshooting
11. The following prompt appears:
Do
you want the kernel environment rebuilt? (yIn)
Answer y. A message appears confirming that the kernel is linked and
installed.
12. Exit sysadmsh and reboot your system by entering the following command:
init6
Network tuning and troubleshooting
It is likely that from time to time you will encounter problems using your network. The first thing to do is check your network connections. On networks
such as the Ethernet a loose cable tap or poorly placed power cable can result
in severely deteriorated service. The ping(ADMN) command is particularly
useful for confirming the existence of network connections. If there is no hardware problem, check next for routing problems and addressing problems.
The netstat(TC) program can also be helpful in tracking down hardware
malfunctions. In particular, look at the -i and -s options in the manual page.
The netstat(TC) program also shows detailed information about network
behavior. Examples of netstat displays appear later in this chapter.
If you think a communication protocol problem exists, consult the protocol
specifications and attempt to isolate the problem in a packet trace. The
SO_DEBUG option can be supplied before establishing a connection on a
socket, in which case the system traces all traffic and internal actions (such as
timers expiring) in a circular trace buffer. This buffer can then be printed out
with the trpt(ADMN) program. Most of the servers distributed with the system accept a -d option forcing all sockets to be created with debugging turned
on. Consult the appropriate manual pages for more information.
STREAMS tuning
If your system does not have enough STREAMS buffers it will lose connections
for no reason, hang on processes that communicate over the network, cause
programs that communicate over the network to malfunction, and hang on
any process that deals with terminalI/O.
47
Network administration
Run netstat -m at the prompt to display the current STREAMS buffer use. The
FAIL column should have a 0 in every row. If failures are listed in this
column, increase the corresponding STREAMS buffers. For example, if you
have 40 failures in the NBLKS12 row, increase the kernel parameter NBLKS12.
Start by increasing the number of buffers by 50%. If you still have failures,
increase NBLKS12 again by 50% of the original value until there are no
failures.
To increase STREAMS buffers, use sysadmsh and select the following:
System ¢ Configure ¢ Kernel ¢ Parameters
Choose the Streams Data option. You are prompted to enter a value for all
STREAMS parameters. Press (Return) for values that you do not want to
change. Enter the new value for the STREAMS buffer that you want to
increase. You can also use the UNIX Link Kit configure(ADM) command to
increase STREAMS buffer resources.
48
TCPjIP Users and Administrator's Guide
Network tuning and troubleshooting
Active connections display
The active connections display is the default display of the netstat(TC) command. It displays a line of information for each active connection on the local
machine under the following heading.
netstat -a
Active Internet connections (including servers) are as follows:
scobox$ nets tat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address
(state)
Foreign Address
ip
*.*
*.*
0
0
tcp
scobox.telnet
scoter.2460
0
0
ESTABLISHED
tcp
0
0
*.srntp
*.*
LISTEN
tcp
* *
0
*.1024
LISTEN
0
tcp
*.sunrpc
*.*
0
0
LISTEN
* *
tcp
0
0
*.chargen
LISTEN
* *
tcp
0
*.daytirne
0
LISTEN
tcp
0
*.time
*.*
0
LISTEN
tcp
*.dornain
*.*
0
0
LISTEN
tcp
0
*.finger
*.*
0
LISTEN
tcp
*.*
0
0
*.exec
LISTEN
tcp
*.ftp
*.*
0
0
LISTEN
tcp
0
*.telnet
*.*
LISTEN
0
tcp
* *
0
*.login
0
LISTEN
tcp
*.*
0
0
* . shell
LISTEN
tcp
0
0
scobox.listen
*.*
LISTEN
tcp
0
0
scobox.nterrn
*.*
LISTEN
tcp
*.*
*.*
0
0
CLOSED
udp
0
*.1035
*.*
0
udp
0
*.1034
*.*
0
* *
*.1033
udp
0
0
udp
*.*
0
0
*.1032
udp
0
*.2049
*.*
0
udp
*.*
0
0
*.1028
*.*
udp
0
0
*.sunrpc
* *
udp
0
scobox.dornain
0
udp
*.*
0
0
localhost.dornain
scobox$
49
Network administration
Descriptions of the display headings
Proto
protocol used in the connection
Recv-Q
receive queue. This is the number of received characters
(bytes) of data waiting to be processed.
Send-Q
send queue. This is the number of characters (bytes) of
data waiting to be transmitted.
Local Address
port number of the local connection, displayed symbolically. The port numbers are taken from the /etc/services file.
Foreign Address port number of the remote connection, displayed symbolically. The port numbers are taken from the /etc/services file.
State
current state of the connection. Each protocol has its own
set of states. For the protocol-dependent states that can be
displayed, see the appropriate protocol specification.
Interfaces
The interface display describes activities on all the local machine's interfaces
to the net, in the form of a table of cumulative statistics. This display is available through netstat with the -i option.
netstat -i
scobox$ netstat -i
Name Mtu Network
Address Ipkts
Ierrs Opkts Oerrs
enO 1500 sco-eng-ne scobox
No Statistics Available
e3BO 1500 128.174.14 128.174.14.10
0
0
0
100 2048 loopback
10calhost189
0
189
0
scobox$
Collis
0
0
Descriptions of the display headings
Each interface is described by a line with the following headings:
Name
name of the network interface. For example, enO is the name
of the first Ethernet interface board.
Mtu
maximum transmission unit (in bytes). This is the largest
size permitted for any single packet sent through this interface.
Network
name of the network address of the interface as given in
/etc/networks
50
TCP/IP Users and Administrator's Guide
Network tuning and troubleshooting
Address
name of the machine address of the interface in jete/hosts
Ipkts
input packets. This is the number of packets received on the
interface.
lerrs
input errors. This is the number of errors detected in packets
of data received on this interface.
Opkts
output packets. This is the number of packets transmitted
on the interface.
Oerrs
output errors. This is the number of errors detected and
corrected in packets of data transmitted on this interface.
Collis
collisions that occurred on the network
Routing tables
The Routing Table display provides information about the usage of each route
you have configured. A route consists of a destination host or network and a
network interface used to exchange packets. Direct routes are created for
each interface attached to the local host.
netstat -r
scobox$ netstat
Routing tables
Destination
localhost
sco-eng-net
128.174.14
128.174
scobox$
-r
Gateway
localhost
scobox
128.174.14.1
scoffle
Flags
UH
U
U
UG
Refcnt Use
4
0
4
537
0
0
0
0
Interface
100
enD
e3BO
enD
51
Network administration
Descriptions of the display headings
The information displayed for each route is as follows.
Destination
network or machine to which this route allows you to connect
Gateway
name of the gateway you configured for this route. If you
are directly connected, this is a local address. Otherwise, it is
the name of the machine through which packets must be
routed.
Flags
state of the route. Valid states are:
U
up
G
a route to a gateway
N
a route to a network
H
a route to a host
Refcnt
current number of active connections using the route.
Connection-oriented protocols normally hold on to a single
route for the duration of the connection, while connectionless protocols obtain a route, then discard it as needed.
Use
current number of packets sent using this route
Interface
name of the physical network interface used to begin the
route
Statistics display
The Protocol Statistics display provides protocol-specific errors. The errors in
the display are grouped under headings for each higher-level protocol in your
system. The headings are protocol-specific.
• Internet Protocol (ip)
• Internet Control Message Protocol (icmp)
• Transmission Control Protocol (tcp)
• User Datagram Protocol (udp)
52
TCP/IP Users and Administrator's Guide
Network tuning and troubleshooting
netstat -s
ip:
3209 total packets received
o bad header checksums
o with size smaller than minimum
o with data size < data length
o with header length < data size
o with data length < header length
o fragments received
o fragments dropped (dup or out of space)
o fragments dropped after timeout
o packets forwarded
o packets not forwardable
o redirects sent
icmp:
1 call to icmp_error
o errors not generated because old message was icmp
Output histogram:
destination unreachable: 1
o messages with bad code fields
o messages < minimum length
o bad checksums
o messages with bad length
Input histogram:
destination unreachable: 640
o message responses generated
tcp:
348 packets sent
202 data packets (3661 bytes)
o data packets (0 bytes) retransmitted
101 ack-only packets (60 delayed)
o URG only packets
o window probe packets
o window update packets
45 control packets
(Continued on next page.)
53
Network administration
(Continued)
411 packets received
233 acks (for 3654 bytes)
19 duplicate acks
o acks for unsent data
200 packets (1677 bytes) received in-sequence
o completely duplicate packets (0 bytes)
o packets with some dup. data (0 bytes duped)
9 out-of-order packets (0 bytes)
o packets (0 bytes) of data after window
o window probes
o window update packets
o packets received after close
o discarded for bad checksums
o discarded for bad header offset fields
o discarded because packet too short
25 connection requests
12 connection accepts
21 connections established (including accepts)
72 connections closed (including 0 drops)
16 embryonic connections dropped
233 segments updated rtt (of 259 attempts)
o retransmit timeouts
o connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
o keepalive probes sent
o connections dropped by keepalive
0 connections lingered
Olinger timers expired
0 linger timers cancelled
0 linger timers aborted by signal
udp:
o incomplete
headers
o bad data length fields
o bad
54
checksums
TCP/IP Users and Administrator's Guide
Chtzpter 8
Administering serial line
communications
This chapter describes two Internet Protocol (Ip) networking products that
operate over serial lines: SLIP (Serial Line Internet Protocol) and PPP (Pointto-Point Protocol). SLIP and PPP let two computers transfer information,
using the serial port in place of a network card and a standard serial cable in
place of an Ethernet cable. Both SLIP and PPP are commonly used on dedicated serial links. They are useful for allowing mixes of hosts and gateways
to communicate with one another (host-host, host-gateway, and gatewaygateway are all common SLIP and PPP network configurations). You can
operate SLIP and PPP at any speed from 1200 baud to 19.2K baud, as long as
your serial port supports the speed.
The first section of this chapter covers SLIP, and the second covers PPP. Each
section describes the protocol's features, explains the configuration procedure, and offers troubleshooting suggestions.
Administering SLIP
SLIP functionality is limited to defining a sequence of characters that frame IP
packets (or datagrams) on a serial line. SLIP provides no addressing, packet
type identification, or error detection or correction, and allows only asynchronous transmission. SLIP does offer a compression mechanism for packet
headers. PPP, described later in this chapter, provides some enhancements to
SLIP's capabilities.
The TCP lIP Runtime system includes SLIP in the basic TCP lIP installation
package, so you install it automatically when you install TCP lIP.
55
Administering serial line communications
Configuring a SUP connection
This section begins with information that you need before you begin configuring SLIP. The section then describes step-by-step procedures for configuring
three types of SLIP lines: a direct SLIP connection, a dialup SLIP connection,
and a SLIP/Ethernet or SLIP /Token-Ring gateway.
Preparing to configure a SUP connection
seQ TCP lIP supports up to four SLIP lines per machine. Each SLIP line
requires a unique network address and hostname, making it a separate subnet. For example, a hostname for the first SLIP line on a machine called opal
might be opaCslipl, the second opaCslip2, and so forth. For more information
on network addresses, see the section on IP addresses in the introduction to
this guide.
Chapter 1 of this guide contains the information that you need to configure a
SLIP connection. If you read this material before you configure the SLIP
driver, the configuration process flows more smoothly than if you attempt to
answer prompts during configuration.
Information you need to know includes:
• name of the tty line you plan to use
• baud rate at which you are operating SLIP
• IP address (or Internet address) of your system
• IP address of the target system to which you are connecting the SLIP line
• hostname of the target system to which you are connecting the SLIP line
Configuring a direct SUP connection
This section describes how to use netconfig(ADMN) to configure a direct SLIP
connection between a machine named emerald and a machine named ruby.
The following procedure assumes that the machines are connected through
their COMl serial ports using a null modem cable, and both machines have
TCP/IP installed. After you enter each selected value, press (Return) to complete your response:
1. Boot the machine emerald in System Maintenance mode by entering the
root password at the following prompt:
Type CONTROL-D to proceed with normal startup (or enter root
passwd for System Maintenance Mode):
56
TCP/IP Users and Administrator's Guide
Administering SUP
2. Enter the following command:
netconfig
3. At the Available options menu, enter the number that corresponds to Add
a chain. A chain, in netconfig terms, is a communications configuration
that binds networking products together as though by a chain.
4. From the list of available top-level products, enter the number that corresponds to sco_tcp. (SLIP is a TCP lIP product.)
5. At the prompt Select next level of chain to Add or q to quit, enter
the number that corresponds to slOe
6. When a prompt asks you to confirm the selected product chain, enter y if
the displayed product chain is correct. If the chain is incorrect, enter n to
return to the netconfig main menu. You can then either quit netconfig or
add a different chain of products.
7. At the prompt Enter tty line to be used for slip, enter the name of
the tty line in this format: ttyta.
8. At the prompt Enter Baud rate for t tyla, enter the baud rate. The
default baud rate is 9600.
9. At the prompt Enter the internet address of this interface, enter
the IP address for your system (emerald) in this format: nnn.nnn.nnn.nnn.
See the introduction to this guide for a discussion of IP addresses.
10. At the prompt Enter the internet address of the destination interface:, enter the address for the target system (ruby) in this format:
nnn.nnn.nnn.nnn.
11. At the prompt Enter hostname of the destination interface:, enter
the name of the target system; in this example, ruby.
12. The prompt Are these values correct? (yin), gives you a chance to
change your choices. If you wish to alter any of the values, enter n, then
follow the screen prompts. If the values are correct, enter y.
The netconfig utility automatically adds ruby's information to emerald's
/etc/hosts file.
13. At the prompt Configure gateway?, enter n, unless you plan to establish a
SLIP /Ethemet or SLIP/Token-Ring gateway as described later in this
chapter.
14. When netconfig prompts you to add or remove pseudo ttys, it displays the
current number of pseudo ttys already configured on the system. If this
number is correct, enter q to quit the pseudo tty configuration screen. If
you want to add or remove pseudo ttys, enter the number corresponding
57
Administering serial line communications
to the desired option and follow the prompts. For more information on
pseudo ttys, see the chapter "'rCP lIP network administration" earlier in
this document.
15. When you again see the Available options menu, enter q.
16. You see a prompt to relink the kernel. Enter y for the first SLIP configuration. Subsequent SLIP configurations on the same machine do not require
relinking the kernel.
17. During kernel relinking, enter y to have this kernel boot by default, and y
again to have the kernel environment rebuilt. This procedure takes a few
minutes. When the rebuild is complete, you return to the command line.
18. Disable both the modem and non-modem control ports corresponding to
the tty device being used for SLIP. (The ports might already be disabled.)
For example, use the following commands for COM1:
disable ttyla
disable ttylA
19. If you want to use header compression, edit the /etc/tcp script, and add the
+c flag (to tum on compression mode) or the +e flag (to tum on compression detection) to the slattach(ADMN) command. Using header compression lets you make the most efficient use of the serial line. See the
slattach(ADMN) manual page for more information.
20. Reboot emerald. On booting up with the new kernel, TCP lIP should start
up successfully using the SLIP interface.
21. Use the same procedure to configure the SLIP line on ruby, making the
interface address for ruby's SLIP line match the destination address for
emerald's SLIP line, and making the destination address for ruby's SLIP line
match the interface address for emerald's SLIP line.
This completes the configuration of the SLIP interface on both emerald and
ruby. If you want to configure more than one SLIP line on a machine, repeat
the netconfig procedure for each line you wish to configure, selecting the
option for sl1, and so on. Make sure that each SLIP line is a separate subnet
(has a unique network address and hostname).
Configuring a dialup SUP conrrection
seQ TCP lIP does not directly support dialup SLIP lines. If PPP is available on
both machines, configure a dialup connection using PPP rather than SLIP.
However, if you cannot use PPP, you can configure dialup SLIP lines using the
workaround described in this section. This workaround has not yet been
tested on the current version of TCP /lP.
58
TCP/IP Users and Administrator's Guide
Administering SUP
NOTE Dialup SLIP uses one of the dialer programs from the operating
system's UUCP package; for example lusrllib/uucp/dialHA12 for a Hayes™
modem at 1200 baud. If UUCP and the appropriate dialer program are not
installed, use custom(ADM) to install them.
The following procedure describes how to configure a dialup SLIP connection
between a machine named jade and a machine named diamond across ttyla at
1200 baud. The procedure assumes that both machines have TCP lIP installed
and SLIP configured.
1. Execute the following commands for diamond at the super-user shell
prompt or through the /etc/tcp script:
(stty 1200; echo "ATEO\r" > /dev/tty1a) < /dev/tty1a
slat tach /dev/tty1a diamond_IP_address jade_IP_address 1200
The commands on the first line put the modem into non-echo mode, and
the second line is the slattach(ADMN) command. diamond must execute
the slattach command before jade connects over the dialup SLIP connection.
For information on selecting IP addresses for diamond and jade, see the
introduction to this guide.
2. Execute the following commands for jade at the super-user shell prompt or
through a shell script:
(stty 1200; echo "ATEO\r" > /dev/tty1a) < /dev/tty1a
/dev/tty1a 5551212 1200
/usr/lib/uucp/dialer~ogram
if [ $? ]
then
slat tach /dev/tty1a jade_IP_address diamond_IP_address 1200
else
echo "Error dialing\n"
fi
The commands on the first line put the modem into non-echo mode, and
the second line uses a UUCP dialer program to dial diJzmond at the phone
number 555-1212. The subsequent lines execute slattach if the dialer program reports success. Make sure that jade dials diamond before issuing
slattach.
59
Administering serial line communications
Double-check the following points when you configure a dialup SLIP:
• each SLIP line is a separate subnet (has a unique network address and hostname)
• the slattach command specifies the same, supported baud rate for both machines
• both modems are using the same error protocols, data compression types,
and other configurable features
• you use dedicated tty lines for the SLIP connection
• you use a non-modem control file for the device special file (for example,
use /dev/ttyla instead of /dev/ttylA for COM1)
• the modem and non-modem control ports are disabled
• the modem is attached to the same port that the slattach command
specifies
• the routed(ADMN) daemon starts after slattach. If routed starts before slattach, the following message appears on the console at roughly one-minute
intervals:
routed: packet from unknown router net_address
If you see this message, kill routed, and then restart it.
Configuring a SUP/Ethernet or SUP/Token-Ring gateway
This section explains how to set up a machine as a gateway between a SLIP
network and an Ethernet network. Use the same procedure to configure a
SLIP /Token-Ring gateway, a PPP /Ethernet gateway, or a PPP /Token-Ring
gateway.
A SLIP /Ethernet gateway must connect two distinct networks; that is, the network address and hostname for the SLIP side must be different from those of
the Ethernet side. For a complete discussion on network addresses and host
addresses, see the section on IP addresses in the introduction to this guide.
This procedure describes a SLIP/Ethernet gateway for which the machine
emerald has the serial interface for the SLIP connection, the machine ruby has
the Ethernet card for the Ethernet connection, and the machine opal is the
gateway system. Both networks are configured as Class C networks. (For a
discussion of network classes, see the introduction to this guide.)
60
TCP/IP Users and Administrator's Guide
Administering SUP
This configuration procedure assumes that opal has TCP lIP installed, but neither the SLIP driver nor the Ethernet driver is configured:
1. Configure the SLIP interface on opal, using the steps outlined for a direct
connection or for a dialup connection. Enter y at the prompt Configure
gateway?
2. Run netconfig to configure the Ethernet card on opal, following the
instructions in the sea rep/IP Release and Installation Notes. Enter y at the
prompt Configure gateway?
3. Edit the fete/networks file on opal to include the hostname and network
address for each network as follows:
ruby_ethernet
emerald_slip
ruby_net_address
emerald_net_address
4. If /ete/if.ignore contains a line for sID, remove the line.
5. Reboot opal.
6. Use netstat -i to check that both interfaces are configured. These three
entries should appear in the first column: loopback, sID, and an Ethernet
driver such as wdnO or e3BO. Each entry should show non-zero values for
incoming packets (Ipkts) and outgoing packets (Opkts).
Removing SUP
Remove SLIP with netconfig, then restore the files that you changed to reflect
the SLIP line.
1. At the Available options menu, enter the number corresponding to
Remove a chain, and press (Return).
2. Follow the directions in the rest of the netconfig screen prompts.
3. Edit the /etc/hosts file on each machine and remove the entry associated
with each SLIP line.
4. If you are removing a SLIP/Ethernet or SLIP /Token-Ring gateway, remove
the network entries from fete/networks.
Troubleshooting SUP configurations
This section describes many of the common error messages generated from
ping(ADMN), telnet(TC), or rlogin(TC). For more information on troubleshooting your network connections, see the chapter on network administration earlier in this guide.
61
Administering serial line communications
Common problems with SLIP
If you encounter a problem with SLIP, check to make sure the following are
true:
• slattach is running at both ends of the SLIP connection
• the source address of the first machine matches the destination address of
the second machine, and the destination address of the first machine
matches the source address of the second machine
• the machines at both ends of the connection expect to send and receive
packets with compressed headers, or neither machine expects to send or
receive compressed headers (that is, both machines agree about header
compression)
• the machines at both ends of the connection are using the same baud rate
• the modems at both ends of the connection are using the same protocols
Verifying serial cable connectivity
To verify that your problem is not a serial cable connectivity problem, follow
this procedure on both machines to which the serial cable connects:
1. While logged on as root, bring the system to single-user mode.
2. Edit the file /usr/lib/uucp/Devices to uncomment the following lines, by
removing the number sign from each line:
# Direct ttyla - 9600 direct
# Direct tty2a - 9600 direct
3. After you perform the previous steps on both machines, enter the following command on the source machine: cu -1 ttyla dir.
If the screen displays connected, enter some characters. They should
appear on. the destination machine only. If they do, your serial line is
sound. Type - . at the beginning of a line to exit the cu program.
If there is no response, the problem probably lies with the cable. Check the
cable's connections, or try another cable. If an error message appears, see
the chapter "Building a remote network with UUCP" in the sea UNIX Sys-
tem Administrator's Guide.
62
TCP/IP Users and Administrator's Guide
Administering SUP
Troubleshooting problems with ping
Test that the local and remote interfaces are functional and responding by
booting the system in multi-user mode and executing the following ping commands:
ping local_hostname
ping remote_host_IP_address
ping remote_hostname
If all these commands successfully respond to transmitted packets, the connection is functional and you can try other TCP lIP commands, such as teInet
and rIogin.
The following error message from ping indicates that the network address of
the remote host is different from that of the local host:
ping send: Network is unreachable
Make sure that the network portion of the remote host's IP address is correct.
(See the introduction to this guide for a discussion of the network portion of
the IP address.) For machines on the same network, the network part of the IP
addresses for the local host and the remote host should match. If the machines are not on the same network, you need to configure a gateway to route
packets between the two networks.
The following error message from ping indicates that the remote_hostname
used on the ping command line does not have an entry in fete/hosts:
ping: unknown host remote_hostname
Edit the fete/hosts file on the local host to include an entry for the remote host.
If ping hangs with no response:
1. Make sure that the IP address used on the command line is correct. It
should be the value assigned to the machine connected to the other end of
the direct or modem line.
2. Use the ifconfig(ADMN} command as follows to check the local SLIP interface:
ifconfig sIn
This command should return an output similar to the following:
sIn: flags=51
inet source address-->destination address netmask ffffOOOO
Check that the source and destination addresses are correct and have corresponding entries on the system connected to the other end of the line.
3. Check the netmasks of both machines. An incorrect netmask can render a
host or network unreachable. For more information on netmasks, see the
introduction to this guide.
63
Administering serial line communications
Troubleshooting problems with rlogin or telnet
If ping works correctly but rlogin(TC) or telnet(TC) fails, consult the appropriate manual page to make sure that your command syntax is correct. If the
syntax is correct, verify that your /etc/hosts file has an entry for the target host.
The following telnet or rlogin error message indicates either that there are no
more pseudo ttys available to make additional connections, or that the terminal database does not contain entries for the /dev/ttyp** the system is attemptingtouse:
Cannot obtain database information on this terminal.
Connection closed.
For information on gaining access to additional pseudo ttys, see the section on
administering pseudo ttys in the chapter "Network administration" earlier in
this guide.
More SUP information
The following manual pages provide information about SLIP:
Manual page
slip(ADMP)
slattach(ADMN)
strcf(SFF)
Description
SLIP implementation
the command for assigning a tty line to a network interface
STREAMS configuration file format
For more information about how SLIP is designed and implemented, refer to
RFC 1055 by J. Romkey. For information about compressing SLIP headers,
refer to RFC 1144 by Van Jacobson. You can get these documents from Jon
Postel, RFC Editor, USC Information Sciences Institute, 4676 Admiralty Way,
Marina del Rey, CA 90292-6695.
Administering PPP
Some of the enhancements that Point-to-Point Protocol (PPP) provides to
SLIP's capabilities include error detection, process authentication, and the
ability to send data asynchronously or synchronously.
PPP's features include the following:
• dynamic connect and disconnect service to reduce phone line costs during
idle time. When the phone line disconnects, the process using PPP continues in service without receiving a carrier hangup signal. When the process
transmits or receives data after idling, the phone link is automatically reestablished.
64
rep/IP Users and Administrator's Guide
Administering PPP
• simultaneous serial line sharing with UUCP and cu(C) services
• error detection of transmitted data
• adaptability to high-speed links such as TI, cellular phones, and dial-in services
• ease of setup with the netconfig(ADM) administrative utility
The TCP lIP Runtime system supplies PPP as a separate installation package
that you can install automatically with the rest of the TCP lIP product or
separately.
NOTE PPP is supplied with device drivers for use with IP datagrams and for
asynchronous High-level Data Link Control (HDLC) serial data transmission. PPP requires customized device drivers for synchronous transmission.
Information on creating device drivers is available in the sea UNIX Device
Driver Writer's Guide. Note that creating a device driver is a complex and
difficult task requiring specialized programming skills and a thorough
knowledge of UNIX system internals.
PPP compared to SUP
PPP was created to enhance the capabilities of the Serial Line Internet Protocol
(SLIP) discussed earlier in this chapter. The following table compares these
two products:
SLIP
Asynchronous transmission only
Internet Protocol only
Serial line always in use
Exclusive line use
No error detection of datagrams
PPP
Asynchronous or synchronous
Multiple protocol stack capability
Dynamic connect and disconnect
optimizes line use during idles
Can be shared with UUCP and cu
Built-in error detection
Configuring PPP
This section begins with information that you need before you begin configuring PPP, then describes the netconfig procedure for configuring PPP. Finally,
the section explains how to edit the UUCP Systems and Devices files (and the
Dialers file, if the PPP line operates over modems) to configure the software for
a PPP serial line.
You can edit the Systems, Devices, and Dialers files before or after running
netconfig. Editing them before running netconfig is better, so that you can
verify connectivity.
65
Administering serial line communications
Preparing to configure PPP
Before configuring PPP, make sure that UUCP is installed on your system.
Refer to the chapter IIBuilding a remote network with UUCP" the System
Administrator's Guide supplied with your system for information about how to
set up UUCP.
seQ TCP lIP supports up to four PPP lines per machine. Each PPP line requires
a unique network address and hostname, making it a separate subnet. For
example, a hostname for the first PPP line on a machine called opal might be
opatpppl, the second opatppp2, and so forth. Network addresses are discussed in the section on IP addresses in the introduction to this guide.
Chapter 1 of this guide contains contains the information that you need to
configure a PPP connection. If you read this material before you configure the
SLIP driver, the configuration process flows more smoothly than if you
attempt to answer prompts during configuration.
Information you need to know includes:
• IP address (or Internet address) of your system
• IP address of the target system to which the PPP line is being connected
• netmask for this interface
For more information on IP addresses and netmasks, see the introduction to
this guide.
Configuring PPP with netconfig
This section describes how to use netconfig(ADMN) to configure PPP. The
netconfig utility can configure several PPP serial lines. Even though PPP permits dynamic IP address negotiation, netconfig treats each PPP connection as
though it were a SLIP line and requires explicit entry of IP addresses for your
system and for the target system. You can consider the target system address
a starting address with negotiation available when you use PPP.
I
NOTE During configuration, the netconfig utility supplies information to
the fete/hosts, /ete/stref, and /ete/tep files. None of these files require additional
editing during configura tion.
66
TCP/IP Users and Administrator's Guide
Administering PPP
The following procedure describes how to configure PPP between a machine
named emerald and a machine named ruby. After you enter each selected
value, press the (Return) key to complete your response:
1.
Boot the machine emerald in System Maintenance mode by entering the
root password at the following prompt:
Type CONTROL-D to proceed with normal startup (or enter root
passwd for System Maintenance Mode):
2.
Enter the following command and press (Return):
netconfig
3.
At the Available options menu, enter the number that corresponds to
Add a chain. A chain, in netconfig terms, is a communications configuration that binds networking products together as though by a chain.
4.
From the list of available top-level products, enter the number that corresponds to sco_tcp.
5.
At the prompt Select next level of chain to Add or q to quit:,
enter the number that corresponds to pppO.
6.
When a prompt asks you to confirm the selected product chain, enter y
if the displayed product chain is correct. If the chain is incorrect, enter n
to return to the netconfig main menu. You can then either quit
netconfig or add a different chain of products.
7.
The first time that you configure a PPP connection, follow the netconfig
prompts to choose a password.
S.
At the prompt Enter the internet address of this interface:, enter
the IP address for your system (emerald) in this format: nnn.nnn.nnn.nnn.
9.
At the prompt Enter the netmask for this interface, enter the netmask in this format: nnn.nnn.nnn.nnn.
10.
At the prompt Enter the internet address of the destination
interface:, enter the IP address for the target system (ruby) in this format: nnn.nnn.nnn.nnn.
11.
At the prompt Enter hostname of the destination interface:, enter
the name of the target system; in this example, ruby.
12.
The prompt Are these values correct? (yIn) gives you a chance to
change your choices. If you want to alter any of the values, enter n, then
follow the screen prompts. If the values are correct, enter y.
13.
At the prompt Configure gateway?, enter n, unless you plan to establish
a PPP /Ethernet or PPP /Token-Ring gateway as described in the SLIP sec-
67
Administering serial line communications
tion of this chapter. (You only see this prompt if pppO is the first driver
configured after the loopback driver.)
14.
When netconfig prompts you to add or remove pseudo ttys, enter q if
you want to maintain the pseudo ttys currently configured. If you want
to change the number of pseudo ttys, enter y, and consult the section on
administering pseudo ttys in the chapter "TCP lIP network administration" earlier in this document.
15.
When you again see the Available options: menu, enter q.
16.
You see a prompt to relink the kernel. Enter y for the first PPP configuration. Subsequent PPP configurations on the same machine do not
require relinking the kernel.
17.
Ouring kernel relinking, enter y to have this kernel boot by default, and
y again to have the kernel environment rebuilt. This procedure takes a
few minutes. When the rebuild is complete, you return to the command
line.
18.
Reboot emerald.
19.
Enable the tty line that PPP is using.
20.
Make sure that /etc/ppphosts has the correct entry in the tty column for
the chosen connection (modem or direct). The correct entry for a
modem connection is a dash
the correct entry for a direct connection is the name of the device that PPP is using (for example, /dev/ttyla).
1/ -
21.
";
Use the same procedure to configure the PPP line on ruby, making the
interface address for ruby's PPP line match the destination address for
emerald's PPP line, and making the destination address for ruby's PPP line
match the interface address for emerald's PPP line.
If you want to configure more than one PPP line on a machine, repeat the
netconfig procedure for each line you wish to configure, selecting the option
for pppl, and so on. Make sure that each PPP line is a separate subnet (has a
unique network address and hostname).
Adding PPP in/onnation to configuration files
The next step in the configuration procedure is to add information to the
parameter files used by UUCP and PPP. If your PPP line operates over
modems, you might also need to add information to a file that controls the
dial activity. Each file has an associated manual page as follows:
File
/usr /lib /uucp /Systems
/usr /lib /uucp /Devices
/usr /lib /uucp /Dialers
68
Description
remote system info
device info
dialing info
Manual page
systems(F)
devices(F)
dialers(F)
Permissions
600
644
644
TCP/IP Users and Administrator's Guide
Administering PPP
You can edit these files directly, using your choice of text editor, or you can
run uuinstall(ADM), which prompts you for the necessary information.
NOTE If you edit the parameter files directly, create a backup copy of each
file and refer to the respective manual page before you make any changes.
When you finish editing a file, make sure that the permissions modes are the
same as those shown for each file. This is especially important for the Systems file, which contains high-security information.
The remainder of this section briefly presents information and examples to
help you edit the parameter files either directly or through uuinstall. For
more details about these files, see the UUCP chapter in your administrator's
guide.
Make sure that site names are consistently named in each file.
/usr/lib/uucp/Systems:
pppdir Any Direct 2400-9600 - •• \r ogin:--ogin: nppp word: testing
pppmodem Any ACU 9600 5555 •• \r ogin:--ogin: nppp word: testing
The first entry is for a PPP direct line called pppdir that can operate at speeds
from 2400 to 9600 baud. The second entry is for a modem line that uses an
Automatic Calling Unit (ACU) that operates at 9600 baud. This dialer is
accessed through an internal phone system, such as a PBX, and is reached at
extension 5555. Both lines have testing as their login keyword.
/usr/lib/uucp/Devices:
Direct ttyla - 2400-9600 direct
ACU ttylA - 9600 atdialUSR
For this file, the UUCP installation might supply sufficient entries. Make sure
that the file provides direct information, as the first entry shows. If PPP is
used with a modem, make sure that the file contains a line such as the second
entry.
/usr/lib/uucp/Dialers:
This file might already contain the appropriate entries. Refer to the dialers(F)
manual page and the chapter "Using Modems" later in this guide for instructions on adding information to the Dialers file.
Configuring a pPPIEthernet or PPPIToken-Ring gateway
To set up a machine as a gateway between a PPP network and an Ethernet network, follow the procedure for configuring a SLIP/Ethernet gateway that
appears earlier in this chapter. Configuring a gateway machine between a
PPP network and a Token-Ring network also uses the same procedure.
69
Administering serial line communications
Removing PPP
Remove PPP with neteonfig, and then restore the files that you changed to
reflect the PPP line.
1. At the Available options prompt, enter the number corresponding to
Remove a chain, and press (Return).
2. Follow the directions in the rest of the neteonfig screen prompts, entering
y to relink the kernel.
3. If you are removing a PPP /Ethernet or PPP /Token-Ring gateway, remove
the network entries from /etc/networks.
4. If you are removing your last link to another machine, remove the entry
for that machine from your Systems file for security reasons. You can use
uuinstall to edit the Systems file.
Troubleshooting PPP
To begin troubleshooting PPP, prepare a test environment as follows:
1.
Place two computers side-by-side and connect with a direct serial line.
Generally, a null modem cable should cross-connect the serial ports
between the two computers.
2.
Make sure that the PPP software is installed correctly by running
neteonfig and verifying that the display matches your expectations.
3.
Be familiar with the Troubleshooting your system" chapter in the System Administrator's Guide supplied with your system.
4.
Bring both systems to a known state. For example, reboot both systems,
and bring them to multiuser mode.
5.
Using multiscreens, monitor the system message log on each system
with:
tail -£ lusr/admlsyslog
1/
The following guidelines can help you isolate the problem and find the solution:
Does the serial line function?
For a PPP connection on ttyla running at 1200 baud, enter the following command on each machine:
eu -ltty1a -s1200 dir
This command should cause characters typed on one machine to display on
the other. If not, make sure that the /usr/lib/uucp file is correct, and make sure
that your cable does not have a short. If the eu command does display the
70
rep/IP Users and Administrator's Guide
Administering PPP
characters on the other machine, then run netconfig to make sure that the PPP
is installed. If it is installed, then make sure that a device node exists for the
tty, and that the serial cable is securely connected.
Does the modem connection work?
For a PPP connection on tty1a running at 1200 baud and calling a modem at
extension 5555, enter the following command on each machine:
cu -ltty1a -s1200 5555
The modem should dial, connect, and present a login prompt. If you do not
see a login prompt after many seconds, type -% B to make sure that the remote
modem did not accidentally cycle past the correct baud rate. Try -% B three
times, waiting several seconds in between each try. If you still do not get a
login prompt, make sure that the entries in your Devices file are correct, and
that the remote tty setup is correct.
Next, enter the following command on each machine, specifying the remote
hostname:
cuhostname
You should get the same results as when you specify the extension number. If
you do not, make sure that the entries in your Systems are correct.
Does ping work?
Follow the directions in the SLIP troubleshooting section earlier in this chapter
to test the connection with the ping command. If ping does not work, make
sure that the hostname listed in /etc/ppphosts is correct.
Does telnet work?
If you run telnet or one of the other utilities for using PPP, and messages do
not appear or the command fails, check the /usr/adm/syslog display. If this
does not provide the answer, try disabling and enabling the tty device associated with the PPP serial line. You can also check that the uutry(ADM) and
uustat(C) utilities work. Follow the directions in the Performance and Troubleshooting section of the System Administrator's Guide. This chapter has
detailed directions for handling error messages such as DEVICE LOCKED, LOGIN
FAILED, or NO DEVICES AVAILABLE.
For additional troubleshooting ideas, consult the section on troubleshooting
SLIP lines that appears earlier in this chapter.
71
Administering serial line communications
More PPP infonnation
The following manual pages provide information about PPP:
Manual page
asyhdlc(ADMP)
ifconfig(ADMN)
if.ignore(SFF)
ppp(ADMN)
ppp(ADMP)
pppd(ADMN)
ppphosts(SFF)
strcf(SFF)
Description
asynchronous HOLC device driver
configure network parameters
specifies which daemons should not be sent over PPP
PPP login shell
PPP implementation
PPPdaemon
PPP host attributes
STREAMS configuration file format
For more information about how PPP is designed and implemented, refer to
RFC 1171 and RFC 1172, both written by Jon Postel and Joyce Reynolds. These
documents are available from Jon Postel, RFC Editor, USC Information Sciences Institute, 4676 Admiralty Way, Marina del Rey, CA 90292-6695.
72
rep/IP User's and Administrator's Guide
Chnpter 9
Configuring the BIND name server
With the Berkeley Internet Name Domain (BIND) server, you can create and
maintain a distributed host name and address database for computers on
your network. Your system is configured by default to use the network hosts
file Jete/hosts found on each computer. If you have a large network, updating
every computer's Jete/hosts file can be time-consuming. Using BIND frees the
system administrator from continually updating host name and address data
on every machine.
This chapter explains basic BIND concepts, describes BIND configuration
tasks, and provides examples of the various BIND configuration files.
The name seroice
The basic function of the name server is to answer queries from clients about
host names and addresses. With the name server, the network is broken into
a hierarchy of domains. The name space is organized as a tree, according to
organizational or administrative boundaries. Each node, called a domain, is
given a label, and the name of the domain is the concatenation of all the labels
of the domains from the root to the current domain, listed from right to left,
separated by dots. A label need only be unique within its domain. The whole
space is partitioned into several areas called zones, each starting at a domain
and extending down to the leaf domains or to domains where other zones
start. Zones usually represent administrative boundaries. An example of a
host address for a host at the University of California, Berkeley, would look as
follows:
monet . Berkeley. EDU
73
Configuring the BIND name server
The top-level domain for educational organizations is EDU; Berkeley is a subdomain of EDU and monet is the name of the host. Additional top-level
domains include:
COM
commercial organizations
GOV
government organizations
MIL
military departments
ORG
miscellaneous organizations
Types of servers
There are several types of servers. These are:
• master servers
• caching-only servers
• remote servers
• slave servers
These types of servers are described in more detail in the following four sections.
Master servers
A "master" server for a domain is the authority for that domain. This server
maintains all the data corresponding to its domain. Each domain should have
at least two master servers: a primary master, and some secondary masters to
provide backup service if the primary is unavailable or overloaded. A server
may be a master for multiple domains, being primary for some domains and
secondary for others.
Primary
A "primary master" server is a server that loads its data from a file on disk.
This server may also delegate authority to other servers in its domain.
Secondary
A "secondary master" server is a server that is delegated authority and
receives its data for a domain from a primary master server. At boot time, the
secondary server requests all the data for the given zone from the primary
master server. This server then periodically checks with the primary server to
see if it needs to update its data.
74
TCP/IP Users and Administrator's Guide
Types of servers
Caching-only seroers
All servers are /lcaching" servers. This means that the server caches the information that it receives for use until the data expires. A caching only server is a
server that is not authoritative for any domain. This server services queries
and asks other servers that have the authority for the information needed. All
servers keep data in their caches until the data expires, based on a time-to-live
field attached to the data when it is received from another server.
Remote seroers
A "remote" server is an option given to people who would like to use a name
server on their workstation or on a machine that has a limited amount of
memory and CPU cycles. With this option, you can run all of the networking
programs that use the name server without running the name server on the
local machine. All of the queries are serviced by a name server that is running
on another machine on the network.
. Slave seroer
A "slave" server is a server that always forwards queries it cannot satisfy
locally to a fixed list of forwarding servers instead of interacting with the master name servers for the root and other domains. The queries to the forwarding servers are recursive queries. There may be one or more forwarding
servers, and they are tried in turn until the list is exhausted. A slave and forwarder configuration is typically used when you do not wish all the servers at
a given site to be interacting with the rest of the Internet servers.
A typical scenario would involve a number of workstations and a departmental timesharing machine with Internet access. The workstations might be
administratively prohibited from having Internet access. To give the workstations the appearance of access to the Internet domain system, the workstations could be slave servers to the timesharing machine, which would forward the queries and interact with other name servers to resolve the query
before returning the answer. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. The use of slave
mode and forwarding is discussed further under the description of the named
boot file commands.
75
Configuring the BIND name server
Setting up your own domain
When setting up a domain that is going to be on a public network, the site
administrator should contact the organization in charge of the network and
request the appropriate domain registration form.
I
NOTE If you ever want to connect to a public network, you should reserve
a name before customizing your name server files. Doing so ensures that
you do not choose a name that is already in use elsewhere on the network.
An organization that belongs to multiple networks (such as the Internet and
BITNET) should register with only one network.
The contacts are as follows:
Internet
Sites that are already on the Internet and need information on setting up a
domain should contact HOSTMASTER@NIC.DDN.MIL. You may also want to
be placed on the BIND mailing list, which is a mail group for people on the
Internet running BIND. This group discusses future design decisions, operational problems, and other related topics. To request placement on this mailing list, send mail to the following address:
bind-request@ucbarpa.Berkeley.EDU.
If you have access to news over the network, you can also subscribe to the
newsgroup comp.protocols.tcp-ip.domains for more discussion of domains.
BITNET
If you are on the BITNET and need to set up a domain, contact INFO@BITNIC.
Boot file
The name server uses several files to load its database. The major file used is
the boot file. This is the file that is first read when named starts up. This tells
the server what type of server it is, which zones it has authority over, and
where to get its initial data. The default location for this file is /etc/named.boot.
However, this can be changed by setting the BOOTFILE variable or by specifying the location on the command line when named starts up.
Directory
The directory line specifies the directory in which the name server should run,
allowing the other filenames in the boot file to use relative pathnames.
directory
/usr/local/lib/named
If you have more than a couple of named files to be maintained, you may
wish to place the named files in a directory such as /usr/local/domain and adjust
76
TCP/IP User's and Administrator's Guide
Setting up your own domain
the directory command properly. The main purposes of this command are to
make sure named is in the proper directory when trying to include files by
relative pathnames with $INCLUDE and to allow named to run in a location
that is reasonable to dump core.
Primary master
The line in the boot file that designates the server as a primary server for a
zone looks like the following:
primary
Berkeley. Edu
ucbhosts
The first field specifies that the server is a primary one for the zone stated in
the second field. The third field is the name of the file from which the data is
read.
Secondary master
The line for a secondary server is similar to that for the primary, except that it
lists addresses of other servers (usually primary servers) from which the zone
da ta is obtained.
secondary
Berkeley. Edu
128.32.0.10
128.32.0.4
The first field specifies that the server is a secondary master server for the
zone stated in the second field. The two network addresses specify the name
servers that are primary for the zone. The secondary server gets its data across
the network from the listed servers. Each server is tried in the order listed
until it successfully receives the data from a listed server. If a filename is
present after the list of primary servers, data for the zone is dumped into that
file as a backup. When the server is first started, the data are loaded from the
backup file if possible, and a primary server is then consulted to check that the
zone is still up-to-date.
Caching-only server
You do not need a special line to designate that a server is a caching server. A
caching-only server is indicated by the absence of authority lines, such as secondary or primary in the boot file.
All servers should have the following line in the boot file to prime the name
server's cache:
cache
root.cache
The period" . " specifies the domain. All cache files listed are read in at named
boot time and any values still valid are reinstated in the cache and the root
name server information in the cache files are always used. For information
on the cache file, see the section "Initializing the Cache" later in this chapter.
77
Configuring the BIND name seroer
Forwarders
Any server can make use of forwarders. A forwarder is another server capable of processing recursive queries to try to resolve queries on behalf of other
systems.
The forwarders command specifies forwarders by Internet address as follows:
forwarders
128.32.0.10 128.32.0.4
There are two main reasons for wanting to do so. First, the other systems may
not have full network access and may be prevented from sending any IP packets into the rest of the network and, therefore, must rely on a forwarder that
does have access to the full net. The second reason is that the forwarder sees
a union of all queries as they pass through the forwarders server and, therefore, the forwarder builds up a very rich cache of data compared to the cache
in a typical workstation name server. In effect, the forwarder becomes a
meta-cache that all hosts can benefit from, thereby reducing the total number
of queries from that site to the rest of the net.
Slave mode
Slave mode is used if the use of forwarders is the only possible way to resolve
queries because of lack of full net access or if you wish to prevent the name
server from using other than the listed forwarders. Slave mode is activated by
placing the simple command in the boot file:
slave
If slave is used, then you must specify forwarders. When in slave mode, the
server forwards each query to each of the forwarders until an answer is found
or the list of forwarders is exhausted.
Remote sewers
Every remote server on your system requires the file /etc/resolv.conf. This file
designates the name servers on the network that should be queried.
Initializing the cache
The name server needs to know the identities of the authoritative name
servers for the root domain of the network. To do this, you have to prime the
name servers cache with the address of these higher authorities. This is done
in a file called root.cache. The location of this file is specified in the boot file
/etc/named.boot.
78
TCP/IP Users and Administrator's Guide
Standard resource records
Standard files
There are three standard files used to specify the data for a domain. These
files are:
named.local
named.hosts
named. rev.
The named.local file specifies the address for the localloopback interface, better
known as localhost, with the network address 127.0.0.1. The location of this
file is specified in the boot file.
The named.hosts file contains all the data about the machines in this zone. The
location of this file is specified in the boot file.
The named. rev file specifies the IN-ADDR . ARPA domain. This is a special
domain for allowing address-to-name mapping. Because Internet host
addresses do not fall within domain boundaries, this special domain was
formed to allow inverse mapping. The IN-ADDR.ARPA domain has four
labels preceding it. These labels correspond to the four octets of an Internet
address. All four octets must be specified even if an octet is zero. The Internet
address 128.32.0.4 is located in the domain 4.0.32.128.IN-ADDR.ARPA. This
reversal of the address is awkward to read but allows for the natural grouping
of hosts in a network.
Standard resource records
The records in the name server data files are called resource records. The following is a general description of a resource record:
{name}
{ttl}
addr-class
Record Type
Record Specific data
Resource records have a standard format, as shown above. The first field is
always the name of the domain record and it must always start in column 1.
For some resource records, the name can be left blank. In such cases, the
name of the previous resource record is used. The second field is an optional
time-to-live field. This specifies how long this data is stored in the database.
When this field is left blank, the default time-to-live is specified in the Start of
Authority resource record discussed later in this chapter. The third field is the
address class. There are currently two classes: IN for Internet addresses and
ANY for all address classes. The fourth field states the type of the resource
record. The fields after that are dependent on the type of the resource record.
Case is preserved in names and data fields when loaded into the name server.
All comparisons and lookups in the name server database are caseinsensitive.
79
Configuring the BIND name server
The following characters have special meanings:
A free-standing dot in the name field refers to the current domain.
A free-standing @" in the name field denotes the current origin.
You can use origins within configuration files as a shorthand for
fully qualified domain names.
@
II
Two free-standing dots represent the null domain name of the root
when used in the name field.
\X
Here X is any character other than a digit (0-9), and \X quotes that
character so that its special meaning does not apply. For example,
\ . can be used to place a dot character in a label.
\DDD Here each D is a digit, and \DDD is the octet corresponding to the
decimal number described by DDD. The resulting octet is assumed
to be text and is not checked for special meaning.
()
Parentheses are used to group data that crosses a line. In effect, line
terminations are not recognized within parentheses.
A semicolon starts a comment; the remainder of the line is
ignored.
*
An asterisk signifies a wildcard.
Most resource records have the current origin appended to names if they are
This is useful for appending the current domain
not terminated by a
name to the data, such as machine names, but can cause problems when you
do not want this to happen. The following is a good rule of thumb: if the
name is not in the domain for which you are creating the data file, end the
name with a
II . " .
/I • " .
Separating data into multiple files
An include line begins with $INCLUDE (starting in column 1) and is followed
by a filename. This feature is particularly useful for separating different types
of data into multiple files. Here is an example:
$INCLUDE /usr/named/data/mailboxes
The line would
be
interpreted
as
a
request
to
load
the
file
/usr/named/data/mailboxes. The $INCLUDE command does not cause data to be
loaded into a different zone or tree. This is simply a way to allow data for a
given zone to be organized in separate files. For example, mailbox data might
be kept separately from host data using this mechanism.
80
TCP/IP Users and Administrator's Guide
Standard resource records
Changing an origin in a data file
Use the $ORIGIN command to change the origin in a data file. The line starts
in column 1 and is followed by a domain origin. This is useful for putting
more than one domain in a data file. For example, /ete/named.hosts might contain lines of the form:
$ORIGIN CC.Berkeley.EDU
[assorted domain data ... ]
$ORIGIN EE.Berkeley.EDU
[assorted domain data ... ]
The start of authority resource record (SOA)
The Start of Authority record designates the start of a zone. An SOA record
includes the following fields:
Name
name of the zone
Origin
name of the host on which this data file resides
Person in charge mailing address for the person responsible for the name
server
Serial number
version number of this data file; this number should be
incremented whenever a change is made to the data. (Note
that the name server cannot handle numbers over 9999
after the decimal point.)
Refresh
how often, in seconds, a secondary name server is to check
with the primary name server to see if an update is needed
Retry
how long, in seconds, a secondary server is to retry after a
failure to check for a refresh
Expire
upper time limit, in seconds, that a secondary name server
is to use the data before it expires for lack of getting a
refresh
Minimum
default number of seconds to be used for the time-to-live
field on resource records
There should only be one SOA record per zone.
81
Configuring the BIND name server
Here is an example of an SOA record:
name {ttl} addr-class SOA
Origin
@
IN
SOA
ucbvax.Berkeley.Edu.
Serial
1.1
3600
Refresh
300
Retry
3600000
Expire
3600)
Minimum
Person in charge
kjd.ucbvax.Berkeley. Edu.(
The name server resource record (NS)
The name server record (NS) lists a name server responsible for a given
domain. The first name field lists the domain that is serviced by the listed
name server. There should be one NS record for each master server for the
domain. Here is an example of a name server record:
{name}
{ttl}
@
addr-class
IN
NS
NS
Name servers name
ucbarpa . Berkeley. Edu.
The @" character specifies the current origin. The address class is IN (Internet addresses), and the record type is name server (NS). The record uses the
default ttl (time-to-live) value. Here, the record-specific data is the identity of
the name server.
II
The address resource record (A)
The address record (A) lists the address for a given machine. The name field is
the machine name and the address is the network address. There should be
one A record for each address of the machine. Here is an example of an
address record for a machine named ucbarpa with two network addresses:
{name} {ttl}
ucbarpa
addr-class
IN
A
IN
A
A
address
128.32.0.4
10.0.0.78
The host information resource record (HINFO)
The host information resource record (HINFO) is for host-specific data. It lists
the hardware and operating system that are running at the listed host. It
should be noted that only a single space separates the hardware information
and the operating-system information. If you want to include a space in the
machine name, you must quote the name. Host information is not specific to
any address class, so ANY may be used for the address class. There should be
one HINFO record for each host. Here is an example:
{name}
82
{ttl}
addr-class
ANY
HINFO
HINFO Hardware
VAX-11/780 UNIX
OS
TCP/IP Users and Administrator's Guide
Standard resource records
Note that the current release ignores any records that appear after an HINFO
record. Thus, you can use only one HINFO record within the file, and it
should be the last record in the file.
The wel'-knO'Wn services resource record (WKS)
The well-known services record (WI cd /pub/ntp/doc
250 CWD command successful.
ftp> get clock. txt
200 PORT command successful.
150 ASCII data connection for clock. txt (128.212.66.118,1198) (57002 bytes).
local: clock. txt remote: clock. txt
58409 bytes received in 8 seconds (7.1 Kbytes/s)
ftp> quit
221 Goodbye.
144
TCP/IP Users and Administrator's Guide
Network time protocol
The driftfile
The driftfile entry in /etc/ntp.conf tells xntpd the name of the file where it can
find and store the clock drift, also known as frequency error, of the system
clock. If the file exists at startup, it is read and the value used to initialize
xntpd's internal value of the frequency error. The file is updated once every
hour by xntpd. It usually takes a day or so after the daemon is started to compute a good estimate of the clock drift. Once the initial value is computed it
will change only by relatively small amounts during the course of continued
operation. Because xntpd needs a good estimate to synchronize closely to its
server, there should always be a driftfile entry in /etc/ntp.conf.
Association modes
There are several different modes that hosts can be directly configured to
operate in with respect to synchronization with other hosts: client mode,
broadcastclient mode, and symmetric active mode.
In client mode, a host polls other hosts to get the current time. From among
all of the hosts polled, the local host selects one with which to synchronize. To
configure your host this way, include a server statement in your host's configuration file. The name or IP address of each time server to be polled must be
specified in the server statement.
In broadcastclient mode, a host does no polling at all. Rather, it listens for
NTP packets broadcast over the network. From among all of the broadcasting
hosts, the local host selects one with which to synchronize. To configure your
host this way, include a broadcastclient yes statement in your host's configuration file. For this mode to function, the local time servers must be configured in broadcast mode with the broadcast configuration statement.
Finally, in symmetric active mode, a host polls other hosts and responds to
polls from those hosts. In addition, hosts retain time-related information
about the hosts with which they are communicating. To configure your host
this way, include a peer statement in your host's configuration file. The name
or IP address of each time server must be specified in the peer statement.
A general guideline is to configure all hosts, except those at the highest strata
of the synchronization subnet (those furthest away from stratum 1 servers), to
operate in symmetric active mode. For those hosts that are at the highest
strata, you have a choice: configure them to operate either in client mode or in
broadcastclient mode. You should consider opting for broadcastclient mode if
your hosts are on a high-speed LAN that supports broadcasts efficiently, especially if the hosts number more than twenty or so.
145
Synchronizing clocks
If you do opt for broadcastclient mode on those hosts, you must configure the
time servers on the local network to be both in broadcast mode (to send
broadcast NTP packets on the local network) and in symmetric active mode
(to poll hosts at lower strata).
Address and mask facility
The address and mask configuration facility adds various restrictions or erect
barriers between your host and other time servers. A typical statement in the
configuration file looks as follows:
restrict IP_address mask IP_address_mask flagl flag2 ...
Each statement adds an entry to an internal list maintained by xntpd. Each
entry in this list contains the list entry address (the IP address following restrict), the address mask, and the flags. Below is a list of all of the flags and
their meaning:
ignore
indicates that all packets from hosts matching this entry will be
ignored
noquery
indicates that your host will not respond to mode 6 and 7 packets sent from hosts with a matching address
nomodify
indicates that your host will not allow itself to be reconfigured
by hosts with a matching address
notrap
indicates that your host will not allow hosts with a matching
address to register as a trap receiver
lowpriotrap indicates that your host will give hosts with a matching address
a low priority for the use of traps
146
noserve
indicates that your host will not give the time to hosts with a
matching address
nopeer
indicates that your host will not attempt to get time from any
host with a matching address
notrust
indicates that hosts matching this entry, while treated normally
in other respects, should not be trusted for synchronization
TCP/IP User's and Administrator's Guide
Network time protocol
When xntpd receives a packet, it compares the address of the host that sent
the packet (the source address) with each entry in the internal list. Whenever
the following relation (expressed in C language syntax) is true, a match
occurs.
In words, the source address and the address mask are logically ANDed
together bitwise, the list entry address and the address mask are logically
ANDed together bitwise, and the two results compared for equality. If the
results are equal, a match has occurred. To establish default restrictions that
apply to all hosts for which no match is found, include a statement like the
following in the configuration file:
restrict default flagl flag2 ...
If a particular source address matches more than one list entry, the entry with
the most one bits in the address mask is taken to be the matched entry. If a
match is found, flags associated with this entry are returned.
Suppose that you are running xntpd on a host with IP address 128.212.66.67.
You would like to ensure that runtime reconfiguration requests can be made
only from the local host. Further, you would like the host to synchronize with
only one of a pair of offsite servers or, failing that, a time source on the class B
network whose address is 128.212. The following entries in the configuration
file would implement this policy:
# By default, do not trust and do not allow modifications
restrict default notrust nomodify
# These hosts are trusted for time, but no modifications allowed
restrict 128.212.0.0 mask 255.255.0.0 nomodify
restrict 128.192.8.4 nomodify
restrict 192.211.1.24 nomodify
# These local addresses are unrestricted
restrict 128.212.66.67
restrict 127.0.0.1
The first entry is the default entry, which all hosts match and hence which
provides the default set of flags. The next three entries indicate that matching
hosts have only the nomodify flag set and hence are trusted for time. If the
mask is not specified in the restrict statement, it defaults to 255.255.255.255.
147
Synchronizing clocks
Note that the address 128.212.66.67 matches three entries in the table, the
default entry (mask 0.0.0.0), the entry for net 128.212 (mask 255.255.0.0) and
the entry for the host itself (mask 255.255.255.255). As expected, the flags for
the host are derived from the last entry, as that mask has the most bits set.
Each restrict statement applies to packets from all hosts, including those that
are configured elsewhere in the configuration file. Hence, if you specify a
default set of restrictions that you do not wish to apply to the hosts you are
synchronizing with, you must override the default restrictions for those hosts
with additional restrict statements.
Name resolution
The xntpd daemon can specify host names requiring resolution in peer and
server statements in the configuration file. This task is actually accomplished
by a separate program, xntpres. When the daemon comes across a peer or
server statement in the configuration file where the host is identified by name
rather than by IP address, it records the relevant information and continues.
When the end of the configuration file has been reached and one or more
entries requiring name resolution have been found, xntpres is started. The
xntpd daemon continues running at the same time to process those hosts with
numeric addresses.
The xntpres program attempts to resolve each host name, meaning that it tries
to obtain the IP address associated with the named host. If it succeeds in
resolving the name, it reconfigures the local host to add the newly resolved
host to the list of time servers to be polled. The runtime reconfiguration of the
local host is accomplished using the same mode 7 runtime reconfiguration
facility that xntpdc uses. If xntpres is at first unable to resolve a host's name,
it retries periodically until it succeeds or until it determines that the name cannot be resolved.
There are several configuration requirements if xntpres is to be used. The
pathname of the xntpres program must be made known to the daemon with
the resolver statement in the configuration file. Also, mode 7 runtime reconfiguration must be enabled with the requestkey statement and a list of valid
keys (valid keys are specified in the keys file).
The following fragment might be added to /etc/ntp.conf to accomplish this:
resolver /local/etc/xntpres
keys /etc/ntp.keys
requestkey 65535
148
TCP/IP Users and Administrator's Guide
Network time protocol
Note that xntpres sends packets to the server with a source address of
127.0.0.1. If you are using the address-and-mask facility in the configuration
file, you must take care not to restrict modification requests from this address
or xntpres fails.
Sample scenarios
This first scenario would be used when configuring a single host to use NTP.
The host rainbow.sci.com is expected to run as a stratum 2 server because it is
configured to get the time from two time servers with radio clocks,
bedivere.cs.purdue.edu and asmus1.genetics.uga.edu. The xntpd daemon stores
the frequency error of the clock on rainbow.sci.com in /etc/driftfile. This is a
good example to use if you just want to get xntpd up and running quickly.
Note that it can take a day or two for a host to synchronize with a time server.
Here is the ntp.conf file for rainbow.sci.com.
#
# Peer configuration for 128.212.66.13 (rainbow.sci.com)
#
peer 128.211.1.24
# bedivere.cs.purdue.edu
peer 128.192.8.4
# asmus1.genetics.uga.edu
driftfile /etc/driftfile
This next scenario is the complete configuration for sci.com. The configuration
files here configure sci.com to match the topology discussed in "Guidelines"
earlier in this chapter. All hosts can be configured dynamically with xntpd.
There are no restrictions on which hosts can be designated as time servers in a
given host's configuration file.
149
Synchronizing clocks
Here is the ntp.conf file for Zite.
#
# Peer configuration file for 12B.212.66.90 (zite.sci.com)
#
peer
peer
peer
peer
12B.211.1.4
# percival.cs.purdue.edu
192.35.53.67
# deidinator.psyc.chi.il.us
HGWells.Sci.com
DrWho.Sci.com
broadcast 12B.212.66.255
driftfile /etc/ntp.drift
resolver
/etc/xntpres
keys
/etc/ntp.keys
requestkey 65534
controlkey 65535
Here is the ntp.keys file for Zite.
2313
65534
65535
A
A
A
APassword
NoSecret
BadKey
Here is the ntp.conf file for HGWells.
#
# Peer configuration for HGWells (12B.212.66.67)
#
peer
peer
peer
peer
12B.192.8.4
128.211.1.24
zite
DrWho
# asmus1.genetics.uga.edu
# bedivere.cs.purdue.edu
broadcast 128.212.66.255
driftfile /etc/ntp.drift
/etc/xntpres
resolver
keys
/etc/ntp.keys
requestkey 65534
controlkey 65535
150
TCP/IP Users and Administrator's Guide
Network time protocol
Here is the ntp.keys file for HGVVells.
2313
65534
65535
A
A
A
APassword
NoSecret
BadKey
Here is the ntp.conf file for DrWho.
#
# Peer configuration file for 128.212.66.118
#
DrWho.Sci.com
#
peer
peer
peer
peer
# nehd.gov
192.35.54.2
# berdie.athens.ga.us
192.35.55.2
HGWells.Sci.com
Zite.Sci.com
broadcast 128.212.66.255
drift file /etc/ntp.drift
resolver
/etc/xntpres
keys
/etc/ntp.keys
requestkey 65534
controlkey 65535
Here is the ntp.keys file for DrWho.
2313
65534
65535
A
A
A
APassword
NoSecret
BadKey
151
Synchronizing clocks
Here is the ntp.conf file for Moondoggie.
# Peer configuration used by all stratum 3
#
servers at sci.com
#
broadcastclient yes
broadcastdelay
0.0500
driftfile
/etc/ntp.drift
/etc/xntpres
resolver
keys
/etc/ntp.keys
requestkey 65534
controlkey 65535
Here is the ntp.keys file for Moondoggie.
2313
65534
65535
A
A
A
APassword
NoSecret
BadKey
Testing and tuning
There are several parameters available for tuning time servers. These are set
using the precision and maxskew configuration statements. A fragment that
would simply reset these to their default values follows:
precision
maxskew
-6
0.01
The precision statement sets the value of sys.precision, and the maxskew
statement sets the value of NTP.MAXSKW. The variable sys.precision is the
base two logarithm of the expected precision of the system clock. The default
value is -6 on all servers.
The NTP protocol makes use of sys.precision in several places. For one,
sys.precision is included in packets sent to peers and is used by them as a
kind of quality indicator. When faced with selecting for synchronization purposes one of several servers, all of which are at the same stratum and offer
about the same network path delay, clients prefer to synchronize to those
claiming the smallest (most negative> value of sys.precision. The effect is particularly pronounced when all the servers are on the same LAN. Hence, if you
run several stratum 1 seI'vers, or three or four stratum 2 servers, and you
would like clients to prefer one of these over the others for synchronization,
you can accomplish this by decreasing the value of sys.precision on the preferred server or by increasing this value on the other servers, or by doing both.
152
TCPjIP Users and Administrator's Guide
Network time protocol
The other tuning parameter is the antihop aperture and is derived from
sys.precision and NTP.MAXSKW using the following equation:
antihop aperture
=2
** sys.precision + NTP.MAXSKW
This equation says that the antihop aperture is equal to 2 raised to the
sys.precision power plus NTP.MAXSKW.
Making the antihop aperture larger makes it less likely that the host will
"hop" from the server it is currently synchronizing with to a different server.
Unfortunately, this also increases the probability that the host continues to
synchronize with a server whose clock is no longer accurate.
Making the antihop aperture smaller allows the host to hop more freely from
server to server, but this can also cause it to generate a fair bit more NTP
packet traffic than necessary and to no good purpose. Given the agreement
among current stratum 1 NTP servers and the performance typical of the
Internet, it is recommended that the antihop aperture be kept between 0.020
and 0.030. The default value is about 0.026.
You can change the antihop aperture by changing the value of NTP.MAXSKW
using the maxskew configuration statement. Note, however, that if you wish
to change sys.precision with the precision configuration statement, but do
not wish to alter the anti hop aperture, you must change NTP.MAXSKW to
compensate.
Query commands
Two query programs, ntpq(ADMN) and xntpdc(ADMN), are available for use
by the network administrator. The ntpq command sends queries and receives
responses using NTP standard mode 6 control messages, while the xntpdc
command uses NTP private mode 7 messages to send its requests. The format
and content of these messages are specific to xntpdc. This command allows
you to inspect a wide variety of internal counters and other state data. It also
provides you with an interface to the runtime reconfiguration facility.
Both xntpdc and xntpd use seconds as the unit of time, both when reading the
configuration file and when doing runtime reconfiguration. Both programs
also print values in seconds. On the other hand, ntpq prints all time values in
milliseconds. You must, therefore, take special care to convert values output
by ntpq from milliseconds to seconds before modifying the configuration file,
either manually or with xntpdc.
The xntpd daemon is designed to allow its configuration to be modified at
runtime. Nearly everything that can be configured in the configuration file
ntp.conf may be altered using xntpdc.
153
Synchronizing clocks
Mode 6 and mode 7 packets, which would modify the configuration of the
local host, must be authenticated. To enable the facilities one must, in addition to specifying the location of a keys file, indicate in the configuration file
the key IDs to be used for authenticating reconfiguration requests. The following fragment might be added to the configuration file to enable ntpq and
xntpdc.
keys /etc/ntp.keys
requestkey 65535
controlkey 65534
# for mode 7 requests (used by xntpdc)
# for mode 6 requests (used by ntpq)
If the requestkey or the controlkey configuration statement is omitted from
the configuration file, the corresponding runtime reconfiguration facility is
disabled.
The query programs require the user to specify a key ID and a key to use for
authenticating requests to be sent. The key ID provided must be the same one
specified in the configuration file, while the key value provided must match
the one corresponding to the given key ID in the keys file.
Further examples
This example demonstrates the use of ntpq and xntpdc to list the servers that
Moondoggie.sci.com is currently polling. The server marked with an asterisk
is the one that Moondoggie is currently synchronizing with. Moondoggie is
also listening for broadcast packets on the subnet with IP address 128.212.66,
but no packets are currently being broadcast there. Note the difference in the
units used by ntpq and xntpdc to display delay, offset, and dispersion. The
former uses milliseconds, whereas the latter uses seconds.
U "'"
sjc@moondoggie $ ntpq
ntpq> peer
remote
refid
st when poll reach delay offset
disp
======================================================================
128.212.66.255
* Zite . sc i. com
+DrWho.sci.com
154
0.0.0.0
16 never
deidinator.ps 2
53
berdie.athens 2
11
64
64
64
0
376
37
0.0
81.1
41.2
0.00 64000
12.4
-1. 00
30.00 7504.3
TCPjIP Users and Administrator's Guide
Network time protocol
sjc@moondoggie $ XDtpd
xntpd> peer
st poll reach delay
local
remote
offset
disp
======================================================================
*Zite.sci.com
-DrWho.sci.com
~128.212.66.255
192.35.53.67
192.35.55.2
0.0.0.0
2
2
16
64
64
64
376 0.0811 -0.001003 0.0124
37 0.0412 0.030001 7.5043
0 0.0000 0.000000 64.000
This information tells us, among other things, that:
• Moondoggie is currently synchronizing with Zite.
• Zite is at stratum 2, implying that Moondoggie is at stratum 3.
• Moondoggie is polling Zite once every 64 seconds.
• The reachability register for Zite is octal 376.
• The dock on Moondoggie is 1 millisecond, or more precisely, 1003
microseconds, behind the dock on Zite.
• The roundtrip delay to Zite is 81 milliseconds.
• The dispersion is 12.4 milliseconds.
The next example shows how to tum on monitoring and how to list the statistics that are gathered when monitoring is enabled.
xntpdc> monitor on
Keyid: 65534
Password: NoSecret
done!
Now that monitoring is on, we can let the daemon run for a while, then display statistics, as shown here.
xntpdc> monlist
address
port
count
mode version lasttime firsttime
================================================================
127.0.0.1
128.212.66.118
128.212.66.90
1417
123
123
6
3818
7432
7
1
5
2
2
2
0
92
48
475668
475332
475632
155
Synchronizing clocks
This display tells us who has connected to the xntpd daemon, on what UDP
port the connection was made, the number of packets received, the mode of
this connection, the version of NTP being run, the time since the last packet
exchange in seconds, and the time since the first packet exchange in seconds.
The last example shows how we can dynamically delete and add time servers.
First, we indicate which host we wish to communicate with, then we display
the current peers of that host.
xntpdc> host rainbow
current host set to rainbow.sci.com
xntpdc> peers
remote
local
st poll reach
delay
offset
disp
==================================================================
*zite.sci.com
128.211.1.4 2 64
tHGWells.sci.com 0.0.0.0
16 1024
376 0.0512 -0.010000 0.0021
0 0.0000 0.000000 64.000
Now we remove HGWells as a peer and view the result.
xntpdc> unconfig HGWells
Keyid: 65534
Password: NoSecret
done!
xntpdc> peers
remote
local
*zite.sci.com 128.211.1.4
st poll reach
2
64
376
delay
offset
disp
0.0512 -0.010000 0.0021
Now that HGWells has been removed as a peer, we go ahead and add host
DrWho as a new peer.
156
TCP/IP Users and Administrator's Guide
Network time protocol
xntpdc> addpeer DrWho.8ci.com
done!
xntpdc> peers
remote
local
st poll reach
delay
offset
disp
================================================================
+DrWho.sci.com 0.0.0.0
16
*zite.sci.com 128.211.1.4 2
64
64
0 0.0000 0.000000 64.000
376 0.0512 -0.010000 0.0021
If we allow Rainbow to poll the new peer for a period of time and then reissue
the peers subcommand, we might see something like this display.
xntpdc> peers
remote
local
*DrWho.sci.com 128.212.66.118
-zite.sci.com 128.211.1.4
st poll reach delay
2
2
64
64
377
376
offset
disp
0.0312 -0.004488 0.0011
0.0512 -0.010000 0.0021
Troubleshooting
The xntpd daemon records all problems and errors using the syslog(SLIB) system call into the file /usr/adm/syslog. You can examine this log for signs of trouble. For example, too many entries indicating that the local clock was stepped
instead of slewed to the correct time suggests that the daemon is having trouble synchronizing the clock. (In this instance, more than two entries per hour
on a consistent basis is probably too many.) The most likely cause is that
some other program, perhaps timed, is also setting or slewing the clock.
Another sign of more than one entity setting or slewing the clock is the following message in the syslog file:
Previous time adjustment did not complete
157
Synchronizing clocks
One of the following messages is issued when the clock of another host (the
remote clock) is offby more than 1000 seconds from the clock on the local host
(the local clock):
Clock appears to be nuntber_of_secondS seconds fast,
something may be wrong
Clock appears to be nuntber_of_seconds seconds slow,
something may be wrong
In this situation xntpd will not try to synchronize with that host. If you want
to synchronize with that host, you will need to set the local clock to within
1000 seconds of the remote clock. You can accomplish this by using the
ntpdate(ADMN) command.
Running mixed synchronization subnets
The xntpd time daemon is an implementation of NTP Version 2. By default,
xntpd sends NTP packets marked as being of the Version 2 variety. However,
another implementation of the NTP time daemon, called ntpd, may be running on hosts you wish to poll. If this is the case, you must include the version option in the peer or server configuration statements for those hosts to
force xntpd to send packets of the Version 1 variety.
For example, if the host nehd.gov at IP address 192.35.54.2 is a host you wish to
poll in symmetric active mode and you know that nehd.gov is running ntpd
instead of xntpd, you should include the following configuration statement in
your local hosts ntp.conf file:
peer 192.35.54.2 version 1
# nehd.gov (running ntpd)
This statement ensures that Version 1 NTP packets are sent by your local host
to nehd.gov.
158
TCP/IP Users and Administrator's Guide
Chapter 14
TCPjIP sendmail administration
The sendmail(ADMN) utility provides a "back-end" mail interface to other
mail programs; that is, sendmail only routes and delivers mail, it does not
provide a user interface for composing or formatting letters. sendmail provides network access and supports either Internet-style addressing, such as
user@domain or UUCP-style addressing, such as host!user. sendmail works
with delivery agents such as SMTP (Simple Mail Transfer Protocol), X.400, and
UUCP. sendmail only handles text format files; binary data is not allowed.
NOTE This chapter describes how you can manually fine-tune sendmail
configuration. In most installations, running the initialization script mkdev
sendmail-init without any manual configuration will produce the desired
results on your system. In that case, the information found in this chapter
following the section "Configuring a standard installation" is unnecessary,
and is provided for completeness only.
You do not need to use sendmail to route mail; the operating system's MMDF
mail router is also available and provides several key benefits over using
sendmail, including an easier configuration process. For more information on
MMDF, refer to your operating system's.
This chapter compares sendmail to other mailers, discusses how sendmail
works, explains sendmail configuration, shows how to run sendmail, and
details sendmail administration.
159
rep/IP sendmail administration
sendmail and other mailers
This section compares sendmail with three other mail programs:
• delivermail
• MMDF (Multichannel Memorandum Distribution Facility)
• MPM (Message Processing Module)
These comparisons are provided for those who are familiar with these other
mail routing programs.
Comparing sendmail with delivermail
The sendmail program is an outgrowth of delivermail. The primary
differences are as follows:
• Configuration information is not compiled in. This change simplifies many
of the problems of moving to other machines. It also simplifies debugging
of new mailers.
• Address parsing is more flexible. For example, delivermail only supported
one gateway to any network, whereas sendmail can be sensitive to host
names and reroute to different gateways.
• The forward and include features of sendmail eliminate the requirement
that the system alias file be writable by any user (or that an update program be written, or that the system administration make all changes).
• The sendmail program supports message batching across networks when a
message is being sent to multiple recipients.
• A mail queue is provided in sendmail. Mail that cannot be delivered
immediately but can potentially be delivered later is stored in this queue
for a later retry. The queue also provides a buffer against system crashes;
after the message has been collected, it may be reliably redelivered even if
the system crashes during the initial delivery.
• The sendmail program uses the networking support of the operating system to provide a direct interface to networks such as Ethernet using SMTP
(the Simple Mail Transfer Protocol) over a TCP lIP connection.
Comparing sendmail with MMDF
The Multichannel Memorandum Distribution Facility (MMDF) spans a wider
problem set than sendmail. For example, the domain of MMDF includes a
"phone network" mailer, whereas sendmail calls on pre-existing mailers in
most cases.
160
TCP/IP Users and Administrator's Guide
sendmail and other mailers
MMDF and sendmail both support aliasing, customized mailers, message
batching, automatic forwarding to gateways, queueing, and retransmission.
MMDF supports two-stage timeout, which sendmail does not support. MMDF
uses two-stage timeout when routing mail through machines to users. If a
message cannot be forwarded to a particular machine or to a particular user
on a machine, a warning is sent back to the mail message sender. This is stage
1. At some future time (configurable by the administrator), the message is
relayed again. If it fails, a failure message is returned to the sender, and
MMDF makes no further attempts to resend the original message. This is
stage 2.
MMDF does offer several substantial benefits over sendmail, including:
• Configuration files that are easy to read and understand.
• The ability for end-users to configure their own sorting parameters.
• A larger set of supported delivery agents.
Because MMDF does not consider backwards compatibility as a design goal,
the address parsing is simpler but much less flexible.
It is somewhat harder to integrate a new channel into MMDF. In particular,
MMDF must know the location and format of host tables for all channels, and
each channel must speak a special protocol. This allows MMDF to do additional verification (such as verifying host names) at submission time.
MMDF strictly separates the submission and delivery phases. Although sendmail has the concept of each of these stages, they are integrated into one program, whereas in MMDF they are split into two programs.
Sendmail and the message-processing module (MPM)
The Message Processing Module (MPM) matches sendmail closely in terms of
its basic architecture. However, like MMDF, the MPM includes the network
interface software as part of its domain.
MPM also postulates a duplex channel to the receiver, as does MMDF. This
allows simpler handling of errors by the mailer than is possible in sendmail.
When a message queued by sendmail is sent, any errors must be returned to
the sender by the mailer itself. Both MPM and MMDF mailers can return an
immediate error response, and a single error processor can create an appropriate response.
MPM prefers passing the message as a structured object, with {type, length,
value} triples. Such a convention requires a much higher degree of cooperation between mailers than is required by sendmail. MPM also assumes a
universally agreed-upon Internet name space (with each address in the form
of a net-host-user tuple), which sendmail does not.
161
TCPIIP sendmail administration
How sendmail works
When a sender, for example the mail (C) command, wants to send a message,
a request is issued to sendmail directly, via SMTP over a pair of pipes, or via
SMTP using a socket. sendmail then collects and queues the message along
with other messages, ·and when ready delivers the message. If any errors
occur while delivering the message, sendmail returns a message to the sender
describing the error. Alternatively, it may return a status code to indicate
what went wrong.
If sendmail is called using SMTP over pipes or through a socket, the arguments are first scanned and option specifications are processed. Recipient
addresses are then collected, either from the command line or from the SMTP
command RCPT (recipient), and a list of recipients is created. Aliases are
expanded at this point. This includes any aliases that are part of a mailing list.
At this stage, as much validation of the addresses as possible is done. Syntax
is checked and local addresses are verified, but detailed checking of host
names and addresses is deferred until delivery. Forwarding is also performed
as the local addresses are verified.
The sendmail program appends each address to the recipient list after parsing
the recipient list. When a name is aliased or forwarded, the old name is
retained in the list, and a flag is set that tells the delivery phase to ignore this
recipient. This list is kept free from duplicates, preventing alias loops and
duplicate messages from being delivered to the same recipient, as might occur
if a person is in two groups.
Collecting messages
The sendmail program collects the message after the address parsing is complete. The message should have a header at the beginning. No formatting
requirements are imposed on the message, except that they must be lines of
text; binary data is not allowed. A message consists of a header and a body,
which are separated by a blank line. The header is parsed and stored in memory, and the body of the message is saved in a temporary file.
To simplify the program interface, the message is collected even if no
addresses are valid. The message is then returned to the sender with an error.
The header is formatted as a series of lines of the form:
field-name: field-value
field-value can be split across lines by starting the lines that follow with a
space or a tab. Some header fields have special internal meaning, in which
162
TCP/IP Users and Administrator's Guide
How sendmail works
case they are subject to special processing. Other headers are simply passed
through. Some header fields, such as time stamps, may be added automatically.
The message body is a series of text lines. It is completely uninterpreted and
untouched by sendmail, except that lines beginning with a dot II • " have the
dot doubled when transmitted over an SMTP channel. This extra dot is
stripped by the receiver. (SMTP uses lines beginning with a dot to signal the
end of the message.>
Delivering messages
For each unique mailer and host in the recipient list, sendmail calls the
appropriate mailer. Each mailer invocation sends to all users receiving the
message on one host. Mailers that accept only one recipient at a time are handled accordingly.
The message is sent to themailer.using one of the same three interfaces used
to submit a message to sendmail. Each copy of the message is prefaced by a
customized header. The mailer status code is caught and checked, with a suitable error message given as appropriate. The exit code must conform to a system standard; otherwise, a generic message such as Service unavailable is
given.
The send queue is sequenced by the receiving host before transmission in
order to implement message batching. Each address is marked as it is sent,
and so rescanning the list is safe. An argument list is built as the scan
proceeds. Mail to files is detected during the scan of the send list.
After a connection is established, sendmail makes the changes to the header
necessary for correct interpretation by a particular mailer and sends the result
to that mailer. If any mail is rejected by the mailer, a flag is set to invoke the
return-to-sender function after all delivery completes.
Queueing for retransmission
If the mailer returns a status code indicating that the message should be sent
later, sendmail puts the mail on the queue and tries again later.
Return to sender
If errors occur during processing, sendmail returns the message to the sender
for retransmission. If the user agent (mail) detects the error, then it is put in
the dead.letter file located in the sender's home directory. If a sendmail server
is connecting with a sendmail client on another machine, then the user is
presumed to have become detached from the transaction, and so the message
is mailed back to them.
163
TCP/IP sendmail administration
Editing the message header
A certain amount of editing occurs automatically to the message header.
Header lines can be inserted under control of the configuration file. Some
lines can be merged. For example, a HFrom:" line and a HFull-name:" line can
be merged under certain circumstances.
Aliasing, forwarding and including mail
The sendmail program reroutes mail in any of the following three ways:
• by aliasing
• by forwarding
• by inclusion
Aliasing applies across the entire system. Forwarding allows all users to
reroute incoming mail destined for their accounts. Inclusion directs sendmail
to read a file for a list of addresses. Forwarding is normally used in conjunction with aliasing. Each of these methods is described in more detail in the
next three sections.
Aliasing
Aliasing matches names to address lists using a system-wide file. This file is
indexed to speed access. Only names that parse as local are allowed as
aliases. This guarantees a unique key. The alias file is usually configured to
be /usr/lib/aliases. This file is not in the same format as the alias file
/usr/lib/mail/aliases. The identity of the alias file is configured through the
sendmail.cf file.
Forwarding
After aliasing, recipients that are local and valid are checked for the existence
of a .forward file in their home directory. If one exists, the message is not sent
to that user, but rather to the list of users in that file. Often, this list contains a
single address, and is used only for network mail forwarding.
Forwarding also permits a user to specify a private incoming mailer. For
example, this forwarding uses a different incoming mailer:
I
I /usr/local/newmail myname
l
Including
The syntax for including a file is:
: include: pathname
An address of this form reads the file specified by pathname and sends to all
users listed in that file.
164
TCP/IP Users and Administrator's Guide
Configuring sendmail
The intention is not to support direct use of this feature, but rather to use this
as a subset of aliasing. In the following example, the form of the alias used is
a method of letting a project maintain a mailing list without interaction with
the system administration, even if the alias file is protected.
project: :include:/usr/project/userlist
It is not necessary to rebuild the index on the alias database when a list of this
type is changed. All that is needed is to edit the include file to reflect the
changes. In this example, the include file is /usr/project/userlist.
Queued messages
If the mailer returns a temporary failure exit status, the message is queued.
A control file describes the recipients to be sent to and various other parameters. This control file is formatted as a series of lines, each describing a sender,
a recipient, the time of submission, or some other significant parameter of the
message. The header of the message is stored in the control file, so that the
associated data file in the queue is just the temporary file that was originally
collected.
Configuring sendmail
There are three basic steps to installing sendmail. They are:
• installing the software, as described in the
sea TCPjIP Release and Installa-
tion Notes
• running mkdev sendmail-init to create the sendmail configuration file
• editing the sendmail configuration file to fine-tune sendmail operation
Because the basic configuration file is adequate for most sites, the third step is
often unnecessary.
The configuration file is read by sendmail reads when the program starts.
This file describes the mailers that sendmail knows about, how to parse
addresses, how to rewrite the message header, and the settings of various
options.
Configuring a standard installation
To use the sendmail mail system, you must first run mkdev sendmail-init,
which initializes sendmail and configures it by invoking mkdev cf. After first
initializing sendmail, you can reconfigure it at any time by running mkdev d.
165
TCPIIP sendmail administration
The mkdev cf script supports both uucp and Internet style addressing. The
uucp configuration allows a network administrator to designate a machine on
the network as the UUCP Gateway Machine, which will process all UUCP
requests for the net or subnet.
To configure a standard installation with mkdev sendmail-init:
1. Type mkdev sendmail-init at the command line. The message Saving the
following files: appears, followed by a list of files and this message: The
mail system will now use sendmail for delivering messages.
The mkdev sendmail-init command installs and configures sendmail.
The mkdev cf command reconfigures sendmail.
2. A list of files is displayed, along with the message: Press (Return) to
continue.
3. A menu appears. You must go through the various options of the menu in
sequence.
4. The first menu option is to edit UUCP connections. Default values can be
taken from the system, but you need to know if your machine is a UUCP
gateway or not.
5. The second menu option is to edit the domain name. The default domain
name is taken from the hostname utility; otherwise, you can specify a
domain name.
6. The third menu option is to edit alternate host names. This menu selection is optiona1.
7. The fourth menu option is to edit network configuration information. The
default answers are all "nd' for the questions displayed in this option.
Change the answers if necessary. If your machine is a UUCP mail gateway,
then answer "yes" to the question Is there a uUCP gateway?
8. The fifth menu option is simply a display that allows you to review your
answers from the preceding options. If necessary, go back and correct any
errors at this point by returning to the earlier option. This menu selection
is optiona1.
9. The sixth menu option generates the new sendmail.cf file. A display of
your selections is presented first, then you can generate the new file.
You are prompted with this message: Do you wish to change anything?
[y In] The old sendmail.cf file is saved as /usr/lib/custom/save/sendmail.cf.
10. The seventh menu option lets you quit the sendmail configuration menu.
166
TCP/IP Users and Administrator's Guide
Configuring sendmail
Configuring a non-standard installation
H the default configuration performed by mkdev sendmail-init is not adequate for your system, you will need to edit the sendmail configuration file,
sendmail.cf, then run mkdev cf to effect the changes you made. This section
describes the configuration file in detail, including hints on how to write one
of your own if you have to.
There is one point that should be made clear immediately: the syntax of the
configuration file is designed to be reasonably easy to parse, because this is
done every time sendmail starts up. As a result, the configuration file is not
particularly easy for a human to read or write.
An overview of the configuration file is given first, followed by details of the
semantics.
The syntax
The configuration file is organized as a series of lines, each of which begins
with a single character defining the semantics for the rest of the line. Lines
beginning with a space or a tab are continuation lines (although the semantics
are not well defined in many places). Blank lines and lines beginning with a
number sign # are comments.
1/
1/
R and S - rewriting rules
The core of address parsing is the rewriting rules. These are an ordered production system. The sendmail command scans through the set of rewriting
rules looking for a match on the left-hand side (lhs) of the rule. When a rule
matches, the address is replaced by the right-hand side (rhs) of the rule.
There are several sets of rewriting rules. Some of the rewriting sets are used
internally and must have specific semantics. Other rewriting sets do not have
specifically assigned semantics, and may be referenced by the mailer
definitions or by other rewriting sets.
The syntax of these two commands is:
Sn
Sets the current ruleset being collected to n. H you begin
a ruleset more than once, it deletes the old definition.
Rlhs rhs comments The Ihs is a pattern that is applied to the input. H it
matches, the input is rewritten to the rhs. The comments
are ignored. The fields must be separated by at least one
tab character; there may be embedded spaces in the
fields.
167
TCP/IP sendmail administration
D - define macro
Macros are named with a single character. These can be selected from the
entire ASCII set, but user-defined macros should be selected from the set of
uppercase letters only. Lowercase letters and special symbols are used internally.
The syntax for macro definitions is:
Dxval
Here x is the name of the macro and val is the value it should have. Macros
can be interpolated in most places using the escape sequence $x.
C and F - define classes
Classes of words may be defined to match on the left-hand side of rewriting
rules. For example, a class of all local names for this site might be created so
that attempts to send to oneself can be eliminated. These can either be
defined directly in the configuration file or read in from another file. Classes
may be given names from the set of uppercase letters. Lowercase letters and
special characters are reserved for system use.
The syntax is:
Ce word1 word2 ...
Fe file
The first form defines the class e to match any of the named words. It is permissible to split them among multiple lines, for example:
CHmonet ucbmonet
This example is equivalent to the following:
CHmonet
CHucbmonet
The second form reads th~ elements of the class e from the named file.
define mailer
Programs and interfaces to mailers are defined in this line. The format is:
Mname, {field=value }*
Here name is the name of the mailer (used internally only) and the
"field=name' pairs define attributes of the mailer. Fields are:
Path
pathname of the mailer
Flags
special flags for this mailer
Sender
rewriting set for sender addresses
Recipient
rewriting set for recipient addresses
Argv
argument vector to pass to this mailer
Eol
end-of-line string for this·mailer
Maxsize
The maximum message length for this mailer
Only the first character of the field name is checked.
M -
168
TCP/IP Users and Administrator's Guide
Configuring sendmail
H - define header
The format of the header lines that sendmail inserts into the message is
defined by the H line. The syntax of this line is:
H[?mflags?]hname: htemplate
Continuation lines in this specification are reflected directly into the outgoing
message. The htemplate is macro-expanded before insertion into the message. If the mflags (surrounded by question marks) are specified, at least one
of the specified flags must be stated in the mailer definition for this header to
be automatically output. If one of these headers is in the input, it is reflected
to the output, regardless of these flags.
Some headers have special semantics, described in the following sections.
o - set option
There are a number of "random" options that can be set from a configuration
file. Options are represented by single characters. The syntax of this line is:
00 value
This sets option 0 to be value. Depending on the option, value can be a string,
an integer, a Boolean (with legal values lit"~, "T", "f", or "F"; the default is
TRUE), or a time interval.
define trusted users
Trusted users are those who are permitted to override the sender address
using the -f flag. These typically are root, uucp, and network, but in some cases
it may be convenient to extend this list to include other users, perhaps to support a separate UUCP login for each host. The syntax of this line is:
Tuserl user2 ...
There may be more than one of these lines.
T -
precedence definitions
Values for the "Precedence:" field may be defined using the P control line. The
syntax of this field is:
Pname=num
When the name is found in a "Precedence:" field, the message class is set to
num. Higher numbers mean higher precedence. Numbers below zero have
the special property that error messages cannot be returned. The default precedence is zero. For example, our list of precedences is:
Pfirst-class=O
Pspecial-delivery=100
Pjunk=-lOO
P-
169
TCPIIP sendmail administration
The semantics
This section describes the semantics of the configuration file.
Special macros, conditionals
Macros are interpolated using the construct $x, where x is the name of the
macro to be interpolated. In particular, lowercase letters are reserved to have
special semantics, used to pass information in or out of sendmail; some special characters are reserved to provide conditionals; and so on.
Conditionals can be specified using the syntax:
$?x tutl $1 text2 $.
This interpolates textl if the macro $x is set, and text2 otherwise. The "else"
($1) clause can be omitted.
The following macros must be defined to transmit information into sendmail:
e SMTP entry message
Hofficial" domain name for this site
j
I
format of the UNIX system from line
n name of the daemon (for error messages)
o set of "operators" in addresses
q default format of sender address
The $e macro is printed out when SMTP starts up. The first word must be the
$j macro. The $j macro should be in RFC821 format. The $1 and $n macros
can be considered constants, except under terribly unusual circumstances.
The $0 macro consists of a list of characters that are considered tokens and
that separate tokens when parsing. For example, if @" were in the $0 macro,
then the input a@b would be scanned as three tokens: "a", H@", and ~".
Finally, the $q macro specifies how an address should appear in a message
when it is defaulted. For example, on our system, these definitions are:
H
De$j Sendmail $v ready at $b
DnMAILER-DAEMON
D1From $g $d
Do. :%@!"=/
Dq$g$?x ($x)$.
Dj$H.$D
An acceptable alternative for the $q macro is $?x$x $.<$g>. These correspond
to the following two formats:
eric@Ocelot (Eric Allman)
Eric Allman
170
TCPIIP Users and Administrator's Guide
Configuring sendmail
Some macros are defined by sendmail for interpolation into argv's for mailers
or for other contexts. These macros are:
a origination date in Arpanet format
b current date in Arpanet format
c hop count
d date in UNIX (ctime) format
f
sender (from) address
g sender address relative to the recipient
h recipient host
i
queueid
p sendmail's pid
r
protocol used
s senders host name
t
numeric representation of the current time
u recipient user
v version number of sendmail
w hostname of this site
x full name of the sender
z home directory of the recipient
There are three types of dates that can be used. The $a and $b macros are in
Arpanet format; $a is the time as extracted from the "Date:" line of the message (if there was one), and $b is the current date and time (used for postmarks). If no "Date:" line is found in the incoming message, $a is set to the
current time also. The $d macro is equivalent to the $a macro in UNIX system
(ctime) format.
The $f macro is the ID of the sender as originally determined; when you are
mailing to a specific host, the $g macro is set to the address of the sender relative to the recipient. For example, if you send to bollard@matisse from the machine ucbarpa, the $f macro is "eric" and the $g macro is "eriC@Ucbarpa."
The $x macro is set to the full name of the sender. This can be determined in
several ways. It can be passed as a flag to sendmail. The second choice is the
value of the "Full-name:" line in the header if it exists, and the third choice is
the comment field of a "From:" line. If all of these fail, and if the message is
being originated locally, the full name is looked up in the /etc/passwd file.
When sending, the $h, $u, and $z macros are set to the host, user, and home
directories (if local) of the recipient. The first two are set from the $@ and $:
parts of the rewriting rules, respectively.
The $p and $t macros create unique strings (for example, for the "MessageId:" field). The $i macro is set to the queue ID on this host; if put into the
timestamp line, it can be extremely useful for tracking messages. The $v
macro is set to be the version number of sendmail; this is normally put in
171
rep/IP sendmail administration
timestamps and has proved extremely useful for debugging. The $w macro is
set to the name of this host, if it can be determined. The $c field is set to the
"hop count," that is, the number of times this message has been processed.
This can be determined by the -h flag on the command line or by counting the
timestamps ~ the message.
The $r and $s fields are set to the protocol used to communicate with sendmail and the sending hostname; these are not supported in the current version.
Special classes
Set the class $=w to be the set of all names by which this host is known. This
can be used to delete local hostnames.
The left-hand side
The left-hand side of rewriting rules contains a pattern. Normal words are
simply matched directly. Metasyntax is introduced using a dollar sign. The
metasymbols are:
$* match zero or more tokens
$+ match one or more tokens
$- match exactly one token
$=x match any token in class x
$-x match any token not in class x
If any of these match, they are assigned to the symbol $n for replacement on
the right-hand side, where n is the index in the LHS. For example:
$-:$+
Suppose the LHS is applied to the following input:
UCBARPA:eric
The rule matches, and the values passed to the RHS are:
$1 UCBARPA
$2 eric
The right-hand side
When the left-hand side of a rewriting rule matches, the input is deleted and
replaced by the right-hand side. Tokens are copied directly from the RHS,
unless they begin with a dollar sign. Metasymbols are:
$n
$[name$]
$>n
$#mailer
$@host
$:user
172
substitutes indefinite token n from LHS
canonicalizes name
calls ruleset n
resolves to mailer
specifies host
specifies user
TCPjIP Users and Administrator's Guide
Configuring sendmail
The $n syntax substitutes the corresponding value from a $+, $-, $., $=, or $match on the LHS. It can be used anywhere.
A host name enclosed between $[ and $] is looked up using the gethostent(3)
routines and replaced by the canonical name. For example, $[[128.32.130.2]$]
would become vangogh.berkeley.edu, and $[csam$] would become lblcsam.arpa.
The $>n syntax causes the remainder of the line to be substituted as usual and
then passed as the argument to ruleset n. The final value of ruleset n then
becomes the substitution for this rule.
The $# syntax should only be used in ruleset zero. It causes evaluation of the
ruleset to terminate immediately, and it signals to sendmail that the address
has completely resolved. The complete syntax is:
$#mailer$@host$:user
This specifies the {mailer, host, user} 3-tuple necessary to direct the mailer. If
the mailer is local, the host part can be omitted. The mailer and host must be
a single word, but the user can be multi-part.
A RHS can also be preceded by a $@ or a $: to control evaluation. A $@ prefix
causes the ruleset to return with the remainder of the RHS as the value. A $:
prefix causes the rule to terminate immediately, but the ruleset to continue.
This can avoid continued application of a rule. The prefix is stripped before
continuing.
The $@ and $: prefixes can precede a $> specification. For example, the form:
R$+
$:$>7$1
matches anything, passes that to ruleset seven, and continues; the $: is necessary to avoid an infinite loop.
Substitution occurs in the order described; that is, parameters from the LHS
are substituted, hostnames are canonicalized, Hsubroutines" are called and,
finally, $#, $@, and $: are processed.
173
TCPIIP sendmail administration
Semantics of rewriting rule sets
There are five rewriting sets that have specific semantics. These are related as
follows:
msg
Figure 14-1 Rewriting set semantics
D - sender domain addition
s - mailer-specific sender rewriting
R - mailer-specific recipient rewriting
Ruleset three should tum the address into Ncanonical form." This form should
have the basic syntax:
local-part@host-domain-spec
If no "@" sign is specified, then the host-domain-spec can be appended from
the sender address (if the C flag is set in the mailer definition corresponding to
the sending mailer). Ruleset three is applied by sendmail before doing anything with any address.
Ruleset zero is applied after ruleset three to addresses that are actually going
to specify recipients. It must resolve to a {mailer, host, user} triple. The
mailer must be defined in the mailer definitions from the configuration file.
The host is defined into the $h macro for use in the argv expansion of the
specified mailer.
Rulesets one and two are applied to all sender and recipient addresses,
respectively. They are applied before any specification in the mailer
definition. They must never resolve.
Ruleset four is applied to all addresses in the message. It is typically used to
translate internal to external form.
Mailer flags
There are several flags that can be associated with each mailer, each identified
by a letter of the alphabet. Many of them are assigned semantics internally.
Any other flags can freely assign headers conditionally to messages destined
for particular mailers.
174
TCP/IP Users and Administrator's Guide
Configuring sendmail
The AIerror' mailer
The mailer with the special name "errorr can generate a user error. The
(optional) host field is a numeric exit status to be returned, and the user field
is a message to be printed. For example:
$#error$:Host unknown in this domain
The entry on the RHS of a rule causes the specified error to be generated if the
LHS matches. This mailer is only functional in ruleset zero.
Building a configuration file from scratch
Building a configuration file from scratch is an extremely difficult job. Fortunately, it is almost never necessary to do so; nearly every situation that may
come up may be resolved by changing an existing table. In any case, it is critical that you understand what you are trying to do and come up with a philosophy for the configuration table. This section is intended to explain the real
purpose of a configuration table and to give you some ideas as to what your
philosophy might be.
Purpose of the configuration table
The configuration table has three major purposes. The first and simplest is to
set up the environment for sendmail. This involves setting the options,
defining a few critical macros, and so on. Because these are described in other
sections, we will not go into more detail here.
The second purpose is to rewrite addresses in the message. This should typically be done in two phases. The first phase maps addresses in any format
into a canonical form. This should be done in ruleset three. The second phase
maps this canonical form into the syntax appropriate for the receiving mailer.
The sendmail program performs this second phase in the following three subphases: Rulesets one and two are applied to all sender and recipient
addresses, respectively. After this, you can specify per-mailer rulesets for
both sender and recipient addresses. This allows mailer-specific customization. Finally, ruleset four is applied to do any default conversion to external
form.
The third purpose of the configuration table is to map addresses into the
actual set of instructions necessary to get the message delivered. Ruleset zero
must resolve to the internal form, which is in tum used as a pointer to a
mailer descriptor. This describes the interface requirements of the mailer.
Relevant issues
The canonical form you use should almost certainly be as specified in the
Arpanet standards documents RFC819 and RFC822. RFC822 describes the format of the mail message itself. The sendmail program follows this RFC
175
TCP/IP sendmail administration
closely, to the extent that many of the standards described in this document
cannot be changed without changing the code. In particular, the following
characters have special interpretations:
<>()"\
Any attempt to use these characters for other than their RFC822 purpose in
addresses is probably doomed to disaster.
RFC819 describes the specifics of the domain-based addressing. This is
touched on in RFC822 as well. Essentially, each host is given a name that is a
right-to-Ieft dot-qualified pseudo-path from a distinguished root. The elements of the path need not be physical hosts; the domain is logical rather than
physical. For example, at Ocelot, one legal host might be "a.CC.Ocelot.EDU";
reading from right to left, "EDU" is a top level domain comprising educational
institutions, "Ocelot" is a logical domain name, "CC" represents the Computer
Center, (in this case a strictly logical entity), and "a" is a host in the Computer
Center.
How to proceed
Once you have decided on a philosophy, it is worth examining the available
configuration tables to decide whether any of them are close enough for you
to use major parts of them as a basis for your configuration files. Even under
the worst of conditions, there should be a large amount of material you can
use.
The next step is to build ruleset three. This is the hardest part of the job.
Beware of doing too much to the address in this ruleset, because anything you
do reflects through to the message. In particular, stripping of local domains is
best deferred, as this can leave you with addresses with no domain specifications at all. Because sendmail likes to append the sending domain to
addresses with no domain, this can change the semantics of addresses. Also,
try to avoid fully qualifying domains in this ruleset. Although technically
legal, this can lead to unpleasantly and unnecessarily long addresses reflected
into messages. The Ocelot configuration files define ruleset nine to qualify
domain names and strip local domains. This is called from ruleset zero to get
all addresses into a cleaner form.
Once you have ruleset three finished, the other rulesets should be relatively
trivial. If you need hints, examine the supplied configuration tables.
Testing the rewriting rules: the -ht flag
When you build a configuration table, you can do a certain amount of testing
using the "test mode" of sendmail. For example, you could invoke sendmail
as:
sendmail -bt -Ctest.cf
176
TCPjIP Users and Administrator's Guide
Configuring sendmail
This reads the configuration file test.cf and enter test mode. In this mode, you
enter lines of the form:
rwset address
Here rwset is the rewriting set you want to use and address is an address to
which to apply the set. Test mode shows you the steps it takes as it proceeds,
finally showing you the address with which it ends up. You may use a
comma-separated list of rwsets for sequential application of rules to an input;
ruleset three is always applied first. For example:
1,21,4 monet:bollard
The first applies ruleset three to the input "monet:bollard." Ruleset one is then
applied to the output of ruleset three, followed similarly by ntlesets 21 and 4.
If you need more detail, you can also use the -d21 flag to turn on more debugging. For example:
sendmail -bt -d21.99
This turns on a huge amount of information. A single-word address probably
prints out several pages of information.
Building mailer descriptions
To add an outgoing mailer to your mail system, you must define the characteristics of the mailer.
Each mailer must have an internal name. This can be arbitrary, except that the
names "local" and "prog" must be defined.
The pathname of the mailer must be given in the P field. If this mailer should
be accessed via an IPC connection, use the string "[IPC)" instead.
The F field defines the mailer flags. You should specify an "f" or "r" flag to
pass the name of the sender as a -f or -r flag, respectively. These flags are only
passed if they were passed to sendmaiI, so that mailers that give errors under
some circumstances can be placated. If the mailer is not picky, you can just
specify "_f $g" in the argv template. If the mailer must be called as root, the S
flag should be given. This does not reset the user 10 before calling the mailer.
If this mailer is local (that is, it performs final delivery rather than another network hop), the I flag should be given. Quote characters (backslashes and"
marks) can be stripped from addresses if the s flag is specified. If this is not
given, they are passed through. If the mailer is capable of sending to more
than one user on the same host in a single transaction, the m flag should be
stated. If this flag is on, then the argv template containing $u is repeated for
each unique user on a given host. The e flag marks the mailer as being expensive, which causes sendmail to defer connection until a queue run.
177
rep/IP sendmail administration
An unusual case is the C flag. This flag applies to the mailer that the message
is received from, rather than the mailer being sent to; if set, the domain specification of the sender (that is, the @host.domain part) is saved and is
appended to any addresses in the message that do not already contain a
domain specification. For example:
From: eric@ucbarpa
To: wnj@monet, mckee
A message of this form is modified to:
From: eric@ucbarpa
To: wnj@monet, mckee@ucbarpa
This happens if and only if the C flag is defined in the mailer corresponding to
eriC@Ucbarpa.
The Sand R fields in the mailer description are per-mailer rewriting sets to be
applied to sender and recipient addresses, respectively. These are applied
after the sending domain is appended and the general rewriting sets (numbers
one and two) are applied, but before the output rewrite (ruleset four) is
applied. A typical use is to append the current domain to addresses that do
not already have a domain. For example:
From: eric
A header of this form might be changed to be:
From: eric@ucbarpa
Or to this form, depending on the domain it is being shipped into:
From: ucbvax!eric
These sets can also be used to do special-purpose output rewriting in cooperation with ruleset four.
The E field defines the string to use as an end-of-line indication. A string containing only newline is the default. The usual backslash escapes (\r, \n, \f,
\b) may be used.
Finally, an argv template is given as the A field. It may have embedded
spaces. If there is no argv with a $u macro in it, sendmail speaks SMTP to the
mailer. If the pathname for this mailer is [IPC], the argv should be:
IPC $h [ port ]
Here port is the optional port number to connect to.
For example:
Mlocal, P=/usr/bin/mail, F=lsDFMmnPS S=10, R=20, A=lmail $u
Mether, P=[IPC], F=meC, S=11, R=21, A=IPC $h, M=100000
These specifications specify a mailer to do local delivery and a mailer for Ethernet delivery. The first is called local; it is located in the file /bin/mail, takes a
178
TCP/IP Users and Administrator's Guide
Configuring sendmail
picky -r flag, and does local delivery; quotes should be stripped from
addresses, and multiple users can be delivered at once; ruleset 10 should be
applied to sender addresses in the message, and ruleset 20 should be applied
to recipient addresses. The argv to send to a message is the word -mail,- the
word --d,- and words containing the name of the receiving user. If a -r flag is
inserted, it is between the words mail and -d. The second mailer is called
ether; it should be connected via an !PC connection; it can handle multiple
users at once; connections should be deferred; and any domain from the
sender address should be appended to any receiver name without a domain.
Sender addresses should be processed by ruleset 11 and recipient addresses
by ruleset 21. There is a l00,OOO-byte limit on messages passed through this
mailer.
Configuration options
The following options can be set using the -0 flag on the command line or the
o line in the configuration file. Many of them cannot be specified unless the
invoking user is trusted.
Afile
Use the named file as the alias file. If no file is specified, use
aliases in the current directory.
aN
If set, wait up to N minutes for an @:@ entry to exist in the alias
database before starting up. If it does not appear in N minutes,
rebuild the database (if the D option is also set) or issue a warning.
Bc
Set the blank substitution character to c. Unquoted spaces in
addresses are replaced by this character.
c
If an outgoing mailer is marked as being expensive, do not connect
immediately. This requires that queueing be compiled in, because
it depends on a queue-run process to actually send the mail.
dx
Deliver in mode x. Legal modes are:
i Deliver interactively (synchronously).
b Deliver in background (asynchronously).
q Just queue the message (deliver during queue run).
D
If set, rebuild the alias database if necessary and possible. If this
option is not set, sendmaiI will never rebuild the alias database
unless explicitly requested using -bi.
ex
Dispose of errors using mode x. The values for x are:
p Print error messages (default).
q No messages, just give exit status.
m Mail back errors.
w Write back errors (mail if user not logged in).
eMail back errors and give zero exit status always.
179
TCP/IP sendmail administration
Fn
This is the temporary file mode, in octal. 644 and 600 are good
choices.
f
Save UNIX-style "FroIIf lines at the front of headers. Normally,
they are assumed redundant and discarded.
gn
Set the default group ID for mailers to run into n.
Hfile
Specify the help file for SMTP.
I
Use the domain name server, named.
i
Ignore dots in incoming messages.
Ln
Set the default log level to n.
Mx value Set the macro x to value. This is intended only for use from the
command line.
m
Send to me, too, even if I am in an alias expansion.
Nnetname The name of the home network (ARPA is the default). The argument of an SMTP HELO command is checked against
hostname.netname, where hostname is requested from the kernel for
the current connection. If they do not match, Received: lines are
augmented by the name that is determined in this manner, so that
messages can be traced accurately.
180
o
Assume that the headers may be in old format; that is, spaces delimit names. This actually turns on an adaptive algorithm: if any
recipient address contains a comma, parentheses, or angle bracket,
it is assumed that commas already exist. If this flag is not on, only
commas delimit names. Headers are always output with commas
between the names.
Qdir
Use the named dir as the queue directory.
qfactor
Use factor as the multiplier in the map function to decide when
just to queue up jobs rather than run them. This value is divided
by the difference between the current load average and the load
average limit (x flag) to determine the maximum message priority
that is sent. Defaults to 10,000.
rtime
Timeout reads after time interval.
Sfile
Log statistics in the named file.
s
Be extra safe when running things, that is, always instantiate the
queue file, even if you are going to attempt immediate delivery.
The sendmail program always instantiates the queue file before
returning control to the client.
Ttime
Set the queue timeout to time. After this interval, messages that
have not been successfully sent is returned to the sender.
TCP/IP Users and Administrator's Guide
Running sendmail
tS,D
Set the local time zone name to S for standard time and D for daylight time. This is only used under version six.
un
Set the default user 10 for mailers to ft. Any mailer without the S
flag in the mailer definition runs as this user.
v
Run in verbose mode.
w
Allow wildcard MX records.
xLA
When the system-load average exceeds LA, just queue messages
(that is, do not try to send them).
XLA
When the system load average exceeds LA, refuse incoming SMTP
connections.
yfact
The indicated factor is added to the priority (thus lowering the
priority of the job) for each recipient, that is, this value penalizes
jobs with large numbers of recipients.
y
If set, deliver each job that is run from the queue in a separate process. Use this option if you are short of memory, because the
default tends to consume considerable amounts of memory while
the queue is being processed.
zfact
The indicated factor is multiplied by the message class (determined by the "Precedence:" field in the user header and the P lines
in the configuration file) and subtracted from the priority. Thus,
messages with a higher Priority is favored.
Zfact
The factor is added to the priority every time a job is processed.
Thus, each time a job is processed, its priority is decreased by the
indicated value. In most environments, this should be positive,
because hosts that are down are all too often down for a long time.
Running sendmail
The following sections illustrate the flags and options used when executing
sendmail, which is invoked from the /etc/tcp shell script at startup. The tcp
script is initialized by the mkdev sendmail-init and mkdev cf scripts, which
are described earlier in this chapter. Refer to tcp(ADMN) for more information
about /etc/tcp.
Command line flags
Arguments must be presented with flags before addresses. The flags are:
-f addr
The senders machine address is addr. This flag is ignored unless
the real user is listed as a "trusted user" or addr contains an exclamation point (because of certain restrictions in UUCP).
181
TCPIIP sendmail administration
-r addr
This flag is an obsolete form of -f.
-h cnt
This flag sets the "hop count" to cnt. This represents the number
of times this message has been processed by sendmail (to the
extent that it is supported by the underlying networks). cnt is
incremented during processing, and if it reaches .MAXHOP
(currently 30) sendmail throws away the message with an error.
-Fname
This flag sets the full name of this user to name.
·-n
Do not alias or forward.
-t
Read the header for To:, Cc:, and Bec: lines, and send to everyone
in those lists. The Bec: line is deleted before sending. Any
addresses in the argument vector is deleted from the send list.
-bx
Set operation mode to x. The operation modes are:
m Deliver mail (default).
a Run in ARPANET mode (see below).
s Speak SMTP on input side.
d Run as a daemon.
t
Run in test mode.
v Just verify addresses, do not collect or deliver.
i
Initialize the alias database.
p Print the mail queue.
z Freeze the configuration file.
The special processing for the ARPANET includes reading the
From: line from the header to find the sender, printing ARPANETstyle messages (preceded by three-digit reply codes for compatibility with the FrP protocol), and ending lines of error messages
with .
-qtime
Try to process the queued up mail. If the time is given, sendmail
runs through the queue at the specified interval to deliver queued
mail; otherwise, it only runs once.
-Cfile
Use a different configuration file. The sendmail program runs as
the invoking user (rather than root) when this flag is specified.
-dlevel
Set debugging level.
-ox value Set option x to the specified value. These options are described in
the next section.
There are a number of options that can be specified as primitive flags (provided for compatibility with delivermail). These are the e, i, m, and v
options. Also, the f option can be specified as the -s flag.
182
TCPIIP Users and Administrator's Guide
Running sendmail
Mailer flags
The following flags can be set in the mailer description.
f
The mailer wants a -f from flag, but only if this is a network forward operation (that is, the mailer gives an error if the executing
user does not have special permissiOns).
r
This is the same as f, but sends a -r flag.
S
Do not reset the user ID before calling the mailer. This would be
used in a secure environment where sendmail ran as root. This
could be used to avoid forged addresses. This flag is suppressed if
given from an unsafe environment (for example, a user's mail.cf
file).
n
Do not insert a UNIX-system-style From: line on the front of the
message.
I
This mailer is local (that is, final delivery is performed).
s
Strip quote characters off the address before calling the mailer.
m
This mailer can send to multiple users on the same host in one
transaction. When a $u macro occurs in the argv part of the mailer
definition, that field is repeated as necessary for all qualifying
users.
F
This mailer wants a From: header line.
D
This mailer wants a Date: header line.
M
This mailer wants a Message-Id: header line.
x
This mailer wants a Full-Name: header line.
P
This mailer wants a Return-Path: line.
u
Uppercase should be preserved in user names for this mailer.
h
Uppercase should be preserved in host names for this mailer.
A
This is an Arpanet-compatible mailer, and all appropriate modes
should be set.
U
This mailer wants UNIX-system-style From lines with the UUCPstyle Nremote from " on the end.
e
This mailer is expensive to connect to, so try to avoid connecting
normally. Any necessary connection occurs during a queue run.
X
This mailer wants to use the hidden dot algorithm as specified in
RFC821. Basically, any line beginning with a dot has an extra dot
prepended (to be stripped at the other end). This ensures that
lines in the message containing a dot does not terminate the message prematurely.
183
TCPIIP sendmail administration
L
Limit the line lengths as specified in RFC821.
P
Use the return-path in the SMTP -MAIL FROM:" command, rather
than just the return address. Although this is required in RFC821,
many hosts do not process return paths properly.
I
This mailer is speaking SMTP to another sendmail. As such, it can
use special protocol features. This option is not required (that is, if
this option is omitted, the transmission still operates successfully,
although perhaps not as efficiently as possible).
C
If mail is received from a mailer with this flag set, any addresses in
the header that do not have an at sign _ @" after being rewritten by
ruleset three has the @domain clause from the sender tacked on.
This allows mail with headers of the form to be rewritten automatically:
From: usera@hosta
To: userb@hostb, userc
. It becomes:
From: usera@hosta
To: userb@hostb, userc@hosta
E
Escape lines beginning with nprom" in the message with a">"
sign.
Arguments
Some important arguments of the sendmail program are described here.
Queue interoal
The amount of time between forking a process to run through the queue is
defined by the -q flag. If you run in mode f or a, this can be relatively large,
because it is only relevant when a host that was down comes back up. If you
run in q mode, it should be relatively short, because it defines the maximum
amount of time that a message may sit in the queue.
Daemon mode
If you allow incoming mail over an IPC connection, you should have a daemon running. This should be set by your /etc/rc file using the -bd flag. The
-bd flag and the -q flag may be combined in one call:
lusrllib/sendmail -bd -q3Om
184
TCP/IP Users and Administrator's Guide
Running sendmail
Forcing the queue
In some cases, you may find that the queue has gotten clogged for some reason. You can force a queue run using the -q flag (with no value). It is entertaining to use the -v flag (verbose) when this is done, to watch what happens:
lusrllib/sendmail -q -v
Debugging
There is a fairly large number of debug flags built into sendmail. Each debug
flag has a number and a level, where higher levels cause more information to
be printed out. The convention is that levels greater than nine are not
required. They print out so much information that you would not normally
want to see them, except for debugging that particular piece of code. Debug
flags are set using the -d option. The syntax is:
debug-flag:
-d debug-list
debug-list:
debug-option [ , debug-option]
debug-option: debug-range [ . debug-level]
debug-range: integer I integer - integer
debug-level: integer
The spaces are for reading ease only. For example:
-d12
Set flag 12 to level 1.
-d12.3
Set flag 12 to level 3.
-d3-17
Set flags 3 through 17 to level 1.
-d3-17.4
Set flags 3 through 17 to level 4.
Trying a different configuration file
An alternative configuration file can be specified using the -C flag. The following example uses the configuration file test.cf instead of the default
/usr/lib/sendmail.cf·
/usr/lib/sendmail -Ctest.cf
If the -C flag has no value, it defaults to sendmail.cf in the current directory.
Changing the values of options
Options can be overridden using the -0 flag. For example:
/usr/lib/sendmail -oT2m
This sets the T (timeout) option to two minutes for this run only.
Tuning
There are a number of configuration parameters you may want to change,
depending on the requirements of your site. Most of these are set using an
option in the configuration file. For example, the line "OT3d" sets option 7'
to the value "3d" (three days).
185
TCPIIP sendmail administration
Most of these options default appropriately for most sites. However, sites
having very high mail loads may find they need to tune them as appropriate
for their mail load. In particular, sites experiencing a large number of small
messages, many of which are delivered to many recipients, may find that they
need to adjust the parameters dealing with queue priorities.
Timeouts
All time intervals are set using a scaled syntax. For example, N1Om"
represents ten minutes, whereas N2h3Om" represents two-and-a-half hours.
The full set of scales is:
s
m
h
d
w
seconds
minutes
hours
days
weeks
Queue interval
The argument to the -q flag specifies how often a subdaemon runs the queue.
This is typically set to between fifteen minutes and one hour.
Read timeouts
It is possible to time out when reading the standard input or when reading
from a remote SMTP server. Technically, this is not acceptable within the published protocols. However, it might be appropriate to set it to something
large (such as an hour) in certain environments. This reduces the chance of
large numbers of idle daemons piling up on your system. This timeout is set
using the r option in the configuration file.
Message timeouts
After sitting in the queue for a few days, a message times out. This means that
if a message cannot be delivered for some reason, it is returned to the sender.
This ensures that at least the sender is aware that the message was not sent.
The timeout is typically set to three days. This timeout is set using the T
option in the configuration file.
The time of submission is set in the queue, rather than the amount of time left
until timeout. As a result, you can flush messages that have been hanging for
a short period by running the queue with a short message timeout. For example:
/usr/lib/sendmail -oTld -q
This runs the queue and flushes anything that is one day old.
186
TCP/IP Users and Administrator's Guide
Running sendmail
Forking during queue runs
When the Y option is set, sendmail forks before each individual message
while running the queue. This prevents sendmail from consuming large
amounts of memory, and so it may be useful in memory-poor environments.
However, if the Y option is not set, sendmail keeps track of hosts that are
down during a queue run, which can improve performance dramatically.
Queue priorities
Every message is assigned a priority when it is first instantiated, consisting of
the message size (in bytes) offset by the message class multiplied by the Mwork
class factor" and the number of recipients multiplied by the Mwork recipient
factor.N The priority plus the creation time of the message (in seconds since
January 1, 1970) are used to order the queue. Higher numbers for the priority
mean that the message is processed later, when running the queue.
The message size is included so that large messages are penalized relative to
small messages. The message class allows users to send high-priority messages by including a "Precedence:N field in their message; the value of this
field is looked up in the P lines of the configuration file. Because the number
of recipients affects the size of load a message presents to the system, this is
also included in the priority.
The recipient and class factors can be set in the configuration file by using the
y and z options, respectively. They default to 1000 (for the recipient factor)
and 1800 (for the class factor). The initial priority is:
'pri = size - (class * z) + (nrcpt * y)
(Remember, higher values for this parameter actually mean that the job is
treated with lower priority.)
The priority of a job can also be adjusted each time it is processed (that is,
each time an attempt is made to deliver it) using the Mwork time factor," set by
the Z option. This is added to the priority, so it normally decreases the precedence of the job, on the grounds that jobs that have failed many times tend
to fail again in the future.
Delivery mode
There are a number of delivery modes for sendmail, and they are set by the d
configuration option. These modes specify how quickly mail is delivered.
Legal modes are:
i
deliver interactively (synchronously)
b deliver in background (asynchronously)
q queue only (do not deliver>
There are tradeoffs. Mode Mi" passes the maximum amount of information to
the sender, but it is hardly ever necessary. Mode Me( puts the minimum load
187
TCPIIP sendmail administration
on your machine, but means that delivery may be delayed for up to the queue
interval. Mode 41' is probably a good compromise. However, this mode can
cause large numbers of processes if you have a mailer that takes a long time to
deliver a message.
File modes
There are several files involved with sendmail that can have a number of
modes. The modes depend on the functionality you want and the level of
security you require.
To suid or not to suid?
The sendmail program can safely be made setuid to root. At the point where
it is about to exec(S) a mailer, it checks to see if the user ID is zero. If so, it
resets the user ID and groupid to a default (set by the u and g options). (This
can be overridden by setting the S flag to the mailer for mailers that are
trusted and must be called as root.) However, this causes mail processing to
be accounted to root rather than to the user sending the mail.
Temporary file modes
The mode of all temporary files that sendmail creates is determined by the F
option. Reasonable values for this option are 0600 and 0644. If the more permissive mode is selected, it is not necessary to run sendmail as root at all
(even when running the queue).
Should the alias database be writable?
The database that sendmail actually uses is represented by two files. These
files are:
• aliases.dir
• aliases.pag
Both files are located in /usr/lib/mail. The mode on these files should match the
mode on /usr/lib/mail/aliases. If aliases is writable and the DBM files (aliases.dir
and aliases.pag) are not, users cannot reflect their desired changes through to
the actual database. However, if aliases is read-only and the DBM files are
writable, a slightly sophisticated user can arrange to steal mail anyway.
If your DBM files are not writable by the world or YOU;. do not have auto-
rebuild enabled (with the D option), then you must be careful to reconstruct
the alias database each time you change the text version via the command:
newaliases
If this step is ignored or forgotten, any intended changes are also ignored or
forgotten.
188
TCP/IP Users and Administrator's Guide
Administering sendmail
Administering sendmail
System administration with sendmail consists of monitoring the system log
file, managing the mail queue, maintaining the system alias file, and performing other related actions.
System log
The system log is entered in the file /usr/adm/syslog. Each line in the system
log consists of a timestamp, the name of the machine that generated it (for
logging from several machines over the network), the word sendmail," and a
message.
II
A large amount of information can be logged. The log is arranged as a succession of levels. At the lowest level, only extremely strange situations are
logged. At the highest level, even the most mundane and uninteresting
events are recorded for posterity. As a convention, log levels under 10 are
considered lIuseful"; log levels above 10 are usually for debugging purposes.
The mail queue
The mail queue should be processed transparently. However, you may find
that manual intervention is sometimes necessary. For example, if a major host
is down for a period of time the queue may become clogged. Although sendmail ought to recover gracefully when the host comes up, you may find performance unacceptably bad in the meantime.
The contents of the queue can be printed using the maiIq command (or by
specifying the -bp flag to sendmail):
mailq
This produces a listing of the queue identifiers, the size of the message, the
date the message entered the queue, and the sender and recipients.
Format of sendmail queue files
All queue files have the form x fAA99999, where AA99999 is the ID for this file
and x is a type. The types are:
d
data file. The message body (excluding the header) is kept in this
file.
I
lock file. If this file exists, the job is currently being processed, and a
queue run does not process the file. For that reason, an extraneous If
file can cause a job to seem to disappear. It will not even time out.
189
rep/IP sendmail administration
n
this file is created when an ID is being created. It is a separate file to
ensure that no mail can ever be destroyed due to a race condition. It
should exist for no more than a few milliseconds at any given time.
q
queue control file. This file contains the information necessary to
process the job.
t
temporary file. This is an image of the qf file when it is being rebuilt.
It should be renamed to a qf file very quickly.
x
transcript file, existing during the life of a session, showing everything that happens during that session
The qf file is structured as a series of lines, each beginning with a code letter.
The lines are as follows:
190
D
name of the data file. There can only be one of these lines.
H
header definition. There can be any number of these lines. The order
is important: it represents the order in the final message. This uses
the same syntax as header definitions in the configuration file.
R
recipient address. This is normally completely aliased, but is actually re-aliased when the job is processed. There is one line for each
recipient.
S
sender address. There can only be one of these lines.
E
error address. If any such lines exist, they represent the addresses
that should receive error messages.
T
job creation time. This computes how long a job remains in the
queue undelivered, before being returned to the sender.
P
current message priority. This orders the queue. Higher numbers
mean lower priorities. The priority changes as the message sits in
the queue. The initial priority depends on the message class and the
size of the message.
M
message. This line is printed by the mailq command, and is generally used to store status information. It can contain any text.
TCPIIP Users and Administrator's Guide
Administering sendmail
As an example, the following is a queue file sent to Nmckee@calder" and
IIwnj:"
DdfA13557
Seric
T404261372
P132
Rmckee@calder
Rwnj
H?D?date: 23-0ct-82 15:49:32-PDT (Sat)
H?F?from: eric (Eric Allman)
H?x?full-name: Eric Allman
Hsubject: this is an example message
Hmessage-id: <8209232249.13557@UCBARPA.BERKELEY.ARPA>
Hreceived: by UCBARPA.BERKELEY.ARPA (3.227 [10/22/82])
id A13557; 23-0ct-82 15:49:32-PDT (Sat)
HTo: mckee@calder, wnj
This shows the name of the data file, the person who sent the message, the
submission time (in seconds since January 1, 1970), the message priority, the
message class, the recipients, and the headers for the message.
Forcing the queue
The sendmail program should run the queue automatically at intervals. The
algorithm is to read and sort the queue, then to attempt to process all jobs in
order. When it attempts to run the job, sendmail first checks to see if the job
is locked. If so, it ignores the job.
There is no attempt to ensure that only one queue processor exists at any
time, because there is no guarantee that a job cannot take forever to process.
Dueto the locking algorithm, it is impossible for one job to freeze the queue.
However, an uncooperative recipient host or a program recipient that never
returns can accumulate many processes in your system. Unfortunately, there
is no way to resolve this without violating the protocol.
In some cases, you may find that if a major host goes down for a couple of
days, this can create a prohibitively large queue. This situation causes sendmail to spend an inordinate amount of time sorting the queue. This situation
can be fixed by moving the queue to a temporary place and creating a new
queue. The old queue can be run later, when the offending host returns to service.
To do this, it is acceptable to move the entire queue directory:
cd lusrlspool
mv mqueue omqueuej mkdir mqueuej chmod 777 mqueue
You should then kill the existing daemon (because it is still processing in the
old queue directory) and create a new daemon.
191
TCP/IP sendmail administration
To run the old mail queue, run the following command:
lusrllib/sendmail-oQ/usrlspoollomqueue -q
The -oQ flag specifies an alternate queue directory, and the -q flag says just to
run every job in the queue. Use the -v flag to view what is going on.
When the queue is finally emptied, you can remove the directory:
rmdir lusrlspoollomqueue
sendmail configuration file
Almost all configuration information for sendmail is read at runtime from the
ASCII file /usr/lib/sendmail.cf. This file has macro definitions encoded in it.
These define such details as the value of macros used internally, header
declarations, mailer definitions and address rewriting rules.
The sendmail configuration file is created as shown earlier in this chapter in
the section nConfiguring sendmail."
The header declarations tell sendmail the format of header lines that are processed specially. For example, any lines that are added or reformatted receive
special processing. The mailer definitions give information such as the location and characteristics of each mailer. The address rewriting rules enable
sendmail to be highly configurable and customizable, though this comes at
the cost of some complexity.
The alias database
The alias database exists in two forms. One is a text form, maintained in the
file /usr/libfmail/aliases. The aliases are of the form:
name: name1, name2, ...
Only local names can be aliased. For example:
eric@mit-xx: eric@berkeley.EDU
This does not have the desired effect. Aliases can be continued by starting any
continuation line with a space or a tab. Blank lines and lines beginning with a
number sign n #" are comments.
The second form is processed by the dbm(S) library. This form is in the files
/usr/lib/mail/aliases.dir and /usr/lib/mail/aliases.pag. This is the form that sendmail actually uses to resolve aliases. This technique improves performance.
192
TCP/IP Users and Administrator's Guide
Administering sendmail
Rebuilding the alias database
The DBM version of the database can be rebuilt explicitly by executing the
command:
newaliases
This is equivalent to giving sendmail the -bi flag:
lusrnib/sendmail-bi
H the "0" option is specified in the configuration, sendmail rebuilds the alias
database automatically, if possible, when it is out of date. It does this under
either or both of the following conditions:
• The DBM version of the database is mode 666.
• sendmail is running setuid to root.
Auto-rebuild can be dangerous on heavily loaded machines with large alias
files; if it might take more than five minutes to rebuild the database, there is a
chance that several processes start the rebuild process simultaneously.
Potential alias database problems
There are a number of problems that can occur with the alias database. They
all result when a sendmail process accesses the DBM version while it is only
partially built. This can happen under two circumstances: either one process
accesses the database while another process is rebuilding it, or the process
rebuilding the database dies (due to being killed or a system crash) before
completing the rebuild.
The sendmail program includes two techniques to try to relieve these problems. First, it ignores interrupts while rebuilding the database; this avoids the
problem of someone aborting the process and leaving a partially rebuilt database. Second, at the end of the rebuild it adds an alias of the form:
@: @
(Note that this is not normally legal.) Before sendmail accesses the database,
it checks to ensure that this entry exists. The sendmail program waits for this
entry to appear, at which point it forces a rebuild itself.
List owners
If an error occurs on sending to a certain address, say "x," sendmaillooks for
an alias of the form "owner-X" to receive the errors. This is typically useful for
193
TCPIIP sendmail administration
a mailing list where the submitter of the list has no control over the maintenance of the list itself; in this case the list maintainer would be the owner of
the list. For example:
unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser,
sam@matisse
owner-unix-wizards: eric@ucbarpa
This would cause "eriC@Ucbarpaw to get the error that occurs when someone
sends to unix-wizards, due to the inclusion of "nosuchuser" on the list.
Per-user forwarding (.forward files)
As an alternative to the alias database, any user can put a file with the name
.forward in his or her home directory. If this file exists, sendmail redirects mail
for that user to the list of addresses listed in the .forward file. For example,
suppose the home directory for user mckee has a .forward file with contents:
mckee@ernie
kirk@calder
Then any mail arriving for mckee is redirected to the specified accounts.
Special· header lines
Several header lines have special interpretations defined by the configuration
file. Others have interpretations built into sendmail that cannot be changed
without changing the code. These built-ins are described here.
Retum-receipt-to:
If this header is sent, a message is sent to any specified addresses when the
final delivery is completed, that is, when successfully delivered to a mailer
with the I flag (local delivery) set in the mailer descriptor.
.Errors-to:
If errors occur anywhere during processing, this header causes error messages
to go to the listed addresses rather than to the sender. This is intended for
mailing lists.
Apparently-to:
If a message comes in with no recipients listed in the message (in a To:, Cc:, or
Bec: line), then sendmail adds an "Apparently-To:w header line for any recipients it is aware of. This is not put in as a standard recipient line to warn any
recipients that the list is not complete.
194
TCP/IP User's and Administrator's Guide
Administering sendmail
Summary of support files
This is a summary of the support files that sendmail creates or generates.
/usr/lib/sendmail
/usr/bin/newalUzses
binary of sendmail
/usr/bin/mailq
prints a listing of the mail queue. This program is
equivalent to using the -bp flag to sendmail.
link to /usr/lib/sendmail; causes the alias database to be
rebuilt. Running this program is completely
equivalent to giving sendmail the -bi flag.
configuration file, in textual form
/usr/lib/sendmail.cf
configuration file represented as a memory image
/usr/lib/sendmail·fc
SMTP help file
/usr/lib/sendmail.hf
statistics file; need not be present
/usr/lib/sendmail.st
/usr/lib/mail/alUzses
textual version of the alias file
/usr/lib/mail/alUzses.1 pag,dir}
alias file in dbm(S) format
/usr/spool/mqueue
directory in which the mail queue and temporary files
reside
/usr/spool/mqueue/qf
/usr/spool/mqueue/df
/usr/spool/mqueue/lf
/usr/spool/mqueue/tf
control (queue) files for messages
/usr/spool/mqueue/nf
/usr/spool/mqueue/xf
data files
lock files
temporary versions of the qf files, used during queuefile rebuild
file used when creating a unique ID
transcript of the current session
195
rep/IP sendmail administration
More sendmail infonnation
The following manual pages provide additional information about sendmail:
Manual page
Description
aliases(SFF)
aliases file for sendmail
Imail(ADMN)
handle local mail delivery from sendmail
mailaddr(ADMN) mail addressing description
mconned(ADMN) connect to SMTP mail server socket
rmail(ADMN)
handle remote mail received by UUCP
sendmail(ADMN) sendmail command information
sendmail.c! Idev/rdO"
If the files are local, and the device is remote, you may use one of the following commands:
tar cvf - lusr I rcmd machinename dd of=/dev/rdO
find lusr -cpio -print I cpio -oc I rcmd machinename dd of=/dev/rdO
199
Helpful hints
If the files are remote, and the device is local, you may use one of the follow-
ing commands:
remd machinename "tar evf - lusi' > IdevlrdO
remd machinename "find lusr -epio -print I cpio
-Oc' > Idev/reto
Restoring a backup
If you want to restore a backup where the command is issued locally, but the
files and the device are remote, you may use one of the following commands.
Note the changes to the tar, cpio, and dd commands.
rcmd machinename tar xvf Idev/rdO
remd machinename "epio -idev < Idev/rdO"
If the files are local, and the device is remote, you may use one of the following commands.
rcmd machinename dd if=/dev/rdO I tar xvf rcmd machinename dd if=/dev/rdO I cpio -idev
If the files are remote, and the device is local, you may use one of the following commands:
dd if=/dev/rdO I rcmd machinename tar xvI dd if=/dev/rdO I rcmd machinename epio -icdv
See the tar, cpio, and rcmd(C) manual pages for more information.
Differences in sendmail implementations
Q: What are the differences between the /usr/lib/sendmail provided with seQ
UNIX System V/386 Release 3.2 and the /usr/lib/sendmail provided with
seQ TCP/IP?
A: The /usr/lib/sendmail program provided with seQ UNIX System V/386
Release 3.2 is a front end to the MMDF mail system. It is provided for those
third party programs that normally use the Berkeley sendmail program as
their mail agent.
The /usr/lib/sendmail provided in seQ TCP lIP, and installed with mkdev
sendmail-init, is the traditional Berkeley sendmail program. This sendmail, if installed with mkdev sendmail-init, completely replaces the
MMDF mail system. As such, they are mutually exclusive. However, it
must be noted that it is not absolutely necessary to use sendmail under
seQ TCP lIP, as seQ TCP /lP and MMDF are compatible. Berkeley sendmail
is provided for those more familiar with a traditional mailer.
200
TCP/IP Users and Administrator's Guide
Setting up user equivalence
Setting up user equivalence
Q: How do I set up user equivalence between two systems running seQ
TCP/IP?
A: User equivalence is a state in which a particular user or group of users
may access the accounts of another user or group of users, where this
second group is usually on a different machine. This access is done
without the use of any authentication, such as passwords.
For example, if user alpha on machine m1 is equivalent to users alpha and
beta on machine m2, then the following commands work without specifying any passwords from alpha's account on m1. For example:
rlogin m2
User alpha logs into m2.
rlogin m2 -I beta
User beta logs into m2.
remd m2 who
User alpha executes the who command on machine m2.
remd m2 -I beta who
User beta executes the who command on machine m2.
Also, note the following:
rep filename m2:filename2
This command requires user equivalence of user alpha on m1 for user alpha
onm2.
rep filename beta@m2:filename2
This command requires user equivalence of user alpha on m1 for user beta
onm2.
There are two files that control this access. The first is .rhosts in the home
directory of the affected user. The format of the .rhosts file is:
machine username
The username is optional.
The other file is /etc/hosts.equiv. The format is identical to that of the .rhosts
file, but usually only the machine portion is used.
201
Helpful hints
For example, suppose user alpha on machine ml wants to allow user alpha
on machine m2 to access her account without the use of a password. User
alpha, on m1, would create a file called .rhosts in her home directory with
the line:
m2 alpha
In addition, if alpha wanted to allow user delta on m2 and gamma on m3 to
access her account without a password, the .rhosts file in alpha's home
directory would read:
m2 alpha
m2 delta
m3 gamma
If alpha additionally wanted all users on machine m4 to be able to access
her account without a password, the .rhosts file would read:
m2 alpha
m2 delta
m3 gamma
m4
Suppose that the system administrator of machine m1 wanted to allow all
users on machine m5 to access their own accounts on machine m1. This
would be accomplished by adding the following line to the /etc/hosts.equiv
file on m1:
m5
Thus user beta on machine m5 could access user beta on m1 without the
need for a password.
Note that /etc/hosts.equiv does not work for the user root. If you wish to
access the root user on m1 from m2 without a password, you must set up a
.rhosts file in the / directory on m1, with:
m2 root
Or, if you want a user other than root on m2 to access root on machine ml
without a password, use:
m2 user
Note that users on the machines with their own .rhosts file must have a
password assigned. Also, if the system administrator has configured a
/etc/hosts.equiv file, the users on that system must have a password
assigned to make use of the /etc/hosts.equiv file. Finally, the .rhosts file in a
particular user's home directory must be owned by that user.
202
TCP/IP Users and Administrator's Guide
Chapter 16
Bibliography
The following books provide additional useful information about TCP lIP that
is beyond the scope of this Administrator's Guide.
• Comer, Douglas. Internetworking With TCP/IP Volume I: Principles, Protocols,
and Architecture, 2nd edition. Prentice-Hall, Inc.: Englewood Cliffs, 1991
A very accessible and more complete introduction to all aspects of TCP lIP
and internetworking. This book includes information on: Internet Protocol
(IP); User Datagram Protocol (UDP); Transmission Control Protocol (TCP);
error and control Messages (ICMP); internet, subnet, and physical addressing; routing and gateways (EGP, RIP, OSPF, HELLO); client-server architecture; Bootstrap Protocol (BOOTP); network domains; Berkeley sockets; network applications; and internet management.
• Davidson, John. An Introduction to TCP/IP. Sprinter-Verlag: New York, 1988
A brief overview of TCP lIP, organized by the seven layers of the OSI reference model. This book provides a good basic working knowledge of
TCP lIP and how different parts of the protocol interact.
• Rose, Marshall. The Simple Book. Prentice-Hall: Englewood Cliffs, 1990.
A thorough background reference on the Simple Network Management
Protocol (SNMP). This book includes: definitions of the protocol, Structure
of Management Information (SMI), and Management Information Base
(MIB); examples of agent and management station configuration; and
descriptions of common troubleshooting tasks you can accomplish using
SNMP.
• Santifaller, Michael. TCP/IP and NFS: Internetworking in a UNIX Environment.
Addison-Wesley (Deutschland) GmbH, 1991
203
Bibliography
Another overview of TCP lIP including protocol descriptions and common
network administration tasks. Noteworthy in that it discusses NFS and its
interaction with TCP lIP.
• Stevens, W. Richard. UNIX Network Programming. Prentice-Hall, Inc.: Englewood Cliffs 1991
An excellent reference for network programming. This book includes information on: programming in sockets and TLI; how to program under the
UNIX Operating System; descriptions of how daemon processes work (fork
and exec); and how the TCP lIP protocols are implemented. Also included
are some 15,000 lines of public domain source code, with examples of
streams pipes, rlogind, rcmd, lpd, tftp, rexec, and rmt. This book covers
issues not addressed in IIInternetworking with TCP/IP Volume 1.11
204
TCP/IP
Us~rs and Administrator's Guide
:1
Index
Special characters
(at-sign), in mail address, 33
: (colon), remote machine delimiter, 25
? (question mark)
ftp, 27
telnet,24
- (tilde), text, 23
-. (tilde dot), rlogin escape sequence, 22
@
A
Abbreviating telnet commands, 24
Aborting a remote session, 22-23
Access privileges, 19,26,29,43
Account, ftp, 19
Active connections display, 49
Address
mask, 146-147
parsing rules, 167
resource records, 82
Agents, 106
Alias
database, 188,193-194
forms, 192
Aliasing, 164
Anonymous account, 19,44
Anonymous ftp, 30
Apparently-To header line, 194
ASCII files, copying with ftp, 29
Association modes, 145
at-sign (@), in mail address, 33
Automatic login, 22, 29-30
Autonomous system, 95
B
Berkeley Internet Name Domain (BIND). See
Name server
Binary files, copying with ftp, 29
BIND. See Name server
BITNET,76
Boot file, name server, 76, 86
Broadcast address, configuration, 16
broadcastclient mode, 145
c
Cache, initialization, 78
Caching-only server, 86
Canonical, domain name, 83
Chain, netconfig, 67
Changing
rlogin escape character, 22-23
telnet escape character, 24
chroot(ADM), 44
Class, C and F defined, 168
Client
defined,6
mode, 133, 145
Clock
synchronizing, 129, 135
clock txt, 144
close command, ftp(TC), 28
Colon (:), remote machine delimiter, 25
Command line, flags, 181
Command mode
ftp command, 27
telnet program, 23
Commands
miscellaneous, 35
networking, 11
ntpq, 153
remote printing, 122
xntpdc, 153
Communications protocols, 8
Community name, 107
Conditionals, 170
Configuration file
Internet, 42
Configuration file, sendmail
building from scratch, 175
defined, 167
semantics, 170
sendmail program, 192
special header lines, 194
syntax, 167
trying a different, 185
205
Configuration
Configuration options, sendmail, 179
Configuring
broadcast address, 16
domain names, 14
gated,97
gateways, 97
interrupt vectors, 12
I/O base address, 12
IP address, 14-16
netmask,17
network, 41
network drivers, 12
NTPhosts, 146
PPP,66
pseudo ttys, 46-47
RAM buffer size, 13
remote printer, 125
serial line drivers, 17
SLIP,56,58
SNMP, 109-110
system name, 12
TCP/IP, 11-14, 16-17
Connection, to a remote machine, 27
controlkey statement, 154
Conventions, notational, 3
Coordinated Universal Time, 129, 133
Copying
directory trees, 26
files between machines, 25-26
Creating links in /usr /hosts, 22
Ctrl-] (telnet escape character), 23
D
Daemons
gateway, 95-96
mode, 184
remote printing, 121
routed,97
server,42
SNMP, 107
timed, 129
DARPA, setting up, 76
Database, network, 43
Datagram, Internet Protocol, 9
dead.letter file, 163
Debug mode in ftp, 30
Debugging, sendmail, 185
Default
206
Default (continued)
remote printer,. 125
routing, 96
Defining, macros in the .netrc file, 29
delivermail program, 160
Delivery
sendmail, 163, 187
Devices file, PPP entry, 69
Dialers file, PPP entry, 69
Dialup SLIP connection
configuring, 58
troubleshooting, 60
Disabling, control port, 58
Disconnecting from a remote machine, 22-23,
28
Dispersion, 133
Display, routing table, 51
DIX (thick) cable, configuring, 13
Domain
management, 91
name, 33, 83
name configuration, 14
name server, 86
pointerrecord,83
setting up, 76
Drift, 133
driftfile, 145
Driver
configuring, 12
kernel,37
E
Equivalence, 19, 43
Equivalent user, 26
Error, mailer, 175
Errors-To header line, 194
Escape character, changing, 22
Escaping
rlogin,22
shell metacharacters, 32
telnet, 23-24
/etc directory, network files, 43
/etc/ftpusers, 19,44
/etc/gated.bgp,97
/etc/gated.conf,97
/etc/gated.egp,97
/etc/gated.hello,97
/etc/gated.rip,97
Key
/etc/hosts,92
/etc/hosts file, 18
/etc/hosts.equiv, 19,43, 123, 126
/etc/hosts.lpd, 123, 126
/etc/inetd,42
/etc/inetd.conf, 42
/etc/named.pid,92
/etc/networks,61
/etc/printcap, 123
/etc/resolv.conf,87
Ethernet/SLIP gateway, 60
Executing, remote programs, 31
Exiting
ftp, 28
rlogin,22
tel net, 23
F
File
access, 19
copying, 25
modes, sendmail, 188
transfer, 25
transferring with ftp, 29
Forcing mail queue, 185, 191
Forking during queue runs in send mail, 187
.forward files, 194
Forwarding, 164
ftp(TC)
account, 19,44
anonymous, 30
commands, 27
compared to rcp(TC), 25
defined, 27
modes, 27, 29-30
options, 30
prompt, 27, 30
transferring files, 29
G
gated(ADMN) daemon, 95
Gateway
defined, 95
smart, 96
get command, ftp(TC), 28
gethostbyname call, 92
getid (ADMN), 111
getmany (ADMN), 111-112
getone (ADMN), using, 111
glob command, ftp(TC), 30
Guest ftp account, 19, 30
H
Header lines, 194
Host
defined, 8, 133
information resource record, 82
name, 33
Host name, setting, 12
hostname(TC), 91
Hosts database, 18
hosts.equiv file, 19, 43
I
~CMP, routing-redirect messages, 96
Ifconfig(ADMN), 41, 63
ignore flag, 146
inetd(SFF),42
Initializing, cache, 78
Installing
PPP,65
remote printing, 120
SLIP, 55
Interface network, 41, 50
Internet
address, 41
address configuration, 14-16
daemon, 42
defined, 8, 133
protocol,9
Interrupt vector, configuring, 12
I/O base address, configuring, 12
IP, defined, 9
•
K
Kernel, configuration, 37
Key, 10, 154
207
LAN
L
N
LAN (Local Area Network)
defined, 5-6
List owners, 193
Local, subnetwork, 41
Local Area Network, See LAN
Logging out from a remote machine, 22
Login, automatic, 22, 29-30
lowpriotrap flag, 146
Ip(C),122
Ipd(ADMN), 121
lpq command, 123
lpr command, 123
lprm command, 123
Ipstat(C), 122
Name resolution, 148
Name resource record, canonical, 83
Name server
cache initialization, 78
cacmng-only, 75, 86
changing origin, 81
data files, 79
defined, 73
master servers, 74
multiple files, 80
remote, 75, 78
resourcerecords,79,81-85
sample files, 86, 89
slave, 75
starting, 76, 91
types, 74
named(ADMN),91-93
named.hosts, 88
named.local, 87
named.rev,89
Netmask, configuration, 17
netstat(TC), 47,49-50,52,61
Network
activities, 50
connections, 49
data files, 43
mail,33
pathname,25
protocols, 8
sample, 6
server,42
system administrator responsibilities, 8
troubleshooting, 47
Network Information Center. See NIC
Network Time Protocol. See NTP
NIC (Network Information Center), 95, 101
Node, defined, 8
nomodify flag, 146
nopeer flag, 146
noquery flag, 146
noserve flag, 146
Notational conventions, 3
notrap flag, 146
notrust flag, 146
NTP (Network Time Protocol)
add server dynamically, 156
algorithms, 141
configuration, 138-139, 146
M
~acro,defined,168
~acros
in the .netrc file, 29
~ail
header, 164
queue, 189, 191
resource record, 84-85
sending to remote sites, 33
~ailbox, resource record, 84
~ailer
defining, 168
flags, 174, 183
~anagement Information Base (MIB), 106
Management stations, 106
~aster server
primary,74,86
secondary, 74,86
maxskew, 152
~essage
Processing Module (MPM), 161
queues, 165
timeouts in sendmail, 186
Metacharacters, for remote commands, 32
mkdev(ADM)
rIp, 120
snmp, 109-110
M~F, compared to sendmail, 160
~ode NTP packets, 154
~onitoring NTP, 155
MP~ (~essage Processing Module), 161
208
put
NTP (Network Time Protocol) (continued)
controlkey statement, 154
defined, 129, 133
delete server dynamically, 156
example configuration file, 142
guidelines, 136
keys file, 142
maxskew, 152
monitoring, 155
overview, 136
precision, 152
query, 153
requestkey statement, 154
subnet, 137, 158
syslog entries, 157
terms, 133-135
testing, 152
troubleshooting, 157
tuning, 152
NTP.MAXSKW, 152-153
ntpq(ADMN), 153
o
Object identifier
defined, 104
hierarchy, 105
types, 105
open command
ftp(TC), 27
telnet(TC),24
p
Packet
NTP,l34
trace, 47
Parameters, network, 41
Password, ftp(TC), 29
Pathname
ftp(TC), 28
network, 25
remote,25
Permissions, .netrc file, 29
Per-user forwarding, 194
ping(ADMN), 63
Point-to-Point Protocol. See PPP
Poll, 133
PPP (Point-to-Point Protocol)
PPP (Point-to.:Point Protocol) (continued)
compared to SLIP, 65
configuring, 66
defined,55,64
Devices file entry, 69
Dialers file entry, 69
Ethemet/PPP gateway, 60
installing, 65
manual pages, 72
removing, 70
sharing serial line with UUCP, 65
Systems file entry, 69
Token-Ring/PPP gateway, 60
troubleshooting, 70-71
Precedence definitions, 169
Precision oscillators, 144
precision statement, 152
Primary server, 86,134,144
Print server
defined, 119
remote, setting up, 126
Printer, remote, 123, 125
Printing
mail queue, 189
remote, 119-120, 122
remotely, 32
Privileges, access, 26, 29
Prompt
ftp(TC), 27, 30
telnet(TC), 24
Protocol
BGP,95
communications, 8-10
defined,6
EGP,95
exterior gateway, 95
HELLO,95
interior gateway, 95
RIP, 95
SNMP,104
statistics display, 52
TCP/IP,10
Pseudo ttys, administering, 46-47
Public ftp account, 19, 30
put command, ftp(TC), 28
209
Query
Q
QueryNTP,153
Question mark (7)
ftp, 27
telnet,24
Queue
forcing, 185
interval, 184
intervals in sendmail, 186
priorities in sendmail, 187
runs, forking, 187
Queued messages, 165
Quitting
ftp, 28
rlogin,22
telnet,23-24
R
RAM buffer size, configuring, 13
rcmd(TC),31-32
rcp(TC), 25-26
Read timeouts in sendmail, 186
Rebuilding the alias database, 193
Remote
command execution, 31
file copy, 25
name server, 75, 78
pathname, 25
printer, 123, 125-127
printing, 32, 119-120, 122
session, aborting, 22
Remote machine
connecting, 27
delimiters, 25
disconnecting, 22-23
disconnecting from, 28
logging out, 22-23
Removing, remote printing, 120
requestkey statement, 154
Resource records, 79, 81-85
restrict statement, 146
Restricting file access, 19,30
Retum-Receipt-To header line, 194
Rewriting rules, 167, 172, 176
RFC, gateway protocols, 101
.rhosts,43
rlogin(TC)
defined,21-22
210
rlogin(TC) (continued)
escape character, 22-23
escaping, 22
RLP,119
rlpconf(ADMN),l25-126
root.cache, 87
Roundtrip delay, 134
routed(ADMN), 60,95
Routing
default, 96
table, 18, 51
wildcard, 96
Rule sets, rewriting, 174
Running commands remotely, 31
s
Search path, UNIX system, 22
Secondary
serve~86, 134, 144
Sending mail across the network, 33
sendmail
administering, 189
alias database, 188
arguments, 184
changing option values, 185
collecting messages, 162
command line flags, 181
compared to delivermail, 160
compared to MMDF,16O
compared to MPM, 161
configuration file, 167, 170, 175, 185, 192
daemon mode, 184
debugging, 185
delivering messages, 163
delivery mode, 187
editing the message header, 164
error mailer, 175
file modes, 188
flags, 174
mail queue, 189
mailer flags, 174
Message Processing Module, 161
options, changing values of, 185
queue, 184-185
return to sender, 163
rewriting rules, 167
special header lines, 194
suid,l88
telnet(TC)
sendmail (continued)
support files, 195
temporary file modes, 188
tuning, 185
Server
defined,6
mode, 134
types,74-75
setany(ADMN),114
Sharing, hardware, 31
Shell
metacharacters, 32
startup file, 31
Simple Network Management Protocol. See
SNMP
Skew,NTP,l34
slattach(ADMN),59
Slew, NTP, 134
SLIP (Serial Line Internet Protocol)
compared to PPP, 65
configuring, 17,56,58
defined,55
dialup connection, 58
direct connection, 56
error messages, 63-64
Ethernet/SLIP gateway, 60
installing, 55
manual pages, 64
removing, 61
Token-Ring/SLIP gateway, 60
troubleshooting, 60, 62
SNMP (Simple Network Management
Protocol)
agents, 106
authentication, 107
basic concepts, 103
commands, 108-109
communities, 107
configuration, 107, 109-110
daemon, 107
defined,103
Management Information Base (MIB), 106
management stations, 106
object identifier, 104-105
protocol defined, 104
relevant RFC's, 117
sample file, 108
Structure of Management Information
(SMI),104
traps, 107
SNMP (Simple Network Management
Protocol) (continued)
using, 110-117
snmpd sample, 108
snmpstat (ADMN),112-113
SOA (Start of Authority) record, 81
SO_DEBUG option, 47
Special
classes, 172
macros, 170
Special characters, 32
Standard resource record format, 79
Startup files, 31
status command, telnet(TC), 24
Step, NTP, 134
Stratum, NTP, 134
STREAMS, tuning, 47
Structure of Management Information (SMI),
104
Subnetwork, 41
suid in sendmail, 188
Support files, summary of, 195
Symmetric active mode, 134, 145
Symmetric passive mode, 134
Synchronization subnet, 135
Synchronizing clocks, 129
syslog entries, NTP, 157
sys.precision, 152
System equivalence, 19, 43
System administrator, duties, 8
System name, setting, 12
Systems file, PPP entry, 69
T
TCP
defined,9
reliable transmission, 9
TCP/IP
defined,8·
end user commands, 11
protocol layers, 7-8
protocols, 10
telnet(TC)
abbreviating commands, 24
command mode, 23
defined, 21, 23
escape character (Ctrl-]), 23-24
exiting, 23
211
Temporary,
telnet(TC) (continued)
options, 24
Temporary, file modes, sendmail, 188
Testing, NTP, 152
Tilde C-), text, 23
Time
client, 135
daemon, 135
server, 135
synchronizing, 129
Timecode
receivers, 144
transmitters, 144
timed(ADMN), 129, 132
timedc(ADMN),132
Timeouts in sendmail, 186
Token-Ring/SLIP gateway, 60
Transferring files
between machines, 25
ftp(TC), 28-29
Traps, 107, 135
Troubleshooting
network, 47
NTP, 157
PPP, 70-71
SLIP, 60, 62-64
SNMP,115-117
using SNMP, 103
trpt(ADMN), 47
truechimer, 141
Trusted, users, 169
TSP (Time Synchronization Protocol), 129
Tuning
NTP,152
sendmail, 186-188
STREAMS, 47
u
User
equivalence, 19,26,43
user command, ftp(TC), 30
/usr/adm/syslog, 157
/usr /hosts, creating links, 22
UUCP
dialer program, 59
sharing serial line with PPP, 65
212
v
Verbose mode in ftp, 27, 30
w
WAN (Wide Area Network), 5
Well known services resource record, 83
Wide area network, See WAN
Wildcard characters, 30
x
xntpdc(ADMN),153-154
xntpres program, 148
OPEN SYSTEMS SOFTWARE
Please help us to write computer manuals that meet your needs by completing this
form. Please pait the completed form to the Publications Manager nearest you: The
Santa Cruz Operation, Ltd., Croxley Centre, Hatters Lane, Watford WDI 8YN,
United Kingdom; The Santa Cruz Operation, Inc., 400 Endnal Street, p.o. Box 1900,
Santa Cruz, California 95061, USA or SCO Canada, Inc., 130 Bloor Street West, 10th
Flocr, Toronto, Ontario, CanadaMSS INS.
Volumetitle: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
(cqpy this from the title page of the manual, for example, SCD UNIX Operating System User's Guide)
Produet:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ___
(for example, SCD UNIX System V Release 3.2 Operating System Version 4.0)
How long have you used this product?
o Less than one month 0 Less than six months
o
1 to 2 years
0 Less than one year
0 More than 2 years
How much have you read of this manual?
o Entire manual
o Spedfic chapters
o
Used only for reference
Disagree
Agree
The software was fully and accurately described
The manual was well organized
The writing was at an appropriate technical level
(neither to.o complicated nor too simple)
It was easy to find the information I was looking for
Examples were clear and easy to follow
TIlustrations added to my understanding of the software
I liked the page design of the manual
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
H you have spedfic comments or if you have found spedfic inaccurades,
please report these on the back of this form or on a separate sheet of paper.
In the case of inaccurades, please list the relevant page number.
May we contact you further about how to improve SCO UNIX documentation?
Hso, please supply the following details:
Name _____________ Position _____________
Company __________________________
Addr~s
______________________________
City & Post/Zip Code ______________________________
Counhy ___________________________
Telephone _ _ _ _ _ _ _ _ _ _ Facsimile ____________
24 June 1992
111111111111111111111111111111111111111111111111111111111111II11I
BH02803P00a
71292
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2013:07:02 09:55:42-08:00 Modify Date : 2013:07:02 11:14:18-07:00 Metadata Date : 2013:07:02 11:14:18-07:00 Producer : Adobe Acrobat 9.55 Paper Capture Plug-in Format : application/pdf Document ID : uuid:05319b1d-b803-7241-ad14-3da822e81def Instance ID : uuid:28e12daa-4d06-654e-a900-7aa95de424c7 Page Layout : SinglePage Page Mode : UseNone Page Count : 231EXIF Metadata provided by EXIF.tools