Red Hat Linux Networking and System Administration Third Edition phần 5 pptx

Table 15-4 PostgreSQL Client Programs and Utilities
PROGRAM DESCRIPTION
createdb Creates a new database in the database cluster
createuser Creates a new user in the database cluster
dropdb Deletes a database from the database cluster
dropuser Deletes a user form the database cluster
pg_dump Saves (dumps) the contents of a database or database object to
a file
pg_restore Reloads a database or database object using a file created by
pg_dump
psql Provides a command interpreter for interacting with a database
server
Most PostgreSQLclients share a number of options in common. For example,
-U username specifies the username to use when connecting to the server. -W
indicates you should be prompted for a password. -D /path specifies the path
to the PostgreSQL database cluster, which defaults to the value of the environ-
ment variable $PGDATA or the compiled in default (/var/lib/pgsql/data).
-e causes wrapper scripts like createdb and dropuser to echo to standard
output (stdout) the SQL commands used. Commands that operate on or
require a connection to a specific database usually accept a database name as an
argument. If a database name is not specified, it defaults to the name of the user
connecting to the database specified using -U username or to the connecting
user’s login name if -U username is not specified.
Similarly, most PostgreSQL clients can use PostgreSQL-specific environ-
ment variables to set certain defaults. In addition to $PGDATA, which you’ve
already seen, the variable $PGDATABASE stores the name of the database to
use (or create or drop) unless overridden on the command line. $PGHOST spec-
ifies the name of the host on which the database server is running and so is
usually used when connecting to a database running on a remote host.
$PGUSER defines the default connection parameters, which usually consists of
the PostgreSQL user name.

You’ve already seen the syntax for createdb and createuser, so we
won’t review it here. dropdb and dropuser drop (delete) a database or user,
respectively, from the database cluster. dropdb’s syntax is:
dropdb [option ] dbname
dbname identifies the database to drop and option (there can be multiple
options) accepts the options previously described and, most importantly, the
376 Chapter 15
21_599496 ch15.qxd 8/30/05 6:40 PM Page 376
-i option, which asks for confirmation before actually dropping the database.
This is an important option because dropping a database deletes the data and
data structures associated with the database. Unless you have previously
saved the data, dropping a database is a permanent action. Because it is such a
drastic action, only the database owner and the PostgreSQL superuser have
privileges to drop a database. As a precaution, you should always save the
database data before dropping it (use the pg_dump command, about which
you’ll learn shortly).
The dropuser wrapper utility deletes a specified user from the database
cluster. Its syntax is:
dropuser [option ] username
Replace username with the name of the PostgreSQL user account you want
to delete. The possible values for option were described earlier and won’t be
repeated here, except to add the dropuser, like dropdb, also accepts the -i
option to request interactive use.
Before dropping a database, you should use the pg dump pg_dump pro-
gram to save the data unless you are absolutely, positively, 100 percent certain
beyond the slightest shadow of a doubt that you won’t need the data in the
future. pg_dump’s syntax is:
pg_dump [option ] dbname
As usual, dbname specifies the name of the database to dump. option con-
trols the actual dump behavior. The various options already described also

work with pg_dump, but it has a number of options specific to its behavior that
you’ll want to know about. pg_dump is usually used to archive and retrieve
data, such as for backup and upgrade purposes, so the options discussed focus
on that purpose.
A typical archive/restore operation consists of dumping the database, drop-
ping it, recreating it, and reloading it with the dumped data. Using the -C
option, pg_dump will begin the dump output with the SQL statements neces-
sary to create the database and then connect to it. The rest of the dump will
consist of COPY statements that use a PostgreSQL-specific extension for per-
forming high-speed data loads. Use the -f filename option to specify the
name of the output file. If you don’t use this option, output goes to stdout and
must be redirected to a file using the shell’s > operator. To create an output file,
finally, most suitable for use with pg_restore (described next), use the -Fc
option, which specifies a custom output format specifically designed for use
with pg_restore (-Fp outputs a plain ASCII text file with data and SQL
statements and -Ft outputs a tar archive that pg_restore can read).
Configuring a Database Server 377
21_599496 ch15.qxd 8/30/05 6:40 PM Page 377
If you want to dump only the database schema (the actual design of the
database, not its data) specify the -s option. Similarly, if you are interested in
only the contents of a particular table, specify -t table, where table is the
name of the table that interests you.
pg_restore is pg_dump’s counterpart and restores or reloads a PostgreSQL
database dump created with pg_dump. It also accepts the same command-line
options as pg_dump, so your learning curve has flattened out considerably. The
difference between the two is that pg_restore’s argument is the name of an
input file created by pg_dump.
So, given the following pg_dump command:
-bash-3.00$ pg_dump -Fc -C rhlnsa3 > rhlnsa3.db
You can restore the contents of the tables in the database rhlnsa3 using the

