To configure the NFS server, you must first create a directory hierarchy to hold Apache configurations for all of your different web servers, since it’s hubris to assume they’re all configured identically. There are numerous ways to organize the hierarchy. You could try to emulate the native filesystem as closely as possible, using symlinks to get it all perfect. You could also create a tree for each web server to hold its configuration, so that when you add another web server you can just add another directory on the NFS server for its configuration. I’ve found the latter method to be a bit less taxing on the brain.

The first thing to do on the NFS server is to create the space where this information will live. Let’s say your servers are numbered web1 through web5. Here’s an example of what the directory structure might look like:

	/servconf
		mail/
		common/
		web/ 
	web1/
		conf/
			httpd.conf
			access.conf
			modules.conf
		conf.d/
			php4.conf
	web2/
		conf/
			httpd.conf
			access.conf
			modules.conf
		conf.d/
			php4.conf
			python.conf
			mod_auth_mysql.conf

This sample hierarchy illustrates a few interesting points. First, notice the directories mail/ and common/. As these show, the configuration tree doesn’t need to be limited to a single service. In fact, it doesn’t actually have to be service-specific at all! For example, the common/ tree can hold configuration files for things like global shell initialization files that you want to be constant on all production service machines (you want this, believe me) and the OpenSSH server configuration file, which ensures that the ssh daemon acts the same way on each machine.

