- 论坛徽章:
- 0
|
Van's NFSv3 mini-HOWTO
Introduction
I recently needed to setup NFS between some Red Hat Linux systems. I had two different types of
NFS connections to setup: a permanent read-only (RO) directory for copying software, and some
automatically mounted home directories. Although you can use the redhat-config-nfs GUI
tool, it is good to know what is going on under the hood. These are my notes on setting up NFS
in both scenarios.
The notes were based on a stock Red Hat 8 NFS server, and a stock Red Hat 9 client. The NFS
server is named "im" and has IP address 192.168.1.2 with a /24 netmask. The NFS client is named
"tp1" and has IP address 192.168.1.191 with a /24 netmask. In this example, I will force the use
of NFSv3.
Exporting a Read-Only File System Mapped to the Anonymous UID/GID:
This is an example of a directory that you want
available throughout your LAN, but you don't want anyone writing to that directory.
Add the following entry to /etc/exports:
# Van's NFS export file
/Data/Photos 192.168.1.0/24(ro,all_squash,anonuid=65534,anongid=65534)
(There should already be a user called "nfsnobody" with UID/GID=65534)
Add the following entry to /etc/hosts.deny:
portmap: ALL
Add the following entry to /etc/hosts.allow:
portmap: 192.168.1.0/255.255.255.0
This prevents hosts from other networks from connecting to the portmapper.
Now start the portmapper, nfsd, and related daemons:
# /etc/init.d/portmap start
Starting portmapper: [ OK ]
# /etc/init.d/nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
# /etc/init.d/nfslock start
Starting NFS statd: [ OK ]
When you make changes to /etc/exports, you should enter the following command to re-read the
export table:
# exportfs -rv
exportfs: No 'sync' or 'async' option specified for export "192.168.1.0/24:/Data/Photos".
Assuming default behaviour ('sync').
NOTE: this default has changed from previous versions
exporting 192.168.1.0/24:/Data/Photos
Now, let's make sure everything is working properly:
# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 762 rquotad
100011 2 udp 762 rquotad
100011 1 tcp 765 rquotad
100011 2 tcp 765 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 32781 nlockmgr
100021 3 udp 32781 nlockmgr
100021 4 udp 32781 nlockmgr
100005 1 udp 32782 mountd
100005 1 tcp 33396 mountd
100005 2 udp 32782 mountd
100005 2 tcp 33396 mountd
100005 3 udp 32782 mountd
100005 3 tcp 33396 mountd
100024 1 udp 32783 status
100024 1 tcp 33397 status
# showmount -e
Export list for im.vanemery.com:
/Data/Photos 192.168.1.0/24
# exportfs
/Data/Photos 192.168.1.0/24
The netstat -tuap command should also give you a good idea of what TCP and UDP ports are
listening now.
Final server setup: You will want to make sure that the portmapper and all the NFS-related
daemons start at boot time. You can do this with the following commands:
# chkconfig portmap off
# chkconfig nfs off
# chkconfig nfslock off
# chkconfig --level 345 portmap on
# chkconfig --level 345 nfs on
# chkconfig --level 345 nfslock on
Also, you need to make sure that you don't have a Linux firewall like iptables automatically
blocking the connections.
Mounting the Read-Only NFS filesystem on the NFS Client:
Prerequisites: The client must be running the portmapper service and the rpc.statd service. If you need
file locking, you must also be running the NFS lock daemon. You do not need to be running
rquotad, nfsd, or mountd. By running /etc/init.d/portmap and /etc/init.d/nfslock, I had everything
ready for the NFS mount. After mounting the NFS partition, running rpcinfo -p on the client showed me
that the "status" RPC service had been started automatically. This is called "rpc.statd" in the
ps listings. You will probably want to secure the portmapper and other RPC services
with /etc/hosts.allow and /etc/hosts.deny, just like you did on the server.
On the client, make sure you do not have a firewall like iptables enabled, or it will
prevent you from making the NFS connection. Now, let's check RPC and UDP connectivity to the
NFS server:
[tp1]# ping im
[tp1]# showmount -e im
Export list for im:
/Data/Photos 192.168.1.0/24
[tp1]# rpcinfo -p im
[tp1]# tracepath im/2049
1?: [LOCALHOST] pmtu 1500
1: im (192.168.1.2) 0.371ms reached
Resume: pmtu 1500 hops 1 back 1
Based on the output of these commands, you should be able to see if the client will be able
to make an NFS connection to the server or not.
Make a mountpoint for the directory:
[TP1]# mkdir /mnt/Photos
Mount the NFS server manually:
[tp1]# mount -t nfs -o hard,intr,ro,rsize=2048,wsize=2048,nfsvers=3 im:/Data/Photos /mnt/Photos
[tp1]# mount
im:/Data/Photos on /mnt/Photos type nfs (ro,hard,intr,rsize=2048,wsize=2048,addr=192.168.1.2)
Test from root and non-root accounts on tp1 to see if directory and file read operations work. Commands like
df, du, ls, cd, and cp should work just fine.
Now, let's look at stats back on the server:
# showmount -a
All mount points on im.vanemery.com:
tp1:/Data/Photos
# nfsstat
# nfsstat -o net
Warning: /proc/net/rpc/nfs: No such file or directory
Server packet stats:
packets udp tcp tcpconn
353441 353441 0 0
Client packet stats:
packets udp tcp tcpconn
0 0 0 0
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:E0:29:42:F8:C2
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:391457 errors:0 dropped:0 overruns:0 frame:37
TX packets:698615 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:89280722 (85.1 Mb) TX bytes:846404790 (807.1 Mb)
Interrupt:10 Base address:0xb400
# netstat -s
# cat /proc/net/snmp
Back on the client, let's make sure that no process or user is accessing files via NFS, including
having a shell open in the NFS directory. Then we will unmount the NFS directory like this:
[tp1]# umount /mnt/PhotosLet us setup our /etc/fstab file on the client so that the NFS mount happens automatically on
boot:
im:/Data/Photos /mnt/Photos nfs ro,hard,intr,rsize=2048,wsize=2048,nfsvers=3,bg 0 0
You can test this with the mount -av command without rebooting the server.
Final Comments on Read-Only NFS
I selected the rsize=2048 and wsize=2048 option for this NFS mount based on some testing I did with
copying 90MB worth of files over the network to the client with different rsize settings. I tried a
number of settings, and 2048 was the 2nd fastest next to 8192. 8192 produced UDP datagrams fragmented
into 6 IP packets, 5 of which were max size at 1514 bytes on the wire. I don't want that many max sized
packets or fragments on my LAN. 2048 gave reasonable performance and only produced 2 IP fragments
per UDP datagram. This leaves more space on the LAN for other traffic, especially if you are using a
repeater instead of a switch.
Using the Automounter to Mount Home Directories over the Network:
What if you would like users on a remote host to be able to mount their home directories from a
central server? With conventional NFS mounts, only root can mount and unmount NFS directories.
With the automount utility (a.k.a. autofs), NFS directories can be mounted and unmounted automatically
as needed by regular users.
This section will show you how to set up the automounter on an NFS client so that machine tp1's
users can login to their home directories on a central NFS server. This has several advantages:
- user files are centrally stored and managed
- user files can easily be backed up
- the server is more likely to be running hardware RAID and to be physically secured
In this scenaro, host "im" is the NFS server, host "tp1" is the client. User "gishj" will have his
home directory located on the NFS server. Also, the partition /dev/hdb2 is mounted to /ahome
as ext3. This partition has user quota support enabled.
Note: NFS assumes that users have the same UID and GID on the client machine as they
do on the server machine. The UIDs, GIDs, and usernames can be synchronized via several mechanisms, which
are outside the scope of this mini-HOWTO. Here is a short list of possibilities:
- NIS
- NIS+
- LDAP
- /etc file replication via various mechanisms
- manual user/group creation and synchronization on each host
On the server, identify a directory for NFS-mounted user homes. Create the directory
and partition as needed. Each user's home directory needs to be "chown"ed and "chmod"ed appropriately.
For this example, I will create a new user and group for "gishj" on the server and the client with the same
UID and GID.
[root@im /]# mkdir /ahome
[root@im /]# useradd -d /ahome/gishj -u 600 gishj
Note that the /etc/skel files were put here by the useradd utility, allowing you
to create a standard user environment for every user on the server.
Now, let's export the filesystem via NFS with appropriate options. Add this line to
/etc/exports:
/ahome 192.168.1.0/24(rw,sync,root_squash)
Activate the NFS export and verify it with these commands:
# exportfs -rv
exporting 192.168.1.0/24:/ahome
# showmount -e
Export list for im.vanemery.com:
/ahome 192.168.1.0/24
# exportfs -v
/ahome 192.168.1.0/24(rw,wdelay,root_squash)
On the client, let's make sure we can see the NFS export on the server:
[tp1]# showmount -e im
Export list for im:
/ahome 192.168.1.0/24
On the client, let's setup the automount map by adding this to /etc/auto.master:
/autohome /etc/auto.autohome --timeout=120
Create a new file called /etc/auto.autohome and add these lines:
# This is for mounting user homes over NFS
# Format = key [-mount-options-separated-by-comma] location
* -fstype=nfs,rw,hard,intr,rsize=2048,wsize=2048,nosuid,nfsvers=3 im:/ahome/&
The wildcards "*" and "&" allow usernames to be inserted as NFS paths. "rw" allows read and write
operations, and "nosuid" is a security option. If you want to read more about the allowable wildcards
in the autofs maps, try man 5 autofs.
Now, let's create the mountpoint and activate the automounter, and set it up to start
automatically on boot:
[tp1]# mkdir /autohome
[tp1]# /etc/init.d/autofs start
Starting automount: [ OK ]
[tp1]# chkconfig autofs off
[tp1]# chkconfig --level 345 autofs on
We need to make an account and add a password for user "gishj". Remember, the UID/GID needs to
be the same on the client as on the server, and we will be configuring Joe Gish's home directory to
be at /ahome/gishj.
[root@tp1 /]# useradd -M -d /autohome/gishj -u 600 gishj
[root@tp1 /]# passwd gishj
Changing password for user gishj.
New password: ********
Retype new password: ******
passwd: all authentication tokens updated successfully.
Now, login on tp1 as "gishj". You should be able to login. If you issue a pwd command, you will
see that you are in the /autohome/gishj directory, and you will be able to read and write
files with no problem. If you use the "mount" command, you will see this:
automount(pid1510) on /autohome type autofs (rw,fd=5,pgrp=1510,minproto=2,maxproto=3)
im:/ahome/gishj on /autohome/gishj type nfs (rw,nosuid,hard,intr,rsize=2048,wsize=2048,nfsvers=3,addr=192.168.1.2)
After Joe Gish logs out, 2 minutes later the auto-mounter will unmount the NFS directory. When you use the
mount command on tp1 again (as root), here is what you will see:
automount(pid1510) on /autohome type autofs (rw,fd=5,pgrp=1510,minproto=2,maxproto=3)
Final Comments on Automounting NFS directories:
The automount maps can be distributed via NIS, NIS+, LDAP, or other means. Back on the NFS
server, you can watch the automount operation with watch showmount -a. Note that the user on
the NFS clients does not need to be able to login to the NFS server. If you don't run passwd for
the user on the server, they will not be able to login, but they can still use their home directory over
the network.
Limiting the disk space for each user on the NFS server with quotas:
If you are using ext2/ext3 or ReiserFS for your automount partition on the server, then you can setup
quotas for each user. This limits how much disk space each user can have. This may also be possible
in some kernels with JFS and XFS, but I have not looked into this. When quotas are enabled, the
user on the NFS client can still view his or her quota by typing the quota command. I tested the
quota function by logging in as one of the users and copying lots of files to my home directory.
As expected, when I exceeded my quota, further copy operations failed with an error. Removing some files
fixed my quota problem, and I could write to the NFS directory again.
NFSv4
This mini-HOWTO has focused on NFSv3 for Linux. The NFSv2 and NFSv3 implementations for Linux are
fairly mature now, with the exception of TCP support (client and server) for NFSv3, which will be
incorporated in future kernels. NFSv4 is being actively developed for Solaris and Linux.
NFSv4 will become an Internet standard for filesharing over a network. It has some key improvements
over NFSv3:
- Will work over TCP with portmapper and mount functions integrated. This means a client can
connect to a server with a single TCP connection - Works with/through NAT firewalls
- Includes MANDATORY encryption and security support (Kerberos 5 and LIPKEY)
- Support for ACLs
NFSv4 will be part of the standard 2.6 Linux kernels.
http://www.vanemery.com/Linux/NFS-Van.html
本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/31550/showart_548158.html |
|