following pg_restore command (the rhlnsa3 database must exist) after
dropping any tables in the database:
-bash-3.00$ pg_restore -d rhlnsa3.dump
Table 15-5 lists the PostgreSQL server programs you’ll want to know how
to use.
You will rarely, if ever, need to invoke the postgres command directly. It is
called by the postmaster command. postgres is responsible for processing
queries for a single connection to the database server. When a connection
starts, postmaster, which listens for incoming connection requests, starts a
postgres process to handle that connection. In addition to serving as the
multiuser server for a PostgreSQL databases, postmaster is also responsible
for handling communication between individual postgres processes. You can
also almost always rely on the PostgreSQL initialization script, postgresql, to
start and stop the postmaster service, so you should hardly ever need to exe-
cute postmaster directly.
Table 15-5 PostgreSQL Server Programs and Utilities
PROGRAM DESCRIPTION
initdb Creates and initializes a PostgreSQL database cluster
pg_ctl Controls a running database server instance
postgres Processes queries for a single connection to a PostgreSQL
database (usually started by postmaster)
postmaster Starts postgres processes to handle incoming database
connections and coordinates communication between
postgres processes
378 Chapter 15
21_599496 ch15.qxd 8/30/05 6:40 PM Page 378
Summary
Linux-based database servers are becoming as ubiquitous as Linux-based Web
and email servers, so it is likely that you will need to create a database server
at some point. While you don’t need to be on a first-name basis with the finer

points of database administration to configure a database server, it does help to
be familiar with the general process. Just installing the software isn’t usually
sufficient, either. As an administrator, you usually need to be able to make sure
that the database is accessible (or not as the case might be), that the initial
accounts are secure, and that the server is working. This chapter showed you
how to configure MySQL and PostgreSQL to a basic level of functionality. As
you learned, installing them is easy, but the postinstallation configuration and
testing can be tedious. The good news is that database installations are usually
performed in conjunction with a DBA who provides guidelines and instruc-
tions for you to follow. You’re rarely on your own.
Configuring a Database Server 379
21_599496 ch15.qxd 8/30/05 6:40 PM Page 379
21_599496 ch15.qxd 8/30/05 6:40 PM Page 380
381
Providing network services for remote employees, whether they are road war-
riors barricaded in a hotel room or telecommuters working from a home office,
is nothing new. As telecommuting becomes more common and broadband
Internet access more widespread, system administrators are increasingly
being asked to provide remote access to their networks. Various approaches to
providing LAN services to disconnected employees have been tried over the
years, including remote control software virtual private networks (VPNs). The
goal has always been to make it possible for remote employees to use another
computer or LAN-based services as if those employees were sitting in the
office. VNC gives you remote access to an existing desktop system and all of
the resources that it can access. This chapter describes how use Fedora Core
and RHEL to create a VNC server, enabling telecommuters and other remote
employees to access a Fedora Core- or RHEL-based LAN and LAN-based ser-
vices. It also shows you how to configure a Linux system as a VNC client.
What Is VNC?
Just to get the acronym out of the way, VNC stands for virtual network com-

puting, and it provides a way to fully control one computer from any other
computer or similarly capable device situated anywhere on the Internet. One of
Creating a
VNC Server
IN THIS CHAPTER
■■ What Is VNC?
■■ Setting Up a VNC Server
■■ Testing the VNC
CHAPTER
16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 381
the virtues of VNC solutions over other methods is that VNC is cross-platform.
You can access and control a Linux host from a Windows PC, something not
possible with products like PCAnywhere. Another VNC advantage is that the
protocol is optimized for Internet transmission, so it is actually possible and not
glacially slow to run X applications across the Internet.
In addition to providing remote users access to LAN-based systems and ser-
vices, VNC also has clear uses for help desk technicians, other technical sup-
port professionals, and system administrators. If you ever worked at a help
desk, you know how difficult it is to get the “helpees” on the other end of the
telephone to tell you what the screen looks like, what applications are running,
and even to coherently describe the problem they’re having. You also know
how hard it is to make sure that the person you’re helping types the com-
mands you want typed or executes the problem resolution procedure properly.
Using VNC, you have immediate access to the user’s system and can remotely
diagnose and troubleshoot the problem at hand, all without having to leave
your desk. VNC is a real boon for system administrators for the same reasons.
Even if out of the office or at a remote site, the administrator always has access
to management and monitoring tools that can make detecting and fixing a
troublesome server a trivial undertaking.

