Olaf Kirch - Linux Network Administrator Guide, Second Edition

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.

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.

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/.

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] Novell and NetWare are trademarks of the Novell Corporation. 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.

First, let's look at where the protocols came from and what they look like. In the late 1970s, the Xerox Corporation developed and published an open standard called the Xerox Network Specification (XNS). The Xerox Network Specification described a series of protocols designed for general purpose internetworking, with a strong emphasis on the use of local area networks. There were two primary networking protocols involved: the Internet Datagram Protocol (IDP), which provided a connectionless and unreliable transport of datagrams from one host to another, and the Sequenced Packet Protocol (SPP), which was a modified form of IDP that was connection-based and reliable. The datagrams of an XNS network were individually addressed. The addressing scheme used a combination of a 4-byte IDP network address (which was uniquely assigned to each Ethernet LAN segment), and the 6-byte node address (the address of the NIC card). Routers were devices that switched datagrams between two or more separate IDP networks. IDP has no notion of subnetworks; any new collection of hosts requires another network address to be assigned. Network addresses are chosen such that they are unique on the internetwork in question. Sometimes administrators develop conventions by having each byte encode some other information, such as geographic location, so that network addresses are allocated in a systemic way; it isn't a protocol requirement, however.

The Novell Corporation chose to base their own networking suite on the XNS suite. Novell made small enhancements to IDP and SPP and renamed them IPX (Internet Packet eXchange) and SPX (Sequenced Packet eXchange). Novell added new protocols, such as the NetWare Core Protocol (NCP), which provided file and printer sharing features that ran over IPX, and the Service Advertisement Protocol (SAP), which enabled hosts on a Novell network to know which hosts provided which services.