linux network administration i, tcp-ip and tcp-ip services - student notebook (ibm learning, 2003,...

V3.0

cover

��
Front cover
Linux NetworkAdministration I: TCP/IP and TCP/IP Services (Course Code LX07)

Student NotebookERC 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:

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.

AIX® DB2® Domino™Lotus Notes® Lotus® Notes®SecureWay®

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis withoutany warranty either express or implied. The use of this information or the implementation of any of these techniques is a customerresponsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. Whileeach item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results willresult 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 restrictionsset forth in GSA ADP Schedule Contract with IBM Corp.

September 2003 Edition

Student NotebookV3.0

TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

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

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

Unit 2. Configuring TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2TCP/IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Configure Hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Configure Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Assign IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Configuring Wireless Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Configuring the Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Configuring Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13/etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14/etc/resolv.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

© Copyright IBM Corp. 1999, 2003 Contents iii

Student Notebook

Testing Your Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17Verify Local Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18Verify Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19Verify ARP Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20Verify Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21Verify Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22Verify Open Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-24Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-25

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

Unit 4. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2telnet, ftp, rexec, rsh, rcp Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3SSH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4SSH Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6ssh Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7scp Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8sshd Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9ssh/sshd Host Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10sshd User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11RSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12DSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13Protecting Your Private Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17


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


TOC
Unit 5. Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2PPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3Linux PPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Setting Up A PPP Client (Overview) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Establishing a Serial Connection (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8Establishing A Serial Connection (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9Establishing the PPP Connection (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Establishing the PPP Connection (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Setting Up A PPP Client (Wrapup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Setting Up A PPP Server (Overview) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Setting Up for a Serial Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Setting Up for an Incoming PPP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20Client Authentication (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22Client Authentication (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Client Authentication (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25Windows Clients Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26PPP and a Permanent Null-Modem Connection . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Unit 6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2The Internet - How It Seems To Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3The Internet - How It Really Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Router Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5Linux as a Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9A Sample Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Basic Route Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12Viewing the Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Filling the Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15route Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16Configuring Static Routes Permanently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17Dynamic Routing Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Routing Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20Debugging Routing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Unit 7. Domain Name System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3DNS Hierarchy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6Resource Records Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8DNS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10


© Copyright IBM Corp. 1999, 2003 Contents v

Student Notebook

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

Unit 8. Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2E-mail Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3E-mail model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4User Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6Simple Mail Transfer Protocol (SMTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8SMTP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9Message Transfer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11Deliver to which MTA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12Post Office Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14POP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16Internet Message Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18Linux E-mail Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19Sendmail Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-20sendmail.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22Important Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25Postfix Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27


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


TOC
/etc/postfix/main.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31User-Defined Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33Virtual Mail Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34Implementing POP3 or IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36Protecting POP and IMAP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Unit 9. Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3Dynamic Host Configuration Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5Leasing an IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7DHCP Client-Server Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8DHCP Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10Selected DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11Linux DHCP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12Linux DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13Linux DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14Sample /etc/dhcpd.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16DHCP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20Troubleshooting DNS Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25

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


© Copyright IBM Corp. 1999, 2003 Contents vii

Student Notebook

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

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

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


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


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

Unit 14. The Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2Why Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3The Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5Sources of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6Stratum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8NTP Communication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9ntp Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10/etc/ntp.conf Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12Receiver Pseudo IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14NTP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16Other Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18Unit 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


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:

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.

AIX® DB2® Domino™Lotus Notes® Lotus® Notes®SecureWay®


© Copyright IBM Corp. 1999, 2003 Trademarks xi

Student Notebook


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


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


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 NFSUnit 12 - NFS Automounter Exercise 12 - NFS Automounter

Day 5

Unit 13 - Network Information Service Exercise 13 - Configure and Use NISUnit 14 - Lightweight Directory Access ProtocolExercise 14 - Lightweight Directory Access ProtocolUnit 15 - Network Time ProtocolExercise 15 - Network Time Protocol


© Copyright IBM Corp. 1999, 2003 Agenda xv

Student Notebook


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


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


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

Figure 1-1. Objectives LX073.2

Notes:

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


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


Uempty

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.

What is TCP/IP

Transmission Control Protocol/Internet Protocol

Suite of protocols that work togetherTCP, IP, UDP, ARP, ICMP, PPP, ...

Open standards

Allows communication between heterogeneous systems

Supports different physical network types

Protocol of the Internet



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.




Uempty

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.

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

History



Student Notebook

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

Requests for Comment (RFC)

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

RFC 791

Internet

Protocol




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

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.

TCP/IP Layering

WAN LAN

IP

UDP TCP

Applications such as NFS, NIS, mail, DNS

Unreliable delivery to correct program Reliable delivery to correct program

Unreliable delivery of packets to correct system

(Modem connections, lease lines, ...) (Ethernet, Token Ring, ...)




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

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 lessthan three hours to transmit nine "ping" packets, of which four were actually answered. For more information seehttp://www.blug.linux.no/rfc1149.

Network Architecture Support in Linux

Wide Area NetworksSerial/modem/ISDN connectionsCCITT X.25 Protocol (under development)ATM (under development)Frame Relay (dlci or sdla)

Local Area NetworksEthernet (eth)Token Ring (tr)FDDI (fddi)ARCnet (arc)WiFi (???)

MiscellaneousLoopback (lo)AX.25 (sl or ax)




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

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 usedby network sniffers such as tcpdump.

LANs and the ARP Protocol

Most LANs are broadcast networks at the lowest levelEverybody receives what you are sending

To identify the recipient, a MAC address is used48 bits, unique for the network adapterNotation: 02:60:8C:2E:9B:CASpecial 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 anyoneOnly the destination replies with its MAC address

ARP is invoked automatically by IP if the destination MAC address is not known

Cached in ARP tableView table with arp -a




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

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.

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, ...)authenticationconnection negotiation and configuration




Uempty

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.

IP Protocol

Packet delivery protocol:Best effort - no guaranteesNext-hop routing to destination host based on IP address

Additional featuresPacket fragmentation and reassembly if packet too large for infrastructurePriority indicationBroadcast capability



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.




Uempty

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.

Internet Address

10000001 00100001 10010111 00000111

33129 151 7.. .Decimal-Dot

Each host on an IP network needs an IP address32 bitsshould be unique

IP addresses are usually written in decimal-dot notation:

Binary



Student Notebook

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.

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 networksAll hosts in a network have the first n+m in common

Thus, the first n+m bits identify the networkThe last 32-n-m bits identify the host on the network

Example:

10000001 00100001 10010111 00000111

33129 151 7.. .

n=16 m=8

Assigned by IANA to this organization Assigned by this organization to this network

Assigned by the network administrator to this host

Identifies the network Identifies the host




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

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.

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

33129 151 7.. .

Indicates: The first 24 bits identify the network last 8 bits identify

the host

11111111 11111111 11111111 00000000

255255 255 0.. .

IP Address

Subnet Mask

Notation: 129.33.151.7/255.255.255.0

New, alternative notation: 129.33.151.7/24




Uempty

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.

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/8172.16.0.0/12192.168.0.0/16

Multicast addresses: 224.0.0.1 and up



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.




Uempty

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)

Off-the-byte Subnet Masks

Subnet Masks do not have to end at an 8-bit boundaryGives more control on number of IP addresses assigned to a networkMakes calculations much harder

Examples:129.33.151.7/255.255.254.0 (= 129.33.151.7/23)

23 bits subnetmaskNetwork identifier is 129.33.150.0Valid IP addresses: 129.33.150.1 - 129.33.151.254Broadcast address is 129.33.151.255

129.33.151.7/255.255.255.128 (= 129.33.151.7/25)25 bits subnetmaskNetwork identifier is 129.33.151.0Valid IP addresses: 129.33.151.1 - 129.33.151.126Broadcast address is 129.33.151.127



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)




Uempty

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.

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 messagesPackets 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



Student Notebook

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.

Ports and Sockets

A port identifies the application on the host

Server side ports are well-known and fixedStored in /etc/servicese.g. telnet is 23, http is 80

Client side ports are dynamic, > 1023Every 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




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

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

UDP Protocol

Connectionless application interface to IP

Does not guarantee packet delivery or duplication protection

Main usage:Broadcast/multicast trafficReal-time communications (streaming audio/video)Traffic with low overhead requirements (e.g. DNS, NFS)




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

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.

TCP Protocol

Connection-oriented application interface to IP

Ensures reliable communicationsDuplication, out-of-order protectionRetransmission of missing packetsPacing (adapt number of packets sent to available bandwidth)

Main usage:Unicast, reliable connections such as http, telnet, ftp, mail




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

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).

Name Resolution

A symbolic hostname exists for (almost) every IP addressEasier to rememberMore 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 networkHostname is a single word, e.g. nfsserver1Mapping stored locally

Domain networkHostname is a hierarchical name, e.g. www.ibm.comMapping stored in global Domain Name System (DNS)




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

Figure 1-20. Checkpoint (1 of 2) LX073.2

Notes:

Write down your answers here:

1.

2.

3.

4.

5.

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 numberb. An IP address, port number and protocol familyc. A machine address and IP addressd. A host name and port number

4. How many bits make up the unique physical address of a Token Ring or Ethernet adapter?a. 16b. 32c. 48d. 64

5. How many bits make up the Internet address?a. 16b. 32c. 48d. 64




Uempty


Notes:


6.

7.

8.

9.

10.

11.

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.



Student Notebook

Figure 1-22. Unit Summary LX073.2

Notes:

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




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:

��

��

��

��




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.

��

'� ��*��

�� !�� !��

#��$��!�� *��+%�%&��$<%�@��&




Uempty

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 detectsthese adapters in the reverse order...

��!��"��

��*��*�� !��J� �� !

%�� %�� !

�� !�� K�� K�� +�� K��

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



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.




Uempty

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.

!��!��

'� ��*�� 7�!��7�7�A��?��

��*�� *��

��+�� !�� #��$��!�� *��+� ��Q��JY��Q��Z%�%&��!�� *��+��JY��Q��Z

��Q��Q�� !�� JY��Q��Z�� "�� C��



Student Notebook

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.

��#��$��!��"��

[��&&&�\]^K__�� +�� *��*��`��

j� +��{��{�%%�'��%��Q��%��'� ��[&�� !�� +�!��

'� ��*�� C ��7�"��DEFHJK�� 7��+�LA;!��

�� !�� JY��Q��Z��

�� *��

<�� $��j�� *�� *��+��"��'��!�� |��!��




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

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

��!$��

}��

}��*�� }�� *��+�� !�� *��+�� $��J�Q��!��

�� ]�� ]�]��]�_��KKK��*�� M��@�� <��M��M��




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 isa difference".



Student Notebook

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.

��%��$��&��

��'��#��{*�!��{��!�� *��+

%�� "��7�!��7�7�7

��*�� Q��

��+�� !�� #��$��!�� *��+��!�� *��+� ��Q��JY��Q��Z��~�%�%&��!�� *��+��!�� *��+��JY��Q��Z��~�

�~�� J��Q�� !�� K�K��*�� Q�� !




Uempty

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.

��'��&��$��

$��

��Q��!��*��Q��

�� &�� %�� '@%�� QK��



Student Notebook

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.

��

��O��"��M��Q�R�S��"��T�Q&��T�QS��T ��

7�A��7�� ?�� 7�!��7�7�A��U�A7�!��7�7�7��U�7�"��"7�!��7�7��7��U��7��77�!��7�7��U��




Uempty

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.

�� $�*��

��" ��UV�� "@"�7�!��7�7��7��"@"�7�!��7�7��



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.




Uempty

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.

��+��

��!��

��!��

��!��#��

��!�� Q��!

��!��

��!��



Student Notebook

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.)

.��0��$��

��

��'��?�� MF��"��&W��"M��M��M�LM;7M��M�7

��"M7�!��7�7�A�D ��M7�!��7�7��E��?M��

��JR�D#XSHKSYO�#JZZ�Z[�EJ'O�KSYO�EOJM7��E�"� M7

��#\�� ?��M+!�""�"�M��"��M��@""��M��"�M�

��O\�� ?��M��""�"�M��"��M��@""��M�� ""�"M�

�� M��B��M7��

��""��M!�D��"��M��7��

��'��?�� M'� ��'�� ?

��"M7�A��7��E��?M��

��JR�'XXRDSK]�#JZZ�Z[�EOJM�!�+�E�"� M7

��#\�� ?��M��""�"�M��"��M��@""��M��"�M�

��O\�� ?��M��""�"�M��"��M��@""��M�� ""�"M�

�� M��B��M�




Uempty

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.

.��&��

��"��

]"��R�"��

H��[��C�U��[��?��^��E�"� ��#��J��

7�!��7�7��`��J��

��7�!��7�7�7��J[��



Student Notebook

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.

.��!&��$�

��"�

S��"��&W�U��&W��"��^��E��?��

7�!��7�7�7��"��MS�M�+M;SM;�MDS��K��




Uempty

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.

.��

��7�!��7�7�7

R�Z[�7�!��7�7�7�*7�!��7�7�7>��"��7�!��7�7�A�M��L*;+>��U��

L+��U��"��7�!�7�7��7M�� V�B��

L+��U��"��7�!�7�7��7M�� V�B�7��A��

L+��U��"��7�!�7�7��7M�� V�B��A��

L+��U��"��7�!�7�7��7M�� V�B��A��

hK

<<<�7�!�7�7��7�� <<<

+�� ?��"��+�� ?��" �@��j�� ?��

"��<�"��@��A�7�A��



Student Notebook

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 inthe second example comes from. We will cover this in the DNS unit.

.��&��$��

��U�A

�U�A�UV�� "��7�!��7�7�A

��7�!��7�7�A

A�7�7��7�!��Z<SHH#�S#RS��"��U�A�UV��




Uempty

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.

.��"��

��<�

S ��@��"�� *�"@"��>

R"��# @<w�Y��<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`��A��

"�C��`M� ��`M`��A��



Student Notebook

Figure 2-19. Checkpoint LX073.2

Notes:


1.

2.

3.

4.

��"��

_K [�� *��*�� +�� *��+�

^K [�� !��

�K [�� *��!�*�� !��

�K [�� *��*�� *��+�� +�� *��+��




Uempty


Notes:

3��4��

�� *� ��+� �� %�� '��

}��!��

��!�� Q��



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:

• Checkpoint questions • Exercises


© Copyright IBM Corp. 1999, 2003 Unit 3. The inetd Daemon and inetd Services 3-1

Student Notebook


Notes:

��

��

'��

'��

'�� `� ��

'�� Q��




Uempty

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

��54�"��5�%��

��!��Q�� *J��Q�� +�� KKK

'� ��*� ��*�� Q�� !

%�� j�� %��Q�� *��

'�� J��Q��



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.




Uempty

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

�� *��

� �� "� � � ��C��"�� "��

� �� "� �� C��"�� "��

�� "� ��"� � � ��C��"�� "��

�� "� ��"� �� C��"�� "��

��U�� "� � � ��C��"�� "��

��U�� "� �� C��"�� "��

� ��"�� "� � � ��C��"�� "��

� ��"�� "� �� C��"�� "��

�� "� � � ��C��"�� "��

�� "� �� C��"�� "��

�� "� � � ��C��"�� "�� <��<�

�� "�� C��"��"��

�� "� � � ��C��"�� "�� "��

�� "� � � ��C��"�� "�� "��

� ��"� � � ��C��"�� "�� "� �

��? ��"� �� C�� U��U ��"�� ?�

��? ��"� �� C�� U��U ��"�� ?�

��<��"�� C��"��"��

��<��"�� C��"��"��

��"�� C��"��"��



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.




Uempty

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.

��"��#��""��%��

&`��!�� Q��

��

��{�� K��J��J�{

��"�� |��Q�� K��*�� K�� !

��*��"��{� K��J��J�{

�� +�

#�� Q��'@%��+��*��+��



Student Notebook

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

�� *�$$�� *��

%! ��`��%��Q��$��

%��Q��!��6��!00

$��!�� '@%�� jj

��+� ��K��*��*��Q��*��K�� !�� Q�� !��<��*��*��

&`�� C��M�� !��;�� US''M�S''

�� `�� "��




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. Forexample, 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 onlyneeds 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 evenworse. As part of the command string, people have used finger to retrieve information about the user that made the connection. Theuser knew this and linked his .plan file to a character generator. This caused a buffer overflow in the finger client on the server, andultimately caused the server to crash.



Student Notebook

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.

��7��54�"��5�%��

%��

� ��"�� !

�� ! ��`��

�� !��`� ��K�




Uempty

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:

�� 7��*�� 7��*� 8

��

��z

�� L�

��V�U��Y{Y'X[��"�@

��V��V�� &XYO�R�H

��V��V��"��&XYO�#FKX#H

|

�� "��

��

��z

��

��#FJYF

�� ?�V�U��"�

��C��

��"��"��

��"@"��"��

��V��V��"��}��JYF#�H

|



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.




Uempty

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.

��4��

� �� Q��!�� Q��!�� +�� Q��!�� Q�� ^J��Q�� !�� J��

�� `�� Q��$��$�� "�� 7��`��Q�� $��*�� ! ��



Student Notebook

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.

&��0��6�97��:�$��

!&�!'9 ;9&<909+

��$��

��$�� $��

��7��

��7��

��$��

��"� ��"

�#�� #�� !�� Q��!��*��

��+��!�� @��Q��!��*��[��+�� !��*�� }@��




Uempty

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.

��$��

j�� !��

�� Q�� Q��&#�'�%�j��

&`�� ~��U�AO"U��7�!��7�7�A��K�� U�A�F� �� "� �"��h��

W� ��U�A��M��7R��C�"�M�U�A~� ��~H�YR'S{ ��M��U�A~�h��T�B��K�� ~�V



Student Notebook

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.

��"

�� !��

��`�� Q��*�� #�j�� j�

�� $<�&�K �� !��

��

&`�� ~��U�AK�� U�A��U�A�^OR��"@"�"��U�Z��* ��M��7>M��7R��C�"�M��T� �� T��7��7��T��T�B��7�[��U ��~




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

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 tothat specific directory. After this system call, the process that made the call cannot leave this directory. So even if the user manages toobtain root privileges, he cannot do much damage to the system as a whole. Only the directory itself is vulnerable.

!��"

��*��*��*��{��J��{��!�� Q��

�� Q �� Q��

��

��

��K��KKK��KKK

��




Uempty

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.

��7��

��*��`��

�� $<�&�K ��

'��

&`�� ~�"� ��U�A��Z�M�*�U�AM��7>M��7R��C�"��*�U�AM��7>H�?�� ~



Student Notebook

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.

�$��

j�� !��

}��K�|��Q�� $<�&�K�� Q��

�� Q�� '@%��+�

&`�� ~�"��<��7��U�AR��C�"�M�U�A~��H�?�� U�A~�� ~




Uempty

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.

��"

�� !��

#�|��K�|��Q�� $<�&�K�� Q��

[�� Q��*��

%! ��`� ��!��|��Q�� "�� `� ��*�� Q��!�� Q�� J��!��

&`�� ~� ��7��U�AM� ��`�� ~



Student Notebook

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.

��

��*��`��

#�|��K�|��Q�� $<�&�K�� Q��

[�� Q��*��

[�� `��*�� $��

&`�� ~�"��<��7��U�A��H�?�� ~

��*�� ~�"��<��7��`� �T�� ~�"��<��7��`� �T��




Uempty

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 (“:”).

��

��*��! �� < �!�� JZ�� * �� |��! �� Q��%! ��`��"�� !�� J��

&`��j��! ��

��~�"�U� ��7�CCC<��7�CCC

%! ��Q�� ~�"�U� �<�@��7�CCC<��CCCM�@�"�CCC�� ~�"�U� �<�@��<��7�CCC<��CCCM�@�"�CCC��

%! �� ! ��|��! ��K�� ~�"�U� �<�@��7�CCC<��CCCMMCCC��"��



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.




Uempty

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.

��

}��Q�� !��

&`�� ~��"��U�A��U�A�'��Z��O�U��'��O��X�� "��#��@��`M��E�"��!��!M��"��#��@��E�"��!��!M�L��7��O��R��7��E�"��!�7�M��

��~��"�"��U�A��U�A�'��M�"�� Z�M�#��@��H�" ��"UM��"�� Y��M��X�� ^"��E�"��!��!M��*KFO>��M��*��>X�� ^"��E�"��!��!M�L�*KFO>��7!�� E��"��Y��+�7�M��*KFYO>

R��MW�"��



Student Notebook

Figure 3-19. talk LX073.2

Notes:

talk is used to initiate a chat session with another user, possibly on another system.

��$�

}��*�� !�� !��

&`�� ~��?��7��U�A

*J�"��7�C��" �@��C��M>

E��"��O��?H�� 7�M7L��?M� �� "B��U�� ?M�"��C��M��?��

*O�� @��7��"�M>

�U�A~��?��




Uempty


Notes:


1.a.b.c.

2.a.b.

3.a.b.

4.a.b.

5.

��"��

_K �� K�K�K

^K �*�� K�K

�K �*�� `��

�K�K

�K [��*�� !�� Q��$��"��

�K�K

�K [��"�� 7�� !��



Student Notebook


Notes:

3��4��

�� `� �� *J��Q��

�� K�� `� ��K��

�� Q�� Q��!��

�� K��*�� K�� !

��Q�� `� �� Q��+��#�� $�� $�� "�� "#��`�� 7�� #��Q�� $�




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:

• Checkpoint questions • Machine exercises


© Copyright IBM Corp. 1999, 2003 Unit 4. Secure Shell and Secure Copy 4-1

Student Notebook


Notes:

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




Uempty

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.

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 passwordSend as plain textVulnerable to sniffingNeed to remember each password for each account

Authentication can also be based on IP addressUses /etc/hosts.equiv or $HOME/.rhosts fileVulnerable to IP address spoofingDependent on DNS server



Student Notebook

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.

SSH Protocol

Invented at http://www.ssh.fiSubmitted as Internet Draft (pre-RFC status)

Two client programs:ssh -> remote login, remote executionscp -> remote copy

One server program: sshd

Uses encryption to protect data in transitSupport for various encryption methodsSniffing attack no longer practical

Uses public key algorithms to authenticate serverPrevents against man-in-the-middle attack

Can use public key algorithms to authenticate user tooAccount passwords no longer needed




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

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.

SSH Implementations

Linux:http://www.ssh.fi

Traditional implementationRestrictive license

http://www.openssh.orgNew implementationGNU Public LicenseUses 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.




Uempty

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”.

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)



Student Notebook

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 OpenSSHwebsite, but doesn’t get a lot of priority.

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




Uempty

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.

sshd Usage

Daemon process directly on port 22Does not use [x]inetd

Started by /etc/rc.d/init.d/sshd

When started:Read config from /etc/ssh/sshd_configRead host-specific RSA key from /etc/ssh/ssh_host_keyCreate session-specific RSA key (never stored on disk)

When a client connection is startedNegotiate session key with clientEncrypt all communications with session keyAuthenticate clientLog in, execute command or copy file(s)



Student Notebook

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.

ssh/sshd Host Authentication

Every sshd host needs to generate a host key pairPrivate key stored in /etc/ssh/ssh_host_keyPublic 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




Uempty

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.

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 authenticationRequires the user to have the correct RSA key pair

4. Password based authenticationRequires the user to supply the correct password



Student Notebook

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.

RSA Challenge-Response Authentication

User generates RSA keypair on client with ssh-keygen -t rsa1

Private key stored in $HOME/.ssh/identityPublic 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




Uempty

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.

DSA Challenge-Response Authentication

SSH Protocol Version 2 can use DSA instead of RSA

To generate a DSA key, use ssh-keygen -t dsaPrivate key stored in $HOME/.ssh/id_dsaPublic 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



Student Notebook

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.

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 itssh-add manages the private keys that are retained in memory by ssh-agent

Use ssh-add [<filename>] to add a keyUse ssh-add -l to list all keysUse ssh-add -d [<filename>] to remove a key




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


Notes:


1.

2.

3.

4.

5.

6.

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?




Uempty


Notes:

Unit Summary

There are various reasons not to use telnet, ftp, rexec, rsh and rcp

Vulnerable to password sniffingVulnerable to IP address spoofingVulnerable to man-in-the-middle attacks

The SSH protocol uses strong encryption and can prevent this kind of attacks

Several implementations for Linux existhttp://www.ssh.fihttp://www.openssh.com



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


Notes:

Objectives


Explain the main features of PPP

Determine whether PPP is suitable for particular applications

Configure and use PPP on Linux




Uempty

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.

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



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.




Uempty

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.

Linux PPP Features

PPP Client

PPP Server

PPP

- PAP/CHAP Authentication

10.0.0.2

10.0.0.1



Student Notebook

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.

Setting Up a PPP Client (Overview)

Establishing a serial connectionInitializing modem, dialing phone numberLogging in

Establishing the PPP connectionExchange of IP addresses

AuthenticationPAP/CHAP




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

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.

Establishing a Serial Connection (1)

Initialize modem and dial number (if modem connection)

Log in to system (optional - depending on ISP)

Generally done using chatexpect-send tool: if you see this, do that.Syntax: chat -f chatfile or chat expect send expect send




Uempty

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".

Establishing a Serial Connection (2)

Scenario:We have a Hayes compatible modem (which therefore uses the AT commands)Telephone number to dial is 1234567890We need to log in to our ISP with userid ppp and password ppp

Then our chat script becomes basically:

"" ATZ

OK ATDT1234567890

CONNECT ""

ogin: ppp

word: ppp

reset modem

dial telephone number

wait for "CONNECT" and send enter

wait for "ogin:" and send userid

send password



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.




Uempty

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).

Establishing the ppp Connection (1)

Done using the pppd daemon

After the serial line has been set upHowever, 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



Student Notebook

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.

Establishing the ppp Connection (2)

Scenario:Our IP address is 10.0.0.1The remote IP address is 10.0.0.2Use hardware flow controlUse /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)




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

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.

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




Uempty

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

Setting Up a PPP Client (Wrapup)

Some tools can automate the client setup:kpppredhat-config-network

pppd can also use dial-on-demandThe connection is automatically started as data arrivesSet using the following options in /etc/ppp/options:

demandidleholdoff

After setting up the link, don't forgetSet up routing

The defaultroute option configures the default route over the PPP link

Set up DNSMight want to use /etc/ppp/ip-up script for this



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.




Uempty

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.

Setting Up a PPP Server (Overview)

Allow for establishing a serial connectionConfigure modem to answer calls

Allow for establishing a ppp connectionWhen a user logs in, start the pppd daemonSupply IP addresses

Require authentication using PAP or CHAP



Student Notebook

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 ATAcommand, but will answer the call immediately. The usual command to enable this is ATS0=1, meaning: auto-answer after one ring. Thismodem configuration change is generally something we will want to store in the non-volatile memory of the modem so that after a resetof the modem the auto-answer will remain enabled. Depending on your modem, this is usually done with the ATZ command.

Setting Up for a Serial Connection

Start an mgetty on the tty.vi /etc/inittab and add a line for the getty:

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

s1:2345:respawn:/sbin/mgetty ttyS0

ppp:x:501:501::/home/ppp:/usr/sbin/pppd




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

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

Setting Up for an Incoming PPP Connection

pppd will be started by users, but has to run as rootchmod 4755 /usr/sbin/pppd

Add general options to /etc/ppp/options

Add specific options to /etc/ppp/options.ttyS0

crtscts

-detach

10.0.0.2:10.0.0.1




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

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.

Client Authentication (1)

Can be done using Password Authentication Protocol (PAP) or CHAP (Cryptographic Handshake Authentication Protocol)

Done after the PPP connection is set upThe 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 connectionThe other side is tested for whether it knows the same secret as you do.The secret is normally your password

CHAP is considered more secureChallenge encrypted with passwordRegular intervals




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


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.


/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




Uempty


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.


pppd can also use regular /etc/passwd authenticationUse 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

* * "" *



Student Notebook

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.

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-userTo 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




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

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.

PPP and a Permanent Null-Modem Connection

With a null-modem, the connection is permanentNo need to set up a serial connection

Probably no need for security as wellSo 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

.




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


Notes:


1.

2.

3.

Checkpoint

1. Which Linux daemon runs for each PPP connection the system has?a. pppdb. chatc. initd. 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.




Uempty


Notes:

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 connectionSetting up the PPP connectionAuthentication

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



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


Notes:

��

��

&`��

j��

&`�� *�� ! ��

��

'��! ��




Uempty

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.

��4��#��

***K��K��



Student Notebook

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.

***K��K��

��&��$$��#��

��

��

��

��

��

��




Uempty

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, defineda number of terms that were in common use, including the term router and gateway. These definitions have stuck and a device thatroutes packets through a network without altering them is now called a router. The term "gateway" is reserved for a device which does aprotocol conversion. In older documentation, and in various abbreviations and in various commands, the term gateway is occasionallyused instead of router.

&��

'�Q��*�� j�@[�@

}��$�� `�� *��+

��*��+�� `��

�� %��*��j� �`��[� ��*��}@��KKK$��*��KKK

&Q��!�� *��+� �� +��



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.




Uempty

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

0��7��&��

�� *�� 7�T��"� ��U��@+��V��"C�"�

��+�� !�� #��$��!��K�� %�%&��!�� !��

��

'�� ! ��



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.




Uempty

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".

&��$�

j�� `��Q��!�+ �* ��

�� !�� !�J� �� +

�� $��@��*��+��@��*��+��'��%�� +'��

@�`�� j�� J�*�� !�� *��+� ��J�*�� !



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.




Uempty

Figure 6-7. A Sample Network LX073.2

Notes:

This sample network will be used in the next few visuals.

!�4��"$��'��

� ��

��

��

��'�� &

_^�K��K_�_K�_^�K��K_�_K_

_^�K��K_�]K_

_�^K_�\K_K__�^K_�\K_K^ _�^K_�\K_K\

_�^K_�\K^K_

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



Student Notebook

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.

;��&��$�

$��H��[��C�U��"�� 7�A��<��7�!��7�7��<��7�!��7�7�7��<

$��H��[��C�U��"�� 7�A��<��7!��7L;�7��<��7!��7L;��7!��7L;�7�;��<��7!��7L;�7�7��<

#��H��[��C�U��"�� 7�A��<��7�!��7��<��7�!��7�7��<��7!��7L;�7��<��77!��7L;��7!��7L;�7�;��<��7�!��7��<

#��

$��




Uempty

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.

.��&��$�

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

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

<�� *�� J� ��j�� "�� j��+��



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.




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

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.

��

��"��<��7�!��7�7��?��C�7�!��7��7

��"��<��7!��7L;��C�7!��7L;�7�;

��"��C�7�!��7�7�7

� � � '

��

�� *��+��

�� +��

'��

}��




Uempty

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.

��4��&��$�

#��$��!�� *��+� ��Q��JY��Q��Z��!�� *��+� ��Q��Y��Q��ZJ��

%�%&�� !�� *��+��



Student Notebook

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

%��&��"$�

#� ��{#�� '�� {��

��

��Q��!�� Q��!�� *��+

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

�� #��#��Q^��<%��KKK

'�� ^��




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

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.

&��%��

�� #�� !@�� !< �!�� *��+�

��***K��K��}�� J�� &`�� Q�� !�� *��+��!��!�� !�� *��+��

^��<� �%��%��




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

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.

%��&��$��

� �*�!�� *��+�

J�� [��+��J�� '�� +��

��'��!�� #��!�

"��&��#��Q��!�� < �!�*��+��*�� j��

��}��+��*�� j�� *��+�

}�� !� ��*��+�� *�� Q��Q��

#��




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


Notes:


1.

2.

3.

��"��

_K [�� *��+�� K�[��*��

�K �! ��

�K ��

�K ��`��

^K @��*�� ! ��

�K @��*��




Uempty


Notes:

3��4��

#��Q��*��+�� *��+�� +��

#�� +��

�� ! ��

�� *�� Q��%�� !�� '! �� ^��

�� "��



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


Notes:

Objectives


Describe domain name concepts and terminology

Configure a master and slave name server and a DNS client




Uempty

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).

Domain Name System

RFC 1034 and 1035

System that allows lookups in a tree-like databaseFinding a specific information item such as an IP address that belongs to a "node" in the DNS systemThe nodename is specified as a "Fully Qualified Domain Name" (FQDN)

HierarchicalRoot domain: . (dot)Top Level Domains (TLDs)

Generic (gTLDs) such as com, org, netCountry Code (ccTLDs) such as nl, au, uk

Subdomains

DecentralizedEvery domain implements its own tables and serversEvery domain can do its own delegation of subdomain



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.




Uempty

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.

DNS Hierarchy Example

.

com org net nl au uk

ibm

www mail watson

pc387

The root domain

gTLDsccTLDs

ibm.com domain

watson.ibm.com

domain The FQDN of this node is

pc387.watson.ibm.com.



Student Notebook

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.

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 nodePTR (Pointer): The hostname of the nodeCNAME (Common Name): The node for which this is an aliasHINFO (Host Info): Information about this node

Common RR's for domains:NS (Name Server): The nameserver of the nodeMX (Mail Exchanger): The mail server of the nodeSOA (Start of Authority): Information from the authoritative server of the node




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

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 [email protected].

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 thatreceive and grant applications for a domain. Several other organizations like universities have configured their DNS servers as slaveservers from these servers and offer DNS service for these domains to all clients as well, to spread the load.

Resource Records Example

.


ibm

www mail watson

pc387

NS a.gtld-servers.net

NS b.gtld-servers.netNS ns1.ibm.com

NS ns2.ibm.com

MX 0 mail.ibm.com

A 129.42.16.99NS ns.watson.ibm.com

A 129.42.18.99

A 129.1.151.17

NS a.root-servers.net

NS b.root-servers.net




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

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.

.


ibm

www mail watson

pc387

DNS Lookups

pc387# host www.ibm.com

1

23

4

5

6

7

8A 129.42.16.99




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

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.

Reverse DNS Lookups

IP address to Hostname lookups


ibm

www mail watson

pc387

A 129.1.151.17

arpa

.

in-addr

129

1

151

17

PTR pc387.watson.ibm.com.




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

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.

Nameservers

Master NameserversAre "authoritative" for a domainMay initiate zone transfers to slave nameserversService all client requestsCache lookups for other domains

Slave NameserversAre also authoritative for a domainRetrieve data from a master nameserver in a zone transferService all client requestsCache lookups for other domains

Caching-Only NameserversHave no data for a domainService all client requestsCache lookups for all domains (but are not authoritative)




Uempty

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.

Scenario - Domain Name Structure

(root)

dc

ibm

com

sys99.ibm.com

sys1 - MasterName Server

9.19.98.1

9.19.98.2 9.19.98.3 9.19.98.4

9.19.99.4

9.19.99.6

9.19.99.5

sys6 - SlaveName Server

sys2 sys3

sys5

sys4e

sys4



Student Notebook

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.

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




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

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.

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";

};




Uempty

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

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.



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.




Uempty

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!)

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. IN NS sys6.dc.ibm.com.

sys1 IN A 9.19.98.1sys2 3600 IN A 9.19.98.2sys3 IN A 9.19.98.3sys4 IN A 9.19.98.4sys4e IN A 9.19.99.4sys5 IN A 9.19.99.5sys6 IN A 9.19.99.6



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




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 [email protected]. 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

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:

IP Zone File

# cat /var/named/named.9.19.98; 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. IN NS sys6.dc.ibm.com.

1 IN PTR sys1.dc.ibm.com.2 3600 IN PTR sys2.dc.ibm.com.3 IN PTR sys3.dc.ibm.com.4 IN PTR sys4.dc.ibm.com.




Uempty
; 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. IN NS sys6.dc.ibm.com. 4 IN PTR sys4e.dc.ibm.com. 5 IN PTR sys5.dc.ibm.com. 6 IN PTR sys6.dc.ibm.com.


Student Notebook

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.

Local Zone Files

# cat /var/named/named.localhost; Default TTL$TTL 86400;NAME TTL CLASS TYPE RDATA@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.( 2002061001 3600 300 3600000 86400 ) IN NS sys1.dc.ibm.com. IN NS sys6.dc.ibm.com.

1 IN PTR localhost.

# cat /var/named/named.127.0.0; Default TTL$TTL 86400;NAME TTL CLASS TYPE RDATA@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.( 2002061001 3600 300 3600000 86400 ) IN NS sys1.dc.ibm.com. IN NS sys6.dc.ibm.com.

@ IN A 127.0.0.1




Uempty

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

Cache File

# cat /var/named/named.ca;NAME TTL CLASS TYPE RDATA. 9999999 IN NS sys99.ibm.com.sys99.ibm.com. 9999999 IN A 9.19.93.99

# cat /var/named/named.ca;NAME TTL CLASS TYPE RDATA. 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

- OR -



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.




Uempty

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.

Final Master Name Server Setup Steps

Ensure the hostname is the fully qualified domain name# hostname

Configure hostname, if neededredhat# vi /etc/sysconfig/networksuse# vi /etc/HOSTNAME

Create /etc/resolv.conf# vi /etc/resolv.confdomain dc.ibm.comnameserver 9.19.98.1nameserver 9.19.99.6

Start namedredhat# service named startsuse# rcnamed start



Student Notebook

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 BINDversions on most Linux distributions however do implement this mechanism.

Checklist: Adding a Host to the Domain

Update name zone file add host entry A recordadd any optional records such as CNAMEincrease 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




Uempty

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.

Setting Up the Slave Name Server

Create "named" control file

Create local IP zone file

Create cache file

Start "named" daemon



Student Notebook

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.

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 "." {


};




Uempty

Figure 7-21. Local Zone Files LX073.2

Notes:

These files are exactly the same as on the master nameserver.

Local Zone Files

# cat /var/named/named.localhost; Default TTL$TTL 86400;NAME TTL CLASS TYPE RDATA@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.( 2002061001 3600 300 3600000 86400 ) IN NS sys1.dc.ibm.com. IN NS sys6.dc.ibm.com.

1 IN PTR localhost.

# cat /var/named/named.127.0.0; Default TTL$TTL 86400;NAME TTL CLASS TYPE RDATA@ IN SOA sys1.dc.ibm.com. root.sys1.dc.ibm.com.( 2002061001 3600 300 3600000 86400 ) IN NS sys1.dc.ibm.com. IN NS sys6.dc.ibm.com.

@ IN A 127.0.0.1



Student Notebook

Figure 7-22. Cache File LX073.2

Notes:

This file is also exactly the same as on the master.

Cache File

# cat /var/named/named.ca;NAME TTL CLASS TYPE RDATA. 9999999 IN NS sys99.ibm.com.sys99.ibm.com. 9999999 IN A 9.19.93.99

# cat /var/named/named.ca;NAME TTL CLASS TYPE RDATA. 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

- OR -




Uempty

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.

Final Slave Name Server Setup Steps


Configure hostname, if neededredhat# vi /etc/sysconfig/networksuse# vi /etc/HOSTNAME


Start namedredhat# service named startsuse# rcnamed start



Student Notebook

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.

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 "." {


};




Uempty

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.

Managing Your Nameserver

Management of the name server daemon is done via the network with the rndc utility

Need to configure authentication keys firstIn /etc/named.confIn /etc/rndc.conf

Generate keys with rndc-confgenMost distributions configure rndc keys during install

When configured, use rndc to:Reload configuration files and zone dataWrite server statistics to statistics fileDump the active databaseStop the serverRetrieve the server statusChange debugging levelFlush the servers cache



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.




Uempty

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.

Setting Up the Client


Configure hostname, if needed# vi /etc/sysconfig/network# vi /etc/HOSTNAME




Student Notebook

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.

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 nameserversCheck if the normal and reverse lookups match for all systems

Review the /var/named/* filesWatch out for missing dots at the end of an FQDN

Dump the active named database




Uempty

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:

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



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.




Uempty

Figure 7-29. nslookup Noninteractive Queries LX073.2

Notes:

The visual shows examples of noninteractive queries.

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



Student Notebook

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.

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




Uempty

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.

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



Student Notebook

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.

Active Database Dumps

Nameserver retains a lot of information in memoryOwn domain dataCached dataStatistics

All data can be dumped to disk on requestUseful to look at in case of problemsStored in directory identified in named.conf

Dumps are initiated from rndcrndc dumpdb: DNS data to named_dump.dbrndc stats: Statistics to named.stats




Uempty

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.

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.$ORIGIN 98.19.9.in-addr.arpa.1 86400 IN PTR sys1.dc.ibm.com.2 3600 IN PTR sys2.dc.ibm.com.3 86400 IN PTR sys3.dc.ibm.com.4 86400 IN PTR sys4.dc.ibm.com.$ORIGIN 99.19.9.in-addr.arpa.4 86400 IN PTR sys4e.dc.ibm.com.5 86400 IN PTR sys5.dc.ibm.com.$ORIGIN dc.ibm.com.sys4e 86400 IN A 9.19.99.4sys1 86400 IN A 9.19.98.1sys2 3600 IN A 9.19.98.2sys3 86400 IN A 9.19.98.3sys4 86400 IN A 9.19.98.4sys5 86400 IN A 9.19.98.5$ORIGIN ibm.com.sys99 86400 IN A 9.19.93.99



Student Notebook


Notes:


1.

2.

3.

4.

Checkpoint (1 of 2)

1. The TTL of the Standard Resource Records for the name server zone files is specified in:a. Minutesb. Hoursc. Daysd. 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 lastb. It is the reverse translation of IP address to domain namec. 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.




Uempty


Notes:


5.

6.

7.

8.

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.dbb. /var/named/named_dump.dbc. /tmp/named_dump.dbd. 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?



Student Notebook


Notes:

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




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


Notes:

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




Uempty

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.

E-mail Example

[ed@xyz]$ mail [email protected] 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 [email protected] Wed Oct 2 22:28 11/353 "Test Message" & n Message 1: From [email protected] Wed Oct 2 22:28:43 1996 Date: Wed, 2 Oct 1996 22:28:42 -0500 From: [email protected] (Ed Smith) To: [email protected] Subject: Test Message Hi there, Fred. & q Saved 1 message in /home/fred/mbox

?



Student Notebook

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.

E-mail Model

User Agent

Queue

Receiver

Message Transfer Agent


Queue

Queue

User Agent

Queue

Sender

mail client

incoming mail servermail client

outgoing mail server

SMTP

SMTP

POP/

IMAP




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

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.

User Agents

Send and receive email on behalf of one userSending using SMTPReceiving using POP, IMAP or reading directly from /var/spool/mail/user

Can store e-mailoutgoingsentincomingreceived

Typical UAs available on Linux:mailelmpinenetscapeevolution




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

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.

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




Uempty

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.

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: [email protected] 250 [email protected]... Sender is valid.

RCPT TO: [email protected] 250 [email protected]... Recipient is valid.

DATA 354 Enter mail. End with the . character on a line by itself.

From: Ed Beaver <[email protected]>

To: Fred Flintstone <[email protected]>

Subject: Test Message

Hi there, Fred.

. 250 Ok

QUIT221 mailgate.abc.com: closing connection.

Connection closed by foreign host.



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.




Uempty

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.


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



Student Notebook

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 theMX value is higher than its own. That way, the message will end at the main MTA for a domain eventually.

Deliver to which MTA?

Dependent on MX records in DNS

An MX record defines the mail exchanger for a domain

Sending MTA algorithm:Try MTA with lowest preference valueIf not reachable, try next lowestRepeat until no mail exchanges leftTry to connect directly to "host"

Sender and all intermediate MTAs use same algorithm

# 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.

.




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

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.

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




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

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

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 <[email protected]>

To: Fred Flintstone <[email protected]>

Subject: Test Message

Hi there, Fred.

.

dele 1 +OK message deleted

quit +OK Sayonara




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

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.

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 directoryMay be subject to quota




Uempty

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.

Linux E-Mail Implementation

Queue

Receiver

Sendmail

Postfix

/var/spool/

mqueue

Evolution,

kmail, ...

Queue

Sender

mail client

incoming mail servermail client

outgoing mail server

SMTP

SMTP

POP/

IMAP

Evolution,

kmail, ...

/var/spool/

mail/userid

pop3d,

imapd,

...

/var/spool/

postfix/*



Student Notebook

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.

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 complicatedCan act as mail filterCan act as mail gatewayCan act as mail relay




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

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.

/etc/mail/sendmail.cf

Difficult syntaxOptions always start with OMacros always start with DClasses always start with CComments always start with #...and so forth

Can be configured directly or by using m4 macrosUsed to initially create sendmail.cfSome people only edit sendmai.mc, not sendmail.cf

sendmail.mc

predefined macros in

/usr/share/sendmail-cf

m4 sendmail.mc >sendmail.cf

sendmail.cf




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 #.




Uempty

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

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-mailCwxyz.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



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.




Uempty

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.

Postfix Daemon

Alternative to Sendmail

Default MTA in SuSE

Configuration files in /etc/postfixMain configuration file /etc/postfix/main.cf

Various queues in /var/spool/postfixDifferent 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)



Student Notebook

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




Uempty

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 [email protected]. With the myorigin option set, Postfix will rewrite this to [email protected].

/etc/postfix/main.cf

Main postfix configuration file

Well documented

Important configuration options:myhostname = my hostnamemydomain = my domainmyorigin = $mydomaininet_interfaces = allmydestination = $myhostname, $mydomain



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.




Uempty

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 [email protected]. Thus, fred can be used as an address in mail sent from this host and it will be transformed to [email protected]. 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.

Aliases

Define alternative names for mail addresses

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: [email protected]

Can cause commands to run:joe-fax: | /usr/local/bin/fax-it

$ cat /etc/aliases

Postmaster: root

fred: [email protected]

penpals: fred, joe, [email protected]



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.




Uempty

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 [email protected]

• 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.

User-Defined Forwarding

.forward file in user's home directory defines forwarding list:

Applies only to mail for particular user

[[email protected]]$ cat .forward

[email protected]

joe

| "cat >>~fred/forwarded-mail"



Student Notebook

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 [email protected] is forwarded to colin on the local system, and mail for [email protected] is forwarded to [email protected].

• 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 [email protected], regardless of the username.

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:[email protected] [email protected] [email protected]@dairy.org [email protected]@artist.org [email protected]

For reverse-mapping of outbound mail, use /etc/mail/genericstable (Sendmail) or /etc/postfix/sender_canonical (Postfix)colin [email protected]

After modification, run make (Sendmail) or postmap (Posfix)




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 [email protected] is forwarded to [email protected], 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

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/*.

Implementing POP3 or IMAP

Install daemonsRed Hat: Both ipop3 and imap contained in imap RPMSuSE: qpopper RPM and imap RPM

Both run out of [x]inetdShould be enabled

Both use regular Linux username/passwordsMay 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 directorySubject to quota, if configured




Uempty

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 SSL5 SSL is now standardized under the name TLS (Transport Layer Security). However, everybody still uses the name SSL.

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 certificateEnable pop3s and imaps service in xinetd

To implement in SuSE:Install sslwrap RPMObtain official certificate via certificate authority, or create self-signed certificateConfigure pop3s or imaps service using sslwrap



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.




Uempty

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.

Mailing Lists

Mailing List: Group of mail users interested in the same subject.

By sending mail to a special mail address, it reaches allA "moderator" manages the list: approves subscriptions and posts, if required

Several programs available for Linux implementing this:Majordomo, Majordomo2SmartmailMailman

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



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!




Uempty


Notes:


1.

2.

3.

Checkpoint

1. A program that transmits e-mail from one system to another is called a:a. User agentb. Message transfer agentc. SMTP agentd. SNMP agente. Sendmail transmission agent

2. The command that starts an SMTP transaction and identifies the message sender is:a. HELOb. EHLOc. DATAd. MAILe. RCPT

3. T/F. Each hop between relay MTAs involves a separate SMTP session.



Student Notebook


Notes:

Unit Summary

The Linux e-mail system contains of User Agents and MTAs

The User Agent can be chosen by the users themselvesThe 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 systemreceives messages from UAs and other MTAsfilters e-mail messagesexpands aliasescarries out delivery




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


Notes:

Objectives


Describe the purpose and operation of DHCP

Configure DHCP clients

Configure DHCP servers




Uempty

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.

Host Configuration

StaticIP configuration stored on local storage medium (disk, EEPROM, ...)Requires one IP address for every machineRequires local configuration on each systemTypically used for servers

DynamicIP configuration assigned by serverRequires one IP address for every active machine onlyDoes not require any local configurationTypically used for clients



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.




Uempty

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.

Dynamic Host Configuration Protocols

Reverse ARP ProtocolRFC 903IP address onlyIP address statically linked to MAC addressLink level protocol - not routable

Bootp ProtocolRFC 951Every conceivable IP option (address, subnetmask, DNS, routers, ...)IP address statically linked to MAC addressUses UDP - routable

DHCP ProtocolRFC 2131 and 2132Downwards compatible with BootpIP address dynamically assigned with lease time



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.




Uempty

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 IPaddress. This prevents people from having a permanent, static IP addresses and thus from building servers.

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 leaseRenew the lease

All lease times are expressed as offset from now in seconds

Prevents against problems when clocks are out of sync



Student Notebook

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.

DHCP Client-Server Interactions

DHCP Server

DHCP Client

DHCP Relay1. DHCPDISCOVER

2. DHCPOFFERs

3. DHCPREQUEST

4. DHCPACK

DHCP Server




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

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.

Server

DHCPREQUEST

Graceful shutdown

DHCPRELEASEDiscards lease

ClientT1 (0.5*

duration oflease)

Renewing State

T2 (0.875*duration of lease) DHCPREQUEST

(broadcast)

(unicast)

[Init State]

DHCPDISCOVER

DHCPACK

[Rebinding State]

[commitsconfiguration]

[ignoresrequest]

[ignoresrequest]

or

LeaseExpires

[commitsconfiguration]

or

DHCP Renewal




Uempty

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.

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



Student Notebook

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.

Linux DHCP Implementation

Linux as a DHCP clientdhcpcdpumpdhclient

Linux as a DHCP relayISC dhcprelay

Linux as a DHCP serverISC dhcpd




Uempty

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, ...).

Linux DHCP Clients

dhcpcdBasic syntax: dhcpcd [interface]Results stored in /var/lib/dhcpcd directoryDoes not work on Token Ring networks

Red Hat pumpBasic syntax: pump [-i interface] Configuration file /etc/pump.confWorks with Token Ring networks too

ISC dhclientBasic syntax: dhclient [interface]Configuration file /etc/dhclient.confResults 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



Student Notebook

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.

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.leasesBackup: dhcpd.leases~Server will not start if the state file is not present

The server is started as any other servicercdhcpd startservice dhcpd start




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

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.

Sample /etc/dhcpd.conf File

# cat /etc/dhcpd.confoption 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 {}




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

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.

DHCP Considerations

Every dynamic IP address needs a DNS entryRegular 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 rangeMake 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




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

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.

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

ddns-update-style interim;

key DHCP_UPDATER {

algorithm hmac-md5;

secret "pRP5FapFoJ95JEL06sv4PQ==";

};

zone example-company.com. {

primary 10.1.1.3;

key DHCP_UPDATER;

}

zone 1.1.10.in-addr.arpa. {

primary 10.1.1.3;

key DHCP_UPDATER;

}

# vi /etc/named.conf

key DHCP_UPDATER {

algorithm hmac-md5;

secret "pRP5FapFoJ95JEL06sv4PQ==";

};

zone example-company.com. {

type master;

file "named.example-company.com";

allow-update{ DHCP_UPDATER; };

}

zone 1.1.10.in-addr.arpa. {

type master;

file "named.10.1.1";

allow-update{ DHCP_UPDATER; };

}




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

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.

Troubleshooting DHCP

If server won't start at all:Check syntax of /etc/dhcpd.confCheck existence of state file

Check server log file (/var/log/messages)

Check server leases file (/var/lib/dhcp/dhcpd.leases)

Check client IP address assignmentWin9x: winipcfgWinNT/2000: ipconfigLinux: pump -s, dhcpcd -s, ifconfig

Verify time on systems is synchronized

Check DHCP packet exchange with a sniffertcpdumpethereal




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


Notes:


1.

2.

3.

4.

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. DHCPACKb. DHCPREQUESTc. DHCPREPLYd. DHCPRELEASEe. DHCPDISCOVERf. DHCPOFFER




Uempty


Notes:

Unit Summary

It is very useful to configure IP clients dynamicallyNo local configuration necessaryLess 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



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:

• Checkpoint questions • Exercises


© Copyright IBM Corp. 1999, 2003 Unit 10. Network File System 10-1

Student Notebook


Notes:

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




Uempty

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.

Sharing Data on a Network

Data

NFS ServerNFS Client

NFS Client

NFS Client



Student Notebook

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.

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 directoryThe client "mounts" an NFS exported directory

NFS is stateless:Server does not remember anything about transactionsClient is not notified when server is downNo system recovery procedures




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

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.

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

mount request

kernel

portmap

rpc.mountd

Server

(port 111)

call to portmap

returns mountd port #

mount request

OK - passes file handle

1

3

2

5

Client




Uempty

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.

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

System Calls

vfs

Linux disk

filesystem

NFS client

routines

disk RPC/XDR

UDP/IP

vfs

Linux disk

filesystem

NFS server

routines

diskRPC/XDR

UDP/IP

Client Server

network



Student Notebook

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 authenticationphase.

How NFS Shared Files are Protected

NFS does not do any authenticationUser credentials (UID, GID) on the client are also used on the serverEnsure that UIDs, GIDs, usernames and group names are synchronized!

NFS relies on Linux authorizationUID/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")




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

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.

UNIX Authorization - User

sys1

sys3

/home/mntpt

file1 file2

/etc/passwdteam01 208, 1... team02 209, 1...team03 210, 2...

ls -ln /home/filesrwxrw---208, 1 file1rwxrw---208, 1 file2

/etc/passwdteam04 208, 1...

RPC requestUID GID

vi /home/mntpt/file1

SERVER

CLIENT

A user uses the same UID on the client and on the server




Uempty

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.

UNIX Authorization - Root

sys1

sys3

/home/mntpt

file1 file2

/etc/passwdroot:!:0:0

ls -l /home/filesrwxrw---208, 1 file1rwxrw---208, 1 file2

/etc/passwdnobody:x:99:99:Nobody:/:

RPC requestUID GID

vi /home/mntpt/file1

SERVER

CLIENT

The root user is by default mapped to the nobody account



Student Notebook

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.

Configuring the Server

Identify what to export

Add all exports to /etc/exports file

Start portmap

Start NFS server daemonsrpc.mountd: Satisfies mount requestsnfsd: Performs actual file operations (open, close, read, write)

Add NFS to system startup




Uempty

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.

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)



Student Notebook

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.

Configuring the Client

Create mount point (empty directory)

Mount NFS filesystems

Add NFS filesystems to /etc/fstab, if needed




Uempty

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.

Manual Remote Mount

sys1

/

home

mntpt

NFS Client

Mount Point

sys3

/

home

files

NFS Server

Exported Directory

file 1

file 2

# mount sys3:/home/files /home/mntpt



Student Notebook

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.

Predefined Mounts

All predefined mounts are listed in /etc/fstab

Mounted automatically at system startupAfter 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




Uempty

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.

NFS Mount Options (1)

Option Function Default

autonoauto

Mount automatically when mount -a is issued

auto

devnodev

Interpret special devices dev

execnoexec

Allow execution of executables exec

suidnosuid

Allow SUID and SGID bits to have effect

suid

usernouser

Allow ordinary (non-root) users to execute the mount

nouser

rorw

Read-only/Read-write rw



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.




Uempty

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.

NFS Mount Options (2)

Option Function Default

bg Mount attempted in background if first attempt fails

fg All mount attempts done in foreground

Yes

soft Repeated RPC calls eventually timeout

hard RPC calls try indefinitely until server responds

Yes

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 retransmission (in 1/10 of a second)

7

retrans Number of retransmissions 3

retry Number of minutes to retry read/write on hard mounted filesystems

10000



Student Notebook

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.

Useful Commands

rpcinfo queries what rpc services are availablerpcinfo -p host shows all rpc services on host

exportfs maintains table of current exportsexportfs -a re-reads /etc/exportsexportfs -u un-exports exports

showmount shows what an NFS server has exportedshowmount -a shows all actual mountsshowmount -e host shows the exports on host




Uempty

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

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



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.




Uempty

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.

Troubleshooting NFS Problems

Verify export list in /etc/exports

Verify that all server-side daemons are startedportmapnfsdrpc.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



Student Notebook


Notes:


1.

2.

3.

4.

5.

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?




Uempty


Notes:

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



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 • Checkpoint questions


© Copyright IBM Corp. 1999, 2003 Unit 11. NFS Automounter 11-1

Student Notebook


Notes:

��

��

'�� !��

j��*�� j� �`

��

��




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

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.

#��!�� !��@�%��

@��J�� !� �� !�� * ��Q��

@�� !��Q��`�� !��

��Q�� J�!��

!��;��




Uempty

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.

0��7�!��

��'�� K��%'�� #� �� [�� %�� !�� Y�� Z�Y��Z�Y��Z¡�� !�� +

��@�*�� !�� +�� !� �*�� !�� !

[�� Q��



Student Notebook

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.

!�%��:�$�� *��

��

��

��V��"��

��V��@�"��

��V��

��V�U��

�"�C��V��"��U�

��

��V��




Uempty

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.

!�%��"��$�

��

��7 �U�M��®"��M��U��®"��M��7

�� U�M��®"��M��U��®"��M��

�� U�M��®"��M��U��®"��M��



Student Notebook

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.

4��!�%

¢� �� *� ��

�� K�� !�

J�<#�J

¢�� *��

� �� J��




Uempty

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.

!�%��!��

�U�7�� "�

�U�7��

��@��7��U��*"C>

��"� ��U��"� �*"C>

�U�7M*��7��+>��U��*"C��" �� >��

�U�7�� 7

�U�7��

��@��7��U��*"C>

��"� ��U��"� �*"C>

�U�7M*��7��+>��U��*"C��" �� >��

�U��M��7��U��7��U��*"C>



Student Notebook

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.

!�%��"��

� �

��

�!�_�� !��Q��

��`_�!��

��

��`_

��

�� !��

�� +




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

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.

!��"��$�

��

��7 �U��M��7

�� U��M��

�� U��M��




Uempty

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.

4��!��

�� *� ��

�� K�� !�

��&��

�� $�� *��

� �� J��



Student Notebook

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.

!��!��

�U�7�� "�

�U�7��

��@��7��U��*"C>

��"� ��U��"� �*"C>

��*��77�>��U��*"C>��

�U�7�� 7

�U�7��

��@��7��U��*"C>

��"� ��U��"� �*"C>

��*��77�>��U��*"C>

�U��M��7��7��U��*"C>




Uempty

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.

!��

� �� *��!�} �� !�� #��Q��!�� '�



Student Notebook


Notes:


1.

��"��

_K ��!�� *��

�K � �� £££ �� *�� !��

�K �� £££ ��

�K �� £££ �� *�!��|�� @�%�� K

�




Uempty


Notes:

3��4��

� �� !�� !��

��'�� *��

�� *��

[��!��

�� @�%��

��!��Q�� Q�� *��



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


Notes:


Define the purpose of NIS

Define NIS terminology and daemons

Configure an NIS Master Server, NIS Slave Server and NIS Client

Objectives




Uempty

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.

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

Distributed Environment Concerns



Student Notebook

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.

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

How NIS Addresses Distributed Environment Concerns




Uempty

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.

root:!:0:0::/root:/bin/bashtux1:!:203:2::/home/tux1:/bin/bashtux2:!:204:2::/home/tux2:/bin/bashtux3:!:205:2::/home/tux3:/bin/bash

root:!:0:0::/root:/bin/bashtux4:!:205:2::/home/tux4:/bin/bashtux5:!:206:2::/home/tux5:/bin/bashtux3:!:207:2::/home/tux3:/bin/bash

root:!:0:0::/root:/bin/bashtux1:!:203:2::/home/tux1:/bin/bashtux2:!:204:2::/home/tux2:/bin/bashtux4:!:205:2::/home/tux4:/bin/bashtux5:!:206:2::/home/tux5:/bin/bashtux3:!:207:2::/home/tux3:/bin/bash

NFS Server-sys1

/etc/passwd

NFS Client-sys2

/etc/passwd

NFS Client-sys3

/etc/passwd

NFS and /etc/passwd



Student Notebook

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.

NIS Centralized Control of /etc/passwd

root:!:0:0::/root:/bin/bash

NIS Master Server-sys1

/etc/passwd

NFS Client-sys3

/etc/passwd

root:!:0:0::/root:/bin/bash

tux1:!:203:2::/home/tux1:/bin/bash


tux4:!:205:2::/home/tux4:bin/bash



DBM FORMAT

passwd map

/etc/nsswitch.conf

passwd: files nis




Uempty

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.

NIS Centralized Control of /etc/group

root::0:root

NIS Master Server-sys1

/etc/group

NFS Client-sys3

/etc/group

root::0:root

students::1:me,you

pinguins::2:tux1,tux2,tux3,tux4,tux5DBM FORMAT

group map

/etc/nsswitch.conf

group: files nis



Student Notebook

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.

NIS Systems

NISMaster Server

NISSlave Server

Stores copies of

maps

Answers client requests

Stores copies of

maps

Answers client requests

Creates, maintains

maps

Answers client

requests

Requests and

receives info

from maps

Requests and

receives info

from maps

NIS Client NIS Client

Transfer Maps Transfer Maps

NISSlave Server




Uempty

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.

NIS Binding

/var/yp/binding/accounting.version - address of server

Broadcast -needserver foraccountingdomain

1

3

I'm availablefor accountingdomain/var/yp/accounting

2

sys1

ypbind

ypserv

NIS Server

sys3



Student Notebook

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.

System Default NIS Data Maps

File

/etc/passwd/etc/group/etc/hosts/etc/aliases/etc/netgroup/etc/protocols/etc/rpc/etc/services/etc/netid/var/yp/ypservers

Contains

User names, user IDs, and passwordsUser groupsHost names and IP addressesAliases and mailing lists for the mail systemNetgroup definitions (used by NIS)Network protocol names and numbersRemote procedure call program numbersNetwork port numbers and service namesID info for machine, hosts, and groupsNIS servers




Uempty

Figure 12-10. NIS Configuration Scenario LX073.2

Notes:

The visual shows the scenario we're going to use in the next few visuals.

NIS Configuration Scenario

Bigbucks Accounting Firm

NISMaster server, clientsys1

NISSlave server, clientsys2

domainname=accounting

/var/yp/accounting


/var/yp/accounting

NISclientsys3




Student Notebook

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.

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




Uempty

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

NIS Domain Name - Master Server

Need to set the domain name before anything

# domainname accounting

# domainname

accounting

Configure system to set domainname at rebootRed Hat: authconfig (modifies /etc/sysconfig/network)SuSE: yast (modifies /etc/yp.conf and /etc/defaultdomain)



Student Notebook

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.

Editing NIS Master Server /etc/passwd File

root:!:0:0::/:






May also need to edit /etc/group

Ensure that it is complete and non-ambiguous




Uempty

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.

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



Student Notebook

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.

To initialize the master server and test everything:

Make sure daemons are started at bootup

Final Master Server Configuration Steps

# /etc/init.d/ypserv start

# /usr/lib/yp/ypinit -m

(answer all questions)

# chkconfig ypserv on

# chkconfig ypbind on

# chkconfig yppasswdd on




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

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.

Contents of the NIS Domain Directory

All DBM map files stored in /var/yp/domainname

Each DBM map is sorted by a keyAllows for fast lookups in large tablesIf 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

.

.




Uempty

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.

NIS Slave Server Configuration Overview

Set NIS Domainname


Transfer NIS maps from master server

Start daemons



Student Notebook

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.

NIS Domain Name - Slave Server



# domainname

accounting





Uempty

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.

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 groupsGroups needed in case of master server failure

Edit /etc/hosts to include only: Loopback entry Entry for this hostEntry for other vital hosts



Student Notebook

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.

Configuring NIS Slave Server

To initialize the slave server and test everything:

Make sure daemons are started automatically on startup

Ensure that maps are updated regularly: add to crontab:

20 * * * * /usr/lib/yp/ypxfr_1perhour40 6 * * * /usr/lib/yp/ypxfr_1perday55 6,18 * * * /usr/lib/yp/ypxfr_2perday

# /etc/rc.d/ypbind start

# ypwhich

# /etc/rc.d/ypserv start

# /usr/lib/yp/ypinit -s sys1

.

# chkconfig ypbind on

# chkconfig ypserv on




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

Figure 12-21. NIS Client Configuration Overview LX073.2

Notes:

The visual shows the configuration steps for the client.

NIS Client Configuration Overview

Set NIS Domainname


Start daemons




Uempty

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.

NIS Domain Name - Client



# domainname

accounting




Student Notebook

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.

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




Uempty

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.

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



Student Notebook

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.

Updating NIS Passwords with yppasswdd

$ yppasswdChanging NIS password for tux1 on sys1Old NIS password:New password:Retype new password:NIS password changed on sys1

NIS Master Serversys1

yppasswdd

/etc/passwd

make

rebuildpasswd

map

yppush

all slaves

NIS Clientsys2

Also available:

ypchsh

ypchfn




Uempty

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.

Updating NIS Maps

After updating /etc/passwd:

# cd /var/yp

# make passwd

.

# yppush passwd



Student Notebook

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.

NIS Master Server

Downlevel Slave Server Maps

update map

make

rebuild map

UpdatedMap

UpdatedMap

EarlierVersion

Slave3(down)

Slave2ypxfr

Slave1ypxfr

yppush

Cron jobs running ypxfr can keep slave maps current




Uempty

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:

NIS Programs Overview

Activity Client Slave Server Master Server

Initial setup domainname domainnameypinit -s

domainnameypinit -m

Bind to serverSet server to bind toShow server bound to

ypbindypset

ypwhich

ypserv ypserv

Match entriesView mapView map information

ypmatchypcatyppoll

ypserv ypserv

Change passwordChange shellChange name

yppasswd

ypchshypchfn

yppasswdd

Transfer maps ypservypxfr

yppushypservypxfrd



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.




Uempty

Figure 12-29. Troubleshooting NIS Problems LX073.2

Notes:

The visual shows some checks you can perform when troubleshooting NIS problems.

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 boundCheck /etc/nsswitch.confRead contents of map file with ypcat and ypmatch



Student Notebook


Notes:


1.

2.

3.

4.

5.

6.

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 networkb. NIS domainc. TCP/IP domaind. NIS master server

3. How many NIS Master Servers can there be per NIS domain?a. 1b. 2c. 3d. 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/legalb. /legalc. /usr/var/yp/legald. /etc/legal

6. T/F. NIS maps are created from text input files.




Uempty


Notes:

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/hostsSet the domain nameInitialize NIS

Updating existing data maps uses the make utility to re-create the target maps using updated source ASCII files as input



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


Notes:

Objectives

Describe the basic principles of LDAP

List different LDAP servers

Install and configure the OpenLDAP server

Configure Linux to use LDAP authentication




Uempty

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

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 directoryLibrary card catalog



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.




Uempty

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

Directories vs. Relational Databases

Directory Relational Database

Examples LDAP, X.500, Microsoft Active Directory

DB2, Oracle, PostgreSQL

Keyspace Hierarchical LinearData Loosely structured Strictly structuredOptimized for Lookups UpdatesSecurity model Simple ComplexTables One or more,

unrelatedTypically more, related

Atomic transactions possible?

No Yes

Replication between systems

Easy because inconsistency is (temporarily) allowed

Hard: inconsistency not allowed

Way of accessing information

Simplified and optimized access protocol (LDAP)

Structured Query Language (SQL)



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.




Uempty

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”.

LDAP Concepts (1)

LDAP objects are described using attributese.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 attributee.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



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.




Uempty

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.

LDAP Concepts (2)

(Directory Root)

C=US

O=IBM

OU=IT Education Services

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

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

C=CA C=NL

O=IBM O=IBM O=IBM



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”.




Uempty

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.

The "Core" Schema

Set of schema defined in various RFCs

Form the default building blocks of an LDAP directory

Attributes defined:cn: Common namesn: Surnamec: Country...

ObjectClasses defined:countryorganizationpersonorganizationalPerson...

Defines required/optional attributes for each ObjectClass



Student Notebook

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

LDAP Authentication

While connecting to an LDAP server ("binding"), authentication is performed against the LDAP directory

Three methods:No authenticationBasic authentication

DN/PasswordSimple Authentication and Security Layer (SASL)

Framework for adding additional authentication mechanismsTypically uses SSL/TLS




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

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

LDAP Servers

OpenLDAPOpen-Source implementationDefault LDAP server in Linux

IBM SecureWay DirectoryUsed 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




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

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.

LDAP Clients for Linux

OpenLDAPSuite of standard LDAP client tools: ldapadd, ldapmodify, ...

gq: Graphical LDAP clientNot 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




Uempty
auth_ldap is a set of modules for Apache that allow you to use LDAP for Apache authentication.


Student Notebook

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.

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




Uempty

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.

The OpenLDAP Server

OpenLDAP Servers:slapd: Service daemonslurpd: Replication daemon

slapd configuration file: /etc/openldap/slapd.confSchema to use (stored in /etc/openldap/schema)Backend database to useBase DN of directoryRoot DN and password of directory

slurpd configuration file: /etc/openldap/slapd.confReplica information



Student Notebook

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.

/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 ...




Uempty

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.

Converting UNIX Authentication Info

Done using a set of conversion tools from www.padl.com

Typically stored in /usr/share/openldap/migrationSuSE does not include these scripts - need to download and install manually

Edit migrate_common.ph firstChange $DEFAULT_MAIL_DOMAIN and $DEFAULT_BASE

Run migrate_all_offline.shMight need to touch /etc/netgroupMight need to comment out some entries in /etc/protocols and /etc/services

All LDAP files are now in /var/lib/ldapMight need to chown ldap.ldap /var/lib/ldap



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.




Uempty

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.

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



Student Notebook

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.

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




Uempty

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.

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)



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.




Uempty

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).

LDAP Replication

First copy all files in /var/lib/ldap to slaves manually

Updates on master propagated by the slurpd daemonUses in-band transfers (regular LDAP updates)

Requires the following in the master slapd.conf:# General sectionreplogfile /var/lib/ldap/master-slapd.replog

# Directory sectionreplica 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 sectionupdatedn "cn=Manager,dc=ibm,dc=com"updateref ldap://ldap-master.ibm.com



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.




Uempty

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.

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



Student Notebook


Notes:

Write your answers here:

1. Differences

a.b.c.

2.

3.

4. Steps:

a.b.c.d.

5.

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.




Uempty


Notes:

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



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 • Machine Exercises


© Copyright IBM Corp. 1999, 2003 Unit 14. The Network Time Protocol (NTP) 14-1

Student Notebook


Notes:

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




Uempty

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

Why Time Synchronization

DHCP lease times

Kerberos tickets

Logfile synchronization

Bug tracking

Network monitoring



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.




Uempty

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).

The Network Time Protocol (NTP)

RFC 1129

Synchronizes time between systems

µsec precision



Student Notebook

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.

Sources of Time

Directly connected atomic clockHighest precision but really expensive

Radio Time ReceiverReceivers fairly expensivePrecise

Global Positioning System (GPS) Satellite ReceiverCheapReception problem: does not work indoors

Another NTP serverAdds incremental error

Internal PC clockUseful if no other sources are available




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

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.

Stratum

The stratum number identifies how far you are from the time source.

The maximum stratum is 15

receiver

sender

time client time client time client

"stratum 0"

"stratum 1"

"stratum 2"

"stratum 3"

time server

time server time server




Uempty

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.

NTP Communications Methods

Unicast

Broadcast using local broadcast address

Multicast using IANA reserved address 224.0.1.1



Student Notebook

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.

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 clientConfiguration file /etc/ntp.conf

ntpq: Queries a time server

Various other supporting programs

Excellent documentation in /usr/share/doc/ntp-version




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

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.

/etc/ntp.conf Configuration File

Configures ntpd daemon

Most common directives:server <ip address>: Connect to server with lower stratumpeer <ip address>: Synchronize with peer of equal stratumfudge <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 addressmulticastclient: Listen to multicast address 224.0.1.1driftfile <filename>: File where local clock drift is stored




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

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.

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 typeu indicates the connection (such as serial port)

Examples:server 127.127.1.0: Local PC clockserver 127.127.20.0: GPS receiver conforming to NMEA protocol on ttyS0




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 standarddescribes the output format of GPS receivers, so that this can be used by autopilots and other navigational equipment.



Student Notebook

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.

NTP Authentication

NTP protocol supports authenticationPrevents hackers from simulating a time server with incorrect timeNo replay attacks possible

Not used often




Uempty

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.

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



Student Notebook


Notes:


1.

2.

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.




Uempty


Notes:

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



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


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.




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




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


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:

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.

CourseCompTIA LPI Red Hat

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.


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


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


Uempty

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.

3��'��$

@@��

@@��

@@��

@@��

@@��@@��

@@��

@@��

@�*��Q��*��

�� *��

@�*��

�*��Q��Q�� *��+



Student Notebook

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).

'��'��$

#��

}�� J��Q�� Q��J��Q�� @�*�� @�*�� @�*��




Uempty

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.)

'��&��

�� *�� *�

@�*�� j�� *��}��J�� Q��@@��!��*�� *��Q��Q��J��

&`�� + ��@



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




Uempty

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."

'��4��

%�� *�� *��!��!�� Q�� *��

��*� �*�� *��

#��*�� *��Q�� }�� *��*��+�� !��*��

&`�� !�

&`�� @@�� @��@�*��J��



Student Notebook

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.

'��"

��

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

j�� * � �*��

�� *��Q�� *�� J��

@�*�� Q��




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

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.

��'��'��''�

��***K��K��

��J�� @�*��%��Q��

� �� j� �`��

�� *�� K��

@�*�� Q�� *�

��

%��"��$� �� *�� "�� 7�� *�� *��Q�� *��




Uempty

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

�� *��

�@@��

�� Q�� ¥'@�� ¥'@��'�� *�� "��$�� *�� ^��@��*�� <�� %� ��$��&J��

�� !��+



Student Notebook

is the fallback address, usually %[email protected], 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.




Uempty

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.

�� *��

'��*�!�� +��"��$�� !�� *�� *�� *�� J��

�� |�� %�� J ��@%��jj��

&`��"��z��C��"��M�`|

�� !��



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.*




Uempty

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.

��'��"

�Q�� *��Q�j��Q�� *��*�� `�� %! ��`��$��$��

�� $�� !�� *�� $�� *�� *��

�Q�� *�� *��j�� *��*�� %! ��`��"��



Student Notebook

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.

��'��

�� *��{��{��Q�� <��@@��Q��<�� J@@��Q��K�K�}}��j��K�K��

�� *�� *�� *��%! ��`��Y��Z�Y�� Z�Y��Z�Y��Z

��%!�� "��[�� *�� $�� "�� *��!�




Uempty

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.

�� *�� K��}��!��"�� *�� @@��

��"��!��"�� Q�+��7��

%! ��`��Y��Z�Y�|� Z�Y�`£��Z�¦Y��Z§��%!�� ¥'@�� *��Q��7��^��`��Q�� 7��

��''��'��



Student Notebook

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.

��5'��5

%��Q��J�� *��*��

'� ��!��

�� *�� *��6#�� $��

%�� Q�� *��Q��Q��*@�*��* ��




Uempty

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.

��''��'��

�� *�� K�� j�� *��%! ��`��Y��Z�¨�¦��§KKK�©

��%!��

��j��¥'@��"��j�� *��*��



Student Notebook

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.

��''��'��

�� *��K�� j��*��*�� *�{��{�� {��{��

&`�� z��M��`��7�� M��Q�� T��7�� |� �� z��"�M��Q�� T��7�� C��"��M��`�|




Uempty

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.

��97"��

� !� �*��!��* �&`��

�� `�� *��

�� *��`��K��%��`��!��!�� *��%! ��`��Y �*��Z�Y��Z�Y+��Z�Y��Z�Y��Z

��"��j�� *��$�� !��}��} �� !��"�� *��+��$��'��*��+��"��`��*��+��



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.

��

�� ª�� *�� @@��!�� *��!��&`��

< �� ª��!��




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

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.

#��"�"��"$��''

� ��@@�#��

�� *�� K��

�� *��

�� *��

%��@@

�� *�� $��

j�� Q�� *��




Uempty

Figure C-20. Checkpoint LX073.2

Notes:


1.

2.

3.

��"��

_K �� }�� *��K %��K @@��K �@@�K }��

^K ��K��@�*��*�� *��Q�� !�� K

�K ��££££££££££�� *�K



Student Notebook

Figure C-21. Unit Summary LX073.2

Notes:

3��4��

}�� @�*��*��*��{�� {

}�� *��

@�*�� Q��

��@@�� *��*�� *�� *��Q�� *�� *�� *��Q��

�@@�� *��Q��




IX
Index
Symbols$DISPLAY 3-15$HOME/.xinitrc 4-15$TERM 3-15.forward 8-33.netrc 3-16, 3-19.plan 3-25.rhosts 3-21, 4-11.rlogin 3-20.shosts 4-11/etc/amd.conf 11-6/etc/auto.master 11-11/etc/dhcpd.conf 9-14, 9-17, 9-18, 9-22/etc/exports 10-12, 10-13/etc/fstab 10-16, 11-4/etc/ftpusers 3-17/etc/HOSTNAME 2-4, 9-21/etc/hosts 1-32, 2-13, 2-14/etc/hosts.allow 3-8/etc/hosts.deny 3-8/etc/hosts.equiv 3-20, 3-21, 4-3, 4-11/etc/inetd.conf 3-5, 3-11/etc/named.boot 7-16/etc/named.conf 7-16, 7-18, 7-37/etc/news/incoming.conf C-19/etc/news/inn.conf C-11/etc/passwd 3-25/etc/ppp/chap-secrets 5-24/etc/ppp/options 5-11, 5-20/etc/ppp/pap-secrets 5-24/etc/resolv.conf 2-13, 2-15, 2-22, 7-29, 7-35, 7-39/etc/rndc.conf 7-37/etc/services 3-15, 8-38/etc/shosts.equiv 4-11/etc/sysconfig/network 2-4/etc/xinetd.conf 3-11/etc/xinetd.d 3-10, 3-11/usr/lib/yp/ypinit 12-16

-m option 12-16-s option 12-22

/var/lib/news/active C-15/var/lib/news/newsgroup C-15

Numerics127.0.0.1 1-21, 7-17

AA 7-6Acknowledgement 1-31Address Resolution Protocol 1-9, 1-12

Course materials may not be rwithout the prior writte

© Copyright IBM Corp. 1999, 2003

airsnort 2-9aliases 8-31AMD 11-5amd 11-8Anonymous ftp 3-18Apache 3-3ARCnet 1-11ARP 1-9arp 1-13, 2-20ARP reply 1-13ARP request 1-13ARPANET 1-5ARPAnet 3-14ASCII 8-9AT commands 5-9ATM 1-11atomic clock 14-6auth_ldap 13-17authconfig 13-26Autofs 11-5, 11-11avian carriers 1-10AX.25 1-11

BBase DN 13-8Berkeley Internet Name Distribution 7-16Berkeley Software Distribution 1-5BGP 6-19BIND 7-16Bootp 9-6Border Gateway Protocol 6-19broadcast 1-16, 14-9BSD 1-5

Ccaching-only nameserver 7-14, 7-36ccTLD 7-3certification authority 8-37Cesium 14-6Challenge Handshake Authentication Protocol 5-5CHAP 5-5, 5-22chargen 3-13chat 5-8, 5-11, 5-12chmod 5-20Class A address 1-18Class B address 1-19Class C address 1-19clear text 4-3CN 13-8CNAME 7-6

eproduced in whole or in part n permission of IBM.

Index X-1

Student Notebook

Common Name 13-8CompTIA B-1Connection 1-31Connection setup 1-30cp 3-21crond 8-26crtscts 5-12ctlinnd C-15, C-23

DDARPA 1-5date 14-17daytime 3-13decimal dot notation 1-17, 1-20DECnet 5-3default route 2-12, 6-10, 6-16DHCP 1-16, 9-6, 14-3DHCP_HOSTNAME 9-20DHCPACK 9-9dhcpcd 9-12, 9-13dhcpd 9-14, 9-16dhcpd.leases 9-22DHCPDISCOVER 9-8DHCPOFFER 9-8DHCPREQUEST 9-8dig 7-40, 7-41digital certificate 8-37discard 3-13Distinguished Name 13-8dmesg 2-18DN 13-8DNS 1-33, 2-22, 4-3, 7-3DNS server 1-33dnssec-keygen 9-21Domain Name System 1-33, 7-3domainname 12-13dot domain 7-3DSA 4-13Duplicate packets 1-30Dynamic DNS 9-20Dynamic Host Configuration Protocol 9-6dynamic port 1-26dynamic route 6-15Dynamic routing 6-18

Eecho 3-13elm 8-4ethereal 9-23Ethernet 1-11exec 3-13Exim 8-11explicit route 6-15exportfs 10-20

-a option 10-13

Ffailover 9-19Fast Ethernet 1-11Fiber Distributed Digital Interface 1-11File Transfer Protocol 1-7finger 3-3, 3-13, 3-25FQDN 7-3Frame Relay 1-11FTP 1-7ftp 3-3, 3-13, 3-16Fully Qualified Domain Name 1-33, 2-15, 7-3

Ggated 6-19, 6-20gateway 6-5get-lease-hostname 9-18Gigabit Ethernet 1-11Global Positioning System 14-7GPS 14-7gq 13-16, 13-23gTLD 7-3

HHINFO 7-7host 2-22, 7-10, 7-40, 7-41host route 6-9, 6-16hostname 2-4hostnames 1-32http 3-4hwclock 14-17

IIAB 1-6, 4-4IANA 1-18, 1-21, 1-26, 1-27, 3-5IBM Public License 8-27ICMP 1-9, 1-25IEEE 802.11 2-8IETF 1-6ifconfig 2-7, 2-18, 6-15IMAP 8-11, 8-18, 8-36imaps 8-38implicit route 6-15in-addr.arpa domain 7-12inetd 3-4, 3-5, 3-7, 3-13, 8-36INN C-10inn C-7innd C-10innxmit C-10, C-17Internet Architecture Board 1-6Internet Assigned Number Authority 1-18Internet Control Message Protocol 1-9


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

Student Notebook

Internet Engineering Task Force 1-6InterNet News C-10Internet Service Provider 1-10Internet Software Consortium C-10InterNIC 1-18IP 1-9IP address 1-17IP alias 2-10IP Control Protocol 5-4IP forwarding 6-7IP protocol 1-15IPCP 5-4IPX 5-3ISP 1-10, 1-18, 5-3iterative query 7-10iwconfig 2-9iwlist 2-9iwspy 2-9

KKerberos 14-3knode C-6kppp 5-15

LLCP 5-4LDAP 13-7LDAP Data Interchange Format 13-21LDAP replication 13-27LDAP schema 13-11ldapadd 13-16, 13-22ldapdelete 13-16ldapmodify 13-16, 13-27ldapmodrdn 13-16ldapsearch 13-16LDIF 13-21lease 9-7Link Control Protocol 5-4link speed 2-8Link State algorithm 6-19Linux Professional Institute -xvii, B-1Local Area Network 1-12login 3-13Loopback interface 1-11LPI -xviiLPI certification -xviiLPI. See Linux Professional InstituteLX02 B-2LX03 B-2LX07 B-2LX22 B-2LX23 B-2LX24 B-2LX25 B-2

LX26 B-2

Mm4 8-22MAC address 1-12, 1-13mail 8-3, 8-4Mailman 8-39mailx 8-4Majordomo 8-39master nameserver 7-14Message Transfer Agent 8-4mgetty 5-18MTA 8-4, 8-11multicast 14-9multicasts 1-22MX 7-7

Nname resolution 1-32National Marine Electronics Association 14-15NCP 5-4NetBIOS name 9-18, 9-20netmask 1-20netscape 13-16, C-6netstat 2-23

-a option 2-23-n option 2-23-r option 6-13, 6-22

Network Control Protocol 5-4Network File System 1-29network route 6-10, 6-16Network Time Protocol 14-5newsgroup C-8NFS 1-29, 10-3NFS automounter 11-3nfsd 10-12NIS 1-16, 1-32, 12-4NMEA-0183 14-15nn C-6nnrpd C-10NNTP C-3nntpd C-7nntpsend C-10, C-17NS 7-7nslookup 7-40, 7-41nss_ldap 13-16nternet Protocol 1-9NTP 1-16, 9-7, 14-4, 14-5ntpd 14-10ntpdate 14-10ntpq 14-11null-modem 5-28


© Copyright IBM Corp. 1999, 2003 Index X-3

Student Notebook

OOpen Shortest Path First 6-19OpenLDAP 13-16, 13-19OpenSSH 4-6OpenSSL 8-38OSI 1-10OSPF 6-19Out-of-sequence 1-30overchan C-18overchan is C-10

PPacing 1-31PAM 3-17PAN C-6PAP 5-5, 5-22passwd 5-25Password Authentication Protocol 5-5Permanent Virtual Circuits 1-11pine 8-4ping 1-25, 2-21, 6-22

-n option 7-40-R option 6-22

Point to Point Protocol 1-9, 1-14POP 8-11, 8-14POP3 8-36pop3s 8-38port 1-26port number 1-26portmap 10-6, 10-12Post Office Protocol 8-14Postfix 8-11, 8-19, 8-27Postmaster 8-31PPP 1-9, 1-14, 5-3pppd 5-11, 5-12, 5-20, 5-28ProCert -xviiPTR 7-6, 7-12pump 9-12, 9-13PVC 1-11

QQmail 8-11

RRARP 9-5rcp 3-14, 3-21, 3-23, 4-5recursive query 7-10Red Hat B-1Red Hat Certified Engineer B-1Red Hat Certified Technician B-1redhat-config-network 2-9, 9-20Request For Comments 1-6resource record 7-6

Reverse ARP 9-5reverse DNS lookups 3-7, 7-12rexec 3-19RFC 1-6, 4-4

1034 7-31035 7-31123 8-311129 14-51149 1-101332 5-41661 5-41662 5-41996 7-302132 9-11821 8-8822 8-8977 C-4

RHCE. See Red Hat Certified EngineerRHCT. See Red Hat Certified TechnicianRIP 1-16, 6-19RIPv2 6-19rlogin 3-14, 3-20, 3-22rn C-6rndc 7-37, 7-46

dumpdb command 7-46stats command 7-46

rndc-confgen 7-37root privileges 1-27root server 1-33root squashing 10-11route 2-12, 2-19, 6-13, 6-15, 6-16, 6-22

-ee option 6-13Route Information Protocol 6-19routed 6-19, 6-20router 6-5routing daemon 6-15, 6-18routing table 1-15, 6-5, 6-9, 6-18rp3 5-15rpc.mountd 10-6, 10-12, 10-13rpc.nfsd 10-13rpc.rquotad 10-21rpc.statd 10-21rpc.yppasswdd 12-17rpc.ypxfrd 12-30rpcinfo 10-20RR 7-6RSA Challenge-Response Authentication 4-12RSA challenge-response authentication 4-11rsh 3-14, 3-22, 4-5rsync 3-23

SSamba 3-3, B-3SASL 13-13scp 4-4, 4-8



Student Notebook

secure port 1-27Secure Sockets Layer 8-37Sendmail 8-11, 8-19, 8-20sendmail.cf 8-22sendmail.mc 8-22Serial Line IP 1-9, 1-14Service Set IDentifier 2-8showmount 10-20Simple Authentication and Security Layer 13-13slapadd 13-22slapd 13-19slapd.conf 13-20slave nameserver 7-14, 7-31SLIP 1-9, 1-14slurpd 13-19, 13-27Smartmail 8-39SMTP 8-9, 8-11SNA 5-3SOA 7-7socket 1-27SSH 4-4ssh 3-24, 4-4, 4-7ssh-add 4-15ssh-agent 4-14sshd 4-4, 4-9SSID 2-8SSL 8-37sslwrap 8-38static route 6-15, 6-17stratum 14-8Subnet Mask 1-20, 1-23SUN Microsystems 10-4SVC 1-11Switched Virtual Circuits 1-11

TT.J. Watson Research Center 8-27talk 3-3, 3-13, 3-25, 3-26TCP 1-8, 1-27, 1-30tcpd 3-7, 3-10tcpdump 9-23telnet 3-3, 3-13, 3-15time 3-13Time To Live 6-23timeconfig 14-17tin C-6TLD 1-33, 7-3TLS 8-37Token Ring 1-11Top Level Domain 1-33, 7-3traceroute 6-23Transmission Control Protocol 1-8Transport Layer Security 8-37trn C-6TTL 6-23

UUDP 1-8, 1-27, 1-28unicast 14-9UnitedLinux B-1Usenet News C-3User Agent 8-4User Datagram Protocol 1-8

Vvector distance algorithm 6-18Verisign 8-38VFS 10-7virtual file system 10-7

Wwebmin 2-3well-known ports 1-26WEP 2-8WEP keys 2-9Wietse Venema 8-27Wired Equivalent Privacy 2-8Wireless LANs 1-11wireless LANs 2-9wireless network adapters 2-8

XX Window System 7-17X.25 1-10xinetd 3-10, 8-36, 8-38

Yyast 2-9ypbind 12-9, 12-16, 12-22, 12-27, 12-31ypcat 12-18, 12-30, 12-32ypchfn 12-28, 12-32ypchsh 12-28, 12-32ypinit 12-31ypmatch 12-32yppasswd 12-28, 12-32yppasswdd 12-23, 12-28, 12-32yppoll 12-32yppush 12-23, 12-29, 12-32ypserv 12-16, 12-31, 12-32ypset 12-9, 12-23, 12-31ypwhich 12-9, 12-22, 12-23, 12-31ypxfr 12-30, 12-32

Zzebra 6-19, 6-21zone transfer 7-14


© Copyright IBM Corp. 1999, 2003 Index X-5

Student Notebook



V3.0

backpg
Back page

��®

linux network administration i, tcp-ip and tcp-ip services - student notebook (ibm learning, 2003,...

Documents

copyright ibm

ip protocol

united states

tcpip configuration

tcpip concepts

tcpip layering

inetd daemon

arp protocol