Unlike older, less capable remote control software, VNC supports multiple
incoming connections to the same VNC server, so it is possible for several
users to connect to the same system and work collaboratively on a project,
such as a presentation. Alternatively, you can use a single VNC server as an
access concentration point from which properly authorized users can connect
to other systems. Another difference between VNC and other remote control
protocols is that VNC, described as “remote display protocol” or an RFB
(remote framebuffer), is an open and nonproprietary protocol, whereas the
other products (from Symantec, Citrix, Insignia Solutions, and Microsoft) are
closed protocols that are closely tied to the Windows GUI.
What VNC is not is a VPN, or virtual private network. Speaking broadly, a
VPN is a network configuration in which a main internal network has remote
nodes (such as telecommuting employees) that use a VPN running over (per-
haps it is better to say across) the Internet to access the main internal network.
To achieve this, a secure (encrypted) tunnel is created between the main net-
work and the remote nodes, and IP traffic is routed through that tunnel. VNC,
on the other hand, while it can be used across a VPN and uses the Internet to
transport packets back and forth, is usually used to provide access to a single
system and to allow a remote user full control over that system. More suc-
cinctly, VPN makes a remote system part of the main network; VNC gives a
remote user control over one system on the main network.
For more information about VNC, two of the best resources are the excellent
VNC overview at uk.research.att.com/pub/docs/att/tr.98.1.pdf
382 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 382
and the RealVNC Web site (realvnc.com/). There is a connection between
AT&T and RealVNC. Researchers at the AT&T UK research labs created VNC.
RealVNC was formed by some of the AT&T researchers as a venture to com-
mercialize VNC technology. The VNC software is licensed under the GPL, so
RealVNC’s business model depends on providing support, service, and value-

added software.
Setting Up a VNC Server
In this context, a VNC server is the machine you want to access remotely. So, if
you’re at home and want to connect to the Linux system on your desk at work,
the system at work is the server; the system at home is the VNC client. Figure
16-1 illustrates this arrangement.
To set up a VNC server, you’ll need to install the vnc-server and vnc
packages. The commands shown below will show you if they are installed:
$ rpmquery vnc-server
vnc-server-4.1.1-10
$ rpmquery vnc
vnc-4.1.1-10
If these packages are not installed, install them before proceeding.
Starting the VNC server is simplicity itself: execute the Perl script vncserver
as a mortal user. vncserver is a wrapper script that handles the persnickety
details of starting Xvnc, the X Window System VNC server. Speaking more pre-
cisely, Xvnc creates a VNC desktop on the server system to which VNC clients
can connect. There is a configuration step that must be performed by the root
user, but starting the server does not require any special privileges. The first time
you start vncserver, you have to set the password that connecting clients must
issue, as shown in the following example:
$ vncserver
You will require a password to access your desktops.
Password:
Verify:
New coondog.example.com:1 (bubba)’ desktop is coondog.example.com:1
Creating default startup script /home/bubba/.vnc/xstartup
Starting applications specified in /home/bubba/.vnc/xstartup
Log file is /home/bubba/.vnc/coondog.com:1.log
Creating a VNC Server 383

22_599496 ch16.qxd 8/30/05 6:40 PM Page 383
Figure 16-1 Typical VNC client and server configuration.
The output is important. The first line after setting the password indi-
cates that Xvnc has created a new display, :1 on the host coondog.example
.com. You will need this information when you connect from the client sys-
tem. vncserver asks for a password only the first time you start it. You can
change the password later using the command vncpasswd or by removing
the file $HOME/.vnc/passwd.
The next two lines tell you that a startup script, /home/bubba/.vnc
/xstartup, has been created and that the script has been executed, that is, the
applications it specifies are running on the Xvnc display. This means that
when you connect to the VNC server, the client will have those applications
already running. This also means that if you want to customize the desktop
provided by the server, you can edit the xstartup file. Finally, vncserver
tells you where to find the log file it creates, which will simplify troubleshoot-
ing the VNC server problems if you encounter any. When vncserver com-
pletes, a simple, unadorned VNC desktop is ready to accept connections.
Configuring Your Firewall for VNC
Well, your VNC server is almost ready to accept connections. VNC listens on
port 5500 plus the X display number for incoming VNC client sessions. On a
properly secured system, these ports are blocked at the firewall. You have to
punch a hole in the firewall for that port so that VNC clients can get through
to the server. This configuration step requires root access because you need to
use the Security Level Configuration tool to modify your system’s firewall
setup (you are running a firewall, right?).
1. To start the Security Level Configuration tool, select Red Hat ➪ System
Settings ➪ Security Level or type system-config-securitylevel
at a command prompt. Figure 16-2 shows the Security Level Configura-
tion tool’s main screen.
INTERNET

