From e547601770f855055e5c77d4b21ec7e191a1ed7f Mon Sep 17 00:00:00 2001
From: binh <>
Date: Fri, 18 Feb 2005 11:53:35 +0000
Subject: [PATCH] More consolidation. Binh.
---
.../Protocols-Standards-Services.xml | 2440 -----------------
.../docbook/Linux-Networking/Sources.xml | 40 +-
2 files changed, 39 insertions(+), 2441 deletions(-)
diff --git a/LDP/guide/docbook/Linux-Networking/Protocols-Standards-Services.xml b/LDP/guide/docbook/Linux-Networking/Protocols-Standards-Services.xml
index 59c9d67a..2d7162cd 100644
--- a/LDP/guide/docbook/Linux-Networking/Protocols-Standards-Services.xml
+++ b/LDP/guide/docbook/Linux-Networking/Protocols-Standards-Services.xml
@@ -2399,84 +2399,12 @@ especially in large networks or networks which have lots of mobile users.
Resources section at the end of the document). You can also read
[32]http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html.
-4.5. Other interesting documents
-
- Linux Magazine has a pretty good article in their April issue called
- [62]Network Nirvana: How to make Network Configuration as easy as DHCP
- that discusses the set up for DHCP.
-
-References
-
- 1. DHCP.html#AEN17
- 2. DHCP.html#AEN19
- 3. DHCP.html#AEN24
- 4. DHCP.html#AEN41
- 5. DHCP.html#AEN45
- 6. DHCP.html#AEN64
- 7. DHCP.html#AEN69
- 8. DHCP.html#AEN74
- 9. DHCP.html#AEN77
- 10. DHCP.html#SLACKWARE
- 11. DHCP.html#REDHAT6
- 12. DHCP.html#AEN166
- 13. DHCP.html#AEN183
- 14. DHCP.html#DEBIAN
- 15. DHCP.html#AEN230
- 16. DHCP.html#NAMESERVER
- 17. DHCP.html#AEN293
- 18. DHCP.html#TROUBLESHOOTING
- 19. DHCP.html#AEN355
- 20. DHCP.html#AEN369
- 21. DHCP.html#DHCPSERVER
- 22. DHCP.html#AEN382
- 23. DHCP.html#AEN403
- 24. DHCP.html#AEN422
- 25. DHCP.html#AEN440
- 26. http://www.oswg.org/oswg-nightly/DHCP.html
- 27. http://www.linux.org.tw/CLDP/mini/DHCP.html
- 28. http://www.linux.or.jp/JF/JFdocs/DHCP.html
- 29. ftp://cuates.pue.upaep.mx/pub/linux/LuCAS/DHCP-mini-Como/
- 30. mailto:vuksan-feedback@veus.hr
- 31. http://www.opencontent.org/opl.shtml
- 32. http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
- 33. mailto:sergei@phystech.com
- 34. ftp://ftp.phystech.com/pub/
- 35. http://www.cps.msu.edu/~dunham/out/
- 36. ftp://metalab.unc.edu/pub/Linux/system/network/daemons
- 37. ftp://ftp.phystech.com/pub/
- 38. DHCP.html#NAMESERVER
- 39. DHCP.html#LINUXPPC-RH6
- 40. mailto:alexander.stevenson@home.com
- 41. DHCP.html#NAMESERVER
- 42. ftp://ftp.redhat.com/pub/redhat/redhat-4.2/i386/RedHat/RPMS/dhcpcd-0.6-2.i386.rpm
- 43. DHCP.html#SLACKWARE
- 44. mailto:nothing@cc.gatech.edu
- 45. DHCP.html#NAMESERVER
- 46. http://ftp.debian.org/debian/dists/slink/main/binary-i386/net/
- 47. DHCP.html#SLACKWARE
- 48. mailto:heiko@os.inf.tu-dresden.de
- 49. DHCP.html#NAMESERVER
- 50. DHCP.html#REDHAT6
- 51. ftp://ftp.linuxppc.org/
- 52. ftp://ftp.phystech.com/pub/dhcpcd-1.3.17-pl9.tar.gz
- 53. DHCP.html#TROUBLESHOOTING
- 54. mailto:nothing@cc.gatech.edu
- 55. DHCP.html#ERROR3
- 56. ftp://vanbuer.ddns.org/pub/
- 57. DHCP.html#DHCPSERVER
- 58. mailto:mellon@isc.org
- 59. ftp://ftp.isc.org/isc/dhcp/
- 60. http://www.kde.org/
- 61. ftp://ftp.us.kde.org/pub/kde/unstable/apps/network/
- 62. http://www.linux-mag.com/2000-04/networknirvana_01.html
-
DNS
-
Setting Up Your New Domain Mini-HOWTO.
@@ -2690,169 +2618,6 @@ Start the automounter. From now on, whenever you try to access the inexistent mo
Linux NFS-HOWTO
-Tavis Barr
-
- tavis dot barr at liu dot edu
-
-
-Nicolai Langfeldt
-
- janl at linpro dot no
-
-
-Seth Vidal
-
- skvidal at phy dot duke dot edu
-
-
-Tom McNeal
-
- trmcneal at attbi dot com
-
-
-2002-08-25
-Revision History
-Revision v3.1 2002-08-25 Revised by: tavis
-Typo in firewalling section in 3.0
-Revision v3.0 2002-07-16 Revised by: tavis
-Updates plus additions to performance, security
------------------------------------------------------------------------------
-
-Table of Contents
-1. Preamble
- 1.1. Legal stuff
- 1.2. Disclaimer
- 1.3. Feedback
- 1.4. Translation
- 1.5. Dedication
-
-
-2. Introduction
- 2.1. What is NFS?
- 2.2. What is this HOWTO and what is it not?
- 2.3. Knowledge Pre-Requisites
- 2.4. Software Pre-Requisites: Kernel Version and nfs-utils
- 2.5. Where to get help and further information
-
-
-3. Setting Up an NFS Server
- 3.1. Introduction to the server setup
- 3.2. Setting up the Configuration Files
- 3.3. Getting the services started
- 3.4. Verifying that NFS is running
- 3.5. Making changes to /etc/exports later on
-
-
-4. Setting up an NFS Client
- 4.1. Mounting remote directories
- 4.2. Getting NFS File Systems to Be Mounted at Boot Time
- 4.3. Mount options
-
-
-5. Optimizing NFS Performance
- 5.1. Setting Block Size to Optimize Transfer Speeds
- 5.2. Packet Size and Network Drivers
- 5.3. Overflow of Fragmented Packets
- 5.4. NFS over TCP
- 5.5. Timeout and Retransmission Values
- 5.6. Number of Instances of the NFSD Server Daemon
- 5.7. Memory Limits on the Input Queue
- 5.8. Turning Off Autonegotiation of NICs and Hubs
- 5.9. Synchronous vs. Asynchronous Behavior in NFS
- 5.10. Non-NFS-Related Means of Enhancing Server Performance
-
-
-6. Security and NFS
- 6.1. The portmapper
- 6.2. Server security: nfsd and mountd
- 6.3. Client Security
- 6.4. NFS and firewalls (ipchains and netfilter)
- 6.5. Tunneling NFS through SSH
- 6.6. Summary
-
-
-7. Troubleshooting
- 7.1. Unable to See Files on a Mounted File System
- 7.2. File requests hang or timeout waiting for access to the file.
- 7.3. Unable to mount a file system
- 7.4. I do not have permission to access files on the mounted volume.
- 7.5. When I transfer really big files, NFS takes over all the CPU cycles
- on the server and it screeches to a halt.
- 7.6. Strange error or log messages
- 7.7. Real permissions don't match what's in /etc/exports.
- 7.8. Flaky and unreliable behavior
- 7.9. nfsd won't start
- 7.10. File Corruption When Using Multiple Clients
-
-
-8. Using Linux NFS with Other OSes
- 8.1. AIX
- 8.2. BSD
- 8.3. Tru64 Unix
- 8.4. HP-UX
- 8.5. IRIX
- 8.6. Solaris
- 8.7. SunOS
-
-
-
-1. Preamble
-
-1.1. Legal stuff
-
-Copyright (c) <2002> by Tavis Barr, Nicolai Langfeldt, Seth Vidal, and Tom
-McNeal. This material may be distributed only subject to the terms and
-conditions set forth in the Open Publication License, v1.0 or later (the
-latest version is presently available at [http://www.opencontent.org/openpub
-/] http://www.opencontent.org/openpub/).
------------------------------------------------------------------------------
-
-1.2. Disclaimer
-
-This document is provided without any guarantees, including merchantability
-or fitness for a particular use. The maintainers cannot be responsible if
-following instructions in this document leads to damaged equipment or data,
-angry neighbors, strange habits, divorce, or any other calamity.
------------------------------------------------------------------------------
-
-1.3. Feedback
-
-This will never be a finished document; we welcome feedback about how it can
-be improved. As of February 2002, the Linux NFS home page is being hosted at
-[http://nfs.sourceforge.net] http://nfs.sourceforge.net. Check there for
-mailing lists, bug fixes, and updates, and also to verify who currently
-maintains this document.
------------------------------------------------------------------------------
-
-1.4. Translation
-
-If you are able to translate this document into another language, we would be
-grateful and we will also do our best to assist you. Please notify the
-maintainers.
------------------------------------------------------------------------------
-
-1.5. Dedication
-
-NFS on Linux was made possible by a collaborative effort of many people, but
-a few stand out for special recognition. The original version was developed
-by Olaf Kirch and Alan Cox. The version 3 server code was solidified by Neil
-Brown, based on work from Saadia Khan, James Yarbrough, Allen Morris, H.J.
-Lu, and others (including himself). The client code was written by Olaf Kirch
-and updated by Trond Myklebust. The version 4 lock manager was developed by
-Saadia Khan. Dave Higgen and H.J. Lu both have undertaken the thankless job
-of extensive maintenance and bug fixes to get the code to actually work the
-way it was supposed to. H.J. has also done extensive development of the
-nfs-utils package. Of course this dedication is leaving many people out.
-
-The original version of this document was developed by Nicolai Langfeldt. It
-was heavily rewritten in 2000 by Tavis Barr and Seth Vidal to reflect
-substantial changes in the workings of NFS for Linux developed between the
-2.0 and 2.4 kernels. It was edited again in February 2002, when Tom McNeal
-made substantial additions to the performance section. Thomas Emmel, Neil
-Brown, Trond Myklebust, Erez Zadok, and Ion Badulescu also provided valuable
-comments and contributions.
------------------------------------------------------------------------------
-
2. Introduction
2.1. What is NFS?
@@ -2880,2211 +2645,6 @@ for inclusion in the next version of NFS (Version 4) ([http://www.nfsv4.org]
http://www.nfsv4.org). The advantage of NFS today is that it is mature,
standard, well understood, and supported robustly across a variety of
platforms.
------------------------------------------------------------------------------
-
-2.2. What is this HOWTO and what is it not?
-
-This HOWTO is intended as a complete, step-by-step guide to setting up NFS
-correctly and effectively. Setting up NFS involves two steps, namely
-configuring the server and then configuring the client. Each of these steps
-is dealt with in order. The document then offers some tips for people with
-particular needs and hardware setups, as well as security and troubleshooting
-advice.
-
-This HOWTO is not a description of the guts and underlying structure of NFS.
-For that you may wish to read Linux NFS and Automounter Administration by
-Erez Zadok (Sybex, 2001). The classic NFS book, updated and still quite
-useful, is Managing NFS and NIS by Hal Stern, published by O'Reilly &
-Associates, Inc. A much more advanced technical description of NFS is
-available in NFS Illustrated by Brent Callaghan.
-
-This document is also not intended as a complete reference manual, and does
-not contain an exhaustive list of the features of Linux NFS. For that, you
-can look at the man pages for nfs(5), exports(5), mount(8), fstab(5), nfsd(8)
-, lockd(8), statd(8), rquotad(8), and mountd(8).
-
-It will also not cover PC-NFS, which is considered obsolete (users are
-encouraged to use Samba to share files with Windows machines) or NFS Version
-4, which is still in development.
------------------------------------------------------------------------------
-
-2.3. Knowledge Pre-Requisites
-
-You should know some basic things about TCP/IP networking before reading this
-HOWTO; if you are in doubt, read the Networking- Overview-HOWTO.
------------------------------------------------------------------------------
-
-2.4. Software Pre-Requisites: Kernel Version and nfs-utils
-
-The difference between Version 2 NFS and version 3 NFS will be explained
-later on; for now, you might simply take the suggestion that you will need
-NFS Version 3 if you are installing a dedicated or high-volume file server.
-NFS Version 2 should be fine for casual use.
-
-NFS Version 2 has been around for quite some time now (at least since the 1.2
-kernel series) however you will need a kernel version of at least 2.2.18 if
-you wish to do any of the following:
-
- * Mix Linux NFS with other operating systems' NFS
-
- * Use file locking reliably over NFS
-
- * Use NFS Version 3.
-
-
-There are also patches available for kernel versions above 2.2.14 that
-provide the above functionality. Some of them can be downloaded from the
-Linux NFS homepage. If your kernel version is 2.2.14- 2.2.17 and you have the
-source code on hand, you can tell if these patches have been added because
-NFS Version 3 server support will be a configuration option. However, unless
-you have some particular reason to use an older kernel, you should upgrade
-because many bugs have been fixed along the way. Kernel 2.2.19 contains some
-additional locking improvements over 2.2.18.
-
-Version 3 functionality will also require the nfs-utils package of at least
-version 0.1.6, and mount version 2.10m or newer. However because nfs-utils
-and mount are fully backwards compatible, and because newer versions have
-lots of security and bug fixes, there is no good reason not to install the
-newest nfs-utils and mount packages if you are beginning an NFS setup.
-
-All 2.4 and higher kernels have full NFS Version 3 functionality.
-
-In all cases, if you are building your own kernel, you will need to select
-NFS and NFS Version 3 support at compile time. Most (but not all) standard
-distributions come with kernels that support NFS version 3.
-
-Handling files larger than 2 GB will require a 2.4x kernel and a 2.2.x
-version of glibc.
-
-All kernels after 2.2.18 support NFS over TCP on the client side. As of this
-writing, server-side NFS over TCP only exists in a buggy form as an
-experimental option in the post-2.2.18 series; patches for 2.4 and 2.5
-kernels have been introduced starting with 2.4.17 and 2.5.6. The patches are
-believed to be stable, though as of this writing they are relatively new and
-have not seen widespread use or integration into the mainstream 2.4 kernel.
-
-Because so many of the above functionalities were introduced in kernel
-version 2.2.18, this document was written to be consistent with kernels above
-this version (including 2.4.x). If you have an older kernel, this document
-may not describe your NFS system correctly.
-
-As we write this document, NFS version 4 has only recently been finalized as
-a protocol, and no implementations are considered production-ready. It will
-not be dealt with here.
------------------------------------------------------------------------------
-
-2.5. Where to get help and further information
-
-As of November 2000, the Linux NFS homepage is at [http://
-nfs.sourceforge.net] http://nfs.sourceforge.net. Please check there for NFS
-related mailing lists as well as the latest version of nfs-utils, NFS kernel
-patches, and other NFS related packages.
-
-When you encounter a problem or have a question not covered in this manual,
-the faq or the man pages, you should send a message to the nfs mailing list
-(). To best help the developers and other users
-help you assess your problem you should include:
-
- * the version of nfs-utils you are using
-
- * the version of the kernel and any non-stock applied kernels.
-
- * the distribution of linux you are using
-
- * the version(s) of other operating systems involved.
-
-
-It is also useful to know the networking configuration connecting the hosts.
-
-If your problem involves the inability mount or export shares please also
-include:
-
- * a copy of your /etc/exports file
-
- * the output of rpcinfo -p localhost run on the server
-
- * the output of rpcinfo -p servername run on the client
-
-
-Sending all of this information with a specific question, after reading all
-the documentation, is the best way to ensure a helpful response from the
-list.
-
-You may also wish to look at the man pages for nfs(5), exports(5), mount(8),
-fstab(5), nfsd(8), lockd(8), statd(8), rquotad(8), and mountd(8).
------------------------------------------------------------------------------
-
-3. Setting Up an NFS Server
-
-3.1. Introduction to the server setup
-
-It is assumed that you will be setting up both a server and a client. If you
-are just setting up a client to work off of somebody else's server (say in
-your department), you can skip to Section 4. However, every client that is
-set up requires modifications on the server to authorize that client (unless
-the server setup is done in a very insecure way), so even if you are not
-setting up a server you may wish to read this section to get an idea what
-kinds of authorization problems to look out for.
-
-Setting up the server will be done in two steps: Setting up the configuration
-files for NFS, and then starting the NFS services.
------------------------------------------------------------------------------
-
-3.2. Setting up the Configuration Files
-
-There are three main configuration files you will need to edit to set up an
-NFS server: /etc/exports, /etc/hosts.allow, and /etc/hosts.deny. Strictly
-speaking, you only need to edit /etc/exports to get NFS to work, but you
-would be left with an extremely insecure setup. You may also need to edit
-your startup scripts; see Section 3.3.3 for more on that.
------------------------------------------------------------------------------
-
-3.2.1. /etc/exports
-
-This file contains a list of entries; each entry indicates a volume that is
-shared and how it is shared. Check the man pages (man exports) for a complete
-description of all the setup options for the file, although the description
-here will probably satistfy most people's needs.
-
-An entry in /etc/exports will typically look like this:
- directory machine1(option11,option12) machine2(option21,option22)
-
-where
-
-directory
- the directory that you want to share. It may be an entire volume though
- it need not be. If you share a directory, then all directories under it
- within the same file system will be shared as well.
-
-machine1 and machine2
- client machines that will have access to the directory. The machines may
- be listed by their DNS address or their IP address (e.g.,
- machine.company.com or 192.168.0.8). Using IP addresses is more reliable
- and more secure. If you need to use DNS addresses, and they do not seem
- to be resolving to the right machine, see Section 7.3.
-
-optionxx
- the option listing for each machine will describe what kind of access
- that machine will have. Important options are:
-
- + ro: The directory is shared read only; the client machine will not be
- able to write to it. This is the default.
-
- + rw: The client machine will have read and write access to the
- directory.
-
- + no_root_squash: By default, any file request made by user root on the
- client machine is treated as if it is made by user nobody on the
- server. (Excatly which UID the request is mapped to depends on the
- UID of user "nobody" on the server, not the client.) If
- no_root_squash is selected, then root on the client machine will have
- the same level of access to the files on the system as root on the
- server. This can have serious security implications, although it may
- be necessary if you want to perform any administrative work on the
- client machine that involves the exported directories. You should not
- specify this option without a good reason.
-
- + no_subtree_check: If only part of a volume is exported, a routine
- called subtree checking verifies that a file that is requested from
- the client is in the appropriate part of the volume. If the entire
- volume is exported, disabling this check will speed up transfers.
-
- + sync: By default, all but the most recent version (version 1.11) of
- the exportfs command will use async behavior, telling a client
- machine that a file write is complete - that is, has been written to
- stable storage - when NFS has finished handing the write over to the
- filesysytem. This behavior may cause data corruption if the server
- reboots, and the sync option prevents this. See Section 5.9 for a
- complete discussion of sync and async behavior.
-
-
-
-Suppose we have two client machines, slave1 and slave2, that have IP
-addresses 192.168.0.1 and 192.168.0.2, respectively. We wish to share our
-software binaries and home directories with these machines. A typical setup
-for /etc/exports might look like this:
-+---------------------------------------------------------------------------+
-| /usr/local 192.168.0.1(ro) 192.168.0.2(ro) |
-| /home 192.168.0.1(rw) 192.168.0.2(rw) |
-| |
-+---------------------------------------------------------------------------+
-
-Here we are sharing /usr/local read-only to slave1 and slave2, because it
-probably contains our software and there may not be benefits to allowing
-slave1 and slave2 to write to it that outweigh security concerns. On the
-other hand, home directories need to be exported read-write if users are to
-save work on them.
-
-If you have a large installation, you may find that you have a bunch of
-computers all on the same local network that require access to your server.
-There are a few ways of simplifying references to large numbers of machines.
-First, you can give access to a range of machines at once by specifying a
-network and a netmask. For example, if you wanted to allow access to all the
-machines with IP addresses between 192.168.0.0 and 192.168.0.255 then you
-could have the entries:
-+---------------------------------------------------------------------------+
-| /usr/local 192.168.0.0/255.255.255.0(ro) |
-| /home 192.168.0.0/255.255.255.0(rw) |
-| |
-+---------------------------------------------------------------------------+
-
-See the [http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html]
-Networking-Overview HOWTO for further information about how netmasks work,
-and you may also wish to look at the man pages for init and hosts.allow.
-
-Second, you can use NIS netgroups in your entry. To specify a netgroup in
-your exports file, simply prepend the name of the netgroup with an "@". See
-the [http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html] NIS HOWTO for details on
-how netgroups work.
-
-Third, you can use wildcards such as *.foo.com or 192.168. instead of
-hostnames. There were problems with wildcard implementation in the 2.2 kernel
-series that were fixed in kernel 2.2.19.
-
-However, you should keep in mind that any of these simplifications could
-cause a security risk if there are machines in your netgroup or local network
-that you do not trust completely.
-
-A few cautions are in order about what cannot (or should not) be exported.
-First, if a directory is exported, its parent and child directories cannot be
-exported if they are in the same filesystem. However, exporting both should
-not be necessary because listing the parent directory in the /etc/exports
-file will cause all underlying directories within that file system to be
-exported.
-
-Second, it is a poor idea to export a FAT or VFAT (i.e., MS-DOS or Windows 95
-/98) filesystem with NFS. FAT is not designed for use on a multi-user
-machine, and as a result, operations that depend on permissions will not work
-well. Moreover, some of the underlying filesystem design is reported to work
-poorly with NFS's expectations.
-
-Third, device or other special files may not export correctly to non-Linux
-clients. See Section 8 for details on particular operating systems.
------------------------------------------------------------------------------
-
-3.2.2. /etc/hosts.allow and /etc/hosts.deny
-
-These two files specify which computers on the network can use services on
-your machine. Each line of the file contains a single entry listing a service
-and a set of machines. When the server gets a request from a machine, it does
-the following:
-
- * It first checks hosts.allow to see if the machine matches a description
- listed in there. If it does, then the machine is allowed access.
-
- * If the machine does not match an entry in hosts.allow, the server then
- checks hosts.deny to see if the client matches a listing in there. If it
- does then the machine is denied access.
-
- * If the client matches no listings in either file, then it is allowed
- access.
-
-
-In addition to controlling access to services handled by inetd (such as
-telnet and FTP), this file can also control access to NFS by restricting
-connections to the daemons that provide NFS services. Restrictions are done
-on a per-service basis.
-
-The first daemon to restrict access to is the portmapper. This daemon
-essentially just tells requesting clients how to find all the NFS services on
-the system. Restricting access to the portmapper is the best defense against
-someone breaking into your system through NFS because completely unauthorized
-clients won't know where to find the NFS daemons. However, there are two
-things to watch out for. First, restricting portmapper isn't enough if the
-intruder already knows for some reason how to find those daemons. And second,
-if you are running NIS, restricting portmapper will also restrict requests to
-NIS. That should usually be harmless since you usually want to restrict NFS
-and NIS in a similar way, but just be cautioned. (Running NIS is generally a
-good idea if you are running NFS, because the client machines need a way of
-knowing who owns what files on the exported volumes. Of course there are
-other ways of doing this such as syncing password files. See the [http://
-www.linuxdoc.org/HOWTO/NIS-HOWTO.html] NIS HOWTO for information on setting
-up NIS.)
-
-In general it is a good idea with NFS (as with most internet services) to
-explicitly deny access to IP addresses that you don't need to allow access
-to.
-
-The first step in doing this is to add the followng entry to /etc/hosts.deny:
-
-+---------------------------------------------------------------------------+
-| portmap:ALL |
-| |
-+---------------------------------------------------------------------------+
-
-Starting with nfs-utils 0.2.0, you can be a bit more careful by controlling
-access to individual daemons. It's a good precaution since an intruder will
-often be able to weasel around the portmapper. If you have a newer version of
-nfs-utils, add entries for each of the NFS daemons (see the next section to
-find out what these daemons are; for now just put entries for them in
-hosts.deny):
-
-+---------------------------------------------------------------------------+
-| lockd:ALL |
-| mountd:ALL |
-| rquotad:ALL |
-| statd:ALL |
-| |
-+---------------------------------------------------------------------------+
-
-Even if you have an older version of nfs-utils, adding these entries is at
-worst harmless (since they will just be ignored) and at best will save you
-some trouble when you upgrade. Some sys admins choose to put the entry ALL:
-ALL in the file /etc/hosts.deny, which causes any service that looks at these
-files to deny access to all hosts unless it is explicitly allowed. While this
-is more secure behavior, it may also get you in trouble when you are
-installing new services, you forget you put it there, and you can't figure
-out for the life of you why they won't work.
-
-Next, we need to add an entry to hosts.allow to give any hosts access that we
-want to have access. (If we just leave the above lines in hosts.deny then
-nobody will have access to NFS.) Entries in hosts.allow follow the format
-
-
-+---------------------------------------------------------------------------+
-| service: host [or network/netmask] , host [or network/netmask] |
-| |
-+---------------------------------------------------------------------------+
-
-Here, host is IP address of a potential client; it may be possible in some
-versions to use the DNS name of the host, but it is strongly discouraged.
-
-Suppose we have the setup above and we just want to allow access to
-slave1.foo.com and slave2.foo.com, and suppose that the IP addresses of these
-machines are 192.168.0.1 and 192.168.0.2, respectively. We could add the
-following entry to /etc/hosts.allow:
-
-
-+---------------------------------------------------------------------------+
-| portmap: 192.168.0.1 , 192.168.0.2 |
-| |
-+---------------------------------------------------------------------------+
-
-For recent nfs-utils versions, we would also add the following (again, these
-entries are harmless even if they are not supported):
-
-
-+---------------------------------------------------------------------------+
-| lockd: 192.168.0.1 , 192.168.0.2 |
-| rquotad: 192.168.0.1 , 192.168.0.2 |
-| mountd: 192.168.0.1 , 192.168.0.2 |
-| statd: 192.168.0.1 , 192.168.0.2 |
-| |
-+---------------------------------------------------------------------------+
-
-If you intend to run NFS on a large number of machines in a local network, /
-etc/hosts.allow also allows for network/netmask style entries in the same
-manner as /etc/exports above.
------------------------------------------------------------------------------
-
-3.3. Getting the services started
-
-3.3.1. Pre-requisites
-
-The NFS server should now be configured and we can start it running. First,
-you will need to have the appropriate packages installed. This consists
-mainly of a new enough kernel and a new enough version of the nfs-utils
-package. See Section 2.4 if you are in doubt.
-
-Next, before you can start NFS, you will need to have TCP/IP networking
-functioning correctly on your machine. If you can use telnet, FTP, and so on,
-then chances are your TCP networking is fine.
-
-That said, with most recent Linux distributions you may be able to get NFS up
-and running simply by rebooting your machine, and the startup scripts should
-detect that you have set up your /etc/exports file and will start up NFS
-correctly. If you try this, see Section 3.4 Verifying that NFS is running. If
-this does not work, or if you are not in a position to reboot your machine,
-then the following section will tell you which daemons need to be started in
-order to run NFS services. If for some reason nfsd was already running when
-you edited your configuration files above, you will have to flush your
-configuration; see Section 3.5 for details.
------------------------------------------------------------------------------
-
-3.3.2. Starting the Portmapper
-
-NFS depends on the portmapper daemon, either called portmap or rpc.portmap.
-It will need to be started first. It should be located in /sbin but is
-sometimes in /usr/sbin. Most recent Linux distributions start this daemon in
-the boot scripts, but it is worth making sure that it is running before you
-begin working with NFS (just type ps aux | grep portmap).
------------------------------------------------------------------------------
-
-3.3.3. The Daemons
-
-NFS serving is taken care of by five daemons: rpc.nfsd, which does most of
-the work; rpc.lockd and rpc.statd, which handle file locking; rpc.mountd,
-which handles the initial mount requests, and rpc.rquotad, which handles user
-file quotas on exported volumes. Starting with 2.2.18, lockd is called by
-nfsd upon demand, so you do not need to worry about starting it yourself.
-statd will need to be started separately. Most recent Linux distributions
-will have startup scripts for these daemons.
-
-The daemons are all part of the nfs-utils package, and may be either in the /
-sbin directory or the /usr/sbin directory.
-
-If your distribution does not include them in the startup scripts, then then
-you should add them, configured to start in the following order:
-
-rpc.portmap
-rpc.mountd, rpc.nfsd
-rpc.statd, rpc.lockd (if necessary), and rpc.rquotad
-
-The nfs-utils package has sample startup scripts for RedHat and Debian. If
-you are using a different distribution, in general you can just copy the
-RedHat script, but you will probably have to take out the line that says:
-+---------------------------------------------------------------------------+
-| . ../init.d/functions |
-| |
-+---------------------------------------------------------------------------+
-to avoid getting error messages.
------------------------------------------------------------------------------
-
-3.4. Verifying that NFS is running
-
-To do this, query the portmapper with the command rpcinfo -p to find out what
-services it is providing. You should get something like this:
-+---------------------------------------------------------------------------+
-| program vers proto port |
-| 100000 2 tcp 111 portmapper |
-| 100000 2 udp 111 portmapper |
-| 100011 1 udp 749 rquotad |
-| 100011 2 udp 749 rquotad |
-| 100005 1 udp 759 mountd |
-| 100005 1 tcp 761 mountd |
-| 100005 2 udp 764 mountd |
-| 100005 2 tcp 766 mountd |
-| 100005 3 udp 769 mountd |
-| 100005 3 tcp 771 mountd |
-| 100003 2 udp 2049 nfs |
-| 100003 3 udp 2049 nfs |
-| 300019 1 tcp 830 amd |
-| 300019 1 udp 831 amd |
-| 100024 1 udp 944 status |
-| 100024 1 tcp 946 status |
-| 100021 1 udp 1042 nlockmgr |
-| 100021 3 udp 1042 nlockmgr |
-| 100021 4 udp 1042 nlockmgr |
-| 100021 1 tcp 1629 nlockmgr |
-| 100021 3 tcp 1629 nlockmgr |
-| 100021 4 tcp 1629 nlockmgr |
-| |
-+---------------------------------------------------------------------------+
-
-This says that we have NFS versions 2 and 3, rpc.statd version 1, network
-lock manager (the service name for rpc.lockd) versions 1, 3, and 4. There are
-also different service listings depending on whether NFS is travelling over
-TCP or UDP. Linux systems use UDP by default unless TCP is explicitly
-requested; however other OSes such as Solaris default to TCP.
-
-If you do not at least see a line that says portmapper, a line that says nfs,
-and a line that says mountd then you will need to backtrack and try again to
-start up the daemons (see Section 7, Troubleshooting, if this still doesn't
-work).
-
-If you do see these services listed, then you should be ready to set up NFS
-clients to access files from your server.
------------------------------------------------------------------------------
-
-3.5. Making changes to /etc/exports later on
-
-If you come back and change your /etc/exports file, the changes you make may
-not take effect immediately. You should run the command exportfs -ra to force
-nfsd to re-read the /etc/exports file. If you can't find the exportfs
-command, then you can kill nfsd with the -HUP flag (see the man pages for
-kill for details).
-
-If that still doesn't work, don't forget to check hosts.allow to make sure
-you haven't forgotten to list any new client machines there. Also check the
-host listings on any firewalls you may have set up (see Section 7 and Section
-6 for more details on firewalls and NFS).
------------------------------------------------------------------------------
-
-4. Setting up an NFS Client
-
-4.1. Mounting remote directories
-
-Before beginning, you should double-check to make sure your mount program is
-new enough (version 2.10m if you want to use Version 3 NFS), and that the
-client machine supports NFS mounting, though most standard distributions do.
-If you are using a 2.2 or later kernel with the /proc filesystem you can
-check the latter by reading the file /proc/filesystems and making sure there
-is a line containing nfs. If not, typing insmod nfs may make it magically
-appear if NFS has been compiled as a module; otherwise, you will need to
-build (or download) a kernel that has NFS support built in. In general,
-kernels that do not have NFS compiled in will give a very specific error when
-the mount command below is run.
-
-To begin using machine as an NFS client, you will need the portmapper running
-on that machine, and to use NFS file locking, you will also need rpc.statd
-and rpc.lockd running on both the client and the server. Most recent
-distributions start those services by default at boot time; if yours doesn't,
-see Section 3.2 for information on how to start them up.
-
-With portmap, lockd, and statd running, you should now be able to mount the
-remote directory from your server just the way you mount a local hard drive,
-with the mount command. Continuing our example from the previous section,
-suppose our server above is called master.foo.com,and we want to mount the /
-home directory on slave1.foo.com. Then, all we have to do, from the root
-prompt on slave1.foo.com, is type:
-+---------------------------------------------------------------------------+
-| # mount master.foo.com:/home /mnt/home |
-| |
-+---------------------------------------------------------------------------+
-and the directory /home on master will appear as the directory /mnt/home on
-slave1. (Note that this assumes we have created the directory /mnt/home as an
-empty mount point beforehand.)
-
-If this does not work, see the Troubleshooting section (Section 7).
-
-You can get rid of the file system by typing
-+---------------------------------------------------------------------------+
-| # umount /mnt/home |
-| |
-+---------------------------------------------------------------------------+
-just like you would for a local file system.
------------------------------------------------------------------------------
-
-4.2. Getting NFS File Systems to Be Mounted at Boot Time
-
-NFS file systems can be added to your /etc/fstab file the same way local file
-systems can, so that they mount when your system starts up. The only
-difference is that the file system type will be set to nfs and the dump and
-fsck order (the last two entries) will have to be set to zero. So for our
-example above, the entry in /etc/fstab would look like:
- # device mountpoint fs-type options dump fsckorder
- ...
- master.foo.com:/home /mnt nfs rw 0 0
- ...
-
-
-See the man pages for fstab if you are unfamiliar with the syntax of this
-file. If you are using an automounter such as amd or autofs, the options in
-the corresponding fields of your mount listings should look very similar if
-not identical.
-
-At this point you should have NFS working, though a few tweaks may still be
-necessary to get it to work well. You should also read Section 6 to be sure
-your setup is reasonably secure.
------------------------------------------------------------------------------
-
-4.3. Mount options
-
-4.3.1. Soft vs. Hard Mounting
-
-There are some options you should consider adding at once. They govern the
-way the NFS client handles a server crash or network outage. One of the cool
-things about NFS is that it can handle this gracefully. If you set up the
-clients right. There are two distinct failure modes:
-
-soft
- If a file request fails, the NFS client will report an error to the
- process on the client machine requesting the file access. Some programs
- can handle this with composure, most won't. We do not recommend using
- this setting; it is a recipe for corrupted files and lost data. You
- should especially not use this for mail disks --- if you value your mail,
- that is.
-
-hard
- The program accessing a file on a NFS mounted file system will hang when
- the server crashes. The process cannot be interrupted or killed (except
- by a "sure kill") unless you also specify intr. When the NFS server is
- back online the program will continue undisturbed from where it was. We
- recommend using hard,intr on all NFS mounted file systems.
-
-
-Picking up the from previous example, the fstab entry would now look like:
- # device mountpoint fs-type options dump fsckord
- ...
- master.foo.com:/home /mnt/home nfs rw,hard,intr 0 0
- ...
-
------------------------------------------------------------------------------
-
-4.3.2. Setting Block Size to Optimize Transfer Speeds
-
-The rsize and wsize mount options specify the size of the chunks of data that
-the client and server pass back and forth to each other.
-
-The defaults may be too big or to small; there is no size that works well on
-all or most setups. On the one hand, some combinations of Linux kernels and
-network cards (largely on older machines) cannot handle blocks that large. On
-the other hand, if they can handle larger blocks, a bigger size might be
-faster.
-
-Getting the block size right is an important factor in performance and is a
-must if you are planning to use the NFS server in a production environment.
-See Section 5 for details.
------------------------------------------------------------------------------
-
-5. Optimizing NFS Performance
-
-Careful analysis of your environment, both from the client and from the
-server point of view, is the first step necessary for optimal NFS
-performance. The first sections will address issues that are generally
-important to the client. Later (Section 5.3 and beyond), server side issues
-will be discussed. In both cases, these issues will not be limited
-exclusively to one side or the other, but it is useful to separate the two in
-order to get a clearer picture of cause and effect.
-
-Aside from the general network configuration - appropriate network capacity,
-faster NICs, full duplex settings in order to reduce collisions, agreement in
-network speed among the switches and hubs, etc. - one of the most important
-client optimization settings are the NFS data transfer buffer sizes,
-specified by the mount command options rsize and wsize.
------------------------------------------------------------------------------
-
-5.1. Setting Block Size to Optimize Transfer Speeds
-
-The mount command options rsize and wsize specify the size of the chunks of
-data that the client and server pass back and forth to each other. If no
-rsize and wsize options are specified, the default varies by which version of
-NFS we are using. The most common default is 4K (4096 bytes), although for
-TCP-based mounts in 2.2 kernels, and for all mounts beginning with 2.4
-kernels, the server specifies the default block size.
-
-The theoretical limit for the NFS V2 protocol is 8K. For the V3 protocol, the
-limit is specific to the server. On the Linux server, the maximum block size
-is defined by the value of the kernel constant NFSSVC_MAXBLKSIZE, found in
-the Linux kernel source file ./include/linux/nfsd/const.h. The current
-maximum block size for the kernel, as of 2.4.17, is 8K (8192 bytes), but the
-patch set implementing NFS over TCP/IP transport in the 2.4 series, as of
-this writing, uses a value of 32K (defined in the patch as 32*1024) for the
-maximum block size.
-
-All 2.4 clients currently support up to 32K block transfer sizes, allowing
-the standard 32K block transfers across NFS mounts from other servers, such
-as Solaris, without client modification.
-
-The defaults may be too big or too small, depending on the specific
-combination of hardware and kernels. On the one hand, some combinations of
-Linux kernels and network cards (largely on older machines) cannot handle
-blocks that large. On the other hand, if they can handle larger blocks, a
-bigger size might be faster.
-
-You will want to experiment and find an rsize and wsize that works and is as
-fast as possible. You can test the speed of your options with some simple
-commands, if your network environment is not heavily used. Note that your
-results may vary widely unless you resort to using more complex benchmarks,
-such as Bonnie, Bonnie++, or IOzone.
-
-The first of these commands transfers 16384 blocks of 16k each from the
-special file /dev/zero (which if you read it just spits out zeros really
-fast) to the mounted partition. We will time it to see how long it takes. So,
-from the client machine, type:
- # time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
-
-This creates a 256Mb file of zeroed bytes. In general, you should create a
-file that's at least twice as large as the system RAM on the server, but make
-sure you have enough disk space! Then read back the file into the great black
-hole on the client machine (/dev/null) by typing the following:
- # time dd if=/mnt/home/testfile of=/dev/null bs=16k
-
-Repeat this a few times and average how long it takes. Be sure to unmount and
-remount the filesystem each time (both on the client and, if you are zealous,
-locally on the server as well), which should clear out any caches.
-
-Then unmount, and mount again with a larger and smaller block size. They
-should be multiples of 1024, and not larger than the maximum block size
-allowed by your system. Note that NFS Version 2 is limited to a maximum of
-8K, regardless of the maximum block size defined by NFSSVC_MAXBLKSIZE;
-Version 3 will support up to 64K, if permitted. The block size should be a
-power of two since most of the parameters that would constrain it (such as
-file system block sizes and network packet size) are also powers of two.
-However, some users have reported better successes with block sizes that are
-not powers of two but are still multiples of the file system block size and
-the network packet size.
-
-Directly after mounting with a larger size, cd into the mounted file system
-and do things like ls, explore the filesystem a bit to make sure everything
-is as it should. If the rsize/wsize is too large the symptoms are very odd
-and not 100% obvious. A typical symptom is incomplete file lists when doing
-ls, and no error messages, or reading files failing mysteriously with no
-error messages. After establishing that the given rsize/ wsize works you can
-do the speed tests again. Different server platforms are likely to have
-different optimal sizes.
-
-Remember to edit /etc/fstab to reflect the rsize/wsize you found to be the
-most desirable.
-
-If your results seem inconsistent, or doubtful, you may need to analyze your
-network more extensively while varying the rsize and wsize values. In that
-case, here are several pointers to benchmarks that may prove useful:
-
- * Bonnie [http://www.textuality.com/bonnie/] http://www.textuality.com/
- bonnie/
-
- * Bonnie++ [http://www.coker.com.au/bonnie++/] http://www.coker.com.au/
- bonnie++/
-
- * IOzone file system benchmark [http://www.iozone.org/] http://
- www.iozone.org/
-
- * The official NFS benchmark, SPECsfs97 [http://www.spec.org/osg/sfs97/]
- http://www.spec.org/osg/sfs97/
-
-
-The easiest benchmark with the widest coverage, including an extensive spread
-of file sizes, and of IO types - reads, & writes, rereads & rewrites, random
-access, etc. - seems to be IOzone. A recommended invocation of IOzone (for
-which you must have root privileges) includes unmounting and remounting the
-directory under test, in order to clear out the caches between tests, and
-including the file close time in the measurements. Assuming you've already
-exported /tmp to everyone from the server foo, and that you've installed
-IOzone in the local directory, this should work:
- # echo "foo:/tmp /mnt/foo nfs rw,hard,intr,rsize=8192,wsize=8192 0 0"
- >> /etc/fstab
- # mkdir /mnt/foo
- # mount /mnt/foo
- # ./iozone -a -R -c -U /mnt/foo -f /mnt/foo/testfile > logfile
-
-The benchmark should take 2-3 hours at most, but of course you will need to
-run it for each value of rsize and wsize that is of interest. The web site
-gives full documentation of the parameters, but the specific options used
-above are:
-
- * -a Full automatic mode, which tests file sizes of 64K to 512M, using
- record sizes of 4K to 16M
-
- * -R Generate report in excel spreadsheet form (The "surface plot" option
- for graphs is best)
-
- * -c Include the file close time in the tests, which will pick up the NFS
- version 3 commit time
-
- * -U Use the given mount point to unmount and remount between tests; it
- clears out caches
-
- * -f When using unmount, you have to locate the test file in the mounted
- file system
-
-
------------------------------------------------------------------------------
-5.2. Packet Size and Network Drivers
-
-While many Linux network card drivers are excellent, some are quite shoddy,
-including a few drivers for some fairly standard cards. It is worth
-experimenting with your network card directly to find out how it can best
-handle traffic.
-
-Try pinging back and forth between the two machines with large packets using
-the -f and -s options with ping (see ping(8) for more details) and see if a
-lot of packets get dropped, or if they take a long time for a reply. If so,
-you may have a problem with the performance of your network card.
-
-For a more extensive analysis of NFS behavior in particular, use the nfsstat
-command to look at nfs transactions, client and server statistics, network
-statistics, and so forth. The "-o net" option will show you the number of
-dropped packets in relation to the total number of transactions. In UDP
-transactions, the most important statistic is the number of retransmissions,
-due to dropped packets, socket buffer overflows, general server congestion,
-timeouts, etc. This will have a tremendously important effect on NFS
-performance, and should be carefully monitored. Note that nfsstat does not
-yet implement the -z option, which would zero out all counters, so you must
-look at the current nfsstat counter values prior to running the benchmarks.
-
-To correct network problems, you may wish to reconfigure the packet size that
-your network card uses. Very often there is a constraint somewhere else in
-the network (such as a router) that causes a smaller maximum packet size
-between two machines than what the network cards on the machines are actually
-capable of. TCP should autodiscover the appropriate packet size for a
-network, but UDP will simply stay at a default value. So determining the
-appropriate packet size is especially important if you are using NFS over
-UDP.
-
-You can test for the network packet size using the tracepath command: From
-the client machine, just type tracepath server 2049 and the path MTU should
-be reported at the bottom. You can then set the MTU on your network card
-equal to the path MTU, by using the MTU option to ifconfig, and see if fewer
-packets get dropped. See the ifconfig man pages for details on how to reset
-the MTU.
-
-In addition, netstat -s will give the statistics collected for traffic across
-all supported protocols. You may also look at /proc/net/snmp for information
-about current network behavior; see the next section for more details.
------------------------------------------------------------------------------
-
-5.3. Overflow of Fragmented Packets
-
-Using an rsize or wsize larger than your network's MTU (often set to 1500, in
-many networks) will cause IP packet fragmentation when using NFS over UDP. IP
-packet fragmentation and reassembly require a significant amount of CPU
-resource at both ends of a network connection. In addition, packet
-fragmentation also exposes your network traffic to greater unreliability,
-since a complete RPC request must be retransmitted if a UDP packet fragment
-is dropped for any reason. Any increase of RPC retransmissions, along with
-the possibility of increased timeouts, are the single worst impediment to
-performance for NFS over UDP.
-
-Packets may be dropped for many reasons. If your network topography is
-complex, fragment routes may differ, and may not all arrive at the Server for
-reassembly. NFS Server capacity may also be an issue, since the kernel has a
-limit of how many fragments it can buffer before it starts throwing away
-packets. With kernels that support the /proc filesystem, you can monitor the
-files /proc/sys/net/ipv4/ipfrag_high_thresh and /proc/sys/net/ipv4/
-ipfrag_low_thresh. Once the number of unprocessed, fragmented packets reaches
-the number specified by ipfrag_high_thresh (in bytes), the kernel will simply
-start throwing away fragmented packets until the number of incomplete packets
-reaches the number specified by ipfrag_low_thresh.
-
-Another counter to monitor is IP: ReasmFails in the file /proc/net/snmp; this
-is the number of fragment reassembly failures. if it goes up too quickly
-during heavy file activity, you may have problem.
------------------------------------------------------------------------------
-
-5.4. NFS over TCP
-
-A new feature, available for both 2.4 and 2.5 kernels but not yet integrated
-into the mainstream kernel at the time of this writing, is NFS over TCP.
-Using TCP has a distinct advantage and a distinct disadvantage over UDP. The
-advantage is that it works far better than UDP on lossy networks. When using
-TCP, a single dropped packet can be retransmitted, without the retransmission
-of the entire RPC request, resulting in better performance on lossy networks.
-In addition, TCP will handle network speed differences better than UDP, due
-to the underlying flow control at the network level.
-
-The disadvantage of using TCP is that it is not a stateless protocol like
-UDP. If your server crashes in the middle of a packet transmission, the
-client will hang and any shares will need to be unmounted and remounted.
-
-The overhead incurred by the TCP protocol will result in somewhat slower
-performance than UDP under ideal network conditions, but the cost is not
-severe, and is often not noticable without careful measurement. If you are
-using gigabit ethernet from end to end, you might also investigate the usage
-of jumbo frames, since the high speed network may allow the larger frame
-sizes without encountering increased collision rates, particularly if you
-have set the network to full duplex.
------------------------------------------------------------------------------
-
-5.5. Timeout and Retransmission Values
-
-Two mount command options, timeo and retrans, control the behavior of UDP
-requests when encountering client timeouts due to dropped packets, network
-congestion, and so forth. The -o timeo option allows designation of the
-length of time, in tenths of seconds, that the client will wait until it
-decides it will not get a reply from the server, and must try to send the
-request again. The default value is 7 tenths of a second. The -o retrans
-option allows designation of the number of timeouts allowed before the client
-gives up, and displays the Server not responding message. The default value
-is 3 attempts. Once the client displays this message, it will continue to try
-to send the request, but only once before displaying the error message if
-another timeout occurs. When the client reestablishes contact, it will fall
-back to using the correct retrans value, and will display the Server OK
-message.
-
-If you are already encountering excessive retransmissions (see the output of
-the nfsstat command), or want to increase the block transfer size without
-encountering timeouts and retransmissions, you may want to adjust these
-values. The specific adjustment will depend upon your environment, and in
-most cases, the current defaults are appropriate.
------------------------------------------------------------------------------
-
-5.6. Number of Instances of the NFSD Server Daemon
-
-Most startup scripts, Linux and otherwise, start 8 instances of nfsd. In the
-early days of NFS, Sun decided on this number as a rule of thumb, and
-everyone else copied. There are no good measures of how many instances are
-optimal, but a more heavily-trafficked server may require more. You should
-use at the very least one daemon per processor, but four to eight per
-processor may be a better rule of thumb. If you are using a 2.4 or higher
-kernel and you want to see how heavily each nfsd thread is being used, you
-can look at the file /proc/net/rpc/nfsd. The last ten numbers on the th line
-in that file indicate the number of seconds that the thread usage was at that
-percentage of the maximum allowable. If you have a large number in the top
-three deciles, you may wish to increase the number of nfsd instances. This is
-done upon starting nfsd using the number of instances as the command line
-option, and is specified in the NFS startup script (/etc/rc.d/init.d/nfs on
-Red Hat) as RPCNFSDCOUNT. See the nfsd(8) man page for more information.
------------------------------------------------------------------------------
-
-5.7. Memory Limits on the Input Queue
-
-On 2.2 and 2.4 kernels, the socket input queue, where requests sit while they
-are currently being processed, has a small default size limit (rmem_default)
-of 64k. This queue is important for clients with heavy read loads, and
-servers with heavy write loads. As an example, if you are running 8 instances
-of nfsd on the server, each will only have 8k to store write requests while
-it processes them. In addition, the socket output queue - important for
-clients with heavy write loads and servers with heavy read loads - also has a
-small default size (wmem_default).
-
-Several published runs of the NFS benchmark [http://www.spec.org/osg/sfs97/]
-SPECsfs specify usage of a much higher value for both the read and write
-value sets, [rw]mem_default and [rw]mem_max. You might consider increasing
-these values to at least 256k. The read and write limits are set in the proc
-file system using (for example) the files /proc/sys/net/core/rmem_default and
-/proc/sys/net/core/rmem_max. The rmem_default value can be increased in three
-steps; the following method is a bit of a hack but should work and should not
-cause any problems:
-
- * Increase the size listed in the file:
- # echo 262144 > /proc/sys/net/core/rmem_default
- # echo 262144 > /proc/sys/net/core/rmem_max
-
- * Restart NFS. For example, on Red Hat systems,
- # /etc/rc.d/init.d/nfs restart
-
- * You might return the size limits to their normal size in case other
- kernel systems depend on it:
- # echo 65536 > /proc/sys/net/core/rmem_default
- # echo 65536 > /proc/sys/net/core/rmem_max
-
-
-This last step may be necessary because machines have been reported to crash
-if these values are left changed for long periods of time.
------------------------------------------------------------------------------
-
-5.8. Turning Off Autonegotiation of NICs and Hubs
-
-If network cards auto-negotiate badly with hubs and switches, and ports run
-at different speeds, or with different duplex configurations, performance
-will be severely impacted due to excessive collisions, dropped packets, etc.
-If you see excessive numbers of dropped packets in the nfsstat output, or
-poor network performance in general, try playing around with the network
-speed and duplex settings. If possible, concentrate on establishing a
-100BaseT full duplex subnet; the virtual elimination of collisions in full
-duplex will remove the most severe performance inhibitor for NFS over UDP. Be
-careful when turning off autonegotiation on a card: The hub or switch that
-the card is attached to will then resort to other mechanisms (such as
-parallel detection) to determine the duplex settings, and some cards default
-to half duplex because it is more likely to be supported by an old hub. The
-best solution, if the driver supports it, is to force the card to negotiate
-100BaseT full duplex.
------------------------------------------------------------------------------
-
-5.9. Synchronous vs. Asynchronous Behavior in NFS
-
-The default export behavior for both NFS Version 2 and Version 3 protocols,
-used by exportfs in nfs-utils versions prior to Version 1.11 (the latter is
-in the CVS tree, but not yet released in a package, as of January, 2002) is
-"asynchronous". This default permits the server to reply to client requests
-as soon as it has processed the request and handed it off to the local file
-system, without waiting for the data to be written to stable storage. This is
-indicated by the async option denoted in the server's export list. It yields
-better performance at the cost of possible data corruption if the server
-reboots while still holding unwritten data and/or metadata in its caches.
-This possible data corruption is not detectable at the time of occurrence,
-since the async option instructs the server to lie to the client, telling the
-client that all data has indeed been written to the stable storage,
-regardless of the protocol used.
-
-In order to conform with "synchronous" behavior, used as the default for most
-proprietary systems supporting NFS (Solaris, HP-UX, RS/6000, etc.), and now
-used as the default in the latest version of exportfs, the Linux Server's
-file system must be exported with the sync option. Note that specifying
-synchronous exports will result in no option being seen in the server's
-export list:
-
- * Export a couple file systems to everyone, using slightly different
- options:
-
- # /usr/sbin/exportfs -o rw,sync *:/usr/local
- # /usr/sbin/exportfs -o rw *:/tmp
-
- * Now we can see what the exported file system parameters look like:
-
- # /usr/sbin/exportfs -v
- /usr/local *(rw)
- /tmp *(rw,async)
-
-
-If your kernel is compiled with the /proc filesystem, then the file /proc/fs/
-nfs/exports will also show the full list of export options.
-
-When synchronous behavior is specified, the server will not complete (that
-is, reply to the client) an NFS version 2 protocol request until the local
-file system has written all data/metadata to the disk. The server will
-complete a synchronous NFS version 3 request without this delay, and will
-return the status of the data in order to inform the client as to what data
-should be maintained in its caches, and what data is safe to discard. There
-are 3 possible status values, defined an enumerated type, nfs3_stable_how, in
-include/linux/nfs.h. The values, along with the subsequent actions taken due
-to these results, are as follows:
-
- * NFS_UNSTABLE - Data/Metadata was not committed to stable storage on the
- server, and must be cached on the client until a subsequent client commit
- request assures that the server does send data to stable storage.
-
- * NFS_DATA_SYNC - Metadata was not sent to stable storage, and must be
- cached on the client. A subsequent commit is necessary, as is required
- above.
-
- * NFS_FILE_SYNC - No data/metadata need be cached, and a subsequent commit
- need not be sent for the range covered by this request.
-
-
-In addition to the above definition of synchronous behavior, the client may
-explicitly insist on total synchronous behavior, regardless of the protocol,
-by opening all files with the O_SYNC option. In this case, all replies to
-client requests will wait until the data has hit the server's disk,
-regardless of the protocol used (meaning that, in NFS version 3, all requests
-will be NFS_FILE_SYNC requests, and will require that the Server returns this
-status). In that case, the performance of NFS Version 2 and NFS Version 3
-will be virtually identical.
-
-If, however, the old default async behavior is used, the O_SYNC option has no
-effect at all in either version of NFS, since the server will reply to the
-client without waiting for the write to complete. In that case the
-performance differences between versions will also disappear.
-
-Finally, note that, for NFS version 3 protocol requests, a subsequent commit
-request from the NFS client at file close time, or at fsync() time, will
-force the server to write any previously unwritten data/metadata to the disk,
-and the server will not reply to the client until this has been completed, as
-long as sync behavior is followed. If async is used, the commit is
-essentially a no-op, since the server once again lies to the client, telling
-the client that the data has been sent to stable storage. This again exposes
-the client and server to data corruption, since cached data may be discarded
-on the client due to its belief that the server now has the data maintained
-in stable storage.
------------------------------------------------------------------------------
-
-5.10. Non-NFS-Related Means of Enhancing Server Performance
-
-In general, server performance and server disk access speed will have an
-important effect on NFS performance. Offering general guidelines for setting
-up a well-functioning file server is outside the scope of this document, but
-a few hints may be worth mentioning:
-
- * If you have access to RAID arrays, use RAID 1/0 for both write speed and
- redundancy; RAID 5 gives you good read speeds but lousy write speeds.
-
- * A journalling filesystem will drastically reduce your reboot time in the
- event of a system crash. Currently, [ftp://ftp.uk.linux.org/pub/linux/sct
- /fs/jfs/] ext3 will work correctly with NFS version 3. In addition,
- Reiserfs version 3.6 will work with NFS version 3 on 2.4.7 or later
- kernels (patches are available for previous kernels). Earlier versions of
- Reiserfs did not include room for generation numbers in the inode,
- exposing the possibility of undetected data corruption during a server
- reboot.
-
- * Additionally, journalled file systems can be configured to maximize
- performance by taking advantage of the fact that journal updates are all
- that is necessary for data protection. One example is using ext3 with
- data=journal so that all updates go first to the journal, and later to
- the main file system. Once the journal has been updated, the NFS server
- can safely issue the reply to the clients, and the main file system
- update can occur at the server's leisure.
-
- The journal in a journalling file system may also reside on a separate
- device such as a flash memory card so that journal updates normally
- require no seeking. With only rotational delay imposing a cost, this
- gives reasonably good synchronous IO performance. Note that ext3
- currently supports journal relocation, and ReiserFS will (officially)
- support it soon. The Reiserfs tool package found at [ftp://
- ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz] ftp://
- ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz contains
- the reiserfstune tool, which will allow journal relocation. It does,
- however, require a kernel patch which has not yet been officially
- released as of January, 2002.
-
- * Using an automounter (such as autofs or amd) may prevent hangs if you
- cross-mount files on your machines (whether on purpose or by oversight)
- and one of those machines goes down. See the [http://www.linuxdoc.org/
- HOWTO/mini/Automount.html] Automount Mini-HOWTO for details.
-
- * Some manufacturers (Network Appliance, Hewlett Packard, and others)
- provide NFS accelerators in the form of Non-Volatile RAM. NVRAM will
- boost access speed to stable storage up to the equivalent of async
- access.
-
-
------------------------------------------------------------------------------
-6. Security and NFS
-
-This list of security tips and explanations will not make your site
-completely secure. NOTHING will make your site completely secure. Reading
-this section may help you get an idea of the security problems with NFS. This
-is not a comprehensive guide and it will always be undergoing changes. If you
-have any tips or hints to give us please send them to the HOWTO maintainer.
-
-If you are on a network with no access to the outside world (not even a
-modem) and you trust all the internal machines and all your users then this
-section will be of no use to you. However, its our belief that there are
-relatively few networks in this situation so we would suggest reading this
-section thoroughly for anyone setting up NFS.
-
-With NFS, there are two steps required for a client to gain access to a file
-contained in a remote directory on the server. The first step is mount
-access. Mount access is achieved by the client machine attempting to attach
-to the server. The security for this is provided by the /etc/exports file.
-This file lists the names or IP addresses for machines that are allowed to
-access a share point. If the client's ip address matches one of the entries
-in the access list then it will be allowed to mount. This is not terribly
-secure. If someone is capable of spoofing or taking over a trusted address
-then they can access your mount points. To give a real-world example of this
-type of "authentication": This is equivalent to someone introducing
-themselves to you and you believing they are who they claim to be because
-they are wearing a sticker that says "Hello, My Name is ...." Once the
-machine has mounted a volume, its operating system will have access to all
-files on the volume (with the possible exception of those owned by root; see
-below) and write access to those files as well, if the volume was exported
-with the rw option.
-
-The second step is file access. This is a function of normal file system
-access controls on the client and not a specialized function of NFS. Once the
-drive is mounted the user and group permissions on the files determine access
-control.
-
-An example: bob on the server maps to the UserID 9999. Bob makes a file on
-the server that is only accessible the user (the equivalent to typing chmod
-600 filename). A client is allowed to mount the drive where the file is
-stored. On the client mary maps to UserID 9999. This means that the client
-user mary can access bob's file that is marked as only accessible by him. It
-gets worse: If someone has become superuser on the client machine they can su
-- username and become any user. NFS will be none the wiser.
-
-Its not all terrible. There are a few measures you can take on the server to
-offset the danger of the clients. We will cover those shortly.
-
-If you don't think the security measures apply to you, you're probably wrong.
-In Section 6.1 we'll cover securing the portmapper, server and client
-security in Section 6.2 and Section 6.3 respectively. Finally, in Section 6.4
-we'll briefly talk about proper firewalling for your nfs server.
-
-Finally, it is critical that all of your nfs daemons and client programs are
-current. If you think that a flaw is too recently announced for it to be a
-problem for you, then you've probably already been compromised.
-
-A good way to keep up to date on security alerts is to subscribe to the
-bugtraq mailinglists. You can read up on how to subscribe and various other
-information about bugtraq here: [http://www.securityfocus.com/forums/bugtraq/
-faq.html] http://www.securityfocus.com/forums/bugtraq/faq.html
-
-Additionally searching for NFS at [http://www.securityfocus.com]
-securityfocus.com's search engine will show you all security reports
-pertaining to NFS.
-
-You should also regularly check CERT advisories. See the CERT web page at
-[http://www.cert.org] www.cert.org.
------------------------------------------------------------------------------
-
-6.1. The portmapper
-
-The portmapper keeps a list of what services are running on what ports. This
-list is used by a connecting machine to see what ports it wants to talk to
-access certain services.
-
-The portmapper is not in as bad a shape as a few years ago but it is still a
-point of worry for many sys admins. The portmapper, like NFS and NIS, should
-not really have connections made to it outside of a trusted local area
-network. If you have to expose them to the outside world - be careful and
-keep up diligent monitoring of those systems.
-
-Not all Linux distributions were created equal. Some seemingly up-to-date
-distributions do not include a securable portmapper. The easy way to check if
-your portmapper is good or not is to run strings(1) and see if it reads the
-relevant files, /etc/hosts.deny and /etc/hosts.allow. Assuming your
-portmapper is /sbin/portmap you can check it with this command:
- strings /sbin/portmap | grep hosts.
-
-
-On a securable machine it comes up something like this:
-+---------------------------------------------------------------------------+
-| /etc/hosts.allow |
-| /etc/hosts.deny |
-| @(#) hosts_ctl.c 1.4 94/12/28 17:42:27 |
-| @(#) hosts_access.c 1.21 97/02/12 02:13:22 |
-| |
-+---------------------------------------------------------------------------+
-
-First we edit /etc/hosts.deny. It should contain the line
-
-+---------------------------------------------------------------------------+
-| portmap: ALL |
-| |
-+---------------------------------------------------------------------------+
-
-which will deny access to everyone. While it is closed run:
-+---------------------------------------------------------------------------+
-| rpcinfo -p |
-| |
-+---------------------------------------------------------------------------+
-just to check that your portmapper really reads and obeys this file. Rpcinfo
-should give no output, or possibly an error message. The files /etc/
-hosts.allow and /etc/hosts.deny take effect immediately after you save them.
-No daemon needs to be restarted.
-
-Closing the portmapper for everyone is a bit drastic, so we open it again by
-editing /etc/hosts.allow. But first we need to figure out what to put in it.
-It should basically list all machines that should have access to your
-portmapper. On a run of the mill Linux system there are very few machines
-that need any access for any reason. The portmapper administers nfsd, mountd,
-ypbind/ypserv, rquotad, lockd (which shows up as nlockmgr), statd (which
-shows up as status) and 'r' services like ruptime and rusers. Of these only
-nfsd, mountd, ypbind/ypserv and perhaps rquotad,lockd and statd are of any
-consequence. All machines that need to access services on your machine should
-be allowed to do that. Let's say that your machine's address is 192.168.0.254
-and that it lives on the subnet 192.168.0.0, and that all machines on the
-subnet should have access to it (for an overview of those terms see the the
-[http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html]
-Networking-Overview-HOWTO). Then we write:
-+---------------------------------------------------------------------------+
-| portmap: 192.168.0.0/255.255.255.0 |
-| |
-+---------------------------------------------------------------------------+
-in /etc/hosts.allow. If you are not sure what your network or netmask are,
-you can use the ifconfig command to determine the netmask and the netstat
-command to determine the network. For, example, for the device eth0 on the
-above machine ifconfig should show:
-
-+---------------------------------------------------------------------------+
-| ... |
-| eth0 Link encap:Ethernet HWaddr 00:60:8C:96:D5:56 |
-| inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0 |
-| UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 |
-| RX packets:360315 errors:0 dropped:0 overruns:0 |
-| TX packets:179274 errors:0 dropped:0 overruns:0 |
-| Interrupt:10 Base address:0x320 |
-| ... |
-| |
-+---------------------------------------------------------------------------+
-and netstat -rn should show:
-+---------------------------------------------------------------------------------+
-| Kernel routing table |
-| Destination Gateway Genmask Flags Metric Ref Use Iface |
-| ... |
-| 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0 |
-| ... |
-| |
-+---------------------------------------------------------------------------------+
-(The network address is in the first column).
-
-The /etc/hosts.deny and /etc/hosts.allow files are described in the manual
-pages of the same names.
-
-IMPORTANT: Do not put anything but IP NUMBERS in the portmap lines of these
-files. Host name lookups can indirectly cause portmap activity which will
-trigger host name lookups which can indirectly cause portmap activity which
-will trigger...
-
-Versions 0.2.0 and higher of the nfs-utils package also use the hosts.allow
-and hosts.deny files, so you should put in entries for lockd, statd, mountd,
-and rquotad in these files too. For a complete example, see Section 3.2.2.
-
-The above things should make your server tighter. The only remaining problem
-is if someone gains administrative access to one of your trusted client
-machines and is able to send bogus NFS requests. The next section deals with
-safeguards against this problem.
------------------------------------------------------------------------------
-
-6.2. Server security: nfsd and mountd
-
-On the server we can decide that we don't want to trust any requests made as
-root on the client. We can do that by using the root_squash option in /etc/
-exports:
- /home slave1(rw,root_squash)
-
-
-This is, in fact, the default. It should always be turned on unless you have
-a very good reason to turn it off. To turn it off use the no_root_squash
-option.
-
-Now, if a user with UID 0 (i.e., root's user ID number) on the client
-attempts to access (read, write, delete) the file system, the server
-substitutes the UID of the server's 'nobody' account. Which means that the
-root user on the client can't access or change files that only root on the
-server can access or change. That's good, and you should probably use
-root_squash on all the file systems you export. "But the root user on the
-client can still use su to become any other user and access and change that
-users files!" say you. To which the answer is: Yes, and that's the way it is,
-and has to be with Unix and NFS. This has one important implication: All
-important binaries and files should be owned by root, and not bin or other
-non-root account, since the only account the clients root user cannot access
-is the servers root account. In the exports(5) man page there are several
-other squash options listed so that you can decide to mistrust whomever you
-(don't) like on the clients.
-
-The TCP ports 1-1024 are reserved for root's use (and therefore sometimes
-referred to as "secure ports") A non-root user cannot bind these ports.
-Adding the secure option to an /etc/exports means that it will only listed to
-requests coming from ports 1-1024 on the client, so that a malicious non-root
-user on the client cannot come along and open up a spoofed NFS dialogue on a
-non-reserved port. This option is set by default.
------------------------------------------------------------------------------
-
-6.3. Client Security
-
-6.3.1. The nosuid mount option
-
-On the client we can decide that we don't want to trust the server too much a
-couple of ways with options to mount. For example we can forbid suid programs
-to work off the NFS file system with the nosuid option. Some unix programs,
-such as passwd, are called "suid" programs: They set the id of the person
-running them to whomever is the owner of the file. If a file is owned by root
-and is suid, then the program will execute as root, so that they can perform
-operations (such as writing to the password file) that only root is allowed
-to do. Using the nosuid option is a good idea and you should consider using
-this with all NFS mounted disks. It means that the server's root user cannot
-make a suid-root program on the file system, log in to the client as a normal
-user and then use the suid-root program to become root on the client too. One
-could also forbid execution of files on the mounted file system altogether
-with the noexec option. But this is more likely to be impractical than nosuid
-since a file system is likely to at least contain some scripts or programs
-that need to be executed.
------------------------------------------------------------------------------
-
-6.3.2. The broken_suid mount option
-
-Some older programs (xterm being one of them) used to rely on the idea that
-root can write everywhere. This is will break under new kernels on NFS
-mounts. The security implications are that programs that do this type of suid
-action can potentially be used to change your apparent uid on nfs servers
-doing uid mapping. So the default has been to disable this broken_suid in the
-linux kernel.
-
-The long and short of it is this: If you're using an old linux distribution,
-some sort of old suid program or an older unix of some type you might have to
-mount from your clients with the broken_suid option to mount. However, most
-recent unixes and linux distros have xterm and such programs just as a normal
-executable with no suid status, they call programs to do their setuid work.
-
-You enter the above options in the options column, with the rsize and wsize,
-separated by commas.
------------------------------------------------------------------------------
-
-6.3.3. Securing portmapper, rpc.statd, and rpc.lockd on the client
-
-In the current (2.2.18+) implementation of NFS, full file locking is
-supported. This means that rpc.statd and rpc.lockd must be running on the
-client in order for locks to function correctly. These services require the
-portmapper to be running. So, most of the problems you will find with nfs on
-the server you may also be plagued with on the client. Read through the
-portmapper section above for information on securing the portmapper.
------------------------------------------------------------------------------
-
-6.4. NFS and firewalls (ipchains and netfilter)
-
-IPchains (under the 2.2.X kernels) and netfilter (under the 2.4.x kernels)
-allow a good level of security - instead of relying on the daemon (or perhaps
-its TCP wrapper) to determine which machines can connect, the connection
-attempt is allowed or disallowed at a lower level. In this case, you can stop
-the connection much earlier and more globally, which can protect you from all
-sorts of attacks.
-
-Describing how to set up a Linux firewall is well beyond the scope of this
-document. Interested readers may wish to read the [http://www.linuxdoc.org/
-HOWTO/Firewall-HOWTO.html] Firewall-HOWTO or the [http://www.linuxdoc.org/
-HOWTO/IPCHAINS-HOWTO.HTML] IPCHAINS-HOWTO. For users of kernel 2.4 and above
-you might want to visit the netfilter webpage at: [http://
-netfilter.filewatcher.org] http://netfilter.filewatcher.org. If you are
-already familiar with the workings of ipchains or netfilter this section will
-give you a few tips on how to better setup your NFS daemons to more easily
-firewall and protect them.
-
-A good rule to follow for your firewall configuration is to deny all, and
-allow only some - this helps to keep you from accidentally allowing more than
-you intended.
-
-In order to understand how to firewall the NFS daemons, it will help to
-breifly review how they bind to ports.
-
-When a daemon starts up, it requests a free port from the portmapper. The
-portmapper gets the port for the daemon and keeps track of the port currently
-used by that daemon. When other hosts or processes need to communicate with
-the daemon, they request the port number from the portmapper in order to find
-the daemon. So the ports will perpetually float because different ports may
-be free at different times and so the portmapper will allocate them
-differently each time. This is a pain for setting up a firewall. If you never
-know where the daemons are going to be then you don't know precisely which
-ports to allow access to. This might not be a big deal for many people
-running on a protected or isolated LAN. For those people on a public network,
-though, this is horrible.
-
-In kernels 2.4.13 and later with nfs-utils 0.3.3 or later you no longer have
-to worry about the floating of ports in the portmapper. Now all of the
-daemons pertaining to nfs can be "pinned" to a port. Most of them nicely take
-a -p option when they are started; those daemons that are started by the
-kernel take some kernel arguments or module options. They are described
-below.
-
-Some of the daemons involved in sharing data via nfs are already bound to a
-port. portmap is always on port 111 tcp and udp. nfsd is always on port 2049
-TCP and UDP (however, as of kernel 2.4.17, NFS over TCP is considered
-experimental and is not for use on production machines).
-
-The other daemons, statd, mountd, lockd, and rquotad, will normally move
-around to the first available port they are informed of by the portmapper.
-
-To force statd to bind to a particular port, use the -p portnum option. To
-force statd to respond on a particular port, additionally use the -o portnum
-option when starting it.
-
-To force mountd to bind to a particular port use the -p portnum option.
-
-For example, to have statd broadcast of port 32765 and listen on port 32766,
-and mountd listen on port 32767, you would type:
-# statd -p 32765 -o 32766
-# mountd -p 32767
-
-lockd is started by the kernel when it is needed. Therefore you need to pass
-module options (if you have it built as a module) or kernel options to force
-lockd to listen and respond only on certain ports.
-
-If you are using loadable modules and you would like to specify these options
-in your /etc/modules.conf file add a line like this to the file:
-options lockd nlm_udpport=32768 nlm_tcpport=32768
-
-The above line would specify the udp and tcp port for lockd to be 32768.
-
-If you are not using loadable modules or if you have compiled lockd into the
-kernel instead of building it as a module then you will need to pass it an
-option on the kernel boot line.
-
-It should look something like this:
- vmlinuz 3 root=/dev/hda1 lockd.udpport=32768 lockd.tcpport=32768
-
-The port numbers do not have to match but it would simply add unnecessary
-confusion if they didn't.
-
-If you are using quotas and using rpc.quotad to make these quotas viewable
-over nfs you will need to also take it into account when setting up your
-firewall. There are two rpc.rquotad source trees. One of those is maintained
-in the nfs-utils tree. The other in the quota-tools tree. They do not operate
-identically. The one provided with nfs-utils supports binding the daemon to a
-port with the -p directive. The one in quota-tools does not. Consult your
-distribution's documentation to determine if yours does.
-
-For the sake of this discussion lets describe a network and setup a firewall
-to protect our nfs server. Our nfs server is 192.168.0.42 our client is
-192.168.0.45 only. As in the example above, statd has been started so that it
-only binds to port 32765 for incoming requests and it must answer on port
-32766. mountd is forced to bind to port 32767. lockd's module parameters have
-been set to bind to 32768. nfsd is, of course, on port 2049 and the
-portmapper is on port 111.
-
-We are not using quotas.
-
-Using IPCHAINS, a simple firewall might look something like this:
-ipchains -A input -f -j ACCEPT -s 192.168.0.45
-ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
-ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
-ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
-ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
-ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
-ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
-ipchains -A input -s 0/0 -d 0/0 -p 6 -j DENY -y -l
-ipchains -A input -s 0/0 -d 0/0 -p 17 -j DENY -l
-
-The equivalent set of commands in netfilter is:
-iptables -A INPUT -f -j ACCEPT -s 192.168.0.45
-iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
-iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
-iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
-iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
-iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
-iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
-iptables -A INPUT -s 0/0 -d 0/0 -p 6 -j DENY --syn --log-level 5
-iptables -A INPUT -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5
-
-The first line says to accept all packet fragments (except the first packet
-fragment which will be treated as a normal packet). In theory no packet will
-pass through until it is reassembled, and it won't be reassembled unless the
-first packet fragment is passed. Of course there are attacks that can be
-generated by overloading a machine with packet fragments. But NFS won't work
-correctly unless you let fragments through. See Section 7.8 for details.
-
-The other lines allow specific connections from any port on our client host
-to the specific ports we have made available on our server. This means that
-if, say, 192.158.0.46 attempts to contact the NFS server it will not be able
-to mount or see what mounts are available.
-
-With the new port pinning capabilities it is obviously much easier to control
-what hosts are allowed to mount your NFS shares. It is worth mentioning that
-NFS is not an encrypted protocol and anyone on the same physical network
-could sniff the traffic and reassemble the information being passed back and
-forth.
------------------------------------------------------------------------------
-
-6.5. Tunneling NFS through SSH
-
-One method of encrypting NFS traffic over a network is to use the
-port-forwarding capabilities of ssh. However, as we shall see, doing so has a
-serious drawback if you do not utterly and completely trust the local users
-on your server.
-
-The first step will be to export files to the localhost. For example, to
-export the /home partition, enter the following into /etc/exports:
-/home 127.0.0.1(rw)
-
-The next step is to use ssh to forward ports. For example, ssh can tell the
-server to forward to any port on any machine from a port on the client. Let
-us assume, as in the previous section, that our server is 192.168.0.42, and
-that we have pinned mountd to port 32767 using the argument -p 32767. Then,
-on the client, we'll type:
- # ssh root@192.168.0.42 -L 250:localhost:2049 -f sleep 60m
- # ssh root@192.168.0.42 -L 251:localhost:32767 -f sleep 60m
-
-The above command causes ssh on the client to take any request directed at
-the client's port 250 and forward it, first through sshd on the server, and
-then on to the server's port 2049. The second line causes a similar type of
-forwarding between requests to port 251 on the client and port 32767 on the
-server. The localhost is relative to the server; that is, the forwarding will
-be done to the server itself. The port could otherwise have been made to
-forward to any other machine, and the requests would look to the outside
-world as if they were coming from the server. Thus, the requests will appear
-to NFSD on the server as if they are coming from the server itself. Note that
-in order to bind to a port below 1024 on the client, we have to run this
-command as root on the client. Doing this will be necessary if we have
-exported our filesystem with the default secure option.
-
-Finally, we are pulling a little trick with the last option, -f sleep 60m.
-Normally, when we use ssh, even with the -L option, we will open up a shell
-on the remote machine. But instead, we just want the port forwarding to
-execute in the background so that we get our shell on the client back. So, we
-tell ssh to execute a command in the background on the server to sleep for 60
-minutes. This will cause the port to be forwarded for 60 minutes until it
-gets a connection; at that point, the port will continue to be forwarded
-until the connection dies or until the 60 minutes are up, whichever happens
-later. The above command could be put in our startup scripts on the client,
-right after the network is started.
-
-Next, we have to mount the filesystem on the client. To do this, we tell the
-client to mount a filesystem on the localhost, but at a different port from
-the usual 2049. Specifically, an entry in /etc/fstab would look like:
- localhost:/home /mnt/home nfs rw,hard,intr,port=250,mountport=251 0 0
-
-Having done this, we can see why the above will be incredibly insecure if we
-have any ordinary users who are able to log in to the server locally. If they
-can, there is nothing preventing them from doing what we did and using ssh to
-forward a privileged port on their own client machine (where they are
-legitimately root) to ports 2049 and 32767 on the server. Thus, any ordinary
-user on the server can mount our filesystems with the same rights as root on
-our client.
-
-If you are using an NFS server that does not have a way for ordinary users to
-log in, and you wish to use this method, there are two additional caveats:
-First, the connection travels from the client to the server via sshd;
-therefore you will have to leave port 22 (where sshd listens) open to your
-client on the firewall. However you do not need to leave the other ports,
-such as 2049 and 32767, open anymore. Second, file locking will no longer
-work. It is not possible to ask statd or the locking manager to make requests
-to a particular port for a particular mount; therefore, any locking requests
-will cause statd to connect to statd on localhost, i.e., itself, and it will
-fail with an error. Any attempt to correct this would require a major rewrite
-of NFS.
-
-It may also be possible to use IPSec to encrypt network traffic between your
-client and your server, without compromising any local security on the
-server; this will not be taken up here. See the [http://www.freeswan.org/]
-FreeS/WAN home page for details on using IPSec under Linux.
------------------------------------------------------------------------------
-
-6.6. Summary
-
-If you use the hosts.allow, hosts.deny, root_squash, nosuid and privileged
-port features in the portmapper/NFS software, you avoid many of the presently
-known bugs in NFS and can almost feel secure about that at least. But still,
-after all that: When an intruder has access to your network, s/he can make
-strange commands appear in your .forward or read your mail when /home or /var
-/mail is NFS exported. For the same reason, you should never access your PGP
-private key over NFS. Or at least you should know the risk involved. And now
-you know a bit of it.
-
-NFS and the portmapper makes up a complex subsystem and therefore it's not
-totally unlikely that new bugs will be discovered, either in the basic design
-or the implementation we use. There might even be holes known now, which
-someone is abusing. But that's life.
------------------------------------------------------------------------------
-
-7. Troubleshooting
-
-
- This is intended as a step-by-step guide to what to do when things go
- wrong using NFS. Usually trouble first rears its head on the client end,
- so this diagnostic will begin there.
-
-
------------------------------------------------------------------------------
-7.1. Unable to See Files on a Mounted File System
-
-First, check to see if the file system is actually mounted. There are several
-ways of doing this. The most reliable way is to look at the file /proc/
-mounts, which will list all mounted filesystems and give details about them.
-If this doesn't work (for example if you don't have the /proc filesystem
-compiled into your kernel), you can type mount -f although you get less
-information.
-
-If the file system appears to be mounted, then you may have mounted another
-file system on top of it (in which case you should unmount and remount both
-volumes), or you may have exported the file system on the server before you
-mounted it there, in which case NFS is exporting the underlying mount point
-(if so then you need to restart NFS on the server).
-
-If the file system is not mounted, then attempt to mount it. If this does not
-work, see Symptom 3.
------------------------------------------------------------------------------
-
-7.2. File requests hang or timeout waiting for access to the file.
-
-This usually means that the client is unable to communicate with the server.
-See Symptom 3 letter b.
------------------------------------------------------------------------------
-
-7.3. Unable to mount a file system
-
-There are two common errors that mount produces when it is unable to mount a
-volume. These are:
-
- a. failed, reason given by server: Permission denied
-
- This means that the server does not recognize that you have access to the
- volume.
-
- i. Check your /etc/exports file and make sure that the volume is
- exported and that your client has the right kind of access to it. For
- example, if a client only has read access then you have to mount the
- volume with the ro option rather than the rw option.
-
- ii. Make sure that you have told NFS to register any changes you made to
- /etc/exports since starting nfsd by running the exportfs command. Be
- sure to type exportfs -ra to be extra certain that the exports are
- being re-read.
-
- iii. Check the file /proc/fs/nfs/exports and make sure the volume and
- client are listed correctly. (You can also look at the file /var/lib/
- nfs/xtab for an unabridged list of how all the active export options
- are set.) If they are not, then you have not re-exported properly. If
- they are listed, make sure the server recognizes your client as being
- the machine you think it is. For example, you may have an old listing
- for the client in /etc/hosts that is throwing off the server, or you
- may not have listed the client's complete address and it may be
- resolving to a machine in a different domain. One trick is login to
- the server from the client via ssh or telnet; if you then type who,
- one of the listings should be your login session and the name of your
- client machine as the server sees it. Try using this machine name in
- your /etc/exports entry. Finally, try to ping the client from the
- server, and try to ping the server from the client. If this doesn't
- work, or if there is packet loss, you may have lower-level network
- problems.
-
- iv. It is not possible to export both a directory and its child (for
- example both /usr and /usr/local). You should export the parent
- directory with the necessary permissions, and all of its
- subdirectories can then be mounted with those same permissions.
-
-
- b. RPC: Program Not Registered: (or another "RPC" error):
-
- This means that the client does not detect NFS running on the server.
- This could be for several reasons.
-
- i. First, check that NFS actually is running on the server by typing
- rpcinfo -p on the server. You should see something like this:
- +------------------------------------------------------------+
- | program vers proto port |
- | 100000 2 tcp 111 portmapper |
- | 100000 2 udp 111 portmapper |
- | 100011 1 udp 749 rquotad |
- | 100011 2 udp 749 rquotad |
- | 100005 1 udp 759 mountd |
- | 100005 1 tcp 761 mountd |
- | 100005 2 udp 764 mountd |
- | 100005 2 tcp 766 mountd |
- | 100005 3 udp 769 mountd |
- | 100005 3 tcp 771 mountd |
- | 100003 2 udp 2049 nfs |
- | 100003 3 udp 2049 nfs |
- | 300019 1 tcp 830 amd |
- | 300019 1 udp 831 amd |
- | 100024 1 udp 944 status |
- | 100024 1 tcp 946 status |
- | 100021 1 udp 1042 nlockmgr |
- | 100021 3 udp 1042 nlockmgr |
- | 100021 4 udp 1042 nlockmgr |
- | 100021 1 tcp 1629 nlockmgr |
- | 100021 3 tcp 1629 nlockmgr |
- | 100021 4 tcp 1629 nlockmgr |
- | |
- +------------------------------------------------------------+
- This says that we have NFS versions 2 and 3, rpc.statd version 1,
- network lock manager (the service name for rpc.lockd) versions 1, 3,
- and 4. There are also different service listings depending on whether
- NFS is travelling over TCP or UDP. UDP is usually (but not always)
- the default unless TCP is explicitly requested.
-
- If you do not see at least portmapper, nfs, and mountd, then you need
- to restart NFS. If you are not able to restart successfully, proceed
- to Symptom 9.
-
- ii. Now check to make sure you can see it from the client. On the client,
- type rpcinfo -p server where server is the DNS name or IP address of
- your server.
-
- If you get a listing, then make sure that the type of mount you are
- trying to perform is supported. For example, if you are trying to
- mount using Version 3 NFS, make sure Version 3 is listed; if you are
- trying to mount using NFS over TCP, make sure that is registered.
- (Some non-Linux clients default to TCP). Type man rpcinfo for more
- details on how to read the output. If the type of mount you are
- trying to perform is not listed, try a different type of mount.
-
- If you get the error No Remote Programs Registered, then you need to
- check your /etc/hosts.allow and /etc/hosts.deny files on the server
- and make sure your client actually is allowed access. Again, if the
- entries appear correct, check /etc/hosts (or your DNS server) and
- make sure that the machine is listed correctly, and make sure you can
- ping the server from the client. Also check the error logs on the
- system for helpful messages: Authentication errors from bad /etc/
- hosts.allow entries will usually appear in /var/log/messages, but may
- appear somewhere else depending on how your system logs are set up.
- The man pages for syslog can help you figure out how your logs are
- set up. Finally, some older operating systems may behave badly when
- routes between the two machines are asymmetric. Try typing tracepath
- [server] from the client and see if the word "asymmetric" shows up
- anywhere in the output. If it does then this may be causing packet
- loss. However asymmetric routes are not usually a problem on recent
- linux distributions.
-
- If you get the error Remote system error - No route to host, but you
- can ping the server correctly, then you are the victim of an
- overzealous firewall. Check any firewalls that may be set up, either
- on the server or on any routers in between the client and the server.
- Look at the man pages for ipchains, netfilter, and ipfwadm, as well
- as the [http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html]
- IPChains-HOWTO and the [http://www.linuxdoc.org/HOWTO/
- Firewall-HOWTO.html] Firewall-HOWTO for help.
-
-
-
------------------------------------------------------------------------------
-7.4. I do not have permission to access files on the mounted volume.
-
-This could be one of two problems.
-
-If it is a write permission problem, check the export options on the server
-by looking at /proc/fs/nfs/exports and make sure the filesystem is not
-exported read-only. If it is you will need to re-export it read/write (don't
-forget to run exportfs -ra after editing /etc/exports). Also, check /proc/
-mounts and make sure the volume is mounted read/write (although if it is
-mounted read-only you ought to get a more specific error message). If not
-then you need to re-mount with the rw option.
-
-The second problem has to do with username mappings, and is different
-depending on whether you are trying to do this as root or as a non-root user.
-
-If you are not root, then usernames may not be in sync on the client and the
-server. Type id [user] on both the client and the server and make sure they
-give the same UID number. If they don't then you are having problems with
-NIS, NIS+, rsync, or whatever system you use to sync usernames. Check group
-names to make sure that they match as well. Also, make sure you are not
-exporting with the all_squash option. If the user names match then the user
-has a more general permissions problem unrelated to NFS.
-
-If you are root, then you are probably not exporting with the no_root_squash
-option; check /proc/fs/nfs/exports or /var/lib/nfs/xtab on the server and
-make sure the option is listed. In general, being able to write to the NFS
-server as root is a bad idea unless you have an urgent need -- which is why
-Linux NFS prevents it by default. See Section 6 for details.
-
-If you have root squashing, you want to keep it, and you're only trying to
-get root to have the same permissions on the file that the user nobody should
-have, then remember that it is the server that determines which uid root gets
-mapped to. By default, the server uses the UID and GID of nobody in the /etc/
-passwd file, but this can also be overridden with the anonuid and anongid
-options in the /etc/exports file. Make sure that the client and the server
-agree about which UID nobody gets mapped to.
------------------------------------------------------------------------------
-
-7.5. When I transfer really big files, NFS takes over all the CPU cycles on
-the server and it screeches to a halt.
-
-This is a problem with the fsync() function in 2.2 kernels that causes all
-sync-to-disk requests to be cumulative, resulting in a write time that is
-quadratic in the file size. If you can, upgrading to a 2.4 kernel should
-solve the problem. Also, exporting with the no_wdelay option forces the
-program to use o_sync() instead, which may prove faster.
------------------------------------------------------------------------------
-
-7.6. Strange error or log messages
-
- a. Messages of the following format:
-
- +-------------------------------------------------------------------------------------------+
- | Jan 7 09:15:29 server kernel: fh_verify: mail/guest permission failure, acc=4, error=13 |
- | Jan 7 09:23:51 server kernel: fh_verify: ekonomi/test permission failure, acc=4, error=13 |
- | |
- +-------------------------------------------------------------------------------------------+
-
- These happen when a NFS setattr operation is attempted on a file you
- don't have write access to. The messages are harmless.
-
- b. The following messages frequently appear in the logs:
-
- +---------------------------------------------------------------------+
- | kernel: nfs: server server.domain.name not responding, still trying |
- | kernel: nfs: task 10754 can't get a request slot |
- | kernel: nfs: server server.domain.name OK |
- | |
- +---------------------------------------------------------------------+
-
- The "can't get a request slot" message means that the client-side RPC
- code has detected a lot of timeouts (perhaps due to network congestion,
- perhaps due to an overloaded server), and is throttling back the number
- of concurrent outstanding requests in an attempt to lighten the load. The
- cause of these messages is basically sluggish performance. See Section 5
- for details.
-
- c. After mounting, the following message appears on the client:
-
- +---------------------------------------------------------------+
- |nfs warning: mount version older than kernel |
- | |
- +---------------------------------------------------------------+
-
- It means what it says: You should upgrade your mount package and/or
- am-utils. (If for some reason upgrading is a problem, you may be able to
- get away with just recompiling them so that the newer kernel features are
- recognized at compile time).
-
- d. Errors in startup/shutdown log for lockd
-
- You may see a message of the following kind in your boot log:
- +---------------------------------------------------------------+
- |nfslock: rpc.lockd startup failed |
- | |
- +---------------------------------------------------------------+
-
- They are harmless. Older versions of rpc.lockd needed to be started up
- manually, but newer versions are started automatically by nfsd. Many of
- the default startup scripts still try to start up lockd by hand, in case
- it is necessary. You can alter your startup scripts if you want the
- messages to go away.
-
- e. The following message appears in the logs:
-
- +---------------------------------------------------------------+
- |kmem_create: forcing size word alignment - nfs_fh |
- | |
- +---------------------------------------------------------------+
-
- This results from the file handle being 16 bits instead of a mulitple of
- 32 bits, which makes the kernel grimace. It is harmless.
-
-
------------------------------------------------------------------------------
-7.7. Real permissions don't match what's in /etc/exports.
-
-/etc/exports is very sensitive to whitespace - so the following statements
-are not the same:
-/export/dir hostname(rw,no_root_squash)
-/export/dir hostname (rw,no_root_squash)
-
-The first will grant hostname rw access to /export/dir without squashing root
-privileges. The second will grant hostname rw privileges with root squash and
-it will grant everyone else read/write access, without squashing root
-privileges. Nice huh?
------------------------------------------------------------------------------
-
-7.8. Flaky and unreliable behavior
-
-Simple commands such as ls work, but anything that transfers a large amount
-of information causes the mount point to lock.
-
-This could be one of two problems:
-
- i. It will happen if you have ipchains on at the server and/or the client
- and you are not allowing fragmented packets through the chains. Allow
- fragments from the remote host and you'll be able to function again. See
- Section 6.4 for details on how to do this.
-
-ii. You may be using a larger rsize and wsize in your mount options than the
- server supports. Try reducing rsize and wsize to 1024 and seeing if the
- problem goes away. If it does, then increase them slowly to a more
- reasonable value.
-
-
------------------------------------------------------------------------------
-7.9. nfsd won't start
-
-Check the file /etc/exports and make sure root has read permission. Check the
-binaries and make sure they are executable. Make sure your kernel was
-compiled with NFS server support. You may need to reinstall your binaries if
-none of these ideas helps.
------------------------------------------------------------------------------
-
-7.10. File Corruption When Using Multiple Clients
-
-If a file has been modified within one second of its previous modification
-and left the same size, it will continue to generate the same inode number.
-Because of this, constant reads and writes to a file by multiple clients may
-cause file corruption. Fixing this bug requires changes deep within the
-filesystem layer, and therefore it is a 2.5 item.
------------------------------------------------------------------------------
-
-8. Using Linux NFS with Other OSes
-
-Every operating system, Linux included, has quirks and deviations in the
-behavior of its NFS implementation -- sometimes because the protocols are
-vague, sometimes because they leave gaping security holes. Linux will work
-properly with all major vendors' NFS implementations, as far as we know.
-However, there may be extra steps involved to make sure the two OSes are
-communicating clearly with one another. This section details those steps.
-
-In general, it is highly ill-advised to attempt to use a Linux machine with a
-kernel before 2.2.18 as an NFS server for non-Linux clients. Implementations
-with older kernels may work fine as clients; however if you are using one of
-these kernels and get stuck, the first piece of advice we would give is to
-upgrade your kernel and see if the problems go away. The user-space NFS
-implementations also do not work well with non-Linux clients.
-
-Following is a list of known issues for using Linux together with major
-operating systems.
------------------------------------------------------------------------------
-
-8.1. AIX
-
-8.1.1. Linux Clients and AIX Servers
-
-The format for the /etc/exports file for our example in Section 3 is:
- /usr slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com
- /home slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com
-
------------------------------------------------------------------------------
-
-8.1.2. AIX clients and Linux Servers
-
-AIX uses the file /etc/filesystems instead of /etc/fstab. A sample entry,
-based on the example in Section 4, looks like this:
-/mnt/home:
- dev = "/home"
- vfs = nfs
- nodename = master.foo.com
- mount = true
- options = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp
- account = false
-
-
- i. Version 4.3.2 of AIX, and possibly earlier versions as well, requires
- that file systems be exported with the insecure option, which causes NFS
- to listen to requests from insecure ports (i.e., ports above 1024, to
- which non-root users can bind). Older versions of AIX do not seem to
- require this.
-
-ii. AIX clients will default to mounting version 3 NFS over TCP. If your
- Linux server does not support this, then you may need to specify vers=2
- and/or proto=udp in your mount options.
-
-iii. Using netmasks in /etc/exports seems to sometimes cause clients to lose
- mounts when another client is reset. This can be fixed by listing out
- hosts explicitly.
-
-iv. Apparently automount in AIX 4.3.2 is rather broken.
-
-
------------------------------------------------------------------------------
-8.2. BSD
-
-8.2.1. BSD servers and Linux clients
-
-BSD kernels tend to work better with larger block sizes.
------------------------------------------------------------------------------
-
-8.2.2. Linux servers and BSD clients
-
-Some versions of BSD may make requests to the server from insecure ports, in
-which case you will need to export your volumes with the insecure option. See
-the man page for exports(5) for more details.
------------------------------------------------------------------------------
-
-8.3. Tru64 Unix
-
-8.3.1. Tru64 Unix Servers and Linux Clients
-
-In general, Tru64 Unix servers work quite smoothly with Linux clients. The
-format for the /etc/exports file for our example in Section 3 is:
-
-/usr slave1.foo.com:slave2.foo.com \
- -access=slave1.foo.com:slave2.foo.com \
-
-/home slave1.foo.com:slave2.foo.com \
- -rw=slave1.foo.com:slave2.foo.com \
- -root=slave1.foo.com:slave2.foo.com
-
-
-(The root option is listed in the last entry for informational purposes only;
-its use is not recommended unless necessary.)
-
-Tru64 checks the /etc/exports file every time there is a mount request so you
-do not need to run the exportfs command; in fact on many versions of Tru64
-Unix the command does not exist.
------------------------------------------------------------------------------
-
-8.3.2. Linux Servers and Tru64 Unix Clients
-
-There are two issues to watch out for here. First, Tru64 Unix mounts using
-Version 3 NFS by default. You will see mount errors if your Linux server does
-not support Version 3 NFS. Second, in Tru64 Unix 4.x, NFS locking requests
-are made by daemon. You will therefore need to specify the insecure_locks
-option on all volumes you export to a Tru64 Unix 4.x client; see the exports
-man pages for details.
------------------------------------------------------------------------------
-
-8.4. HP-UX
-
-8.4.1. HP-UX Servers and Linux Clients
-
-A sample /etc/exports entry on HP-UX looks like this:
-/usr -ro,access=slave1.foo.com:slave2.foo.com
-/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
-
-(The root option is listed in the last entry for informational purposes only;
-its use is not recommended unless necessary.)
------------------------------------------------------------------------------
-
-8.4.2. Linux Servers and HP-UX Clients
-
-HP-UX diskless clients will require at least a kernel version 2.2.19 (or
-patched 2.2.18) for device files to export correctly. Also, any exports to an
-HP-UX client will need to be exported with the insecure_locks option.
------------------------------------------------------------------------------
-
-8.5. IRIX
-
-8.5.1. IRIX Servers and Linux Clients
-
-A sample /etc/exports entry on IRIX looks like this:
-/usr -ro,access=slave1.foo.com:slave2.foo.com
-/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
-
-(The root option is listed in the last entry for informational purposes only;
-its use is not recommended unless necessary.)
-
-There are reportedly problems when using the nohide option on exports to
-linux 2.2-based systems. This problem is fixed in the 2.4 kernel. As a
-workaround, you can export and mount lower-down file systems separately.
-
-As of Kernel 2.4.17, there continue to be several minor interoperability
-issues that may require a kernel upgrade. In particular:
-
- * Make sure that Trond Myklebust's seekdir (or dir) kernel patch is
- applied. The latest version (for 2.4.17) is located at:
-
- [http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif]
- http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif
-
- * IRIX servers do not always use the same fsid attribute field across
- reboots, which results in inode number mismatch errors on a Linux client
- if the mounted IRIX server reboots. A patch is available from:
-
- [http://www.geocrawler.com/lists/3/SourceForge/789/0/7777454/] http://
- www.geocrawler.com/lists/3/SourceForge/789/0/7777454/
-
- * Linux kernels v2.4.9 and above have problems reading large directories
- (hundreds of files) from exported IRIX XFS file systems that were made
- with naming version=1. The reason for the problem can be found at:
-
- [http://www.geocrawler.com/archives/3/789/2001/9/100/6531172/] http://
- www.geocrawler.com/archives/3/789/2001/9/100/6531172/
-
- The naming version can be found by using (on the IRIX server):
- xfs_growfs -n mount_point
-
-
- The workaround is to export these file systems using the -32bitclients
- option in the /etc/exports file. The fix is to convert the file system to
- 'naming version=2'. Unfortunately the only way to do this is by a backup/
- mkfs/restore.
-
- mkfs_xfs on IRIX 6.5.14 (and above) creates naming version=2 XFS file
- systems by default. On IRIX 6.5.5 to 6.5.13, use:
- mkfs_xfs -n version=2 device
-
-
- Versions of IRIX prior to 6.5.5 do not support naming version=2 XFS file
- systems.
-
-
------------------------------------------------------------------------------
-8.5.2. IRIX clients and Linux servers
-
-Irix versions up to 6.5.12 have problems mounting file systems exported from
-Linux boxes - the mount point "gets lost," e.g.,
- # mount linux:/disk1 /mnt
- # cd /mnt/xyz/abc
- # pwd
- /xyz/abc
-
-
-This is known IRIX bug (SGI bug 815265 - IRIX not liking file handles of less
-than 32 bytes), which is fixed in IRIX 6.5.13. If it is not possible to
-upgrade to IRIX 6.5.13, then the unofficial workaround is to force the Linux
-nfsd to always use 32 byte file handles.
-
-A number of patches exist - see:
-
- * [http://www.geocrawler.com/archives/3/789/2001/8/50/6371896/] http://
- www.geocrawler.com/archives/3/789/2001/8/50/6371896/
-
- * [http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html] http://
- oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html
-
-
------------------------------------------------------------------------------
-8.6. Solaris
-
-8.6.1. Solaris Servers
-
-Solaris has a slightly different format on the server end from other
-operating systems. Instead of /etc/exports, the configuration file is /etc/
-dfs/dfstab. Entries are of the form of a share command, where the syntax for
-the example in Section 3 would look like
-share -o rw=slave1,slave2 -d "Master Usr" /usr
-
-and instead of running exportfs after editing, you run shareall.
-
-Solaris servers are especially sensitive to packet size. If you are using a
-Linux client with a Solaris server, be sure to set rsize and wsize to 32768
-at mount time.
-
-Finally, there is an issue with root squashing on Solaris: root gets mapped
-to the user noone, which is not the same as the user nobody. If you are
-having trouble with file permissions as root on the client machine, be sure
-to check that the mapping works as you expect.
------------------------------------------------------------------------------
-
-8.6.2. Solaris Clients
-
-Solaris clients will regularly produce the following message:
-+---------------------------------------------------------------------------+
-|svc: unknown program 100227 (me 100003) |
-| |
-+---------------------------------------------------------------------------+
-
-This happens because Solaris clients, when they mount, try to obtain ACL
-information - which Linux obviously does not have. The messages can safely be
-ignored.
-
-There are two known issues with diskless Solaris clients: First, a kernel
-version of at least 2.2.19 is needed to get /dev/null to export correctly.
-Second, the packet size may need to be set extremely small (i.e., 1024) on
-diskless sparc clients because the clients do not know how to assemble
-packets in reverse order. This can be done from /etc/bootparams on the
-clients.
------------------------------------------------------------------------------
-
-8.7. SunOS
-
-SunOS only has NFS Version 2 over UDP.
------------------------------------------------------------------------------
-
-8.7.1. SunOS Servers
-
-On the server end, SunOS uses the most traditional format for its /etc/
-exports file. The example in Section 3 would look like:
-/usr -access=slave1.foo.com,slave2.foo.com
-/home -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com
-
-
-Again, the root option is listed for informational purposes and is not
-recommended unless necessary.
------------------------------------------------------------------------------
-
-8.7.2. SunOS Clients
-
-Be advised that SunOS makes all NFS locking requests as daemon, and therefore
-you will need to add the insecure_locks option to any volumes you export to a
-SunOS machine. See the exports man page for details.
diff --git a/LDP/guide/docbook/Linux-Networking/Sources.xml b/LDP/guide/docbook/Linux-Networking/Sources.xml
index 74055074..bfa0aeef 100644
--- a/LDP/guide/docbook/Linux-Networking/Sources.xml
+++ b/LDP/guide/docbook/Linux-Networking/Sources.xml
@@ -402,5 +402,43 @@ The Clock Mini-HOWTO
X Window System Architecture Overview HOWTO
The LBX Mini-HOWTO
Leased line Mini HOWTO
-
+
+ 26. http://www.oswg.org/oswg-nightly/DHCP.html
+ 27. http://www.linux.org.tw/CLDP/mini/DHCP.html
+ 28. http://www.linux.or.jp/JF/JFdocs/DHCP.html
+ 29. ftp://cuates.pue.upaep.mx/pub/linux/LuCAS/DHCP-mini-Como/
+ 30. mailto:vuksan-feedback@veus.hr
+ 31. http://www.opencontent.org/opl.shtml
+ 32. http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
+ 33. mailto:sergei@phystech.com
+ 34. ftp://ftp.phystech.com/pub/
+ 35. http://www.cps.msu.edu/~dunham/out/
+ 36. ftp://metalab.unc.edu/pub/Linux/system/network/daemons
+ 37. ftp://ftp.phystech.com/pub/
+ 38. DHCP.html#NAMESERVER
+ 39. DHCP.html#LINUXPPC-RH6
+ 40. mailto:alexander.stevenson@home.com
+ 41. DHCP.html#NAMESERVER
+ 42. ftp://ftp.redhat.com/pub/redhat/redhat-4.2/i386/RedHat/RPMS/dhcpcd-0.6-2.i386.rpm
+ 43. DHCP.html#SLACKWARE
+ 44. mailto:nothing@cc.gatech.edu
+ 45. DHCP.html#NAMESERVER
+ 46. http://ftp.debian.org/debian/dists/slink/main/binary-i386/net/
+ 47. DHCP.html#SLACKWARE
+ 48. mailto:heiko@os.inf.tu-dresden.de
+ 49. DHCP.html#NAMESERVER
+ 50. DHCP.html#REDHAT6
+ 51. ftp://ftp.linuxppc.org/
+ 52. ftp://ftp.phystech.com/pub/dhcpcd-1.3.17-pl9.tar.gz
+ 53. DHCP.html#TROUBLESHOOTING
+ 54. mailto:nothing@cc.gatech.edu
+ 55. DHCP.html#ERROR3
+ 56. ftp://vanbuer.ddns.org/pub/
+ 57. DHCP.html#DHCPSERVER
+ 58. mailto:mellon@isc.org
+ 59. ftp://ftp.isc.org/isc/dhcp/
+ 60. http://www.kde.org/
+ 61. ftp://ftp.us.kde.org/pub/kde/unstable/apps/network/
+ 62. http://www.linux-mag.com/2000-04/networknirvana_01.html
+