Linux Network Administration I, TCP-IP and TCP-IP Services - Student Notebook (IBM Learning, 2003, Course Code LX07)

V3.
cover
Front cover
Linux Network
Administration I: TCP/IP and
TCP/IP Services
(Course Code LX07)
Student Notebook
ERC 3.2
IBM Certified Course Material

Student Notebook
Trademarks
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX® DB2® Domino™
Lotus Notes® Lotus® Notes®
SecureWay®
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
September 2003 Edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
© Copyright International Business Machines Corporation 1999, 2003. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V3.0
Student Notebook
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Unit 1. TCP/IP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
What is TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Requests for Comment (RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
TCP/IP Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Network Architecture Support in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
LANs and the ARP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
WANs and the SLIP and PPP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
IP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Internet Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
IP Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Special Internet Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Off-the-byte Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
ICMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Ports and Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
UDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
TCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Unit 2. Configuring TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
TCP/IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Configure Hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Configure Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Assign IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Configuring Wireless Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Configuring the Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Configuring Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
/etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
/etc/resolv.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
© Copyright IBM Corp. 1999, 2003 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Student Notebook
Testing Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17

Verify Local Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
Verify Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
Verify ARP Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
Verify Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21
Verify Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
Verify Open Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-24
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-25
Unit 3. The inetd Daemon and inetd Services . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
The inetd "Super" Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
/etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
The tcpd Wrapper Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7
/etc/hosts.allow and /etc/hosts.deny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
The xinetd "Super" Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
/etc/xinetd.conf and /etc/xinetd.d/* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11
Overview of inetd Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13
Remote Login, Execute and File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16
Anonymous ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18
rexec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19
rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20
rcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21
rsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22
rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23
finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25
talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28
Unit 4. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
telnet, ftp, rexec, rsh, rcp Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
SSH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
SSH Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
ssh Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
scp Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
sshd Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
ssh/sshd Host Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
sshd User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
RSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
DSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
Protecting Your Private Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
iv Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
TOC Unit 5. Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
PPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Linux PPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Setting Up A PPP Client (Overview) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Establishing a Serial Connection (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Establishing A Serial Connection (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Establishing the PPP Connection (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Establishing the PPP Connection (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Setting Up A PPP Client (Wrapup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Setting Up A PPP Server (Overview) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Setting Up for a Serial Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Setting Up for an Incoming PPP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Client Authentication (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Windows Clients Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
PPP and a Permanent Null-Modem Connection . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Unit 6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
The Internet - How It Seems To Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
The Internet - How It Really Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Router Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Linux as a Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
A Sample Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Basic Route Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Viewing the Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Filling the Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
route Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Configuring Static Routes Permanently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Dynamic Routing Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Routing Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Debugging Routing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Unit 7. Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
DNS Hierarchy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Resource Records Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
DNS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
© Copyright IBM Corp. 1999, 2003 Contents v

Student Notebook
Reverse DNS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12

Nameservers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14
Scenario - Domain Name Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-15
Setting Up the Master Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16
Master Name Server Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18
Syntax of a named Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
Name Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21
IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-24
Local Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26
Cache File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-27
Final Master Name Server Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-29
Checklist: Adding a Host to the Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-30
Setting Up the Slave Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-31
Slave "named" Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-32
Local Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-33
Cache File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-34
Final Slave Name Server Setup Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-35
Caching-Only Nameserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-36
Managing Your Nameserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-37
Setting Up the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-39
Debugging DNS Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-40
host, nslookup and dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-41
nslookup Noninteractive Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-43
nslookup Interactive Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-44
dig Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-45
Active Database Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-46
Active Database Dump Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-47
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-48
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-49
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-50
Unit 8. Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
E-mail Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
E-mail model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
User Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
Simple Mail Transfer Protocol (SMTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8
SMTP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Message Transfer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11
Deliver to which MTA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12
Post Office Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14
POP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Internet Message Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18
Linux E-mail Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Sendmail Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-20
sendmail.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
Important Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25
Postfix Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27
vi Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
TOC /etc/postfix/main.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29

Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
User-Defined Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Virtual Mail Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
Implementing POP3 or IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Protecting POP and IMAP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Unit 9. Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Dynamic Host Configuration Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Leasing an IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
DHCP Client-Server Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
DHCP Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Selected DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Linux DHCP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Linux DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Linux DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
Sample /etc/dhcpd.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
DHCP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Troubleshooting DNS Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Unit 10. Network File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Sharing Data on a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
The NFS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Virtual File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
How NFS Shared Files are Protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
UNIX Authorization - User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
UNIX Authorization - Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Configuring The Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
The /etc/exports File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
Configuring the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Manual Remote Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Predefined Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
NFS Mount Options (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17
NFS Mount Options (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
Useful commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Additional NFS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21
Troubleshooting NFS Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24
© Copyright IBM Corp. 1999, 2003 Contents vii

Student Notebook
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-25
Unit 11. NFS Automounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2
Automounter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3
Automounter Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4
Linux Automounters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5
AMD Configuration File: /etc/amd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
AMD Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7
Starting AMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8
AMD in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
AMD Mountpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
Autofs Configuration File: /etc/auto.master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-11
Autofs map file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12
Starting Autofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-13
Autofs in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-14
Automounter Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-16
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-17
Unit 12. Network Information Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Distributed Environment Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
How NIS Addresses Distributed Environment Concerns . . . . . . . . . . . . . . . . . . . .12-4
NFS and /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5
NIS Centralized Control of /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
NIS Centralized Control of /etc/group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-7
NIS Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8
NIS Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9
System Default NIS Data Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10
NIS Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11
NIS Master Server Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-12
NIS Domain Name - Master Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
Editing NIS Master Server /etc/passwd File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14
Editing NIS Master Server /etc/hosts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15
Final Master Server Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16
Contents of the NIS Domain Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
NIS Slave Server Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19
NIS Domain Name - Slave Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20
Edit Local Files - Slave Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-21
Configuring NIS Slave Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-22
NIS Client Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-24
NIS Domain Name - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25
Edit Local Files - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-26
Start Client Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27
Updating NIS Passwords with yppasswd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28
Updating NIS Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29
Downlevel Slave Server Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-30
viii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
TOC NIS Programs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31

Troubleshooting NIS Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-33
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-34
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
Unit 13. The Lightweight Directory Access Protocol (LDAP) . . . . . . . . . . . . . . 13-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
What’s a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
Directories vs. Relational Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
LDAP Concepts (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
LDAP Concepts (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
The “Core” Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
LDAP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12
LDAP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14
LDAP Clients for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16
Using LDAP for UNIX User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
The OpenLDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-19
/etc/openldap/slapd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
Converting UNIX Authentication Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-21
Start and Test OpenLDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23
OpenLDAP Client Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-24
Configure UNIX Authentication via LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-25
LDAP Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-27
Troubleshooting LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-29
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-30
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31
Unit 14. The Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Why Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
The Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Sources of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Stratum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
NTP Communication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
ntp Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
/etc/ntp.conf Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
Receiver Pseudo IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14
NTP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16
Other Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-19
© Copyright IBM Corp. 1999, 2003 Contents ix

Student Notebook
Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Appendix C. Usenet News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
x Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
TMK Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX® DB2® Domino™
Lotus Notes® Lotus® Notes®
SecureWay®
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
© Copyright IBM Corp. 1999, 2003 Trademarks xi

Student Notebook
xii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
pref Course Description

Linux Network Administration I: TCP/IP and TCP/IP Services
Duration: 5 days
Purpose
The purpose of this course is to teach TCP/IP network configuration
and administration including the skills necessary to begin
implementing and using PPP, DHCP, electronic mail, Usenet news,
static and dynamic routing, DNS, NFS, NIS, LDAP and NTP.
Audience
Network administrators or other personnel responsible for the
configuration, use, and support of TCP/IP and common network
services, such as electronic mail, Usenet News, DHCP, DNS, NFS,
NIS, LDAP and NTP on Linux.
Prerequisites
• Have a working knowledge of the Linux environment and
commands
• Be able to edit files with vi
• Understand file systems, directories, files and their security
• Understand the concept of mounting file systems
• Have a basic knowledge of general networking concepts
Objectives
On completion of this course, students should be able to:
• Understand the basic concepts of TCP/IP protocols and
addressing
• Understand TCP/IP broadcasting and multicasting
• Configure TCP/IP on Linux
• Configure PPP
• Understand DHCP and build a DHCP server on Linux
• Connect multiple TCP/IP networks using static and dynamic
routing
© Copyright IBM Corp. 1999, 2003 Course Description xiii

Student Notebook
• Use networking commands for remote login, remote execution, and

file transfer
• Understand and implement DNS, NFS, NIS and LDAP
• Understand and implement NTP
• Perform basic troubleshooting of network problems.
Contents
• TCP/IP protocols and addressing
• TCP/IP broadcasting and multicasting
• TCP/IP subnet masking
• Configuring TCP/IP on Linux
• TCP/IP commands
• Electronic mail
• Point-to-Point Protocol implementation
• Static and dynamic routing including an introduction to the RIP and
OSPF protocols
• Concepts and basic implementation of DNS
• Introduction to troubleshooting network problems
• Concepts and basic implementation of NFS, NIS and LDAP
• Concepts and implementation of NTP
xiv Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
pref Agenda
Day 1
Unit 1 - TCP/IP Concepts
Unit 2 - Configuring TCP/IP
Exercise 2 - Configuring TCP/IP
Unit 3 - The inetd Daemon and inetd Services
Exercise 3 - The inetd Daemon and inetd Services
Day 2
Unit 4 - Secure Shell and Secure Copy
Exercise 4 - Secure Shell and Secure Copy
Unit 5 - PPP
Exercise 5 - Configuring PPP
Unit 6 - Routing
Exercise 6 - Routing
Day 3
Unit 7 - The Domain Name System
Exercise 7 - The Domain Name System
Unit 8 - Electronic Mail
Exercise 8 - Electronic Mail
Unit 10 - Dynamic Host Configuration Protocol
Day 4
Exercise 10 - Configuring DHCP
Unit 11 - Network Filesystem
Exercise 11 - Configuring NFS
Unit 12 - NFS Automounter
Exercise 12 - NFS Automounter
Day 5
Unit 13 - Network Information Service
Exercise 13 - Configure and Use NIS
Unit 14 - Lightweight Directory Access Protocol
Exercise 14 - Lightweight Directory Access Protocol
Unit 15 - Network Time Protocol
Exercise 15 - Network Time Protocol
© Copyright IBM Corp. 1999, 2003 Agenda xv

Student Notebook
xvi Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
pref Certification Information

Several professional certifications currently exist for Linux. This
course, combined with other Linux courses, will prepare you for all of
them. For more information, see appendix B.
This course, in combination with other courses, has been certified by
ProCert (http://www.procert.com) as appropriate course material for
preparing for LPI certification tests. The statement below reflects this.
Linux Professional Institute Statement

“This course is specifically designed to provide you with the skills,
knowledge and understanding required to become professionally
certified by LPI. To learn more about LPI certifications, or to register to
take an official LPI certification exam, visit www.lpi.org.”
© Copyright IBM Corp. 1999, 2003 Certification Information xvii

Student Notebook
xviii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
Uempty Unit 1. TCP/IP Concepts
What This Unit Is About

This unit is an introduction to networking and TCP/IP. It describes the
protocols of TCP/IP, how those protocols work together, and
terminology associated with TCP/IP. It also goes into detail about
network addressing.
What You Should Be Able to Do

After completing this unit, you should be able to:
• List and describe the main protocols included in the TCP/IP
protocol suite
• Describe the TCP/IP layering model
• Discuss the main features of the main TCP/IP protocols
• Describe IP addressing
How You Will Check Your Progress

Accountability:
• Checkpoint questions
© Copyright IBM Corp. 1999, 2003 Unit 1. TCP/IP Concepts 1-1

Student Notebook
Objectives
After completing this unit, students should be able to:

List and describe the main protocols included in the
TCP/IP protocol suite
Describe the TCP/IP layering model
Discuss the main features of the main TCP/IP protocols
Describe IP addressing
Figure 1-1. Objectives LX073.2
Notes:
1-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
Uempty
What is TCP/IP
Transmission Control Protocol/Internet Protocol

Suite of protocols that work together
TCP, IP, UDP, ARP, ICMP, PPP, ...
Open standards
Allows communication between heterogeneous systems
Supports different physical network types
Protocol of the Internet
Figure 1-2. What is TCP/IP LX073.2
Notes:
TCP/IP stands for Transmission Control Protocol/Internet Protocol. A more accurate name
is Internet Protocol Suite.
TCP/IP is a set of protocols or rules which define various aspects of how two computers in
a network may communicate with each other. A protocol is a set of rules which describe the
mechanisms and data structures involved. Using these definitions, vendors can write
software to implement the protocols for particular systems.
There are many different protocols which cover the aspects of addressing hosts in the
network, data representation and encoding, message passing, interprocess
communications, and application features, such as how to send mail or transfer files across
the network.
Where possible, the protocols are defined independently of any operating system, network
hardware, or machine architecture. In order to implement TCP/IP on a system, interface
software must be written to allow the protocols to use the available communications
hardware.

Student Notebook
This means that heterogeneous environments can be created where machines from
different manufacturers can be connected together, and different types of networks can be
interconnected.

V3.0
Student Notebook
Uempty
History
Late 1960s DARPA primary funding agency
Mid 1970s ARPANET point-to-point leased line

interconnection
1980 Internet established, ARPANET as
backbone
1983 TCP/IP mandatory use in ARPANET
Mid 1980s BSD UNIX incorporates TCP/IP
Late 1980s TCP/IP available on almost all computer

systems
1990s TCP/IP becomes protocol of choice for
most organizations; explosive growth of
Internet
Figure 1-3. History LX073.2
Notes:
TCP/IP is the result of work commissioned in 1968, by the US Department of Defense,
Advanced Research Projects Agency (DARPA). Many other research and vendor
organizations have contributed to the development of TCP/IP.
DARPA implemented a point-to-point network using leased lines, called ARPANET, with
protocols which eventually evolved into TCP/IP. In 1980, ARPANET became the backbone
to the "Internet", which linked many US government, military, research, educational, and
commercial organizations. By 1983, all hosts in ARPANET, now called the Internet, used
TCP/IP protocols.
The main popularity of TCP/IP has been due to its association with UNIX systems. In
particular, DARPA funded University of California, Berkeley to integrate TCP/IP into the
Berkeley Software Distribution (BSD).
TCP/IP is the protocol of the Internet. Thus, anyone connecting to the Internet uses TCP/IP.

Student Notebook
Requests for Comment (RFC)
RFC 791
Internet
Protocol
Issued by Internet Architecture Board (IAB)

TCP/IP standards
Information on managing TCP/IP networks
Identified by number with larger numbers indicating
newer RFCs
http://www.rfc-editor.org
Figure 1-4. Requests for Comment (RFC) LX073.2
Notes:
Some TCP/IP development is initiated by an organization called the Internet Architecture
Board (IAB), which oversees development of the Internet network and the TCP/IP software
it uses. The actual development of standards is performed by the Internet Engineering Task
Force (IETF) which reports to the IAB. The IETF is divided into a number of working groups
which pursue specific projects. Other TCP/IP development is performed by vendor
organizations that write protocols which may become Internet standards.
The IAB distributes documents called Request For Comments (RFC) which describe
TCP/IP protocols and other relevant information. RFCs are the master source of TCP/IP
and Internet information. They include:
• administrative information
• requirements and guidelines
• protocols and standards
• measurement and statistics
• historical information

V3.0
Student Notebook
Uempty Anyone can submit a document for publication as an RFC. Submissions must be made via
electronic mail to the RFC Editor. They are reviewed technically from the task forces,
individual technical experts, or the RFC Editor, as appropriate.
The RFC series comprise a wide range of documents, ranging from informational
documents of general interest to specifications of standard Internet protocols.
Once a document is assigned an RFC number and published, that RFC is never revised or
reissued with the same number. There is never a question of having the most recent
version of a particular RFC. However, a protocol (such as File Transfer Protocol (FTP)) may
be improved and redocumented many times in several different RFCs. It is important to
verify that you have the most recent RFC on a particular protocol. RFCs are available from
the RFC Editor at http://www.rfc-editor.org.

Student Notebook
TCP/IP Layering
Applications such as NFS, NIS, mail, DNS
UDP TCP
Unreliable delivery to correct program Reliable delivery to correct program
IP
Unreliable delivery of packets to correct system
WAN LAN
(Modem connections, lease lines, ...) (Ethernet, Token Ring, ...)
Figure 1-5. TCP/IP Layering LX073.2
Notes:
The TCP/IP protocol suite consists of some hundred different protocols, which are
described in about 2,500 RFCs. Most of these protocols and RFCs are either application
specific (such as RFC 959, which describes the FTP protocol), or describe how data should
be transferred over a specific architecture (such as RFC 894, which describes IP over
Ethernet). For now, it is important to understand the working and interdependency of only a
few core protocols: UDP, TCP, ICMP, IP, SLIP/PPP and ARP.
Since these protocols are built on top of each other, where one protocol uses another
protocol to get things done, the interdependency is just about as important as
understanding each protocol independently.
From top to bottom we find the following protocols:
• Applications use either the User Datagram Protocol (UDP) or the Transmission
Control Protocol (TCP) to transmit their data.
Both TCP and UDP deliver the data to the right process, and make use of IP and ICMP
to arrange delivery to the right host.

V3.0
Student Notebook
Uempty The difference between UDP and TCP is that TCP implements a mechanism of
acknowledgements, whereby reliability can be guaranteed. UDP does not have such a
mechanism, making UDP less reliable.
• The Internet Protocol (IP) receives data to be transmitted from TCP, UDP or ICMP,
and deliver it to the corresponding protocol at the receiving host.
• For error reporting, the Internet Control Message Protocol (ICMP) is used. This
protocol can report errors in TCP, UDP and IP, and sends its data using IP.
• IP sends its data from hop to hop by using the physical network in between. If such a
physical network is a Wide Area Network, it might need to enlist the Serial Line IP
(SLIP) or Point to Point Protocol (PPP) to send the data, and if the physical network is
a Local Area Network, the Address Resolution Protocol (ARP) is needed.

Student Notebook
Network Architecture Support in Linux
Wide Area Networks

Serial/modem/ISDN connections
CCITT X.25 Protocol (under development)
ATM (under development)
Frame Relay (dlci or sdla)
Local Area Networks
Ethernet (eth)
Token Ring (tr)
FDDI (fddi)
ARCnet (arc)
WiFi (???)
Miscellaneous
Loopback (lo)
AX.25 (sl or ax)
Figure 1-6. Network Architecture Support in Linux LX073.2
Notes:
RFCs have been written on sending IP packets over a variety of networks. When
implemented correctly, you can send IP over just about anything. A great example of this is
RFC 1149, which describes how an IP packet should be sent over a network of "avian
carriers" (postal pigeons). According to the author: "Avian carriers can provide high delay,
low throughput, and low altitude service." If that's what you need, implement this RFC.
Linux does not support avian carriers1, but it does support the most common networking
technologies currently found in the marketplace:
• Serial connections, such as modem and ISDN connections are typically used as
dial-up connections to an Internet Service Provider (ISP). But most leased lines also
make use of this technology.
• X.25 is an OSI-compliant protocol which was very popular some 10-20 years ago, since
it was the only protocol which allowed continuous, reliable data connections with a
1 This is not quite true. On April 28th, 2001, the Bergen Linux Users Group implemented RFC 1149 for Linux. It took them a little less
than three hours to transmit nine "ping" packets, of which four were actually answered. For more information see
http://www.blug.linux.no/rfc1149.

V3.0
Student Notebook
Uempty reasonable bandwidth. It is still used a lot for instance to connect ATMs to the financial
networks.
• ATM is a newer protocol which can be used for WANs as well as for LANs and offers
high-bandwidth, low-latency connections.
• Frame Relay is the low-overhead successor of X.25. It offers higher and more flexible
bandwidth than X.25 against the same or lower cost.
• Ethernet and Fast Ethernet are the most common architectures used in Local Area
Networks today. Because of high volume sales, hardware is cheap and performance is
adequate for most office applications today. Gigabit Ethernet is becoming more and
more common in places where high bandwidth is required, such as backbones.
• Token Ring is a more reliable architecture than Ethernet, where bandwidth reservation
is possible. It is generally more expensive than Ethernet. It is typically used in IBM
environments in combination with SNA. Development of the Token Ring architecture
has stopped, which has caused a lot of companies to migrate to Ethernet.
• Fiber Distributed Digital Interface is a 100 Mbps fiber optic network architecture
which was very popular in backbones. It is being replaced by Fast or Gigabit Ethernet
though.
• ARCnet is a low-cost, low bandwidth alternative to Ethernet which also offers
bandwidth reservation.
• Wireless LANs, mostly based on the WiFi 802.11 standard are becoming increasingly
popular. Depending on the adapters used, the bandwidth lies between 11 and 54 Mbps,
and the distance covered can be several hundreds of meters.
A major problem within wireless LANs today is security. The wireless LAN standards
incorporate WEP, Wired Equivalent Privacy, but a lot of people simply forget to turn this
on. And even when turned on, it can be broken relatively easy.
• The Loopback interface (lo) allows you to do TCP/IP communications over a virtual
interface, even when no real interface is present. This is useful for applications that
need TCP/IP, such as X-Windows. It is also useful for testing.
• AX.25 is a protocol for sending IP packets over long-distance amateur radios.
Certain architectures are listed as "under development". This does not mean that you
should wait before using this architecture with Linux. Typically it means that parts of the
architecture are fully supported, and other parts are not supported at all, because the
author and other Linux users are not interested in this part. Consider for instance
X.25:Switched Virtual Circuits (SVCs) are fully supported, and Permanent Virtual Circuits
(PVCs) are not supported at all. Nobody uses PVCs anyway.

Student Notebook
LANs and the ARP Protocol
Most LANs are broadcast networks at the lowest level

Everybody receives what you are sending
To identify the recipient, a MAC address is used
48 bits, unique for the network adapter
Notation: 02:60:8C:2E:9B:CA
Special MAC address FF:FF:FF:FF:FF:FF is used for
broadcasts
The ARP protocol is used to determine the MAC address
of your party
Broadcast destination IP address to anyone
Only the destination replies with its MAC address
ARP is invoked automatically by IP if the destination MAC
address is not known
Cached in ARP table
View table with arp -a
Figure 1-7. LANs and the ARP Protocol LX073.2
Notes:
Most Local Area Networks are, at a low level, broadcast networks. This means that a data
packet is sent out to every system on the network. The reason for this is that all systems
are all connected to basically the same cable. In order to distinguish between systems,
every network adapter has been assigned a so-called MAC address. This 48-bit address is
assigned by the manufacturer of the network adapter, and is unique. (In fact, the first 24
bits identify the manufacturer itself.) MAC addresses are usually written down in
hexadecimal form.
Every packet that is sent over such a LAN carries the MAC address of the recipient and the
sender. It is received by everyone on the LAN, but automatically discarded by everyone
except the intended recipient.2
Before data can be sent to someone on a LAN, you need to figure out the MAC address of
the recipient. This is done by the Address Resolution Protocol, which works roughly as
follows:
2
It is possible to put your network adapter in "promiscuous mode", in which case it will receive every packet on the network. This is used
by network sniffers such as tcpdump.

V3.0
Student Notebook
Uempty 1. The sender sends a special packet, the "ARP request" to the MAC broadcast address
(48 ones or "FF:FF:FF:FF:FF:FF"). This packet contains the IP address of the intended
recipient, and the IP and MAC address of the sender.
2. All systems receive the ARP request and compare the IP address of the intended
recipient with their own IP address. If these are not the same, the ARP request is
discarded. If these addresses are the same, the recipient sends back an "ARP reply",
which contains its MAC address.
3. The sender now sends the IP packet directly to the MAC address of the recipient.
4. Both the sender and the recipient store each others IP and MAC address in the ARP
cache for the next time.
The ARP protocol is invoked automatically by IP if the destination MAC address is not
known.
To view the contents of the arp cache, use the command arp -a. The arp command also
allows you to delete or add entries from/to the arp cache manually.

Student Notebook
WANs and the SLIP and PPP Protocols
Some WANs do not transmit packets but streams of

bytes
To transmit IP packets, an encapsulation technique is
needed
SLIP:
encapsulation technique for IP only
PPP:
encapsulation technique for multiple protocols (IP, IPX,
DECnet, ...)
authentication
connection negotiation and configuration
Figure 1-8. WANs and the SLIP and PPP Protocols LX073.2
Notes:
WANs have a completely different set of problems that IP needs to cope with. The most
important problem comes from the fact that most WAN connections are just that:
connections. This means that there is no packet structure by default, but a stream of bytes.
In order to use this stream-based connection for sending packets, an encapsulation
technique has to be introduced. Two of these are well known: SLIP and PPP.
The Serial Line IP Protocol (SLIP) is just that: an encapsulation technique which allows
you to send IP packets over a stream-based connection. It does not offer any other
features.
The Point to Point Protocol (PPP) is also an encapsulation technique, but it also offers a
number of other features which are generally useful in dealing with WANs:
• It can encapsulate multiple protocols, not just IP.
• It can perform authentication.
• It can do connection negotiation and configuration.
PPP is very complex. We will cover it in a separate unit.

V3.0
Student Notebook
Uempty
IP Protocol
Packet delivery protocol:

Best effort - no guarantees
Next-hop routing to destination host based on IP
address
Additional features
Packet fragmentation and reassembly if packet too
large for infrastructure
Priority indication
Broadcast capability
Figure 1-9. IP Protocol LX073.2
Notes:
The IP protocol is the packet delivery protocol of the TCP/IP protocol suite. It is comparable
to the Postal Service: It delivers the packet independent of the physical infrastructure such
as train, airplane, car, bike, horse-and-cart.
IP uses a best-effort approach: it tries to deliver the data to the destination, but in order to
be efficient, it does not make any guarantees as to if and when the data will arrive. It may
well be that different packets that make up a connection will take a different route and will
arrive in the wrong order, duplicated or not at all. It is up to the higher layer protocol to
correct this, or not.
The routing of IP packets is based on a so-called "IP address", which can be compared to
a ZIP code. At every hop, this IP address is read, a routing table is consulted and the
packet is send to the next hop, where again a routing table is consulted. These routing
tables are important, since a wrong routing table somewhere will mean that packets are not
sent to the destination via the shortest route, but will take a detour or will not arrive at all.
Routing has its own unit later in this course.

Student Notebook
The IP protocol offers some additional features as well:

• If a packet is too large for the architecture that it has to pass through, then a packet can
be fragmented into multiple, smaller packets who are sent individually to the
destination. At the destination, the fragments are reassembled.
• Each IP packet can have a priority indication which identifies the type of service that is
needed: low latency, high bandwidth, low cost or maximum reliability. Unfortunately, this
priority mechanism is not often implemented: all packets are often using the same path
to a destination, regardless of their type of service, and are transmitted on a first-come
first-served basis.
• The IP protocol offers a broadcast capability, using a specially formed IP address. This
allows you to send an IP packet to all systems on the local network (LAN). Some
higher-level protocols, such as DHCP, RIP, NIS and NTP use this to save bandwidth
and for automatic discovery of servers. The protocols mentioned will be covered later.

V3.0
Student Notebook
Uempty
Internet Address
Each host on an IP network needs an IP address

32 bits
should be unique
IP addresses are usually written in decimal-dot notation:
Binary 10000001 00100001 10010111 00000111

Decimal-Dot 129 . 33 . 151 . 7
Figure 1-10. Internet Address LX073.2
Notes:
In order to be able to deliver the IP packet to the correct destination host, every host needs
an IP address. These IP addresses are 32 bit values and have to be unique.
In most cases, the IP address is not written in its binary form, but in the so-called "decimal
dot" notation, where the 32 bits are grouped into four groups of eight bits each, and those
eight bits are written in decimal form, separated with dots.

Student Notebook
IP Address Assignment
IP Addresses assigned in groups ("classes") by the IANA

(Internet Assigned Numbers Authority) through ISPs
All addresses in a class have the first n bits in common
A class can be broken up to assign to networks
All hosts in a network have the first n+m in common
Thus, the first n+m bits identify the network
The last 32-n-m bits identify the host on the network
Example:
n=16 m=8
10000001 00100001 10010111 00000111

129 . 33 . 151 . 7
Assigned by IANA to this organization Assigned by this Assigned by the
organization to this network administrator
network to this host
Identifies the network Identifies the host
Figure 1-11. IP Address Assignment LX073.2
Notes:
IP addresses need to be assigned in such a fashion that they are unique across the whole
Internet. That's why there is a special organization that does this. This is the Internet
Assigned Number Authority, or IANA for short. They are responsible for assigning groups
of addresses (called "classes") to organizations. They do not do this directly, but have
contracted out that responsibility to the InterNIC (http://www.internic.net), who in turn
delegates this to local ISPs.
A class of IP addresses is a range of IP addresses who all share the same first n bits,
where n determines the number of IP addresses in the class. (The number of IP addresses
in a class is 232-n .) Obviously, every class is assigned only once, in order to prevent against
duplicate addresses.
There are a few standard classes, which can be assigned:
• Class A address ranges use n=8, which means that there are about 16 million IP
addresses in such a class.

V3.0
Student Notebook
Uempty All class A addresses have their first bit set to "0", so all addresses between 0.0.0.0 and
127.255.255.255 are class A addresses. Since the class A address range 0.*.*.* and
127.*.*.* are reserved for other uses, there are 126 usable class A address ranges,
each containing 16777216 IP addresses.
• Class B address ranges use n=16, which means that there are about 64 thousand IP
address in such a class.
All class B addresses have their first two bits set to "10", so all addresses between
128.0.0.0 and 191.255.255.255 are class B addresses. In total, there are 16384 class B
addresses, each containing 65536 IP addresses.
• Class C address ranges use n=24, which means that there are 256 IP addresses in
such a class.
All class C addresses have their first three bits set to "110", so all addresses between
192.0.0.0 and 223.255.255.255 are class C addresses. In total, there are 2097152
class C addresses, each containing 256 IP addresses
• In addition to the class A, B and C mentioned, there also exists a class D (starting with
bits "1110"), which is used for multicast addresses, and a class E (starting with bits
"1111"), which is used for experiments.
When an organization receives a class of addresses, it can then break up this class in
separate ranges who are each used on a separate network. In the visual, this is indicated
with m. Important in this respect is that the first n+m bits indicate the network, and the other
bits indicate the host on the network. Thus, you should set m so that 2m is larger than the
amount of networks you have.
As an example, consider an organization which has requested a large number of IP
addresses. The IANA has assigned it the class B address range 129.33, which means that
the first 16 bits of the IP address are 10000001 00100001. This organization has
determined that it is going to use a maximum of about 250 networks, with on each network
a maximum of about 250 hosts. It has therefore decided to split the class after the 24th bit,
and assign the numbers 129.33.0 through 129.33.255 to different networks in the
organization.
The last step then is to assign different IP addresses to different hosts in each network. In
the example above, we're talking about IP address 129.33.151.7, which means in our case,
host 7 on network 151 in organization 129.33. Or, shorter: host 7 on network 129.33.151.

Student Notebook
Subnet Mask
The subnetmask identifies which part of the IP address is

the network address, and which part is the host address
10000001 00100001 10010111 00000111

IP Address
129 . 33 . 151 . 7
11111111 11111111 11111111 00000000

Subnet Mask
255 . 255 . 255 . 0
Indicates: The first 24 bits identify the network last 8 bits identify
the host
Notation: 129.33.151.7/255.255.255.0
New, alternative notation: 129.33.151.7/24
Figure 1-12. Subnet Mask LX073.2
Notes:
The "Subnet Mask", also called netmask, identifies which part of an IP address is the
network address, and which part is the host address. This information is important to know:
with this, a host can determine whether another system is on the same network (the
network part of the IP address is the same) or not.
The Subnet Mask is again a 32-bit value, with all ones on the position of the network
identification, and all zeros on the position of the host identification. An IP address that has
the first 24 bits as network identifier and the last eight bits as host identifier will therefore
have a subnetmask consisting of 24 ones followed by eight zeros.
Subnetmasks are usually written down in decimal dot notation as well, yielding
255.255.255.0 in the example above. The full notation usually combines the IP address
with the subnetmask, yielding for example 129.33.151.7/255.255.255.0.
Recently, a shorter notation has become popular. Instead of writing down the subnetmask,
only the number of significant network address bits (number of ones) in the subnetmask
are written down, yielding 129.33.151.7/24.

V3.0
Student Notebook
Uempty
Special Internet Addresses
Several special addresses reserved by IANA:

Loopback: 127.0.0.1
Local network: host part all zeros (129.33.151.0)
Local broadcast: host part all ones (129.33.151.255)
Reserved for intranets not directly connected to the
internet:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Multicast addresses: 224.0.0.1 and up
Figure 1-13. Special Internet Addresses LX073.2
Notes:
The IANA has reserved several addresses and address ranges for special purposes. The
most important ones are listed here:
• The IP address 127.0.0.1 (in fact, the whole 127.0.0.0/8 network) is reserved for the
loopback address.
• Any IP address with the hostname part all zeros, such as 129.33.151.0, is reserved as
an identification for the network itself. It is not a valid IP address to be assigned to a
host.
• Any IP address with the hostname part all ones, such as 129.33.151.255, is reserved as
the local broadcast address. Data sent to this address is delivered to all systems on the
local network.
• Several ranges of addresses are reserved for intranets. These addresses will never be
assigned as official addresses and thus should never appear on the Internet. In fact, all
routers on the Internet are configured to silently discard packets sent to or originating
from these addresses.

Student Notebook
• Addresses 224.0.0.1 and up are reserved for multicasts. A multicast address is a

special address which is assigned on a per-application basis. All hosts that run a such
an application configure themselves to listen to that specific address. This makes it
possible for a server to transmit a data packet only once but to have it received by a
large number of clients spread out across different networks. Real-time radio for
instance can use multicasts to make efficient use of bandwidth.

V3.0
Student Notebook
Uempty
Off-the-byte Subnet Masks
Subnet Masks do not have to end at an 8-bit boundary

Gives more control on number of IP addresses
assigned to a network
Makes calculations much harder
Examples:
129.33.151.7/255.255.254.0 (= 129.33.151.7/23)
23 bits subnetmask
Network identifier is 129.33.150.0
Valid IP addresses: 129.33.150.1 - 129.33.151.254
Broadcast address is 129.33.151.255
129.33.151.7/255.255.255.128 (= 129.33.151.7/25)
25 bits subnetmask
Network identifier is 129.33.151.0
Valid IP addresses: 129.33.151.1 - 129.33.151.126
Broadcast address is 129.33.151.127
Figure 1-14. Off-the-byte Subnet Masks LX073.2
Notes:
Subnet Masks do not have to end at an 8-bit boundary. It is perfectly legal to end a subnet
mask after 23 or 25 bits for instance. This means that the maximum number of hosts on a
network, or the maximum number of networks in an organization can more precisely be
tuned to the real-world environment. It does make calculations a lot harder though.
Two examples are presented in the visual:
• The first example is using a 23 bits subnetmask. This means we can only create 27
(128) networks, but each network can hold 29 -2 (510) hosts. The calculations are as
follows:
10000001 00110001 10010111 00000111 129.33.151.7 (IP address)
11111111 11111111 11111110 00000000 255.255.254.0 (subnet mask)
10000001 00110001 10010110 00000000 129.33.150.0 (network identifier)

10000001 00110001 10010110 00000001 129.33.150.1 (lowest valid IP address)
10000001 00110001 10010111 11111110 129.33.151.254 (highest valid IP address)
10000001 00110001 10010111 11111111 129.33.151.255 (local broadcast address)

Student Notebook
• The second example is using a 25 bits subnetmask. This means we can create 29 (512)
networks, but each network can only hold 27 -2 (126) hosts. The calculations are as
follows:
10000001 00110001 10010111 00000111 129.33.151.7 (IP address)
11111111 11111111 11111111 10000000 255.255.255.128 (subnet mask)
10000001 00110001 10010111 00000000 129.33.151.0 (network identifier)

10000001 00110001 10010111 00000001 129.33.151.1 (lowest valid IP address)
10000001 00110001 10010111 01111110 129.33.151.126 (highest valid IP address)
10000001 00110001 10010111 01111111 129.33.151.127 (local broadcast address)

V3.0
Student Notebook
Uempty
ICMP Protocol
Used to communicate error and control messages for IP,

UDP and TCP
Integral to IP operation, but functionally separate
ICMP messages are sent using IP datagrams
Reports back on any IP error with the exception of:
Errors with IP packets containing ICMP messages
Packets discarded because the source or destination
address is an address reserved for intranets
Used in ping to verify if a host is alive
$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=0 ttl=128 time=1.5 ms
--- 10.0.0.2 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.8/1.0/1.5 ms
Figure 1-15. ICMP Protocol LX073.2
Notes:
The ICMP protocol is a separate protocol in the TCP/IP protocol suite, and is used to
communicate error and control messages for IP, TCP and UDP. Example messages that
can be communicated by ICMP are:
• Destination host unreachable
• Network overloaded - slow down
• Checksum error
All ICMP messages are sent using IP packets.
Any error that is detected in a TCP/IP network is reported, except for two cases: Errors that
were detected in IP packets that contained ICMP data, and packets that were discarded
because any of the IP addresses used in it is not allowed on the Internet.
Another function of ICMP is to transmit control messages. The most important example of
this is ping, which sends an ICMP echo request message, to which the recipient responds
with an ICMP echo reply. By calculating the round-trip time and by counting the number of
requests against the number of replies, you can get a good estimate of the line quality.

Student Notebook
Ports and Sockets
A port identifies the application on the host

Server side ports are well-known and fixed
Stored in /etc/services
e.g. telnet is 23, http is 80
Client side ports are dynamic, > 1023
Every client connection uses a new port
A socket is a combination of IP address, protocol and
port and identifies an application uniquely on the network
TCP and UDP both implement ports, independent of
each other
Figure 1-16. Ports and Sockets LX073.2
Notes:
When IP delivers the data to the correct host, it hands the data over to either the TCP or the
UDP protocol. Among other things, it is the duty of these protocols to determine to which
process the data needs to be delivered. This is done using a mechanism of port numbers.
It is easiest to compare this concept to the concept of PO Boxes.
Every application that wants to communicate requests a free port from the operating
system. There's two ways an application can do this:
• A server application (meaning: others will try to connect to it) requests a specific port
number. The port number that "belongs" to an application is well-known. In fact, the
IANA assigns these ports to applications. A webserver will therefore always listen to
port 80, for example.
• A client application (meaning: it will try to connect to another application) will request a
dynamic port, an arbitrary port above 1023. This port is then used as source for the
connection to the server. In general, for each new connection, a new client port is
requested.

V3.0
Student Notebook
Uempty Traditionally, and still valid under Linux, only programs that are running with root privileges
can requests ports below 1024. These ports are therefore also called "secure ports".
There's nothing secure about them any more, since every hacker can install Linux and run
applications as root anyway.
The term socket is the combination of IP address, port and protocol (TCP or UDP). The
combination of these three parameters uniquely identifies an application on your network.
TCP and UDP both implements the concept of ports. Since the protocol is different, the
implementation is different and these ports are not compatible or interchangeable. You
cannot communicate between a UDP based socket and a TCP based socket, for instance.
Yet, the IANA has tried to keep the portnumbers the same for both TCP and UDP. As an
example, port number 7 is reserved for the echo application, regardless of whether the
echo application uses TCP or UDP.

Student Notebook
UDP Protocol
Connectionless application interface to IP

Does not guarantee packet delivery or duplication
protection
Main usage:
Broadcast/multicast traffic
Real-time communications (streaming audio/video)
Traffic with low overhead requirements (e.g. DNS,
NFS)
Figure 1-17. UDP Protocol LX073.2
Notes:
The UDP protocol is nothing more than a simple interface to IP, with the addition of the
ports concept. As with IP, UDP does not guarantee packet delivery or duplication
protection.
At a first glance, this seems senseless. Which application is going to accept the loss of its
data? However, there are a few applications that benefit from this:
• Applications that use broadcasts or multicasts. If you talk to ten, twenty, a hundred or
more systems at once, for instance when doing Internet radio broadcasts, you probably
can't or will not want to handle the complexities of every system reporting back to you
which packet they received and not, and resend all the packets that were lost.
In such situations, if a packet is lost, nothing is being done because nothing can
reasonably be done about it.
• Another reason for using UDP when doing streaming radio and/or video is that time
goes on. If a packet is lost and you want to resend it, you have to interrupt the stream

V3.0
Student Notebook
Uempty momentarily, and can only continue when the packet has been resend. This might take
a few seconds, and all that time the user is staring at a blank screen.
It is more likely that the user, in case of a lost packet, will accept a little static on his
screen for a few milliseconds.
• The third reason why an application might want to use UDP is the low overhead of UDP.
This is really important where performance is critical, and the chance of data loss is low
and can be handled. The typical example is NFS (Network File System) on a Local Area
Network.

Student Notebook
TCP Protocol
Connection-oriented application interface to IP

Ensures reliable communications
Duplication, out-of-order protection
Retransmission of missing packets
Pacing (adapt number of packets sent to available
bandwidth)
Main usage:
Unicast, reliable connections such as http, telnet, ftp,
mail
Figure 1-18. TCP Protocol LX073.2
Notes:
The TCP protocol is far more ingenious than UDP. It offers a connection-oriented interface
to IP, which basically means that, if applications use TCP, a reliable data transfer is
guaranteed. If IP packets are lost, duplicated or arrive out of order, the TCP protocol will
take all necessary actions to correct this and will deliver the data to the application in
exactly the same way as it was sent.
This makes TCP the suitable protocol for all applications that require unicast (one-to-one),
reliable communications. Examples of these applications include webservers, telnet, ftp,
mail and so forth.
This reliability comes at a cost though: the overhead of communicating via TCP is much
higher. Some of the problems that need to be handled by TCP are:
• Connection setup: check whether the other party is alive and able and willing to receive
data on a certain port.
• Out-of-sequence arrival of packets.
• Duplicate arrival of packets.

V3.0
Student Notebook
Uempty • Acknowledgement of packets and retransmission of lost packets and lost

acknowledgements.
• Pacing: A method where multiple packets can be sent before the sender expects
acknowledgement.
• Connection closing: A connection can only be closed once all parties have sent all the
data they wanted to send.

Student Notebook
Name Resolution
A symbolic hostname exists for (almost) every IP address

Easier to remember
More flexible: hostname is not linked to the physical
network a server is on
All hosts need a way to resolve the hostname to an IP
address and vice versa
Flat network
Hostname is a single word, e.g. nfsserver1
Mapping stored locally
Domain network
Hostname is a hierarchical name, e.g. www.ibm.com
Mapping stored in global Domain Name System (DNS)
Figure 1-19. Name Resolution LX073.2
Notes:
So far we've only talked about IP addresses. As it turns out, these IP addresses are really
hard to remember. This is why the concept of hostnames was invented. Hostnames are
symbolic names that are mapped to IP addresses. Through a process called "name
resolution", the IP address that belongs to a hostname can be retrieved. And obviously, the
reverse process is needed as well.
There's another advantage to using hostnames too. If you only tell the hostname of a
server to your users, and not the IP address, you are faced with a far smaller problem if you
decide to move that server to another IP network. In that case, you only have to change the
mapping of the hostname to another IP address in a few places, instead of telling all users
the changed IP address.
There are basically two ways of storing the mapping:
• The first method is called a flat network. In this case, all hostnames are single words,
like nfsserver1. The mapping of hostnames and IP addresses is stored in a file (usually
called /etc/hosts) which is then distributed over the network (either manually or by using
a system such as NIS).

V3.0
Student Notebook
Uempty The main characteristic of this method is that there is one logical entity (network
management) who is responsible for the maintenance of the complete mapping of every
system in the network.
• In a large organization, or on a network such as the Internet, it becomes totally
impossible to have one entity that is responsible for the mapping of thousands or
millions of IP addresses to hostnames and vice versa. And decentralizing the
responsibility but keeping a central file where everybody makes his changes is
absolutely impossible. To cope with this problem, the Domain Name System was
created.
The Domain Name System is a global, distributed database. Every network
administrator maintains its own table, which describes its own network, and is stored on
its own server. All these tables are linked to each other using a hierarchical structure.
That hierarchical structure is reflected in the hostnames. A "Fully Qualified Domain
Name" consists of the hostname, subdomains and the Top Level Domain (TLD) where
the host resides. An example is www.ibm.com. This domain name basically means: The
host called www in the subdomain ibm in the top level domain com. To resolve this
hostname to an IP address, you first go to a root server. There's only a handful of them
and their IP addresses are well known. The root server will point you to the DNS server
of the .com domain. The .com name server will point you to the .ibm.com name server,
and the .ibm.com name server will provide you with the IP address of www.ibm.com.
For simple networks that are not directly connected to the Internet, a flat network is usually
the easiest approach. For larger networks, or networks that are directly connected to the
Internet, DNS is being used.

Student Notebook
Checkpoint (1 of 2)
1. T/F. IP addresses must be unique for each interface on the
network.
2. T/F. Protocols define rules for orderly communications.
3. A socket consists of:
a. A machine address and port number
b. An IP address, port number and protocol family
c. A machine address and IP address
d. A host name and port number
4. How many bits make up the unique physical address of a Token
Ring or Ethernet adapter?
a. 16
b. 32
c. 48
d. 64
5. How many bits make up the Internet address?
a. 16
b. 32
c. 48
d. 64
Figure 1-20. Checkpoint (1 of 2) LX073.2
Notes:
Write down your answers here:
1.
2.
3.
4.
5.

V3.0
Student Notebook
Uempty
Checkpoint (2 of 2)
6. What are the two pieces of an Internet address?
7. T/F. The common form of an Internet address is four octets in

decimal form known as decimal dot notation.
8. What is the special address 127.0.0.1?
9. T/F. ARP is used on networks which do broadcasts at the lowest

level and thus need MAC addresses to identify the recipient.
10. What is the reason for a port number in the UDP and TCP
headers?
11. T/F. IP guarantees delivery of datagrams in the same sequence

as they are sent.
Notes:
6.
7.
8.
9.
10.
11.

Student Notebook
Unit Summary
TCP/IP is a protocol suite consisting of several protocols

The main protocols used in the TCP/IP protocol suite are
IP, ICMP, ARP, TCP and UDP along with many network
interface and application protocols
The Internet Protocol has a 32-bit, two-part logical
address which represents a network and a host address
When provided an IP address and a mask the network
and host addresses can be determined
The UDP protocol provides connectionless, unreliable
data communications
The TCP protocol provides connection oriented, reliable
data communications
Figure 1-22. Unit Summary LX073.2
Notes:

V3.0
Student Notebook
Uempty Unit 2. Configuring TCP/IP

This unit covers the configuration of TCP/IP. It describes the files that
are used by TCP/IP and the commands that can be used to gather
information about your configuration.

• Configure TCP/IP
• Test the TCP/IP configuration

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 2. Configuring TCP/IP 2-1

Student Notebook

Notes:

V3.0
Student Notebook
Uempty

!
! !
#$
%%&

'

Figure 2-2. TCP/IP Configuration LX073.2
Notes:
Most Linux distributions include the configuration of TCP/IP in the installation process. This
is fine for a simple workstation but it doesn't help us if we need to reconfigure TCP/IP, or if
we've got multiple adapters in our system. That's why, in this unit, we will take a look at
configuring TCP/IP manually.
Manual configuration of TCP/IP requires several steps:
• Configure the hostname
• Configure the adapters
• Assign IP addresses
• Define routing information
• Configure hostname resolution
Each of these steps will be covered in the next few visuals.
Note that you can do all this completely by hand. You need to edit various configuration
files and run various commands. But most distributions also include handy tools for
configuring this. These are listed in the visual. In addition to this, general configuration tools
like webmin can also be used.

Student Notebook

' *

!

!
#$! *+
%%&$<%@&
Figure 2-3. Configure Hostname LX073.2
Notes:
The host name of a system is a unique name which is used by applications on the local
system. This name is used in, for instance, outgoing email and should thus be the name
that the network administrator has assigned to your host.
The hostname is set using the hostname command, which can also be used to retrieve the
hostname.
If you want to configure your hostname permanently, you need to store it in the correct
configuration file for your distribution. Red Hat stores the hostname in
/etc/sysconfig/network while SuSE stores the hostname in /etc/HOSTNAME. When the
system boots, this file is read and the hostname command is executed to set the
hostname.

V3.0
Student Notebook
Uempty
!"

**
! J !
%

%

!

!
K K

+
K

!

""

#
&'*+7;<>
?
"
@ <+7;<""
@A
!

!

"B
Figure 2-4. Configure Adapters LX073.2
Notes:
As Linux boots, it will autodetect most adapters and configure them automatically.
However, some adapters will not be autodetected:
• Linux is configured to only detect one Ethernet adapter. Since most people have only
one, this normally is not a problem. If you do have more, you need to make sure the
kernel knows about them, and knows which of the adapters you want to call "eth0" and
which one "eth1".1
• Some adapters cannot be probed correctly. Probing for an adapter (figuring out if it is
there) is done by leaving data on a certain I/O address which is specific for that adapter.
If the adapter reacts, Linux knows it's there and can configure it further. If the adapter
does not react, it is apparently not there. The I/O addresses that can be used by each
adapter are well-known. However, certain I/O addresses overlap with other devices and
may cause the system to hang. Linux, as a safety feature, by default does not probe
such addresses. And furthermore, an adapter may be configured on an I/O address
1 Suppose you are running a firewall with one adapter in the secure network, and the other in the insecure network, and Linux detects
these adapters in the reverse order...

Student Notebook
which is not probed at all. In both cases, the user is required to configure the I/O
address and IRQ line manually.
Note that this does not apply to PCI or ISA PnP adapters, only to the traditional ISA
adapters. PCI and ISA PnP adapters have standardized identification mechanisms and
need not be probed like traditional ISA adapters.
To configure these I/O and IRQ addresses, you need to know how support for that
particular adapter is compiled.
• For adapters for which support is compiled into the kernel image itself: Supply the
information to Linux at boot time, either at the Lilo boot:-prompt or as an append
statement in /etc/lilo.conf.
• For adapters for which support is supplied in the form of kernel modules, add the
information to the /etc/modules.conf file.
Most distributions compile ethernet adapter support as modules.
When using the configuration tools of the distribution, this work is typically done for you.

V3.0
Student Notebook
Uempty
! !
' *

7!77A
?
*
*
+
!
#$! *+ QJYQZ
%%&! *+JYQZ
QQ !
JYQZ "

C

Figure 2-5. Assign IP Addresses LX073.2
Notes:
The ifconfig command configures or displays network interface parameters for a network.
If a machine has more than one adapter card that will be used for TCP/IP, like a router, then
the ifconfig command needs to be executed for each adapter.
To display configuration information, simply enter ifconfig or ifconfig <interface>. While
any user can query the status of a network interface using ifconfig, only a user who has
root authority can modify the configuration of the interface.
If you want to make your changes permanent, you have to add them to the startup
configuration files. Red Hat stores this in /etc/sysconfig/networking/devices/ifcfg-<device>
while SuSE uses /etc/sysconfig/network/ifcfg-<device>.
Two additional commands are handy: ifup and ifdown bring a network adapter up or down,
but use the information in ifcfg-<device>. This means that their only argument is the name
of the device.

Student Notebook
#$ !"
[&&&\]^K__
+

**`

j +
{{
%%'%Q%'
[& !
+!
' *
C
7"

DEFHJK
7+LA;!
!

JYQZ

*

<
$ j * *+
"'
! |!
Figure 2-6. Configuring Wireless Adapters LX073.2
Notes:
Linux has full support for wireless network adapters that conform to the IEEE 802.11
standard. These adapters are generally configured like any other ethernet adapter (their
device name is even “eth0”), but they do require a few extra parameters. The three most
important parameters are:
• The link speed. Several flavors of link speeds exist, with 11 Mbps being the most
common today. You have to choose the correct link speed for your network. Most
adapters configure the link speed automatically if you set this to “auto”.
• The SSID (Service Set IDentifier). This string is used to identify the network that you
want to connect to. It’s usually a symbolic name (32 characters maximum) which refers
to the organization or department running the network. All network adapters, access
points and other pieces of infrastructure that belong to a network should have the same
SSID.
• The WEP (Wired Equivalent Privacy) encryption keys in use. The original wireless
protocols did not have any security features built-in, which meant that everybody who
happened to be in the neighborhood would get unlimited access to the network.

V3.0
Student Notebook
Uempty To add more security to the standards, WEP was added to the standards. This allows
you to encrypt all packets on the network. This encryption is done in the wireless
adapter itself, and thus is completely transparent to the rest of the system, if the keys
have been set up correctly.
WEP keys can be 40 or 128 bits. Obviously you will want to use 128 bit keys for
additional security as compared to 40 bits. But don’t be fooled: the way WEP is
integrated in the standards has been the subject of a lot of criticism from the security
community. This criticism was justified, since programs like airsnort are able to
(passively) listen to the traffic, and once they have gathered enough data, break the
encryption (even 128 bits) in a matter of minutes.
Most wireless adapters also allow you to store the WEP key on the adapter itself, using
proprietary tools. That way, you don’t need to specify the WEP key in your operating
systems configuration files, and thus prevent users from obtaining the WEP keys.
Typical adapters support four on-board keys. To select key 2, use key [2].
Security experts therefore suggest that you should consider your wireless LANs to be
as secure as your internet connection: not secure at all. In addition to WEP, you should
also configure additional security measures to make sure that no unauthorized access
is gained via the wireless network to your internal network.
Wireless security beyond WEP is beyond the scope of this course.
In order to set all these (and more) parameters, you are going to need the iwconfig
command. It works more or less like the ifconfig command. See the visual for an example.
Most distributions, including Red Hat and SuSE, have full support for wireless networks
built into their configuration tools, scripts and files. The wireless parameters (link speed,
SSID, WEP keys and a few other options) are stored in the same files where the IP
configuration details are stored as well: ifcfg-<device>. Also, redhat-config-network and
yast have full support for configuring these parameters.
A few other tools that are useful when working with wireless networks are:
• iwlist: Lists information on the wireless network(s) that are reachable by your adapter.
• iwspy: Displays signal strength and quality of the current association.

Student Notebook
!$
}

}*
}
*+
! *+

$JQ!

] ]]]_KKK
*

M
@ <
M

M
Figure 2-7. IP Aliases LX073.2
Notes:
With IP aliases, you can assign multiple IP addresses to one adapter. Although in most
cases this is not necessary, it can be useful. Some examples:
• Certain reasons (such as IP address shortages) may require you to run multiple logical
networks (multiple, different IP address ranges) on one physical network. In order to be
able to communicate with each other, one or more systems need then to be set up with
two IP addresses, one in each range, on one adapter. This system will then act as a
router between the two logical networks.
• The above situation is especially true when an organization is in the process of
transitioning from one IP range to another. When doing that, there is typically a brief
period of time when both IP ranges are in use.
• Another situation where IP aliases are used often is in High-Available clusters. In these
clusters, each of the systems gets a permanent IP address, called the service address.
This is statically assigned to a system and is used for system maintenance and testing.
In addition to this, a production IP address is assigned to the cluster as a whole. The
system that is running the production gets this IP address assigned as an alias and thus

V3.0
Student Notebook
Uempty receives the load. If the production system fails, it's just a matter of adding the alias IP
address to the backup system, and the load automatically gets diverted to the backup.2
• A last usage of IP aliases is in testing. Suppose for instance that we are testing routing
protocols. If we would not have IP aliases, this would require us to have a lot of network
hardware (hubs, adapters, cables, routers) available. With IP aliases, we can just
configure multiple logical network on one physical network and run our tests
nevertheless. In fact, this is exactly what we're going to do in the routing unit.
Configuring IP aliases is really simple under Linux. If you want to configure an alias on
eth0, you just configure the device eth0:0 as if it were a separate device. This enables the
first alias. The second alias is obviously eth0:1, and so forth. The maximum number of
aliases you can use is 255.
2 That's the principle at least. Reality is much harder. As they say "In theory, theory is the same as practice. In practice however, there is
a difference".

Student Notebook
%$&
'#{*!{! *+

%
"

7!777
*
Q
+
!
#$! *+
! *+ QJYQZ~
%%&! *+
! *+JYQZ~
~

JQ !
KK

* Q !
Figure 2-8. Configuring the Default Route LX073.2
Notes:
When you configured the IP address and the subnetmask, you should be able to
communicate with everyone on your local network. If you want to communicate with
someone outside the local network, you need to configure the IP address of the router
which connects your network to the outside world. This is called the default router, and the
route to it (essentially its IP address) is called the default route.
The default route is configured with the route command, which can also be used to show
the routing table.
Again, if you want to make these changes permanent, you need to add the default routers
IP address to /etc/sysconfig/network (Red Hat) or /etc/sysconfig/network/routes (SuSE),
depending on your distribution. Most distributions also allow you to configure a default
route in a device-specific file. This is useful on laptops, where different adapters are used in
different locations, and each location has a different default gateway.
Note: If you have multiple routers in your network, or if you are a router yourself, you need
to set up more advanced routing. This will be covered in the routing unit.

V3.0
Student Notebook
Uempty
'& $
$

Q!*Q

&

%
'@% QK
Figure 2-9. Configuring Name Resolution LX073.2
Notes:
Symbolic hostnames like www.ibm.com are easier to remember than IP addresses like
129.42.16.99. That's why almost every IP address will have a hostname associated with it.
Every host on an IP network will need to be able to "resolve" a hostname into the
corresponding IP address. There's basically two ways of doing things:3
• By adding all hostnames and IP addresses you will want to use to the /etc/hosts file.
• By configuring DNS, using the /etc/resolv.conf file.
3
Technically, NIS also offers this ability. But you generally will not want to use NIS to do this.

Student Notebook

O
"

M
QRS"
TQ&
TQS
T

7A7 ?

7!77AUA
7!777U7"
"
7!777U77
7!77U
Figure 2-10. /etc/hosts LX073.2
Notes:
The /etc/hosts file has the following syntax:
<IP Address> <Hostname> <Aliases>
Entries that should always be included in /etc/hosts are loopback and the local machine.
Additionally, you might want to include other machines on your network, especially if DNS
is not being used.
Aliases can be created in this file by entering them after the host name. Each alias is
separated by a space. Aliases cannot exceed 255 characters and each entry must be
contained on one line.
If a network relies on /etc/hosts files exclusively to do name resolution, then each /etc/hosts
file should contain an entry for each system on the network. You therefore need to keep all
/etc/hosts files synchronized. This method of name resolution is called flat name resolution,
and these networks are called flat networks.

V3.0
Student Notebook
Uempty
$*

" UV

"@
"7!777

"@
"7!77
Figure 2-11. /etc/resolv.conf LX073.2
Notes:
If we want to use DNS for name resolution, there is another file that needs to be edited:
/etc/resolv.conf.
The most important line in this file is the nameserver line, which identifies the IP address
(why not the hostname?) of the DNS server to be used. There can be a total of three
nameserver lines in /etc/resolv.conf, and each nameserver will be queried in turn until the
answer is returned.
You may also specify one or more search directives. When DNS is used, hostnames are
so-called "Fully Qualified Domain Names", for example sys7.acme.com. If you use
systems in the acme.com domain a lot, it becomes a drag to type this name every time
over and over again. (And domain names can be much worse than acme.com...) With the
directive search acme.com in the /etc/resolv.conf file, the domain acme.com is
automatically added to a hostname, when a name lookup is done. So instead of typing
sys7.acme.com, you may also type sys7.
You may specify multiple arguments on a search line, and may specify multiple search
lines in the /etc/resolv.conf file.

Student Notebook
The domain argument is sometimes used as well. This specifies the DNS domain the host
itself is in. This is especially useful if your hostname is not set to the fully qualified domain
name (which happens a lot to mobile workers with laptops who connect to different
networks). Only one domain stanza may be present. If a domain stanza is present, this
domain is searched as well, just like a search directive.
Note: Setting up a DNS server is covered in a later unit.

V3.0
Student Notebook
Uempty

+
!

!
!#
! Q!
!
!

Figure 2-12. Testing Your Configuration LX073.2
Notes:
Testing your configuration is done by executing a number of steps. These steps will be
covered in the next few visuals.

Student Notebook
.0$

'?
MF
"
&W"MMMLM;7MM7

"M7!77AD M7!77E?M
JRD#XSHKSYO#JZZZ[EJ'OKSYOEOJM7E
" M7
#\ ?
M+!
"""M"
M@
""M"
M
O\ ?
M
"""M"
M@
""M ""
"M
MB

M7

""M!D
"
M7
'?
M' ' ?

"M7A7E?M
JR'XXRDSK]#JZZZ[EOJM!+E
" M7
#\ ?
M
"""M"
M@
""M"
M
O\ ?
M
"""M"
M@
""M ""
"M
MB

M
Figure 2-13. Verify Local Interfaces LX073.2
Notes:
The ifconfig allows you to verify the configuration of your local interfaces. The visual
shows a correct configuration.
If an interface which is supposed to be configured does not show up, you can do a specific
query for that interface with the command ifconfig <interface>. If something shows up, it
is most likely that the interface was not configured or not brought up. If you get an error
message, then the adapter itself has not been configured. (Did you load the correct
modules? Did you specify the correct IRQ and I/O address? You can run the dmesg
command to see the kernel output, and verify that the kernel did detect and enable the
device.)

V3.0
Student Notebook
Uempty
.&
"
]
"
R"
H
[
CU[
?Ê
" #
J

7!77`J

7!777J[

Figure 2-14. Verify Routing LX073.2
Notes:
The route command allows you to view the routing table. It should look roughly like the
output above. Further discussion of the routing table will be done in the routing unit.

Student Notebook
.!&
$
"
S"
&WU
&W"
Ê?
7!777

"MSM+M;SM;MDSK

Figure 2-15. Verify ARP Table LX073.2
Notes:
The arp command shows the contents of the ARP cache table. It should list all IP
addresses and MAC addresses of hosts on the local network with which you've had contact
in the last 20 minutes or so.
If a MAC address shows up as "incomplete", then an ARP request was sent but no reply
was received. The remote host is possibly not turned on, or there is a network problem.
By looking at the ARP cache table on various hosts, and comparing the MAC address that
belongs to a specific IP address, it is possible to detect duplicate IP addresses on a
network.
The arp command can also be used to delete entries from the cache, and to manually add
entries to the table. Manually added entries will never be deleted from the cache.

V3.0
Student Notebook
Uempty
.
7!777
RZ[7!777*7!777>" 7!77AML*;+>U

L+U
" 7!777M V
B

L+U
" 7!777M V
B7
A
L+U
" 7!777M V
B
A
L+U
" 7!777M V
B
A
hK
<<<7!777 <<<
+ ?
"
+ ?
"

@
j ?

"<" @ A7A
Figure 2-16. Verify Connectivity LX073.2
Notes:
With the ping command you can verify that a system is alive and responding to ICMP echo
requests. You can also get an idea about the quality of the connection between the two
systems.
ping will go on endlessly. To interrupt it, hit Ctrl-C.
If a host does not respond to a ping, you generally have a low-level network problem, or a
routing problem. Try pinging the router first.
In case a host is firewalled (certain ports are blocked using filters), a host may be
configured not to respond to pings.
The ping command has options to increase the size of the packets that are being sent, to
increase or decrease the time between packets, to send only a number of packets, and to
record the route the packet travels.

Student Notebook
. & $
UA
UA UV "
7!77A
7!77A
A777!Z<SHH#S#RS

"UA UV
Figure 2-17. Verify Hostname Resolution LX073.2
Notes:
The host command allows you to test hostname resolution. When given the hostname as
argument, it tries to find the corresponding IP address or IP addresses. When given the IP
address, it tries to find the corresponding hostname.4
Please note that the host command only performs a DNS lookup. If you are using a flat
network where only /etc/hosts files are used for name resolution, you can't use the host
command but will have to look in /etc/hosts by hand.
If no hostname can be resolved, try using the fully qualified domain name, and check
/etc/resolv.conf. If the hostname can be resolved into an IP address, but not the other way
around, then the DNS server is malconfigured and you need to inform the administrator of
the DNS server.
4 The latter is done by converting the IP address into a pseudo hostname which ends at in-addr.arpa. That's where the strange output in
the second example comes from. We will cover this in the DNS unit.

V3.0
Student Notebook
Uempty
."

<
S @

"

*
"@
"

>
R"#
@<wY
<w' S"
^"
S"
Y

`MCCC`M`'YOFZ
`M `M`'YOFZ
`M"
"`M`'YOFZ
`M`M`'YOFZ
`M
"`M`'YOFZ
`M

`M`'YOFZ
`M`M`'YOFZ
`M
`M`'YOFZ
`M

`M`'YOFZ
`M`M`'YOFZ
`M?`M`
`M?`M`
"C`M `MÀ
"C`M `MÀ
Figure 2-18. Verify Open Ports LX073.2
Notes:
The last thing you might want to verify is what services you are offering to the outside
world. Remember: Every server service you are running requires a specific, well-known
port.
The netstat -a command lists all open ports, both the server ports (which are in the
LISTEN state), and any client connections to or from any port (which are in the
CONNECTED state). It also lists any Unix sockets (which are not covered in this class and
not shown in the visual, but will normally show up right after the TCP/IP ports).
If you want to see port numbers instead of symbolic port names (which are taken from
/etc/services, by the way), use the command netstat -an.

Student Notebook
"
_K [ **

+ *+
^K [ !

K [ *
!* !

K [ ** *+

+ *+

Figure 2-19. Checkpoint LX073.2
Notes:
1.
2.
3.
4.

V3.0
Student Notebook
Uempty
34
*

+

%

'

}!

! Q

Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 3. The inetd Daemon and inetd Services

This unit describes the inetd daemon and the various services that are
commonly run from inetd.

• Describe and configure the inetd daemon
• Describe and configure the tcpd daemon
• Describe and configure the xinetd daemon
• Describe, configure and use the most common inetd services

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 3. The inetd Daemon and inetd Services 3-1
Student Notebook

'
'

' `
'
Q
Notes:

V3.0
Student Notebook
Uempty

54"5%
!
Q *JQ

+

KKK
' * * Q
!
%
j

%Q
*

' JQ

Figure 3-2. The inetd "Super" Daemon LX073.2
Notes:
A typical TCP/IP server on a network offers a range of services to the networked users and
the administrators of that system:
• telnet, so users and administrators can login remotely to the system.
• ftp, so users and administrators can up- and download files.
• talk, so that users can chat with each other.
• finger, so that users can retrieve information about each other.
All these services are typically low-usage services: Most Linux systems are not used for
interactive logins (telnet) by users, but run some sort of network server like Samba or
Apache. So typically only the administrator uses telnet to do remote management. File
transfers, on most systems, are also only done a few times per day, at most. And the days
of talk and finger are over, but might be offered out of nostalgia.
There is a catch here though: even though a service may only be used once a month, you
never know when you are going to use it. So you need to have a daemon running all day to
Student Notebook
offer this service. If you have a large number of services like this, you are wasting
resources, particularly memory.
That's why the inetd daemon was invented. This daemon runs all day on behalf of various
low-usage services, and watches all ports of these services. If a connection comes in for a
service, the inetd daemon starts the corresponding service daemon.
Note that starting a daemon for each incoming connection is rather expensive: Instead of
having one or a few processes handling all connections (like a webserver does), you need
to start a new process. That's why the inetd daemon should not be used for high-usage
services such as http.

V3.0
Student Notebook
Uempty
*

"
C"
"

" C"
"
" "
C"
"
" " C"
"
U
"
C"
"
U
" C"
"
"
"
C"
"
"
" C"
"

"
C"
"

" C"
"
"
C" " <<

"
C""

"
C" " "
"
C" " "

"
C" " "

? " C UU " ?
? " C UU " ?
<"
C""
<"
C""
"
C""
Figure 3-3. /etc/inetd.conf LX073.2
Notes:
The /etc/inetd.conf file describes the services that should be watched by inetd. The file
consists of six columns which are separated by whitespace (spaces or tabs). Every line
that starts with a hash (#) is commented out.
The first column lists the identification of the service. This is the IANA registered name for
the service, and should be listed in the /etc/services file.
The second column lists the protocol type of the service. For historic reasons several
options are possible here, but today the two possibilities are "stream", for TCP
connections, and "dgram", for UDP based services.
The third column lists the actual protocol, tcp or udp.
The fourth column describes whether the service is multi-threaded or not, and thus what
inetd should do when a request comes in. If this is set to "wait", which is the default for udp
connections, then inetd will not accept any additional incoming data, when the service for
that port has been started. All data coming in should thus be handled by the daemon that
was started. In contract, when this column is set to "nowait", then inetd will keep listening to
Student Notebook
the port, and fork a new daemon for every new connection. Thus, every daemon only
needs to handle one single connection.
The fifth column lists the userid and possibly the groupid as which the daemon should run.
The sixth column contains the command to be executed, and any options for that
command.

V3.0
Student Notebook
Uempty

"#""%
&`! Q

{
K
JJ{
" |Q
K* K !
*"{ K
JJ{
+
# Q'@%+
*+

Figure 3-4. The tcpd Wrapper Daemon LX073.2
Notes:
In the early days of the Internet, everybody was allowed on every machine. When the
Internet grew however, people started realizing that this was not a good idea, and a need
for IP-based security was becoming apparent. This was added with the tcpd wrapper
daemon.
The tcpd wrapper daemon sits between the inetd daemon and the service daemon (e.g.
in.telnetd or in.ftpd). It is started by inetd for every incoming connection. It then checks the
source IP address and/or hostname against the files /etc/hosts.allow and /etc/hosts.deny.
Only if a connection from that host is allowed does it actually start the service daemon
itself. Otherwise it just closes the connection and exits.
Note that this is completely transparent to both the inetd daemon and the service daemon.
And if the connection is allowed, it is even transparent to the user. To the system
administrator however, this adds a great deal of control over who is allowed to connect to
your system.
There is one little catch here though: Because access control can be based on hostname,
tcpd requires reverse DNS lookups to work. This will be covered in a later unit.
Student Notebook
*$$ *
%! `
%Q$
%Q !
6 !00
$ !
'@%
jj
+
K**Q*
K ! Q !
<**
&`

C

M !;

U
S''MS''
`
"
Figure 3-5. /etc/hosts.allow and /etc/hosts.deny LX073.2
Notes:
The /etc/hosts.allow and /etc/hosts.deny files both have a list of services and hostnames
that are allowed to make use of that service, or not. The general syntax of both files is
Service: Hostlist
The service is generally the name of the executable, such as in.telnetd. Multiple services
can be specified on one line, if they are separated by commas. The "ALL" keyword applies
to all services, and the notation "ALL EXCEPT service, service" applies to all services
except the services listed.
The hostlist is a comma-separated list of hostnames ("www.ibm.com"), domain names
(".ibm.com"), IP addresses ("129.33.151.7"), IP address ranges ("129.33.151.",
"129.33.151.0/255.255.255.0"or "129.33.151.0/24"), the keyword "ALL" or the combination
"ALL EXCEPT hostlist".
The /etc/hosts.allow file is checked first. If the client is listed there for the service involved,
the connection is allowed. The /etc/hosts.deny file is checked next. If the client is listed
there, the connection is not allowed. If no file matches, then the connection by default is
allowed. So, in order to run a "secure by default" server, add "ALL: ALL" to your

V3.0
Student Notebook
Uempty /etc/hosts.deny file and allow specific service and client combinations in /etc/hosts.allow, as
shown in the example.
An additional feature of the /etc/hosts.allow and /etc/hosts.deny files is the ability to start a
command when a match occurs. This is done by adding a second colon at the end of the
hostlist, followed by the "spawn" keyword, followed by the command to be executed.1 In
order to pass information to the command being executed, a few variables have been
defined:
%c Is being replaced with the IP address of the client.
%s Is being replaced with the IP address and name of the service
that was accessed.
For more variables, see man hosts_access.
1 This seems like a useful feature, but can actually backfire, because a hacker might use this to do a Denial of Service (DoS) attack. For
example, if you were to log a failed connection into a logfile, then each connection will take about 60-80 bytes on disk. But a hacker only
needs to send a few bytes to simulate opening a connection. That makes it real easy for a hacker to fill your disks. And it can be even
worse. As part of the command string, people have used finger to retrieve information about the user that made the connection. The
user knew this and linked his .plan file to a character generator. This caused a buffer overflow in the finger client on the server, and
ultimately caused the server to crash.
Student Notebook

754"5%
%
" !
! `
!` K
Figure 3-6. The xinetd "Super" Daemon LX073.2
Notes:
Recently the xinetd daemon has been released on the Internet. It is intended to be the
successor of the inetd daemon, as it offers a number of advantages:
• It integrates the tcpd functionality. This means that it is no longer necessary to start a
separate program.
• The syntax of the configuration file has changed. This allows for far more flexibility in
configuring the daemon.
• A configuration directory has been added: /etc/xinetd.d. All files in this directory will also
be seen as xinetd configuration files and will be read. This makes it far easier to install
and deinstall software, and to enable and disable services, using scripts.

V3.0
Student Notebook
Uempty
7* 7* 8

z

L
VU
Y{Y'X["@
VV
&XYORH
VV"
&XYO#FKX#H
|

"

z

#FJYF
?
VU
"

C

""

"@
""

VV"
}JYF#H
|
Figure 3-7. /etc/xinetd.conf and /etc/xinetd.d/* LX073.2
Notes:
The visual shows an example /etc/xinetd.conf file. Note that it is almost completely empty; it
only specifies some defaults that are applicable to all services:
• instances specifies the number of instances a service may run in parallel. This is used
to limit the load of a system to a reasonable number, but note that this may be used in
DoS attacks. (What if a hacker sets up 60 telnet connections to your system, but simply
does not login?)
• The log_type, log_on_success and log_on_failure keywords describe where the log
output should go, and what should be logged.
The last line of /etc/xinetd.conf is includedir /etc/xinetd.d. This is the indication for the
xinetd daemon to include every file in that directory in the configuration as well.
The visual also shows an example from this directory. Note that the syntax is just about the
same as in /etc/xinetd.conf, and that a number of fields of the old /etc/inetd.conf file appear
here as well. There are only a few items that are new:
Student Notebook
• The disabled flag tells xinetd that a service is disabled or not. This makes it possible to
have a large number of template services in /etc/xinetd.d, but not enable them all
(possibly because after an install they have not yet been configured properly). It also
makes it possible for tools like chkconfig to enable and disable services that are run out
of xinetd.
• The flags keyword specifies the flags that are to be used when the socket is opened. In
this case, the "REUSE" flag allows multiple processes to connect to one socket, which
is vital if multiple clients want to connect to the same socket simultaneously.
• The log_on_failure is something we've seen before, but in this case it adds (hence the
"+=") the USERID of the user that tried to login.
There is a large number of additional options that may be specified, either as part of the
defaults, or as part of a specific service. Some of the more useful options include:
• only_from can be used to specify a list of IP addresses and/or hostnames from which
clients can connect.
• no_access can be used to specify a list of IP addresses and/or hostnames from which
clients can not connect.
Both only_from and no_access work in addition to the /etc/hosts.allow and
/etc/hosts.deny files.
• access_times specifies the hours between which the service can be accessed.
• nice specifies the priority at which the daemon is to run.
• bind allows you to specify an interface to listen to. Normally xinetd will listen on all
interfaces.
• redirect allows you to redirect a connection to another system.

V3.0
Student Notebook
Uempty
4
Q !

Q! +
Q! Q
^JQ

! J
` Q
$$
"
7 `
Q
$*
!
Figure 3-8. Overview of inetd Services LX073.2
Notes:
inetd and xinetd support a number of internal services:
• The echo service replies everything back to the sender.
• The discard service discards everything that is received.
• The daytime service sends the time as a 32-bit (four character) value.
• The chargen service generates data.
• The time service displays the local time in a human-readable format.
These internal services are normally not enabled but can be used for testing.
In addition to this, there are a number of services that are typically run from inetd:
• telnet and login allow you to login remotely to a system.
• ftp allows you to transfer files to and from a system.
• exec allows you to remotely execute commands.
• finger allows you to retrieve information about users that are logged in.
• talk allows you to chat with another user.
These services will be covered in more detail in the next few pages.
Student Notebook
&0697:$

#

# ! Q!
*

+!
@Q!
*
[+ !* }@
!&!'9
;9&<909+
$ $
$
7
7
$ " "

Figure 3-9. Remote Login, Execute and File Transfer LX073.2
Notes:
Remote login, execute and file transfer were the first services that were implemented when
the Internet was born. They allowed users to use other systems over the network as if they
were local users. There were two competing organizations however, who both
implemented these services differently.
The commands and protocols that were implemented as part of the ARPAnet effort were
reasonably secure, but not very powerful. But most importantly, they were platform
independent, and allowed, for instance, for file conversion on the fly. The reason for this is
that the ARPAnet wanted a series of secure protocols that could be used by the military, in
a heterogeneous environment.
The commands and protocols that were developed at Berkeley University had a different
design goal: Berkeley only used UNIX systems and wanted their network protocols to be as
powerful as the corresponding local UNIX tools. All their commands started with an "r",
followed by the corresponding UNIX tool: rsh, rlogin, rcp. In most cases, the options to the
commands were equal too.

V3.0
Student Notebook
Uempty
$
j !

Q Q
&#
'%j
&`

~

UA
O"U7!77A
K

UA
F
"
"h
W

UA
M7
RC"M
UA~
~HYR'S{

M
UA~h

TB
K

~V
Figure 3-10. telnet LX073.2
Notes:
telnet is used to login to another system on the network. The syntax is telnet hostname
[portnumber] where the portnumber defaults to the “telnet” portnumber found in the
/etc/services file (normally 23).
When a telnet connection is set up, certain environment variables are configured
automatically, most notably $TERM (your terminal type) and $DISPLAY (your X-Windows
display identification). This allows easy interoperability between different operating
systems.
During the telnet session, you can hit Ctrl-]2, to escape to telnet command mode. This
mode can be used to execute various telnet commands. You can enter the command
"help" to get a list of available commands. The most commonly used command is "quit",
which quits the current session. This is especially useful if the session hangs, for instance
because the server was rebooted but you did not log out in time.
2
On non-US keyboards, you might have to use a different combination.
Student Notebook
"
!

` Q* #j j
$<&K
!

&`

~UA
K

UA
UAÔR
"@
""
U
Z
*
M7>M7
RC"M
T
T
7
7
T

TB
7[U

~
Figure 3-11. ftp LX073.2
Notes:
ftp is used to transfer files to and from other systems. If the systems employ different
operating systems, for instance when transferring files between Windows and UNIX, ftp
can convert these files from CR/LF format (DOS, Windows text files) to LF format (UNIX
text files). This conversion is done automatically if "ASCII transfer mode" is chosen. "Binary
transfer mode" will not do any conversion at all, and is the appropriate transfer mode for
binary files such as compressed files, executables, images and so forth.
The user can create a .netrc file on his client system, in which two things can be stored on
a per-server basis:
• The username and password with which to logon to the server. In this case, the user
does not have to type a username and password to logon.
• A number of macros that can be called by the user after the user has logged on. These
macros then perform a number of consecutive ftp commands automatically.
If a macro "init" is defined, then this macro will be executed automatically after a
successful logon.

V3.0
Student Notebook
Uempty The .netrc file should have permissions rw------- (octal 600), otherwise it will not be used.
For more information, see the manual page of netrc(5).
On the server side, the file /etc/ftpusers file is used to determine which user is allowed to ftp
to this system: If a user is listed in this file, it is not allowed to ftp to this system. This
behavior can be changed by changing the PAM configuration file /etc/pam.d/ftp.
Student Notebook
! "
**
*

{J{
! Q
Q Q

KKK
KKKK
Figure 3-12. Anonymous ftp LX073.2
Notes:
Anonymous ftp is a popular method of making software and other files available to
everyone on the Internet. It is a default feature of every ftp server, and is usually enabled by
installing an additional RPM like "anonftp.version.rpm".
When anonymous ftp is enabled, it allows a user to login with username "anonymous", "ftp"
or something similar. No password is required, but it is appreciated if you enter your email
address as password. After this, you are allowed access to a special, so-called
"change-rooted" area of the hard disk3, usually /var/ftp. In this directory the files that are
available for anonymous download are stored, usually in the (/var/ftp)/pub directory.
A catch here is that the whole in.ftpd process is actually running change-rooted. This
means that all libraries and programs that are used by in.ftpd need to be present in the
change-rooted environment as well. That is the reason for the existence of (/var/ftp)/bin,
(/var/ftp)/etc and (/var/ftp)/lib, with a minimal set of configuration files, executables and
libraries.
3
Just before giving you the ftp-prompt, the server does a chroot system call, which changes the perceived root (/) of the filesystem to
that specific directory. After this system call, the process that made the call cannot leave this directory. So even if the user manages to
obtain root privileges, he cannot do much damage to the system as a whole. Only the directory itself is vulnerable.

V3.0
Student Notebook
Uempty
7
* `

$<&K
'
&`

~"

UA
Z
M*UAM7>M7
RC"*UAM7>
H
?

~
Figure 3-13. rexec LX073.2
Notes:
rexec is the ARPAnet command for remote execution of commands. Just as with ftp, it
uses the .netrc file to automate logins.
For security reasons, rexec is disabled in most distributions.
Student Notebook
$
j !

}K|Q $<&K Q

Q

'@%+
&`

~"<7UA
RC"M
UA~
H
?
UA~

~
Figure 3-14. rlogin LX073.2
Notes:
rlogin allows you to login to another system, just like telnet does. There are a number of
differences though:
• As with every Berkeley command, it only works UNIX-to-UNIX.
• It does not automatically transfer environment variables, like telnet does.
The most important difference however is that rlogin uses the /etc/hosts.equiv and
$HOME/.rlogin files on the server to automate logins. This means that if a client host is
listed in either one of these files, that connection that originate (or seem to originate) from
this client, no authentication is performed. The user gets a shell prompt immediately.
This last feature is considered extremely insecure, since it allows a hacker to gain access
to a system simply by spoofing an IP address, or by altering DNS data. You should allow
rlogin (and, for that matter, any r-service) only on a network you absolutely trust, and from
hosts that you absolutely trust. And only if you can trust your users not to do something
stupid like including every known host in their personal .rlogin file.

V3.0
Student Notebook
Uempty
"
!

#|K|Q $<&K
Q
[ Q

*
%! ` !|Q "
`
*
Q
!

Q

J
!

&`

~ 7UAM `

~
Figure 3-15. rcp LX073.2
Notes:
The rcp command is the Berkeley command to transfer files between systems. Just as with
rlogin, it uses the servers /etc/hosts.equiv and $HOME/.rhosts files to automate logins.
It is nearly 100% compatible with the regular UNIX cp command, so you can do recursive
copies, preserve permissions and so forth. The only real difference is the notation of the
filename: instead of [directory/]filename you use
[[user@]host:][directory/]filename.
Third-party-copies are also possible, where an rcp command entered on system A will
cause a file to be copied from system B to system C.
Student Notebook

* `

#|K|Q $<&K
Q
[ Q

*
[ `* $
&`

~"<7UA
H
?

~
*

~"<7` T

~"<7` T

Figure 3-16. rsh LX073.2
Notes:
The rsh command allows you to execute commands remotely. Providing that you keep the
security considerations in mind, this can be very useful.
If rsh is executed without a command, it actually performs an rlogin.
One thing to keep in mind here is the order in which the shell interprets wildcards and
redirection. Consider the command
client$ rsh -l tux1 sys7 ls *.c > allcfiles
In this case, the wildcard expansion of "*.c" will be executed on the client, not on sys7, and
the output of the ls command will be stored on the client as well, not on sys7. The
command should have been specified as
client$ rsh -l tux1 sys7 'ls *.c > allcfiles'
to obtain the desired result.

V3.0
Student Notebook
Uempty

* !

< ! JZ

*

|! Q

%! `
"
!
J

&`

j!

~"U
7CCC<

7CCC
%! Q

~"U <@
7CCC<
CCCM@"CCC

~"U <@<
7CCC<
CCCM@"CCC
%! !
|! K

~"U <@
7CCC<
CCCMMCCC"
Figure 3-17. rsync LX073.2
Notes:
rsync was written specifically to synchronize multiple local and remote directories with
each other, without having to transfer all data. It is modeled after the rcp command but will
only transfer the files that have actually changed (based on size, timestamp and
checksum). In fact, large files will only be updated incrementally, so if only part of a file is
changed, then only that part will be transferred. In addition to this, rsync also supports
compression on the fly. Depending on circumstances, all this might yield tremendous
speedups. In fact, rsync, at the end of the transfer, actually brags about the speedup,
which regularly is more than a thousandfold.
rsync can be used in three modes:
• In local mode, to synchronize files or directories on the local system
Local mode is automatically used if the source or destination do not contain a colon
(“:”).
Student Notebook
• In rsh or ssh mode, where rsh or ssh is used as the transport mechanism. This only
requires the presence of the rsync executable on the server system, and a running rsh
or ssh daemon.
rsh or ssh mode is automatically selected if the source or destination contains a single
colon (“:”), as in www:/var/www/pub.
• In rsync mode, where the rsync protocol is used directly over TCP/IP. This requires the
presence of an rsync daemon (which in reality is the rsync executable, started with the
--daemon option) on the server, listening behind port 873.
rsync mode is automatically selected if the source or destination contains a double
colon (“::”), as in www::wwwdir/pub.
Running an rsync daemon requires the presence of an /etc/rsyncd.conf file, which lists
the access permissions for each module (such as “wwwdir” in the example). The syntax
of this file is rather complex. In addition to this, authentication can only be done using a
plain-text userid/passwd file. For this reason, rsync mode is not used often.
There are numerous options available to control the behavior of rsync. The most important
options are:
-a Archive mode: Equivalent to -rlptgoD. Quick way of saying that
you want recursion and want to preserve almost everything.
-u Update only; don’t overwrite newer files.
-v Verbose.
-e <program> Specify rsh replacement.
-z Compress
For more options, see man rsync.

V3.0
Student Notebook
Uempty

}Q !

&`

~
"UA
UA
'Z
OU
'O
X

"#
@`ME"!!M
"#
@E"!!ML
7O
R
7E"!7M

~
""UA
UA
'M" Z
M#
@
H"
"UM" Y
M
X
^"E"!!M*KFO>M*

>
X
^"E"!!ML*KFO>7!

E"
Y+7M*KFYO>
RM
W"
Figure 3-18. finger LX073.2
Notes:
The finger command is used to retrieve information about users on a system, or about a
specific user. This used to be useful to determine who was logged on where, before you
initiated a talk session, but is no longer considered good practice, because it can give a
hacker far too much information about your users, usernames, inactive sessions and so
forth. The less information a hacker can obtain about your system and your users, the
better.
There are two main uses of finger:
• The first method is by specifying "@hostname", in which case you will see all active
users on that hostname, including the tty they are using and their idle time.
• The second method is by specifying "user@hostname", in which case you get specific
information about the user. Most of the information comes from publicly available files
such as /etc/passwd and /var/log/lastlog. In addition to this, a user can create a .plan file
in its own home directory, which can include some information on the user, his plans,
the projects he is working on, today’s weather report or anything you can think of. This
file is then displayed, providing that the file itself (and the home directory of course) is
readable by other users.
Student Notebook
$
}*

!
!
&`

~?7UA
*J
"7C"

@

C

M>
E

" O?H

7M7L
?M
"
B

U

?M"
CM?

*O

@7

"M>
UA~?

Figure 3-19. talk LX073.2
Notes:
talk is used to initiate a chat session with another user, possibly on another system.

V3.0
Student Notebook
Uempty
"
_K

K
K
K
^K *
K
K
K * `

K
K
K [*
! Q
$"
K
K
K [" 7
!
Notes:
1.
a.
b.
c.
2.
a.
b.
3.
a.
b.
4.
a.
b.
5.
Student Notebook
34
` *J

Q
K ` K

Q Q!

K* K !
Q `
Q+
# $ $
" "
# ` 7
#Q
$
Notes:

V3.0
Student Notebook
Uempty Unit 4. Secure Shell and Secure Copy

This unit describes the inner workings of the SSH protocol and the
installation of OpenSSH.

• Discuss problems with telnet, ftp, rlogin, rsh, rcp and rexec
• Describe the SSH standard
• List different SSH implementations
• Configure and use OpenSSH
• Use RSA and DSA authentication

Accountability:
• Machine exercises
© Copyright IBM Corp. 1999, 2003 Unit 4. Secure Shell and Secure Copy 4-1
Student Notebook
Objectives
Discuss problems with telnet, ftp, rlogin, rsh, rcp, rexec

Describe the SSH standard
List different SSH implementations
Configure and use OpenSSH
Use RSA and DSA authentication
Notes:

V3.0
Student Notebook
Uempty
telnet, ftp, rexec, rsh, rcp Problems
telnet, ftp, rexec, rsh, rcp traditional methods of remote

login, file transfer and remote execution
Authentication usually based on password
Send as plain text
Vulnerable to sniffing
Need to remember each password for each account
Authentication can also be based on IP address
Uses /etc/hosts.equiv or $HOME/.rhosts file
Vulnerable to IP address spoofing
Dependent on DNS server
Figure 4-2. telnet, ftp, rexec, rsh, rcp Problems LX073.2
Notes:
Various problems are associated with the traditional methods of remote login, file transfer
and remote execution. The most important problem is that passwords are passed around in
clear text, available for anybody to see with a sniffer. That person can then use your
password to authenticate as you, and break into your account. This is made worse by the
fact that people usually have accounts on multiple servers, and do not use a different
password for each account. And if they do, they generally need to write down all these
passwords somewhere because it is too hard to remember them all.
The second problem is that authentication can be configured by a user to be based on IP
address instead of password, using the .rhosts file, and by the superuser using the
/etc/hosts.equiv file. This is vulnerable to IP spoofing and, if hostnames instead of IP
addresses are used, dependent on a DNS server which itself might be compromised.
Student Notebook
SSH Protocol
Invented at http://www.ssh.fi
Submitted as Internet Draft (pre-RFC status)
Two client programs:
ssh -> remote login, remote execution
scp -> remote copy
One server program: sshd
Uses encryption to protect data in transit
Support for various encryption methods
Sniffing attack no longer practical
Uses public key algorithms to authenticate server
Prevents against man-in-the-middle attack
Can use public key algorithms to authenticate user too
Account passwords no longer needed
Figure 4-3. SSH Protocol LX073.2
Notes:
A solution to the problems in the previous visual is the SSH protocol. It was invented by a
Finnish company, not coincidentally called ssh. They submitted the protocol description to
the IAB (Internet Architecture Board), where it now lives as an Internet Draft. This is an
interim status in which standards can exist before an RFC number is assigned.
The SSH protocol provides you with all the capabilities mentioned before.
SSH uses strong encryption to encrypt the data in transit and to authenticate the client, the
server and optionally the user as well. This prevents against sniffers and man-in-the-middle
attacks and can also spare the user from the ordeal of having multiple passwords for all his
accounts. A user is no longer authenticated based on his password but based on public
key algorithms.
A typical SSH implementation consists of two client programs:
• ssh, which is used for remote logins and remote command execution.
• scp, which is used for remote copy.
In addition to this, you need to run a server program called sshd.

V3.0
Student Notebook
Uempty Both ssh and scp have the same syntax and capabilities as rsh and rcp. In fact, for ease of
use, most ssh implementations offer replacements for rsh and rcp, which actually use the
SSH protocol.
Student Notebook
SSH Implementations
Linux:
http://www.ssh.fi
Traditional implementation
Restrictive license
http://www.openssh.org
New implementation
GNU Public License
Uses OpenSSL library of cryptographic routines
Windows 95/98/NT/2000:
Various client implementations available. See
http://www.securityportal.com/lasg/servers/shell/index.html
for an overview.
Figure 4-4. SSH Implementations LX073.2
Notes:
SSH is implemented on various operating systems, including Linux and Windows
95/98/NT/2000.
On Linux, the traditional implementation was done by http://www.ssh.fi. Unfortunately, this
company was bought by another who decided to change the license statement for SSH
2.0. You are no longer allowed to use their product in a commercial organization without
paying license fees. In addition to that, their product suffered from a number of security
problems which is especially important in high-risk areas such as firewalls.
So another group of people decided to reimplement the SSH protocol in an open source
product. This product is called OpenSSH. It uses the OpenSSL library of cryptographic
routines, making it one of the most flexible SSH implementations available.

V3.0
Student Notebook
Uempty
ssh Usage
Syntax: ssh [options] [user@]hostname [command]

Interprets command line options:
-c <cipher>: Encryption to be used (blowfish, 3des)
-p <port>: Remote port number
-P: Use local port > 1023
-C: Use compression
Reads config file $HOME/.ssh/config
Reads config file /etc/ssh/ssh_config
Connects to hostname
Asks password
Executes command (optional)
Figure 4-5. ssh Usage LX073.2
Notes:
The ssh command allows you to remote login to a system, and optionally allows you to
execute a command automatically. By default it tries to log you in using the same
username as you are currently using, but this can be changed by specifying
“user@hostname”.
Student Notebook
scp Usage
Syntax: scp [options] [sourcefile] ... [destinationfile]

Options:
-c <cipher>: Encryption to be used (blowfish, 3des)
-p: Preserve modification times and modes
-r: Recursively copy subdirectories
-C: Use compression
-P <port>: Remote port number
Filenames specified as: [[user@]host:]filename
Third-party copies also possible:
hostC# scp hostA:/tmp/fileA hostB:/tmp/fileB
Figure 4-6. scp Usage LX073.2
Notes:
The scp command lets you copy files to and from the remote system. It is even possible to
do third-party copies, as shown in the visual1.
1 At least, the documentation claims that this is possible. It doesn’t work, unfortunately. This has been logged as a bug on the OpenSSH
website, but doesn’t get a lot of priority.

V3.0
Student Notebook
Uempty
sshd Usage
Daemon process directly on port 22

Does not use [x]inetd
Started by /etc/rc.d/init.d/sshd
When started:
Read config from /etc/ssh/sshd_config
Read host-specific RSA key from
/etc/ssh/ssh_host_key
Create session-specific RSA key (never stored on disk)
When a client connection is started
Negotiate session key with client
Encrypt all communications with session key
Authenticate client
Log in, execute command or copy file(s)
Figure 4-7. sshd Usage LX073.2
Notes:
The sshd daemon process should be running on the server. It is usually not run out of inetd,
because it needs to generate an RSA key each time it starts, and this takes some seconds.
Note: A useful thing to know is that sshd can be started with the -d option. This prevents
sshd from forking itself into the background, and sends all debug output to stdout/stderr,
and is very useful for debugging a faulty configuration file.
Student Notebook
ssh/sshd Host Authentication
Every sshd host needs to generate a host key pair

Private key stored in /etc/ssh/ssh_host_key
Public key stored in /etc/ssh/ssh_host_key.pub
Upon first connection, the public key is transferred to the
client
User gets warning: Unknown host. Accept (yes/no)?
When user accepts, public key stored in
$HOME/.ssh/known_hosts
Upon subsequent connections, keypairs verified.
When option StrictHostKeyChecking is set, you can only
connect to hosts whose public key is stored in
/etc/ssh/known_hosts or $HOME/.ssh/known_hosts
Prevents against man-in-the-middle attack
Figure 4-8. ssh/sshd Host Authentication LX073.2
Notes:
Every sshd host (server) needs to generate a host key pair. This was done at install time
with the make host-key command. This key pair is stored in /etc/ssh/ssh_host_key (private
key) and /etc/ssh/ssh_host_key.pub (public key).
When a client first connects to the server, the public key of the host is transferred to the
client. The client then gets a warning that this host is unknown, and is able to accept or not.
When the user accepts, the public key is stored in $HOME/.ssh/known_hosts. Upon
subsequent connections, the keypairs are verified and the user is warned if the keys don't
match.
When the StrictHostKeyChecking option is set either in $HOME/.ssh/config or in
/etc/ssh/ssh_config, the user can only connect to hosts whose public key is stored in
/etc/ssh/known_hosts or $HOME/.ssh/known_hosts. This effectively prevents against
man-in-the-middle attacks.

V3.0
Student Notebook
Uempty
sshd User Authentication
Four methods, tried in order:

1. .rhost authentication (normally disabled)
Requires the hostname to be stored in .rhosts or
/etc/hosts.equiv (insecure - vulnerable to IP spoofing)
2. .rhosts with RSA host authentication (normally disabled)
Requires the hostname to be stored in .rhosts or
/etc/hosts.equiv and requires the client host to have the
correct RSA certificate (fairly insecure - only
authenticates host, not the user)
3. RSA challenge-response authentication
Requires the user to have the correct RSA key pair
4. Password based authentication
Requires the user to supply the correct password
Figure 4-9. sshd User Authentication LX073.2
Notes:
After host authentication, user authentication is done. This is a four step process:
The first step is to verify whether the hostname (possibly in combination with the
username) is stored in $HOME/.rhosts or /etc/hosts.equiv. This works exactly the same as
rsh, rcp or rlogin and is considered very insecure. It is disabled by default.
The next step is .rhosts authentication combined with RSA authentication. This is
considered fairly insecure and normally disabled.
The third step is RSA challenge-response authentication. This basically comes down to the
fact that the user has to have the correct RSA key pair to be able to login. This is pretty
secure, arguably more secure than password authentication. The user needs to set it up
though.
The last step is password based authentication.
Most implementations of SSH will also check for the existence of /etc/shosts.equiv and
$HOME/.shosts in addition to /etc/hosts.equiv and $HOME/.rhosts in the first two steps.
Student Notebook
RSA Challenge-Response Authentication
User generates RSA keypair on client with ssh-keygen -t

rsa1
Private key stored in $HOME/.ssh/identity
Public key stored in $HOME/.ssh/identity.pub
Can be protected with passphrase
Can contain comment
Transfers public key to server and adds it to
$HOME/.ssh/authorized_keys
# scp ~/.ssh/identity.pub 192.168.1.1:myidentity
# ssh 192.168.1.1
# cat myidentity >> ~/.ssh/authorized_keys
# chmod 600 ~/.ssh/authorized_keys
User can then login without password
Figure 4-10. RSA Challenge-Response Authentication LX073.2
Notes:
RSA Challenge-Response Authentication requires each user to generate a keypair on the
client host with the ssh-keygen command. This command then stores the private key in
$HOME/.ssh/identity and the public key in $HOME/.ssh/identity.pub. The usage of this key
can be protected with a passphrase (so the system administrator cannot borrow them...)
The user then transfers the public key to the server and adds it to
$HOME/.ssh/authorized_keys. After that, the user can login without needing to supply a
password to authenticate itself. (Note however that if the key is protected with a
passphrase, he still has to type that one.)
The advantage of this scheme is that a user is no longer required to authenticate himself to
a server using a password, but is authenticated based on public key algorithms. This
greatly simplifies account administration, both for the user and the system administrator.
The only drawback is that the users private key has to be kept secret. That's why this key is
usually protected with a passphrase.

V3.0
Student Notebook
Uempty
DSA Challenge-Response Authentication
SSH Protocol Version 2 can use DSA instead of RSA

To generate a DSA key, use ssh-keygen -t dsa
Private key stored in $HOME/.ssh/id_dsa
Public key stored in $HOME/.ssh/id_dsa.pub
Transfers public key to server and add it to
$HOME/.ssh/authorized_keys2
# scp ~/.ssh/id_dsa.pub 192.168.1.1:myid_dsa
# ssh 192.168.1.1
# cat myid_dsa >> ~/.ssh/authorized_keys2
# chmod 600 ~/.ssh/authorized_keys2
User can then login without password
Figure 4-11. DSA Challenge-Response Authentication LX073.2
Notes:
SSH Protocol Version 2 uses DSA instead of RSA for user and host authentication. The
principles are the same, but the files where the keys are stored are a little different, as is
the command to generate the user keys.
Student Notebook
Protecting Your Private Key
Anyone who can use your private key (identity or id_dsa)

can login to any system where you are authorized
Important to password-protect your private key
Disadvantage: Need to type password every time the key
is used
Solution:
ssh-agent is a client-side daemon who retains
unlocked private keys in memory and activates them
when one of its child processes needs it
ssh-add manages the private keys that are retained in
memory by ssh-agent
Use ssh-add [<filename>] to add a key
Use ssh-add -l to list all keys
Use ssh-add -d [<filename>] to remove a key
Figure 4-12. Protecting Your Private Key LX073.2
Notes:
As we’ve seen in the previous visuals, with RSA and DSA authentication can be performed
using a public/private key pair instead of with passwords. This method has several
advantages, but there is one big disadvantage: Anyone who is able to use your private key
is able to login to any of your accounts. Because of this, you should always
password-protect your private keys.
This leads to another disadvantage though: You need to type that same password every
time you need that private key. For this problem, a solution has been created in the form of
the ssh-agent client-side daemon.
The ssh-agent client-side daemon retains all unlocked private keys in its memory space,
and activates them when one of its client processes needs them. This means that the
ssh-agent has to be started as the parent process of all shells and other programs that
make use of it.

V3.0
Student Notebook
Uempty There are basically two methods of starting ssh-agent:

• First, you can start ssh-agent in a regular shell with the command ssh-agent bash.
This will start ssh-agent, and will start a bash shell as its child. Any commands typed in
this shell will, if necessary, use ssh-agent.
• Second, you can integrate ssh-agent in your X startup scripts. How this is done
depends on how the distribution starts X.
On a Red Hat system, ssh-agent is started automatically as part of the X startup
scripts.
On a SuSE system, modify the $HOME/.xinitrc file. On one of the last lines you will find
the following line:
exec $WINDOWMANAGER
Change this to:
ssh-agent $WINDOWMANAGER
Then log out and log in again, so that ssh-agent is started.
When ssh-agent has been started properly, you also need to unlock and upload your
private keys. This is done with the ssh-add command.
The ssh-add command without any options or arguments asks for the passphrase of
$HOME/.ssh/identity, $HOME/.ssh/id_rsa and/or $HOME/.ssh/id_dsa to unlock them, and
then uploads them to the ssh-agent daemon. If your private key is stored in another file,
you can specify this file too.
The -l option to ssh-add shows all currently retained keys, and the -d option deletes keys.
Student Notebook
Checkpoint
1. Why are the traditional remote login, remote file transfer

and remote execution programs not safe?
2. How does the SSH protocol counter these weaknesses?
3. Which SSH products are available?
4. Which certificates (RSA/DSA key pairs) are there?
5. When is a host public key transferred and what is it used
for?
6. When is a user public key transferred and what is it
used for?
Notes:
1.
2.
3.
4.
5.
6.

V3.0
Student Notebook
Uempty
Unit Summary
There are various reasons not to use telnet, ftp, rexec,

rsh and rcp
Vulnerable to password sniffing
Vulnerable to IP address spoofing
Vulnerable to man-in-the-middle attacks
The SSH protocol uses strong encryption and can
prevent this kind of attacks
Several implementations for Linux exist
http://www.ssh.fi
http://www.openssh.com
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 5. Point-to-Point Protocol

This unit covers the Point-to-Point Protocol in general and its
configuration and use on Linux. The unit first covers the main features
of the protocol itself, and then moves on to the details of how to
configure and use PPP on Linux systems. There is also a lab in which
students will configure PPP on Linux.

• Describe the main features of PPP
• Configure and use PPP on Linux
• Establish a PPP connection

Accountability:
• Checkpoint Exercises
• Machine Exercises
© Copyright IBM Corp. 1999, 2003 Unit 5. Point-to-Point Protocol 5-1

Student Notebook
Objectives

Explain the main features of PPP
Determine whether PPP is suitable for particular
applications
Configure and use PPP on Linux
Notes:

V3.0
Student Notebook
Uempty
PPP Features
Encapsulates IP datagrams for serial link transmission

Supports multiple protocols on a single link
Dynamic negotiation of IP address, authentication,
compression
Consists of:
link control protocol (LCP)
network control protocol (NCP)
encapsulation/framing technique
Figure 5-2. PPP Features LX073.2
Notes:
PPP, the Point-to-Point protocol, is a method of encapsulating IP or other protocol
datagrams for transmission over full-duplex point-to-point links. Nowadays it is mostly used
for connecting PCs through a modem connection to an ISPs network and thus, to the
Internet. But there are other ways of using PPP.
PPP for instance, also allows link-level protocols other than IP to be transported. So you
can also use PPP for connecting SNA, IPX or DECnet networks together. And PPP can not
only run over a serial modem connection, but, for instance, also over a TCP connection. By
using PPP over TCP, we have a very effective way of tunneling a multiprotocol network
over the Internet, for instance.
In this unit we will only look at IP over PPP and PPP over a serial (modem) connection.
PPP is made up of three elements:
• A method for encapsulating multiprotocol datagrams. PPP supports the TCP/IP network
layer protocols.

Student Notebook
• A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link
connection.
• A family of Network Control Protocols (NCPs) for establishing and configuring different
network layer protocols. PPP supports the IP Control Protocol (IPCP) for negotiating, for
instance, IP addresses.
PPP is specified in RFC 1661, which covers the encapsulation method and link control
protocol, and RFC 1662, which discusses the framing method. RFC 1332 describes PPP
when used with IP.

V3.0
Student Notebook
Uempty
Linux PPP Features
10.0.0.1
PPP PPP
10.0.0.2
Server
- PAP/CHAP Authentication
PPP
Client
Figure 5-3. Linux PPP Features LX073.2
Notes:
Linux supports the Point-to-Point protocol over asynchronous (modem) connections. The
PPP support on Linux allows it to act both as a client to other (Linux and non-Linux)
servers, and as a server to (Linux and non-Linux) clients.
PPP itself is strictly a peer-to-peer protocol and we should, therefore, not speak about PPP
servers and PPP clients. However in the common speech today we denote the calling
system the "PPP client" and the called system the "PPP server".
The Linux PPP implementation supports the Password Authentication Protocol (PAP) and
the Challenge Handshake Authentication Protocol (CHAP) to allow one or both ends of the
PPP connection to authenticate the other.

Student Notebook
Setting Up a PPP Client (Overview)
Establishing a serial connection

Initializing modem, dialing phone number
Logging in
Establishing the PPP connection
Exchange of IP addresses
Authentication
PAP/CHAP
Figure 5-4. Setting Up A PPP Client (Overview) LX073.2
Notes:
There are three separate stages in setting up a PPP connection from a client to a server:
The first stage is setting up the serial connection. The objective is that the client and the
server have a clean connection between them, over which they can transmit individual
bytes. Usually this connection is a modem connection. Setting up such a connection
requires the client to do the following:
• Initialize the modem and dial the appropriate telephone number.
• Handle any errors that occurred.
• Sometimes: logging in with a username/password.
The second step is establishing the PPP connection and exchanging the necessary
parameters between the two systems. The most important step from a users point of view
is the exchange of IP addresses, in case the server dynamically allocates IP addresses to
clients.

V3.0
Student Notebook
Uempty The last step in establishing a PPP connection is authentication. There are two methods of
authentication: PAP and CHAP. CHAP is considered the most secure. Authentication
allows both the server and the clients to verify that the other party is indeed who it claims to
be, by testing if the other party knows a common secret.

Student Notebook
Establishing a Serial Connection (1)
Initialize modem and dial number (if modem connection)

Log in to system (optional - depending on ISP)
Generally done using chat
expect-send tool: if you see this, do that.
Syntax: chat -f chatfile or chat expect send expect
send
Figure 5-5. Establishing a Serial Connection (1) LX073.2
Notes:
Establishing a serial connection using a modem generally involves two steps:
• Initializing the modem and having it dial the number
• Logging into a remote system.
Both of these steps are usually done with a program called chat.
Chat can conduct a "conversation" with a device (modem) using expect-send pairs. These
pairs can be supplied on the command line or can be stored in a file. Each pair basically
means "if you receive this, then send this". For instance: if you see a login prompt, send the
userid. If you see the password prompt, send the password.

V3.0
Student Notebook
Uempty
Establishing a Serial Connection (2)
Scenario:
We have a Hayes compatible modem (which therefore
uses the AT commands)
Telephone number to dial is 1234567890
We need to log in to our ISP with userid ppp and
password ppp
Then our chat script becomes basically:
"" ATZ reset modem
OK ATDT1234567890 dial telephone number
CONNECT "" wait for "CONNECT" and send enter
ogin: ppp wait for "ogin:" and send userid
send password
word: ppp
Figure 5-6. Establishing A Serial Connection (2) LX073.2
Notes:
A Hayes compatible modem uses a series of standardized AT commands. That is, every
command starts with AT. There are two commands important for us: ATZ (reset) and ATDT
(dial).
The first command we need to submit to the modem is the ATZ command. We do this
regardless of whether the modem is sending something to us. This is what is done in the
first line of the chat command.
The modem should now reply with an OK, upon which we send it the ATDT dial command.
This is done in the second line.
The modem will now start dialing and set up the connection. When it is finished, it sends us
the "CONNECT" reply. Now we need to wake up the gettyp process on the other side of the
connection. So we just send an Enter. This is the third line of the chat script.
The server will now ask us for a login name. Since some servers write login with a capital L,
and some with a lowercase l, we have chat scan for "ogin:", upon which it sends our userid,
"ppp".

Student Notebook
The last line ensures that our password is also submitted.

Most ISPs are configured to automatically start PPP as soon as a user is logged in. Some
ISPs, however, offer you a normal login prompt ("$") and require you to start PPP yourself.
In this case, an extra line is added to the chatscript: "$ ppp-start". (If you see the prompt,
issue the ppp-start command1.)
The chat script in the visual is fairly simple, and doesn't handle all kinds of errors. A
full-fledged chat-script would look like this:
TIMEOUT 3
ABORT '\nBUSY\n'
ABORT '\nNO ANSWER\n'
ABORT '\nRINGING\r\nRINGING\r'
"" \rATZ
'OK-+++\c-OK' ATH0
TIMEOUT 30
OK ATDT1234567890
CONNECT ""
ogin:--ogin: ppp
word: ppp
This script tells chat to do the following:
1. Set the timeout to three seconds.
2. Abort the script if it receives either:
- BUSY
- NO ANSWER
- RINGING twice in a row
3. Send ATZ (reset)
4. Upon receiving OK, send ATH0 (means: select highest possible speed). If chat does not
receive OK within 3 seconds, send +++\c (the universal hangup command) then wait for
OK again.
5. Now set timeout to 30.
6. Wait for OK again, then dial the number 1234567890
7. Wait for CONNECT, send Enter
8. Wait for login:, send ppp
9. Wait for word:, send ppp
This dial script is generally sophisticated enough to handle most of the connections.
1
Or whatever command is appropriate for your ISP.

V3.0
Student Notebook
Uempty
Establishing the ppp Connection (1)
Done using the pppd daemon

After the serial line has been set up
However, pppd calls chat to set up the serial line
If necessary, exchange of IP addresses
Syntax: pppd options ttyname speed
Options include:
connect script (how to set up the serial connection)
crtscts (use hardware flow control)
localIPaddress:remoteIPaddress
Options can also be stored in option files:
/etc/ppp/options -> global options
/etc/ppp/options.ttyname -> options per tty
Figure 5-7. Establishing the PPP Connection (1) LX073.2
Notes:
The pppd daemon is the program that initiates and manages the PPP connection after the
serial connection has set up. However, if you run chat first and then run pppd you will run
into all kinds of scripting problems keeping the connection alive while no program is
connected to the tty. Therefore, it is pppd that actually runs the chat program and takes
over immediately as chat is finished.
As soon as chat is finished, the system on the other side should be sending PPP data. This
will look like: ‘y}#.!}!}!} }8}!}$}%U}"} } } } }%}& ...}'}"}(}"} .’’y}...
and will just keep coming. This is the PPP initialization from the PPP program on the other
side. pppd on our machine will pick this up and interpret it as a PPP data stream.
Now that pppd has a connection with the other side, they exchange certain PPP
parameters. The most important for us is the exchange of IP addresses, but there are
several others.
The pppd daemon accepts various options. These options can be specified on the
command line, but can also be stored in the files /etc/ppp/options (global options for every
connection) and /etc/ppp/options.ttyname (options specific for that tty).

Student Notebook
Establishing the ppp Connection (2)
Scenario:
Our IP address is 10.0.0.1
The remote IP address is 10.0.0.2
Use hardware flow control
Use /etc/ppp/chatscript as chat script
pppd crtscts 10.0.0.1:10.0.0.2 connect 'chat -v -f
/etc/ppp/chatscript' /dev/ttyS1 38400
After the connection comes up, the /etc/ppp/ip-up script is
run (if it exists)
Terminating the connection:
kill -INT `cat /var/run/ppp0.pid`
After the connection is brought down, the
/etc/ppp/ip_down script is run (if it exists)
Figure 5-8. Establishing the PPP Connection (2) LX073.2
Notes:
pppd is invoked when you need to set up the connection (for instance to your ISP). In the
above scenario, no options to pppd are stored in /etc/ppp/options or /etc/ppp/options.ttyS1.
All options are supplied on the command line.
The first option, crtscts tells pppd to use hardware flow control.
The second option, 10.0.0.1:10.0.0.2 tells pppd to use 10.0.0.1 as local IP address and
10.0.0.2 as remote IP address, once the link has come up.2
The third option, connect 'chat -v -f /etc/ppp/chatscript' means that pppd has to set up
the serial connection using the chat program. The -v option tells chat to be verbose, so
everything that is exchanged is logged into /var/log/messages. The -f /etc/ppp/chatscript
option tells chat what to use as chatscript.
The fourth parameter is the tty name to use, /dev/ttyS1.
The last parameter is the speed to use, 38400 bps.
2
Note that is it normally the server and not the client who decides on the IP addresses that are being used.

V3.0
Student Notebook
Uempty pppd will fork itself in the background and bring up the connection. If you don't want pppd
to detach itself, use the -detach option.
You can check the progress of establishing the link in /var/log/messages.
After the PPP link has been brought up and is ready to transmit IP packets, the
/etc/ppp/ip-up script is executed, if this script exists.
A PPP connection is terminated by sending the interrupt signal to pppd. If pppd is running
in the foreground, simply hit Ctrl-C. If it is in the background, use kill -INT. And since pppd
stores its PID in /var/run/device.pid, we can use that PID to send the interrupt signal to:
kill -INT `cat/var/run/ppp0.pid`. for instance. When the PPP link is no longer able to
transmit IP packets, the /etc/ppp/ip-down script is executed, if this script exists.
The /etc/ppp/ip-up and ip-down scripts can be used, for instance, to configure routing and
DNS.

Student Notebook
Server Authentication
Since the client dials the server, the client normally does
not require the server to authenticate itself
The noauth option is used for this
Figure 5-9. Server Authentication LX073.2
Notes:
pppd by default requires the other side of the connection to authenticate itself using PAP or
CHAP. But since the client actually dialed the server, it is unlikely that the server will need
to authenticate itself. So in this case the noauth option is being used to disable server
authentication.

V3.0
Student Notebook
Uempty
Setting Up a PPP Client (Wrapup)
Some tools can automate the client setup:

kppp
redhat-config-network
pppd can also use dial-on-demand
The connection is automatically started as data arrives
Set using the following options in /etc/ppp/options:
demand
idle
holdoff
After setting up the link, don't forget
Set up routing
The defaultroute option configures the default route
over the PPP link
Set up DNS
Might want to use /etc/ppp/ip-up script for this
Figure 5-10. Setting Up A PPP Client (Wrapup) LX073.2
Notes:
We've seen how to set up the PPP client. It is not too long ago that you had to do this all
yourself when you wanted to connect to an ISP. But nowadays various tools exist who
automate the process for you. The most often used are kppp, which is part of the KDE
Desktop Environment, rp3, and various others. These make life a lot easier, but do not give
you an understanding about what is going on. That's what you do need when you want to
setup a PPP server.
Programming "raw" pppd has another advantage too: You can configure it to do demand
dialing. This means that the connection is automatically set up when there is data that
should flow through that connection, and that the connection is automatically brought down
after a certain idle period. How to set up a dial-on-demand connection is not part of the
course material however. Take a look at the manual page of pppd for that.
After the link is correctly configured, don't forget to set up routing. This can be done
automatically with the "defaultroute" option. Routing will be discussed in a later unit.
Also, don't forget to set up a DNS client configuration if you connect to the Internet. DNS
will also be covered in a later unit, but for now it is useful to know that when the

Student Notebook
usepeerdns option is used, the pppd will ask the peer to supply up to two DNS addresses.
These are stored in $DNS1 and $DNS2 when the /etc/ppp/ip-up script is run. You can then
add the DNS addresses to /etc/resolv.conf, for instance.

V3.0
Student Notebook
Uempty
Setting Up a PPP Server (Overview)
Allow for establishing a serial connection

Configure modem to answer calls
Allow for establishing a ppp connection
When a user logs in, start the pppd daemon
Supply IP addresses
Require authentication using PAP or CHAP
Figure 5-11. Setting Up A PPP Server (Overview) LX073.2
Notes:
The same three steps that we saw for the client also are necessary for the server. However,
they are different, since it is the client who initiates the connection.
First, we have to configure our system so that if a call comes in, it is detected and
answered.
Then, we have to start a pppd daemon somehow that will establish the PPP connection on
the server side.
And the last step is again authentication. On the server side we will want to authenticate
the client, to prevent unauthorized access.

Student Notebook
Setting Up for a Serial Connection
Start an mgetty on the tty.

vi /etc/inittab and add a line for the getty:
s1:2345:respawn:/sbin/mgetty ttyS0
Restart init: kill -HUP 1

Add users to /etc/passwd like always, but ensure that
their shell is /usr/sbin/pppd instead of /bin/bash
ppp:x:501:501::/home/ppp:/usr/sbin/pppd
Figure 5-12. Setting Up for a Serial Connection LX073.2
Notes:
For our server to be able to pick up an incoming call, two things are needed:
• The modem has to detect the incoming call.
• The modem needs to answer the call.
There are several ways of establishing this. The most common way is by running the
mgetty command on the tty. mgetty opens the tty, which enables the DTR (Data Terminal
Ready) line of the serial connection between the computer and the modem. This is the
indication for the modem that something is listening to the modem output. If a call comes in,
the modem is then able to send the "RING" message to the computer.
mgetty is able to detect this ring message and will issue the ATA command, which is the
indication for the modem to answer the call.3
3
Another, less often used technique is to put the modem in "auto answer" mode. In this case the modem will not wait for an ATA
command, but will answer the call immediately. The usual command to enable this is ATS0=1, meaning: auto-answer after one ring. This
modem configuration change is generally something we will want to store in the non-volatile memory of the modem so that after a reset
of the modem the auto-answer will remain enabled. Depending on your modem, this is usually done with the ATZ command.

V3.0
Student Notebook
Uempty After the modem has answered the call and synchronized with the modem on the other
side, the serial connection is ready. mgetty now sends the login prompt to the other side
and waits for a username to be received. It then starts the login process to enable the user
to login further.
The last step we have to take is configuring our user accounts. There should be one user
account for each user that connects to our system, and they can be set up using the normal
procedures (adduser, passwd). One important thing however, their login shell should
probably NOT be /bin/bash, but should be /usr/sbin/pppd. We don't want our users to get
the shell prompt, but we want PPP to be started automatically.

Student Notebook
Setting Up for an Incoming PPP Connection
pppd will be started by users, but has to run as root

chmod 4755 /usr/sbin/pppd
Add general options to /etc/ppp/options
crtscts
-detach
Add specific options to /etc/ppp/options.ttyS0

10.0.0.2:10.0.0.1
Figure 5-13. Setting Up for an Incoming PPP Connection LX073.2
Notes:
pppd has to be started by the users, but it has to run with root privileges, since it modifies
network interfaces, routing tables and so on. The easiest way to accomplish this is to make
the program "SUID root". This can be done using the command chmod 4755
/usr/sbin/pppd. Of course, one can also use all kinds of wrapper programs, including
sudo to accomplish that.
Providers which have normal users logged into their system in a normal way (for instance
with telnet) sometimes choose to limit the execution of pppd to a limited number of users.
For that purpose they create a new group, usually PPP, and add only the users which are
allowed PPP connections to that group. Then, they change the group of /usr/sbin/pppd to
PPP and the permissions to 4750. That way, only users in the PPP group can execute
pppd.
The next step is configuring the global PPP options in /etc/ppp/options. The most
important are crtscts and -detach, but others may also be applicable, depending on one's
need. crtscts means hardware flow control, and -detach ensures that pppd does not fork
and put itself in the background, which would otherwise surely confuse init

V3.0
Student Notebook
Uempty The next step is usually the configuration of IP addresses per tty. Since each tty should
have its own IP address, these IP addresses are configured in the /etc/ppp/options.ttyname
file.

Student Notebook
Client Authentication (1)
Can be done using Password Authentication Protocol

(PAP) or CHAP (Cryptographic Handshake
Authentication Protocol)
Done after the PPP connection is set up
The pppd noauth option disables authentication
Both PAP and CHAP use "secrets"
Stored in /etc/ppp/pap-secrets and
/etc/ppp/chap-secrets, respectively.
Different for each connection
The other side is tested for whether it knows the same
secret as you do.
The secret is normally your password
CHAP is considered more secure
Challenge encrypted with password
Regular intervals
Figure 5-14. Client Authentication (1) LX073.2
Notes:
Authentication of a PPP connection can be done by using Password Authentication
Protocol (PAP) or Cryptographic Handshake Authentication Protocol (CHAP). This is done
after the PPP connection has been set up.
The pppd "auth" option forces authentication of the other party. So if you specify "auth" on
the server, then the server forces the client to authenticate itself and vice versa. The
"noauth" option disables authentication.
Both PAP and CHAP use so-called secrets, which are words or complete sentences only
known to the client and the server. They are stored in /etc/ppp/pap-secrets and
/etc/ppp/chap-secrets respectively. If one of the parties requires the other to authenticate
using PAP, the password is send and compared. If one of the parties requires the other to
authenticate using CHAP, the requestor sends a randomly generated "challenge" to the
other. This challenge is then encrypted with its password using a one-way hash function,
and send back. The requester performs the same operation and compares the results. If
these results are equal it can conclude that the other side knew the correct secret and can
be trusted.

V3.0
Student Notebook
Uempty The advantage of CHAP over PAP is clear: Someone eavesdropping on the line can easily
retrieve a PAP password, but will not be able to retrieve the CHAP password. In addition to
this, when CHAP authentication is being used, the authentication is done at regular
intervals instead of once, during connection setup. All this makes CHAP more secure than
PAP.

Student Notebook
/etc/ppp/chap-secrets:
# Secrets for authentication using CHAP
# client server secret IP addresses
marcia john cats
john marcia dogs
Meaning: if "john" wants "marcia" to authenticate, their
common secret is "cats". If "marcia" wants "john" to
authenticate, their common secret is "dogs".
/etc/ppp/pap-secrets has the same syntax
Wildcards possible
Notes:
The secrets for CHAP are stored in /etc/ppp/chap-secrets. The secrets for PAP are stored
in /etc/ppp/pap-secrets. They both use the same syntax.
Each line of the file contains the secret for one connection. The connection is identified with
the client and server fields, which are the host names of the client and the server. The third
field contains the secret. If the secret is a sentence, you should enclose it in quotes. The
fourth field contains optional IP addresses, identifying which IP addresses the server is
allowed to use.
Should an authentication method be applied to several clients or several servers, then one
can use a wildcard ("*") instead of specifying the client or server name.

V3.0
Student Notebook
Uempty
pppd can also use regular /etc/passwd authentication

Use login option to enable this
This is usually done in combination with all-wildcards in
/etc/ppp/pap-secrets or /etc/ppp/chap-secrets:
# Secrets for authentication using PAP
# client server secret IP addresses
* * "" *
Notes:
It is also possible to use the regular user passwords in /etc/passwd (or /etc/shadow)
instead of /etc/ppp/pap-secrets and /etc/ppp/chap-secrets. This is enabled by specifying
the "login" option to pppd. In this case, you need to setup the /etc/ppp/pap-secrets and
/etc/ppp/chap-secrets file with all wildcards.
The advantage of this scheme is that a user who logs in to your server uses the same
password and password management tools as are used for PPP authentication. If a user
wants to reset its password, he can just issue the passwd command for that.

Student Notebook
Windows Clients Considerations
Windows clients do not log in to the server but start PPP

as soon as the serial connection has been established
mgetty can detect this and log in as a pseudo-user
To enable this, edit /etc/mgetty+sendfax/login.config
and add:
/AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login
Windows 9x can only authenticate using PAP

Windows NT/2000/XP can authenticate using PAP and
CHAP
Figure 5-17. Windows Clients Considerations LX073.2
Notes:
Windows clients are not as flexible in their setup as the clients we saw in the first part of this
unit. There are two peculiar things about them:
• The first difference is that Windows clients do not attempt to login as soon as the serial
connection has been established, but they start PPP directly, as soon as they have
received the "CONNECTED" message from the modem.
More modern Windows variants (NT, 2000, XP) allow you to configure a pre-dial and
post-connect script, which allows you to login to the server manually.
• The second difference is that Windows 9x only allows authentication to be done using
PAP. No other authentication mechanisms are supported.
Windows NT/2000/XP allows you to use CHAP as well, but PAP is the default.
The solution to the first problem is an added feature of mgetty: mgetty can detect that a
client is sending PPP data at the point where normally the username is entered. It can then
start the pppd daemon directly, without requiring that the user first logs in. This is achieved
by adding a line to mgettys login.config file.

V3.0
Student Notebook
Uempty The second problem is solved by using the pppd options "auth -chap +pap" when pppd
starts. This ensures that PAP authentication is used.

Student Notebook
PPP and a Permanent Null-Modem Connection
With a null-modem, the connection is permanent

No need to set up a serial connection
Probably no need for security as well
So you don't have to log in or authenticate
So the only thing to do is start pppd.
We can do that in /etc/inittab
client# cat /etc/inittab
.
s1:2345:respawn:/usr/sbin/pppd -detach noauth crtscts 10.0.0.2:10.0.0.1 /dev/ttyS0 38400
.
server# cat /etc/inittab

.
s1:2345:respawn:/usr/sbin/pppd -detach noauth crtscts 10.0.0.1:10.0.0.2 /dev/ttyS0 38400
.
Figure 5-18. PPP and a Permanent Null-Modem Connection LX073.2
Notes:
A very simple, but very useful other use of PPP is to use it to drive a permanent
null-modem connection between two systems. For instance, because you want these two
systems in a network, but don't have (the money to buy) network adapters. (A null-modem
cable can be obtained for less than US$ 10.)
This usage is so simple because you have a permanent connection, so you don't have to
worry about the setup of serial connections. And furthermore, you generally don't have to
worry about security at all, so no login procedure, no secrets and so forth.
In fact, the only thing to do is connect the cables and start pppd with the right options at
boot time. That is something we can do in /etc/inittab. We don't even have to worry about a
lot of PPP options.
The lines to add to the /etc/inittab files are listed in the visual. The advantage of using init
to start pppd directly is that should the connection fail, for some reason, init will start a new
instance of pppd almost immediately, to try it again. And since the connection will use the
same IP addresses, users will probably hardly notice it.

V3.0
Student Notebook
Uempty This configuration also works if the systems are not booted at the same time, or if the cable
becomes disconnected and is reconnected again.

Student Notebook
Checkpoint
1. Which Linux daemon runs for each PPP connection the

system has?
a. pppd
b. chat
c. init
d. getty
2. T/F. The official definition of PPP does not use the
client/server concept, but in normal speak we use
"client" for the called system and "server" for the calling
system.
3. T/F. A PPP server (called station) assigns client IP
addresses in sequence according to the TTY device
name, for example, tty0 gets the first address, tty1 the
second, and so forth.
Notes:
1.
2.
3.

V3.0
Student Notebook
Uempty
Unit Summary
PPP is used for making IP connections over a serial line

or modem connection
Setting up a connection requires three steps:
Setting up the serial connection
Setting up the PPP connection
Authentication
The serial connection is usually configured using chat
The PPP connection is configured using pppd
Authentication is done using PAP or CHAP, and can also
be done using regular /etc/passwd authentication
Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 6. Routing

This unit describes routing and how it works in Linux.

• Explain Internet routing
• List and understand a routing table
• Explain the difference between dynamic and static routing
• Configure static routing
• Discuss dynamic routing

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 6. Routing 6-1

Student Notebook

&`

j
&`
* !

'!
Notes:

V3.0
Student Notebook
Uempty

4
#
***K K
Figure 6-2. The Internet - How It Seems To Work LX073.2
Notes:
Most people perceive the Internet as one big cloud where packets enter at one point, and
exit at another point. How the packets are handled internally is a big mystery to them.

Student Notebook

&$$#
***K K

Figure 6-3. The Internet - How It Really Works LX073.2
Notes:
In reality, the Internet — at least, the core infrastructure — consists of a large number of
routers, connected to each other using various network topologies. Packets are sent from
router to router and finally end up at the destination.
There is no structured way that these routers are connected: every Internet provider is free
to connect to another Internet provider at will. This leads to the situation that there are
multiple routes to a destination. Choosing the best route to a destination is one of the many
aspects of routing.

V3.0
Student Notebook
Uempty
&
'Q*

j@
[@
}$ `

*+
*
+ `

%*j `[ *}@KKK
$* KKK
&Q! *+

+
Figure 6-4. Router Characteristics LX073.2
Notes:
A router1 is a device which has multiple interfaces and is connected to multiple networks
through these interfaces. This means that it can forward data from one network to another.
It really doesn't matter what sort of networks a router is attached to: Wide Area Networks
(such as PPP links, X.25 or Frame Relay) or Local Area Networks (such as Token Ring or
Ethernet).
The router listens on all connected interfaces for incoming IP packets. When packets come
in, it takes the destination IP address and looks up this address in a "routing table". The
routing table then specifies the next hop to forward this packet to. This happens at every
router, until the packet reaches its final destination. On the Internet as of today, each
packet generally needs to traverse 20-30 routers before arriving at its final destination.
1
In the early days of the Internet, before 1983, the term "gateway" was very common. The OSI model, which came out in 1983, defined
a number of terms that were in common use, including the term router and gateway. These definitions have stuck and a device that
routes packets through a network without altering them is now called a router. The term "gateway" is reserved for a device which does a
protocol conversion. In older documentation, and in various abbreviations and in various commands, the term gateway is occasionally
used instead of router.

Student Notebook
Routers can be implemented in software and in hardware. Software solutions include most
operating systems that are in use today. Hardware solutions are dedicated machines that
can do nothing else. Cisco, IBM and 3Com are all manufacturers of hardware routers.
Every host on an IP network needs minimal routing capabilities, to send outgoing packets
to the correct next hop or final destination, even if this host is not a router itself.

V3.0
Student Notebook
Uempty
07 &
*

7T" U
@+V"C"
+
!
#$!K
%%&! !

' !
Figure 6-5. Linux as a Router LX073.2
Notes:
As with most operating systems of today, Linux can function as a router. The only thing
really to achieve this is to turn on IP forwarding in the kernel. If IP forwarding is turned on,
an incoming packet which does not have this host as its destination will be forwarded to the
next hop. In contrast, if IP forwarding is turned off, an incoming packet which does not have
this host as its destination will simply be discarded.
IP forwarding is a kernel function and can be turned on by executing the following
command:
echo 1 > /proc/sys/net/ipv4/ip_forward
To make this change persistent across reboots, change the appropriate configuration file
for your distribution. Depending on the distribution, you can find this setting in one of the
files below:
• Red Hat: /etc/sysctl.conf
• SuSE: /etc/sysconfig/sysctl

Student Notebook
Two other things that need to be done on every host in an IP network also apply to a router,
obviously. These are filling the routing tables and deciding on dynamic routing.

V3.0
Student Notebook
Uempty
&
$
j `
Q!+ *

! !J +

$
@*+@*+'% +
'
@`

j J*
! *+
J*
!
Figure 6-6. Routing Table LX073.2
Notes:
As seen before, the routing table is the central table for routing, both in regular hosts and in
routers. It basically lists the next hop to send packets to for every known final destination on
the network. A core router on the Internet, which is supposed to know the route to every
destination on the whole Internet, can easily have a routing table which takes up several
megabytes of memory.
On most operating systems, the routing table is only stored in (kernel) memory. It is not
stored on disk as such.
The routing tables two most important information items are:
• The final destination specification. This is matched with the destination address in the
IP packet to determine which line of the routing table is applicable.
The final destination is generally specified in either one of the three forms below:
- The first method is to specify a full IP address. In this case, the entry in the routing
table only applies to packets sent to this specific IP address. This is generally known
as a "host route".

Student Notebook
- The second method is to specify a network ID in combination with a subnetmask. In

this case, the entry in the routing table applies to all packets sent to any IP address
which belongs in this network. This is generally known as a "network route".
- The third method is to specify a default route. In this case, the entry in the routing
table applies to all packets which were not matched elsewhere in the routing table.
This is generally known as the "default route".
All three entries are in practice specified as a combination of an IP address and a
subnetmask:
- Host route: 129.33.151.7/255.255.255.255
- Network route: 129.33.151.0/255.255.255.0
- Default route: 0.0.0.0/0.0.0.0
Specifying these three types of routes like this ensures that only one matching
algorithm has to be implemented, which greatly reduces computing speed.
• The next hop specification. This specifies where the IP packet that matched the final
destination specification should be sent to. There's two possibilities:
- The final destination is on a local network. In this case, the local interface is
specified.
- The final destination is not on a local network. In this case, another router is
specified. This router normally is a system on the local network.
There are several more fields stored in the routing table. They will be covered in due
course.

V3.0
Student Notebook
Uempty
!4"$'

_^KK_]K_

_^KK__K_ _^K_\K_K_
_^KK__K _^K_\K_K^ _^K_\K_K\

_^K_\K^K_
_^K_\K^K^ _^K_\K^K _^K_\K^K

' &
Figure 6-7. A Sample Network LX073.2
Notes:
This sample network will be used in the next few visuals.

Student Notebook
; &
$
$
H
[
CU
"
7A<
7!77<

7!777<
$
H
[
CU
"
7A<
7!7L;7<

7!7L;7!7L;7;<
7!7L;77<
#
H
[
CU
"
7A<
7!7<
7!77<

7!7L;7<
7
7!7L;7!7L;7;<
7!7<
#
$
Figure 6-8. Basic Route Tables LX073.2
Notes:
The visuals shows three routing tables which are used in the example network. To
understand how the routing tables are applied, consider an IP packet which is sent from
host A (129.33.151.7) to host B (192.168.1.2):
1. First, the routing table on host A is searched for the entry where the IP address of host
B matches the destination field. This is the third entry (the default route). The packet is
therefore sent to the system with IP address 129.33.151.1 (router A) first.
2. On router A, the destination IP address of the packet is again matched with the routing
table. Here, two entries match: the second entry and the fourth (the default route). The
entry with the longest subnetmask (the second) is used. This is a local route, so the
packet can be sent to host B directly.
As an exercise, try to construct the routing tables of router B and host C as well.

V3.0
Student Notebook
Uempty
.&
$

<"

!$%$%$%%$%$%$%&&$%$%$%'(%%%
)$,,$&$%%$%$%$%&&$&&$&&$%'(%%%;%
%$%$%$%)$,,$&$%$%$%$%'(%%%;%
"

<'
!$%$%$%=&&$%$%$%'%%%
)$,,$&$%=&&$&&$&&$%'%%%;%

)$,,$&$%$%$%$%'%%%;%
<

* J
j
" j+
Figure 6-9. Viewing the Route Table LX073.2
Notes:
For historic reasons, there are two commands which can show the routing table, the
netstat -r command and the route command. Both show the basic routing table as kept by
the kernel, but each shows a different subset of the fields in the routing table.
For a complete listing of all fields in the routing table, use the route -ee command.
We've already seen the Destination, Genmask (subnetmask), Gateway and Iface fields.
The other fields you might see are less important and are mostly used for tuning the TCP
connections via this route. Here's a list of what they mean and what they are used for:
• The Flags field identifies various flags that can be associated with an entry in the
routing table. The most common flags are:
U: Up. The route is up and usable.
G: Gateway. This is a remote route through a router (gateway).
H: Host. This is a host route, not a network route.

Student Notebook
• The MSS field identifies the maximum segment size for TCP connections over this
route.
• The Window field identifies the default window size for TCP connections over this
route.
• The irtt field identifies the Initial Round Trip Time for TCP connections over this route.
• The Metric identifies the number of hops to the target. This can be useful to select the
shortest of multiple available routes to a target.
• The Ref field identifies the number of references to this route. This value is not being
used in Linux, but present for historic reasons.
• The Use field identifies the number of times this entry was used.
See the manual page of route for a more thorough explanation of these fields.

V3.0
Student Notebook
Uempty
:$$&
$

#
!*
&`
%#
*
'! #
^
Figure 6-10. Filling the Route Table LX073.2
Notes:
There are three ways in which an entry can be added to the routing table.
The first way an entry is added to the routing table is when an interface into a specific
network is activated. The ifconfig command, when activating the interface, automatically
also adds an entry for that interface to the routing table. Likewise, when an interface is
deactivated, the corresponding entry is automatically removed from the routing table.
Entries that are added because of this are called "implicit routes".
The second way is when the user manually adds an entry to the routing table. This is done
with the route command, and is for instance used to define the default route. We will look
at the route command in the next visual. Entries added with the route command are called
"explicit" or "static routes".
The third way is by using routing daemons. These programs, which then run on every
router, communicate their routing tables with each other. Based on the information
exchanged, such a routing daemon can update the local routing table automatically to
reflect the current network topology. Routes added by a routing daemon are called
"dynamic routes".

Student Notebook

}
"
<
7!77
?C7!77
"
<7!7L;C7!7L;7;
"

C7!777
'

*+
+

'
Figure 6-11. route Command LX073.2
Notes:
The route command can also be used to add and delete entries to and from the route
table. The visual shows a network route, a host route and a default route being added to
the routing table.

V3.0
Student Notebook
Uempty
4& $
#$

! *+ QJYQZ

! *+ QYQZJ
%%&

! *+
Figure 6-12. Configuring Static Routes Permanently LX073.2
Notes:
The routing table is not stored on disk as such. We therefore need to add each static route
we will want to configure permanently to the correct startup file. Every distribution uses a
different strategy for this:
• Red Hat stores the default route in the adapter-specific file
/etc/sysconfig/networking/devices/ifcfg-<device>. Additional routes are also stored in a
device-specific file, /etc/sysconfig/networking/devices/<device>.route.
• SuSE stores the default route and additional static routes in
/etc/sysconfig/network/routes.
The syntax of both /etc/sysconfig/networking/devices/<device>.route and
/etc/sysconfig/network/routes is not entirely what you would expect based on the syntax of
the route command. If you want to change this file by hand, it is best to use the distributions
configuration tools (redhat-config-network, yast2, ...) to configure the first static route in that
file, and use that line as a template for other routes that need to be added.

Student Notebook
%&"$
# {# ' {

Q!
Q! *+
*
' < ! *!
*
j +% *Q!!

##Q^<%KKK
'

^
Figure 6-13. Dynamic Routing Principles LX073.2
Notes:
When your network is large and you've got a sizeable number of router, creating each
routing table by hand becomes tedious or just plainly impossible. In these situations,
dynamic routing is used.
Dynamic routing works as follows: Each router runs a so-called routing daemon. This
daemon communicates with other routers in the network and transfers its own routing table
(which, initially, only includes its implicit routes) to other routers. Based on the information
that each router receives, they can decide an accurate picture of the whole network, and
calculate the best route to each destination in the network. This information is then fed into
the kernel routing table and used for routing the IP packets.
This may seem simple but in reality is horribly complex. A lot of academic research has
been done in this area, and currently there's basically two algorithms that are being used:
• In the vector distance algorithm, each router only communicates with his neighbors,
using broadcasts or direct unicasts. Routers update their own routing table with the
information received, and transfer the whole routing table on to the next neighbor. That

V3.0
Student Notebook
Uempty means that each transfer from a router to another may include information about other
routers as well.
In general, vector distance algorithms have two disadvantages:
- Convergence is slow. This means that it takes a while (up to 45 minutes) before a
change in the network has propagated over all routers.
- The only metric that is being used is the hop count. If a low-bandwidth route to a
destination takes three hops, but there's an alternative, high-bandwidth route
available that takes five hops, then a vector distance algorithm will always use the
three hop route.
• When using Link State algorithms, each router multicasts its own table of implicit routes
to every other router in the network using IP multicasts. They do not transfer information
obtained from others.
With every router receiving all implicit routes of every router directly, they can, with a
little effort, construct a mental picture of the whole network. This is then used to
calculate the shortest route to each and every final destination in the network.
The advantage of this is that, since each router has complete knowledge of the network,
routing does not have to be done based on hopcount alone. In fact, five different metrics
can be used:
- The normal metric (hopcount)
- Minimize delay (lowest latency, preferred for interactive communication)
- Maximize throughput (highest bandwidth, preferred for bulk file transfers)
- Maximize reliability (minimize packet loss, preferred for network status messages)
- Minimize monetary cost (preferred for low-value or low-priority services)
The disadvantage of link state algorithms is that it is a huge task to configure and
maintain. There are several courses, both from IBM and from other vendors, that spend
days just covering the concepts and implementation of one specific link state protocol.
Based on these algorithms, several protocols have been designed which implement them,
and who can be used in different situations. These protocols include RIP (Route
Information Protocol), RIPv2, OSPF (Open Shortest Path First) and BGP (Border Gateway
Protocol).
On Linux you may find three daemons that implement these protocols: routed, gated and
zebra.

Student Notebook
&%

#
!
@ !
< !
*+

***KK
} J

&` Q !

*+
!
! ! *+
^
<
%
%
Figure 6-14. Routing Daemons LX073.2
Notes:
Linux, as most UNIX systems, typically comes with two or three routing daemons:
• The first routing daemon is routed. It is also the oldest of the two. It implements the RIP
protocol only, and since RIP does not need any local configuration, the routed daemon
does not need a configuration file as well. In fact, the only configuration option you
might want to set (whether your daemon is active, meaning broadcasting information, or
passive, meaning only listening for information) is set for you based on whether IP
forwarding is turned on or not.2
The RIP protocol, and thus the routed daemon, should only be used in simple, small
and stable networks.
• The second routing daemon is gated. This daemon implements every routing protocol
that can be used on an IP network, including the previously mentioned RIP, RIPv2,
OSPF and BGP. Most of these protocols require extensive configuration though, so you
will quickly end up with a really complex /etc/gated.conf file.
2
Well, there is a command-line option which you can use if this default behavior does not suit you.

V3.0
Student Notebook
Uempty OSPF is the protocol of choice for large, complicated and/or unstable networks. BGP is
the standard routing protocol of the Internet.
• The gated daemon is a commercial product with a fairly restrictive license. Because of
this, and because of some technical issues, the zebra daemon was created. It is
currently nearing completion, and is beginning to replace gated in distributions (Red
Hat 8.0 has it, for example). Zebra is a more modular product and licensed under the
GPL.
In most organizations the Linux system administrator will not be the person who also
administers the routing daemon. Just as any large application on a Linux system, routing
daemon management and system management will be done by different people.

Student Notebook
%&$
*! *+
J

[+ J
' +

'
!
#!
"&#Q!

< !*+*
j
}
+* j
*+
}

! *+ * QQ
#
Figure 6-15. Debugging Routing Problems LX073.2
Notes:
Debugging routing problems is one of the hardest tasks in debugging network problems.
The absolute first prerequisite is to know the network. You have to know what networks are
connected to other networks by which router, and which IP addresses are used throughout
the network. It is extremely useful to draw maps of the network, for instance on a
whiteboard or flipchart, when debugging problems like this.
A useful option when debugging is -n. This option is used in most Linux commands related
to networking (route, netstat, ping, traceroute) and prevents the command from doing a
reverse DNS lookup (determining the host or network name for a given IP address). Apart
from showing you the IP addresses instead of hostnames, it also isolates any DNS
problems you might have.
As seen before, the route and netstat -r commands both show the routing table. This is
extremely useful, provided that you know how to interpret the table, and read it very
carefully.
We've seen the ping command already. The -R flag tells ping to record the route that the
packet has travelled in the IP header, and to show that route when the reply comes in.

V3.0
Student Notebook
Uempty There is one thing you need to know about this though: The number of routers that can be
recorded in the IP header is limited to nine.
The traceroute command seems to work the same as ping -R, but that is not true. ping -R
sends one packet the whole way, and waits for the reply to come in. Only then is the route
shown. That means that if one of the routers or the final destination has problems, that no
reply comes in and that nothing can be shown. traceroute, in contrast, works differently. It
sends an UDP packet to the destination, using a destination port which is known to be not
in use, but configures a Time To Live (TTL) of one. When this packet arrives at the first
router, the router decreases the TTL with one, yielding zero, and discards the packet as per
IP protocol requirements. It also returns an ICMP Time Exceeded message back to the
origin of the packet. traceroute duly records this and then sends an UDP packet with a
TTL of two. This packet is discarded at the second router, who returns an ICMP Time
Exceeded. This process goes on until the UDP packet arrives at the final destination, who
sends back an ICMP Port Unreachable. Then traceroute knows that the destination has
been reached and quits. The advantage of traceroute is that it will give you information,
even if the final destination or an intermediate router is having problems.
Finally, remember that routing is needed in both directions. It is not enough if your ping
(ICMP echo request) arrives at the destination. For you to see anything, the ping reply
(ICMP echo reply) also has to traverse back through the network.

Student Notebook
"
_K [ *+

K[
*
K !
K

K `

^K @ *
!
K @ *

Notes:
1.
2.
3.

V3.0
Student Notebook
Uempty
34
#Q*
+
*+
+

#

+

!

*
Q
% !

'!
^

"
Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 7. Domain Name System

This unit is an introduction to the Domain Name System (DNS). It
describes the concepts of the Domain Name System and the
configuration of a master name server, a slave name server, and a
client participating in a domain environment.

• Describe domain name concepts and terminology
• Configure a master and slave name server and a DNS client

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 7. Domain Name System 7-1
Student Notebook
Objectives

Describe domain name concepts and terminology
Configure a master and slave name server and a DNS
client
Notes:

V3.0
Student Notebook
Uempty
Domain Name System
RFC 1034 and 1035

System that allows lookups in a tree-like database
Finding a specific information item such as an IP
address that belongs to a "node" in the DNS system
The nodename is specified as a "Fully Qualified
Domain Name" (FQDN)
Hierarchical
Root domain: . (dot)
Top Level Domains (TLDs)
Generic (gTLDs) such as com, org, net
Country Code (ccTLDs) such as nl, au, uk
Subdomains
Decentralized
Every domain implements its own tables and servers
Every domain can do its own delegation of subdomain
Figure 7-2. Domain Name System LX073.2
Notes:
The Domain Name System is an Internet Standard. It is described in RFC 1034 and 1035,
with a number of later RFCs augmenting this description.
The purpose of the Domain Name System is to create a system that allows lookups in a
tree-like database. These lookups are mostly (but not only) finding an IP address that
belongs to a "node" (a hostname) in the Domain Name System. A hostname in this respect
is always a "Fully Qualified Domain Name" (FQDN).
The DNS system knows a hierarchical structure:
• The root node is the "dot" domain. This dot is the origin of all domains. It is comparable
with the root of a UNIX filesystem.
• Below the root node you will find a number of Top Level Domains (TLDs). These can
further be distinguished in Generic Top Level Domains (gTLD), such as com, org and
net, and Country Code Top Level Domains (ccTLDs), such as nl (for the Netherlands),
au (for Australia) and uk (for the United Kingdom).
Student Notebook
• Below a Top Level Domain an organization can apply for a subdomain. The application
criteria and procedure for this varies from TLD to TLD. When an application has been
granted, then that organization becomes the "owner" of a domain, and can use it to
store information about its own hosts and (possibly) other subdomains.
Furthermore, the DNS system is decentralized. This means that there is no central
database which holds all the information, but organizations all keep their own databases on
their own servers. Through special so-called "glue records", these databases all point to
each other, making global lookups possible.

V3.0
Student Notebook
Uempty
DNS Hierarchy Example
The root domain .
gTLDs
com org net nl au uk ccTLDs
ibm
www mail watson
watson.ibm.com
pc387
domain The FQDN of this node is
ibm.com domain pc387.watson.ibm.com.
Figure 7-3. DNS Hierarchy Example LX073.2
Notes:
The visual shows an example of a possible DNS structure. The root domain is on top, with
the gTLDs and the ccTLDs right below it. There is one subdomain, ibm.com, which in itself
has another subdomain, watson.ibm.com. Furthermore, three hosts are shown,
www.ibm.com, mail.ibm.com and pc387.watson.ibm.com.
Note that when we are talking about Fully Qualified Domain Names, the final dot should be
included. So the FQDN of pc387 is "pc387.watson.ibm.com." and not
"pc387.watson.ibm.com". This becomes important later on.
Student Notebook
Resource Records
Data (for instance, an IP address) is associated with a

node using Resource Records
The RR identifies the sort of data that is stored
Common RR's for hosts:
A (Address): The IP address of the node
PTR (Pointer): The hostname of the node
CNAME (Common Name): The node for which this is
an alias
HINFO (Host Info): Information about this node
Common RR's for domains:
NS (Name Server): The nameserver of the node
MX (Mail Exchanger): The mail server of the node
SOA (Start of Authority): Information from the
authoritative server of the node
Figure 7-4. Resource Records LX073.2
Notes:
The hierarchical structure as shown in the previous visual can be thought of as the key to
the database. With an FQDN we can find the record for a specific host. The next thing we
need to retrieve is the data that is stored about this host. This is done through a series of
"resource records".
Each resource record stores something about the "node", as each host or domain is called
in DNS-speak. What is stored, depends on the resource record type. There are several
resource records possible. Some are typically only used for a host, and others are typically
only used for a domain. But there is no general rule in this respect. In fact, the DNS system
doesn't even know the difference between a host or a domain.
Common RRs for a host include:
A (Address) This RR gives the IP address of a node.
PTR (Pointer) This gives the FQDN of a node.
CNAME (Common Name) This is used to define aliases. The CNAME is stored with
the alias and lists the official name of a node.

V3.0
Student Notebook
Uempty HINFO (Host Information) This gives information about the host itself, such as
hardware, operating system, administrative contact and so
on.1
Common RRs for a domain include:
NS (Name Server) This identifies a name server for this node.
MX (Mail Exchanger) This identifies the mail server for this node.
SOA (Start of Authority) This indicates that a node and all nodes below it are
managed by a different organization from the nodes above.
It identifies the organization that manages this node and
below, and gives some timing parameters for this domain.
These parameters have to do with how long entries may be
cached and how often slave name servers need to check
for updates, for instance.
1
For security reasons, this RR is rarely used any more.
Student Notebook
Resource Records Example
. NS a.root-servers.net
NS b.root-servers.net
com org net nl au uk

NS a.gtld-servers.net
NS ns1.ibm.com
NS b.gtld-servers.net
NS ns2.ibm.com
ibm MX 0 mail.ibm.com
www mail watson

NS ns.watson.ibm.com
A 129.42.16.99 A 129.42.18.99
pc387
A 129.1.151.17
Figure 7-5. Resource Records Example LX073.2
Notes:
As said before, each node in the DNS tree can have various resource records associated
with it. The visual shows some of the resource records that would be associated with the
various nodes in our example.
First, we start with the root (dot) domain. This domain has two resource records associated
with it, both of which describe who the name servers are for this domain.2
The second node we cover is the com domain. Again, two resource records which list the
name servers for this domain.3
The third node is the ibm.com domain. This domain has two DNS servers listed as well, but
also lists an MX record. This record identifies the mail exchanger for the ibm.com domain,
and is used when somebody sends email to someone@ibm.com.
Both www.ibm.com and mail.ibm.com are hosts, and thus have an A record (an IP address)
associated with them.
2
Note that a name server for a domain does not have to be in that domain!
3
The domain name servers for the root (dot) domain and the TLDs are managed by the so-called registrars, the organizations that
receive and grant applications for a domain. Several other organizations like universities have configured their DNS servers as slave
servers from these servers and offer DNS service for these domains to all clients as well, to spread the load.

V3.0
Student Notebook
Uempty watson.ibm.com is a subdomain of the ibm.com domain, and thus has an NS record
associated with it.
The last node, pc387.watson.ibm.com, is again a host and has an A record to identify its IP
address.
Student Notebook
DNS Lookups
pc387# host www.ibm.com
com org net nl au uk

4
2
5 3
ibm
6
7
www mail watson

A 129.42.16.99 8 1
pc387
Figure 7-6. DNS Lookups LX073.2
Notes:
The visual shows the result of the command "host www.ibm.com", executed on pc387. In
the example, eight DNS queries and responses are performed:
1. The first query is a so-called "recursive" query from pc387 for the IP address of
www.ibm.com to the DNS server of the watson.ibm.com domain. The IP address of this
name server is known to pc387 (it is configured in its /etc/resolv.conf file).
A recursive query in this respect means "I want the answer to this question." This
means that the answer that pc387 expects is the IP address of www.ibm.com.
2. The second query is a so-called "iterative" query from the name server of watson to one
of the root nameservers. Again, the query is for the IP address www.ibm.com.
An iterative query, in contrast to a recursive query, means "I want your help in
answering this question." This means that the watson nameserver will be happy with
any help that the other party can give.
3. The third packet is a reply from the root nameserver, and identifies the nameserver of
the com domain.

V3.0
Student Notebook
Uempty 4. The fourth packet is again an iterative query from the watson name server to one of the
com nameservers.
5. The fifth packet is a reply from the com nameserver, and identifies the nameserver of
the ibm.com domain.
6. The sixth packet is again an interactive query from the watson name server to one of
the ibm.com nameservers.
7. The ibm.com nameservers are "authoritative" for the ibm.com domain. This means that
they have the database which describes all nodes in the ibm.com domain, including the
www.ibm.com node. So the answer that these nameservers can reply (in packet
number seven) is the IP address for the www.ibm.com node.
8. The watson nameserver now knows the IP address of the www.ibm.com node, and
returns this to pc387 (in the eighth packet).
Apart from the procedure to look up a hostname, this also illustrates the benefit of having a
combination of iterative and recursive queries:
• Clients are typically connected to the network through fairly slow lines. If a client would
need to do iterative lookups, then all queries and answers would have to go over this
slow line, reducing performance.
• In contrast, if only recursive queries were allowed, then a very heavy burden would be
placed on the root name servers.
Having a combination of clients doing recursive queries and name servers doing iterative
queries turns out to be the most efficient scheme.
Student Notebook
Reverse DNS Lookups
IP address to Hostname lookups

.
com org net nl au uk arpa

in-addr
ibm 129
1
www mail watson 151
17
pc387
PTR pc387.watson.ibm.com.
A 129.1.151.17
Figure 7-7. Reverse DNS Lookups LX073.2
Notes:
IP address to Hostname lookups would, if nothing else was arranged, require you to go to
every DNS server on the Internet, and see if the IP address was somehow in its tables.
Obviously this is completely impossible. Yet we can do reverse DNS lookups. This is done
by using an ingenious trick, which involves a special "in-addr.arpa" domain. The visual
illustrates how this works.
Suppose someone wants to do a reverse DNS lookup for the IP address 129.1.151.17. The
first step then is to convert this IP address to its corresponding DNS name, which is
"17.151.1.129.in-addr.arpa." This may look strange at first, but remember that IP
addresses become more specific when going from left to right, and that hostnames
become more specific when reading from right to left. To fit IP address in a
hostname-based scheme, we've got to reverse the order.
Just as before, the name servers are then queried for this node. Only this time it's not the A
record (IP address) we're looking for, but the PTR (FQDN) record.

V3.0
Student Notebook
Uempty In all but a few cases, the organization that manages the name-to-IP domain will also
manage the IP-to-name domain. In our example, the nameserver that manages
watson.ibm.com will therefore also manage 151.1.129.in-addr.arpa.
Configuring reverse DNS lookups correctly is pretty hard at first, because of the reversed
IP addresses. Just imagine that you are still talking about regular domains and you'll be
fine.
Note: It is extremely important that reverse DNS lookups are configured correctly. Almost
all services on the Internet can (and about half of the services actually will) perform a
reverse DNS lookup to retrieve the hostname of a client. This hostname is then used for
authorization and logging. If the reverse DNS lookup fails, chances are that the client is
simply not allowed to use the service, or only after a long timeout.
The last visual of this unit has a script listed in the notes which allow you to check whether
regular and reverse DNS lookups match.
Student Notebook
Nameservers
Master Nameservers
Are "authoritative" for a domain
May initiate zone transfers to slave nameservers
Service all client requests
Cache lookups for other domains
Slave Nameservers
Are also authoritative for a domain
Retrieve data from a master nameserver in a zone
transfer
Cache lookups for other domains
Caching-Only Nameservers
Have no data for a domain
Cache lookups for all domains (but are not authoritative)
Figure 7-8. Nameservers LX073.2
Notes:
A "master nameserver" is a nameserver which is "authoritative" for a domain or multiple
domains (most likely the domain itself and the associated reverse DNS domains). This is
the server where the administrator makes changes to the DNS tables. The master
nameserver can serve requests from clients and other name servers, both recursive and
iterative. When it needs to perform a lookup for another domain and it receives answers, it
caches these answers for later reference.
A "slave nameserver" is also authoritative for a domain, but retrieves this data in a
so-called "zone transfer" from a master nameserver.4 It also can serve requests from
clients and other nameservers, and can cache data from other domains.
A "caching-only nameserver" does not have its own data and is not authoritative for a
domain. It just performs iterative queries for clients. All results obtained are cached
however, making it a useful thing to have in a small network which does not warrant its own
slave nameserver but is connected to the outside world through a slow link.
4
In more complex environments, slave nameservers can also retrieve the data from other secondaries.

V3.0
Student Notebook
Uempty
Scenario - Domain Name Structure
(root)
com
ibm
sys99.ibm.com
dc
sys1 - Master
Name Server
9.19.98.1 sys6 - Slave
sys4 Name Server
9.19.98.2 9.19.98.3 9.19.98.4 9.19.99.6
sys2 sys3 9.19.99.4
sys4e 9.19.99.5
sys5
Figure 7-9. Scenario - Domain Name Structure LX073.2
Notes:
This scenario will be used in the remainder of this unit. It shows the dc.ibm.com domain,
which spreads across two physical networks. sys99.ibm.com is a higher-level name server
which serves the ibm.com domain.
Student Notebook
Setting Up the Master Name Server
Create "named" control file

Create name zone file
Create IP zone files
Create local IP zone file
Create cache file
Start "named" daemon
Figure 7-10. Setting Up the Master Name Server LX073.2
Notes:
Setting up a master nameserver requires you to do several things:
The first thing to do is configuring the control file of your nameserver. Virtually all Linux
distributions use BIND (Berkeley Internet Name Distribution) version 8 or later. For these
versions, the control file is called /etc/named.conf. Older versions of BIND use
/etc/named.boot, which is far less flexible. If your distribution still uses /etc/named.boot, you
should upgrade to a newer version of BIND, since these older versions contain a number of
security problems which will not be patched any more. The configuration of
/etc/named.boot will not be discussed in this course.
The control file identifies various global options, and then lists each domain for which we
are a master or slave nameserver. It also lists the file in which the information about this
domain can be found.
The next step is to configure the "zone files" (the files that hold the domain information)
themselves. You nearly always need to configure both the "name zone files", which are
used for hostname-to-address lookups, and the "IP zone files", which are used for
address-to-hostname lookups.

V3.0
Student Notebook
Uempty Also required is the configuration of the "local IP zone file", which basically ensures that
"127.0.0.1" can be looked up, yielding the answer "localhost". This file is really not
spectacular (the default file that comes with BIND usually works perfectly) but is crucial for
things like the X Window System to work properly.
You then need to create the cache file. This file lists the other nameservers that can be
used for higher-level name resolution. If you are connected to the Internet, then this file
should contain all the hostnames and IP addresses of the name servers for the root (dot)
domain. If you are on an intranet, it should point to any upstream nameserver. This file is
called the cache file because all entries that are resolved through these nameservers can
be cached locally.
The last thing you need to do is start the named daemon, and test that everything works.
Student Notebook
Master Name Server Control File

# cat /etc/named.conf
options { directory "/var/named"; };
zone "dc.ibm.com" {
type master; file "named.dc.ibm.com";
};
zone "98.19.9.in-addr.arpa" {
type master; file "named.9.19.98";
};
};
};
zone "localhost" {
type master; file "named.localhost";
}
zone "." {
type hint; file "named.ca";
};
Figure 7-11. Master Name Server Control File LX073.2
Notes:
The visual lists the control file for our domain. This file starts off with defining the "directory"
option. This specifies where all files mentioned in this file can be found. /var/named is
usually a good place.
The file then defines five zones. Each of the five zones identify us as a master, meaning
that we are the master name server for this zone. It also lists the file in which information for
this zone can be found.
The last thing that is defined is the root zone. We are not a nameserver for this domain,
obviously, but we need to go to another nameserver for that and are allowed to cache the
answers. Which nameserver to use for this zone is listed in the named.ca file.

V3.0
Student Notebook
Uempty
Syntax of a named Zone File
[<Name>] [<TTL>] [<Class>] <RR type> <RR data>
Data for this resource record.

If data is multiple fields (eg
SOA), use () for line
continuation
Resource Record type, eg. A, PTR,
CNAME, MX, SOA
Resource Record class, eg. IN (for internet),
XS (for Xerox networking) - today, only IN is
used and is typically omitted since it's the default.
Time To Live (in seconds) for this particular entry.
If no TTL is given then the generic TTL is used which is
identified as "$TTL <seconds>" at the start of the zone file.
The name of the node that is described here. Should start at column 1!
Use "@" as abbreviation for "current domain" (as defined in named.conf).
If no name is given, the name of the previous RR stanza is used.
Figure 7-12. Syntax of a named Zone File LX073.2
Notes:
The visual shows the syntax of a named zone file. In essence, a zone file consists of five
columns:
• The first column, which must start on the first character of the line, is the name of the
node that is described here. You can use "@" for "current domain", and if you leave this
column blank (in other words: the line start with a space or TAB), then the previous
node name is used.
If the node name does not have a period at the end, then the "current domain" is
automatically appended to the name.
• The second column, which is optional, describes the time to live for this entry. This is
the maximum amount of seconds that this particular entry may be cached in other name
servers. If no TTL is given, then the TTL is used that is defined at the start of the file
using a line like:
$TTL 86400
Student Notebook
• The third column is the resource record class. The DNS system was originally designed
to hold much more than just IP addresses and host names, and this column allowed
you to identify the class of data that this entry describes.
Today, DNS is only used to store IN (Internet) data, and other classes, such as Xerox
networking (XS) are not used. Fortunately, IN is also the default class, so this column is
usually omitted.
• The fourth column describes the Resource Record type, such as A, PTR, MX, SOA and
so forth.
• The fifth column lists the RR data.
Some RR records, in particular the SOA record, require multiple fields, and listing all
these fields on a single line may not be possible. In that case, you can use parenthesis
to continue the records on the next line.

V3.0
Student Notebook
Uempty
Name Zone File
# cat /var/named/named.dc.ibm.com
; Default TTL
$TTL 86400
;NAME TTL CLASS TYPE RDATA
@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.(
2002061001 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL
IN NS sys1.dc.ibm.com.
sys1 IN A 9.19.98.1
sys2 3600 IN A 9.19.98.2
sys3 IN A 9.19.98.3
sys4 IN A 9.19.98.4
sys4e IN A 9.19.99.4
sys5 IN A 9.19.99.5
sys6 IN A 9.19.99.6
Figure 7-13. Name Zone File LX073.2
Notes:
The visual lists the /var/named/named.dc.ibm.com zone file, the file that describes the
dc.ibm.com domain. The layout of this file is really complicated, so we cover it slowly.
The first line of the file, “; Default TTL”, is a comment line. Comments in a DNS zone file
start with a semicolon and end at the end of the line.
The second line of the file, “$TTL 86400” defines the default TTL (Time To Live) for all
entries in the file. This will be discussed further on.
The third line is again a comment.
The rest of the file consists basically of five columns, separated by whitespace (spaces or
tabs):
• The first column describes the node we are talking about. This can be written in three
ways:
- By using a Fully Qualified Domain Name, such as "sys1.dc.ibm.com.". (Note the dot
at the end of the hostname!)
Student Notebook
- By using a short hostname, such as "sys1". The named daemon recognized that
there's no dot at the end, and automatically appends the current domain.
- By using the at-sign ("@"), which stands for "current domain". The current domain is
the domain that was defined in the named control file for this file.
If the first column is left empty, then the same node from the previous line is used.
• The second column, which may be empty, specifies the Time To Live, which is the
maximum time an entry may be kept in the cache of another nameserver. If it is empty,
the default value that was defined with the $TTL directive is taken.
In our example only one host, sys2, has a TTL defined. All others will use the default
TTL of 86400. The reason for this might be that the DNS administrator is expecting a
change to sys2, and wants all other DNS servers not to cache this entry for a long time.
• The third column, which also may be empty, specifies the class. This is rather historic:
the DNS system was also used to lookup non-Internet (Chaosnet or Hesiod)
information. The only class that is currently being used is "IN". It is also the default
class, so it can be omitted.
• The fifth column identifies the type of the resource record we are specifying here. Each
resource record will be dealt with later in more detail.
• The sixth column is the data for the resource record.
Various sorts of resource records can be defined in a zone file. The most important are:
A This lists the IP address of the node. The data can only be the IP address in
decimal dot notation. Other data or other notations are not allowed.
NS This lists the nameserver for a node. The data should be a fully qualified domain
name (which ends in a dot!)
SOA This identifies that the node is the Start of Authority, meaning that the domain is a
separately administered zone, and it specifies some important values for this
zone. The SOA specification always follows the following format:
<pr. nameserver> <admin email> <serial> <refresh> <retry>
<expire> <min. TTL>
The parenthesis just allow you to span the SOA record over multiple lines, and the
semicolons start a comment. Both are here to make things more readable.
<pr. nameserver> identifies the master nameserver for this zone.
<admin email> identifies the email address of the zone administrator. One
catch here: Since the at-sign (@) is a special character for DNS, it is replaced by
a dot. Thus, to get a valid email address, you need to replace the first dot in the
email address with the at-sign.
<serial> identifies the serial number of this file. The idea is that slave
nameservers regularly retrieve the SOA of the domain for which they are the slave
server. They look at the serial number and if it has increased, they know that data
from the domain has changed and they do a zone transfer. (If the value has

V3.0
Student Notebook
Uempty decreased, they log an error message.) It is therefore important that each time
you make changes to this file, you increase the serial number.
Serial numbers may include the decimal point and a decimal fraction, but for
technical reasons it is a good idea to stick to integers as serial numbers.5 In fact,
most people use the date, followed by a simple number (YYYYMMDDnn) as their
serial number.
<refresh> tells the slave nameserver how often it should check whether the
data on the master has changed.
<retry> identifies how often a slave should try to check the master, if the first
check failed.
<expire> identifies the maximum amount of time a slave nameserver may serve
clients if the master nameserver cannot be reached. It should be much larger than
the refresh and retry interval.
<minimum TTL> identifies how long data from this zone may be cached, if no
cache interval was given for a node.
Starting with BIND version 9, the SOA values can also be specified in days, hours
and minutes, by using the D, H and M characters, as in 3D5H2M (3days, 5 hours
and 2 minutes), which equals 277320 seconds.
PTR This lists the FQDN of a node, and is used in ip-to-hostname lookups.
CNAME This identifies that the node is an alias name for another node, and identifies what
other node this alias is for.
There are several others. Consult the DNS standards and the BIND documentation for an
explanation about them.
So in short, the file in the visual means the following:
"If not stated otherwise, all Resource Records in this zone can be cached 86400 seconds.
The current domain is the start of a zone. The master nameserver for this zone is
sys1.dc.ibm.com, and the email address of the administrator is root@sys1.dc.ibm.com.
The current serial number is 2002100601. Slave nameservers need to check back every
3600 seconds (one hour) and if the master nameserver is not available at that time, check
back every 300 seconds (five minutes). Nodes in this zone expire after 3600000 seconds
(1000 hours, roughly forty days), and the minimum time that entries may be cached, if not
specified, is 86400 seconds (one day).
The current domain has two nameservers, sys1.dc.ibm.com and sys6.dc.ibm.com.
The host sys1 in the current domain (so its FQDN is sys1.dc.ibm.com.) has IP address
9.19.98.1.
The host sys2 in the current domain (so its FQDN is sys2.dc.ibm.com.) has IP address
9.19.98.2. This information can be cached 3600 seconds."
And so forth...
5
BIND considers 1.1 to be larger than 2.0, for instance.
Student Notebook
IP Zone File
# cat /var/named/named.9.19.98
; Default TTL
$TTL 86400
2002061001 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
1 IN PTR sys1.dc.ibm.com.
2 3600 IN PTR sys2.dc.ibm.com.
Figure 7-14. IP Zone File LX073.2
Notes:
The visual shows the IP zone file for the 9.19.98 network, which is equal to the
98.19.9.in-addr.arpa domain. The nameserver that was authoritative for dc.ibm.com is also
authoritative for this domain, so the SOA record is the same, as are the NS records. The
only difference is in the lines that describe the nodes themselves.
The first node is "1". There's no dot at the end, so it's not an FQDN. We therefore add the
current domain, which yields 1.98.19.9.in-addr.arpa, the reverse name of 9.19.98.1. This
node has a PTR record, sys1.dc.ibm.com, which is the FQDN of that system.
The IP zone file for the 9.19.99.0 network (/var/named/named.9.19.99) is not shown in the
visual, but it will look like this:

V3.0
Student Notebook
Uempty ; Default TTL

$TTL 86400
2002061001 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
4 IN PTR sys4e.dc.ibm.com.
Student Notebook
Local Zone Files

# cat /var/named/named.localhost
; Default TTL
$TTL 86400
2002061001 3600 300 3600000 86400 )
1 IN PTR localhost.
; Default TTL
$TTL 86400
2002061001 3600 300 3600000 86400 )
@ IN A 127.0.0.1
Figure 7-15. Local Zone Files LX073.2
Notes:
Every nameserver needs to be able to resolve 127.0.0.1 into the hostname localhost and
vice versa. That's why every nameserver will be a master nameserver for the "localhost"
and the "0.0.127.in-addr.arpa" domain. There's nothing spectacular here. It's just
something you need to do.
The files that list these zones are listed above.

V3.0
Student Notebook
Uempty
Cache File
# cat /var/named/named.ca
. 9999999 IN NS sys99.ibm.com.
sys99.ibm.com. 9999999 IN A 9.19.93.99
- OR -
. 3600000 IN NS a.root-servers.net.
a.root-servers.net. 3600000 IN A 198.41.0.4
. 3600000 IN NS b.root-servers.net.
b.root-servers.net. 3600000 IN A 128.9.0.107
. 3600000 IN NS c.root-servers.net.
c.root-servers.net. 3600000 IN A 192.33.4.12
; and so forth
Figure 7-16. Cache File LX073.2
Notes:
The cache file has exactly the same layout as the files we've discussed before. It basically
describes the characteristics of the root (dot) domain.
The only difference is that we are not authoritative for this domain, so we cannot specify a
SOA record. And we do not know (or at least, we're not supposed to know) any IP
addresses in this domain. The only thing we are supposed to know is the name and, more
importantly, the IP address of the nameserver(s) which serve this domain. So these are the
only entries listed in this file.
Now, there's two possibilities here:
• The first possibility is that you are a nameserver on an intranet, with no direct outside
connection. In this case, you list an upstream DNS server as the name server for the
root domain. Which one is really not important, as long as they are able to resolve your
queries.
• The second possibility is that you are a nameserver on the Internet. In this case, you
should list the root nameservers of the Internet themselves. This list can be obtained on
Student Notebook
the web and added to your files. In addition to this, BIND automatically contacts one of
these nameservers when BIND is started, and retrieves the current list of all root
nameserver. It then uses this information instead.

V3.0
Student Notebook
Uempty
Final Master Name Server Setup Steps
Ensure the hostname is the fully qualified domain name

# hostname
Configure hostname, if needed
redhat# vi /etc/sysconfig/network
suse# vi /etc/HOSTNAME
Create /etc/resolv.conf
# vi /etc/resolv.conf
domain dc.ibm.com
nameserver 9.19.98.1
Start named
redhat# service named start
suse# rcnamed start
Figure 7-17. Final Master Name Server Setup Steps LX073.2
Notes:
The final steps of configuring a master nameserver are really simple.
The first step is to ensure that the nameserver has the correct, Fully Qualified Domain
Name as its hostname.
The second step is to create an /etc/resolv.conf file which contains the IP address of the
nameserver, and the domain we're in.
The last step is to start the named daemon. This can be done using the regular initscripts.
Student Notebook
Checklist: Adding a Host to the Domain
Update name zone file

add host entry A record
add any optional records such as CNAME
increase serial value in SOA record
Update IP zone file
add IP address entry PTR record for each interface
increase serial value in SOA record
Refresh named
Check slave name servers
Figure 7-18. Checklist: Adding a Host to the Domain LX073.2
Notes:
The checklist in the visual is used when adding a host to a domain. If a host is added to the
domain, it should be added to both the name zone file and the IP zone file. Don't forget to
increase the serial value. Then, restart or refresh the named daemon, for instance with
service named restart or rcnamed restart
If a master nameserver detects that files have changed, it will send an indication of this to
the slave name servers.6 This is the signal for them to do a zone transfer right away. You
should check however that this actually happened.
6
This NOTIFY is described in RFC 1996. Nameservers are currently not required to send or receive notify messages. The BIND
versions on most Linux distributions however do implement this mechanism.

V3.0
Student Notebook
Uempty
Setting Up the Slave Name Server
Create "named" control file

Create local IP zone file
Create cache file
Start "named" daemon
Figure 7-19. Setting Up the Slave Name Server LX073.2
Notes:
The slave nameserver setup is much easier than the master, since it downloads the zone
files from the master. We only need to create the named control file and do some other
minor things, and we're done.
Student Notebook
Slave "named" Control File
zone "dc.ibm.com" {
type slave; file "named.dc.ibm.com.bak"; masters {9.19.98.1;};
};
type slave; file "named.9.19.98.bak"; masters {9.19.98.1;};
};
type slave; file "named.9.19.99.bak"; masters {9.19.98.1;};
};
zone "localhost" {
};
};
zone "." {
};
Figure 7-20. Slave "named" Control File LX073.2
Notes:
The slave named control file looks just like the one from the master, with just one
exception: For every zone for which we are a slave nameserver, we define ourselves as
type "slave", and we need to identify the master name server for that domain. Also notice
that the filename ends in ".bak". This is to indicate that we are talking about a backup file,
which was automatically downloaded from the master server. It should not be edited, since
changes in this file will be lost if changes are made to the master server. This file is only
used when a slave nameserver is started while the master nameserver is down. In that
case, a zone transfer cannot be done and the backup file is used.

V3.0
Student Notebook
Uempty
Local Zone Files
# cat /var/named/named.localhost
; Default TTL
$TTL 86400
2002061001 3600 300 3600000 86400 )
1 IN PTR localhost.
; Default TTL
$TTL 86400
2002061001 3600 300 3600000 86400 )
@ IN A 127.0.0.1
Figure 7-21. Local Zone Files LX073.2
Notes:
These files are exactly the same as on the master nameserver.
Student Notebook
Cache File
. 9999999 IN NS sys99.ibm.com.
sys99.ibm.com. 9999999 IN A 9.19.93.99
- OR -
. 3600000 IN NS a.root-servers.net.
a.root-servers.net. 3600000 IN A 198.41.0.4
. 3600000 IN NS b.root-servers.net.
b.root-servers.net. 3600000 IN A 128.9.0.107
. 3600000 IN NS c.root-servers.net.
c.root-servers.net. 3600000 IN A 192.33.4.12
; and so forth
Figure 7-22. Cache File LX073.2
Notes:
This file is also exactly the same as on the master.

V3.0
Student Notebook
Uempty
Final Slave Name Server Setup Steps

# hostname
redhat# vi /etc/sysconfig/network
suse# vi /etc/HOSTNAME
domain dc.ibm.com
Start named
redhat# service named start
suse# rcnamed start
Figure 7-23. Final Slave Name Server Setup Steps LX073.2
Notes:
The final steps are the same as well, with one minor difference: The order of the DNS
servers in the /etc/resolv.conf file.
The DNS servers in the /etc/resolv.conf file are checked in the order as they appear in this
file, so it is a good idea to list the nearest name server (the local one) first.
Student Notebook
Caching-Only Nameservers
Do not have their own data

Only caching
Useful if you need more DNS servers but want to avoid
the overhead of downloading zone data to secondary
servers
zone "localhost" {
};
};
zone "." {
};
Figure 7-24. Caching-Only Nameserver LX073.2
Notes:
A caching-only nameserver does not have its own data, it only performs caching. This is
really useful if you need more DNS servers in your zone, for instance because you have a
large number of clients on a lot of networks with a slow connection to the backbone. You
could configure slave nameservers on each of those networks, but this requires you to do
regular zone transfers over those slow lines. A better approach might be to configure
caching-only nameservers on each network. This has the benefit of caching, but not the
disadvantage of the zone transfers.
Since a caching-only nameserver has no data of its own, the only three files required are
the file describing the local zones and the cache file.

V3.0
Student Notebook
Uempty
Managing Your Nameserver
Management of the name server daemon is done via the

network with the rndc utility
Need to configure authentication keys first
In /etc/named.conf
In /etc/rndc.conf
Generate keys with rndc-confgen
Most distributions configure rndc keys during install
When configured, use rndc to:
Reload configuration files and zone data
Write server statistics to statistics file
Dump the active database
Stop the server
Retrieve the server status
Change debugging level
Flush the servers cache
Figure 7-25. Managing Your Nameserver LX073.2
Notes:
You can imagine that, in a large network, the DNS server is a crucial piece in your
networking infrastructure: If the DNS server is unavailable, virtually nobody is able to get
any work done. Because of this, the ISC (Internet Software Consortium, the organization
that developed bind) has gone to great lengths in making the name server daemon
manageable without having to stop it.
Management of the named daemon is done via the network with the rndc tool. In order to
use it, you first have to generate a common key, and configure it both in the named
configuration file (/etc/named.conf) and in the rndc configuration file (/etc/rndc.conf). A key
is generally generated with the tool rndc-confgen.
Student Notebook
When configured properly, your /etc/named.conf file will contain the following additional
stanzas:
controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "m3Xz8IIgz/dqUK1KkVGFCQ==";
};
And obviously the same key will appear in /etc/rndc.conf too:
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
key "rndc-key" {
algorithm hmac-md5;
secret "m3Xz8IIgz/dqUK1KkVGFCQ==";
};
Most distributions configure rndc keys by default, so you generally don’t have to worry
about this.
Once your rndc keys have been configured, you can use rndc to
• Reload configuration files and zone data
• Write server statistics to statistics file
• Dump the active database
• Stop the server
• Retrieve the server status
• Change debugging level
• Flush the servers cache
For a full list, run the rndc command without any arguments or options.

V3.0
Student Notebook
Uempty
Setting Up the Client

# hostname
# vi /etc/sysconfig/network
# vi /etc/HOSTNAME
domain dc.ibm.com
Figure 7-26. Setting Up the Client LX073.2
Notes:
Configuring a client is really simple after all this. As with the servers, it comes down to
configuring the correct hostname and configuring a correct /etc/resolv.conf (with the closest
nameserver listed first).
If the /etc/resolv.conf file exists, DNS lookups are performed automatically, although you
might alter this behavior by editing the file /etc/nsswitch.conf.
Student Notebook
Debugging DNS Problems
Check for a correct /etc/resolv.conf file on all clients

ping -n all nameservers
Use host, nslookup and dig to query nameservers
Check if the normal and reverse lookups match for all
systems
Review the /var/named/* files
Watch out for missing dots at the end of an FQDN
Dump the active named database
Figure 7-27. Debugging DNS Problems LX073.2
Notes:
Debugging DNS problems requires a good understanding of the DNS system, and a lot of
experience. Several things are helpful:
The first thing is to check the /etc/resolv.conf file on the client which has problems. Various
protocols, such as PPP and DHCP have the ability to automatically configure the DNS
servers too. This is generally done by the client tool editing the /etc/resolv.conf file, and this
may occasionally destroy or alter this file.
The second thing to remember is when you try to ping the nameservers to see if they are
reachable, use ping -n. This prevents ping from doing reverse DNS lookups.
You can use the host, nslookup and dig commands to query nameservers directly. This
will be covered in the next visuals.
When reviewing the /var/named/* files, watch out for missing dots at the end of an FQDN.
This is a very common mistake.
As a last resort, you can do a dump of the active database. This shows you the internal
database of the named daemon, which also includes any cached entries.

V3.0
Student Notebook
Uempty
host, nslookup and dig
Queries domain name servers

host only used for Hostname->IP and IP->Hostname
lookup:
# host sys1
sys1.dc.ibm.com has address 9.19.98.1
nslookup more advanced
dig latest tool
Figure 7-28. host, nslookup and dig LX073.2
Notes:
host, nslookup and dig all query nameservers directly. They differ in the implementation
though.
The host command only allows you to do hostname-to-address and address-to-hostname
lookups. It does not allow you to query for MX or SOA records for instance. It also does not
allow you to select the nameserver to be queried: It uses the /etc/resolv.conf file for
nameserver selection.
The advantage of the host command is that it can be scripted easily, since the output is
always the same. For instance, here's a script that allows you to check if regular and
reverse lookups match:
Student Notebook
#!/bin/bash
# dnstest: Test whether the reverse and regular DNS lookups match
usage()
{
echo "Usage: $0 <ip address>"
exit
}
if [ $# -ne 1 ]
then
usage
fi
hostname=‘host $1 | awk {print $5}‘

if [ $? -ne 0 -o -z "$hostname" ]
then
echo "Reverse lookup for $1 failed."
exit
fi
ip=‘host $hostname | awk {print $4}‘

if [ $? -ne 0 -o -z "$ip" ]
then
echo "Lookup for $hostname failed."
exit
fi
if [ "$1" != "$ip" ]
then
echo "Reverse and normal lookup for $0 do not match!"
else
echo "DNS for $1 ($hostname) is ok."
fi
nslookup is far more advanced. It allows you to select the nameserver to use, and it can
be used noninteractively, where it is called from the shell, and interactively, where you type
commands against the nslookup prompt. The next two visuals show examples of both. dig
is an even more advanced tool than nslookup, and is expected to replace nslookup in the
near future.

V3.0
Student Notebook
Uempty
nslookup Noninteractive Queries
$ nslookup sys3
Server: sys1.dc.ibm.com
Address: 9.19.98.1
Name: sys3.dc.ibm.com
Address: 9.19.98.3
$ nslookup -querytype=ANY dc.ibm.com

Address: 9.19.98.1
dc.ibm.com
origin = sys1.dc.ibm.com
mail addr = root.sys1.dc.ibm.com
serial = 20020610
refresh = 3600
retry = 300
expire = 3600000
minimum ttl = 86400
dc.ibm.com nameserver = sys1.dc.ibm.com
sys1.dc.ibm.com internet address = 9.19.98.1
Figure 7-29. nslookup Noninteractive Queries LX073.2
Notes:
The visual shows examples of noninteractive queries.
Student Notebook
nslookup Interactive Queries

$ nslookup
Default Server: sys1.dc.ibm.com
Address: 9.19.98.1
> sys3
Address: 9.19.98.1
Name: sys3.dc.ibm.com
Address: 9.19.98.3
> set querytype=ANY

> dc.ibm.com
Address: 9.19.98.1
dc.ibm.com
origin = sys1.dc.ibm.com
mail addr = root.sys1.dc.ibm.com
serial = 20020610
refresh = 3600
retry = 300
expire = 3600000
minimum ttl = 86400
>exit
Figure 7-30. nslookup Interactive Queries LX073.2
Notes:
The visual shows the same examples as in the previous visual, but this time nslookup is
used in interactive mode.
Some other nslookup commands that can be used in interactive mode are:
server <nameserver> Start using another nameserver for lookups.
set d2
set debug Turn debugging mode on, which prints a lot more information
about the packets sent and received to/from the nameserver.
set querytype=<type> Change the type of information query to the specified RR type.
Use "ANY" to request all information.
set norecurse
set recurse Tell the name server to query other servers if it does not have
the information requested.

V3.0
Student Notebook
Uempty
dig Queries
$ dig @sys1.dc.ibm.com dc.ibm.com ns
; <<>> DiG 9.1.3 <<>> @sys1.dc.ibm.com dc.ibm.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59957
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:2
;; QUESTION SECTION:
;dc.ibm.com. IN NS
;; ANSWER SECTION:
dc.ibm.com. 86400 IN NS sys1.dc.ibm.com.
dc.ibm.com. 86400 IN NS sys6.dc.ibm.com.
;; ADDITIONAL SECTION:
sys1.dc.ibm.com. 86400 IN A 9.19.98.1
sys6.dc.ibm.com. 86400 IN A 9.19.99.6
;; Query time: 3 msec

;; SERVER: 9.19.98.1#53(sys1.dc.ibm.com)
;; WHEN: Mon Jun 10 13:48:21 2002
;; MSG SIZE rcvf: 78
Figure 7-31. dig Queries LX073.2
Notes:
Dig, short for Domain Information Groper is a flexible tool for interrogating DNS name
servers. It performs DNS lookups and displays the answers that are returned from the
name server(s) that were queried.
A typical invocation of dig looks like:
dig @server name type
where
server is the name or IP address of the name server to query. If no
server argument is given, dig consults /etc/resolv.conf and
queries the name servers listed there.
name is the name of the resource record to be looked up. If no name
is given, then dig will try a lookup of "." (dot).
type indicates what type of query is required -- ANY, A, MX, SOA etc.
If no type argument is supplied, dig will perform a lookup for an
A record.
Student Notebook
Active Database Dumps
Nameserver retains a lot of information in memory

Own domain data
Cached data
Statistics
All data can be dumped to disk on request
Useful to look at in case of problems
Stored in directory identified in named.conf
Dumps are initiated from rndc
rndc dumpdb: DNS data to named_dump.db
rndc stats: Statistics to named.stats
Figure 7-32. Active Database Dumps LX073.2
Notes:
As a last resort, if all else fails in debugging a nameserver, you might consider dumping the
entire database and going through it by hand. This is done with the rndc tool which we
discussed earlier:
• rndc dumpdb dumps the active database to the dump directory that was identified in
named.conf. If no specific dump directory was defined, then the generic directory as
defined in the named.conf options section is used.
• rndc stats dumps usage statistics to named.stats. The location of this file is again
defined in named.conf.

V3.0
Student Notebook
Uempty
Active Database Dump Example
; Dumped at Mon Jun 10 16:07:39 2002
; ---- Cache & Data ----
$ORIGIN 0.0.127.in-addr.arpa.
1 86400 IN PTR localhost.dc.ibm.com.
4 86400 IN PTR sys4e.dc.ibm.com.
$ORIGIN dc.ibm.com.
sys4e 86400 IN A 9.19.99.4
sys1 86400 IN A 9.19.98.1
sys2 3600 IN A 9.19.98.2
sys3 86400 IN A 9.19.98.3
sys4 86400 IN A 9.19.98.4
sys5 86400 IN A 9.19.98.5
$ORIGIN ibm.com.
sys99 86400 IN A 9.19.93.99
Figure 7-33. Active Database Dump Example LX073.2
Notes:
The visual shows an example database dump of the dc.ibm.com nameserver. You can
imagine that this quickly becomes large if your environment has hundreds of hosts.
Student Notebook
Checkpoint (1 of 2)
1. The TTL of the Standard Resource Records for the name server zone
files is specified in:
a. Minutes
b. Hours
c. Days
d. Seconds
2. There are many special characters to be used in the DNS zone files.
Which one of the following characters is used for continuing lines?
a. ;
b. @
c. #
d. ()
3. The IP octets are given in reverse order for IP addresses in the
in-addr.arpa zone file because:
a. It must be traversed left to right, similar to the domain name with the highest
level of hierarchy indicated last
b. It is the reverse translation of IP address to domain name
c. The host portion of the IP address is evaluated first
4. T/F. The named daemon must be running on every machine
participating in the domain environment.
Notes:
1.
2.
3.
4.

V3.0
Student Notebook
Uempty
Checkpoint (2 of 2)
5. When the system administrator wants to see the active name server
database, a file must be created which contains a dump of the active
database. This is done with the command ndc dumpds. The result of
that dump file is located in:
a. /etc/named_dump.db
b. /var/named/named_dump.db
c. /tmp/named_dump.db
d. named_dump.db in whatever directory was specified in /etc/named.conf
6. T/F. The zone files contain information regarding the nameserver's
zone of authority for both host to IP address name resolution and IP
address to host name resolution.
7.
___ Zone file defines the host to IP a. cache
address name resolution.
___ Zone file defines the IP address to b. name
host name resolution.
___ Zone file defines the local IP address resolution. c. local IP
___ File defines where to send requests for resolution d. IP
of names not contained in nameserver database.
8. What is the name of the file that tells the system DNS is being used?
Notes:
5.
6.
7.
8.
Student Notebook
Unit Summary
The DNS system provides a distributed database that

other systems query to perform name resolution
The three types of name servers are master, slave and
caching-only
The named daemon runs on the name servers
/etc/resolv.conf defines domain and name servers on
clients
host, nslookup and dig query name servers for
information
Notes:

V3.0
Student Notebook
Uempty Unit 8. Electronic Mail

This unit covers the Internet e-mail model and the way e-mail is
implemented on Linux. Popular mail user interfaces such as Netscape
or Microsoft Exchange are not covered in detail since their use is quite
straightforward.

• Describe the Internet e-mail model
• Describe the purpose of SMTP, POP3 and IMAP
• Configure Sendmail and Postfix for a simple mail domain
• Configure pop3 and imap on Linux
• Configure pop3s and imaps on Linux
• Describe how DNS MX records control e-mail delivery

Accountability:
© Copyright IBM Corp. 1999, 2003 Unit 8. Electronic Mail 8-1

Student Notebook
Objectives
After completing this topic, students should be able to:

Describe the Internet e-mail model
Describe the purpose of SMTP and POP3
Configure Sendmail and Postfix for a simple mail domain
Configure POP and IMAP on Linux
Describe how DNS MX records control e-mail delivery
Notes:

V3.0
Student Notebook
Uempty
E-mail Example
[ed@xyz]$ mail fred@abc.com
Subject: Test Message
Hi there, Fred.
.
Cc:
?
[fred@abc]$ mail
Mail version 8.1 6/6/93. Type ? for help.
"/var/spool/mail/fred": 1 message 1 new
>N 1 ed@xyz.com Wed Oct 2 22:28 11/353 "Test Message"
& n
Message 1:
From ed@xyz.com Wed Oct 2 22:28:43 1996
Date: Wed, 2 Oct 1996 22:28:42 -0500
From: ed@xyz.com (Ed Smith)
To: fred@abc.com
Hi there, Fred.
& q
Saved 1 message in /home/fred/mbox
Figure 8-2. E-mail Example LX073.2
Notes:
This visual shows an extremely simple example of how a user of a system uses the mail
command to send email to someone else. E-mail is a very easy to use system, which
proves to be very popular, both on the Internet and on company intranets.
To set up such an email system is rather complicated however, and will be the topic of this
lecture.

Student Notebook
E-mail Model
Sender User
Agent SMTP Message
Transfer Queue
Agent
Queue
mail client outgoing mail server

mail client SMTP incoming mail server
Receiver User POP/ Message

Agent
IMAP Transfer Queue
Agent
Queue
Figure 8-3. E-mail model LX073.2
Notes:
When a user wishes to send e-mail, he uses a program known as a User Agent to
compose a message and initiate the transfer to its destination. Examples of user agents
popular in UNIX are the relatively basic mail command as well as more powerful programs,
such as mailx, elm and pine. Even more advanced tools such as Netscape Mail or Eudora
can also be used. In that case, the user does not have to login to the mail server, but can
connect to the mail server over a network.
Once the user has composed the mail message, his user agent passes it to a message
transfer agent (MTA) to carry out the actual transmission. At some point, the MTA will then
transmit the message further, doing so by establishing a TCP connection to the MTA at the
recipient's systems. (MTAs normally listen on the well-known port 25.) The information is
exchanged between the MTAs according to the Simple Mail Transfer Protocol (SMTP).
Once the destination MTA has received the message, it delivers it to the destination user
agent, normally by placing it in a queue of incoming messages1. Later, the recipient reads
the message with a user agent such as mail, mailx, elm or MH.
1
Some MTAs use a separate program to perform local delivery. This is called a Message Delivery Agent or MDA.

V3.0
Student Notebook
Uempty Variations on this basic model are possible. In particular, additional intermediate MTAs may
be involved. For example, the message may be passed through one or more relay MTAs,
often because the destination MTA is down or is behind a firewall and cannot be directly
accessed. (We will look at relays in more detail later in this lecture.) Alternatively, the
message may be sent to a mail gateway which translates from the SMTP mail protocol to
another protocol such as UUCP or X.400.
Occasionally the sender's MTA may be unable to connect to the receiver's. In that case, it
normally keeps the outgoing message in the queue, periodically retrying to send it. This is
clearly important since without this feature reliable mail delivery would require that all hosts
with MTAs be running at all times. The Host Requirements RFCs recommend an initial
delay of at least 30 minutes before retrying, and that the sender keep trying for at least four
or five days.

Student Notebook
User Agents
Send and receive email on behalf of one user

Sending using SMTP
Receiving using POP, IMAP or reading directly from
/var/spool/mail/user
Can store e-mail
outgoing
sent
incoming
received
Typical UAs available on Linux:
mail
elm
pine
netscape
evolution
Figure 8-4. User Agents LX073.2
Notes:
User Agents are the computer programs that the users interact with when they want to
send and retrieve email. This User Agent then sends and receives the email on behalf of
that user.
Sending an email message is usually done using the SMTP protocol, but receiving email
can be done in two ways:
• By contacting the MTA over a network connection, using the POP3 or IMAP protocols.
• By reading the /ver/spool/mail/user directory directly. For this to work, the User Agent
has to run locally on the mail server.
User Agents usually have their own storage space where e-mail messages can be stored.
One will usually find at least four different queues (sometimes called "folders") here:
• An outgoing queue, where messages are kept which need to be sent.
• A sent queue, where copies of previously sent messages are being kept.
• An incoming queue, where incoming messages are stored upon reception.

V3.0
Student Notebook
Uempty • A received queue, where read messages are being kept.

Most User Agents allow the creation of custom queues, to sort e-mail anyway the user
wants.
A typical Linux system offers a large number of User Agents by default. This may include
mail, elm, pine and netscape.

Student Notebook
Simple Mail Transfer Protocol (SMTP)
RFC 821 and 822

Used to send mail from a UA to an MTA
Used to send mail from an MTA to another MTA
Figure 8-5. Simple Mail Transfer Protocol (SMTP) LX073.2
Notes:
The Simple Mail Transfer Protocol (SMTP) is the protocol that is used to send e-mail
messages from one system to another. It is used both to send mail from a User Agent to a
Message Transfer Agent, and between MTAs. The base standard is described in RFC 821
and 822, with later RFCs augmenting the standard.2
2
For example, RFCs 2045, 2046, 2047, 2048 and 2049 jointly describe the MIME standard, which is commonly used to encode "difficult"
data (not conforming to RFC 822 requirements), such as attachments and HTML messages.

V3.0
Student Notebook
Uempty
SMTP Example
$ telnet mailgate.abc.com smtp
Trying 192.100.10.7...
Connected to mailgate.abc.com.
Escape character is '^]'.
220 mailgate.abc.com ESMTP Sendmail 8.8.7/8.8.7; Wed, 2 Oct 1998 22:49:03 -0500
HELO mailhub.xyz.com
250 mailgate.abc.com Hello mailhub.xyz.com [192.100.1.1], pleased to meet you
MAIL from: ed@xyz.com
250 ed@xyz.com... Sender is valid.
RCPT TO: fred@abc.com
250 fred@abc.com... Recipient is valid.
DATA
354 Enter mail. End with the . character on a line by itself.
From: Ed Beaver <ed@xyz.com>
To: Fred Flintstone <fred@abc.com>
Hi there, Fred.
.
250 Ok
QUIT
221 mailgate.abc.com: closing connection.
Connection closed by foreign host.
Figure 8-6. SMTP Example LX073.2
Notes:
Because SMTP uses ASCII text, it's easy to see how it works by telneting to port 25 of a
system and directly interacting with its MTA. Here, you would be playing the role of the
client UA. In this example, Ed telnets to the system mailgate.abc.com, which is running
sendmail, and issues the commands necessary to send a message.
The interaction proceeds as follows:
• Ed issues the HELO command to identify his system.
• The server MTA, mailgate.abc.com, responds by indicating that the command has
completed successfully and that it is prepared to start a new mail transaction. The
server MTA also identifies itself to the client.
• Ed issues the MAIL command, indicating the source of the mail. Here he gives the
address from which this message is originating. He could also have given a reverse
path to indicate the MTAs through which this message has passed.
• The server replies with a 250 code to indicate that it is prepared to accept mail from this
source.

Student Notebook
• Ed issues the RCPT command to indicate the address of the recipient. If there were
multiple recipients, the RCPT command would be issued once for each.
• The server MTA replies with a 250 code to indicate it is able to deliver mail to the given
address. Note that if the recipient's mailbox were not on this system, the server MTA
would be acting as a relay or gateway. In this case, the 250 code would imply that the
server MTA is able to forward the message to the ultimate destination.
• Ed next issues the DATA command, indicating he is ready to begin sending the
message itself. The server MTA replies with a 354 code indicating it is ready to accept
the message.
• Ed then enters the email message. The line with a single dot indicates the end of the
message. Note that the text message includes three headers, From:, To: and
Subject:. Normally, it would include several others. The actual message body is
separated from the header by an empty line. Also note that RFC 821 includes a
transparency mechanism that allows a line in the body to be composed of only a single
dot, without confusing it with the message termination. As described in section 4.5.2 of
the RFC, the sender replaces such a line with one containing two dots, thus allowing
the server to distinguish the text line from a termination line. The receiver's MTA
removes the extraneous dot.
• The server MTA now replies with the 250 code, indicating that it will deliver the
message. Ed then issues the QUIT command to terminate the connection. If there were
more messages to be sent to this system, the transaction could have continued with a
new MAIL command.

V3.0
Student Notebook
Uempty
Message Transfer Agent
Receives email from UAs or other MTAs

Stores mail temporarily until it can be forwarded
If final MTA: stores mail until user retrieves it
Can do protocol conversions
Can do header rewriting
Traditional MTA in UNIX: Sendmail
Alternatives: Postfix, Qmail, Exim
Figure 8-7. Message Transfer Agent LX073.2
Notes:
An MTA is a program running on a mail server. It receives email from UAs and other MTAs.
Depending on the destination, it can do a number of things:
• It can try to forward them to another MTA. This is generally done using SMTP, but other
protocols such as UUCP are used occasionally as well. If the other MTA cannot be
reached, the email message is stored temporarily, and the MTA will retry the transfer
later.
• It can store the message locally, if this MTA is the last MTA in the chain. The user can
then retrieve the message locally or over the network using for instance the POP or
IMAP protocols.
Depending on requirements, an MTA can do a number of advanced things too. It can for
instance do header rewriting or perform protocol conversions.
The default MTA in Red Hat is Sendmail, while SuSE uses Postfix by default. Alternatives
are Qmail and Exim.

Student Notebook
Deliver to which MTA?
Dependent on MX records in DNS

An MX record defines the mail exchanger for a domain
# cat /var/named/named.abc.com
.
abc.com. IN MX 10 mailhub.abc.com.
abc.com. IN MX 20 relay1.abc.com.
abc.com. IN MX 30 relay2.abc.com.
.
Sending MTA algorithm:

Try MTA with lowest preference value
If not reachable, try next lowest
Repeat until no mail exchanges left
Try to connect directly to "host"
Sender and all intermediate MTAs use same algorithm
Figure 8-8. Deliver to which MTA? LX073.2
Notes:
An e-mail address is usually of the form username@domainname instead of
username@hostname. This way, sending e-mail is no longer dependent on the availability
of a single host. And, e-mail addresses look more friendly.
This does complicate matters though. Instead of just trying to contact that particular host
which is mentioned in the e-mail address, we will need to figure out who the mail server for
a certain domain is. This is done using the MX records which can be added to the DNS
tables.
In the example above you will see how this is done: In the file which identifies the abc.com
domain, three MX records are added. Each of these MX records describes a mail server or
mail relay for the abc.com domain. The values after the MX identifier identify the
precedence of these mail servers. So in the example above, when someone tries to send
e-mail to someone in the abc.com domain, that message will first be sent to
mailhub.abc.com. If that server is not available, relay1.abc.com will be tried. And if that one
is not available, relay2.abc.com will be tried.3 If none of these servers are available, the
3
A mail server which is identified as being a relay for a domain will never send a message to another relay for that same domain if the
MX value is higher than its own. That way, the message will end at the main MTA for a domain eventually.

V3.0
Student Notebook
Uempty routines will assume that abc.com is not a domain name but a host name and will try to
send the message to the host abc.com directly.
The Internet e-mail standard requires all SMTP implementations to use this algorithm, so
this is an excellent way to make e-mail pretty robust.

Student Notebook
Post Office Protocol
Supports remote access to mailboxes

Useful for intermittently connected system, for example
systems that use dial-up internet access
Used only to receive mail
Figure 8-9. Post Office Protocol LX073.2
Notes:
The Post Office Protocol (POP) allows a user on one system to access his mailbox on a
remote system. For example, the user may have only dial access to the Internet but wishes
to be able to receive mail. SMTP requires that his system be connected to the Internet all or
nearly all the time, so that sending systems can connect to transmit mail. Clearly this is not
practical if the user has only dial access.
To solve this problem, the user's mailbox resides on a remote mail system, which is
constantly connected to the Internet. In-bound mail is sent to that system with SMTP as
usual. When the user wishes to read his mail, he connects to the remote mail system, and
uses the POP protocol to download his mail to his own system. Thus, he downloads his
mail on demand and need not be connected constantly to the Internet.
Note that POP is used only for receiving incoming mail. The user sends outgoing mail with
the SMTP protocol. This works well because he can schedule all his mail transmission for
times when he is connected to the Internet. Normally, he would write his outgoing mail
while not connected. He would then connect, send all his outgoing mail with SMTP and
receive his incoming mail with POP.

V3.0
Student Notebook
Uempty Often, the outgoing mail is not sent directly to the destination, but is sent instead to an
SMTP relay system. The relay system will be in a better position to carry out the retries
required when the destination mail system is temporarily unavailable.
POP is also useful for situations other than dial users with intermittent access. In networks
where people use PCs, it is often not reasonable to expect that every user's system
supports SMTP for in-bound mail. This would require that all systems provide an SMTP
server, something most PC operating systems don't do. Also, many people switch their
PCs off at the end of the day, making it impossible to receive incoming mail at night.
In such cases, a central mail system receives all in-bound mail and saves it in mailboxes.
Users then connect using POP to receive their mail. They would normally relay all their
outgoing mail through this same system using SMTP. Note, however, that there is nothing
in POP that requires users to relay outgoing mail through the system running POP.
POP3 is widely supported. Clients include Eudora, Netscape and Microsoft Exchange.

Student Notebook
POP Example
$ telnet pop.abc.com 110
+OK POP3 pop.abc.com v6.50 server ready
user fred
+OK User name accepted, password please
pass wilma
+OK Maildrop open, 1 messages
list
+OK Mailbox scan listing follows
1 3239
.
retr 1
+OK 3239 octets
Status: U
From: Ed Beaver <ed@xyz.com>
To: Fred Flintstone <fred@abc.com>
Hi there, Fred.
.
dele 1
+OK message deleted
quit
+OK Sayonara
Figure 8-10. POP Example LX073.2
Notes:
This is an example of the POP protocol. Because it uses ASCII commands and responses,
we can easily try out the protocol by using Telnet to connect to port 110 on a POP server,
as shown in the example:
• Ed connects and authenticates/identifies himself.
• He then lists his messages that are held on the server.
• Ed retrieves one of the messages and then deletes it. Note that the server terminates
the message with a line consisting solely of a ".".
• Ed issues the QUIT command to disconnect.
The POP protocol divides the commands a client may issue into two sets. One set consists
of those required in a minimal implementation. The other consists of optional commands.
The required minimal commands are:
• USER name - identifies the user and the mailbox
• PASS string - gives the user's password

V3.0
Student Notebook
Uempty • QUIT - ends a POP session

• STAT - lists mailbox statistics, at least the number of messages and their total size
• LIST [message-number] - lists the messages in the mailbox, including the size of each.
If a message number is given, then it simply lists the size of the message
• RETR message-number - causes the server to transmit the indicated message
• DELE message-number - causes the server to delete the indicated message
• NOOP - no-op; simply causes the server to respond positively
• RSET - resets the server to the initial state
• QUIT - ends the session
The optional commands are:
• APOP name digest - an alternative to USER and PASS for identifying and
authenticating the user. It uses the MD5 message digest algorithm to securely perform
authentication. This is preferable to the USER and PASS commands which involve
transmitting the password in clear text.
• TOP message-number n - requests the server to transmit the first n lines in the
indicated message.
• UIDL [message-number] - causes the server to give a Unique ID Listing for all
messages or for the indicated message. The unique ID is a value that can be used
across time to identify the message. Thus, the client could use this value to identify a
message on a subsequent connection to the server.

Student Notebook
Internet Message Access Protocol
Successor of POP3
Used to manage mail locally and on remote servers
Mail on the server is stored in the users' home directory
May be subject to quota
Figure 8-11. Internet Message Access Protocol LX073.2
Notes:
IMAP is a fairly new standard, and can be seen as the successor to POP. Just as with the
POP standard, it allows a user to retrieve his email from a server. But IMAP also allows a
user to leave messages on the server, create folders on the server, and manage his mail
from there. This makes it possible for a user to connect to the mail server from multiple
clients.
The obvious disadvantage of users keeping and managing their mail on the server is that
far more storage capacity is needed there. This is why ISPs generally do not offer IMAP,
but only POP.
The IMAP protocol is not an ASCII-based protocol like SMTP or POP, so we can’t show you
an example of it.

V3.0
Student Notebook
Uempty
Linux E-Mail Implementation
Evolution,
Sender kmail, ... SMTP Sendmail
/var/spool/
mqueue
Queue
mail client outgoing mail server

mail client SMTP incoming mail server
Postfix
/var/spool/
Evolution,
Receiver kmail, ...
POP/ postfix/*
IMAP
pop3d,
Queue /var/spool/
imapd,
mail/userid
...
Figure 8-12. Linux E-mail Implementation LX073.2
Notes:
Linux implements the e-mail model by using the Sendmail or the Postfix daemon. The
temporary queues are named /var/spool/mqueue or /var/spool/postfix for messages that
still have to be delivered to a remote MTA, and /var/spool/mail/username for mail that is
delivered to the local user. Users will then access this mail file to read their e-mail, either
directly by running their UA on the mail server, or by accessing it through POP or IMAP.
On a large mail server, you will want to make the /var/spool/mail directory a separate
filesystem, so that you can use Linux’ default quota system to limit the amount of mail
stored here. A limit of 10-50 MB is usually okay, since mail, once it is retrieved, is typically
stored elsewhere, either on the users local machine or in its home directory.
User Agents typically store their own data in some sort of own format in the home directory
of the user. Among other things, this makes it hard or impossible to switch user agents
without hassle.

Student Notebook
Sendmail Daemon
Default MTA of Red Hat

Main configuration file /etc/mail/sendmail.cf
Listens on port 25 for SMTP clients
Processes mail queue (/var/spool/mqueue) periodically
Delivers mail for remote delivery using SMTP
Delivers mail for local delivery to system mailboxes
(/var/spool/mail/userid)
Fairly complicated
Can act as mail filter
Can act as mail gateway
Can act as mail relay
Figure 8-13. Sendmail Daemon LX073.2
Notes:
Sendmail is traditionally the heart of the e-mail system. It performs a number of tasks:
First, it receives the e-mail message using the SMTP protocol. A message sent to this MTA
can actually originate from a UA and from another MTA.
Second, it adds the Received: header to the e-mail message, so that the path this
particular message took can be traced.
Then, based on the e-mail address in the message, it decides on the next hop to take.
There are several possibilities here:
• The email address is a local address. In this case, the message will be stored in the
user's mail spool file (/var/spool/mail/user).
• The email address is a remote address. In this case, the message will be sent to
another MTA using either the SMTP protocol or the UUCP protocol. The UUCP protocol
is an older protocol which is hardly ever being used for e-mail, but is available for
backwards compatibility.

V3.0
Student Notebook
Uempty • The email address is an alias for a user in another mail system. In this case, Sendmail
will send the message to a so-called mail gateway, which converts the message in the
appropriate format for that other mail system (for instance, Lotus Notes).
And of course, the message will actually be sent to that next hop. If for some reason that
hop is not reachable, the message will be stored in the local queue and Sendmail will try
sending it again at a later time.

Student Notebook
/etc/mail/sendmail.cf
Difficult syntax
Options always start with O
Macros always start with D
Classes always start with C
Comments always start with #
...and so forth
Can be configured directly or by using m4 macros
Used to initially create sendmail.cf
Some people only edit sendmai.mc, not sendmail.cf
sendmail.mc
m4 sendmail.mc >sendmail.cf
predefined macros in sendmail.cf

/usr/share/sendmail-cf
Figure 8-14. sendmail.cf LX073.2
Notes:
The main configuration file for sendmail is sendmail.cf. This file uses a very arcane
syntax, which makes the configuration of sendmail more difficult than it really should be.
However, the vast majority of the changes a system administrator will make are in the first
section, which is significantly more straightforward than the others.
The people who wrote Sendmail have recognized that the sendmail.cf file is becoming too
complicated, and have written a large number of m4 macros which allow you to create a
(complicated) sendmail.cf file based on the contents of a (far simpler) sendmail.mc file and
a number of default macros, stored in /usr/share/sendmail-cf.
There is some discussion on how this mechanism should be used: Some people argue that
this mechanism should only be used to create an initial sendmail.cf file, and that all
subsequent changes should be made directly in sendmail.cf. Others argue that changes
should only be made to sendmail.mc, and that sendmail.cf should not be manually edited,
ever. In this course, we will use the first approach: We will use the default sendmail.cf file
(which was created from sendmail.mc by our distributor) and make manual changes to this
file.

V3.0
Student Notebook
Uempty The definitions in sendmail.cf are normally grouped into the following sections:
• General options and definitions
This section gives global information and options for how sendmail carries out its work.
We will look at the most significant parts of this section in the next several charts.
• Message precedences
These define the precedences or priorities that control the order in which sendmail
delivers mail.
• Trusted users
This defines the set of users allowed to override the sender address on mail they send.
• Mail header definitions
These define the formats of headers that sendmail places in messages.
• Address rewriting rules
These control the way that sendmail rewrites addresses in incoming and outgoing
messages.
• Mailer definitions
These define the mailers that sendmail calls to carry out message delivery.
In most cases, you will modify only the first section. Defaults are provided for all sections,
and they generally work the way you will want them to. There are, however, some common
configuration tasks that require changing the first section. Thus, in the following charts, we
will focus mainly on the first section.
The configuration file uses three different types of configuration items:
• Options control particular aspects of sendmail's operation. For example, the option A
or Aliasfile determines the file in which sendmail expects aliases to be defined. The
option L or LogLevel controls the logging level for sendmail. Options are usually
defined in sendmail.cf in a line of the form:
O option=value
... or ...
Oovalue
While most options have values, there are some that do not. For these, the option is
merely set or not.
It is also possible to define options on the sendmail command line, using the -o flag.
Options defined on the command line override any defined in sendmail.cf. However,
when certain options are defined on the command line, they cause sendmail to
relinquish its setuid root permissions, so it is generally a good idea to define the options
in sendmail.cf.

Student Notebook
• Macro definitions are much like setting variables in a programming languages. Defining
a macro sets it to a particular value. The value of the macro can then be accessed
elsewhere in sendmail.cf and also by sendmail itself. In sendmail.cf, a macro's value
can be accessed using the form $x, where x is the name of the macro.
For example, the value of the macro S is the name of a smart relay host to which all
messages going outside the local host are to be forwarded. When relaying is desired,
this macro is defined in the first section of sendmail.cf. Later in the file (in the address
rewriting rules), this macro's value is accessed to set up delivery to the relay host.
Some macros have default values assigned by sendmail. For example, the macro w is
assigned the local host name as its value. This can be overridden in sendmail.cf by
redefining w.
• Classes are like macros, except they contain sets of values. For example, the class w
contains the set of names by which the local host is known for mail purposes. If class w
is set as shown in the chart, then sendmail will locally deliver mail for any of
sys1.xyz.com, mailgate.xyz.com or mailgate.xyz.com.
As with macros, the values of classes are accessed elsewhere in sendmail.cf and by
sendmail itself.
• Comments always start with #.

V3.0
Student Notebook
Uempty
Important sendmail.cf Configuration Options
What is my fully qualified domain name?

Djmailhub.abc.com
What is my (outgoing) domainname to masquerade as?
DMabc.com
For which domains do I accept e-mail
Cwxyz.com mail.xyz.com sys1.xyz.com
Is there a "smart" MTA to which I can send all my
non-local mail?
DSfirewall.xyz.com
For which domains do I relay?
Kaccess hash -o /etc/mail/access.db
What interfaces do I listen to?
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1,Name=MTA
Figure 8-15. Important Configuration Options LX073.2
Notes:
The following options are the most important options for our purposes:
• The j macro defines our own fully qualified domain name. It is only necessary to set this
name if for some reason sendmail cannot read the hostname of this system directly, or
is not allowed to. It is very useful if you have a virtual hosting scenario, where your
system can actually use multiple hostnames.
• The M macro defines what our hostname (or domainname) is on outgoing messages, in
case it was not specified by the User Agent.
• The w class defines for which domains and hostnames we will accept e-mail for local
delivery. This class should include at least the name of the domain and the hostname of
the mail server, but you might want to include more hostnames. If you need to include a
whole lot of hostnames and domainnames here, you can also put these in the file
/etc/sendmail.cw.
• The S macro defines the name of a "smart" MTA to send all our non-local e-mail to. This
is generally being used for MTAs behind a firewall, who do not have the ability to send

Student Notebook
e-mail outside directly. The firewall will then incorporate a relay MTA, to which we send
all our non-local e-mail.
• The (keyed) access database contains a list of domains for which we are willing to
relay mail to others. Relaying by default is disabled for security reasons. In this file you
should include at least the domain(s) of all your own mail clients so that they are able to
send mail to other destinations.
There are more files in the Sendmail configuration that are keyed databases. A keyed
database is essentially a copy of the corresponding flat file, for which an index is
created. This allows far faster lookups of items in this table, which is especially useful if
the file contains thousands of entries.
In general, all keyed databases within the Sendmail configuration are stored in the
same directory as the original flat textfile. When you cd into this directory, all you need
to do is type make to create these databases from their text files. There is never a need
to edit the hashed database files yourself.
• The DaemonPortOptions option defines the ports we are listening to. By default,
Sendmail only listens to the localhost port (the loopback interface, or 127.0.0.1). This is
done for security reasons: Almost every Linux system needs to have an MTA running
(for instance, for crond output), but almost no Linux system needs that MTA to be
reachable from the outside world.

V3.0
Student Notebook
Uempty
Postfix Daemon
Alternative to Sendmail
Default MTA in SuSE
Configuration files in /etc/postfix
Main configuration file /etc/postfix/main.cf
Various queues in /var/spool/postfix
Different queues are used by the different postfix
components to communicate with each other
Delivers mail for remote delivery using SMTP
Delivers mail for local delivery to system mailboxes
(/var/spool/mail/userid)
Figure 8-16. Postfix Daemon LX073.2
Notes:
An alternative MTA which is commonly found in Linux is Postfix. It was developed by
Wietse Venema from the Netherlands while at assignment at IBM’s T.J. Watson Research
Center. IBM has decided to release Postfix under the IBM Public License and not to retain
any influence over the development process.
Postfix has a far more modular structure than Sendmail. Almost all programs that make up
Postfix perform a single task only, and do not require root privileges to perform that task.
Communication between the different modules is by way of leaving files in directories, and
all modules employ a system of mutual distrust, thus checking each others work and
syntax. This is an inherently safer design than that of Sendmail.
All configuration files are in /etc/postfix. The main configuration file is main.cf, which will be
discussed in the next visual. But just like sendmail, some things are configured in separate
files. An example is the aliases file, /etc/postfix/aliases. The syntax of this file is compatible
with Sendmail’s aliases file.
As said before, Postfix modules communicate with each other by leaving files in directories.
These directories can all be found under /var/spool/postfix.

Student Notebook
Just as with Sendmail, Postfix finally delivers the e-mail to the users mailbox in
/var/spool/mail/username.

V3.0
Student Notebook
Uempty
/etc/postfix/main.cf
Main postfix configuration file

Well documented
Important configuration options:
myhostname = my hostname
mydomain = my domain
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, $mydomain
Figure 8-17. /etc/postfix/main.cf LX073.2
Notes:
The main Postfix configuration file is /etc/postfix/main.cf. It is a large file, mainly due to the
large amount of comments that are included in this file. As a result of these comments,
editing the file is fairly easy.
There are only a few configuration options that need to be set for Postfix to work correctly:
myhostname Should be set to the systems hostname or DNS CNAME under
which this system handles mail.
mydomain Should be set to the systems domain name.
myorigin Is used for header rewriting so that all mail from a certain
number of clients actually seems to originate from one domain.
As an example, consider a user who composes an email on
sys1.dc.ibm.com with the mail program. The From-field of the
email will then look like username@sys1.dc.ibm.com. With the
myorigin option set, Postfix will rewrite this to
username@dc.ibm.com.

Student Notebook
inet_interfaces This option lists the interfaces which Postfix should use. By
default this is set to localhost only, thus preventing
communication with other parties. You can specify individual
interfaces here, or all.
my_destination This option lists all domains for which Postfix is the endpoint in
the chain. Mail with a destination listed in this list is retained
locally, while mail with another destination is forwarded to other
MTAs.

V3.0
Student Notebook
Uempty
Aliases
Define alternative names for mail addresses

$ cat /etc/aliases
Postmaster: root
fred: fred@xyz.com
penpals: fred, joe, ed@bighost.abc.com
Used globally by sendmail and postfix

Apply to all messages passed to mailers (for example,
incoming, outgoing)
Must be activated with newaliases command
Can forward incoming messages to another system:
harry: harry@newhost.xyz.com
Can cause commands to run:

joe-fax: | /usr/local/bin/fax-it
Figure 8-18. Aliases LX073.2
Notes:
Both Sendmail and Postfix provides the ability to set up aliases for use in mail addresses.
For example, in this chart, fred is an alias for the address fred@xyz.com. Thus, fred can
be used as an address in mail sent from this host and it will be transformed to
fred@xyz.com. Aliases may also point to a list of addresses, as shown in the chart for the
alias penpals, which will cause messages to be sent to all addresses corresponding to the
alias.
Aliases have global effect within the host. Per-user aliases are best handled by user
interface programs.
Aliases are normally defined in the file /etc/aliases. Before sendmail or postfix can use
them, they must be activated by the newaliases command. This translates them into a
database format that sendmail or postfix can use directly4.
Note that all hosts are required by RFC 1123 (Host Requirements) to have an address
Postmaster. This is intended for receiving messages relating to the mail system on the
4
The reason for converting the aliases file (and a number of other files) into a database format is that a database supports an index,
which makes large lookups in a file much faster.

Student Notebook
host. As shown in the chart, this would normally be an alias pointing to the mailbox of the
system administrator responsible for mail.
Because aliases apply to incoming mail, and because they can point to users on other
systems, it is possible to use aliases as a way to forward mail. For example, suppose that
user harry has moved to the system newhost.xyz.com. Then the alias shown in this visual
will cause all mail coming to his user ID on the local system to be forwarded to his new
system.
Aliases can also cause commands to run. In the example shown in this chart, mail sent to
the joe-fax user ID on this system will cause the fax-it command to run.

V3.0
Student Notebook
Uempty
User-Defined Forwarding
.forward file in user's home directory defines forwarding

list:
[fred@oldhost.abc.com]$ cat .forward
fred@newhost.xyz.com
joe
| "cat >>~fred/forwarded-mail"
Applies only to mail for particular user
Figure 8-19. User-Defined Forwarding LX073.2
Notes:
Another way to implement mail forwarding is to use the .forward files that users may place
in their home directories. Such a file causes mail sent to the given user to be sent instead
to the listed addresses. The main advantage of these files is that they allow users to define
mail forwarding for themselves, since users would normally not have access to the
/etc/aliases file.
Command aliases can also be used in .forward files.
In the example shown in this chart, if user fred put this .forward file in his home directory,
then incoming mail for him would be processed as follows:
• A copy would be sent to fred@newhost.xyz.com
• A copy would be sent to joe on the local system.
• A copy would be appended to the file forwarded-mail in fred's home directory.
Note that no copy would be sent to fred, unless he listed his user ID in the .forward file.

Student Notebook
Virtual Mail Domains
A "virtual domain" is a mail domain (@mycompany.com)

which is forwarded to another mail address
MX records for virtual domain should point to this server!
Implemented via the /etc/mail/virtusertable (Sendmail) or
/etc/postfix/virtual (Postfix) file:
samiam@bovine.net colin
sunny@bovine.net darkhorse@mystery.net
@dairy.org mail@jhm.org
@artist.org $1@red.firefly.com
For reverse-mapping of outbound mail, use
/etc/mail/genericstable (Sendmail) or
/etc/postfix/sender_canonical (Postfix)
colin samiam@bovine.net
After modification, run make (Sendmail) or postmap
(Posfix)
Figure 8-20. Virtual Mail Domains LX073.2
Notes:
A virtual domain is a DNS domain which does not have a dedicated mail server. Instead,
mail intended for this domain is received by a “virtual mail domain server”, and forwarded to
a regular mail account.
In Sendmail, this mechanism is implemented via the /etc/mail/virtusertable file, while
Postfix uses the /etc/postfix/virtual file. The syntax of both files is identical.
There are basically three different types of entries here:
• The first type of entry is where an individual mail address in a virtual domain is
forwarded to another mail address. In the example above, all mail for
samiam@bovine.net is forwarded to colin on the local system, and mail for
sunny@bovine.net is forwarded to darkhorse@mystery.net.
• The second type is where all mail for a domain is forwarded to a single mail address in
another domain. In the example above, all mail for the dairy.org domain is
automatically forwarded to mail@jhm.org, regardless of the username.

V3.0
Student Notebook
Uempty • The third type is where all mail for a user in a domain is forwarded to the same
username, but in another domain. That’s the last line in the example above. In this
case, mail for somebody@artist.org is forwarded to somebody@red.firefly.com, and
so forth.
This last type is really useful for companies who changed their company name (and
thus, their domain name).
Obviously, for this to work, you need to make sure that the MX records for your virtual
domains point to the correct mailserver!
If you want to apply reverse mapping for outgoing mail as well, you need to configure the
/etc/mail/genericstable (Sendmail) or /etc/postfix/sender_canonical (Postfix) too. This file is
basically the same as the virtusertable, but with the columns swapped, and all irrelevant
entries taken out. In the example above, all entries in the virtusertable which are effectively
forwarded to other mail servers (the last three entries) do not need to appear in the
genericstable, for the simple reason that mail from these addresses never passes through
our mail server.

Student Notebook
Implementing POP3 or IMAP
Install daemons
Red Hat: Both ipop3 and imap contained in imap RPM
SuSE: qpopper RPM and imap RPM
Both run out of [x]inetd
Should be enabled
Both use regular Linux username/passwords
May need to check /etc/pam.d setup
POP does not store any data on the server by design,
only empties mailbox
IMAP stores data in the users home directory
Subject to quota, if configured
Figure 8-21. Implementing POP3 or IMAP LX073.2
Notes:
Implementing POP3 and/or IMAP is really easy. Most distributions have an rpm file
available which installs them for you. On a Red Hat system, both the POP and IMAP
daemons are contained in the imap RPM. On a SuSE system, you will need the qpopper
RPM for POP, and the imap RPM for IMAP.
Both pop and imap need no configuration to speak of, since they use regular /etc/passwd
authentication (through PAM, if possible), and use the home directory of the user to store
any custom folders that the user may want to make (IMAP only).
Both POP and IMAP are generally run out of the [x]inetd daemon, so you might need to
enable them in /etc/inetd.conf or /etc/xinetd.d/*.

V3.0
Student Notebook
Uempty
Protecting POP and IMAP Traffic
Both POP3 and IMAP send passwords as plain text

pop3s and imaps combine the regular pop3 and imap
protocols with SSL (Secure Sockets Layer) encryption
Requires OpenSSL library
To implement in Red Hat:
Obtain official certificate via certificate authority, or use
preinstalled self-signed certificate
Enable pop3s and imaps service in xinetd
To implement in SuSE:
Install sslwrap RPM
Obtain official certificate via certificate authority, or
create self-signed certificate
Configure pop3s or imaps service using sslwrap
Figure 8-22. Protecting POP and IMAP Traffic LX073.2
Notes:
POP and IMAP traffic are by default sent via a cleartext channel. That means that
everybody with a sniffer can see your password and all email in transit. Obviously, that is
something we will want to prevent.
A generic technique, SSL (Secure Sockets Layer) has been developed by Netscape to
protect arbitrary data in transit. This was originally used for the HTTP protocol, but can
basically work on any sockets-based (TCP) connection5.
The SSL protocol uses a server-side digital certificate, which (if issues by a certification
authority) positively identifies the server. In addition to this, the certificate also contains a
public key which is subsequently used to encrypt all communications between the client
and the server. The SSL protocol also allows for client-side digital certificates to be used,
but this capability is not used often.
In order to add SSL capabilities to an existing protocol, one of two things need to be done:
• Recompile the daemon with SSL support
• Use a wrapper program which implements SSL
5
SSL is now standardized under the name TLS (Transport Layer Security). However, everybody still uses the name SSL.

Student Notebook
In both cases, you are going to need an open-source cryptographic library called OpenSSL
Red Hat has chosen the first option, and has recompiled the pop3d and imapd daemons
with SSL support. SuSE has chosen the second approach, and supplies the sslwrap
daemon to implement SSL on arbitrary protocols.
To implement POP3S and IMAPS on a Red Hat system, the procedure is really simple:
1. Decide on whether you are going to use an official certificate issued by a certificate
authority (e.g. Verisign), or are going to use the self-signed certificate that is created by
a Red Hat installation by default.
If you want an official, CA-issued certificate, read the documentation that comes with
the openssl RPM. For a self-signed certificate, you don’t have to do a thing, as Red Hat
sets this up by default.
2. Enable the pop3s and imaps service in xinetd, and then restart xinetd.
For a SuSE system, the procedure is slightly more difficult.
1. Install the sslwrap RPM.
2. Again, decide on whether you are going to use a CA-issued certificate or a self-signed
certificate. Information on CA-issued certificates can again be found in the openssl
RPM documentation. For a self-signed certificate, run the following command in the
directory /etc/ssl/certs:
openssl req -newkey rsa:1024 -keyout sslwrap.pem -nodes -x509 -days 365 \
-out sslwrap.pem
This creates a file /etc/ssl/certs/sslwrap.pem, which contains a self-signed certificate
and the corresponding public and private keys.
3. Add services for xinetd with the correct service names (look in /etc/services for the
name of the service), which invoke sslwrap and then connect to the original,
unencrypted service.
As an example, the xinetd service for pop3s is:
service pop3s
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/sslwrap
server_args = -cert /etc/ssl/certs/sslwrap.pem -port 110
flags = IPv4
}
When done, restart xinetd.
You should now be able to configure your User Agent to use SSL encryption.

V3.0
Student Notebook
Uempty
Mailing Lists
Mailing List: Group of mail users interested in the same

subject.
By sending mail to a special mail address, it reaches all
A "moderator" manages the list: approves subscriptions
and posts, if required
Several programs available for Linux implementing this:
Majordomo, Majordomo2
Smartmail
Mailman
Most mailing list programs can be managed by e-mail
commands
Differences between programs:
Management interface (mail/web)
Additional functions such as archiving, interface with
news systems and so forth
Figure 8-23. Mailing Lists LX073.2
Notes:
A “mailing list” is a group of mail users interested in the same subject. When they send their
mail about that subject to a specific mail address, it is forwarded to all other members of the
group. Typically, the owner (sometimes called the “moderator”) manages the mailing list: he
or she will decide on whether new subscribers are allowed to join, and he or she will
sometimes decide whether individual posts are allowed or not.
Several programs exist for Linux that will implement this functionality:
• Majordomo and Majordomo2 (Majordomo is the current stable release, and
Majordomo2 is in beta test)
• Smartmail
• Mailman
Installation and configuration of these programs is relatively easy:
1. Install the program itself, either from an RPM file or from source, using an install script.

Student Notebook
2. Configure the program so that it knows the e-mail addresses to use and the identity of
the server manager.
3. Add related aliases to the Sendmail aliases file, /etc/aliases or /etc/mail/aliases, or add
a listmanager-specific aliases file to Sendmail using the following OA line to
sendmail.cf:
OA/path/to/listmanager/alias/file
4. Configure the web interface, if applicable. For example, mailman has its own
web-based configuration interface, while Majordomo requires MajorCool to provide a
web interface.
5. Now start adding and configuring mailing lists, either by using the mail interface (e-mail
sent to the list server containing the commands to be executed) or the web interface, if
provided.
6. Test and resolve any problems. Don’t forget to review the logfiles of your mailing list
program to identify the problems!

V3.0
Student Notebook
Uempty
Checkpoint
1. A program that transmits e-mail from one system to another is
called a:
a. User agent
b. Message transfer agent
c. SMTP agent
d. SNMP agent
e. Sendmail transmission agent
2. The command that starts an SMTP transaction and identifies
the message sender is:
a. HELO
b. EHLO
c. DATA
d. MAIL
e. RCPT
3. T/F. Each hop between relay MTAs involves a separate
SMTP session.
Notes:
1.
2.
3.

Student Notebook
Unit Summary
The Linux e-mail system contains of User Agents and

MTAs
The User Agent can be chosen by the users
themselves
The MTA is Sendmail or Postfix, combined with POP
and/or IMAP daemons for remote users
User Agents interact with users to compose, send,
receive and manage e-mail
An MTA is the core of the e-mail system
receives messages from UAs and other MTAs
filters e-mail messages
expands aliases
carries out delivery
Notes:

V3.0
Student Notebook
Uempty Unit 9. Dynamic Host Configuration Protocol

This unit covers the Dynamic Host Configuration Protocol (DHCP),
which allows you to configure an IP host dynamically from a server.

• Describe the purpose and operation of DHCP
• Configure DHCP clients
• Configure DHCP servers

Accountability:
© Copyright IBM Corp. 1999, 2003 Unit 9. Dynamic Host Configuration Protocol 9-1
Student Notebook
Objectives

Describe the purpose and operation of DHCP
Configure DHCP clients
Configure DHCP servers
Notes:

V3.0
Student Notebook
Uempty
Host Configuration
Static
IP configuration stored on local storage medium (disk,
EEPROM, ...)
Requires one IP address for every machine
Requires local configuration on each system
Typically used for servers
Dynamic
IP configuration assigned by server
Requires one IP address for every active machine only
Does not require any local configuration
Typically used for clients
Figure 9-2. Host Configuration LX073.2
Notes:
Every host in an IP network needs to be configured with several parameters, including the
IP address, the subnetmask, the default router, the IP addresses of DNS servers, and so
forth. There are basically two ways of supplying these parameters to the host.
When a site uses static configuration, all parameters are configured on the local system
and stored on some sort of local medium. In most cases this will be the local hard disk, but
for instance EEPROMS can also be used.1
With static configuration, every host on a network needs its own IP address, even when the
system is off, or not connected to the network at all. Think for instance about the situation
where your company has a thousand mobile workers, each with its own laptop, who can
hook up to any network in any of your ten buildings throughout the country. Since you will
never know when someone will be logged in where, you need to reserve 10.000 IP
addresses, one thousand for each network, even if a network has only ten connections
available. This is a tremendous waste of IP addresses, not considering the user who will
need to do some local configuration every time he connects to another network.
1
An example of this is a diskless X-station.
Student Notebook
When a site uses dynamic addressing, no configuration is stored locally. Instead, when the
system boots up, it requests the local configuration from a server. And when the system
shuts down, it also notifies the server that the configuration is no longer needed and can be
reused. This limits the number of IP addresses that need to be reserved, since only the
systems that are actually in use on a network need an IP address for this network. And it
saves the user from doing a lot of local configuration.
The disadvantage of dynamic addressing is that you cannot predict what IP address a
certain host will have. It is therefore not a good idea to give servers a dynamic IP address
(although Dynamic DNS, covered later, might help here). Usually, a mixed approach is
taken, with servers and various other important systems configured statically, and client
systems configured dynamically.

V3.0
Student Notebook
Uempty
Dynamic Host Configuration Protocols
Reverse ARP Protocol

RFC 903
IP address only
IP address statically linked to MAC address
Link level protocol - not routable
Bootp Protocol
RFC 951
Every conceivable IP option (address, subnetmask,
DNS, routers, ...)
IP address statically linked to MAC address
Uses UDP - routable
DHCP Protocol
RFC 2131 and 2132
Downwards compatible with Bootp
IP address dynamically assigned with lease time
Figure 9-3. Dynamic Host Configuration Protocols LX073.2
Notes:
Throughout the history of the TCP/IP protocol, people have come up with ways to do
dynamic configuration.
The first protocol to be used was the Reverse ARP (RARP) protocol. As the name implies,
it is the reverse implementation of the ARP protocol: The ARP protocol was used to find the
MAC address of someone else on the local network, given his IP address, and the RARP
protocol was used to find your own IP address, given your own MAC address.
RARP uses the same packet format as ARP, and has the same limitations:
• It is a link level protocol which runs directly on top of the LAN (ethernet or token ring)
protocol. Because of this, it is not routable, which requires you to have a RARP server
on each and every network.
• It only gives the client its IP address, not the subnetmask, the default router or any other
configuration item.
Student Notebook
• Since the packet format does not allow inclusion of a lease time (which will be
discussed later), it is not possible to assign IP addresses for a limited amount of time
only, and reuse that IP address later for another host.
The second protocol to be used was the Bootp protocol. This protocol aimed to be a better
implementation of RARP, and has the following characteristics:
• It is an application level protocol, which runs on top of UDP. This makes it easier to write
server and client applications and ensures that the packets are routable. You therefore
do not have to configure a bootp server on each and every network.
• It uses a very flexible packet format which allows you to configure the client with every
conceivable IP configuration item, and also has a large number of vendor extensions
defined, which allows vendors of certain hardware to configure that hardware with
special configuration options. An example of this is Intel's PXE boot scheme.
Bootp does not allow the inclusion of a lease time, so reusing IP addresses is not possible.
The most recent protocol to be used is the Dynamic Host Configuration Protocol
(DHCP). It is downwards compatible with Bootp, so Bootp clients can boot of a DHCP
server and vice versa. But it extends Bootp to include a lease time, which ensures that after
a certain amount of time the IP address is free to be assigned to another system.

V3.0
Student Notebook
Uempty
Leasing an IP Address
In DHCP negotiation, the client agrees on a lease time

with the server
Before the lease time is over, the client has to:
Abandon the lease
Renew the lease
All lease times are expressed as offset from now in
seconds
Prevents against problems when clocks are out of sync
Figure 9-4. Leasing an IP Address LX073.2
Notes:
When the client boots up, it starts a brief negotiation with the server. As part of this
negotiation, a lease time is agreed. This is the period of time in which the client may use
the IP address and other configuration items that were assigned.
Before the agreed lease time is over, the client needs to do one of two things:
• It may abandon the lease, essentially telling the server that it no longer needs the IP
address, and that the server can reuse it immediately.
• It may renew the lease. This requires a new, even shorter negotiation phase with the
server to extend the lease time. In all but a few cases, the server will renew a lease
without a problem.2
In all DHCP packets, the lease time and related timings are always expressed in seconds,
as an offset from the current time. This prevents against problems when clocks on different
systems are not synchronized. It is however a good idea to synchronize the clocks as well
as possible, because it makes debugging DHCP problems easier. Synchronizing clocks will
be discussed in the NTP unit.
2 ISPs who offer cable modem or ADSL service sometimes force clients to abandon the lease and acquire a new lease for another IP
address. This prevents people from having a permanent, static IP addresses and thus from building servers.
Student Notebook
DHCP Client-Server Interactions
DHCP Relay DHCP Server

1. DHCPDISCOVER
2. DHCPOFFERs
3. DHCPREQUEST
4. DHCPACK
DHCP Client
DHCP Server
Figure 9-5. DHCP Client-Server Interactions LX073.2
Notes:
The visual shows the exchange of packets that enable a client to obtain a lease on an IP
address.
1. The client broadcasts a DHCPDISCOVER message on its local subnet. This message
is received by all DHCP servers and DHCP relays on the network.
A DHCP relay will relay the message as a unicast message to one or more DHCP
servers. DHCP relay code is typically included in a routers, saving you from having to
put a DHCP server or other special system on each network.
2. All servers check their local configuration to see if they have any IP addresses for that
network that may be used by this client. Each server that wants to offer a lease does
this by sending a DHCPOFFER containing the IP address, other configuration
parameters and the maximum lease time for this IP address.
3. The client receives all offers and selects one (typically, but not necessarily, the one with
the longest maximum lease time), and sends a DHCPREQUEST to that server to
confirm the lease.

V3.0
Student Notebook
Uempty 4. The server receives the DHCPREQUEST, stores the client's configuration details and
sends a DHCPACK message to the client.
Servers don't commit the IP address for the client until they receive the DHCPREQUEST
packet. It may therefore happen that a server sends multiple DHCPOFFERs to multiple
clients with the same IP address. The first client that actually claims the IP address (with a
DHCPREQUEST) is confirmed with the DHCPACK, and other clients are reneged with a
DHCPNACK message. The client may therefore only use an IP address after it has
received the DHCPACK.
Student Notebook
DHCP Renewal
T1(0.5* Client Server

duration of Renewing State
lease)
DHCPREQUEST [commits
(unicast) configuration]
DHCPACK or
[ignores
request]
T2
(0.875* [Rebinding State]
duration of [commits
lease) DHCPREQUEST
configuration]
(broadcast) or
Lease [ignores
[Init State]
Expires request]
DHCPDISCOVER
Graceful shutdown
Discards lease
DHCPRELEASE
Figure 9-6. DHCP Renewal LX073.2
Notes:
This diagram illustrates the renewal of a lease.
1. After half the lease period (usually called T1) the client contacts the server with a
unicast DHCPREQUEST, requesting a renewal of the lease. If the server is still
available and willing, it sends a DHCPACK back to the client, confirming the renewal of
the lease. The timers will now be reset and the lease period countdown starts again.
2. If the server does not react to the unicast DHCPREQUEST, the client waits until T2,
which is about 0.875th of the lease period. It then does a broadcast DHCPREQUEST.
This broadcast still contains the ID of the DHCP server, but this broadcast might be
picked up by a DHCP relay agent, so that it reaches the server even if the server has
been placed on another subnet.
3. If the client still has no confirmation from the server by the time the lease expires, it will
start a DHCPDISCOVER sequence again to get another IP address from another
server. Plus, since the lease has expired, it will send a DHCPRELEASE to the previous
server. But this DHCPRELEASE will probably get lost since the server has not been
responding anyway.

V3.0
Student Notebook
Uempty
Selected DHCP Options
IP address
Subnet mask
Time offset
Router
Time server
Domain name server
LPR server
Hostname
Domain name
IP forwarding enable/disable
Static routes
Figure 9-7. Selected DHCP Options LX073.2
Notes:
This chart lists some of the more interesting options defined in RFC 2132 that a DHCP
server can send to a client. The last option, static routes, allows the server to provide a list
of static routes that the client will install into its IP routing table.
For a more thorough explanation of these options, view the dhcp-options manual page.
Student Notebook
Linux DHCP Implementation
Linux as a DHCP client

dhcpcd
pump
dhclient
Linux as a DHCP relay
ISC dhcprelay
Linux as a DHCP server
ISC dhcpd
Figure 9-8. Linux DHCP Implementation LX073.2
Notes:
Linux can function as a DHCP client, a DHCP relay and as a server. Most distributions
implement all three functions by using the software from the Internet Software Consortium
(http://www.isc.org). This software is pretty good and well supported. The only problem is
that their dhcpcd client daemon does not work on Token Ring. Some distributions therefore
use pump, which was written by Red Hat, which will work with Token Ring.
DHCP relays under Linux are rare (most people configure a DHCP relay on their hardware
router), so we will not discuss them in this unit. If you need more information about them,
consult the manual pages.

V3.0
Student Notebook
Uempty
Linux DHCP Clients
dhcpcd
Basic syntax: dhcpcd [interface]
Results stored in /var/lib/dhcpcd directory
Does not work on Token Ring networks
Red Hat pump
Basic syntax: pump [-i interface]
Configuration file /etc/pump.conf
Works with Token Ring networks too
ISC dhclient
Basic syntax: dhclient [interface]
Configuration file /etc/dhclient.conf
Results stored in /var/lib/dhcp/dhclient.leases
The client daemon is normally configured through the
network configuration tools (redhat-config-network, yast)
and started automatically
Figure 9-9. Linux DHCP Clients LX073.2
Notes:
Most Linux distributions use any of the two clients listed in the visual. In fact, some
distributions actually offer both. Both clients offer virtually the same functionality: they go
through the initial DHCP lease acquisition phase and when this has succeeded, fork
themselves into the background. They will then sleep and renew the lease when needed.
The ISC dhcpcd client has a useful feature in that it stores any and all parameters it
receives in the /etc/dhcpcd directory. Other programs can then access this directory and
retrieve the data. This is especially useful if you use any custom or vendor specific fields.
The Red Hat pump client does not store data in a file, but has the advantage of working on
token ring networks, which the dhcpcd client does not.
On most distributions, the client daemon (whether that is dhcpcd or pump depends on the
distribution) is automatically configured and started when an interface is configured to use
DHCP through the configuration tools for that distribution (netconf, yast, ...).
Student Notebook
Linux DHCP Server
Most distributions use the DHCP server from the Internet

Software Consortium (http://www.isc.org)
Daemon program: dhcpd
Configuration file: /etc/dhcpd.conf
State file: dhcpd.leases
Backup: dhcpd.leases~
Server will not start if the state file is not present
The server is started as any other service
rcdhcpd start
service dhcpd start
Figure 9-10. Linux DHCP Server LX073.2
Notes:
Most distributions use the ISC’s DHCP server. Just like any other service under Linux, it
consists of a daemon program (dhcpd) and a configuration file (/etc/dhcpd.conf) and is
started like any other service, with its /etc/rc.d or /etc/rc.d/init.d script or a special service
script.
One thing that is different is that the DHCP server keeps a state file. This file contains all
the leases that are currently in use by clients, and is used to prevent the server from
handing out duplicate IP addresses after a reboot of the DHCP server. This file is really
important for the DHCP server. That's why two safeguards exist that you should know
about:
• The first safeguard against a corrupted file is that the DHCP server automatically
creates a backup file of this state file, called dhcpd.leases. The DHCP server will never
modify both files at the same time, and will issue a sync after closing the file. This
ensures that one of both files will always be in a consistent state.
• The second safeguard is that the dhcpd server will flatly refuse to start without one of
these files being present, even if this is the first time the server is started on this system.

V3.0
Student Notebook
Uempty So before you start the server the first time, make sure you create an empty
dhcpd.leases file with the command touch dhcpd.leases
And as a further annoyance, the location of the state file in the filesystem has been subject
to a lot of debate. The result is that the location will not only vary from distribution to
distribution, but also from distribution version to distribution version. As an example, the
location on Red Hat has been one of:
• /etc
• /var/state/dhcpd
• /var/lib/dhcp
So your mileage may vary here. The best way of determining the location of the state file is
by using the command rpm -ql ‘which dhcpd‘.
Student Notebook
Sample /etc/dhcpd.conf File

# cat /etc/dhcpd.conf
option domain-name "example-company.com";
option domain-name-servers 10.1.1.3, 10.1.1.4;
max-lease-time 3600;
default-lease-time 600;
ddns-update-style none;
subnet 10.1.1.0 netmask 255.255.255.0 {

option routers 10.1.1.1;
option subnet-mask 255.255.255.0;
range 10.1.1.10 10.1.1.50;
host ns1 {
hardware ethernet 00:04:ac:3f:45:9f;
fixed-address 10.1.1.3;
}
}
subnet 10.1.2.0 netmask 255.255.255.0 {

}
Figure 9-11. Sample /etc/dhcpd.conf File LX073.2
Notes:
The Linux DHCP configuration file defines configuration information for the DHCP server
program, dhcpd.
The configuration file consists of a number of global options, followed by a series of subnet
definitions who each may have a number of options as well. The options used within a
subnet definition can be the same as the global options, in which case the option within the
definition overrides the global option.
The DHCP server needs a subnet statement for every network it is attached to, even if it
does not need to provide leases for that particular network.
More complex configurations are possible, for instance when one physical adapter serves
multiple logical networks (using IP aliases), or if multiple physical adapters are connected
to the same physical network. For this, see the dhcpd.conf manual page.
The effect of the configuration file in the visual is:
• All clients will be given the domain name example-company.com as their domain name.
• All clients will be given 10.1.1.3 and 10.1.1.4 as their DNS servers.

V3.0
Student Notebook
Uempty • All clients will be given 255.255.255.0 as their subnet mask.

• Addresses will be assigned to clients with a maximum lease period of 3600 seconds
(one hour) and a default lease period of 600 seconds (10 minutes). This is not a
problem in testing situations, but will put unnecessary strain on a production network.
For those networks, leasetimes of one day or more will be just about right.
• The DHCP server will not send DDNS updates to the server.
• All clients in subnet 10.1.1.0 will be given an address in the range 10.1.1.10 to
10.1.1.50, and 10.1.1.1 as their router.
• One special client exists, called ns1, which gets a fixed IP address 10.1.1.3, based on
its MAC address.
• This DHCP server will not serve any clients in the 10.1.2.0 network.
There are more options possible in the /etc/dhcpd.conf file. For an overview and
explanation, refer to the manual page of this file (man dhcpd.conf).
Student Notebook
DHCP Considerations
Every dynamic IP address needs a DNS entry

Regular and reverse lookups!
The get-lease-hostnames statement retrieves the
hostname for each dynamic IP address and sends that to
the client as hostname option
Multiple DHCP servers:
Make sure each DHCP server has its own range
Make sure all static declarations are defined on each
server
Failover is supported, but no standards formally exist
so no interoperability with other DHCP servers. See
man dhcpd.conf for more information
Figure 9-12. DHCP Considerations LX073.2
Notes:
Every DHCP client needs a DNS entry as well. This is not so much for DHCP itself, but for
server programs like telnetd, who need to be able to do a reverse DNS lookup. In most
cases this means that you will fill your DNS tables with hostnames like
dyn10-1-1-10.example.com entries, which will work just fine.
You might also want to give just that dynamic hostname to the client as part of their DHCP
option set. This is done with the get-lease-hostname directive in the /etc/dhcpd.conf file.
Note that not all clients actually support configuring the hostname from DHCP. For instance
on Windows systems, the hostname is equal to the NetBIOS name, and can not be
configured by DHCP.
If you plan on using multiple DHCP servers in your environment, make sure that each
DHCP server has its own set of dynamic IP addresses, so one server can't hand out an IP
address which has already been assigned by another system. But if you have hosts in your
environment who need to have static IP addresses assigned by DHCP, make sure their
configuration is stored in each and every /etc/dhcpd.conf file. Otherwise these systems
may accidentally get a dynamic IP address anyway.

V3.0
Student Notebook
Uempty The ISC DHCP server, version 3 and up, also supports a failover mechanism, whereby two
DHCP servers keep an eye on each other and between them make sure that a “pool” of IP
addresses is served to clients. Unfortunately, the protocol with which they communicate is
not yet standardized, so it is unlikely that this will work with other DHCP servers as well.
For more information on DHCP failover, see man dhcpd.conf.
Student Notebook
Dynamic DNS
DDNS: Method where the DHCP server automatically

registers hostname/IP address combinations with the
DNS server using the client's "host-name" DHCP option
Currently no formal RFC available - interim standard
used by ISC DHCP server and ISC DNS server
# vi /etc/dhcpd.conf # vi /etc/named.conf
ddns-update-style interim; key DHCP_UPDATER {

algorithm hmac-md5;
key DHCP_UPDATER { secret "pRP5FapFoJ95JEL06sv4PQ==";
algorithm hmac-md5; };
secret "pRP5FapFoJ95JEL06sv4PQ==";
}; zone example-company.com. {
type master;
zone example-company.com. { file "named.example-company.com";
primary 10.1.1.3; allow-update{ DHCP_UPDATER; };
key DHCP_UPDATER; }
}
zone 1.1.10.in-addr.arpa. {
zone 1.1.10.in-addr.arpa. { type master;
primary 10.1.1.3; file "named.10.1.1";
key DHCP_UPDATER; allow-update{ DHCP_UPDATER; };
} }
Figure 9-13. Dynamic DNS LX073.2
Notes:
The ISC DHCPD server, version 3.0 and up, in combination with BIND 9 (which is also
written and maintained by the ISC) supports Dynamic DNS. This means that when the
DHCP server hands out an IP address, the DNS server is updated automatically, effectively
coupling the fixed hostname of the client to the dynamic IP address that it obtained. This is
especially useful for laptops who need a fixed hostname, but might connect to multiple
different networks (and will thus get a different IP address every time).
This whole mechanism starts with the DHCP client. In order for DDNS to work, the client
needs to supply its hostname to the DHCP server. This is done using DHCP option 12,
“host-name”. Windows clients supplies this name automatically, using their NetBIOS name,
but the Linux mentioned clients don’t supply the name by default. Different distributions
have solved this in different ways:
• On a Red Hat system, make sure the “DHCP_HOSTNAME” option is defined in
ifcfg-<device>. This is done automatically when you supply a hostname for this
interface in redhat-config-network.

V3.0
Student Notebook
Uempty • On a SuSE system, the hostname is automatically supplied, and is taken from
/etc/HOSTNAME.
After the DHCP server assigns an IP address to the client, it will send the hostname and
the assigned IP address to the DNS server. Unfortunately, just as with DHCP failover, the
protocol that governs this mechanism is not yet standardized. DHCPD 3 and BIND 9
therefore use an “interim” protocol which is likely to get standardized soon, but isn’t yet.
Once a final protocol has been standardized, the ISC will ensure that both DHCPD and
BIND will support that as well.
Configuring DDNS requires modifications to the configuration of your DHCP and your DNS
server. The most important configuration is that you have to add a key to their configuration
files. This key is used to authenticate the DHCP server to the DNS server, and should
obviously be the same for both daemons. A random key can be generated with the
command dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER. This
command stores the key in two files in your home directory:
Kdhcp_updater.<number>.key and Kdhcp_updater.<number>.private. (The <number>
is a unique number for this invocation of dnssec-keygen.)
On the DHCP server, you have to identify the protocol to use. Currently, this protocol is
called “interim”. Furthermore, you have to identify the primary nameserver for each of the
domains that are likely to get updated. Don’t forget that reverse lookups need to be
possible as well, so you also need to include one or more “in-addr.arpa” domains here.
On the DNS server, you have to identify the key of the DHCP server who is allowed to
update certain zones.
And there’s one more thing that you need to check: the user that runs the DNS server
(typically “named”) needs to have write access to the directory where the zone files are
kept. Experience has shown that not all distributions set these permissions correctly.
Student Notebook
Troubleshooting DHCP
If server won't start at all:

Check syntax of /etc/dhcpd.conf
Check existence of state file
Check server log file (/var/log/messages)
Check server leases file (/var/lib/dhcp/dhcpd.leases)
Check client IP address assignment
Win9x: winipcfg
WinNT/2000: ipconfig
Linux: pump -s, dhcpcd -s, ifconfig
Verify time on systems is synchronized
Check DHCP packet exchange with a sniffer
tcpdump
ethereal
Figure 9-14. Troubleshooting DNS Problems LX073.2
Notes:
DHCP problems are usually related to one of two things: the server won't start at all, or
clients cannot obtain addresses from the server.
If the server won't start at all, there's usually one of two problems:
• The syntax of the /etc/dhcpd.conf file is incorrect. You might have missed a semicolon,
or added one too much, or have unbalanced parenthesis.
• The state file dhcpd.leases cannot be found in the correct location.
A useful source of debugging information is the systems log file /var/log/messages.
If the server starts, but clients cannot obtain addresses from the server (and you have
configured the correct range statements in the /etc/dhcpd.conf file), check the contents of
the dhcpd.leases file as well, to see if not all addresses are already assigned to clients.
Also check the client itself, using the tools on that client.
Although DHCP is supposed to be immune from invalid clock settings, synchronizing the
clocks will definitely help you troubleshoot any problems you may have.

V3.0
Student Notebook
Uempty As a last resort, you might want to use a sniffer such as tcpdump or ethereal to trace the
client-server interactions and the contents of all packets.
Student Notebook
Checkpoint
1. In what situations can you use DHCP? (Choose all that apply.)
a. To configure laptops automatically, regardless of the network the users
connect their laptop to.
b. To configure classroom PCs automatically with an IP address after restoring
an image made by, for instance, ghost.
c. If your customers dial in over a PPP link and need a dynamic IP address for
that connection.
d. To configure servers with a static IP address by using static DHCP
addresses.
2. The DHCP packet used to figure out which DHCP servers are
willing to offer you a lease is called _________________.
3. When a DHCP client shuts down cleanly, it "gives back" its IP
address to the server by sending a _________________ packet.
4. Put the following DHCP messages in the correct order:
a. DHCPACK
b. DHCPREQUEST
c. DHCPREPLY
d. DHCPRELEASE
e. DHCPDISCOVER
f. DHCPOFFER
Notes:
1.
2.
3.
4.

V3.0
Student Notebook
Uempty
Unit Summary
It is very useful to configure IP clients dynamically

No local configuration necessary
Less IP addresses needed
The DHCP protocol allows dynamic client configuration
Linux can act as a DHCP client using the client daemons
pump, dhcpcd or dhclient
Linux can act as a DHCP server using the server
daemon dhcpd
The DHCP server is configured in /etc/dhcpd.conf
The ISC DHCP server supports Dynamic DNS if you also
use the ISC DNS server
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 10. Network File System

This unit describes the concepts of the Network File System and its
implementation in Linux.

• Define NFS terminology and concepts
• Describe the principles of mounting file systems
• Identify the NFS daemons and their roles
• Describe NFS authentication
• Configure an NFS server
• Configure an NFS client

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 10. Network File System 10-1
Student Notebook
Objectives
Define NFS terminology and concepts

Describe the principles of mounting file systems
Identify the NFS daemons and their roles
Describe NFS authentication
Configure an NFS server
Configure an NFS client
Notes:

V3.0
Student Notebook
Uempty
Sharing Data on a Network
NFS Client NFS Server
NFS Client
Data
NFS Client
Figure 10-2. Sharing Data on a Network LX073.2
Notes:
For various reasons data may need to be shared over the network, instead of being
replicated. This is especially important for users home directories.
One way in which this can be achieved is by using NFS.
Student Notebook
Network File System (NFS)
File sharing between heterogeneous systems in a

TCP/IP network
Transparent access to remote files and directories
Developed by Sun Microsystems in 1984
Uses client/server technology:
The server "exports" a directory
The client "mounts" an NFS exported directory
NFS is stateless:
Server does not remember anything about transactions
Client is not notified when server is down
No system recovery procedures
Figure 10-3. Network File System (NFS) LX073.2
Notes:
Network File System (NFS) is a facility for sharing files in a heterogeneous environment of
machines, operating systems, and networks.
Although NFS will function over any TCP/IP network, it requires the speed of local area
networks to perform file sharing with acceptable performance.
Sharing is accomplished by building a view of a remote file system, then reading or writing
across the network to the files. Only one copy of a file exists on the NFS network, thus
maximizing file storage availability.
The NFS function is built into the kernel of the operating system so it is transparent to
applications and users.
NFS was developed by SUN Microsystems in 1984, and first became available to the
general public in April, 1985. It was first delivered with SUN Berkeley 4.2 UNIX. Over the
years NFS has become a de facto standard in the engineering and scientific worlds.
NFS provides a Client/Server relationship where the server stores files and provides
administration services and the client requests these services.

V3.0
Student Notebook
Uempty One or more systems can be configured to provide a range of server functions for a range
of client systems. A system can play both the client and server role with other systems,
providing some services and requesting others.
NFS uses a stateless protocol. Each remote procedure call contains all of the information
necessary to complete the call and the server does not keep track of any past requests.
Clients must maintain all of this information. They are not notified if the server is down. This
avoids complex crash recovery. A packet is just sent again until the packet gets through.
UDP is used as the transport protocol for NFS RPCs. UDP is connectionless and does not
maintain status information about the server. Other RPCs, for example mount or lock
requests, can either use TCP or UDP.
Student Notebook
The NFS Protocol
All NFS server daemons open a dynamic port < 1024

All opened ports are registered with the portmapper, who
is behind port 111
When a client wants to connect to an NFS server, it asks
the portmapper what port to use
Client Server
mount request portmap (port 111)
1 call to portmap
returns mountd port # 2
rpc.mountd
3 mount request
kernel
OK - passes file handle 5
Figure 10-4. The NFS Protocol LX073.2
Notes:
The NFS protocol is different from other TCP/IP protocols in that it does not use a fixed,
reserved port number to offer its services. Instead, it opens a dynamic port and registers
that port with the portmapper. The portmapper runs behind a well-known port (111) and is
able to send the port numbers used by the NFS daemons to clients.
So if for instance the client wants to perform a mount of an exported filesystem, it first has
to connect to the portmapper to retrieve the port number of the rpc.mountd daemon. Only
then can it connect to the mount daemon to retrieve the file handle.

V3.0
Student Notebook
Uempty
Virtual File Systems
Method used to hide underlying storage media from

application and user, integrated in Linux kernel
Ensures that NFS mounting a filesystem is transparent
Client Server
System Calls
vfs vfs
Linux disk NFS client NFS server Linux disk

filesystem routines routines filesystem
disk RPC/XDR RPC/XDR disk
UDP/IP network UDP/IP
Figure 10-5. Virtual File Systems LX073.2
Notes:
Linux uses a structure called a virtual file system (VFS) to define a hardware-independent
mechanism for addressing different types of file systems. This is done inside the kernel so
that applications using the open, close, read and write system calls to access files do not
need to be modified.
This VFS structure provides a set of well-known operations that interact with underlying file
systems and objects. These operations define a consistent interface to multiple file
systems, remote or local. This consistent interface allows the user to view the directory tree
as a single entity. It also allows the logical file system code in the kernel to operate without
regard to the type of file system being accessed.
Student Notebook
How NFS Shared Files are Protected
NFS does not do any authentication

User credentials (UID, GID) on the client are also used
on the server
Ensure that UIDs, GIDs, usernames and group names
are synchronized!
NFS relies on Linux authorization
UID/GID in combination with standard Linux
permissions
NFS exports can be read-only
NFS exports can be limited to certain hosts
NFS can limit root access ("root squashing")
Figure 10-6. How NFS Shared Files are Protected LX073.2
Notes:
NFS does not offer an integrated security model for protection of the files. Instead, it relies
a lot on inherited Linux security mechanisms to provide security.
For starters, NFS does not do any authentication.1 Instead, it assumes that the client
operating system has already established the identity of the user, and uses the UID and
GID of the user on the client host as the UID and GID on the server as well. This makes it
extremely important that UIDs and GIDs are synchronized between the clients and the
server. One of the tools that make this possible is NIS, which will be discussed later on in
this course.
Furthermore, NFS does not do much authorization2either. To a large extent, it relies on
Linux authorization (UIDs and GIDs in combination with the standard Linux permissions on
files and directories) to determine your access.
1
Authentication is the process of establishing that you really are who you say you are. This is usually verified with a password.
2
Authorization is the process of determining your access to resources, based on your identity that was established in the authentication
phase.

V3.0
Student Notebook
Uempty There are a few ways in which NFS can provide some additional security though:
• NFS exports can be read-only, so that no NFS user can write to a filesystem.
• NFS exports can be limited to certain hosts only, either based on IP address or on
hostname. This limits access to NFS exports to trusted hosts only.
• NFS exports will by default limit the access of the root user to an NFS export: When the
root user on a client system tries to access an exported filesystem, his UID and GID are
mapped from zero (root) to the UID and GID of the nobody account. This process is
called root squashing and ensures that if a client system has been broken into, that the
server is not automatically compromised as well.
Student Notebook
UNIX Authorization - User
A user uses the same UID on the client and on the server
CLIENT
/home
/etc/passwd /mntpt
team01 208, 1...
sys1 team02 209, 1...
team03 210, 2...
file1 file2
RPC request
UID GID
vi /home/mntpt/file1
ls -ln /home/files
rwxrw---208, 1 file1
sys3 /etc/passwd
team04 208, 1...
SERVER
Figure 10-7. UNIX Authorization - User LX073.2
Notes:
The example visual shows the situation where a user is logged in as team01 on the client
system. The UID associated with team01 is 208, and this is the value that is passed to the
server in the RPC request to read data from the NFS exported filesystem. If the user with
UID 208 has access to a certain file on the server, then the user on the client system can
access that same file over NFS.
Note that the user name on the client and server are not the same! UID 208 is associated
with username team01 on the client, but with team04 on the server. This can be done on
purpose, but in most cases this is an error.

V3.0
Student Notebook
Uempty
UNIX Authorization - Root
The root user is by default mapped to the nobody account
CLIENT
/home
/etc/passwd /mntpt
root:!:0:0
sys1
file1 file2
RPC request
UID GID
vi /home/mntpt/file1
ls -l /home/files
sys3 /etc/passwd
nobody:x:99:99:Nobody:/:
SERVER
Figure 10-8. UNIX Authorization - Root LX073.2
Notes:
If a user is logged in as root on the client station, his UID is by definition zero. If he or she
tries to access a file on the NFS server, a safety feature called "root squashing" is enabled,
which ensures that the UID of the user is mapped to the UID of the nobody account.
This safety feature ensures that if a client is compromised by a hacker, the server is still
relatively safe.
The UID of the nobody account in the example is 99, but this differs from distribution to
distribution.
Student Notebook
Configuring the Server
Identify what to export

Add all exports to /etc/exports file
Start portmap
Start NFS server daemons
rpc.mountd: Satisfies mount requests
nfsd: Performs actual file operations (open, close,
read, write)
Add NFS to system startup
Figure 10-9. Configuring The Server LX073.2
Notes:
When configuring the server, you first have to decide what to export, and add this to the
/etc/exports file. Then you need to start the appropriate daemons:
• portmap
• rpc.mountd
• nfsd
And obviously you might want to make sure that all these daemons are started
automatically when the system starts up.

V3.0
Student Notebook
Uempty
The /etc/exports File
# cat /etc/exports
/mnt/cdrom *(ro)
/usr/games *(rw)
/home *.local.domain(rw)
/budgets *.accounting(ro) trusty(rw,no_root_squash)
Figure 10-10. The /etc/exports File LX073.2
Notes:
/etc/exports file lists all directories that a server makes available to its clients. Only
exported directories can be mounted by clients.
The following are some examples:
• /mnt/cdrom - Any client on the network can mount this directory read-only.
• /usr/games - Any client on the network can mount this directory read-write.
• /home - Only clients whose host name ends with .local.domain can mount this
directory, read-write.
• /budgets - Clients whose host name ends with .accounting can mount this directory,
read-only, and the host trusty can mount this directory read-write.
The no_root_squash option in the /budgets line tells nfsd not to apply "root squashing".
After the /etc/exports file is created or altered, the rpc.mountd and rpc.nfsd need to read
it again. This is done using the exportfs -a command, or by restarting the NFS daemons.
Student Notebook
Configuring the Client
Create mount point (empty directory)

Mount NFS filesystems
Add NFS filesystems to /etc/fstab, if needed
Figure 10-11. Configuring the Client LX073.2
Notes:
There are three steps to configure an NFS client.
• Use mkdir to establish the empty mount point directories
• Issue the mount command to invoke an NFS mount.
• Add the NFS mounts to the system startup, if needed.

V3.0
Student Notebook
Uempty
Manual Remote Mount
# mount sys3:/home/files /home/mntpt
sys1 sys3
/ /
home home
mntpt files
file 1
file 2
NFS Client NFS Server

Mount Point Exported Directory
Figure 10-12. Manual Remote Mount LX073.2
Notes:
Manual mounts (explicit) require, as a minimum, the server's host name, absolute path
name of the remote directory and the path name of the local directory mount point. Only
root can issue the mount command for mounting a file system.
Student Notebook
Predefined Mounts
All predefined mounts are listed in /etc/fstab

Mounted automatically at system startup
After network interfaces are enabled
# cat /etc/fstab
/dev/hda1 /boot ext2 defaults 1 2
/dev/hda5 / ext2 defaults 1 1
sys1:/mnt/cdrom /mnt/cdrom nfs ro,noauto 0 0
sys1:/home /home nfs rw 0 0
sys3:/data/budget /budget nfs rw 0 0
/dev/hda2 swap swap defaults 0 0
Figure 10-13. Predefined Mounts LX073.2
Notes:
Predefined mounts are also referred to as implicit mounts. They are probably the most
common way to perform NFS mounts.
Predefined mounts are achieved by adding the appropriate entry to the /etc/fstab file and
are invoked at a system restart.
It is possible to invoke a predefined mount from the command line rather than invoke it at
boot time. Use the mount command and the local mountpoint name. The mount command
uses the this to locate the corresponding stanza in the /etc/fstab file. This stanza is then
used to supply the needed information to complete the mount. Typically these stanzas will
have the noauto option associated with them to prevent them from being performed
automatically when the system starts.

V3.0
Student Notebook
Uempty
NFS Mount Options (1)
Option Function Default

auto Mount automatically when mount -a auto
noauto is issued
dev Interpret special devices dev
nodev
exec Allow execution of executables exec
noexec
suid Allow SUID and SGID bits to have suid
nosuid effect
user Allow ordinary (non-root) users to nouser
nouser execute the mount
ro Read-only/Read-write rw
rw
Figure 10-14. NFS Mount Options (1) LX073.2
Notes:
The options in this visual apply to all types of mounts, not just NFS mounts. But they are
especially useful in NFS mounts, that's why we cover them here as well.
• auto and noauto specifies whether this filesystem should be mounted when the mount
-a command is executed (for instance at system startup). The default is auto.
• dev and nodev specifies whether character and block special devices should be
interpreted as such. The default is dev.
• exec and noexec specifies whether executables on the mounted filesystem can be
executed. The default is exec.
• suid and nosuid specifies whether SUID and SGID bits retain their meaning on the
mounted filesystem. The default is suid.
• user and nouser specifies whether an ordinary user is allowed to mount this filesystem.
This is especially handy to allow users to mount removable media, for instance a floppy.
The default is nouser.
• ro and rw specify whether the filesystem is to be mounted read-only or read-write.
Student Notebook
The nosuid, nodev and noexec are intended to close gaping security holes. Suppose a
hacker is able to break the server. He can then place trojan horses with SUID bits on the
exported filesystem and execute them on the client. Or he can make a block device, for
instance /dev/hda on the exported file system and give read/write access to everybody. He
can then read the entire contents of the disk, even if he only has user privileges on the
client.

V3.0
Student Notebook
Uempty
NFS Mount Options (2)
Option Function Default
bg Mount attempted in background if first
attempt fails
fg All mount attempts done in Yes
foreground
soft Repeated RPC calls eventually
timeout
hard RPC calls try indefinitely until server Yes
responds
intr Allows KB interrupts to halt hard
attempts
rsize Block size for reading 1024
wsize Block size for writing 1024
timeo Timeout before sending first 7
retransmission (in 1/10 of a second)
retrans Number of retransmissions 3
retry Number of minutes to retry read/write 10000
on hard mounted filesystems
Figure 10-15. NFS Mount Options (2) LX073.2
Notes:
The following options are specific for NFS.
• bg and fg specify whether the mount, after the first try, should be attempted in the
background (other processes can go on) or in the foreground (other processes are
halted until the mount succeeds).
• soft and hard specify whether the RPC calls will eventually timeout and return the error
to the application, or will go on indefinitely.
• intr specifies whether the user can interrupt a hard mounted filesystem operation which
hangs with Ctrl-C.
• rsize and wsize specify the block size for reading and writing, respectively. The default
is 1024 bytes but on a system connected to a Local Area Network (LAN) with enough
memory, an increase to 8192 can greatly boost performance.
• timeo, retrans and retry are all parameters for optimization in case of RPC calls not
being answered. See man nfs for details.
The best values for these options highly depend on local circumstances and requirements.
Student Notebook
Useful Commands
rpcinfo queries what rpc services are available

rpcinfo -p host shows all rpc services on host
exportfs maintains table of current exports
exportfs -a re-reads /etc/exports
exportfs -u un-exports exports
showmount shows what an NFS server has exported
showmount -a shows all actual mounts
showmount -e host shows the exports on host
Figure 10-16. Useful commands LX073.2
Notes:
The rpcinfo command can be used to ask any server what RPC services are running. With
the -b option it will do a broadcast on the local network asking all servers who is running a
certain service.
The exportfs command is used to manipulate the list of exports that the NFS server is
exporting. The most important of the list is exportfs -a, which causes the NFS daemons to
re-read the /etc/exports file. But it is also possible to add or delete one export to/from the
list of current exports with this command.
The showmount command can be used to ask an NFS server what it has exported
currently, and what clients actually have something mounted from it.

V3.0
Student Notebook
Uempty
Additional NFS Services
rpc.rquotad: Supports quota over NFS

rpc.lockd: Performs Unix locking over NFS
rpc.statd: Performs lock recovery when clients or
servers crash - needed in combination with rpc.lockd
All these daemons should be run both on the client and
on the server, or use mount -o nolock to prevent these
services from being used
Figure 10-17. Additional NFS Services LX073.2
Notes:
NFS is also able to provide you with some additional capabilities that are not often used but
can be useful in specific situations.
Quota is a way of limiting the amount of disk blocks or inodes a user may use on a certain
filesystem. It is a filesystem-level feature which can be integrated in the NFS system by
running the rpc.rquotad both on the client and the server.
Locking is a feature which allows a process to "lock" a file. Depending on the type of lock,
this disallows other processes from reading from or writing to the file. Locking thus ensures
that only one process can write to the file at any given time. To use locking on an NFS
mounted filesystem, run the rpc.lockd daemon both on the client and the server. If a client
holding a lock on a file crashes, you need to recover the lock eventually. That's why you
also need to run the rpc.statd on the client and server when you run the rpc.lockd.
The NFS server runs all these services by default, and assumes that the NFS client does
the same. However, if the client happens not to run these services, or if the client does not
run the portmapper, then the server will only allow the mount request after a long timeout
Student Notebook
(several minutes). If you are not running these daemons on the NFS client, you should
therefore use mount -o nolock to avoid this timeout.

V3.0
Student Notebook
Uempty
Troubleshooting NFS Problems
Verify export list in /etc/exports

Verify that all server-side daemons are started
portmap
nfsd
rpc.mountd
Verify exports with showmount -e hostname
Verify basic network connectivity and DNS
Verify that users are using correct UIDs and GIDs
Beware of root squashing
Beware of NFS version incompatibilities
Figure 10-18. Troubleshooting NFS Problems LX073.2
Notes:
The visual shows some things to think of when troubleshooting NFS problems.
The last item, beware of version incompatibilities, might need some explanation: Sun
Microsystems recently released a new specification of the NFS protocol, which is version 3.
Some UNIX systems already implement this, and some don't. That would not be a problem,
since every implementation automatically uses version 2 if they see that the other party
does not use version 3. However, in some specific situations this version detection
mechanism fails. You are then faced with a situation that the client thinks the server is on
version 3, while it really is on version 2. This does not happen often, but has been reported
occasionally. In all reported cases, the server used another UNIX than the client.
To solve this problem, every client and server daemon has an option to force it to support
version 2 only. Apply these options (see the manual pages for the correct option) and you'll
be fine.
Student Notebook
Checkpoint
1. T/F. A host can be an NFS server and NFS client

simultaneously.
2. T/F. An NFS mount request is always issued by the
NFS client.
3. Which server daemon handles client requests for file
system operations?
4. Which command is used to see which file systems are
currently mounted?
5. Which daemon provides a lookup function on port
numbers associated with a specific program that a user
needs to access?
Notes:
1.
2.
3.
4.
5.

V3.0
Student Notebook
Uempty
Unit Summary
The TCP/IP portmap daemon must be active before

NFS is started
The NFS server file /etc/exports makes filesystems or
directories available to NFS clients
The two NFS server daemons that need to be started are
rpc.mountd and nfsd
NFS client mount point directories must exist before a
remote mount can be executed
NFS clients mount remote filesystems with the mount
command
Predefined mounts are defined in /etc/fstab on the client
Additional NFS features are quota and locking
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 11. NFS Automounter

This unit describes a facility provided with NFS called automount. It
covers the concepts of automount and how to implement it.

• Describe the basic functionality of the automounter
• List two automount daemons for Linux
• Configure and use the amd automounter
• Configure and use the autofs automounter

Accountability:
• Exercises
© Copyright IBM Corp. 1999, 2003 Unit 11. NFS Automounter 11-1
Student Notebook

' !
j* j `

Notes:

V3.0
Student Notebook
Uempty
!
}

@%!
}

`@'
@%

Figure 11-2. Automounter Overview LX073.2
Notes:
The automounter monitors specified directory mount points, and when a file I/O operation
is requested to that mount point, performs the RPC call to complete the NFS mount to the
remote server specified in the automounter map files. Any directories that don't already
exist on the client will be created. After a period of inactivity, five minutes by default, the
automounter will attempt to unmount any mounted directories under its control.
Automount maps can be ordinary text files, NDBM maps and NIS maps.
Student Notebook
!;
#!

!@%

@
J !

! * Q
@ !Q`
!

Q J!
Figure 11-3. Automounter Benefits LX073.2
Notes:
Using the automounter means you don't have to keep the /etc/fstab file up to date with
NFS stanzas nor do you have to keep file systems mounted that are not being used. This is
especially useful when a client (or worse: a lot of clients) has to boot and servers are not
(yet) available. Imagine, for instance, the situation after a general power failure, where all
clients come up simultaneously, all trying to mount all their directories from nfs servers that
are at that moment booting as well.
When combined with NIS there is another advantage as well: no host-specific information
needs to be stored on the client at all. All the information the client needs is either delivered
through DHCP or through NIS. That means that a system administrator can have one disk
image which he loads on the client in case of problems. He then reboots the system and it
is up and running. No local configuration is necessary.

V3.0
Student Notebook
Uempty
07!
'

K%'
#

[
%
! Y ZYZY
Z¡
! +

@*

!
+

! *
!

!
[

Q
Figure 11-4. Linux Automounters LX073.2
Notes:
There are two automount packages which can today be found on Linux distributions.
The first package is the AMD daemon, which is derived from the 4.4BSD automount
daemon. It runs completely in user space; it acts as a separate NFS server to the client. It
is well understood and highly stable. A disadvantage is that, because of technical reasons,
it cannot mount the directory directly on the mountpoint that is referenced, but instead has
to mount the NFS export on a separate mountpoint. It then creates a symbolic link to this
mountpoint so that everything is transparent to the user.
The Autofs package is fairly new. It is modeled after the AMD package but is partly
implemented in the Linux kernel, as the "autofs" filesystem type. This makes it possible to
do the mount directly at the correct mountpoint. In addition to NFS mounts, autofs can also
automatically mount other network- and local filesystems, such as SMB, CD-ROM,
ext2/ext3, vfat and so forth.
The automount package that is installed depends on your distribution. SuSE, for instance,
only supports the autofs daemon, while Red Hat supplied both.
Student Notebook
!%:$ *

V"
V
@"
V
VU

"C
V"U

V

Figure 11-5. AMD Configuration File: /etc/amd.conf LX073.2
Notes:
The AMD configuration file is called /etc/amd.conf. It starts with a global section,
identifying all the options that are global, meaning that they apply to all the automount
volumes.
After the global section come the sections for the directories that the automount daemon
will have control over. Each section may have its own options, and each section will need
exactly one referral to an automount map. This is identified with the map_name tag.
Some of the more important options are:
• auto_dir - The directory that automount will use to mount all the directories under.
• log_file - The file where automount will log its messages.
• log_options - Identifies which messages will be logged.
• map_type - The type of map being used.
• browsable_dirs - Whether a user can issue for instance the ls command at the top of
the automount hierarchy (in this example in the /home directory). Doing such an ls
causes all mounts in the map file to be performed and may thus cause performance
problems.

V3.0
Student Notebook
Uempty
!%"$

7 U
M®"MU®"M
7
U
M®"MU®"M

U
M®"MU®"M

Figure 11-6. AMD Map File LX073.2
Notes:
The automount map for /home contains two columns.
The first column identifies the directory. Since this is the map for /home, in this example we
talk about /home/tux1, /home/tux2 and /home/tux3. Should anyone access one of these
directories, the corresponding file system is mounted.
The second column identifies where to get this file system. The automount daemon is very
flexible and understands all kinds of file systems which it can mount. It is for instance also
possible to automatically mount the CD-ROM if someone refers to a certain directory. In
this case we are only interested in NFS mounts. So we supply the type:=nfs stanza. The
automounter then knows to mount an NFS file system. The second and third stanza identify
the remote host and the remote file system, respectively.
Student Notebook
4!%
¢ *

K

!
J<#J
¢ *
J

Figure 11-7. Starting AMD LX073.2
Notes:
The automount daemon is invoked with the amd command. It does not need any options,
since all options are specified in /etc/amd.conf. However, should you wish to use another
configuration file, you can specify it with the -F option.
The fact that amd does not need any options does not mean that it won't accept any: there
are several command line options that override the options in /etc/amd.conf. Refer to the
manual page and the documentation for them.
You can also prevent the usage of the configuration file /etc/amd.conf by specifying the
directory to manage and the map file on the command line.
The automount daemon automatically forks and puts itself in the background.
Just like any daemon on a Linux system, the amd daemon is usually not started directly but
through a startup script in /etc/rc.d or /etc/rc.d/init.d.

V3.0
Student Notebook
Uempty
!%!
U7
"
U7

@7U

*"C>

" U
" *"C>
U7M*7+>
U
*"C"

>
U7
7
U7

@7U

*"C>

" U
" *"C>
U7M*7+>
U
*"C"

>
UM
7U
7U
*"C>
Figure 11-8. AMD in Action LX073.2
Notes:
Nothing is mounted when the automount daemon is started, except for an NFS mount on
the /home directory. This NFS mount is actually the automount process itself, which
ensures that all file I/O operations are delivered to it.
When a user references the /home/tux1 directory, then this operation is caught by the
automount daemon, who then automatically mounts the correct NFS export from the
correct host on a mountpoint under /n. It then creates a symbolic link from /home/tux1 to
this mountpoint, and then returns control to the user. The user will then be able to read the
directory as if nothing has happened.
Student Notebook
!%"
!_ !Q

!
`_

! `_

+
Figure 11-9. AMD Mountpoints LX073.2
Notes:
The real NFS mount will not be done on /home/tux1, but on /n/sys3/home/tux1. A symbolic
link /home/tux1 will then be created, which points to /n/sys3/home/tux1.
The reason for this is highly technical and beyond the scope of this course.

V3.0
Student Notebook
Uempty
! :$ *

"

Figure 11-10. Autofs Configuration File: /etc/auto.master LX073.2
Notes:
The Autofs configuration file basically contains the same information as the AMD
configuration file, only with a slightly different syntax. Also note that it is not possible to add
any options here.
Student Notebook
! "$

7 UM
7
UM

UM

Figure 11-11. Autofs map file LX073.2
Notes:
The Autofs map files also contain basically the same information, but in a more readable
format. By default, NFS mounts are used, but it is possible to specify other mount forms,
such as CD-ROM, and to specify various options here. See the manual page of autofs for
more information.

V3.0
Student Notebook
Uempty
4!
*

K

!
&
$ *
J

Figure 11-12. Starting Autofs LX073.2
Notes:
Autofs should basically always be started through its initialization script in /etc/rc.d or
/etc/rc.d/init.d. The reason for this is that the init script reads and parses the
/etc/auto.master configuration file and starts an automount daemon for each and every
entry in this configuration file.
You can start the automount daemon by hand as well, in which case you have to supply the
name of the directory, the type of the map file and the name of the map file by hand.
Student Notebook
! !
U7
"
U7

@7U

*"C>

" U
" *"C>
*77>
U
*"C>
U7
7
U7

@7U

*"C>

" U
" *"C>
*77>
U
*"C>
UM
7
7U
*"C>
Figure 11-13. Autofs in Action LX073.2
Notes:
Autofs works to a user the same as AMD. There are two main differences which can be
seen in the visual though.
The first difference is that autofs is integrated in the kernel. This can be seen from the
output of the first mount command. The mount type of what is mounted on /home is autofs
instead of nfs. This means that the kernel actually knows what is going on, instead of being
fooled by a pseudo-NFS daemon.
The second difference is that the actual mount of /home/tux1 is done on the mountpoint
/home/tux1, instead of on /n/sys3/home/tux1. This makes the system a little quicker and
robust.

V3.0
Student Notebook
Uempty
!

* !

} !

# Q
!
'
Figure 11-14. Automounter Timeout LX073.2
Notes:
If the automountd daemon had to create either the parent and/or the subdirectories listed
in the map, it will automatically unmount them after a timeout has been reached. The
default timeout is 300 seconds (five minutes) but this can be changed with various
automount options.
Student Notebook
"
_K !
*

K £££ * !

K
£££
K £££ *!|

@% K

Notes:
1.

V3.0
Student Notebook
Uempty
34
!

!
' *
*
[!

@%

! Q Q
*
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 12. Network Information Service

This unit discusses the concepts of the Network Information Service
protocol and the implementation thereof under Linux.

• Define the purpose of NIS
• Define NIS terminology and daemons
• Configure an NIS Master Server, NIS Slave Server and NIS Client

Accountability:
• Lab exercises
© Copyright IBM Corp. 1999, 2003 Unit 12. Network Information Service 12-1
Student Notebook
Objectives

Define the purpose of NIS
Define NIS terminology and daemons
Configure an NIS Master Server, NIS Slave Server and
NIS Client
Notes:

V3.0
Student Notebook
Uempty
Distributed Environment Concerns
Maintenance of separate copies of common configuration

files
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
Changes to a configuration file that must be propagated
to all hosts on a network
Probability of editing errors increase
Figure 12-2. Distributed Environment Concerns LX073.2
Notes:
Three common concerns in a networked environment are listed below:
• If all hosts on a network are to work together, depending on the consistency of common
configuration files on all machines can become a problem and is high maintenance for
the systems administrator.
• Changing, adding, and deleting a configuration file, like adding a new host to the
/etc/hosts file or a group to the /etc/group file, must be kept consistent on all similar
configuration files on all hosts, and must be propagated to all hosts.
• Anytime you edit a file, let alone multiple files, the chances of making errors exist.
Small networks may not be a problem, but larger networks could be a nightmare for the
system administrator.
Student Notebook
How NIS Addresses

Distributed Environment Concerns
NIS replaces replicated copies of common configuration

files with one data map for each file and locates them on a
central server
Enforces a consistent view of configuration files on a
network
Simplifies administrative control of a network
Eliminates the need to propagate changes to each
network
Figure 12-3. How NIS Addresses Distributed Environment Concerns LX073.2
Notes:
Instead of having to manage each system's /etc/passwd file or /etc/group file, all changes
are made on a central server that will share its information with all hosts on the network. An
example of a configuration file that is not common to all hosts would be the /etc/fstab file.
This file would not be a candidate for the central server data map structure of NIS.
The last problem can be solved however by using the NFS Automounter and supplying the
map files to the automounter using NIS.

V3.0
Student Notebook
Uempty
NFS and /etc/passwd
NFS Client-sys3 NFS Client-sys2
/etc/passwd /etc/passwd
root:!:0:0::/root:/bin/bash root:!:0:0::/root:/bin/bash
tux1:!:203:2::/home/tux1:/bin/bash tux4:!:205:2::/home/tux4:/bin/bash
NFS Server-sys1
/etc/passwd
root:!:0:0::/root:/bin/bash
tux1:!:203:2::/home/tux1:/bin/bash
Figure 12-4. NFS and /etc/passwd LX073.2
Notes:
The visual shows an example of a very common situation in a distributed network. We've
got an NFS server (sys1) which exports the home directories of all users to a number of
client systems (sys2 and sys3) in the network. Obviously, this requires all users to have an
account on each client as well as on the NFS server, and requires all UIDs to be matched
with the correct username.
In the example above, this is not the case. Not all users have accounts on all clients, and
UID 205 is sometimes used for tux3 and sometimes for tux4.
Student Notebook
NIS Centralized Control of /etc/passwd
NFS Client-sys3
/etc/passwd /etc/nsswitch.conf
root:!:0:0::/root:/bin/bash passwd: files nis
NIS Master Server-sys1

/etc/passwd
root:!:0:0::/root:/bin/bash
passwd map
tux4:!:205:2::/home/tux4:bin/bash DBM FORMAT
Figure 12-5. NIS Centralized Control of /etc/passwd LX073.2
Notes:
With NIS installed as a central server of data maps, the system administrator only updates
one /etc/passwd file for the network. This is centralized administration control via NIS.
If a user name lookup is performed and the name is not found in /etc/passwd, the NIS map
on the server will be checked.
NIS maps are converted into DBM format for faster search. DBM is the database system
that is built into BSD UNIX implementations. Under DBM the database consists of a set of
keys and associated values organized in a table for faster lookup. Every key and value pair
may be located using at most two file system accesses. This makes DBM an efficient
mechanism for NIS maps.

V3.0
Student Notebook
Uempty
NIS Centralized Control of /etc/group
NFS Client-sys3
/etc/group /etc/nsswitch.conf
root::0:root group: files nis
NIS Master Server-sys1

/etc/group
root::0:root
group map
students::1:me,you
pinguins::2:tux1,tux2,tux3,tux4,tux5
DBM FORMAT
Figure 12-6. NIS Centralized Control of /etc/group LX073.2
Notes:
Using a methodology identical to that of /etc/passwd, with NIS installed as a central server
of data maps, only one /etc/group file need be updated for the network
All entries above the NIS escape sequence are considered local entries and affect only the
local system. In effect, on the local system the /etc/group file is a combination of the
/etc/group files on both the server and on the client.
Student Notebook
NIS Systems
NIS NIS NIS

Slave Server Master Server Slave Server
Stores copies of Creates, maintains Stores copies of

maps maps maps
Answers client Answers client Answers client
requests requests requests
Transfer Maps Transfer Maps
Requests and Requests and

receives info receives info
from maps from maps
NIS Client NIS Client
Figure 12-7. NIS Systems LX073.2
Notes:
NIS is built on a client/server relationship.
The NIS server is based on a host that contains the NIS data maps. The NIS server
provides a global or single view of common configuration information for the NIS clients on
the network. A server can be defined as a master or a slave server. The NIS master server
is the true central server that creates, maintains, and distributes copies of the data maps to
the NIS slave servers. The NIS slave servers help balance the load of NIS client requests
for information and act as a backup for the NIS master if it goes down.
An NIS client gets all of its common configuration information from an NIS server.
As with NFS, NIS servers can be NIS clients as well.
Once a map is distributed from the NIS master server, all NIS servers have the same
information.

V3.0
Student Notebook
Uempty
NIS Binding
sys3
Broadcast - 1
need
server for
accounting
domain ypbind
3
/var/yp/binding/accounting.version sys1
- address of server
2
I'm available
for accounting
domain
ypserv /var/yp/accounting
NIS Server
Figure 12-8. NIS Binding LX073.2
Notes:
The process of locating an NIS server is called binding and is initiated by the ypbind
daemon that runs on all the NIS clients. There are two ways this process can happen:
• If no NIS server is stored in the clients /etc/yp.conf file, then the client will broadcast on
the local network to search for an NIS server.
• If a NIS server is stored in the clients /etc/yp.conf file, then the client will contact that
server directly using a unicast connection.
Once the NIS client has bound to an NIS server, it does not broadcast to the servers again.
ypbind hands back the address of the server to the client and stores it in the
/var/yp/binding directory under the name of domainname.version, where domainname is
replaced by the name of the NIS domain being used.
If the NIS server crashes or begins to respond slowly, ypbind on the client will break its
binding and broadcast another request for service from another NIS server.
ypbind broadcasts to the local network only. If the server are on another network, you can
also configure the server names in /etc/yp.conf or by using ypset.
To display the server you are currently bound to, use the ypwhich command.
Student Notebook
System Default NIS Data Maps
File Contains
/etc/passwd User names, user IDs, and passwords

/etc/group User groups
/etc/hosts Host names and IP addresses
/etc/aliases Aliases and mailing lists for the mail system
/etc/netgroup Netgroup definitions (used by NIS)
/etc/protocols Network protocol names and numbers
/etc/rpc Remote procedure call program numbers
/etc/services Network port numbers and service names
/etc/netid ID info for machine, hosts, and groups
/var/yp/ypservers NIS servers
Figure 12-9. System Default NIS Data Maps LX073.2
Notes:
These are the configuration files used to make a standard set of default NIS data maps.
Each file will be used to create the actual NIS map.
The system administrator can select any or all of the above files to be created for the data
maps. There is no minimal amount of files that must be selected.
Along with the system default maps, NIS provides the ability for a system administrator to
create individual data maps for use within the NIS domain. An example would be a
network-wide phone data map that would be built from an ASCII source file containing the
phone listing information of those in the NIS domain.

V3.0
Student Notebook
Uempty
NIS Configuration Scenario
Bigbucks Accounting Firm
NIS NIS
Master server, client Slave server, client
sys1 sys2
domainname=accounting domainname=accounting
/var/yp/accounting /var/yp/accounting
domainname=accounting
NIS
client
sys3
Figure 12-10. NIS Configuration Scenario LX073.2
Notes:
The visual shows the scenario we're going to use in the next few visuals.
Student Notebook
NIS Master Server Configuration Overview
Set NIS Domainname

Configure NIS source files
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
...
Create NIS data maps from source files
Start daemons
Figure 12-11. NIS Master Server Configuration Overview LX073.2
Notes:
The visual shows the steps we need to take to configure our NIS Master Server.

V3.0
Student Notebook
Uempty
NIS Domain Name - Master Server
Need to set the domain name before anything

# domainname accounting
# domainname
accounting
Configure system to set domainname at reboot
Red Hat: authconfig (modifies /etc/sysconfig/network)
SuSE: yast (modifies /etc/yp.conf and
/etc/defaultdomain)
Figure 12-12. NIS Domain Name - Master Server LX073.2
Notes:
The first thing that needs to be configured on the NIS master server (in fact, on any system
participating in a NIS domain) is the domain name. This is done with the domainname
command. Without options, it displays the current domain name. With the domain name as
option, it sets the domainname.
Make sure you configure your system so that when it boots, the domainname is set
automatically as well. How this is done depends on your distribution:
• Distributions that use /etc/sysconfig for their configuration should have the following line
added to the /etc/sysconfig/network file:
NISDOMAIN=accounting
• Distributions that use /etc/rc.config as their configuration file should have the following
line added to this file:
YP_DOMAINNAME=accounting
Student Notebook
Editing NIS Master Server /etc/passwd File
Ensure that it is complete and non-ambiguous
root:!:0:0::/:
May also need to edit /etc/group
Figure 12-13. Editing NIS Master Server /etc/passwd File LX073.2
Notes:
Edit the NIS master server's /etc/passwd file to include all the user accounts for the NIS
domain that the master server is serving. Ensure that there are no duplicate UIDs.
It may also be necessary to edit /etc/group to add in any additional groups needed on the
systems in the domain.

V3.0
Student Notebook
Uempty
Editing NIS Master Server /etc/hosts File
Again, make sure it is complete
127.0.0.1 localhost loopback

9.19.98.1 sys1
9.19.98.2 sys2
9.19.98.3 sys3
Figure 12-14. Editing NIS Master Server /etc/hosts File LX073.2
Notes:
This file should include all entries for all the hosts in the NIS domain that the NIS master
server is supporting.
Student Notebook
Final Master Server Configuration Steps
To initialize the master server and test everything:

# /etc/init.d/ypserv start
# /usr/lib/yp/ypinit -m
(answer all questions)
Make sure daemons are started at bootup
# chkconfig ypserv on
# chkconfig ypbind on
# chkconfig yppasswdd on
Figure 12-15. Final Master Server Configuration Steps LX073.2
Notes:
The steps to finish the NIS Master Server setup are as follows:
1. Start the ypserv daemon. This daemon needs to be running at all times when NIS is
active.
2. Run the /usr/lib/yp/ypinit -m script. The -m means: set up the master server on this
machine.
The ypinit will ask the user for the host names of the slave servers to create the file
/var/yp/ypservers file. This file is then used to create the /var/yp/accounting/ypservers
DBM map.
The ypinit will then go off and create all the NIS maps from the original text files. This
will take several minutes.
Note: There are some bugs in the Red Hat Linux distribution, causing ypinit to fail. One
of them is that the /etc/netgroup file is absent. To prevent this from happening, create an
empty /etc/netgroup file with touch /etc/netgroup before running ypinit.
3. Now start ypbind to become a NIS client as well.

V3.0
Student Notebook
Uempty 4. And last, start rpc.yppasswdd to allow users to change their password, shell and
name.
Now, test the configuration. If you are satisfied with the results, ensure that all daemons will
automatically start at system boot. To be absolutely sure that everything works, reboot and
test again.
Student Notebook
Contents of the NIS Domain Directory
All DBM map files stored in /var/yp/domainname

Each DBM map is sorted by a key
Allows for fast lookups in large tables
If a source file has multiple keys, multiple maps are
created
# ls /var/yp/accounting
group.bygid
group.byname
hosts.byaddr
hosts.byname
mail.aliases
netgroup.byhost
netgroup.byuser
netid.byname
passwd.byname
passwd.byuid
.
.
Figure 12-16. Contents of the NIS Domain Directory LX073.2
Notes:
NIS data maps are built in DBM format so they are indexed for faster searching. They must
have an associated key with a value. Since both the passwd and hosts maps could be
searched by either name or uid, one map is based on a key for the name and another built
with a key for uid and addr respectively.
The syntax for map names are:
/var/yp/domainname/map.key
This is not a complete listing of all the data maps that are built.
To view the contents of the data maps, use the ypcat command. ypcat passwd displays
the passwd.byname data map. ypcat -k passwd will display the keys used for the
passwd.byname data map as well as the contents. ypcat will use either the full name of
the map or a map nickname such as passwd. ypcat -t only allows the full mapname such
as passwd.byname to be used, and will not translate nicknames.

V3.0
Student Notebook
Uempty
NIS Slave Server Configuration Overview
Set NIS Domainname

/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
...
Transfer NIS maps from master server
Start daemons
Figure 12-17. NIS Slave Server Configuration Overview LX073.2
Notes:
The visual shows the configuration overview for the slave server. In a broad sense, it is
exactly the same as the master server.
Student Notebook
NIS Domain Name - Slave Server

# domainname
accounting
/etc/defaultdomain)
Figure 12-18. NIS Domain Name - Slave Server LX073.2
Notes:
The procedure to configure the domain name on the slave server is exactly the same as on
the master server.

V3.0
Student Notebook
Uempty
Editing Local Files - Slave Server
Edit /etc/passwd to include only:

Local user names
User names needed in case of master server failure
Edit /etc/group to include only:
Local groups
Groups needed in case of master server failure
Edit /etc/hosts to include only:
Loopback entry
Entry for this host
Entry for other vital hosts
Figure 12-19. Edit Local Files - Slave Server LX073.2
Notes:
Edit the NIS slave server's /etc/passwd file so it includes only the local users (those not
included in the NIS map). Retain a user with root authority in case the network or master
server crashes and an administrator needs to access the slave server.
Edit /etc/hosts so it includes an entry for local loopback and this system, and possibly
other vitally important systems (e.g. the NIS master server) as well.
Student Notebook
Configuring NIS Slave Server

To initialize the slave server and test everything:
# /etc/rc.d/ypbind start
# ypwhich
# /etc/rc.d/ypserv start
# /usr/lib/yp/ypinit -s sys1
.
Make sure daemons are started automatically on startup
# chkconfig ypbind on
# chkconfig ypserv on
Ensure that maps are updated regularly: add to crontab:
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
Figure 12-20. Configuring NIS Slave Server LX073.2
Notes:
Before we can configure the NIS slave server, the master server has to be running. Then,
we first configure the slave server as a normal NIS client, by running the ypbind daemon.
The ypbind broadcasts on the local network to search for the master server (in fact, any
server) to bind to.
The master server may not be on the same network as the slave server. That's what you
needed slave servers for anyway. In that case, the broadcast will fail and, for instance,
ypwhich will display that no server could be found. In this case, the name or IP address of
the master server needs to be added to /etc/yp.conf. Then, kill ypbind and start it again.
ypwhich should now show the name of the master server, and we can continue with the
next steps.
The next step is configuring this system as a slave server. This is again done using the
/usr/lib/yp/ypinit script, but this time with option -s sys1 to identify that we are a slave
server of sys1. ypinit will now set up the slave server configuration and do a transfer of all
maps. This may take some minutes.

V3.0
Student Notebook
Uempty Once ypinit is finished, we can test the configuration. Remove the master server reference
in /etc/yp.conf, if necessary, and ensure that we are bound to ourselves with ypset
localhost and ypwhich. Now verify whether all maps were transferred correctly with
ypcat. We can also check the contents of the map directory with ls -l /var/yp/accounting
Once everything checks out, ensure that all daemons are started at system boot.
Remember that on the slave server we may not run the yppasswdd daemon! Only
configure ypserv and ypbind.
When a map has changed on the master server, it is the duty of the master server to
contact the slave servers and inform them, so that the slave servers can retrieve the
changed maps. The master server does this by executing yppush after updating his own
maps. However, if the slave server is down at that time, its maps will not be updated until
the next change on the master server, which may take a long time. Therefore, it is wise to
put some entries in the crontab file on the slave server to ensure that it will contact the
master server every now and then to check for updated maps.
Student Notebook
NIS Client Configuration Overview
Set NIS Domainname

/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
...
Start daemons
Figure 12-21. NIS Client Configuration Overview LX073.2
Notes:
The visual shows the configuration steps for the client.

V3.0
Student Notebook
Uempty
NIS Domain Name - Client

# domainname
accounting
/etc/defaultdomain)
Figure 12-22. NIS Domain Name - Client LX073.2
Notes:
The procedure to configure the domain name on the client is exactly the same as on a
server.
Student Notebook
Edit Local Files - Client
Edit /etc/passwd and /etc/group to include only:

Local user names and groups
Edit /etc/hosts to include only:
Loopback entry
Entry for this host
Figure 12-23. Edit Local Files - Client LX073.2
Notes:
Edit the NIS client's /etc/passwd and /etc/group files so it includes only the local users
and groups (those not included in the NIS map).
Edit /etc/hosts so it includes an entry for this system and the local loopback.
If no NIS servers are available on the client's subnet, add the IP address of the NIS servers
to /etc/yp.conf.

V3.0
Student Notebook
Uempty
Start Client Daemon
Edit /etc/yp.conf to contain the IP addresses of NIS

servers in case there are no servers on this subnet
Start ypbind
Make sure ypbind is started at system startup
Figure 12-24. Start Client Daemon LX073.2
Notes:
If there are no NIS servers on your subnet (so you can't find an NIS server through a
broadcast), add the IP addresses of the NIS servers to the /etc/yp.conf file. Then start the
ypbind daemon and make sure it is started automatically when the system boots.
Student Notebook
Updating NIS Passwords with yppasswdd
NIS Client NIS Master Server

sys2 sys1
$ yppasswd
Changing NIS password for tux1 on sys1 yppasswdd
Old NIS password:
New password:
Retype new password: /etc/passwd
NIS password changed on sys1
make
Also available:
ypchsh rebuild
ypchfn passwd
map
yppush
all slaves
Figure 12-25. Updating NIS Passwords with yppasswd LX073.2
Notes:
On a regular, non-NIS system, there are three things a regular user may want to change in
/etc/passwd (and /etc/shadow):
• his own password
• his user information
• his shell
Since a regular user does not have write privileges to the /etc/passwd file, and does not
even have read privileges to the /etc/shadow file, three Set-UID (SUID) programs are
present to do this on the users behalf: passwd, chfn and chsh.
In a NIS environment, the user needs to be able to do the same, but this time over the
network. This is accomplished as follows:
• Three user programs have been introduced: yppasswd, ypchfn and ypchsh. These
programs do the same as the corresponding non-NIS programs.
• A daemon, yppasswdd, needs to run on the master server (not on the slave servers).
This daemon handles the requests from the client programs and makes the
corresponding changes in the source files /etc/passwd and /etc/shadow on the master
server. It then recreates the map files and pushes these out to all slaves.

V3.0
Student Notebook
Uempty
Updating NIS Maps
After updating /etc/passwd:

# cd /var/yp
# make passwd
.
# yppush passwd
Figure 12-26. Updating NIS Maps LX073.2
Notes:
After a source text file (for instance /etc/passwd) has been edited, there are two steps that
need to be taken:
1. First, the new passwd.byname and passwd.byuid map need to be regenerated from the
original /etc/passwd file. This is done by the make command in the /var/yp directory.
2. Second, the slave servers should get a signal that the passwd map has changed. This
is done with the yppush command.
The yppush command can be integrated in the make command by editing
/var/yp/Makefile: Set the variable "NOPUSH" to "false". It is a good idea to do this, since
yppasswdd calls make after a user has changed its password. If the change is
automatically pushed to the slave servers, the user does not have to wait until the
administrator (or cron) triggers a map transfer. However, in a large installation, with
thousands of users changing their password on a regular basis, this may lead to large
overhead. In that case, it is better to run a cron job which transfers the passwd map every
half hour or so.
Student Notebook
Downlevel Slave Server Maps
NIS Master Server
update map
make
rebuild map
yppush
Slave1 Slave2 Slave3

ypxfr ypxfr (down)
Updated Updated Earlier

Map Map Version
Cron jobs running ypxfr can keep slave maps current
Figure 12-27. Downlevel Slave Server Maps LX073.2
Notes:
A map transfer from the master to a slave can be triggered in two ways:
• By a master server executing yppush
• By a cron job on the slave server.
Either way, the ypxfr program is called, which will contact the master server to retrieve the
map file. ypxfr first checks whether the rpc.ypxfrd daemon is running on the master
server. If it is, the actual DBM map is transferred using an RPC DBM transfer. If it is not, it
does a ypcat and creates the DBM file itself, based on the output of the ypcat. Especially
in large installations, running the rpc.ypxfrd daemon on the master server may
significantly reduce the overhead of a map transfer. On the other hand, it is another
daemon which is running the whole day, so it is probably not worth the hassle in small
installations.

V3.0
Student Notebook
Uempty
NIS Programs Overview
Activity Client Slave Server Master Server
Initial setup domainname domainname domainname
ypinit -s ypinit -m
Bind to server ypbind ypserv ypserv
Set server to ypset
bind to
Show server ypwhich
bound to
Match entries ypmatch ypserv ypserv
View map ypcat
View map yppoll
information
Change yppasswd yppasswdd
password
Change shell ypchsh
Change name ypchfn
Transfer maps ypserv yppush
ypxfr ypserv
ypxfrd
Figure 12-28. NIS Programs Overview LX073.2
Notes:
The first program we need to run on all systems in a NIS domain is the domainname
program. It sets the NIS domainname for that host.
Then we have to initialize both the master server and the slave servers. The ypinit script
will do that for you.
The next step is running the daemons. There are two important daemons that need to be
running at all times: ypbind on the client systems, and ypserv on the server systems. Note
that in most cases you will also need to run ypbind on a server system.
Then the client needs to bind to the server. Generally this is done by the ypbind daemon
itself, but you might need ypset to set the server manually and ypwhich to see to which
server you are bound.
Most NIS lookups are built in to the Linux libraries, and do not need separate programs to
run. However, in some cases users will need to access the NIS maps directly. There are
three programs who do that:
Student Notebook
ypmatch will take an argument and match this argument with the NIS map.
ypcat will show an entire NIS map.
yppoll will show status information about a NIS map.
All three commands are being served on either the master or the slave servers by the
ypserv command.
NIS maps are generally built by the system administrator, and users do not need to edit
them. There is one exception to this however: users have some influence in their user
information. They need to be able to change their own password, their own shell and their
own name. For this, the yppasswd, ypchsh and ypchfn commands are available. They
contact the yppasswdd daemon to change the information in the NIS maps. Note that the
yppasswdd daemon only runs on the master server, not on the slave servers.
After a NIS map has changed on the master server, it needs to be transferred to the slave
servers. This works as follows:
• The master server executes the command yppush which sends a signal to ypserv on
the slave servers to update certain maps.
• The slave servers then start ypxfr to retrieve that map from the server. If the ypxfrd
daemon is running on the master server then the slave servers will use that daemon to
do a transfer of the DBM map. If that daemon is not running they will execute a ypcat of
the database and create the DBM maps themselves. Obviously, the last alternative is
slower than the former.

V3.0
Student Notebook
Uempty
Troubleshooting NIS Problems
Are the correct daemons running?

Is domainname set on all systems?
Check logfiles
Master server:
Do source files contain correct information?
Were map files created correctly?
Slave server:
Check contents of /var/yp/domainname for transferred
files
Client:
Check with ypwhich to which server you are bound
Check /etc/nsswitch.conf
Read contents of map file with ypcat and ypmatch
Figure 12-29. Troubleshooting NIS Problems LX073.2
Notes:
The visual shows some checks you can perform when troubleshooting NIS problems.
Student Notebook
Checkpoint
1. T/F. An NIS centralized set of files that all hosts on a network can
query are known as NIS Data Maps.
2. A group of hosts that share the same set of NIS data maps must
belong to the same:
a. Local network
b. NIS domain
c. TCP/IP domain
d. NIS master server
3. How many NIS Master Servers can there be per NIS domain?
a. 1
b. 2
c. 3
d. unlimited
4. T/F. NIS maps can be updated on either the NIS master server or the
NIS slave servers.
5. The maps for the NIS domain "legal" would be located in the
directory:
a. /var/yp/legal
b. /legal
c. /usr/var/yp/legal
d. /etc/legal
6. T/F. NIS maps are created from text input files.
Notes:
1.
2.
3.
4.
5.
6.

V3.0
Student Notebook
Uempty
Unit Summary
The steps to configure a master and slave server as well

as client are very similar. They are:
Update as needed the ASCII input files, for example,
/etc/passwd, /etc/hosts
Set the domain name
Initialize NIS
Updating existing data maps uses the make utility to
re-create the target maps using updated source ASCII
files as input
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 13. The Lightweight Directory Access

Protocol (LDAP)

This unit covers the LDAP protocol, and one of its applications under
Linux: authentication.

After completing this unit, you should be able to
• Describe the basic principles of LDAP
• List different LDAP servers
• Install and configure the OpenLDAP server
• Configure Linux to use LDAP authentication

Accountability:
• Checkpoint
• Machine exercises
References
SG24-4986 Understanding LDAP
SG24-5110 LDAP Implementation Cookbook
© Copyright IBM Corp. 1999, 2003 Unit 13. The Lightweight Directory Access Protocol (LDAP) 13-1
Student Notebook
Objectives
Describe the basic principles of LDAP

List different LDAP servers
Install and configure the OpenLDAP server
Configure Linux to use LDAP authentication
Notes:

V3.0
Student Notebook
Uempty
What's a Directory?
A "directory" is a listing of information about objects

arranged in some order that gives details about each
object
Directories allow users or applications to find resources
that have the characteristics needed for a particular task
Examples of directories:
City telephone directory
Library card catalog
Figure 13-2. What’s a Directory LX073.2
Notes:
A directory is a listing of information about objects arranged in some order that gives details
about each object. Common examples are a city telephone directory and a library card
catalog. For a telephone directory, the objects listed are people; the names are arranged
alphabetically, and the details given about each person are address and telephone number.
Books in a library card catalog are ordered by author or by title, and information such as the
ISBN number of the book and other publication information is given.
In computer terms, a directory is a specialized database, also called a data repository, that
stores typed and ordered information about objects. A particular directory might list
information about printers (the objects) consisting of typed information such as location (a
formatted character string), speed in pages per minute (numeric), print streams supported
(for example PostScript or ASCII), and so on.
Directories allow users or applications to find resources that have the characteristics
needed for a particular task. For example, a directory of users can be used to look up a
person’s e-mail address or fax number. A directory could be searched to find a nearby
Student Notebook
PostScript color printer. Or a directory of application servers could be searched to find a

server that can access customer billing information.
The terms white pages and yellow pages are sometimes used to describe how a directory
is used. If the name of an object (person, printer) is known, its characteristics (phone
number, pages per minute) can be retrieved. This is similar to looking up a name in the
white pages of a telephone directory. If the name of a particular individual object is not
known, the directory can be searched for a list of objects that meet a certain requirement.
This is like looking up a listing of hairdressers in the yellow pages of a telephone directory.
However, directories stored on a computer are much more flexible than the yellow pages of
a telephone directory because they can usually be searched by specific criteria, not just by
a predefined set of categories.

V3.0
Student Notebook
Uempty
Directories vs. Relational Databases
Directory Relational Database

Examples LDAP, X.500, DB2, Oracle,
Microsoft Active PostgreSQL
Directory
Keyspace Hierarchical Linear
Data Loosely structured Strictly structured
Optimized for Lookups Updates
Security model Simple Complex
Tables One or more, Typically more,
unrelated related
Atomic transactions No Yes
possible?
Replication between Easy because Hard: inconsistency
systems inconsistency is not allowed
(temporarily) allowed
Way of accessing Simplified and Structured Query
information optimized access Language (SQL)
protocol (LDAP)
Figure 13-3. Directories vs. Relational Databases LX073.2
Notes:
A directory is often described as a database, but it is a specialized database that has
characteristics that set it apart from general purpose relational databases. One special
characteristic of directories is that they are accessed (read or searched) much more often
than they are updated (written). Hundreds of people might look up an individual’s phone
number, or thousands of print clients might look up the characteristics of a particular printer.
But the phone number or printer characteristics rarely change.
Because directories must be able to support high volumes of read requests, they are
typically optimized for read access. Write access might be limited to system administrators
or to the owner of each piece of information. A general purpose database, on the other,
hand needs to support applications such as airline reservation and banking with high
update volumes.
Because directories are meant to store relatively static information and are optimized for
that purpose, they are not appropriate for storing information that changes rapidly. For
example, the number of jobs currently in a print queue probably should not be stored in the
Student Notebook
directory entry for a printer because that information would have to be updated frequently
to be accurate. Instead, the directory entry for the printer could contain the network address
of a print server. The print server could be queried to learn the current queue length if
desired. The information in the directory (the print server address) is static, whereas the
number of jobs in the print queue is dynamic.
Another important difference between directories and general purpose databases is that
directories may not support transactions (some vendor implementations, however, do).
Transactions are all-or-nothing operations that must be completed in total or not at all. For
example, when transferring money from one bank account to another, the money must be
debited from one account and credited to the other account in a single transaction. If only
half of this transaction completes or someone accesses the accounts while the money is in
transit, the accounts will not balance. General-purpose databases usually support such
transactions, which complicates their implementation.
Because directories deal mostly with read requests, the complexities of transactions can be
avoided. If two people exchange offices, both of their directory entries need to be updated
with new phone numbers, office locations, and so on. If one directory entry is updated, and
then other directory entry is updated there is a brief period during which the directory will
show that both people have the same phone number. Because updates are relatively rare,
such anomalies are considered acceptable.
The type of information stored in a directory usually does not require strict consistency. It
might be acceptable if information such as a telephone number is temporarily out of date.
Because directories are not transactional, it is not a good idea to use them to store
information sensitive to inconsistencies, like bank account balances.
Because general-purpose databases must support arbitrary applications such as banking
and inventory control, they allow arbitrary collections of data to be stored. Directories may
be limited in the type of data they allow to be stored (although the architecture does not
impose such a limitation). For example, a directory specialized for customer contact
information might be limited to storing only personal information such as names,
addresses, and phone numbers. If a directory is extensible, it can be configured to store a
variety of types of information, making it more useful to a variety of programs. Another
important difference between a directory and a general-purpose database is in the way
information can be accessed. Most databases support a standardized, very powerful
access method called Structured Query Language (SQL). SQL allows complex update and
query functions at the cost of program size and application complexity. LDAP directories,
on the other hand, use a simplified and optimized access protocol that can be used in slim
and relatively simple applications.
Because directories are not intended to provide as many functions as general-purpose
databases, they can be optimized to economically provide more applications with rapid
access to directory data in large distributed environments. Because the intended use of
directories is restricted to a read-mostly, nontransactional environment, both the directory
client and directory server can be simplified and optimized.

V3.0
Student Notebook
Uempty
LDAP Concepts (1)
LDAP objects are described using attributes

e.g. telephonenumber=838-6004
All objects in an LDAP database have required and
optional attributes, this is described in the "Schema"
The "Distinguished Name" (DN) is the combination of
attributes which uniquely identifies an object in the
database (key)
Typically: Base DN + one additional attribute
e.g. C=US, O=IBM, OU=IT Education Services,
CN=John Smith
The "Base DN" is the combination of attributes which
identifies the LDAP directory itself
e.g. C=US, O=IBM, OU=IT Education Services
Figure 13-4. LDAP Concepts (1) LX073.2
Notes:
At the heart of the LDAP definitions is the notion of “object”. An object is a single entry in
the LDAP directory. It typically has a number of attributes, such as the name, the address
or the telephone number.
All objects in an LDAP directory are of a specific object class, which is described in the
directory schema. Among other things, the schema describes the required and optional
attributes of an object, and describes the syntax of each attribute.
As an example, a “person” object is required to have a name, while a “car” object will be
required to have a license plate number. And both a “person” object and a “company”
object may have a telephone number, while a “car” object may not.
The definition of a telephone number attribute is also part of the schema. A typical
telephone number will consists of a number of digits, optionally separated with dashes,
brackets, slashes and spaces. But the dashes, brackets, slashes and spaces are not
relevant: The telephone number “345-5412” is considered equal to “(345) 54 12”.
Student Notebook
A “Distinguished Name” (DN) refers to a combination of attributes that uniquely identify a

directory or an object in that directory. When a DN refers to a directory, we typically call this
a “Base DN”. All objects in that directory will typically have the Base DN in common, and
will have one additional attribute, often the Common Name or CN, which uniquely identifies
the object in the database. In other words: the DN of an object in a directory is typically the
Base DN of the directory plus one additional attribute, most often the Common Name.

V3.0
Student Notebook
Uempty
LDAP Concepts (2)
(Directory Root)
C=US C=CA C=NL
O=IBM O=IBM O=IBM
OU=IT Education Services

Root DN: OU=IT Education Services, O=IBM, C=US
DN: CN=John Smith, OU=IT Education Services, O=IBM, C=US

CN: John Smith
OU: IT Education Services
O: IBM
C: US
SN: Smith
Givenname: John
UID: jsmith
telephonenumber: 838-6004
Figure 13-5. LDAP Concepts (2) LX073.2
Notes:
LDAP directories typically have a globally unique Base DN. This makes it possible to
incorporate a large number of LDAP directories into a global, hierarchical structure not
unlike the global DNS system. In practice, such a global system does not exist, although
several global organizations (including IBM) have created their own internal hierarchical
structure.
The visual shows an example of such a global structure: Like DNS, there is a global root
directory which knows how to find the directories for each country. Every country directory
will know each organization in that country, and each organization knows each organization
unit. In the example above, up to here the complete structure is virtual.
There is an LDAP directory however, whose Base DN is “ou=IT Education Services,
O=IBM, C=US”. This LDAP directory contains one object, whose DN is “CN=John Smith,
OU=IT Education Services, O=IBM, C=US”. Apart from the attributes that make up the DN,
the object also defines a number of other attributes such as SN (Surname), Given name,
UID (User ID) and telephone number.
Student Notebook
As said, the global structure typically does not exist. This means that organizations don’t
have to conform to global naming conventions. However, to avoid problems in the future,
most organizations set their Base DN to something that can be derived from the actual
DNS name of that organization (which is, after all, globally unique). IBM for instance could
use the following Base DNs: “cn=ibm,cn=com” instead of “C=US,O=IBM”.

V3.0
Student Notebook
Uempty
The "Core" Schema
Set of schema defined in various RFCs

Form the default building blocks of an LDAP directory
Attributes defined:
cn: Common name
sn: Surname
c: Country
...
ObjectClasses defined:
country
organization
person
organizationalPerson
...
Defines required/optional attributes for each ObjectClass
Figure 13-6. The “Core” Schema LX073.2
Notes:
As part of the LDAP protocol definition, a set of schema was also defined that could be
used by LDAP implementations. These standard schema, although not required, have
gained widespread acceptance. Most organizations either only use the standard schema,
or use the standard schema as a basis to add their own attributes and object classes to.
This means that most LDAP implementations will be compatible with each other.
The core schema define a large number of attributes, such as common name, surname,
country, telephone number and so forth. With these attributes, the schema also define a
large number of object classes such as country, organization, person,
organizationalPerson and so forth. For each object class, the schema also specifies which
attributes are required and optional.
Student Notebook
LDAP Authentication
While connecting to an LDAP server ("binding"),

authentication is performed against the LDAP directory
Three methods:
No authentication
Basic authentication
DN/Password
Simple Authentication and Security Layer (SASL)
Framework for adding additional authentication
mechanisms
Typically uses SSL/TLS
Figure 13-7. LDAP Servers LX073.2
Notes:
LDAP has a built-in security mechanism, which allows you to identify which users have
which access to which part of your directory. The first step in this security mechanism is
authentication: establishing the fact that the client really is who it pretends to be.
Authentication is a mandatory phase in the establishment of a connection to an LDAP
server, otherwise known as “binding”.
There are three methods defined for authentication:
• No authentication. This “mechanism” is used to give every user access to public
information.
• Basic authentication. With this mechanism, the LDAP client needs to supply the DN of
an object in the directory and the corresponding password. Authentication is performed
by checking the password.
The password that is supplied can either be sent in plaintext (or a plaintext equivalent
called base64 encoding), or encrypted. The latter is not supported by all
implementations though, and the encryption is the same every time the bind operation

V3.0
Student Notebook
Uempty is performed. This means that if a hacker was able to sniff the LDAP connection once,
he can use the captured data to authenticate as the unsuspecting user every time over
and over again.
• The Simple Authentication and Security Layer (SASL). This is not an authentication
method, but a framework for incorporating other authentication methods into LDAP.
Vendors are free to implement their own mechanisms.
Within Linux, the most often used authentication method under SASL is SSL/TLS. SSL
(Secure Sockets Layer) was invented by Netscape as a generic way of encrypting and
authentication arbitrary TCP sessions. Netscape used (and still uses) this as part of the
“https” protocol, which is HTTP over SSL. SSL version 3 with minor modifications
became an Internet standard and was renamed to TLS (Transport Layer Security).
Because of the complexities involved in configuring SASL and the fact that it is not needed
to allow you to use LDAP for UNIX authentication, we’re not going to explore this further in
this unit.
Student Notebook
LDAP Servers
OpenLDAP
Open-Source implementation
Default LDAP server in Linux
IBM SecureWay Directory
Used within the IBM intranet to power the "Bluepages"
Lotus Domino (*)
Microsoft Active Directory (*)
Novell Directory Services (NDS) (*)
iPlanet Directory Server (formerly known as Netscape
Directory Server)
(*): Proprietary directories with an LDAP interface

Figure 13-8. LDAP Servers LX073.2
Notes:
A large number of implementations for LDAP exist:
The implementation we will be using in this course is OpenLDAP, the default open source
LDAP server in most Linux distributions.
IBM’s implementation is the “IBM SecureWay Directory”. This application is used for
instance to power IBM’s “Bluepages”, a worldwide directory of all IBM personnel and
contractors, which is used by a very large number of internal IBM applications.
iPlanet Directory Server (formerly known as Netscape Directory Server) is Netscape’s
implementation of an LDAP server. Apart from the regular name/e-mail address, the
schema used in this LDAP server allow a user to store a “roaming profile” in the directory
as well. When set up correctly, this means that a Netscape user will always use the same
bookmarks, no matter which client he or she uses.
Lotus Domino, Novell Directory Services and Microsoft Active Directory are all proprietary
implementations of a directory, each fulfilling a specific function in the corresponding

V3.0
Student Notebook
Uempty application. Due to popular demand, these directories typically received an LDAP interface
as an extra method of gaining access to the directory.
Student Notebook
LDAP Clients for Linux
OpenLDAP
Suite of standard LDAP client tools: ldapadd,
ldapmodify, ...
gq: Graphical LDAP client
Not included in Red Hat 8.0+ anymore
netscape: Supports the ldap:// URL
nss_ldap: Set of libraries and PAM modules to use
LDAP for UNIX user authentication (like NIS)
auth_ldap: Set of modules to use LDAP for Apache user
authentication
Figure 13-9. LDAP Clients for Linux LX073.2
Notes:
There are numerous LDAP clients, since LDAP client support is built into numerous
applications. The visual lists the more important clients that you might come across on a
Linux system:
OpenLDAP is not only an LDAP server for Linux, but it also includes a number of standard
client tools for accessing and managing LDAP servers. These tools are ldapadd,
ldapmodify, ldapdelete, ldapsearch and ldapmodrdn.
gq is a graphical client to access and manage an LDAP directory. It is far easier to use than
the OpenLDAP tools, but not scriptable. Unfortunately, gq is not entirely stable. That’s why
Red Hat stopped shipping gq, starting with Red Hat 8.0.
netscape supports the ldap:// URL notation, and thus can give you read access to an
LDAP directory.
nss_ldap is a set of libraries and PAM modules that allow you to use an LDAP directory for
UNIX user authentication, provided that the LDAP directory uses the correct schema for
this.

V3.0
Student Notebook
Uempty auth_ldap is a set of modules for Apache that allow you to use LDAP for Apache
authentication.
Student Notebook
Using LDAP for UNIX User Authentication
1. Configure OpenLDAP server

2. Convert /etc/passwd etc. to LDAP database
3. Check with regular LDAP clients
4. Integrate with authentication subsystem
Figure 13-10. Using LDAP for UNIX User Authentication LX073.2
Notes:
In the rest of this unit, we’re going to use LDAP for UNIX user authentication. The visual
lists the steps that are required to implement this.
First, we’re going to configure the OpenLDAP server. This comprises of identifying the
Base DN for the server, and the directories that this server is going to serve.
Second, we’re going to convert the current /etc/passwd, /etc/shadow and other files into an
LDAP directory. For this, a set of migration scripts is available which makes this easy.
Then, we’re going to check the LDAP directory using the regular LDAP client tools. This
allows us to verify whether steps one and two were performed properly.
Last, we’re going to integrate LDAP authentication into our authentication subsystem.

V3.0
Student Notebook
Uempty
The OpenLDAP Server
OpenLDAP Servers:
slapd: Service daemon
slurpd: Replication daemon
slapd configuration file: /etc/openldap/slapd.conf
Schema to use (stored in /etc/openldap/schema)
Backend database to use
Base DN of directory
Root DN and password of directory
slurpd configuration file: /etc/openldap/slapd.conf
Replica information
Figure 13-11. The OpenLDAP Server LX073.2
Notes:
The OpenLDAP servers in reality consists of two servers: The slapd, which serves LDAP
requests from LDAP clients, and the slurpd, which replicates the LDAP directories
between master and slave servers.
Both daemons use the same configuration file: /etc/openldap/slapd.conf. The slapd uses
the configuration file to:
• Determine which schema to use. Schema are typically stored in /etc/openldap/schema.
• Determine what backend database to use. The most often used backend database is
LDBM, which is a derivative of a standard BSD UNIX database format called DBM.
• Determine the Base Distinguished Name of the directories. Remember: the Base DN is
the part of the DN that all objects in the directory have in common.
• Determine the Root Distinguished Name of the directories. The Root DN is the object in
the database who manages the database. It can be compared with the root account of a
UNIX system.
The slurpd daemon uses the slapd.conf file to obtain replication information.
Student Notebook
/etc/openldap/slapd.conf
# /etc/openldap/slapd.conf
#
# See slapd.conf(5) for details
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/inetorgperson.schema
...
# Replication log
# replogfile /var/lib/ldap/master-slapd.replog
...
database ldbm
suffix "ou=Learning Services,o=IBM,c=US"
rootdn "cn=Manager,ou=Learning Services,o=IBM,c=US"
rootpw {crypt}ijFYNcSNctBYg
directory /var/lib/ldap
index objectClass,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
# replica ldap-1.example.com:389 tls=yes ...
Figure 13-12. /etc/openldap/slapd.conf LX073.2
Notes:
The visual lists an excerpt of an example slapd.conf file. Because of visual size constraints,
only the most important lines are listed.
The file starts off with a general section, which lists the schema to include, where to store
the replication log and a few other general configuration items. Then, each individual
directory is configured.
In this case, a directory with a backend database type of LDBM is defined. The suffix lists
the Base DN of the directory, and the rootdn and rootpw identify the Root DN and its
password. The directory lists the UNIX directory where the actual files are stored, and the
index keywork lists the indices to create and maintain. An index is needed for every
attribute where you will want to search on.
Commented out in the file are the replogfile and replica lines. These are needed for
replication, which will be covered later.
For detailed information on the slapd.conf file take a look at the manual page for
slapd.conf.

V3.0
Student Notebook
Uempty
Converting UNIX Authentication Info
Done using a set of conversion tools from www.padl.com

Typically stored in /usr/share/openldap/migration
SuSE does not include these scripts - need to
download and install manually
Edit migrate_common.ph first
Change $DEFAULT_MAIL_DOMAIN and
$DEFAULT_BASE
Run migrate_all_offline.sh
Might need to touch /etc/netgroup
Might need to comment out some entries in
/etc/protocols and /etc/services
All LDAP files are now in /var/lib/ldap
Might need to chown ldap.ldap /var/lib/ldap
Figure 13-13. Converting UNIX Authentication Info LX073.2
Notes:
Converting existing UNIX authentication information into LDAP directories is a daunting
task. Fortunately you can find a set of migration scripts at http://www.padl.com. These
scripts use predefined schema to convert a large number of configuration files
(/etc/passwd, /etc/group, /etc/hosts, /etc/services, ...) on your local system into LDIF files1,
which are then imported into the LDAP directories. Red Hat includes these scripts into its
distribution, but SuSE does not. That means that on a SuSE system you will have to
download and install these scripts yourself.
For these scripts to work properly, you first need to edit the file migrate_common.ph. This
file contains two important variables, $DEFAULT_MAIL_DOMAIN and $DEFAULT_BASE.
$DEFAULT_MAIL_DOMAIN should be set to your domainname used in your email
addresses. This typically will be something like “ibm.com”.
$DEFAULT_BASE should be set to the Base DN of your directory. As discussed earlier,
the Base DN of your directory should ideally be globally unique. If you actually are part of a
global hierarchy of LDAP directories then your Base DN will typically be something like
1
LDAP Data Interchange Format: A standard way of putting LDAP data into an ASCII file.
Student Notebook
“C=US, O=IBM”. However, most LDAP directories are not part of a global hierarchy. In
order to be globally unique, you could set your Base DN to something that is derived from
your (globally unique) DNS name, such as “dc=ibm,dc=com”.
After changing the migrate_common.ph file, you should run the migrate_all_offline.sh
script. This script does the following:
• It migrates all configuration files (/etc/passwd, /etc/shadow, ...) to LDIF format and
stores the resulting LDIF file in /tmp.
• It imports the LDIF file directly into OpenLDAP-readable files in /var/lib/ldap, using the
slapadd command.
• It deletes the LDIF file.
It is vitally important that the OpenLDAP server is NOT running while this script runs. (If you
need the OpenLDAP server running while the conversion is going on, try the
migrate_all_online.sh script, which uses ldapadd instead of slapadd to add all objects.
This however is a lot slower.)
When running the migrate_all_offline.sh script, there will be a few error messages. This
has to do with the script not being able to handle missing files correctly, or not being able to
handle unexpected characters in files correctly. In practice, things will go wrong with a lot of
files:
• The file /etc/netgroup does not exist by default. You therefore need to create an empty
/etc/netgroup file with the command touch /etc/netgroup.
• The files /etc/protocols and /etc/services contain protocols and services which have a
plus sign (+) or other illegal in their name. The conversion scripts are not able to handle
this correctly, and since the protocols and services involved are only used rarely, it’s
best to comment these out.
• The /etc/services contains duplicate protocols and names, and, in case of SuSE,
protocols that are associated with a range instead of a single port number.
When the script has finished (this might take several minutes), all files will be stored in
/var/lib/ldap. However, since the script was run by the root user, all files are owned by root
as well. But the LDAP server runs as user ldap, so the last thing to do is chown -R
ldap.ldap /var/lib/ldap.

V3.0
Student Notebook
Uempty
Start and Test OpenLDAP Server
/etc/init.d/ldap start
Check /var/log/messages for startup errors
Configure and use gq to browse the LDAP server
Figure 13-14. Start and Test OpenLDAP Server LX073.2
Notes:
When the files have been converted, you can start the server. After starting, check
/var/log/messages for any startup errors.
When the server seems to be running, you can try to access the LDAP database with any
client tool. The easiest tool to use is gq. After starting, go to the Browse tab and
double-click on “localhost”. This contacts the LDAP server at localhost and will show a list
of Base DNs of your local server (this might take a few seconds). After gq has gotten the
list of Base DNs (in our case only one), you can click on any of them to see the hierarchy
inside.
Note that by default, the migration scripts from www.padl.com use the OU (Organization
Unit) attribute to denote the sort of information stored. This may look strange at first, but is
actually standard.
Student Notebook
OpenLDAP Client Tools
ldapadd
ldapmodify
ldapsearch
ldapdelete
ldappasswd
Common configuration file: ldap.conf:
#
# LDAP Defaults
#
HOST 127.0.0.1
BASE dc=ibm,dc=com
Figure 13-15. OpenLDAP Client Tools LX073.2
Notes:
Instead of using gq, you could also use the tools that are part of the OpenLDAP project.
The advantage of them over gq is that they can be scripted, but the disadvantage is that
the typical argument list is fairly long, since in most cases you will need to include complete
Distinguished Names.
Before using these commands, you need to modify their common configuration file,
ldap.conf. This file contains the LDAP hostname or IP address, and the Base DN of the
LDAP server.
The input and output of some of these commands are files in LDIF (LDAP Data
Interchange Format). This makes it possible to export and import data from one LDAP
directory into another.
If you are serious about using these commands, consult their manual pages.

V3.0
Student Notebook
Uempty
Configuring UNIX Authentication via LDAP
Requires extensive changes to PAM and NSS

subsystems
/etc/pam.d/*
/etc/nsswitch.conf
/etc/ldap.conf
/etc/ldap.secret
Best done during installation or with dedicated distribution
tools such as authconfig (Red Hat) or yast (SuSE)
Figure 13-16. Configure UNIX Authentication via LDAP LX073.2
Notes:
Configuring our authentication subsystem to use an LDAP server for authentication is not a
trivial undertaking, since it requires modification to no less than four files:
The /etc/pam.d/system-auth (or various other files in /etc/pam.d, if these files do not
include system-auth by default) need to be changed so that when authentication is
required, the pam_ldap.so module is called too, in addition to or instead of other PAM
modules such as pam_unix.so.
The /etc/nsswitch.conf file needs to be changed so that the NSS subsystem knows that
LDAP is being used for authentication.
The /etc/ldap.conf file needs to be created. This file is used by the pam_ldap.so module
(Red Hat) or pam_unix2.so (SuSE) to determine the LDAP server to use, and its Base DN.
The /etc/ldap.secret file needs to be created with permissions rwx------. This file contains
the password of the Root DN of the LDAP server. It is used gain access to the LDAP server
when a user wants to change his/her password.
Student Notebook
These changes are very complicated and it’s therefore best if you let a tool like Red Hats
authconfig take care of this. There is one exception: If you want users to be able to
change their passwords, you need to change the files /etc/ldap.conf and /etc/ldap.secret
manually:
• In /etc/ldap.conf, add the following line:
rootbinddn cn=Manager, dc=ibm, dc=com
• In /etc/ldap.secret, store the password of the Root DN:
secret
Make sure that this file is read-write by root only: chmod 0600 /etc/ldap.secret
Note that this needs to be done on every client system that makes use of LDAP
authentication.

V3.0
Student Notebook
Uempty
LDAP Replication
First copy all files in /var/lib/ldap to slaves manually

Updates on master propagated by the slurpd daemon
Uses in-band transfers (regular LDAP updates)
Requires the following in the master slapd.conf:
# General section
replogfile /var/lib/ldap/master-slapd.replog
# Directory section
replica host=ldap-slave.ibm.com:389
bindmethod=simple
binddn="cn=Manager,dc=ibm,dc=com"
credentials=secret
Requires the following in the slave slapd.conf:
# Directory section
updatedn "cn=Manager,dc=ibm,dc=com"
updateref ldap://ldap-master.ibm.com
Figure 13-17. LDAP Replication LX073.2
Notes:
LDAP replication is fairly simple to set up, provided that your master LDAP server is
running correctly, because LDAP replication uses in-band transport of updates. This means
that the master LDAP server creates a local file in which it stores all updates that were
performed on the master server. The file is in a format which looks very much like the input
format of the ldapmodify command. The slurpd daemon on the master server opens an
LDAP connection to each slave server and simply sends the contents of the file over. All
slave servers then apply these changes to their internal database.
For this to work, some things need to be set up though:
First you need to manually copy over all the contents of the /var/lib/ldap directory from the
master server to the slave server. The LDAP replication only handles incremental updates.
Second, the master server needs some configuration file changes:
• The replogfile directive identifies the file were the replication log is going to be written
(by slapd) and read (by slurpd).
Student Notebook
• The replica directive identifies the slave server for this directory, and with which
credentials the master server should contact the slave server.
Third, the slave server needs to know which Distinguished Names are granted access to
update the directory. This is typically done with the updatedn directive, although it is
possible to set up more complex schemes.
The last thing to do is ensure that a client is always referred to the master LDAP server to
perform an update. This is done with the updateref directive on the slave server.
When a change is made to the master LDAP directory, the slurpd on the master contacts
each slave in turn. It “binds” to the slave LDAP server daemon with the credentials found in
the slapd.conf file. The slave server has to be configured so that these credentials really
allow updates. This can generally be done in two ways:
• By letting the master LDAP server bind to the slave as Root DN. This is by far the
easiest, but you run the risk of accidently binding from a client to the slave server as
Root DN, instead of binding to the master server, and thus making an update to the
slave server which is never replicated to other servers, and which might much later be
overwritten by another update from the master server.
• By letting the master LDAP server bind to the slave as a regular DN. This DN has to
exist in the LDAP database though, to be able to verify the credentials (password). This
is typically done by adding a special UNIX user account for the purpose.

V3.0
Student Notebook
Uempty
Troubleshooting LDAP
Check logfiles /var/log/messages

Most commands support the -d <debuglevel> option
Are you bound with the right credentials (Root DN)?
Check permissions of files read by slapd/slurpd
Connect to server using different clients
Check DNS (forward and reverse lookups)
Check documentation/mailinglists at
http://www.openldap.org
Figure 13-18. Troubleshooting LDAP LX073.2
Notes:
Troubleshooting LDAP is not unlike troubleshooting other TCP/IP services. One special
thing to check is whether you are bound to the server with the right credentials.
If things don’t work out, check the mailing lists and documentation at
http://www.openldap.org.
Student Notebook
Checkpoint
1. Name at least three differences between a directory and

a relational database.
2. T/F A DN of an object must be the Base DN of the
directory and exactly one additional attribute.
3. What is defined in a schema?
4. What are the four steps required to implement LDAP
authentication on a UNIX system?
5. T/F If you want to change something in an LDAP
directory, you can send the change to a slave server
who will then forward this to the master server.
Notes:
Write your answers here:
1. Differences
a.
b.
c.
2.
3.
4. Steps:
a.
b.
c.
d.
5.

V3.0
Student Notebook
Uempty
Unit Summary
LDAP is a standard for accessing directory information

An LDAP schema defines the object classes that are part
of a directory, the attributes that each object should and
may contain, and the syntax of each of these attributes
Special schema exist to implement UNIX authentication
via LDAP
OpenLDAP is the default LDAP server on Linux
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 14. The Network Time Protocol (NTP)

This unit will cover the Network Time Protocol, a protocol that will keep
your system running at the correct time.

• Discuss the need for correct time on all machines
• Discuss the sources of time
• Discuss the NTP protocol
• Describe the various ways of communication in the NTP protocol
• Configure an NTP system

Accountability:
• Checkpoint Questions
© Copyright IBM Corp. 1999, 2003 Unit 14. The Network Time Protocol (NTP) 14-1
Student Notebook
Objectives
Discuss the need for correct time on all machines

Discuss the sources of time
Discuss the NTP protocol
Describe the various ways of communication in the NTP
protocol
Configure an NTP system
Notes:

V3.0
Student Notebook
Uempty
Why Time Synchronization
DHCP lease times

Kerberos tickets
Logfile synchronization
Bug tracking
Network monitoring
Figure 14-2. Why Time Synchronization LX073.2
Notes:
On a standalone system keeping the correct time is not all that important. The only minor
problem you will encounter is that all your documents are saved with the wrong time. If the
time is off by a day or more, this might cause problems when trying to retrieve that
particular document you wrote on that particular day. But in general, it is not a problem.
Having the correct time on your system becomes important in a networked environment
though. Sometimes it is just convenient or polite to have the correct time on your system.
Think for instance about timestamps on email messages: It wouldn't do to send a message
to someone with a timestamp in the future... But for certain applications, having the correct
time is really useful or even mandatory. Here are a few examples:
• DHCP lease times are not transferred as absolute time but merely as offsets from
"now". Nevertheless, if a client reports that it may lease an IP address until 6 pm and
the server reports that the lease expires at 4 pm, you might not suspect initially that the
clients clock is simply two hours off.
• Kerberos, an authentication mechanism, works with so-called tickets which are issued
by a ticket server, and who typically are only valid 10 minutes or so. These tickets are
Student Notebook
used to authenticate you on any server in the network, but if your time is more than 10
minutes off, your ticket is expired before you even receive it.
• If you are involved in tracing back what happened on a network and need to look at
logfiles of multiple systems, you will have a hard time understanding the sequence of
events unless the time on these machines is synchronized to the second.
Setting the correct time can be as easy as taking a wristwatch and setting the time on each
system in your network to the time displayed on the wristwatch. In general, accuracy up to
a few seconds can be achieved with this, provided that this procedure is repeated every
now and then. (PC clocks are not very reliable and can easily run a few seconds fast or
slow in 24 hours.) But for more precise timekeeping, some sort of automated system is
needed. That's what NTP is for.

V3.0
Student Notebook
Uempty
The Network Time Protocol (NTP)
RFC 1129
Synchronizes time between systems
µsec precision
Figure 14-3. The Network Time Protocol LX073.2
Notes:
The Network Time Protocol (NTP) is an Internet standard protocol which synchronizes time
between systems on a TCP/IP network. Depending on circumstances, the precision is in
the microsecond range (one millionth of a second).
Student Notebook
Sources of Time
Directly connected atomic clock

Highest precision but really expensive
Radio Time Receiver
Receivers fairly expensive
Precise
Global Positioning System (GPS) Satellite Receiver
Cheap
Reception problem: does not work indoors
Another NTP server
Adds incremental error
Internal PC clock
Useful if no other sources are available
Figure 14-4. Sources of Time LX073.2
Notes:
Keeping accurate track of the correct time has been a problem for many centuries. As it
turns out, the rotation speed of the earth is not constant enough to rely on, so people have
used stellar observations, moon phases and even witchcraft to track the current time.
Recently, atomic clocks have been introduced which measure time by measuring the
natural resonance frequency of a single Cesium-atom (9,192,631,770 Hz). These systems
are off by less than a second in a million years. For an example of such a clock see
http://www.boulder.nist.gov/timefreq/cesium/fountain.htm.
Obviously it would be ridiculous as an individual to go out and buy such an atomic clock
and connect it to your PC. That's why various state-sponsored organizations with an atomic
clock have connected transmitters to their clock and broadcast the correct time to anyone
interested. By connecting a (still fairly expensive) receiver to your computer, you can
synchronize your computer to the atomic clock of that organization. This method is really
precise, since the source of the signal is well-known and the distance can easily be
measured.

V3.0
Student Notebook
Uempty Another, more recent method is by using the signal from Global Positioning System (GPS)
satellites to measure the correct time. Each GPS has its own atomic clock on board which
it uses to send the correct time and its current position to earth. By tracking four or more
satellites and measuring the differences in received time you can work out the exact time
and the exact position of the receiver. GPS receivers have become mainstream devices
and reasonably cheap: US$ 150 or less. Most GPS receivers can be connected to a PC
using the serial port and thus can become a cheap source of correct time. One
disadvantage of GPS is that the signals don't pass through buildings, so you have to place
your receiver near a window, or have to buy an extra antenna.
Once you've got one system which is set to the correct time, you can use the NTP protocol
to transfer this time to other clients. Note however that each communication link, because
of variations in latency and bandwidth, adds a little error. This is normally countered by
using multiple servers. Various public NTP servers on the Internet exist which can be used.
As a last resort, if no other means are available, you can connect your NTP server to the
local clock of your system. This is useful if you are on an isolated network and don't want to
invest in radio and/or GPS receivers, but keeping time synchronized between the systems
is nevertheless necessary.
Student Notebook
Stratum
The stratum number identifies how far you are from the
time source.
The maximum stratum is 15
sender
receiver "stratum 0"
time server "stratum 1"
time server time server "stratum 2"
time client time client time client "stratum 3"

Figure 14-5. Stratum LX073.2
Notes:
The stratum number is the number of hops you are away from the correct time. For the
purpose of NTP, stratum 0 (zero) is defined as the receiver (radio, GPS) itself. Stratum 1 is
the server which connects to this receiver directly, stratum 2 retrieves the time from the
stratum 1 server and so forth.
In NTP, the maximum stratum number is 15.

V3.0
Student Notebook
Uempty
NTP Communications Methods
Unicast
Broadcast using local broadcast address
Multicast using IANA reserved address 224.0.1.1
Figure 14-6. NTP Communication Methods LX073.2
Notes:
All NTP communications are done using UDP/IP, port 123. There are three ways a client
can obtain the time from the server:
• The first method is by starting a unicast connection to the server. In this case the server
is passive: it waits for clients to contact it.
• The second method is by listening to a broadcast from the server. In this case the
server is active: it periodically broadcasts time information to the local network. The
broadcast address being used is the local broadcast address (the host part of the IP
address is all ones).
• The third method is by listening to a multicast from the server. In this case the server is
again active: it periodically broadcasts time information to the IANA assigned multicast
address 224.0.1.1. If all routers are configured correctly, this ensures that the
information is only sent to the clients who are really interested in time information. And
since multicasts can traverse routers, you have effectively ensured that you only need
one or a few time servers in your network, instead of needing one for every subnet.
Choosing between unicast, broadcast and multicast depends on server capacity, how
important having the correct time is, network utilization and so forth.
Student Notebook
ntp Overview
ntpdate: Retrieves time from NTP server and sets

internal clock (only once)
Run before starting ntpd
ntpd: Synchronizes time with another NTP server
(continuously)
Can act as server and client
Configuration file /etc/ntp.conf
ntpq: Queries a time server
Various other supporting programs
Excellent documentation in /usr/share/doc/ntp-version
Figure 14-7. ntp Overview LX073.2
Notes:
The ntp package implements an NTP time server. The package contains a number of
binary programs, sample configuration files and a lot of documentation, which is normally
stored in /usr/share/doc/ntp-version. The two most important programs are ntpdate and
ntpd.
ntpdate is usually started by hand (although some people run it out of cron). It connects to
a time server, retrieves the correct time, sets the local clock to the correct time and exits.
This provides a lightweight method of setting the time on your system, but after ntpdate is
done, the system essentially runs free again.
ntpd is the NTP daemon, which slaves itself to another time source, continuously
monitoring the other source and adjusting the local time. It can also function as an NTP
server, providing time for other clients. It is configured with the file /etc/ntp.conf.
Important to note is that ntpd won't start if the time difference between itself and the time
server to be used is large. It is therefore common to run ntpdate before starting ntpd. In
fact, most init.d scripts do precisely that.

V3.0
Student Notebook
Uempty ntpq allows you to query another NTP server. Of the 50 or so subcommands, the peers
and rl commands are the most useful. The peers command tells you which servers are
being used by this particular NTP server, and some statistics about these servers, including
stratum, offset and jitter. The rl command shows statistics, including its stratum number, of
the server itself.
Student Notebook
/etc/ntp.conf Configuration File
Configures ntpd daemon

Most common directives:
server <ip address>: Connect to server with lower
stratum
peer <ip address>: Synchronize with peer of equal
stratum
fudge <ip address> <options>: Change parameters
of a server or peer (e.g. stratum)
broadcast <ip address>: Broadcast time to <ip
address> (can also be 224.0.1.1)
broadcastclient: Listen to local broadcast address
multicastclient: Listen to multicast address 224.0.1.1
driftfile <filename>: File where local clock drift is
stored
Figure 14-8. /etc/ntp.conf Configuration File LX073.2
Notes:
The /etc/ntp.conf file configures the ntpd daemon. It usually consists of a few lines only.
The following directives are common:
• server <ip address> identifies the server to connect to for the correct time. The ntpd
daemon also automatically retrieves the stratum number of that server and sets its own
statum number one higher.
• Multiple server statements may be used. If one of the statements has the prefer
keyword, than this server has preference over other servers.
• peer <ip address> identifies a peer server to connect to for the correct time. A peer
server always has the same stratum. If the times on two peers are not the same, the
average is taken.1
• fudge <ip address> <options> will change the parameters of an earlier defined server
or peer. For example, normally a server or peer will automatically transfer its stratum
number to the client, but with the fudge option you can change that stratum number to
something else.
1
Actually, the algorithm is a little more ingenious than this, but the times will slowly converge.

V3.0
Student Notebook
Uempty • broadcast <ip address> will configure this NTP server to broadcast the time to the
specified broadcast address (this should be the local broadcast address) or to the
multicast address 224.0.1.1.
• broadcastclient will configure this NTP client to listen to NTP broadcasts on the local
broadcast address.
• multicastclient will configure this NTP client to listen to NTP multicasts on the
multicast address 224.0.1.1.
• driftfile is the name of the file where the drift of the local clock is stored. This drift is
automatically determined by measuring the adjustments needed to the local clock over
a period of time. In case the NTP server cannot be contacted, the ntpd daemon will
keep applying the same adjustments (taken from the driftfile) to reach a high degree of
precision nevertheless.
Student Notebook
Receiver Pseudo IP Addresses
All supported non-NTP sources of time have a pseudo IP

address 127.127.t.u, where:
t is the clock type
u indicates the connection (such as serial port)
Examples:
server 127.127.1.0: Local PC clock
server 127.127.20.0: GPS receiver conforming to
NMEA protocol on ttyS0
Figure 14-9. Receiver Pseudo IP Addresses LX073.2
Notes:
If you want to receive time from a radio or GPS receiver, there's nothing magic you need to
do. ntpd has support for most receivers built-in. This support is activated by using the
server keyword in the /etc/ntp.conf file with a pseudo-IP address of the form 127.127.t.u.
Such an IP address would normally not be used (technically, it is one of the 16 million
reserved loopback addresses) and can therefore be used within ntpd to address the
receiver.
The value t identifies the clock type, and the value u defines the connection, such as the
serial port to use. The meaning of the value u depends on the clock type.
Two examples are useful:
• server 127.127.1.0 identifies the (first) local PC clock. By connecting to this clock you
will get a free-running NTP server which can be used on an isolated network. The
stratum number obtained when connecting to this address is three instead of one, but
you can change this with the fudge keyword.

V3.0
Student Notebook
Uempty • server 127.127.20.0 identifies a GPS receiver which conforms to the NMEA2 protocol
on ttyS0. (ttyS1 would be 127.127.20.1.) Most GPS receivers support this.
For more examples and the definition of all t and u values, consult the ntp documentation.
2 NMEA: National Marine Electronics Association: An association of manufacturers of marine electronics. The NMEA-0183 standard
describes the output format of GPS receivers, so that this can be used by autopilots and other navigational equipment.
Student Notebook
NTP Authentication
NTP protocol supports authentication

Prevents hackers from simulating a time server with
incorrect time
No replay attacks possible
Not used often
Figure 14-10. NTP Authentication LX073.2
Notes:
Theoretically it is sometimes possible to break into a system by doing a replay attack. An
example of this is by sniffing a Kerberos ticket off the network and later using this ticket to
get into the server again. Kerberos tickets have a typical expiration time of only ten minutes
though, so in order for this to work you need to alter the time on the system you will want to
break in to.
If a server uses NTP to get the time from another system, you might use IP spoofing to set
up your own NTP server in place of that other system and thus be able to alter the time on
the server under attack.
In order to prevent this, the NTP protocol supports authentication. When this is used, it is
virtually impossible to spoof an NTP server. This ensures that you always retrieve the time
from a valid server.
There are only a handful of security protocols dependent on the correct time being set on
each and every machine (Kerberos being one of them), so in most cases replay attacks like
the one mentioned here are not possible. That's why NTP authentication is not used very
often. If you want to set it up though, consult the documentation.

V3.0
Student Notebook
Uempty
Other Useful Commands
date: Show current time

date MMDDhhmmCCYY.ss: Set system time manually
hwclock --show: Show hardware clock
hwclock --systohc: Set hardware clock from system
time
hwclock --hctosys: Set system time from hardware
clock
timeconfig (Red Hat): Update /etc/sysconfig/clock
Figure 14-11. Other Useful Commands LX073.2
Notes:
The date command allows you to retrieve or set the current system time, which is corrected
for the local timezone and Daylight Savings Time, if necessary.
The hwclock command allows you to show and set the hardware clock from the system
time, and vice versa. If you decide to store the hardware clock in UTC (Universal Time
Coordinated, formerly known as GMT), you need to add --utc to all hwclock commands.
timeconfig allows you to set the timezone and whether the hardware clock is in UTC or
not. This information is stored in /etc/sysconfig/clock. Since the /etc/sysconfig/clock file is
Red Hat specific, the timeconfig tool is not available in other distributions, but every
distribution will have its own mechanism for doing the same.
Student Notebook
Checkpoint
1. T/F. A server with a higher stratum has a more

accurate time than a server with a lower stratum.
2. T/F. A system which is not synchronized with the

correct time cannot serve time to other clients.
Notes:
1.
2.

V3.0
Student Notebook
Uempty
Unit Summary
The NTP protocol allows you to synchronize your clock to

the correct time, with microsecond precision
Sources of time that can be used are atomic clocks, radio
clock or GPS receivers, other NTP servers or the local
clock
The stratum number indicates how far you are from the
time source
NTP communications can be done using unicast,
broadcast or multicast
The ntpd daemon and support tools implement the NTP
protocol
The configuration file for ntpd is /etc/ntp.conf
Notes:
Student Notebook

V3.0
Student Notebook
AP Appendix A. Checkpoint Solutions

Unit 1
1. True
2. True
3. b
4. c
5. b
6. network address and local host address
7. True
8. It is the local loopback address used to send messages to itself
9. True
10. To distinguish between multiple processes on the same host
11. False. IP is a connectionless protocol. It guarantees nothing.
Unit 2
1. ping
2. host
3. arp
4. ifconfig
Unit 3
1. telnet
rlogin
rsh (without a command)
2. ftp
rcp
3. rexec
rsh
4. /etc/hosts.equiv
$HOME/.rhosts
5. $HOME/.netrc
© Copyright IBM Corp. 1999, 2003 Appendix A. Checkpoint Solutions A-1

Student Notebook
Unit 4
1. They require plain text passwords to be transferred over the
network.
They allow the user to configure authentication based on source IP
address.
2. By disabling IP based authentication and by using strong
encryption for authentication and data transmission.
3. Various, including implementations from http://www.ssh.fi and
//www.openssh.org.
4. Host certificates
user certificates
5. The host public key is transferred the first time a user connects to a
host.
It is used for host authentication, to prevent against a
man-in-the-middle attack.
6. The user public key is transferred when the user wants to and is
used to authenticate a user without a password.
Unit 5
1. a
2. False. It’s the other way around.
3. False. The IP address for each TTY is configured by the system
administrator in /etc/ppp/options.ttyname.
Unit 6
1. b
2. routed, gated
3. ping -R, traceroute
Unit 7
1. d
2. d
3. a
4. False. named only runs on the name servers.
A-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
AP 5. d
6. True
Unit 8
1. b
2. d MAIL. HELO and EHLO identify the client and server; DATA
starts message transfer; RCPT identifies one recipient.
3. True
4. d
5. Received
6. False. POP is used only for receiving incoming mail. Outgoing mail
is sent with the SMTP protocol.
7. SMTP
8. Macro M
9. False. The mailq command lists the mail queue. The queue run is
started by the sendmail -q command.
Unit 9
1. b
2. False
3. News Reader
Unit 10
1. (a), (b), and (d) are correct answers. (c) is incorrect.
(c) is incorrect because PPP does IP address assignment itself.
DHCP is not needed and in fact cannot be used since DHCP only
works on broadcast networks.
(d) is debatable. Assigning static IP addresses to servers can be
done using DHCP (so the answer to the question is yes). The
advantage of this is that if a network needs to be renumbered, all it
takes is a changed /etc/dhcpd.conf file. The disadvantage of this is
that the server is now relying on the DHCP server as well.
2. DHCPDISCOVER
3. DHCPRELEASE

Student Notebook
4. e, f, b, a, d.
Answer (c), DHCPREPLY, is not a proper DHCP message.
Unit 11
1. True
2. True
3. nfsd
4. mount
5. portmap
Unit 12
1. c, a, b
Unit 13
1. True
2. b
3. a
4. False. Maps can only be updated on the master server.
5. a
6. True
Unit 14
1. Hierarchical vs. flat keyspace, read-mostly vs. write-mostly, one
table vs. multiple related tables, variable number vs. fixed number
of attributes, complex vs. simple security model, no support vs.
support for transactions
2. False. Sometimes the DN of an object requires more than one
attributes in addition to the Base DN to make it unique. Consider
for instance the example where you have a Base DN of “O=IBM,
C=US”, and OUs “People” and “Equipment”. The DN of an object
would then be “CN=Printer, OU=Equipment, O=IBM, C=US”.
3. The format of the attributes and the required and possible
attributes for objects.

V3.0
Student Notebook
AP 4. Configure LDAP server; migrate authentication information; Start

server and test; Migrate UNIX authentication subsystem.
5. False. If you want to make a change, then you are referred to the
master server by the slave server.
Unit 15
1. False. The lower the stratum (number) is, the more accurate the
system is.
2. False. It can but all other clients will have the same incorrect time.
This can be useful in an isolated network which nevertheless has
the need to synchronize clocks.

Student Notebook

V3.0
Student Notebook
AP Appendix B. Certification Information

As mentioned in this course, Linux is not a product which is owned by a single company.
Instead, it is developed by a loose team of volunteers on the Internet. As such, there is no
"natural" body responsible for Linux certification. At this moment, at least four organizations
have tried to fill this void and have come up with their own Linux certification program. IBM
supports three of these organizations:
• The Linux Professional Institute (http://www.lpi.org) is an organization run by
volunteers with the sole purpose of implementing a vendor-neutral certification program
for Linux. They are sponsored by a number of Linux-related companies, among which
IBM. The certification tests are delivered by VUE (Virtual University Enterprises)
(http://www.vue.com). LPI aims to implement three levels of certification, of which the
first two levels are currently ready.
UnitedLinux (the consortium of Linux distributors SuSE, SCO, TurboLinux and
Conectiva, http://www.unitedlinux.com) has announced a UnitedLinux certification,
which will be an extension of the LPI certification.
• CompTIA (http://www.comptia.org) is the organization that has, in the past, already
developed a number of certifications that are aimed mostly at helpdesk personnel and
hardware engineers. Recently CompTIA introduced the Linux+ exam, which is aimed
at Linux Professionals with 6 months of experience with Linux. CompTIA tests are also
delivered by VUE, and by Prometric (http://www.prometric.com).
• Red Hat (http://www.redhat.com) is the distributor of Red Hat Linux, one of the leading
commercial Linux distributions. As part of their service organization they have
developed their own education leading to the Red Hat Certified Technician and Red
Hat Certified Engineer exams. In contrast to the other Linux exams, the RHCT and
RHCE exams are performance based, which means that the examinee takes place
behind an actual Red Hat Linux system and needs to demonstrate his/her skills on this
system. The practical components of the RHCT exam takes about 2.5 hours, while the
practical components of the RHCE exam take about five hours.
For all three certification programs, the support of IBM extends to the following:
1. Involvement and/or active support in developing the certification program, the exam
objectives and test questions.
2. Where appropriate: sponsoring the certification program.
3. Developing courseware and teaching courses to prepare students for certification, and
where possible certifying this course material for the exams involved.
4. Exam delivery.
© Copyright IBM Corp. 1999, 2003 Appendix B. Certification Information B-1

Student Notebook
IBM IT Education Services Courseware

IBM IT Education Services started developing courseware for Linux at the end of 1998,
when no certification programs for Linux existed. The Linux curriculum was heavily
modeled after the AIX curriculum, but has changed since to reflect the different ways Linux
and AIX are being used today. IBM's Linux course material is not tied to any particular
distribution, and is also not tied to any particular certification.
The total curriculum consists of more than fifteen courses that cover the Linux Operating
System, and an even larger number of courses that cover IBM middleware that runs on
Linux (such as DB2, MQSeries, Lotus Domino and so forth) and IBM hardware. For the
purpose of certification though, only seven courses are important:
The LX02 (Linux Power User) is the entry course in the IBM/Linux curriculum. Its aim is to
teach a Linux novice to install and configure Linux so that he/she is able to run Linux on
his/her personal workstation or home system in an environment that is mostly based on
MS-Windows.
The LX03 (Linux System Administration I: Implementation) is the main system
administration course. Its aim is to teach a Linux user the techniques and practices used in
installing, configuring, running and maintaining a Linux-based server.
The LX07 (Linux Network Administration I: TCP/IP and TCP/IP Services) is the main
network administration course. Its aim is to teach a Linux system administrator how to
configure TCP/IP and various TCP/IP services that run on Linux.
The LX22 (Linux Perl Programming) is the course that covers Perl programming.
The LX23 (Linux Bash Programming) is the course that covers Bash shell programming
and the various programs that are typically used in shell programs, such as grep, awk and
sed.
The LX24 (Linux Network Administration II: Network Security and Firewalls) covers
the configuration of a full-function firewall under Linux. As such, it also covers a number of
security aspects of Linux that are not particularly related to firewalls, but apply to any
networked system.
The LX25 (Linux as a Web server - Apache) is the course which covers Apache, the most
commonly used web server on Linux and other UNIX platforms.
The LX26 (Linux integration with Windows - Samba) is the course which covers Samba,
the product which emulates a networked Windows NT server to the network.
All these courses are available from IBM IT Education Services and selected business
partners (pricing and availability may differ from country to country). For information on
pricing and scheduling, contact your local IBM IT Education Services representative.
IBM IT Education Services has developed these courses so that they can be taken in a
logical order. Furthermore, the organization of topics into courses is such that at the end of
a course, a student is able to fully grasp a topic, and is able to apply this successfully on his
Linux system(s).
B-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
AP From Education to Certification

IBM’s arrangements of topics into IBM’s Linux courses is not always consistent with the
requirements of the supported certifications. This leads to a problem when determining
which courses are needed for which certification. A certain test might require "installation
and basic configuration" of a product. This is covered by a certain IBM/Linux course, but
that very same course also covers "advanced configuration", which might be the subject of
an entirely different test.
As an example, IBM has one, two-day course about Samba (the LX26), which fully covers
the whole Samba product and its possibilities. Samba knowledge is tested by the LPI in two
places though: Test 102 (topic 1.13, objective 4) requires the examinee to "install and
configure Samba using the included GUI tools or direct edit of the /etc/smb.conf file" (which
is covered in the first two units of the LX26), while test 201 (topic 2.9, objective 1) requires
that "the candidate should be able to set up a Samba server for various clients, including
setting up a login script and setting up and nmbd WINS server" (which is the end objective
of the LX26).
This problem is too fundamental to solve by simply changing or rearranging the course
material, apart from the fact that we think that it is not desirable to specifically write courses
for certification. One of the purposes of this attachment is therefore to identify the areas
where IBM's course material does not match with certification objectives.
© Copyright IBM Corp. 1999, 2003 Appendix B. Certification Information B-3

Student Notebook
Education/Certification Matrix
The following table lists the required and recommended courses for each of the supported
certification programs:
CompTIA LPI Red Hat
Course
Linux+ Test 101 Test 102 Test 201 Test 202 RHCT RHCE
LX02 Required Required Required Required Required Required Required
LX03 Required Required Required Required Required Required Required
LX07 Required Required Required Required
LX22 Recomm.
LX23 Recomm. Recomm.
LX24 Required Recomm.
LX25 Recomm. Required Recomm.
LX26 Recomm. Required Recomm.
Remarks to the table:
1. Required means: the subjects covered in this course are essential knowledge to pass
the exam.
Recommended means that a small portion of the exam (less than 5%) is covered in the
course listed. It is possible to pass the exam without this knowledge. Students do so
however at their own risk and should compare their knowledge with the exam
objectives.
2. CompTIA Linux+ also requires intimate knowledge of PC hardware in general (Domain
7) which accounts for 19% of the exam. This includes knowledge of the BIOS, IRQs, I/O
ports, DMA, ATA devices, SCSI devices, IEEE 1394 devices, PCMCIA devices, ISA
devices, PCI devices, APM and the ability to configure and replace them, were
applicable. This part of the exam is not related to Linux and thus not covered in any of
IBM’s Linux courses. CompTIAs own education (and other education) that leads to
CompTIA A+ certification may be used to obtain this knowledge.
3. ProCert (http://www.procert.com) has certified these courses as appropriate course
material for preparing for LPI certification tests. This certification is only valid if all
courses, including the courses that are listed here as “recommended” are taken before
attempting an LPI certification test.
4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such
allowed to teach the Red Hat courses RH033, RH133 and RH253. These courses can
be used as an alternative to LX02, LX03 and LX07, respectively, to prepare for
RHCT/RHCE certification. They cannot be used for other certifications though, and
these courses are not scheduled in all countries.
B-4 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
Uempty Appendix C. Usenet News

This unit covers the Usenet News model and the way it is implemented
on Linux, with emphasis on the innd daemon. Popular news user
interfaces such as Evolution are not covered in detail since their use is
quite straightforward.

• Describe the Usenet news model
• Describe the NNTP protocol
• Configure INN for a simple news domain

Accountability:
Certification Information
This unit is required knowledge for LPI exam 202. However,
experience has shown that virtually no students are using or planning
to use Usenet News in their organization. Therefore, this unit has been
moved into an appendix.
© Copyright IBM Corp. 1999, 2003 Appendix C. Usenet News C-1

Student Notebook

'} @*
'@@

@@
*
Figure C-1. Objectives LX073.2
Notes:
C-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

V3.0
Student Notebook
Uempty
3 ' $
@@ @@
@@ @@
@*
*QQ *+ @@
@@ @@
@@
@*Q*

*
Figure C-2. Usenet News Model LX073.2
Notes:
Usenet News is a network of news servers who each carry a large number of newsgroups.
Users connect to one of these news servers to read messages in newsgroups, and to post
new messages. If a new message is posted to a newsgroup, it is replicated over all news
servers that carry that particular newsgroup, so that everybody else in the world can read
that message too.
Both the replication of messages and the client connections to the news servers use the
NNTP protocol.
Every news server is free to contact another news servers administrator in order to obtain a
newsfeed, and every news server is free to decide which newsgroups to carry. News
servers can also create local groups, which are not replicated to other servers.

Student Notebook
''
$
#
} JQ QJQ
@*
@*

@*

Figure C-3. Network News Transfer Protocol LX073.2
Notes:
The NNTP protocol is the protocol used in Usenet news. It is described in RFC 977. It is
used both for client-server interaction (news reading and news posting), and in
server-server interaction (news replicating).

V3.0
Student Notebook
Uempty
' &

*
*
@*

j
*
}J Q@@!*
*Q
QJ
&`

+
@
Figure C-4. News Readers LX073.2
Notes:
News readers are client programs that the user uses to read and post news. They usually
have some sort of menu driven or GUI interface.
Most news readers support threading. With this feature, the articles are not sorted
according to the date and time they were posted, but are sorted by subject. The original
post is on top, with the replies to the original post and the replies to the replies all organized
in a tree-like structure. This makes it easy for users to follow (or ignore) a discussion.
To support threading, a process has to read all headers of all messages in a newsgroup. If
this is done on the client (over an NNTP connection), this can take a lot of time (5 minutes
for 1000 messages is not uncommon). Most news servers and news readers therefore
support server side threading. Here, a process running on the server threads all messages
and stores the thread index in a special file. Clients then retrieve this file and use it to
display all headers in a threaded fashion. (Note that the thread process usually only runs
once an hour, so the latest messages may not be threaded correctly.)

Student Notebook
Various news servers are available under Linux, depending on your distribution:
• rn (read news)
• nn (net news)
• tin (threaded Internet news)
• trn (threaded read news)
• netscape messenger
• knode
• PAN

V3.0
Student Notebook
Uempty
' 4
% *

*
!
!
Q
*

* *
*
#
* *Q

} **+ !*

&`
!
&`

@@ @@*J
Figure C-5. News Servers LX073.2
Notes:
On the server you run a program called a news server. These servers store the messages
on disk, typically in a directory like /var/spool/news/messages/news/group/name. They
then open a TCP port to allow newsreaders to read and post messages, and other news
server to replicate messages.
Other functions of news servers include expiring messages after a number of days, and
threading the messages.
Various news servers exist, but the two best known are:
• nntpd, which is the reference implementation. It works, but is not very efficient.
• inn, which is the most common news server. It deviates very slightly from the NNTP
protocol, but as the authors say: "Not in an easily noticeable way."

Student Notebook
' "

$

K~

K~#
K~%!
*K~' *!
K~ Q *

j
* *

*
Q
*
J

@*

Q

Figure C-6. News Groups LX073.2
Notes:
A newsgroup is a group for the discussion of a specific topic. Thousands of newsgroups
exist, and to be able to manage this, they use an hierarchical structure. Some of the most
well-known top-level groups are:
• comp.*: The subgroups in this course are related to computers and computer networks.
An important subhierarchy is comp.os.linux, which holds all newsgroups that relate to
Linux.
• rec.*: Everything that has to do with recreation.
• soc.*: Everything that relates to society.
• news.*: Everything about the news system itself. Two important groups here are
news.groups, which is for the discussion about new groups, including the voting
announcements for each new group, and news.announce.newsgroups in which newly
formed newsgroups are announced. As an administrator of a Usenet News news
server, you should be subscribed to at least the news.announce newsgroup.

V3.0
Student Notebook
Uempty • alt.*: This is an alternative hierarchy in which the rules for the creation of newsgroups
are not as strict. Among other things, the voting process only takes three days instead
of thirty. This makes it a popular hierarchy to discuss current events.
In addition to this, local sites are free to implement their own newsgroups. They will usually
start with the name of the company as top level newsgroups, with a hierarchical structure
below that for the various topics.
A user can post a message to one newsgroup, but can also post one message to a number
of newsgroups. This is called cross-posting, and is usually frowned upon. Posting to all
newsgroups is called spamming, and is not liked at all.
It is possible to mark a newsgroup as "moderated". In this case, every message that is
posted needs approval from a moderator first. Only if the moderator approves the message
does it get added to the newsgroup. This moderation mechanism is usually used on
.announce newsgroups, which are typically low-traffic groups with hundreds or thousands
of subscribers, and which carry announcements only, no discussions.

Student Notebook
'' ''

***KK
J @*%Q
j `
*
K
@* Q
*

%

"$ *
"
7 * *Q
*
Figure C-7. InterNet News (INN) LX073.2
Notes:
InterNet News is the de facto news server on the Internet. It is written and maintained by
the Internet Software Consortium (http://www.isc.org), and is included in most Linux
distributions.
INN uses two main directory trees:
• /etc/news is used for static configuration files
• /var/spool/news is used for dynamic configuration files (such as the number of
messages in each newsgroup), and for the news messages themselves.
The main daemon of INN is innd. This daemon is supposed to run 24 hours a day. There
are also several support programs available:
• nnrpd is a program that is spawned by innd to handle newsreader connections.
• nntpsend is a program that is called by cron, to gather all the messages that need
sending to another news server.
• innxmit is a program that is called by nntpsend to do the actual transfer of the
messages.
• overchan is called by cron to thread all news messages.

V3.0
Student Notebook
Uempty
*
@@

Q ¥'@
¥'@
' *

" $ *

^@ *
<

%

$&J

!+
Figure C-8. /etc/news/inn.conf LX073.2
Notes:
The main configuration file of INN is /etc/news/inn.conf. It is very large, but in most cases
only a few parameters need to be configured. For all others, the defaults are ok.
The options that need configuring are all listed at the top of the file. Their meaning is as
follows:
• server: The FQDN of the server.
• domain: The FQDN of your domain.
• fromhost: The hostname that shows up in the From: field of every message.
• pathhost: The hostname that shows up in the Path: field of every message.
• organization: The organization name that shows up in the Organization: field.
• mta: Pathname and options of the MTA to use to mail the messages to the moderator, if
necessary.
• moderatormailer: The general email address of the moderator. Note that the email
address of each moderator should be configured for each newsgroup, and this address

Student Notebook
is the fallback address, usually %s@uunet.uu.net, where %s is replaced by the

newsgroup name. uunet.uu.edu is used because they keep aliases for every moderator
of every newsgroup. This saves you from doing a lot of local configuration.
For the meaning of other options, see the manual page of inn.conf.

V3.0
Student Notebook
Uempty
*
'*! +

"$ !
*

*

*

J

|
% J @%jj
&`

"z

C"M`
|
!
Figure C-9. /etc/news/storage.conf LX073.2
Notes:
The amount of traffic that is currently being generated on Usenet News is several
Gigabytes per day. If you are running a server that needs to store this amount of data, and
needs to serve hundreds of clients per day, you will need a fairly fast system, obviously.
However, the way INN stores its data has great impact on performance. Traditionally, news
servers reserve one directory per newsgroup (such as
/var/spool/news/articles/comp/os/linux/announce for the comp.os.linux.announce
newsgroup) and store the articles in that newsgroup as single files in that directory. This
method works fine as long as the number of messages in a newsgroup is not too large
(several hundred active messages at most.) However, most filesystems will run into
performance problems if several thousand files need to be stored in a single directory.
That’s why INN supports a number of other methods of storing articles:
• timehash still stores individual messages in individual files, but spreads the messages
from a single newsgroup out over several directories, based on a hash of the time. This
reduces the strain on the filesystem, because each directory will contain at most a few
hundred messages.

Student Notebook
• timecaf also spreads the messages out over multiple directories per newsgroup, but
also stores multiple messages in a single file.
• cnfs (Cyclic News File System) stores articles sequentially in pre-configured buffer
files. When the end of the buffer is reached, new articles are stored from the beginning
of the buffer, overwriting older articles.
These three methods have great advantages in terms of performance, but all rob you from
the ability to easily dig into the filesystem and remove messages manually. It also removes
the ability of some news readers to access /var/spool/news directly instead of going
through the NNTP protocol to the server.
For more information on the different methods, see the file
/usr/share/doc/inn-version/INSTALL.
After configuring the storage method, you need to create the history information manually.
This is a one-time only job, and requires that you execute the following series of
commands:
# touch /var/lib/news/history
# /usr/lib/news/bin/makedbz -i
# cd /var/lib/news
# mv history.n.dir history.dir
# mv history.n.hash history.hash
# mv history.n.index history.index
# chmod 664 history.*
# chown news.news history.*

V3.0
Student Notebook
Uempty
' "
Q *Q
jQ *
* `
%! `$$
$ ! *

$
*
*

Q * *

j *
*

%! ` "
Figure C-10. Configuring Newsgroups LX073.2
Notes:
When a newsgroup is added, two files need to be updated:
/var/lib/news/active is the list of all active newsgroups. It has four fields: the newsgroup
name, the himark and lomark, and the flags. The himark and the lomark number identify
the highest numbered and the lowest numbered article, respectively. This is important for
performance, and should be updated regularly. (This is done automatically, fortunately.)
The flags indicate whether a user may post or not, or that a group is moderated.
/var/lib/news/newsgroup is again a list of all newsgroups, with a short description as to
their content. This is not required, but users will not see the newsgroup description if this
file is not present, or if the newsgroup is not listed in this file.
Note that you will not need to edit the /var/lib/news/active file if you don't want to: ctlinnd
(discussed later) can do this for you.

Student Notebook
'
* {{Q

<@@Q
< J@@QKK}}
j
KK
* *
*
%! `YZY
ZYZY
Z
%!
"[ *

$
"
*!
Figure C-11. Configuring Newsfeeds LX073.2
Notes:
A news feed is a channel to which all locally posted (and possibly non-local postings as
well) are "fed". Through this channel, the articles are sent to various destinations:
• Other NNTP servers
• Other non-NNTP servers (such as news servers connected through UUCP)
• Local processes, for instance to thread all articles.
Newsfeeds are configured in the /etc/news/newsfeeds file. This file contains all the
information about a newsfeed.

V3.0
Student Notebook
Uempty
''
'
*
K
}!"
* @@
" !
" Q+7
%! `YZY| ZY `£Z¦YZ§
%!
¥'@ *Q
7 ^` Q
7
Figure C-12. Configuring the Outgoing NNTP Newsfeed LX073.2
Notes:
The newsfeed that was configured to send the articles to another news server stores the
references to all articles in a special file. Cron periodically invokes nntpsend, which scans
this file and selects the articles that need to be transferred to another server. It then invokes
innxmit for the actual data transfer.
nntpsend is configured by the /etc/news/nntpsend.ctl file. It lists the symbolic name for the
site (which should correspond to the entry in /etc/news/newsfeeds), the FQDN of the other
news server and a number of parameters that control the behavior of nntpsend and
innxmit.

Student Notebook

5' 5
%QJ **

' !
* *

6# $
% Q
*QQ*
@**
Figure C-13. Configuring the Threading "Newsfeed" LX073.2
Notes:
Another newsfeed is the threading newsfeed. This local process (overchan) receives all
messages and updates the threads file (stored in /var/spool/news/index) to reflect the
current threads.

V3.0
Student Notebook
Uempty
''
'
* K

j *
%! `
YZ¨¦
§KKK©
%!

j¥'@

" j *
*
Figure C-14. Configuring Incoming NNTP Newsfeeds LX073.2
Notes:
We also need to configure the incoming newsfeed. These are all listed in
/etc/news/incoming.conf.

Student Notebook
''
'
*K
j**

*
{
{
{
{
&`

z
M` 7

MQ T 7
|

z

"MQ T 7

C"M`
|
Figure C-15. Configuring NNTP Newsreaders LX073.2
Notes:
In order for newsreaders to have access to this news server we need to configure these as
well. This is done in /etc/news/readers.conf.
The configuration of a group of newsreaders is always split in two: an "auth group", which
establishes authentication (determining that the user is who he says he is), and an "access
group" which establishes authorization (allowing access based on credentials).
The example in the visual configures this for a "local" group. The auth group "local"
determines that if the connection originates from any host in the dom1.ibm.com domain,
then the username is considered to be "<local>@dom1.ibm.com". No further authentication
is necessary. Next comes the access group "local". This access group determines that all
users with username "<local>@dom1.ibm.com" have read and post access to all
newsgroups.

V3.0
Student Notebook
Uempty
97"
! * !* &`

`
*

*`
K
%
`
!
! *
%! `
Y *
ZY ZY+
ZYZY
Z
" j *

$
!}
}
!

" *+

$' *+

"` *+
Figure C-16. Configuring Expiring LX073.2
Notes:
Expiring is really important: The daily amount of traffic for a typical Usenet server may be
several gigabytes. If messages are not expired quickly enough, you may run out of storage
pretty fast. On the other hand, if messages are expired too soon, users will start
complaining.
Any message that is posted to Usenet may set its own Expire: header field. This indicates
the date and time at which the message is supposed to expire. Most news readers do not
do this by default however, and in that case the default settings on the server for that
newsgroup are used.
The expiry times associated with a newsgroup are configured in /etc/news/expire.ctl. Three
expiry values are important:
• The minimum time that a message will be kept. This may override the Expire: header
field.
• The default expiry time, which is used if no Expire: header field was set.
• The maximum time that a message will be kept. This may override the Expire: header
field.

Student Notebook

ª * @@

! *
!&`

< ª !

Figure C-17. Configuring cron Jobs LX073.2
Notes:
On a news server, various cron jobs need to be configured. For most distributions, this is all
set up automatically, fortunately. If you install from scratch, read the installation
documentation to see which jobs need to be configured.

V3.0
Student Notebook
Uempty
$
@@
@@ * @@
&`

$"

$"
'
$ *'* *

$ $$#ª* *

Figure C-18. ctlinnd LX073.2
Notes:
ctlinnd is a tool which can manage the running INN daemon, including the changing of
some (dynamic) configuration files in /var/named.
One important thing that ctlinnd can do is to add and delete newsgroups on the fly, without
restarting the innd daemon. Furthermore, it allows you to close innd for news reader or
news server connections, allowing you to do more extensive maintenance. For more
information, see the manual page.

Student Notebook
#"""$''
@@#
* K
*
*
%@@
*
$
j Q *
Figure C-19. Wrapup: Implementing INN LX073.2
Notes:
The visual above shows the steps that you need to undertake to install and configure the
INN daemon.

V3.0
Student Notebook
Uempty
"
_K
} *
K %
K @@
K @@
K }
^K K@** *Q

!
K
K ££££££££££ *K
Figure C-20. Checkpoint LX073.2
Notes:
1.
2.
3.

Student Notebook
34
} @***{ {

}
*

@*
Q
@@

* * *
*Q * * *Q
@@ *Q
Figure C-21. Unit Summary LX073.2
Notes:

V3.0
Student Notebook
IX Index
Symbols airsnort 2-9
$DISPLAY 3-15 aliases 8-31
$HOME/.xinitrc 4-15 AMD 11-5
$TERM 3-15 amd 11-8
.forward 8-33 Anonymous ftp 3-18
.netrc 3-16, 3-19 Apache 3-3
.plan 3-25 ARCnet 1-11
.rhosts 3-21, 4-11 ARP 1-9
.rlogin 3-20 arp 1-13, 2-20
.shosts 4-11 ARP reply 1-13
/etc/amd.conf 11-6 ARP request 1-13
/etc/auto.master 11-11 ARPANET 1-5
/etc/dhcpd.conf 9-14, 9-17, 9-18, 9-22 ARPAnet 3-14
/etc/exports 10-12, 10-13 ASCII 8-9
/etc/fstab 10-16, 11-4 AT commands 5-9
/etc/ftpusers 3-17 ATM 1-11
/etc/HOSTNAME 2-4, 9-21 atomic clock 14-6
/etc/hosts 1-32, 2-13, 2-14 auth_ldap 13-17
/etc/hosts.allow 3-8 authconfig 13-26
/etc/hosts.deny 3-8 Autofs 11-5, 11-11
/etc/hosts.equiv 3-20, 3-21, 4-3, 4-11 avian carriers 1-10
/etc/inetd.conf 3-5, 3-11 AX.25 1-11
/etc/named.boot 7-16
/etc/named.conf 7-16, 7-18, 7-37 B
/etc/news/incoming.conf C-19 Base DN 13-8
/etc/news/inn.conf C-11 Berkeley Internet Name Distribution 7-16
/etc/passwd 3-25 Berkeley Software Distribution 1-5
/etc/ppp/chap-secrets 5-24 BGP 6-19
/etc/ppp/options 5-11, 5-20 BIND 7-16
/etc/ppp/pap-secrets 5-24 Bootp 9-6
/etc/resolv.conf 2-13, 2-15, 2-22, 7-29, 7-35, 7-39 Border Gateway Protocol 6-19
/etc/rndc.conf 7-37 broadcast 1-16, 14-9
/etc/services 3-15, 8-38 BSD 1-5
/etc/shosts.equiv 4-11
/etc/sysconfig/network 2-4
/etc/xinetd.conf 3-11 C
/etc/xinetd.d 3-10, 3-11 caching-only nameserver 7-14, 7-36
/usr/lib/yp/ypinit 12-16 ccTLD 7-3
-m option 12-16 certification authority 8-37
-s option 12-22 Cesium 14-6
/var/lib/news/active C-15 Challenge Handshake Authentication Protocol 5-5
/var/lib/news/newsgroup C-15 CHAP 5-5, 5-22
chargen 3-13
chat 5-8, 5-11, 5-12
Numerics chmod 5-20
127.0.0.1 1-21, 7-17 Class A address 1-18
Class B address 1-19
A Class C address 1-19
A 7-6 clear text 4-3
Acknowledgement 1-31 CN 13-8
Address Resolution Protocol 1-9, 1-12
CNAME 7-6
© Copyright IBM Corp. 1999, 2003 Index X-1

Student Notebook
Common Name 13-8 -a option 10-13

CompTIA B-1
Connection 1-31
Connection setup 1-30 F
cp 3-21 failover 9-19
crond 8-26 Fast Ethernet 1-11
crtscts 5-12 Fiber Distributed Digital Interface 1-11
ctlinnd C-15, C-23 File Transfer Protocol 1-7
finger 3-3, 3-13, 3-25
FQDN 7-3
D Frame Relay 1-11
DARPA 1-5 FTP 1-7
date 14-17 ftp 3-3, 3-13, 3-16
daytime 3-13 Fully Qualified Domain Name 1-33, 2-15, 7-3
decimal dot notation 1-17, 1-20
DECnet 5-3
default route 2-12, 6-10, 6-16 G
DHCP 1-16, 9-6, 14-3 gated 6-19, 6-20
DHCP_HOSTNAME 9-20 gateway 6-5
DHCPACK 9-9 get-lease-hostname 9-18
dhcpcd 9-12, 9-13 Gigabit Ethernet 1-11
dhcpd 9-14, 9-16 Global Positioning System 14-7
dhcpd.leases 9-22 GPS 14-7
DHCPDISCOVER 9-8 gq 13-16, 13-23
DHCPOFFER 9-8 gTLD 7-3
DHCPREQUEST 9-8
dig 7-40, 7-41
digital certificate 8-37
H
HINFO 7-7
discard 3-13
host 2-22, 7-10, 7-40, 7-41
Distinguished Name 13-8
host route 6-9, 6-16
dmesg 2-18
hostname 2-4
DN 13-8
hostnames 1-32
DNS 1-33, 2-22, 4-3, 7-3
http 3-4
DNS server 1-33
hwclock 14-17
dnssec-keygen 9-21
Domain Name System 1-33, 7-3
domainname 12-13 I
dot domain 7-3 IAB 1-6, 4-4
DSA 4-13 IANA 1-18, 1-21, 1-26, 1-27, 3-5
Duplicate packets 1-30 IBM Public License 8-27
Dynamic DNS 9-20 ICMP 1-9, 1-25
Dynamic Host Configuration Protocol 9-6 IEEE 802.11 2-8
dynamic port 1-26 IETF 1-6
dynamic route 6-15 ifconfig 2-7, 2-18, 6-15
Dynamic routing 6-18 IMAP 8-11, 8-18, 8-36
imaps 8-38
implicit route 6-15
E in-addr.arpa domain 7-12
echo 3-13
inetd 3-4, 3-5, 3-7, 3-13, 8-36
elm 8-4
INN C-10
ethereal 9-23
inn C-7
Ethernet 1-11
innd C-10
exec 3-13
innxmit C-10, C-17
Exim 8-11
Internet Architecture Board 1-6
explicit route 6-15
Internet Assigned Number Authority 1-18
exportfs 10-20
Internet Control Message Protocol 1-9
X-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

Student Notebook
Internet Engineering Task Force 1-6 LX26 B-2

InterNet News C-10
Internet Service Provider 1-10
Internet Software Consortium C-10 M
InterNIC 1-18 m4 8-22
IP 1-9 MAC address 1-12, 1-13
IP address 1-17 mail 8-3, 8-4
IP alias 2-10 Mailman 8-39
IP Control Protocol 5-4 mailx 8-4
IP forwarding 6-7 Majordomo 8-39
IP protocol 1-15 master nameserver 7-14
IPCP 5-4 Message Transfer Agent 8-4
IPX 5-3 mgetty 5-18
ISP 1-10, 1-18, 5-3 MTA 8-4, 8-11
iterative query 7-10 multicast 14-9
iwconfig 2-9 multicasts 1-22
iwlist 2-9 MX 7-7
iwspy 2-9
N
K name resolution 1-32
Kerberos 14-3 National Marine Electronics Association 14-15
knode C-6 NCP 5-4
kppp 5-15 NetBIOS name 9-18, 9-20
netmask 1-20
netscape 13-16, C-6
L netstat 2-23
LCP 5-4 -a option 2-23
LDAP 13-7 -n option 2-23
LDAP Data Interchange Format 13-21 -r option 6-13, 6-22
LDAP replication 13-27 Network Control Protocol 5-4
LDAP schema 13-11 Network File System 1-29
ldapadd 13-16, 13-22 network route 6-10, 6-16
ldapdelete 13-16 Network Time Protocol 14-5
ldapmodify 13-16, 13-27 newsgroup C-8
ldapmodrdn 13-16 NFS 1-29, 10-3
ldapsearch 13-16 NFS automounter 11-3
LDIF 13-21 nfsd 10-12
lease 9-7 NIS 1-16, 1-32, 12-4
Link Control Protocol 5-4 NMEA-0183 14-15
link speed 2-8 nn C-6
Link State algorithm 6-19 nnrpd C-10
Linux Professional Institute -xvii, B-1 NNTP C-3
Local Area Network 1-12 nntpd C-7
login 3-13 nntpsend C-10, C-17
Loopback interface 1-11 NS 7-7
LPI -xvii nslookup 7-40, 7-41
LPI certification -xvii nss_ldap 13-16
LPI. See Linux Professional Institute nternet Protocol 1-9
LX02 B-2 NTP 1-16, 9-7, 14-4, 14-5
LX03 B-2 ntpd 14-10
LX07 B-2 ntpdate 14-10
LX22 B-2 ntpq 14-11
LX23 B-2 null-modem 5-28
LX24 B-2
LX25 B-2

Student Notebook
O Reverse ARP 9-5

reverse DNS lookups 3-7, 7-12
Open Shortest Path First 6-19
OpenLDAP 13-16, 13-19 rexec 3-19
OpenSSH 4-6 RFC 1-6, 4-4
OpenSSL 8-38 1034 7-3
OSI 1-10 1035 7-3
OSPF 6-19 1123 8-31
Out-of-sequence 1-30 1129 14-5
overchan C-18 1149 1-10
overchan is C-10 1332 5-4
1661 5-4
1662 5-4
P 1996 7-30
Pacing 1-31 2132 9-11
PAM 3-17 821 8-8
PAN C-6 822 8-8
PAP 5-5, 5-22 977 C-4
passwd 5-25 RHCE. See Red Hat Certified Engineer
Password Authentication Protocol 5-5 RHCT. See Red Hat Certified Technician
Permanent Virtual Circuits 1-11 RIP 1-16, 6-19
pine 8-4 RIPv2 6-19
ping 1-25, 2-21, 6-22 rlogin 3-14, 3-20, 3-22
-n option 7-40 rn C-6
-R option 6-22 rndc 7-37, 7-46
Point to Point Protocol 1-9, 1-14 dumpdb command 7-46
POP 8-11, 8-14 stats command 7-46
POP3 8-36 rndc-confgen 7-37
pop3s 8-38 root privileges 1-27
port 1-26 root server 1-33
port number 1-26 root squashing 10-11
portmap 10-6, 10-12 route 2-12, 2-19, 6-13, 6-15, 6-16, 6-22
Post Office Protocol 8-14 -ee option 6-13
Postfix 8-11, 8-19, 8-27 Route Information Protocol 6-19
Postmaster 8-31 routed 6-19, 6-20
PPP 1-9, 1-14, 5-3 router 6-5
pppd 5-11, 5-12, 5-20, 5-28 routing daemon 6-15, 6-18
ProCert -xvii routing table 1-15, 6-5, 6-9, 6-18
PTR 7-6, 7-12 rp3 5-15
pump 9-12, 9-13 rpc.mountd 10-6, 10-12, 10-13
PVC 1-11 rpc.nfsd 10-13
rpc.rquotad 10-21
rpc.statd 10-21
Q rpc.yppasswdd 12-17
Qmail 8-11 rpc.ypxfrd 12-30
rpcinfo 10-20
RR 7-6
R RSA Challenge-Response Authentication 4-12
RARP 9-5
RSA challenge-response authentication 4-11
rcp 3-14, 3-21, 3-23, 4-5
rsh 3-14, 3-22, 4-5
recursive query 7-10
rsync 3-23
Red Hat B-1
Red Hat Certified Engineer B-1
Red Hat Certified Technician B-1 S
redhat-config-network 2-9, 9-20 Samba 3-3, B-3
Request For Comments 1-6 SASL 13-13
resource record 7-6 scp 4-4, 4-8

Student Notebook
secure port 1-27

Secure Sockets Layer 8-37
U
UDP 1-8, 1-27, 1-28
Sendmail 8-11, 8-19, 8-20 unicast 14-9
sendmail.cf 8-22 UnitedLinux B-1
sendmail.mc 8-22 Usenet News C-3
Serial Line IP 1-9, 1-14 User Agent 8-4
Service Set IDentifier 2-8 User Datagram Protocol 1-8
showmount 10-20
Simple Authentication and Security Layer 13-13
slapadd 13-22 V
slapd 13-19 vector distance algorithm 6-18
slapd.conf 13-20 Verisign 8-38
slave nameserver 7-14, 7-31 VFS 10-7
SLIP 1-9, 1-14 virtual file system 10-7
slurpd 13-19, 13-27
Smartmail 8-39
SMTP 8-9, 8-11 W
SNA 5-3 webmin 2-3
SOA 7-7 well-known ports 1-26
socket 1-27 WEP 2-8
SSH 4-4 WEP keys 2-9
ssh 3-24, 4-4, 4-7 Wietse Venema 8-27
ssh-add 4-15 Wired Equivalent Privacy 2-8
ssh-agent 4-14 Wireless LANs 1-11
sshd 4-4, 4-9 wireless LANs 2-9
SSID 2-8 wireless network adapters 2-8
SSL 8-37
sslwrap 8-38
static route 6-15, 6-17
X
X Window System 7-17
stratum 14-8
X.25 1-10
Subnet Mask 1-20, 1-23
xinetd 3-10, 8-36, 8-38
SUN Microsystems 10-4
SVC 1-11
Switched Virtual Circuits 1-11 Y
yast 2-9
T ypbind 12-9, 12-16, 12-22, 12-27, 12-31
T.J. Watson Research Center 8-27 ypcat 12-18, 12-30, 12-32
talk 3-3, 3-13, 3-25, 3-26 ypchfn 12-28, 12-32
TCP 1-8, 1-27, 1-30 ypchsh 12-28, 12-32
tcpd 3-7, 3-10 ypinit 12-31
tcpdump 9-23 ypmatch 12-32
telnet 3-3, 3-13, 3-15 yppasswd 12-28, 12-32
yppasswdd 12-23, 12-28, 12-32
time 3-13
yppoll 12-32
Time To Live 6-23
yppush 12-23, 12-29, 12-32
timeconfig 14-17
ypserv 12-16, 12-31, 12-32
tin C-6
ypset 12-9, 12-23, 12-31
TLD 1-33, 7-3
ypwhich 12-9, 12-22, 12-23, 12-31
TLS 8-37
ypxfr 12-30, 12-32
Token Ring 1-11
Top Level Domain 1-33, 7-3
traceroute 6-23 Z
Transmission Control Protocol 1-8 zebra 6-19, 6-21
Transport Layer Security 8-37 zone transfer 7-14
trn C-6
TTL 6-23

Student Notebook

V3.0
backpg
Back page
®

Linux Network Administration I, TCP-IP and TCP-IP Services - Student Notebook (IBM Learning, 2003, Course Code LX07)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Linux Network Administration I, TCP-IP and TCP-IP Services - Student Notebook (IBM Learning, 2003, Course Code LX07)

Uploaded by

Copyright:

Available Formats

V3.

Front cover

IBM Certified Course Material

September 2003 Edition

Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Unit 1. TCP/IP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit 2. Configuring TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

© Copyright IBM Corp. 1999, 2003 Contents iii

Testing Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17

Unit 3. The inetd Daemon and inetd Services . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit 4. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

iv Linux Network Administration I © Copyright IBM Corp. 1999, 2003

TOC Unit 5. Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit 6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit 7. Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

© Copyright IBM Corp. 1999, 2003 Contents v

Reverse DNS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12

Unit 8. Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

vi Linux Network Administration I © Copyright IBM Corp. 1999, 2003

TOC /etc/postfix/main.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29

Unit 9. Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Unit 10. Network File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

© Copyright IBM Corp. 1999, 2003 Contents vii

Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-25

Unit 11. NFS Automounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Unit 12. Network Information Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

viii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

TOC NIS Programs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31

Unit 13. The Lightweight Directory Access Protocol (LDAP) . . . . . . . . . . . . . . 13-1

Unit 14. The Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

© Copyright IBM Corp. 1999, 2003 Contents ix

Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Appendix C. Usenet News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

x Linux Network Administration I © Copyright IBM Corp. 1999, 2003

© Copyright IBM Corp. 1999, 2003 Trademarks xi

xii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

pref Course Description

© Copyright IBM Corp. 1999, 2003 Course Description xiii

• Use networking commands for remote login, remote execution, and

xiv Linux Network Administration I © Copyright IBM Corp. 1999, 2003

© Copyright IBM Corp. 1999, 2003 Agenda xv

xvi Linux Network Administration I © Copyright IBM Corp. 1999, 2003

pref Certification Information

Linux Professional Institute Statement

© Copyright IBM Corp. 1999, 2003 Certification Information xvii

xviii Linux Network Administration I © Copyright IBM Corp. 1999, 2003

Uempty Unit 1. TCP/IP Concepts

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

© Copyright IBM Corp. 1999, 2003 Unit 1. TCP/IP Concepts 1-1

After completing this unit, students should be able to:

Figure 1-1. Objectives LX073.2

1-2 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

Transmission Control Protocol/Internet Protocol

Figure 1-2. What is TCP/IP LX073.2

© Copyright IBM Corp. 1999, 2003 Unit 1. TCP/IP Concepts 1-3

1-4 Linux Network Administration I © Copyright IBM Corp. 1999, 2003

Late 1960s DARPA primary funding agency

Mid 1970s ARPANET point-to-point leased line

Mid 1980s BSD UNIX incorporates TCP/IP

Late 1980s TCP/IP available on almost all computer