Corporate
Firewall
Home
Firewall
V
NC Server VNC Clien
t
384 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 384
Figure 16-2 The Security Level Configuration tool.
The firewall configuration shown in Figure 16-2 is tight: no external
access of any sort is permitted on this machine. You’re about to change
this. In the Other ports: (1029:tcp) text box, type 5901:tcp. By default,
VNC uses ports numbered 5900 plus the display number. In this exam-
ple, the display number is :1, so the port number is 5901. If you were
using display number :21, the port number would be 5912. The :tcp
portion of the port number tells the firewall to open port 5901 for TCP
connections because the remote framebuffer protocol uses TCP, not UDP.
2. After you have entered the appropriate port number (see Figure 16-3),
click OK to save your change and close the Security Level Configura-
tion tool. Click Yes when the tool warns you that you are about to over-
write your existing firewall configuration.
VNC clients can now access the VNC server, so the server configuration is
complete.
Creating a VNC Server 385
22_599496 ch16.qxd 8/30/05 6:40 PM Page 385
Figure 16-3 Opening TCP port 5901 with the Security Level Configuration tool.
Customizing the VNC Server
Sure, the server configuration is complete, but the default desktop (jump
ahead to Figure 16-5) is ugly, unless you like the twm window manager and

the plain gray background. Remember that xstartup file, /home/bubba/
.vnc/xstartup? You can edit that to change the default desktop. Listing
16-1 shows the default xstartup file:
#!/bin/sh
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
twm &
Listing 16-1 The default xstartup file.
386 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 386
As you learned in Chapter 9, X Window System startup files configure your
X environment and start certain X programs each time you log in. In this case,
xstartup does the following:
1. Executes the file /etc/vnc/xstartup if it exists and is executable.
2. Loads any X resources stored in the file .Xresources if it exists and is
readable.
3. Invokes xsetroot to set the background color to solid gray.
4. Starts the vncconfig program minimized.
5. Starts an 80x24 xterm with a specific title.
6. Starts twm, the Tab Window Manager.
If you want your usual desktop, the one you get when you are sitting in
front of the system, do what the instructions suggest and uncomment the fol-
lowing two lines:
# unset SESSION_MANAGER

# exec /etc/X11/xinit/xinitrc
You should also comment out the last four lines. The modified file should
resemble Listing 16-2.
#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
#xsetroot -solid grey
#vncconfig -iconic &
#xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
#twm &
Listing 16-2 xstartup modified to display your standard desktop.
The modified xstartup file starts your usual desktop because it invokes
the system xinitrc file, which starts the standard X initialization process.
You might want to stick with the default VNC server configuration, though.
Running X over a network connection is always going to be slower than run-
ning it directly unless you have a very fat pipe and no network congestion. The
default VNC configuration runs the twm window manager, which is consider-
ably faster than X desktop environments like KDE and GNOME. twm is also
Creating a VNC Server 387
22_599496 ch16.qxd 8/30/05 6:40 PM Page 387
faster than many modern window managers too. The point is that the less eye
candy transmitted over the wire, the faster your VNC setup will be. Yes, twm
might make your eyes bleed, and it definitely lacks features that many have
come to expect from your window manager. However, if you are working
remotely, you might not need the application integration and the eye candy as
much as you need a responsive “desktop.” You can also customize twm by edit-
ing (or creating) a twmrc file, which might make it a little easier on your eyes.

Testing the VNC
Testing your VNC setup is simple. First, make sure that it works locally by
starting a VNC client on the same system as the VNC server. If the VNC server
you started in the section “Setting Up a VNC Server” isn’t running, restart it:
$ vncserver
New ‘luther.kurtwerks.com:1 (kwall)’ desktop is luther.kurtwerks.com:1
Starting applications specified in /home/kwall/.vnc/xstartup
Log file is /home/kwall/.vnc/luther.kurtwerks.com:1.log
Next, in a terminal window, start the VNC client, or viewer, by executing the
command vncviewer :n, replacing n with the display number vncserver
reported when it started (1, in the example). You will see the password prompt
shown in Figure 16-4.
$ vncviewer :1
VNC Viewer Free Edition 4.1.1 for X - built Apr 27 2005 02:25:46
Copyright (C) 2002-2005 RealVNC Ltd.
See for information on VNC.
Sat May 21 01:01:32 2005
CConn: connected to host localhost port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
Figure 16-4 The VNC authentication dialog box.
388 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 388
Type the password you provided when you configured the VNC server and
press Enter. Assuming that you are using the default VNC server configura-
tion (the one that uses twm), the resulting screen should resemble Figure 16-5.
Figure 16-5 doesn’t look terribly impressive, but the purpose of this exercise
is to satisfy yourself that the server is working. You should be able to start
applications, surf the Web (assuming that the server is connected to the Inter-
net), and use the remote computer just as if you were sitting in front of it. Fig-

