/home/ftp (ro)
Each line defines a directory and the hosts that are allowed to mount it. A hostname is usually a fully qualified domain name but may additionally contain the * and ? wildcards, which act the way they do with the Bourne shell. For instance, lab*.foo.com matches lab01.foo.com as well as laboratory.foo.com. The host may also be specified using an IP address range in the form address/netmask. If no hostname is given, as with the /home/ftp directory in the previous example, any host matches and is allowed to mount the directory.
When checking a client host against the exports file, rpx.mountd looks up the client's hostname using the gethostbyaddr call. With DNS, this call returns the client's canonical hostname, so you must make sure not to use aliases in exports. In an NIS environment the returned name is the first match from the hosts database, and with neither DNS or NIS, the returned name is the first hostname found in the hosts file that matches the client's address.
The hostname is followed by an optional comma-separated list of flags, enclosed in parentheses. Some of the values these flags may take are:
secure
This flag insists that requests be made from a reserved source port, i.e., one that is less than 1,024. This flag is set by default.
insecure
This flag reverses the effect of the secure flag.
ro
This flag causes the NFS mount to be read-only. This flag is enabled by default.
rw
This option mounts file hierarchy read-write.
root_squash
This security feature denies the superusers on the specified hosts any special access rights by mapping requests from uid 0 on the client to the uid 65534 (that is, -2) on the server. This uid should be associated with the user nobody.
no_root_squash
Don't map requests from uid 0. This option is on by default, so superusers have superuser access to your system's exported directories.
link_relative
This option converts absolute symbolic links (where the link contents start with a slash) into relative links. This option makes sense only when a host's entire filesystem is mounted; otherwise, some of the links might point to nowhere, or even worse, to files they were never meant to point to. This option is on by default.
link_absolute
This option leaves all symbolic links as they are (the normal behavior for Sun-supplied NFS servers).
map_identity
This option tells the server to assume that the client uses the same uids and gids as the server. This option is on by default.
map_daemon
This option tells the NFS server to assume that client and server do not share the same uid/gid space. rpc.nfsd then builds a list that maps IDs between client and server by querying the client's rpc.ugidd daemon.
map_static
This option allows you to specify the name of a file that contains a static map of uids and gids. For example, map_static=/etc/nfs/vlight.map would specify the /etc/nfs/vlight.map file as a uid/gid map. The syntax of the map file is described in the exports(5) manual page.
map_nis
This option causes the NIS server to do the uid and gid mapping.
anonuid and anongid
These options allow you to specify the uid and gid of the anonymous account. This is useful if you have a volume exported for public mounts.
Any error in parsing the exports file is reported to syslogd 's daemon facility at level notice whenever rpc.nfsd or rpc.mountd is started up.
Note that hostnames are obtained from the client's IP address by reverse mapping, so the resolver must be configured properly. If you use BIND and are very security conscious, you should enable spoof checking in your host.conf file. We discuss these topics in Chapter 6, Name Service and Resolver Configuration.
Kernel-Based NFSv2 Server Support
The user-space NFS server traditionally used in Linux works reliably but suffers performance problems when overworked. This is primarily because of the overhead the system call interface adds to its operation, and because it must compete for time with other, potentially less important, user-space processes.
The 2.2.0 kernel supports an experimental kernel-based NFS server developed by Olaf Kirch and further developed by H.J. Lu, G. Allan Morris, and Trond Myklebust. The kernel-based NFS support provides a significant boost in server performance.
In current release distributions, you may find the server tools available in prepackaged form. If not, you can locate them at http://csua.berkeley.edu/~gam3/knfsd/. You need to build a 2.2.0 kernel with the kernel-based NFS daemon included in order to make use of the tools. You can check if your kernel has the NFS daemon included by looking to see if the /proc/sys/sunrpc/nfsd_debug file exists. If it's not there, you may have to load the rpc.nfsd module using the modprobe utility.
The kernel-based NFS daemon uses a standard /etc/exports configuration file. The package supplies replacement versions of the rpc.mountd and rpc.nfsd daemons that you start much the same way as their userspace daemon counterparts.
Kernel-Based NFSv3 Server Support
The version of NFS that has been most commonly used is NFS Version 2. Technology has rolled on ahead and it has begun to show weaknesses that only a revision of the protocol could overcome. Version 3 of the Network File System supports larger files and filesystems, adds significantly enhanced security, and offers a number of performance improvements that most users will find useful.
Olaf Kirch and Trond Myklebust are developing an experimental NFSv3 server. It is featured in the developer Version 2.3 kernels and a patch is available against the 2.2 kernel source. It builds on the Version 2 kernel-based NFS daemon.
The patches are available from the Linux Kernel based NFS server home page at http://csua.berkeley.edu/~gam3/knfsd/.
Chapter 15. IPX and the NCP Filesystem
Long before Microsoft learned about networking, and even before the Internet was known outside academic circles, corporate environments shared files and printers using file and print servers based on the Novell NetWare operating system and associated protocols.[82] Many of these corporate users still have legacy networks using these protocols and want to integrate this support with their new TCP/IP support.
Linux supports not only the TCP/IP protocols, but also the suite of protocols used by the Novell Corporation's NetWare operating system. These protocols are distant cousins of TCP/IP, and while they perform similar sorts of functions, they differ in a number of ways and are unfortunately incompatible.
Linux has both free and commercial software offerings to provide support for integration with the Novell products.
We'll provide a brief description of the protocols themselves in this chapter, but we focus on how to configure and use free software to allow Linux to interoperate with Novell products.
Xerox, Novell, and History