[Chapter 8] 8.4 Using nslookup
> ls big.com > temp.file
[minerals.big.com]
########
Received 406 records.
> view temp.file
acmite 192.168.20.28
adamite 192.168.20.29
adelite 192.168.20.11
agate 192.168.20.30
alabaster 192.168.20.31
albite 192.168.20.32
allanite 192.168.20.20
altaite 192.168.20.33
alum 192.168.20.35
aluminum 192.168.20.8
amaranth 192.168.20.85
amethyst 192.168.20.36
andorite 192.168.20.37
apatite 192.168.20.38
beryl 192.168.20.23
More q
> exit
These examples show that nslookup allows you to:
● Query for any specific type of standard resource record.
● Directly query the authoritative servers for a domain.
● Get the entire contents of a domain into a file so you can view it.
Use nslookup's help command to see its other features. Turn on debugging (with set debug) and examine
the additional information this provides. As you play with this tool, you'll find many helpful features.
Previous: 8.3 Configuring
named
TCP/IP Network
Administration
Next: 8.5 Summary
8.3 Configuring named
Book Index
8.5 Summary
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch08_04.htm (4 of 4) [2001-10-15 09:18:26]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 8] 8.5 Summary
Previous: 8.4 Using
nslookup
Chapter 8
Configuring DNS Name
Service
Next: 9. Configuring
Network Servers
8.5 Summary
Domain Name Service (DNS) is an important user service that should be used on every system
connected to the Internet. UNIX implementations of DNS are based on the Berkeley Internet Name
Domain (BIND) software. BIND provides both a DNS client and a DNS server.
The BIND client issues name queries and is implemented as library routines. It is called the resolver.
The resolver is configured in the resolv.conf file. All systems run the resolver.
The BIND server answers name queries and it runs as a daemon. It is called named. named is
configured by the named.boot file, which defines where the server gets the domain database
information and the type of server being configured. The server types are primary, secondary and
caching servers. Because all servers are caching servers, a single configurtaion often encompasses
more than one server type.
The original domain database source files are found on the primary server. The domain database file
is called a zone file. The zone file is constructed from standard resources records (RR) that are defined
in RFCs. The RRs share a common structure and are used to define all DNS database information.
The DNS server can be tested using nslookup. This test tool is included with the BIND release.
In this chapter we have seen how to configure and test domain name service. In the next chapter we
configure several other services.
Previous: 8.4 Using
nslookup
TCP/IP Network
Administration
Next: 9. Configuring
Network Servers
8.4 Using nslookup
Book Index
9. Configuring Network
Servers
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch08_05.htm [2001-10-15 09:18:27]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
Previous: 8.5 Summary
Chapter 9
Next: 9.2 Line Printer
Daemon
9. Configuring Network Servers
Contents:
The Network File System
Line Printer Daemon
Network Information Service
A BOOTP Server
DHCP
Managing Distributed Servers
Mail Servers
Summary
Now our attention turns to configuring 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. We concentrate on servers
that provide "computer-to-computer" services. [1] The services covered in this chapter are:
[1] Notably absent is sendmail. It requires so much discussion, it has its own chapter (
Chapter 10,
sendmail )!
● The Network File System (NFS)
● The Line Printer Daemon (LPD)
● The Network Information Service (NIS)
● The Bootstrap Protocol (BOOTP)
● Dynamic Host Configuration Protocol (DHCP)
● The Post Office Protocol (POP)
We begin with NFS, which is the server that provides file sharing on UNIX networks.
9.1 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 implementations 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.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (1 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
NFS has several benefits:
● It reduces local disk storage requirements because a network can store a single copy of a directory, while
the directory continues to be fully accessible to everyone on the network.
● NFS simplifies central support tasks - files can be updated centrally, yet available throughout the network.
● NFS 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 a directory. [2] 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 share and mount directories using NFS.
[2] An older term for this function is exporting. Many systems still refer to file sharing as
exporting.
If you're responsible for an NFS server for a large site, you should take care in planning and implementing the
NFS environment. The discussion in this chapter tells 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).
9.1.1 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:
nfsd [nservers]
The NFS daemon, nfsd, runs on NFS servers. This daemon services the client's NFS requests. The
nservers option is available on Solaris systems. It specifies how many daemons should be started.
mountd
The NFS mount daemon, mountd, processes the clients' mount requests. NFS servers run the mount
daemon.
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.
The daemons necessary to run NFS are started from boot scripts. On a Solaris system, two scripts located in the
/etc/init.d directory, nfs.client and nfs.server, handle this job. The nfs.client script starts the statd and lockd
programs. [3] NFS server systems run those two daemons, plus the NFS server daemon, nfsd, and the mount
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (2 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
server daemon, mountd. On Solaris systems, the nfs.server script starts mountd and 16 copies of nfsd.
[3] On your system, the prefix "rpc." may be used on the daemon names. For example, the
Slackware Linux system uses the filename rpc.nfsd for the NFS daemon. Check your system's
documentation.
Each system has its own technique for starting these daemons. If some of the daemons aren't starting, make sure
your startup scripts are correct.
9.1.2 Sharing Filesystems
The first step in configuring a server is deciding which filesystems will be shared, and what restrictions will be
placed on them. Only filesystems that provide a benefit to the client should be shared. Before you share a
filesystem, think about what purpose it will serve. Some common reasons for sharing filesystems are:
● To provide disk space to diskless clients
● To prevent unnecessary duplication of the same data on multiple systems
● To provide centrally supported programs and data
● To share data among users in a group
Once you've selected the filesystems you'll share, you must configuring them for sharing using the appropriate
commands for your system. In the following sections we emphasize the way this is done on Solaris systems. It is
very different on Linux systems. Check your system's documentation to find out exactly how it implements NFS
file sharing.
9.1.2.1 The share command
On Solaris systems, directories are shared using the share command.
A simplified syntax for the share command is:
share -F nfs [-o options] pathname
where pathname is the path of the directory the server is offering to share with its clients, and options are
the access controls for that directory. The commonly used options are:
rw
The rw option grants read and write access to the shared filesystem. It can be specified in the form
rw=host:host to identify the individual hosts that are granted this access. When used in this way, only
the hosts identified in the list are given access to the filesystem. If the colon-separated list of hostnames is
not provided with the rw option, all hosts are given read/write access to the filesystem. In fact, if no
options are specified at all, the share command defaults to giving all clients read/write access. This
default is acceptable if your systems are on an isolated network, but if they are on a connected network,
this could open up a security hole. It is the best practice to restrict access to those hosts that you really
trust.
ro
This option limits access to read-only. It also can be specified with a colon-separated host list, e.g.,
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (3 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
ro=host:host When the host list is included, only the hosts on the list have access and that access is
limited to read-only.
root=host
This option allows the root user on the specified host to have root access to the shared filesystem.
Normally, the root user on a remote system is mapped to the userid nobody and given only normal user
privileges. Granting root access is a big security risk.
The rw and ro options can be combined to grant different levels of access to different clients. For example:
share -F nfs -o rw=almond:pecan ro /usr/man
share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research
The first share command grants read and write access to almond and peanut and read-only access to all other
clients. On the other hand, the second share command grants read/write access to peanut, almond, pecan, and
walnut, and no access of any kind to any other client.
The share command does not survive a boot. Put the share commands in the /etc/dfs/dfstab file to make sure that
the filesystems continue to be offered to your clients even if the system reboots. Here is a sample dfstab file
containing our two share commands:
% cat /etc/dfs/dfstab
# place share(1M) commands here for automatic execution
# on entering init state 3.
#
# share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs" /export/home2
share -F nfs -o rw=almond:pecan ro /usr/man
share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research
The share command, the dfstab file, and even the terminology "share" are Solaris-specific. Most UNIX systems
say that they are exporting files, instead of sharing files, when they are offering files to NFS clients. Furthermore,
they do not use the share command or the dfstab file; instead, they offer filesystems through the /etc/exports file.
Linux is an example of such a system.
9.1.2.2 The /etc/exports file
The /etc/exports file is the NFS server configuration file for Linux systems. It controls which files and directories
are shared (exported), which hosts can access them, and what kinds of access are allowed. A sample /etc/exports
file might contain these entries:
/usr/man almond(rw) pecan(rw) (ro)
/usr/local (ro)
/home/research peanut(rw) almond(rw) pecan(rw) walnut(rw)
This sample file says that:
● /usr/man can be mounted by any client, but it can be written to only by almond and pecan. Other clients
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (4 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
have read-only access.
● /usr/local can be mounted by any client, with read-only access.
● /home/research can be mounted only by the hosts peanut, almond, pecan, and walnut. These four hosts
have read-write access.
The options used in each of the entries in the /etc/exports file determine what kinds of access are allowed. The
information derived from the sample file is based on the options specified on each line in the file. The general
format of the entries is as follows:
directory [host(option)]
directory names the directory or file that is available for export. The host is the name of the client granted
access to the exported directory while the option specifies the type of access being granted. The options used
in the sample file are:
ro
Read-only prevents NFS clients from writing to this directory. Attempts by clients to write to a read-only
directory fail with the message: "Read-only filesystem" or "Permission denied." If ro is specified without
a client hostname, all clients are granted read-only access.
rw
Read-write permits clients to read and write to this directory. When specified without hostname, as simply
(rw), all clients are granted read-write access. If a hostname is specified, only the named host is given
read-write permission.
9.1.3 Mounting Remote Filesystems
You need some basic information before you can decide which NFS directories to mount on your system. You
need to know which servers are connected to your network, and which directories are available from those
servers. A directory cannot be mounted unless it is first exported by a server.
Your network administrator is a good source for this information. The administrator can tell you what systems
are providing NFS service, what directories they are exporting, and what these directories contain. If you are the
administrator of an NFS server, you should develop this type of information for your users. See
Chapter 4,
Getting Started .
On Solaris systems you can also obtain information about the shared directories directly from the servers by
using the showmount command. The NFS servers are usually the same centrally supported systems that provide
other services such as mail and domain name service. Select a likely server and query it with the command
showmount -e hostname. In response to this command, the server lists the directories that it exports and the
conditions applied to their export.
For example, a showmount -e query to filbert produces the following output:
% showmount -e filbert
export list for filbert:
/usr/man (everyone)
/home/research peanut,almond,walnut,pecan
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (5 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
/usr/local (everyone)
The export list shows the NFS directories exported by filbert, as well as who is allowed to access those
directories. From this list, peanut's administrator may decide to mount any of the directories offered by filbert.
Our imaginary administrator decides to:
1. Mount /usr/man from filbert instead of maintaining the man pages locally.
2. Mount /home/research to more easily share files with other systems in the research group.
3. Mount the centrally maintained programs in /usr/local.
These selections represent some of the most common motivations for mounting NFS directories. These are to:
● Save disk space
● Share files with other systems
● Maintain common files centrally
The amount to which you use NFS is a personal choice. Some people prefer the greater personal control you get
from keeping files locally, while others prefer the convenience offered by NFS. Your site may have guidelines
for how NFS should be used, which directories should be mounted, and which files should be centrally
maintained. Check with your network administrator if you're unsure about how NFS is used at your site.
9.1.3.1 The mount command
A client must mount a shared directory before using it. "Mounting" the directory attaches it to the client's
filesystem hierarchy. Only directories offered by the servers can be mounted, but any part of the offered
directory, such as a subdirectory or a file, can be mounted.
NFS directories are mounted using the mount command. The general structure of the mount command is:
mount hostname:remote-directory local-directory
The hostname identifies an NFS server, and the remote-directory identifies all or part of a directory
offered by that server. The mount command attaches that remote directory to the client's filesystem using the
directory name provided for local-directory. The client's local directory, called the mount point, must be
created before mount is executed. Once the mount is completed, files located in the remote directory can be
accessed through the local directory exactly as if they were local files.
For example, assume that filbert.nuts.com is an NFS server and that it shares the files shown in the section above.
Further assume that the administrator of peanut wants to access the /home/research directory. The administrator
simply creates a local /home/research directory, and mounts the remote /home/research directory offered by
filbert on this newly created mount point.
# mkdir /home/research
# mount filbert:/home/research /home/research
Once a remote directory is mounted, it stays attached to the local file system until it is explicitly dismounted or
the local system reboots. To dismount a directory, use the umount command. On the umount command line,
specify either the local or remote name of the directory that is to be dismounted. For example, the administrator
of peanut can dismount the remote filbert:/home/research filesystem from the local /home/research mount point,
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (6 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
with either:
# umount /home/research
or:
# umount filbert:/home/research
Booting also dismounts NFS directories. Because systems frequently wish to mount the same filesystems every
time they boot, UNIX provides a system for automatically remounting after a boot.
9.1.3.2 The vfstab and fstab files
UNIX systems use the information provided in a special table to remount all types of filesystems, including NFS
directories, after a system reboot. The table is a critical part of providing users consistent access to software and
files, so care should be taken whenever it is modified. Two different files with two different formats are used for
this purpose by the different flavors of UNIX. Linux and BSD systems use the /etc/fstab file and Solaris, our
System V example, uses the /etc/vfstab file.
The format of the NFS entries in the Solaris vfstab file is:
filesystem - mountpoint nfs - yes options
The various fields in the entry must appear in the order shown above and they must be separated by whitespace.
The items in bold (both dashes and the words nfs and yes) are keywords that must appear exactly as shown
above. filesystem is the name of the directory offered by the server. mountpoint is the pathname of the
local mount point, and options are the mount options discussed below. A sample NFS vfstab entry is:
filbert:/home/research - /home/research nfs - yes rw,soft
This entry mounts the NFS filesystem filbert:/home/research on the local mount point /home/research. The
filesystem is mounted with the rw and soft options set. The mount options available on Solaris systems are:
rw
If permitted, mount the filesystem read/write. If the filesystem is restricted by the server to read-only, a
warning is issued and the filesystem is mounted read-only.
ro
Mount the filesystem read-only.
remount
If the filesystem is already mounted read-only, remount the filesystem as read/write.
soft
If the server fails to respond, return an error and don't retry the request.
hard
If the server fails to respond, retry until it does respond. This is the default.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (7 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm
bg
Do the retries in background mode.
fg
Do the retries in foreground mode.
intr
Allow a keyboard interrupt to kill a process that is hung waiting for the server to respond. Hard-mounted
filesystems can become hung because the client retries forever, even if the server is down. This is a
default.
nointr
Don't allow keyboard interrupts. In general, this is a bad idea.
nosuid
Do not allow an executable stored on the mounted filesystem to run setuid. This improves security but
may limit utility.
On the Solaris system, the NFS filesystems defined in the vfstab file are mounted by a mountall command
located in a startup file. On the Linux system, the startup file contains a mount command with the -a flag set,
which causes Linux to mount all filesystems listed in fstab. The format of NFS entries in the /etc/fstab file is:
filesystem mountpoint nfs options
The fields must appear in the order shown and must be separated by whitespace. The keyword nfs is required for
NFS filesystems. filesystem is the name of the directory being mounted. mountpoint is the pathname of
the local mount point. options are any of the Linux mount options listed in
Table 9.1
Table 9.1: Linux Mount Options
Option Purpose
async Use asynchronous file I/O.
auto Mount when -a option is used.
dev Allow character and block special devices on the filesystem.
exec Permit execution of files from the filesystem.
noauto Don't mount with the -a option.
nodev Don't allow character and block special devices on the filesystem.
noexec Don't allow execution of files from the filesystem.
nosuid Don't allow programs stored on the filesystem to run setuid or setgid.
nouser Only root can mount the filesystem.
remount Remount a mounted filesystem with new options.
ro Mount the filesystem read-only.
rw Mount the filesystem read-write.
suid Allow programs to run setuid or setgid.
sync Use synchronous filesystem I/O.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (8 of 13) [2001-10-15 09:18:29]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Không có nhận xét nào:
Đăng nhận xét