ure 16-6, for example, shows the Fedora Project Web site in a Mozilla browser
session started from the VNC client.
Figure 16-5 Viewing the default VNC desktop in a VNC client.
Figure 16-6 Using Mozilla in the VNC client.
Creating a VNC Server 389
22_599496 ch16.qxd 8/30/05 6:40 PM Page 389
You can also start the VNC client by selecting Red Hat ➪ Accessories ➪
VNC Viewer. If you use the menu, you will have to specify the VNC server to
which to connect, as shown in Figure 16-7.
The server specification shown in Figure 16-7 included the display number.
If you don’t include this value, you won’t get a connection. You can use either
the IP address, as shown in the figure, or the hostname. In fact, if you use the
hostname, you can use the FQDN or the alias, if one is defined in /etc/hosts.
After establishing that the server is working, close the client session by pressing
F8 while the viewer has the focus and selecting Exit Viewer from the pop-up
menu. (See Figure 16-8.)
Now, test the configuration from a remote machine. Figure 16-9 shows a
VNC client session running on Microsoft Windows XP. The client software is
the RealVNC for Windows, which is the same product as used on Fedora Core
and RHEL systems.
Figure 16-7 Specifying the target VNC server.
Figure 16-8 The VNC viewer pop-up menu.
390 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 390
Figure 16-9 Using a Linux VNC server from Microsoft Windows.
To get the full effect of VNC, especially when you use the viewer from a
Windows system, consider Figure 16-10, which shows a VNC session to the
server configured in the first section of this chapter. In this case, the server was
started using the modified xstartup in Listing 16-2, which displays the stan-
dard system desktop (KDE, in this case) rather than the faster, nimbler, and

uglier twm.
To reiterate the point made earlier, running X across a network, especially
the Internet, is going to be a slower affair than running it directly. On a LAN
such as a home network (the environment in which the Figures 16-9 and 16-10
were taken), the performance hit will be minimal, and you might not notice or
mind the difference. Across the Internet, you will find it intolerably slow run-
ning something like KDE, GNOME, or the more, shall we say, feature-rich
window managers. Whether you use KDE with all the trimmings or some-
thing leaner like twm, you will definitely appreciate being able to access your
desktop system from a remote location.
Creating a VNC Server 391
22_599496 ch16.qxd 8/30/05 6:40 PM Page 391
Figure 16-10 Running KDE on Microsoft Windows via VNC.
When you are done running the VNC server, you can kill the running
process by passing the -kill option to vncserver:
$ vncserver -kill :1
Killing Xvnc process ID 30790
Replace :1 with the display number on which the VNC server was running.
Summary
Providing road warriors and telecommuters access to LAN-based services is
an increasingly important requirement that system administrators are asked to
meet. VNC is one way to meet that requirement. With minimal configuration
on the server side and no configuration on the client side, you can provide
remote access to one or more Linux systems using VNC. As always, poking a
hole in your firewall to permit external access poses a security risk, so you
have to weigh that risk against the advantages and decide whether VNC is the
way you want to go. As you saw in this chapter, the advantages of remote
access to your desktop system are hard to dispute.
392 Chapter 16
22_599496 ch16.qxd 8/30/05 6:40 PM Page 392

393
Any system administrator can testify that requests for new or enhanced ser-
vices pop up constantly. Sometimes they arrive in a trickle; other times a fire
hose delivers them. One commonly requested service is a time server, a service
that provides the authoritative clock against which all other systems on the
LAN sync their clocks. Perhaps the boss wants people to be able to share infor-
mation on the company intranet and asks you to create a way to post Web doc-
uments to the intranet Web server. This chapter describes setting up two
nonessential LAN-based services that select groups of intranet users (or you)
might find useful. These services fall into the nonessential category because
they provide functionality that is nice to have but without your LAN is still
amply serviceable.
The nonessential services described in this chapter include an NTP-based
time server and a caching proxy server. Naturally, these two topics hardly
exhaust the possible list of conveniences users (and managers) can and do
request. Some of the topics that might seem appropriate for this chapter are cov-
ered elsewhere in the book. For example, Chapter 16 describes how to set up a
VNC server to give remote users access to their desktops. Building a Web server
for your company intranet is no different from building a Web server that faces
the Internet, a topic covered in Chapter 23. Likewise, Chapter 24 shows you how
to configure some of the Web-based services users typically want, such as mail-
ing lists, Web-based email, site search functionality, and RSS feeds.
Providing Additional
Network Services
IN THIS CHAPTER
■■ Configuring a Time Server
■■ Providing a Caching Proxy Server
CHAPTER
17
23_599496 ch17.qxd 8/30/05 6:41 PM Page 393

