NFS and the Automounter - Revision history

Jeff at 21:16, 30 May 2010

Jeff — Sun, 30 May 2010 21:16:06 GMT

←Older revision		Revision as of 21:16, 30 May 2010
Line 40:		Line 40:

	=== /etc/auto.master ===		=== /etc/auto.master ===
		+
		+	The Linux automounter is called <code>autofs</code>. It is controlled by at least two files, the master and the map files. To configure <code>autofs</code>, add an entry to <code>/etc/auto.master</code>, defining a mount point on the left, and a map file on the right.

	<pre>		<pre>
	/home /etc/auto.home		/home /etc/auto.home
	</pre>		</pre>
		+
		+	Every time a user requests access to any object inside the mount point listed on the left, the automounter will be consulted, and it will operate according to the instructions in the map file.

	=== /etc/auto.home ===		=== /etc/auto.home ===
		+
		+	In order to mount any user's HOME directory, we define a pattern of "*" on the left of the map. In the middle we include a series of mount options exactly as we might do on the command line with the <code>mount</code> command, or in the <code>/etc/fstab</code> file. On the right, we list which host to contact, a colon, and where to look for the exported file systems. The ampersand tells <code>autofs</code> to match the key specified by leaving an asterisk on the left. In otherwords, a request for <code>user</code> would result in a request for <code>server:/home/user</code> via <code>NFS</code>.

	<pre>		<pre>
	* -nosuid,nodev,soft,rsize=32768,wsize=32768 server:/home/&		* -nosuid,nodev,soft,rsize=32768,wsize=32768 server:/home/&
	</pre>		</pre>
		+
		+	The options listed here are regarded as best practices. Users' home directories should not allow the execution of set-uid binaries nor the creation of device files. These restrictions prevent users from installing software in their home directory which might somehow give them root access, or being able to create a hard disk device to change system settings. Both of these should not be possible under normal circumstances but this helps mitigate the abnormal circumstances as well. The "soft" option prevents <code>NFS</code> interruptions from hanging the client operating system. Both of the size parameters are the largest possible block sizes for <code>NFS</code>. If the server can't support this size, it will negotiate down automatically, so best to set it at the largest.
		+
		+	=== The /net Mountpoint ===
		+
		+	It is quite possible your <code>/etc/auto.master</code> file contains either of the following lines.
		+
		+	<pre>
		+	/net -hosts
		+	</pre>
		+
		+	or
		+
		+	<pre>
		+	/net /etc/auto.net
		+	</pre>
		+
		+	In the former case, this is a built-in to more recent versions of <code>autofs</code>, in which it will automatically search for <code>NFS</code> exports given the next directory component is the name of a host.
		+
		+	In the latter case, <code>/etc/auto.net</code> is an executable shell script, and when <code>autofs</code> encounters an executable map file, it runs it, passing the path which was requested as a command argument, and uses the output to establish the mount point.
		+
		+	In either case, the result is you can specify a path such as <code>/net/server/export</code> and <code>autofs</code> will try to mount <code>server:/export</code> for you.

	----		----
	[[User:Jeff\|Jeff]]		[[User:Jeff\|Jeff]]

Jeff at 03:24, 6 September 2009

Jeff — Sun, 06 Sep 2009 03:24:53 GMT

←Older revision		Revision as of 03:24, 6 September 2009
Line 50:		Line 50:
	* -nosuid,nodev,soft,rsize=32768,wsize=32768 server:/home/&		* -nosuid,nodev,soft,rsize=32768,wsize=32768 server:/home/&
	</pre>		</pre>
		+
		+	----
		+	[[User:Jeff\|Jeff]]

Jeff at 17:06, 2 August 2009

Jeff — Sun, 02 Aug 2009 17:06:31 GMT

←Older revision		Revision as of 17:06, 2 August 2009
Line 1:		Line 1:
		+	NFS is the Unix way to export and mount file systems over the network. It is very easy to configure, and almost too easy to use. I'm going to demonstrate how to configure a file server to export user home directories to various Unix clients, and how to mount them using the automounter, which is a service that mounts various file systems on demand and unmounts them after they have been unused for a period of time.
		+
	== NFS ==		== NFS ==
		+
		+	In order to export directories via NFS, only one file must be edited, and a few services need to be running. I'll explain <code>/etc/exports</code> below.
		+
		+	;portmap or rpcbind
		+
		+	:NFS versions 2 and 3 are not bound to using the same ports all the time. Another service, the port mapper, tells clients which ports to use. The port mapper itself always runs on both TCP and UDP ports 111. NFS version 4 uses registered port numbers but it is much more difficult to configure, so I won't get into its details here.
		+
		+	;rpc.nfsd
		+
		+	:This is the user-space daemon that listens on the network for NFS file requests.
		+
		+	;rpc.mountd
		+
		+	:This service maintains the table of which exported file systems are mounted by which clients. It also advertises which exports are available when queried.
		+
		+	;rpc.rquotad
		+
		+	:An optional service for letting clients know there are quota restrictions on the requested file systems.
		+
		+	;exportfs
		+
		+	:The userspace tool that manipulates the kernel's exports table. It can do this either by re-reading the <code>exports</code> file, or by parameters passed on the command line.

	=== /etc/exports ===		=== /etc/exports ===
		+
		+	In this example, the <code>/home</code> directory is exported to the entire subnet. The format of the file is simple, what to export on the left, one or more whitespace characters, and where to allow the export and under what conditions on the right. Multiple destinations can simply be specified separated by spaces. The open parenthesis must not have any preceding whitespace, or it will apply to every other host except those specified left of that space. Multiple options within the parentheses must be separated by commas only.

	<pre>		<pre>
-	/home 192.168.1.0/24(rw~~,root_squash~~)	+	/home 192.168.1.0/24(rw)
	</pre>		</pre>
		+
		+	Here, the <code>rw</code> option is specified because by default, file systems are exported read-only. There are a few other defaults which might catch you by surprise. Top among these is the concept that just because a user gets root access to a client host, does not necessarily mean that user should have root access to the files shared by the server. Therefore, <code>root_squash</code> is on by default. It means that the server will treat any access to files by root on the client as though they came from the nobody user. This security measure is not perfect by any means, since anyone with root access on the client can still become the user who can access whatever files are in question with a simple <code>su</code> command, but it resists accidents and requires that malice be more deliberate. If you actually want the root user to have unlimited power on a share, then export with the <code>no_root_squash</code> option.
		+
		+	Another option you might not expect is that NFS defaults to synchronous file system operations. This is so that writes are always performed before clients disconnect, ensuring file integrity. Use the <code>async</code> option if this becomes an intolerable performance hit.

	== Automounter ==		== Automounter ==

Jeff at 01:08, 25 June 2009

Jeff — Thu, 25 Jun 2009 01:08:43 GMT

New page

== NFS ==

=== /etc/exports ===

<pre>
/home 192.168.1.0/24(rw,root_squash)
</pre>

== Automounter ==

=== /etc/auto.master ===

<pre>
/home /etc/auto.home
</pre>

=== /etc/auto.home ===

<pre>
* -nosuid,nodev,soft,rsize=32768,wsize=32768 server:/home/&
</pre>