Review
Product Description
This complete guide to setting up and running a TCP/IP network is essential for network administrators, and invaluable for users of home systems that access the Internet. The book starts with the fundamentals -- what protocols do and how they work, how addresses and routing are used to move data through the network, how to set up your network connection -- and then covers, in detail, everything you need to know to exchange information via the Internet.
Included are discussions on advanced routing protocols (RIPv2, OSPF, and BGP) and the gated software package that implements them, a tutorial on configuring important network services -- including DNS, Apache, sendmail, Samba, PPP, and DHCP -- as well as expanded chapters on troubleshooting and security. TCP/IP Network Administration is also a command and syntax reference for important packages such as gated, pppd, named, dhcpd, and sendmail.
With coverage that includes Linux, Solaris, BSD, and System V TCP/IP implementations, the third edition contains:
- Overview of TCP/IP
- Delivering the data
- Network services
- Getting startedM
- Basic configuration
- Configuring the interface
- Configuring routing
- Configuring DNS
- Configuring network servers
- Configuring sendmail
- Configuring Apache
- Network security
- Troubleshooting
- Appendices include dip, ppd, and chat reference, a gated reference, a dhcpd reference, and a sendmail reference
This new edition includes ways of configuring Samba to provide file and print sharing on networks that integrate Unix and Windows, and a new chapter is dedicated to the important task of configuring the Apache web server. Coverage of network security now includes details on OpenSSH, stunnel, gpg, iptables, and the access control mechanism in xinetd. Plus, the book offers updated information about DNS, including details on BIND 8 and BIND 9, the role of classless IP addressing and network prefixes, and the changing role of registrars.
Without a doubt, TCP/IP Network Administration, 3rd Edition is a must-have for all network administrators and anyone who deals with a network that transmits data over the Internet.
From the Publisher
About the Author
Craig Hunt has worked with computer systems for the last twenty years, including a stint with the federal government as both a programmer and systems programmer. He joined Honeywell to work on the WWMCCS network in the days before TCP/IP, back when the network used NCP. After Honeywell, Craig went to work for the National Institute of Standards and Technology. He's still there today and is currently the leader of the Network Engineering Group. Craig is the author of TCP/IP Network Administration and other O'Reilly books.
Excerpted from TCP/IP Network Administration (3rd Edition; O'Reilly Networking) by Craig Hunt. Copyright © 2002. Reprinted by permission. All rights reserved.
In this chapter:
The Network File System
Sharing Unix Printers
Using Samba to Share Resources with Windows
Network Information Service
DHCP
Managing Distributed Servers
Post Office Servers
Now our attention turns to configuring local network servers. As with name service, these servers are not strictly required for the network to operate, but they provide services that are central to the network's purpose.
There are many network services--many more than can be covered in this chapter. Here we concentrate on servers that provide essential services for local clients. The services covered in this chapter are:
· The Network File System (NFS)
· The Line Printer Daemon (LPD) and the Line Printer (LP) service
· Windows file and print services (Samba)
· The Network Information Service (NIS)
· Dynamic Host Configuration Protocol (DHCP)
· The Post Office Protocol (POP)
· Internet Message Access Protocol (IMAP)
All of these software packages are designed to provide service to systems within your organization and are not intended to service outsiders. Essential services that are as important to external users as they are to in-house users, such as email, web service, and name service, are covered in separate chapters.
We begin our discussion of local network services with NFS, which is the server that provides file sharing on Unix networks.
The Network File System
The Network File System (NFS) allows directories and files to be shared across a network. It was originally developed by Sun Microsystems but is now supported by virtually all Unix and many non-Unix operating systems. Through NFS, users and programs can access files located on remote systems as if they were local files. In a perfect NFS environment, the user neither knows nor cares where files are actually stored.
NFS has several benefits:
· It reduces local disk storage requirements because a server can store a single copy of a directory that is fully accessible to everyone on the network.
· It simplifies central support tasks--files can be updated centrally yet be available throughout the network.
· It allows users to use familiar Unix commands to manipulate remote files instead of learning new commands. There is no need to use ftp or rcp to copy a file between hosts on the network; cp works fine.
There are two sides to NFS: a client side and a server side. The client is the system that uses the remote directories as if they were part of its local filesystem. The server is the system that makes the directories available for use. Attaching a remote directory to the local filesystem (a client function) is called mounting a directory. Offering a directory for remote access (a server function) is called sharing or exporting a directory.[1] Frequently, a system runs both the client and the server NFS software. In this section we'll look at how to configure a system to export and mount directories using NFS.
If you're responsible for an NFS server for a large site, you should take care in planning and implementing the NFS environment. This chapter describes how NFS is configured to run on a client and a server, but you may want more details to design an optimal NFS environment. For a comprehensive treatment, see Managing NFS and NIS by Hal Stern (O'Reilly & Associates).
NFS Daemons
The Network File System is run by several daemons, some performing client functions and some performing server functions. Before we discuss the NFS configuration, let's look at the function of the daemons that run NFS on a Solaris 8 system:
nfsd [nservers]
The NFS daemon, nfsd, runs on NFS servers. This daemon services the client's NFS requests. The nservers option specifies how many daemons should be started.
mountd
The NFS mount daemon, mountd, processes the clients' mount requests. NFS servers run the mount daemon.
nfslogd
The NFS logging daemon, nfslogd, logs activity for exported filesystems. NFS servers run the logging daemon.
rquotad
The remote quota server, rquotad, provides information about user quotas on remote filesystems that is then displayed by the quota command. The remote quota server is run on both clients and servers.
lockd
The lock daemon, lockd, handles file lock requests. Both clients and servers run the lock daemon. Clients request file locks, and servers grant them.
statd
The network status monitor daemon, statd, is required by lockd to provide monitoring services. In particular, it allows locks to be reset properly after a crash. Both clients and servers run statd.
On a Solaris 8 system, the daemons necessary to run NFS are found in the /usr/lib/nfs directory. Most of these daemons are started at boot time by two scripts located in the /etc/init.d directory, nfs.client and nfs.server. The nfs.client script starts the statd and lockd programs.[2] NFS server systems run those two daemons, plus the NFS server daemon (nfsd), the NFS logging daemon (nfslogd), and the mount server daemon (mountd). On Solaris systems, the nfs.server script starts mountd, nfslogd, and 16 copies of nfsd. Solaris systems do not normally start rquotad at boot time. Instead, rquotad is started by inetd, as this grep of the /etc/inetd.conf file shows:
$ grep rquotad /etc/inetd.conf
rquotad/1 tli rpc/datagram_v wait root /usr/lib/nfs/rquotad rquotad
Each system has its own technique for starting these daemons. If some of the daemons aren't starting, ensure your startup scripts and your inetd.conf file are correct.