More to the point, we had to limit the topics we covered, just as administra-
tors have to limit the services they provide. And that point might be as impor-
tant as the specifics of creating a time server or setting up a proxy server. You
have to know when to say “No” to feature requests. In some cases, a requested
feature might pose more of a security risk than you are willing to take. In other
cases, a network enhancement might stress your network infrastructure or uti-
lize network, system, and CPU resources better used for other purposes. In
still other cases, you might simply lack the personnel or time to manage any
more services. Whatever the case, you must be able and willing to say no to
such requests, if only to preserve your sanity.
Configuring a Time Server
For this chapter’s purposes, a time server is a daemon that runs on one machine
and to which other systems (in this case, clients on your LAN) synchronize their
system clocks. In the common case, you synchronize your time server’s clock
against one or more reference time servers that are situated outside your LAN.
In some cases, the time server synchronizes its time against a specially designed
clock. This hardware clock is a separate, single-purpose hardware device that
maintains extremely accurate time. (More about these details shortly.)
The motivation for a time server is to keep the system time consistent
throughout the LAN so that time-sensitive operations work reliably. In devel-
opment shops, the make utility uses files timestamps to determine which com-
ponents of a software project need to be rebuilt. If you have an inaccurate
system clock, the timestamps on files will be inconsistent, causing project
builds to fail or to behave unpredictably. Similarly, source code version control
systems often rely on file and directory timestamps to track changes to files
maintained in the source code repository. NFS is also sensitive to timekeeping
irregularities. If the system clock on a client machine is significantly faster or
slower than the system clock on the NFS server, you will run into problems
saving files. Irregularities in system clocks between client systems and the
server can adversely affect the mechanisms content management systems use

to update and maintain complex Web sites.
To take one example from our own experience, we have an NFS server from
which users mount home directories and project-specific work directories.
Everything was working smoothly until we started seeing errors during proj-
ect builds. The errors initially pointed to a problem with the server’s system
clock. After we reset the system clock and synced it to an external time server,
most users reported no further problems and project builds worked normally
again, but some users continued to experience timestamp-related write errors
on files mounted from the server. It took a couple of days for us to work out
394 Chapter 17
23_599496 ch17.qxd 8/30/05 6:41 PM Page 394
that the only users continuing to have these problems were users whose sys-
tems had flaky system clocks that lost anywhere from 15 seconds to several
minutes each day. After configuring these client systems to coordinate their
system clocks with the NFS server’s clock, the problem went away and has not
returned. Eventually, we set up a time server for the entire LAN and config-
ured all systems to synchronize to that time server.
Selecting a Time Server Solution
If you’ve decided (or have been told) that you need a time server, your options
fall into three categories: hardware, software, or both. As mentioned a moment
ago, the hardware solution involves installing a high-resolution clock in your
facility and then configuring client systems to synchronize their system clocks
against that dedicated device. If you have a bottomless pit of money for a bud-
get, you can install an atomic clock, such as a cesium fountain clock, to keep
ridiculously accurate time. In the great majority of cases, though, hardware
clocks aren’t quite so high end. Instead, these lower-end clocks are equipped
with a radio or satellite receiver that monitors one of several radio or satellite
broadcast frequencies specifically allocated to carrying a time signal. These
time signals are broadcast by the United States Naval Observatory (USNO),
the National Institute of Standards and Technology (NIST), or another official

organization of the United States government. (Most countries provide similar
services.) You can buy high-quality hardware clocks for $1000. In fact, depend-
ing on your needs, you can get good, high-resolution, dedicated hardware
clocks for a few hundred dollars.
NOTE For the record, USNO and NIST have multiple atomic clocks, so they keep
ridiculously accurate time on your behalf and do so with your tax dollars. To learn
more about the NIST timekeeping service, visit the NIST’s Time & Frequency
Division Web site at www.boulder.nist.gov/timefreq/service/its.htm.
The USNO operates a comparable site at />The most common time server solution, especially for small(ish) networks
and organizations, is strictly software-based. The simplest approach is to use
the date program to set your system clock to the time broadcast by another sys-
tem. The kid-tested, mom-approved, and syadmin-preferred method, though,
is to use the Network Time Protocol, or NTP. NTP is an open standard that
defines how Internet time servers work and how clients can communicate with
these time servers to maintain accurate time. How accurate? If you believe the
NTP documentation, the best precision is about 232 picoseconds, or 2.32 × 10
–10
seconds, or 0.000000000232 seconds. If you need greater precision than 232
picoseconds, get that cesium clock.
Providing Additional Network Services 395
23_599496 ch17.qxd 8/30/05 6:41 PM Page 395
NOTE David Mills wrote the NTP implementation universally used on Linux
systems. Mills has done an excellent job of documenting his work. For an
overview of time synchronization issues in general, see “Executive
Summary: Computer Network Time Synchronization” at Mills’ Web site,
eecis.udel.edu/~mills/exec.html. For more information about NTP,
the authoritative Web site is ntp.org.
NTP consists of a daemon (ntpd), a small set of utility programs (ntpq,
ntpdc, ntpdate, ntptrace, tickadj, ntptime, ntiptime, ntp-kegen, and ntpdsim),
and the all-important configuration file, /etc/ntp.conf. The NTP daemon