That last sentence brings up another potential benefit of centralized configuration: if you want to make global changes to something like the ssh daemon, you can make the changes in one place instead of many, since all of the ssh daemons will be looking at the centralized configuration file. Once a change is made, the daemons will need to be restarted or sent a SIGHUP to pick up the change. “Execute Commands Simultaneously on Multiple Servers” [Hack #29] ) shows a method that will alow you to do this on multiple servers quickly.

All of this is wonderful, and some sites can actually use a hierarchy like this to have a single NFS server provide configuration to all the services in their department or business. However, it’s important to recognize that, depending on how robust your NFS deployment is, you could be setting yourself up with the world’s largest single point of failure. It’s one thing to provide configuration to all your web servers, in which case a failure of the NFS server affects the web servers. It’s quite another to use a single NFS server to provide configuration data to every production service across the board. In this case, if there’s a problem with the file server, you’re pretty much dead in the water, all owing to a glitch in a single machine! It would be smart to either invest in technologies that ensure the availability of the NFS service, or break up the NFS servers to lessen the impact of a failure of any one server.

Now it’s time to export our configuration tree. It’s important to note that some NFS daemons are somewhat “all or nothing” in the sense that they cannot export a subdirectory of an already exported directory. The exception to that rule is if the subdirectory is actually living on a separate physical device on the NFS server. For safety’s sake, I’ve made it a rule never to do this anyway, in the event that changes in the future cause the subdirectory to share a device with its parent. Note that the same rule applies to exporting a subdirectory and then trying to export a parent directory separately.

Some implementations of the nfsd server do allow subdirectory exports, but for the sake of simplicity I avoid this, because it has implications as to the rules applied to a particular exported directory and can make debugging quite nightmarish.

Let’s see how this works. Using the above “best practices,” you cannot export the whole /servconf tree in our example to one server, and then export mail/ separately to the mail servers. You can export each of the directories under /servconf separately if /servconf itself is not exported, but that would make it slightly more work to repurpose a server, because you’d have to make sure permissions were in place to allow the mount of the new configuration tree, and you’d have to make sure the /etc/fstab file on the NFS client was updated—otherwise, a reboot would cause bad things to happen.

It’s easier just to export the entire /servconf tree to a well-defined subset of the machines, so that /etc/fstab never has to be changed and permissions are not an issue from the NFS server side of the equation. That’s what we’ll do here. The file that tells the NFS server who can mount what is almost always /etc/exports. After all this discussion, here’s the single line we need to accomplish the goal of allowing our web servers to mount the /servconf directory:

	/servconf 192.168.198.0/24(ro,root_squash) @trusted(rw,no_root_squash)

The network specified above is a DMZ where my service machines live. Two important things to note here are the options applied to the export. The ro option ensures that changes cannot be made to the configuration of a given machine by logging into the machine itself. This is for the sake of heightened security, to help guarantee that a compromised machine can’t be used to change the configuration files of all the other machines. Also to that end, I’ve explicitly added the root_squash option. This is a default in some NFS implementations, but I always state it explicitly in case that default ever changes (this is generally good practice for all applications, by the way). This option maps UID 0 on the client to nobody on the server, so even root on the client machine cannot make changes to files anywhere under the mount point.

The second group of hosts I’m exporting this mount point to are those listed in an NIS netgroup named trusted. This netgroup consists of two machines that are locked down and isolated such that only administrators can get access to them. I’ve given those hosts read/write (rw) access, which allows administrators to make changes to configuration files from machines other than the NFS server itself. I’ve also specified the no_root_squash option here, so that admins can use these machines even to change configuration files on the central server owned by root.

For the Apache web server example, we can create a very similar hierarchy on our NFS server to store content served up by the servers, and export it in the exact same way we did for the configuration. However, keep in mind that many web sites assume they can write in the directories they own, so you’ll need to make sure that you either export a writable directory for these applications to use, or export the content tree with read/write privileges.

Getting NFS clients working is usually a breeze. You’ll need to decide where you want the local Apache daemon to find its configuration and content, create the mount points for any trees you’ll need to mount, and then edit the /etc/fstab file to make sure that the directory is always mounted at boot time.

Generally, I tend to create the local mount points under the root directory, mainly for the sake of consistency. No matter what server I’m logged in to, I know I can always run ls -l / and see all of the mount points on that server. This is simpler than having to remember what services are running on the machine, then hunting around the filesystem to check that the mount points are all there. Putting them under / means that if I run the mount command to see what is mounted, and something is missing, I can run one command to make sure the mount point exists, which is usually the first step in troubleshooting an NFS-related issue.

I also attempt to name the mount point the same as the exported directory on the server. This makes debugging a bit simpler, because I don’t have to remember that the mount point named webstuff on the client is actually servconf on the server. So, we create a mount point on the NFS client like this:

	# mkdir /servconf

Then we add a line like the following to our /etc/fstab file:

	mynfs:/servconf /servconf nfs ro,intr,nfsvers=3,proto=tcp 0 0

Now we’re assured that the tree will be mounted at boot time. The other important factor to consider is that the tree is mounted before the service that needs the files living there is started. It should be safe to assume that this will just work, but if you’re trying to debug services that seem to be ignoring configuration directives, or that fail to start at all, you’ll want to double check, just in case!

We’ve now mounted our web server configuration data to all of our web servers. Let’s assume for now that you’ve done the same with the content. What we’ve essentially accomplished is a way to have one hot spare machine, which also mounts all of this information, that can take over for any failed web server in the blink of an eye. Two ways to get it to work are to use symlinks or to edit the service’s initialization script.

To use the symlink method, you consult the initialization script for the service. In the case of Apache, the script will most likely be /etc/init.d/apache or /etc/init.d/httpd. This script, like almost all service initialization scripts, will tell you where the daemon will look for its configuration file(s). In my case, it looks under /etc/apache. The next thing to do is to move this directory out of the way and make a symlink to the directory that will take its place. This is done with commands like the following:

	# mv /etc/apache /etc/apache.DIST
	# ln -s /servconf/web/web1 /etc/apache

Now when the service starts up, it will use whichever configuration files are pointed to by the symlink. The critical thing to make sure of here is that the files under the mount point conform to what the initialization script expects. For example, if the initialization script for Apache in this case was looking for /etc/apache/config/httpd.conf, it would fail to start at all, because the /etc/apache directory is now a symlink to a mount point that has put the file under a subdirectory called conf/, not config/. These little “gotchas” are generally few, and are worked out early in the testing phase of any such deployment.

Now, if we want to make our hot spare look like web3 instead of web1, we can simply remove the symlink we had in place, create a new symlink to point to web3’s configuration directory, and restart the service. Note that if all of the web servers mount the content in the same way under the same mount points, you don’t have to change any symlinks for content, since the configuration file in Apache’s case tells the daemon where to find the content, not the initialization script! Here are the commands to change the personality of our hot spare to web3:

	# rm /etc/apache; ln -s /servconf/web/web3 /etc/apache
	# /etc/init.d/apache restart

The commands used to restart Apache can vary depending on the platform. You might run the apachectl program directly, or you might use the service command available on some Linux distributions.

You can’t assume that you’re completely out of the woods just because a server looks and acts like the one it replaces. In the case of Apache, you’ll also want to make sure that your hot spare is actually reachable by clients without them having to change any of their bookmarks. This might involve taking down the failed web server and assigning its IP address to the hot spare or making the DNS record for the failed web server point to the hot spare.

The main amd configuration file is almost always /etc/amd.conf. This file sets up default behaviors for the daemon and defines other configuration files that are authoritative for each configured mount point. Here’s a quick look at a totally untouched configuration file, as supplied with the Fedora Core 4 am-utils package, which supplies the amd automounter:

	[ global ]
	normalize_hostnames =	no
	print_pid =				yes
	pid_file =				/var/run/amd.pid
	restart_mounts =		yes
	auto_dir =				/.automount
	#log_file =				/var/log/amd
	log_file =				syslog	
	log_options =			all
	#debug_options =		all
	plock =				no
	selectors_on_default =	yes
	print_version =			no
	# set map_type to "nis" for NIS maps, or comment it out to search for all
	# types
	map_type =				file
	search_path =			/etc
	browsable_dirs =		yes
	show_statfs_entries =	no
	fully_qualified_hosts = no
	cache_duration =		300

	# DEFINE AN AMD MOUNT POINT
	[ /net ]
	map_name =				amd.net
	map_type =				file

The options in the [global] section specify behaviors of the daemon itself and rarely need changing. You’ll notice that search_path is set to /etc, which means it will look for mount maps under the /etc directory. You’ll also see that auto_dir is set to /.automount. This is where amd will mount the directories you request. Since amd cannot perform mounts “in-place,” directly under the mount point you define, it actually performs all mounts under the auto_dir directory, and then returns a symlink to that directory in response to the incoming mount requests. We’ll explore that more after we look at the configuration for the [/net] mount point.

From looking at the above configuration file, we can tell that the file that tells amd how to mount things under /net is amd.net. Since the search_path option in the [global] section is set to /etc, it’ll really be looking for /etc/amd.net at startup time. Here are the contents of that file:

	/defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=nosuid,nodev
	* rhost:=${key};type:=host;rfs:=/

Eyes glazing over? Well, then let’s translate this into English. The first entry is /defaults, which is there to define the symlink that gets returned in response to requests for directories under [/net] in amd.conf. Here’s a quick tour of the variables being used here:

Also note that fs: on the /defaults line specifies the local location where the remote filesystem is to be mounted. It’s not the name of our remote file server.

In reality, there are a couple of other variables in play behind the scenes that help resolve the values of these variables, but this is enough to discern what’s going on with our automounter. You should now be able to figure out what was really happening in our simple cd command earlier in this hack.

Because of the configuration settings in amd.conf and amd.net, when I ran the cd command earlier, I was actually requesting a mount of fs:/linux/local under the directory /net/fs/linux/local.amd, behind my back, replaced that directory with a symlink to /.automount/fs/root/linux/local, and that’s where I really wound up. Running pwd with no options will say you’re in /net/fs/linux/local, but there’s a quick way to tell where you really are, taking symlinks into account. Look at the output from these two pwd commands:

	$ pwd
	/net/fs/linux/local
	$ pwd -P
	/.automount/root/fs/linux/local

The–P option reveals your true location.

So, now that we have some clue as to how the amd.net /defaults entry works, we need to figure out exactly why our wonderful hack works. After all, we haven’t yet told amd to explicitly mount anything!

Here’s the entry in /etc/amd.net that makes this functionality possible:

	* rhost:=${key};type:=host;rfs:=/

The * wildcard entry says to attempt to mount any requested directory, rather than specifying one explicitly. When you request a mount, the part of the path after /net defines the host and path to mount. If amd is able to perform the mount, it is served up to the user on the client host. The rfs=/ bit means that amd should request whatever directory is requested from the server under the root directory of that server. So, if we set rfs=/mnt and then request /linux/local, the request will be for fs:/mnt/linux/local.

—Lance Tost

Technically, the Samba service consists of two daemons, smbd and nmbd. The smbd daemon is the one that handles the SMB file- and print-sharing protocol. When a client requests a shared directory from the server, it’s talking to smbd. The nmbd daemon is in charge of answering NetBIOS over IP name service requests. When a Windows client broadcasts to browse Windows shares on the network, nmbd replies to those broadcasts.

The configuration file for the Samba service is /etc/samba/smb.conf on both Debian and Red Hat systems. If you have a tool called swat installed, you can use it to help you generate a working configuration without ever opening vi—just uncomment the swat line in /etc/inetd.conf on Debian systems, or edit /etc/xinetd.d/swat on Red Hat and other systems, changing the disable key’s value to no. Once that’s done, restart your inetd or xinetd service, and you should be able to get to swat’s graphical interface by pointing a browser at http://localhost:901.

Many servers are installed without swat, though, and for those systems editing the configuration file works just fine. Let’s go over the config file for a simple setup that gives access to file and printer shares to authenticated users. The file is broken down into sections. The first section, which is always called [global], is the section that tells Samba what its “personality” should be on the network. There are a myriad of possibilities here, since Samba can act as a primary or backup domain controller in a Windows domain, can use various printing subsystem interfaces and various authentication backends, and can provide various different services to clients.

Let’s take a look at a simple [global] section:

	[global]
	   workgroup = PVT
	   server string = apollo
	   hosts allow = 192.168.42. 127.0.0.
	   printcap name = CUPS
	   load printers = yes
	   printing = CUPS
	   logfile = /var/log/samba/log.smbd
	   max log size = 50
	   security = user
	   smb passwd file = /etc/samba/smbpasswd
	   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192	
	   interfaces = eth0
	   wins support = yes
	   dns proxy = no

Much of this is self-explanatory. This excerpt is taken from a working configuration on a private SOHO network, which is evidenced by the hosts allow values. This option can take values in many different formats, and it uses the same syntax as the /etc/hosts.allow and /etc/hosts.deny files (see hosts_access(8) and “Allow or Deny Access by IP Address” [Hack #64] ). Here, it allows access from the local host and any host whose IP address matches the pattern 192.168.42.*. Note that a netmask is not given or assumed—it’s a pure regex match on the IP address of the connecting host. Note also that this setting can be removed from the [global] section and placed in each subsection. If it exists in the [global] section, however, it will supersede any settings in other areas of the configuration file.

In this configuration, I’ve opted to use CUPS as the printing mechanism. There’s a CUPS server on the local machine where the Samba server lives, so Samba users will be able to see all the printers that CUPS knows about when they browse the PVT workgroup, and use them (more on this in a minute).

The server string setting determines the server name users will see when the host shows up in a Network Neighborhood listing, or in other SMB network browsing software. I generally set this to the actual hostname of the server if it’s practical, so that if users need to manually request something from the Samba server, they don’t try to ask to mount files from my Linux Samba server by trying to address it as “Samba Server.”

The other important setting here is security. If you’re happy with using the /etc/samba/smbpasswd file for authentication, this setting is fine. There are many other ways to configure authentication, however, so you should definitely read the fine (and copious) Samba documentation to see how it can be integrated with just about any authentication backend. Samba includes native support for LDAP and PAM authentication. There are PAM modules available to sync Unix and Samba passwords, as well as to authenticate to remote SMB servers.

We’re starting with a simple password file in our configuration. Included with the Samba package is a tool called mksmbpasswd.sh, which will add users to the password file en masse so you don’t have to do it by hand. However, it cannot migrate Unix passwords to the file, because the cryptographic algorithm is a one-way hash and the Windows hash sent to Samba by the clients doesn’t match.

To change the Samba password for a user, run the following command on the server:

	# smbpasswd username

This will prompt you for the new password, and then ask you to confirm it by typing it again. If a user ran the command, she’d be prompted for her current Samba password first. If you want to manually add a user to the password file, you can use the -a flag, like this:

	# smbpasswd -a username

This will also prompt for the password that should be assigned to the user.

Now that we have users, let’s see what they have access to by looking at the sections for each share. In our configuration, users can access their home directories, all printers available through the local CUPS server, and a public share for users to dabble in. Let’s look at the home directory configuration first:

	[homes]
	   comment = Home Directories
	   browseable = no
	   writable = yes

The [homes] section, like the [global] section, is recognized by the server as a “special” section. Without any more settings than these few minimal ones, Samba will, by default, take the username given during a client connection and look it up in the local password file. If it exists, and the correct password has been provided, Samba clones the [homes] section on the fly, creating a new share named after the user. Since we didn’t use a path setting, the actual directory that gets served up is the home directory of the user, as supplied by the local Linux system. However, since we’ve set browseable = no, users will only be able to see their own home directories in the list of available shares, rather than those of every other user on the system.

Here’s the printer share section:

	[printers]
	   comment = All Printers
	   path = /var/spool/samba
	   browseable = yes
	   public = yes
	   guest ok = yes
	   writable = no
	   printable = yes
	   use client driver = yes

This section is also a “special” section, which works much like the [homes] special section. It clones the section to create a share for the printer being requested by the user, with the settings specified here. We’ve made printers browseable, so that users know which printers are available. This configuration will let any authenticated user view and print to any printer known to Samba.

Finally, here’s our public space, which anyone can read or write to:

	[tmp]
       comment = Temporary file space
	   path = /tmp
	   read only = no
	   public = yes

This space will show up in a browse listing as “tmp on Apollo,” and it is accessible in read/write mode by anyone authenticated to the server. This is useful in our situation, since users cannot mount and read from each other’s home directories. This space can be mounted by anyone, so it provides a way for users to easily exchange files without, say, gumming up your email server.

Once your smb.conf file is in place, start up your smb service and give it a quick test. You can do this by logging into a Linux client host and using a command like this one:

	$ smbmount '//apollo/jonesy' ~/foo/ -o username=jonesy,workgroup=PVT

This command will mount my home directory on Apollo to ~/foo/ on the local machine. I’ve passed along my username and the workgroup name, and the command will prompt for my password and happily perform the mount. If it doesn’t, check your logfiles for clues as to what went wrong.

You can also log in to a Windows client, and see if your new Samba server shows up in your Network Neighborhood (or My Network Places under Windows XP).

If things don’t go well, another command you can try is smbclient. Run the following command as a normal user:

	$ smbclient -L apollo

On my test machine, the output looks like this:

	Domain=[APOLLO] OS=[Unix] Server=[Samba 3.0.14a-2]
		
		Sharename    Type	  Comment
		---------    ----     -------
		tmp			 Disk	  Temporary file space
		IPC$		 IPC	  IPC Service (Samba Server)
		ADMIN$		 IPC	  IPC Service (Samba Server)
		MP780		 Printer  MP780
		hp4m		 Printer  HP LaserJet 4m
		jonesy		 Disk	  Home Directories
	Domain=[APOLLO] OS=[Unix] Server=[Samba 3.0.14a-2]
		Server		 Comment
		---------	 -------
		
		Workgroup	 Master
		---------	 -------
		PVT			 APOLLO

This list shows the services available to me from the Samba server, and I can also use it to confirm that I’m using the correct workgroup name.

Like all hardware purchases, what you end up with is contingent on your budget. I tend to use inexpensive PCs as the basis for NAS boxes, and I’m completely comfortable with basing NAS solutions on today’s reliable, high-speed EIDE drives. The speed of the disk controller(s), disks, and network interfaces is far more important than the CPU speed. This is not to say that recycling an old 300-MHz Pentium as the core of your NAS solutions is a good idea, but any reasonably modern 1.5-GHz or greater processor is more than sufficient. Most of what the box will be doing is serving data, not playing Doom. Thus, motherboards with built-in graphics are also fine for this purpose, since fast, hi-res graphics are equally unimportant in the NAS environment.

My recipe for a reasonable NAS box is the following:

I can’t really describe the details of assembling the hardware because I don’t know exactly what configuration you’ll end up purchasing, but the key idea is that you put a drive tray in each of the external bays, with one of the IDE/ATA drives in each, and put the SATA drive in an internal drive bay. This means that you’ll still have to open up the box to replace the system disk if it ever fails, but it enables you to maximize the storage that this system makes available to users, which is its whole reason for being. Putting the EIDE/ATA disks in drive trays means that you can easily replace a failed drive without taking down the system if the trays are hot-swappable. Even if they’re not, you can bounce a system pretty quickly if all you have to do is swap in another drive and you already have a spare tray available.

At the time I wrote this the hardware setup cost me around $1000 (exclusive of the backup hard drives) with some clever shopping, thanks to http://www.pricewatch.com. This got me a four-bay case; a motherboard with onboard GigE, SATA, and USB; four 300-GB drives with 16-MB buffers; hot-swappable drive racks; and a few extra cooling fans.

As I’ve always told everyone (regardless of whether they ask), I always install everything, regardless of which Linux distribution I’m using. I personally prefer SUSE for commercial deployments, because it’s supported, you can get regular updates, and I’ve always found it to be an up-to-date distribution in terms of supporting the latest hardware and providing the latest kernel tweaks. Your mileage may vary. I’m still mad at Red Hat for abandoning everyone on the desktop, and I don’t like GNOME (though I install it “because it’s there” and because I need its libraries to run Evolution, which is my mailer of choice due to its ability to interact with Microsoft Exchange). Installing everything is easy. We’re building a NAS box here, not a desktop system, so 80% of what I install will probably never be used, but I hate to find that some tool I’d like to use isn’t installed.

To install the Linux distribution of your choice, attach the external CD/DVD drive to your machine and configure the BIOS to boot from it first and the SATA drive second. Put your installation media in the external CD/DVD drive and boot the system. Install Linux on the internal SATA drive. As discussed in “Reduce Restart Times with Journaling Filesystems” [Hack #70] , I use ext3 for the /boot and / partitions on my systems so that I can easily repair them if anything ever goes wrong, and because every Linux distribution and rescue disk in the known universe can handle ext2/ext3 partitions. There are simply more ext2/ext3 tools out there than there are for any other filesystem. You don’t have to partition or format the drives in the bays—we’ll do that after the operating system is installed and booting.

Done installing Linux? Let’s add and configure some storage.

Determining how you want to partition and allocate your disk drives is one of the key decisions you’ll need to make, because it affects both how much space your new NAS box will be able to deliver to users and how maintainable your system will be. To build a reliable NAS box, I use Linux software RAID to mirror the master on the primary IDE interface to the master on the secondary IDE interface and the slave on the primary IDE interface to the slave on the secondary IDE interface. I put them in the case in the following order (from the top down): master primary, slave primary, master secondary, and slave secondary. Having a consistent, specific order makes it easy to know which is which since the drive letter assignments will be a, b, c, and d from the top down, and also makes it easy to know in advance how to jumper any new drive that I’m swapping in without having to check.

By default, I then set up Linux software RAID and LVM so that the two drives on the primary IDE interface are in a logical volume group [Hack #47] .

On systems with 300-GB disks, this gives me 600 GB of reliable, mirrored storage to provide to users. If you’re less nervous than I am, you can skip the RAID step and just use LVM to deliver all 1.2 TB to your users, but backing that up will be a nightmare, and if any of the drives ever fail, you’ll have 1.2 TB worth of angry, unproductive users. If you need 1.2 TB of storage, I’d strongly suggest that you spend the extra $1000 to build a second one of the boxes described in this hack. Mirroring is your friend, and it doesn’t get much more stable than mirroring a pair of drives to two identical drives.

The next step is to decide how you want to partition the logical storage. This depends on the type of users you’ll be delivering this storage to. If you need to provide storage to both Windows and Linux users, I suggest creating separate partitions for SMB and NFS users. The access patterns for the two classes of users and the different protocols used for the two types of networked filesystems are different enough that it’s not a good idea to export a filesystem via NFS and have other people accessing it via SMB. With separate partitions they’re still both coming to the same box, but at least the disk and operating system can cache reads and handle writes appropriately and separately for each type of filesystem.

Getting insights into the usage patterns of your users can help you decide what type of filesystem you want to use on each of the exported filesystems [Hack #70] . I’m a big ext3 fan because so many utilities are available for correcting problems with ext2/ext3 filesystems.

Regardless of the type of filesystem you select, you’ll want to mount it using noatime to minimize file and filesystem updates due to access times. Creation time (ctime) and modification time (mtime) are important, but I’ve never cared much about access time and it can cause a big performance hit in a shared, networked filesystem. Here’s a sample entry from /etc/fstab that includes the noatime mount option:

	/dev/data/music   /mnt/music   xfs   defaults,noatime   0 0

Similarly, since many users will share the filesystems in your system, you’ll want to create the filesystem with a relatively large log. For ext3 filesystems, the size of the journal is always at least 1,024 filesystem blocks, but larger logs can be useful for performance reasons on heavily used systems. I typically use a log of 64 MB on NAS boxes, because that seems to give the best tradeoff between caching filesystem updates and the effects of occasionally flushing the logs. If you are using ext3, you can also specify the journal flush/sync interval using the commit=number-of-seconds mount option. Higher values help performance, and anywhere between 15 and 30 seconds is a reasonable value on a heavily used NAS box (the default value is 5 seconds). Here’s how you would specify this option in /etc/fstab:

	/dev/data/writing	/mnt/writing	ext3	defaults, cls, commit=15 0 0

A final consideration is how to back up all this shiny new storage. I generally let the RAID subsystem do my backups for me by shutting down the systems weekly, swapping out the mirrored drives with a spare pair, and letting the RAID system rebuild the mirrors automatically when the system comes back up. Disk backups are cheaper and less time-consuming than tape [Hack #50] , and letting RAID mirror the drives for you saves you the manual copy step discussed in that hack.

Fine-tuning the services running on the soon-to-be NAS box is an important step. Turn off any services you don’t need [Hack #63] . The core services you will need are an NFS server, a Samba server, a distributed authentication mechanism, and NTP. It’s always a good idea to run an NTP server [Hack #22] on networked storage systems to keep the NAS box’s clock in sync with the rest of your environment—otherwise, you can get some weird behavior from programs such as make.

You should also configure the system to boot in a non-graphical runlevel, which is usually runlevel 3 unless you’re a Debian fan. I also typically install Fluxbox [Hack #73] on my NAS boxes and configure X to automatically start that rather than a desktop environment such as GNOME or KDE. Why waste cycles?

“Centralize Resources Using NFS” [Hack #56] explained setting up NFS and “Share Files Across Platforms Using Samba” [Hack #60] shows the same for Samba. If you don’t have Windows users, you have my congratulations, and you don’t have to worry about Samba.

The last step involved in configuring your system is to select the appropriate authentication mechanism so that you have the same users on the NAS box as you do on your desktop systems. This is completely dependent on the authentication mechanism used in your environment in general. Chapter 1 of this book discusses a variety of available authentication mechanisms and how to set them up. If you’re working in an environment with heavy dependencies on Windows for infrastructure such as Exchange (shudder!), it’s often best to bite the bullet and configure the NAS box to use Windows authentication. The critical point for NAS storage is that your NAS box must share the same UIDs, users, and groups as your desktop systems, or you’re going to have problems with users using the new storage provided by the NAS box. One round of authentication problems is generally enough for any sysadmin to fall in love with a distributed authentication mechanism—which one you choose depends on how your computing environment has been set up in general and what types of machines it contains.

The final step in building your NAS box is to actually make it available to your users. This involves creating some number of directories for the users and groups who will be accessing the new storage. For Linux users and groups who are focused on NFS, you can create top-level directories for each user and automatically mount them for your users using the NFS automounter and a similar technique to that explained in [Hack #57] , wherein you automount your users’ NAS directories as dedicated subdirectories somewhere in their accounts. For Windows users who are focused on Samba, you can do the same thing by setting up an [NAS] section in the Samba server configuration file on your NAS box and exporting your users’ directories as a named NAS share.

Building and deploying your own NAS storage isn’t really hard, and it can save you a significant amount of money over buying an off-the-shelf NAS box. Building your own NAS systems also helps you understand how they’re organized, which simplifies maintenance, repairs, backups, and even the occasional but inevitable replacement of failed components. Try it—you’ll like it!

WebDAV support in Apache is made possible by the mod_dav module. Servers running Apache 2.x will already have mod_dav included in the package apache2-common, so you should only need to make a simple change to your Apache configuration in order to run mod_dav. If you compiled your own version of Apache, make sure that you compiled it with the–enable -dav option to enable and integrate WebDAV support.

If WebDAV support wasn’t statically linked into your version of Apache2, you’ll need to load the modules that provide WebDAV support. To load the Apache2 modules for WebDAV, do the following:

	# cd /etc/apache2/mods-enabled/
	# ln -s /etc/apache2/mods-available/dav.load dav.load
	# ln -s /etc/apache2/mods-available/dav_fs.load dav_fs.load
	# ln -s /etc/apache2/mods-available/dav_fs.conf dav_fs.conf

Next, add these two commands to your httpd.conf file to set variables used by Apache’s WebDAV support:

	DAVLockDB /tmp/DAVLock
	DAVMinTimeout 600!

These can be added anywhere in the top level of your httpd.conf file—in other words, anywhere that is not specific to the definition of a single directory or server. The DAVLockDB statement identifies the directory where locks should be stored. This directory must exist and should be owned by the Apache service account’s user and group. The DAVMinTimeout variable specifies the period of time after which a lock will automatically be released.

Next, you’ll need to create a WebDAV root directory. Users will have their own subdirectories beneath this one, so it’s a bit like an alternative /home directory. This directory must be readable and writable by the Apache service account. On most distributions, this user will probably be called apache or www-data. You can check this by searching for the Apache process in ps using one of the following commands:

	# ps -ef | grep apache2
	# ps -ef | grep httpd

A good location for the WebDAV root is at the same level as your Apache document root. Apache’s document root is usually at /var/www/apache2-default (or, on some systems, /var/www/html). I tend to use /var/www/webdav as a standard WebDAV root on my systems.

Create this directory and give read and write access to the Apache service account (apache, www-data, or whatever other name is used on your systems):

	# mkdir /var/www/webdav
	# chown root:www-data /var/www/webdav
	# chmod 750 /var/www/webdav

Now that you’ve created your directory, you’ll need to enable it for WebDAV in Apache. This is done with a simple Dav On directive, which can be located inside a directory definition anywhere in your Apache configuration file (httpd.conf):

	<Directory /var/www/webdav>
	Dav On
	</Directory>

If you simply activate WebDAV on a directory, any user can access and modify the files in that directory through a web browser. While a complete absence of security is convenient, it is not “the right thing” in any modern computing environment. You will therefore want to apply the standard Apache techniques for specifying the authentication requirements for a given directory in order to properly protect files stored in WebDAV.

As an example, to set up simple password authentication you can use the htpasswd command to create a password file and set up an initial user, whom we’ll call joe:

	# mkdir /etc/apache2/passwd
	# htpasswd -c /etc/apache2/passwd/htpass.dav joe

The htpasswd command will prompt you once for joe’s new WebDAV password, and then again for confirmation. Once you’ve specified the password, you should set the permissions on your new password file so that it can’t be read by standard users but is readable by any member of the Apache service account group:

	# chown root:www-data /etc/apache2/passwd/htpass.dav
	# chmod 640 /etc/apache2/passwd/htpass.dav

Next, the sample user joe will need a WebDAV directory of his own, with the right permissions set:

	# mkdir /var/www/webdav/joe
	# chown www-data:www-data /var/www/webdav/joe
	# chmod 750 /var/www/webdav/joe

The sample user will also need to use the password file that you just created with htpasswd to authenticate access to his directory, so you’ll have to update httpd.conf with another directive for that directory:

	<Directory /var/www/webdav/joe/>
		 require user joe
	</Directory>

Now just restart your Apache server, and you’re done with the Apache side of things:

	# /usr/sbin/apache2ctl restart

At this point, you should be able to connect to your web server and access files in /var/www/webdav/joe as the user joe from any WebDAV-enabled application.