Библиотека сайта rus-linux.net
Purchase | Copyright © 2002 Paul Sheer. Click here for copying permissions. | Home |
Next: 29. Services Running Under Up: rute Previous: 27. DNS and Name   Contents
Subsections
28. Network File System, NFS
This chapter covers NFS, the file-sharing capabilities of UNIX, and describes how to set up directories shareable to other UNIX machines.
As soon as one thinks of high-speed Ethernet, the logical possibility of sharing a file system across a network comes to mind. MS-DOS, OS/2, Apple Macintosh, and Windows have their own file-sharing schemes (IPX, SMB etc.), and NFS is the UNIX equivalent.
Consider your hard drive with its 10,000 or so files. Ethernet is fast enough that you should be able to entirely use the hard drive of another machine, transferring needed data as network packets as required; or you should be able to make a directory tree visible to several computers. Doing this efficiently is a complex task. NFS is a standard, a protocol, and (on LINUX) a software suite that accomplishes this task in an efficient manner. It is really easy to configure as well. Unlike some other sharing protocols, NFS merely shares files and does not facilitate printing or messaging.
28.1 Software
Depending on your distribution, the following programs may be located in any
of the
bin
or
sbin
directories. These are all daemon
processes. To get NFS working, they should be started in the order given here.
portmap
- (also sometimes called
rpc.portmap
) This maps service names to ports. Client and server processes may request a TCP port number based on a service name, andportmap
handles these requests. It is basically a network version of your/etc/services
file. rpc.mountd
- (also sometimes called
mountd
) This handles the initial incoming request from a client tomount
a file system and check that the request is allowable. rpc.nfsd
- (also sometimes called
nfsd
) This is the core--the file-server program itself. rpc.lockd
- (also sometimes called
lockd
) This handles shared locks between different machines on the same file over the network.
The acronym RPC stands for Remote Procedure Call. RPC was developed along with NFS by Sun Microsystems. It is an efficient way for a program to call a function on another machine and can be used by any service that needs to have efficient distributed processing. These days, its not really used for much except NFS, having been superseded by technologies like CORBA. [The ``Object-Oriented'' version of RPC] You can however, still write distributed applications with LINUX's RPC implementation.
28.2 Configuration Example
Sharing a directory with a remote machine requires that forward and
reverse
DNS lookups be working for the server machine as well as all
client machines. DNS is covered in Chapter 27 and
Chapter 40. If you are just testing NFS and you are
sharing directories to your local machine (which we do now), you
may find NFS to still work without a proper DNS setup. You
should at least have proper entries in your
/etc/hosts
file
for your local machine (see page ).
The first step is deciding on the directory you would like to share. A
useful trick is to share your CD-ROM to your whole LAN. This is perfectly
safe considering that CDs are read-only. Create an
/etc/exports
file with the following in it:
|
/mnt/cdrom 192.168.1.0/24(ro) localhost(ro) |
You can immediately see that the format of the
/etc/exports
file is simply a line for each shareable directory. Next to each directory
name goes a list of hosts that are allowed to connect. In this case, those
allowed access are all IP addresses having the upper 24 bits matching
192.168.1
, as well as the
localhost
.
Next, mount your CD-ROM as usual with
|
mkdir -p /mnt/cdrom mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom |
Now start each of the NFS processes in sequence:
|
portmap rpc.mountd rpc.nfsd rpc.lockd |
Whenever you make changes to your
/etc/exports
file you should also follow by running
|
exportfs -r |
which causes a rereading of the
/etc/exports
file.
Entering the
exportfs
command with no options should then
show
|
/mnt/cdrom 192.168.1.0/24 /mnt/cdrom localhost.localdomain |
which lists directories and hosts allowed to access them.
It is useful to test mounts from your local machine before testing from a remote machine. Here we perform the NFS mounting operation proper:
|
mkdir /mnt/nfs mount -t nfs localhost:/mnt/cdrom /mnt/nfs |
You can see that the
mount
command sees the remote
machine's directory as a ``device'' of sorts, although the
t
ype
is
nfs
instead of
ext2
,
vfat
, or
iso9660
. The
remote host name is followed by a colon followed by the directory on that
remote machine relative to the root directory. This syntax is unlike
that for other kinds of services that name all files relative to some
``top level'' directory (eg., FTP and web servers). The acid test now
is to run
ls
on the
/mnt/nfs
directory to verify that its
contents are indeed the same as
/mnt/cdrom
. Supposing our server is
called
cdromserver
, we can run the same command on all client
machines:
|
mkdir /mnt/nfs mount -t nfs cdromserver:/mnt/cdrom /mnt/nfs |
If anything went wrong, you might like to search your process
list for all processes with an
rpc
,
mount
,
nfs
, or
portmap
in them. Completely stopping NFS means clearing all of
these processes (if you really want to start from scratch). It is useful
to also keep
|
tail -f /var/log/messages tail -f /var/log/syslog |
running in a
separate console to watch for any error (or success)
messages (actually true of any configuration you are doing). Note that
it is not always obvious that NFS is failing because of a forward or
reverse DNS lookup, so double-check beforehand that these are
working--
mount
will not usually be more eloquent than the classic NFS
error message: ``
mount: <xyz> failed, reason given by server: Permission denied
.''
A faulty DNS is also indicated by whole-minute pauses in operation.
Most distributions will not require you to manually start and stop the daemon processes above. Like most services, RedHat's NFS implementation can be invoked simply with:
|
/etc/init.d/nfs start /etc/init.d/nfslock start |
(or
/etc/rc.d/init.d/
). On Debian, similarly,
|
/etc/init.d/nfs-common start /etc/init.d/nfs-kernel-server start |
28.3 Access Permissions
Above, we used
192.168.1.0/24(ro)
to specify that we want to
give
r
ead-
o
nly access to a range of IP addresses. You can
actually put host names with wildcards also; for example:
|
/mnt/cdrom *.mynet.mydomain.co.za(ro) |
Then also allow
r
ead-
w
rite access with, say:
|
/home *.mynet.mydomain.co.za(rw) |
One further option,
no_root_squash
, disables NFS's
special treatment of
root
-owned files. This option is useful if you are
finding certain files strangely inaccessible.
no_root_squash
is really only for
systems (like diskless workstations) that need full
root
access
to a file system. An example is:
|
/ *.very.trusted.net(rw,no_root_squash) |
The man page for
/etc/exports
,
exports
(5), contains an
exhaustive list of options.
28.4 Security
NFS requires that a number of services be running that have no use anywhere else.
Many naive administrators create directory exports with
impunity, thus exposing those machines to opportunistic hackers. An NFS
server should be well hidden behind a firewall, and any Internet server
exposed to the Internet should never run the
portmap
or RPC
services. Preferably uninstall all of these services if you are not
actually running an NFS server.
28.5 Kernel NFS
There are actually two versions of the NFS implementation for LINUX.
Although this is a technical caveat, it is worth understanding that the
NFS server was originally implemented by an ordinary daemon process
before the LINUX kernel itself supported NFS. Debian supports both
implementations in two packages,
nfs-server
and
nfs-kernel-server
, although the configuration should be
identical. Depending on the versions of these implementations and the
performance you require, one or the other may be better. You are advised
to at least check the status of the kernel NFS implementation on the
kernel web pages. Of course, NFS as a client must necessarily be
supported by the kernel as a regular file system type in order to be
able to mount anything.
Next: 29. Services Running Under Up: rute Previous: 27. DNS and Name   Contents