is dual-purpose. It acts as a server, listening for time synchronization requests
and providing the time in response, and as a client, communicating with other
time servers to get the correct time and adjust the local system accordingly.
Table 17-1 briefly describes the utility programs.
Configuring the Time Server
Setting up your time server requires a small amount of preparation, imple-
mentation, and verification. You’ll need to perform the following tasks:
1. Install the NTP software.
2. Locate suitable time servers to serve as reference clocks.
3. Configure your local time server.
4. Start the NTP daemon on the local time server.
5. Make sure that the NTP daemon responds to requests.
Table 17-1 NTP Utility Programs
PROGRAM DESCRIPTION
ntpdate Sets the system date and time via NTP
ntpdc Controls the NTP daemon, ntpd
ntp-keygen Generates public and private keys for use with NTP
ntpq Queries the NTP daemon
ntpsim Provides NTP simulation for development and testing
ntptime Displays the time variables maintained by the Linux kernel
ntptrace Traces a chain of NTP servers back to the primary source
tickadj Sets certain time variables maintained by the Linux kernel
396 Chapter 17
23_599496 ch17.qxd 8/30/05 6:41 PM Page 396
Installing the NTP software is simple. Use the rpmquery command to make
sure that the ntp package is installed:
$ rpmquery ntp
ntp-4.2.0.a.20040617-4
The version number you see might be slightly different. If the ntp package
isn’t installed, install it using the installation tool of your choice before

proceeding.
Selecting Reference Clocks
For your time server to keep and thus to serve accurate time, your local time
server needs to synchronize its time against one or more master or reference
clocks. NTP is a distributed application, meaning that servers and clients are
dispersed, that any given client can request a time check from any given server
(modulo access restrictions), and that the application continues to function in
spite of the failure or inaccessibility of one or even many of the servers. NTP is
also hierarchical and organizes time servers into several strata to reduce the
load on any given server or set of servers. Stratum 1 servers are referred to as
primary servers, stratum 2 servers as secondary servers, and so on. There are far
more secondary servers than primary servers. Secondary servers sync to pri-
mary servers, and clients sync to secondary or tertiary servers.
NTP also provides for syncing to pool servers, a large class of publicly acces-
sible secondary servers maintained as a public service for use by the Internet-
connected computing community at large. The NTP pool time servers,
organized into the subnet pool.ntp.org, use DNS round robin to assign
randomly selected open access time servers to NTP clients (recall that an NTP
server can also be an NTP client). The rationale for random server selection is
to distribute the client load more or less equally across all servers participating
in the pool and to ensure that clients are syncing to an appropriately distrib-
uted set of time servers.
The upshot for you is simple:
■■ Use one or more secondary servers as your local server’s reference clock.
■■ Use the pool servers if possible.
Accordingly, this section configures an NTP server to use the pool servers
and also shows you how to configure your local time server to use explicitly
selected secondary servers.
To use the pool servers, NTP is ready to run after you install the ntp pack-
age. Listing 17-1 shows ntpd’s configuration file, /etc/ntp.conf, stripped

of most comments and white space.
Providing Additional Network Services 397
23_599496 ch17.qxd 8/30/05 6:41 PM Page 397
restrict default nomodify notrap noquery
restrict 127.0.0.1
# OUR TIMESERVERS
server pool.ntp.org
server pool.ntp.org
server pool.ntp.org
# GENERAL CONFIGURATION
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
keys /etc/ntp/keys
Listing 17-1 The default NTP configuration file.
The first two entries, beginning with the restrict directive, are, not sur-
prisingly, restrictions on the listed IP addresses or hostnames. The first entry
uses the keyword default, which means an IP address and mask of 0.0.0.0. The
option flags, nomodify, notrap, and noquery, prevent the listed IP address
from modifying, logging, or querying the NTP service on the server. The second
rule, restrict 127.0.0.1, permits all NTP activity over the loopback inter-
face. All activity is permitted because there are no option flags specified. To deny
all activity, you would use the ignore flag, but you shouldn’t do this on the
loopback interface because doing so would prevent certain NTP administrative
functions (issued using the ntpdc command) from working properly.
The next three entries, beginning with the server directive, identify the
time servers you want to use as reference clocks. In this case, ntpd is being con-
figured to use the pool servers. Notice that the names are all pool.ntp.org.
Even though the names are the same, the NTP server pool is configured to use

DNS round robin, so three hostname lookups on the same name will return
three different IP addresses. You can try this yourself to verify that round robin
is working. Issue the command host pool.ntp.org at the command
prompt and, unless your DNS client is broken, you should see output resem-
bling the following:
$ host pool.ntp.org
pool.ntp.org has address 213.219.244.16
pool.ntp.org has address 216.27.185.42
pool.ntp.org has address 62.220.226.2
pool.ntp.org has address 69.37.143.241
pool.ntp.org has address 81.169.154.44
pool.ntp.org has address 82.219.3.1
pool.ntp.org has address 139.140.181.132
pool.ntp.org has address 146.186.218.60
398 Chapter 17
23_599496 ch17.qxd 8/30/05 6:41 PM Page 398
pool.ntp.org has address 195.18.140.242
pool.ntp.org has address 203.217.30.156
pool.ntp.org has address 209.126.142.251
pool.ntp.org has address 212.23.29.225
pool.ntp.org has address 212.41.248.75
pool.ntp.org has address 212.254.25.164
pool.ntp.org has address 213.10.208.72
Normally, a hostname resolves to one and only one IP address, but when
DNS round robin behavior is enabled, a single hostname can resolve to multi-
ple IP addresses, the purpose being to equalize the load on any single system.
The general configuration section sets broad operational policies that control
ntpd’s overall behavior. The line server 127.127.1.0 instructs the NTP dae-
mon to use the local clock (referred to as an undisciplined local clock) if no exter-
nal reference clocks are accessible. You can use any address in the range

127.127.1.0 to 127.127.1.255, although the convention is to use 127.127.1.0. The
line fudge 127.127.1.0 stratum 10 limits the use of the local lock by
assigning it a very low place in the time server hierarchy, the intent being to
prevent the local clock from interfering with other, likely more accurate time
sources elsewhere on network and to enable (or, perhaps, compel) ntpd to look
pretty hard for other time sources before using the undisciplined local clock. In
its normal operation, ntpd listens for broadcasts from other time servers when
trying to find a reference clock. If it finds a time server declaring itself at a
higher stratum than 10, ntpd will use the higher-stratum clock instead of the
undisciplined local clock.
The directive driftfile /var/lib/ntp/drift specifies the name of the
file that stores the oscillation frequency of the local clock. NTP uses this fre-
quency, which varies slightly over time, to make appropriate adjustments to
the system time. The broadcastdelay directive sets the number of seconds
(0.008 in this case) used to calculate the network latency or delay between the
local server and a remote reference server. On a LAN, values between 0.003
and 0.007 seconds are suitable, but when two servers must communicate
across the Internet, it is often necessary to use a longer delay value.
The last line, keys /etc/ntp/keys, tells NTP where to find the crypto-
graphic keys used to encrypt exchanges between client and server machines.
The purpose for encrypting the data exchange is to prevent an unauthorized
reference server accidentally or deliberately sending time signals to your local
time server. Another reason to use encryption is when you enable remote NTP
administration and want to make sure that only properly authorized and
authenticated systems can perform remote administration.
NTP version 4 (NTPv4) supports asymmetric encryption, more commonly
known as public key encryption, using a method or protocol referred to as
autokey but the default configuration on Fedora Core and RHEL systems as
installed doesn’t use it without some configuration work. If you wish to use
Providing Additional Network Services 399

23_599496 ch17.qxd 8/30/05 6:41 PM Page 399
server-side encryption, the following procedure creates a basic autokey setup.
You should use the following procedure on the system that will be configured
as an NTP server. The next section, “Configuring an NTP Client,” describes
configuring client authentication. Although advisable, it isn’t strictly neces-
sary to set up encryption. Of course, wearing seat belts while driving is advis-
able, but isn’t strictly necessary.
1. Add the following lines to /etc/ntp.conf:
broadcast 224.0.1.1 autokey
crypto pw serverpassword
keysdir /etc/ntp
Replace serverpassword with a password of your choosing.
2. Generate the key files and certificates using the following commands:
# cd /etc/ntp
# ntp-keygen -T -I -p serverpassword
Using OpenSSL version 90701f
Random seed file /root/.rnd 1024 bytes
Generating IFF parameters (512 bits)
IFF 0 60 81 1 49 111 2 1 2 3 1 2
Generating IFF keys (512 bits)
Confirm g^(q - b) g^b = 1 mod p: yes
Confirm g^k = g^(k + b r) g^(q - b) r: yes
Generating new iff file and link
ntpkey_iff_ntpbeast.example.com- \
>ntpkey_IFFpar_ntpbeast.example.com.3318548048
Generating RSA keys (512 bits)
RSA 0 24 112 1 11 135 3 1 4
Generating new host file and link
ntpkey_host_ntpbeast.example.com- \
>ntpkey_RSAkey_ntpbeast.example.com.3318548048

Using host key as sign key
Generating certificate RSA-MD5
X509v3 Basic Constraints: critical,CA:TRUE
X509v3 Key Usage: digitalSignature,keyCertSign
X509v3 Extended Key Usage: trustRoot
Generating new cert file and link
ntpkey_cert_ntpbeast.example.com->ntpkey_RSA- \
MD5cert_ntpbeast.example.com.3318548048
The output wraps (indicated by \ in the listing) because of page layout
constraints.
3. If ntpd is running, restart it:
# service ntpd restart
Shutting down ntpd: [ OK ]
Starting ntpd: [ OK ]
400 Chapter 17
23_599496 ch17.qxd 8/30/05 6:41 PM Page 400