the bytes

Edit:

Please see the information I posted in the comments below before enabling the autofs feature on a mobile OSX device.

 

Background

Both at home and works(s), I use nfs for sharing directories, a lot.  I choose nfs a couple reasons:  1)  every Linux/UNIX supports it (and even Windows *can*) and 2) it’s easy to set up.  Sure, it has it’s problems, but so does every other way of sharing files.   If your environment is sane and you know the limitations, nfs can be configured in a few minutes and works very reliably.

There’s a very handy tool called autofs that works well with nfs.  It’s an automounter, but not like the ones most folks are familiar with.  Forget making your usb stick or cd/dvd magically accessible, although it can do that too, autofs can mount essentially anything on demand/access, including network shares.  In my case, I use it with nfs so when I access directories, nfs mounts attach and are ready for use.  After an idle period (no applications using the shares/devices and no shells open in the), autofs also unmounts them, too, eliminating the mess caused by forgetting to unmount your shares or devices.

Recently, I acquired a Macbook Pro running Snow Leopard (OS X 10.6).  It’s a nice addition to my hardware collection and connects easily to TV or stereo (DVI -> hdmi cable and 1/8″ audio -> RCA input cable, respectively).  Only my Atrix has been as easy to connect to them, but using the macbook, I can get anything on the screen without using accessories.

My desktop has quite a few disks of storage in it, and a lot of it has backups, videos, or audio files that I already use on other networked computers here, so naturally I’d like to include the mac in the group of systems I share my data with.  NFS shares to subnets or specific IPs, so I first created a Location (in Network Preferences) that sets a static IP when connecting to my home wireless network, giving me a specific target IP to share the directories to.

 

Exporting NFS Shares

The Linux side of nfs version 3 sharing is easy to configure.  Edit /etc/exports and start up the nfs deamon.  I’m going to show three shares here and how to export and then automatically mount them on the macbook.  In the following output, three directories are shared to one IP address and they are shared with read/write access, asynchronous writes (faster), and with squashing root on the client end.  I write them as ip/subnet to show that CIDR notation can be used when sharing over nfs.

# cat /etc/exports

/mnt/desktop/video    192.168.1.40/32(rw,root_squash,async)
/mnt/desktop             192.168.1.40/32(rw,root_squash,async)
/mnt/image                192.168.1.40/32(rw,root_squash,async)

Configuring OS X automounter

Because I want my shares to automatically mount on access on the mac, I am not going to configure the nfs mounts using fstab or Disk Utility -> File -> NFS Mounts to define them.  I’m going to use the automounter files that are part of the OS X base install.  The main automounter file on OS X is found at /private/etc/auto_master or can be referenced by the /etc/auto_master name, too, and contains a lot of entries that very few people use. I started by commenting out all the entries except /-, which is something that I don’t know is used or not:

#
# Automounter master map
#
#+auto_master                # Use directory service
#/net                                 -hosts                -nobrowse,hidefromfinder,nosuid
#/home                               auto_home        -nobrowse,hidefromfinder
#/Network/Servers               -fstab
/-                                       -static

Now I add a line where I can define the shares from my desktop/server system, named daemon.  The first column shows a mount point that will automatically be created by the automounter.    The second column tells it to parse a file named auto.daemon.  I named the file after the system its defining mounts from and used a dot in the filename rather than the mac way of using an underscore:

/daemon                 auto.daemon

The next step is to create the file that defines the individual shares exported from the nfs server.   I added an entry in /etc/hosts, which is on a different firewalled subnet but reachable through a static route on my gateway, so I could reference the server by hostname:

### Added to make automounter use hostnames instead of IP’s
192.168.11.2    daemon

For the auto.daemon file, three things need defined in a specific order: mount name, mount options, and path to the nfs share on the network.  Mount options can be omitted if a default set works, but I am specifying them here.  Also, I have three shares exported, but I can use two entries in auto.daemon to define them because I am using wildcards , which I’ll explain later:

#cat /etc/auto.daemon
video     -rw,soft,resvport,rsize=32768,wsize=32768        daemon:/mnt/desktop/video
*           -rw,soft,resvport,rsize=32768,wsize=32768      daemon:/mnt/&

First I’ll explain the mount options.  I am mounting the shares read/write and using soft mounts.  Soft mounts will timeout and return an error if the server is not reachable; the alternative to soft is hard mounting, which will wait forever for the server to come online unless a timeout value is given.  The resvport option specifies that the server is running the nfs server on a privileged port, one below 1024.  By default, OS X tries to reach nfs servers on higher port numbers, which would require the “insecure” option to be added to my /etc/exportfs options for each share listed above.  The rsize and wsize values set chunk size for nfs reads and writes, respectively.

The third column of the output is the nfs path.  Since I created an entry for daemon in /etc/hosts, I can use daemon:/<path to share>, which for video is the exported daemon:/mnt/desktop/video directory.  I’ll discuss the second path containing the & in a moment.

The first column in the output above lists the mount points for shares.  The mount points will be created on access and be found inside of the /demon directory that automounter creates.  The first entry, video will allow me to access /daemon/video, which will show the contents of daemon:/mnt/desktop/video.  On the Mac, software will see this no different than a local directory.

The second line of the auto.daemon output above uses wildcards in two places, for both the mount points and for the nfs path.  The asterisk (*) at the beginning simply catches any entry under /daemon that is not explicitly defined before the wildcard line.  So, for example, I can cd /daemon/desktop or /daemon/image without having lines for each of them.  The ampersand (&) at the end of the line in the nfs path appends the value of the asterick to the nfs path.  Thus, cd /mnt/image expands to daemon:/mnt/image.

The asterisk and ampersand entries have some limitations, though.  First, the share path is required to be exported.  My server may have a /mnt/usbstick directory, but cd /daemon/usbstick will fail if /mnt/usbstick is a mount point or directory that is not listed in /etc/exports on daemon.  Second, shares expanded with wildcards must reside at the same absolute paths on the host exporting them.  So, for example, if the host is exporting /usbstick, a /mnt/usbstick -> /usbstick symlink on the server will not let me cd /daemon/usbstick on my client; bind mounting directories would, however work.  Third, a wildcard mount point must be the last entry of the automounter map file.  Since the file is parsed top down with first to match logic, if the wildcard line is first, no other lines will be used.

After editing auto_master and/or any map files for mounts, the automounter needs to be restarted.  The mountpoints I defined, both /daemon and those I explictly specified in auto.daemon will then show:

#automount -vc
automount: /daemon updated
automount: no unmounts

#ls /daemon

video

The Results

To show the ease and speed of NFS, I’ll issue a couple commands just I would normally use.  The setup here is this:  the macbook is connected to a linksys running DD-WRT.  The server (daemon) is connected to another system over 100 MB ethernet, and that system also connects to the DD-WRT router over wireless.  Traffic from the laptop to the server thus follow this path:

laptop -> DD-WRT -> static routing rule -> wireless connection -> iptables on middle man -> iptables on daemon

Run as root (sudo su -) on the mac

#mount |grep daemon

map auto.daemon on /daemon (autofs, automounted, nobrowse)

This shows that the automounter has /daemon running, but there are no submounts active inside the /daemon stub.

#time ls /daemon/video

<directory listing of 73 entries omitted>

real    0m0.293s
user    0m0.006s
sys     0m0.011s

To show ls was the slow part and not the mounting:

#umount /daemon/video

#time cd /daemon/video

real    0m0.058s
user    0m0.000s
sys     0m0.000s

Finally, lets remove the time it took to cd and get a time for just the nfs mounting:

#cd /

#umount /daemon/video

#mkdir /video

#time mount -t nfs -o resvport,soft,rsize=32768,wsize=32768 daemon:/mnt/desktop/video /video

real    0m0.043s
user    0m0.001s
sys     0m0.006s

I’d like to take a look at what I will use.  For reference, I’m Ted, and I’m a Linux systems guy and I don’t code much other than scripting.  Whether you call me an admin or engineer doesn’t matter, I made things work together and I made Linux run well, whether it be big or small.  Using Linux is a certainty for me; once the choice is made, the next step is looking into Linux to see what’s of use (or useable) there.

One solid requirement is a package manager that works.  There has been much debate about the “best” approach to installing software and most distributions have the ability to use different formats of package files.  Hurray for getting some interoperability between distributions!  Overall, many distributions seem to generally handle packages and system changes alright, but in case of any glitch there can be major issues that result in total breakage.  Since I consider stability important, a total system crash is unacceptable unless something very bad happened, i.e. disk or other hardware problem or important disk commits were interrupted.  Ideally, an easy way to repair problems should always be offered, but you’ll see this isn’t the case, just read on.

I tried out Ubuntu the other day on a work desktop, a 64 bit Optiplex with 3 GB of memory and a dual head but nothing-special ATI card.  I was going to use the distribution because it is what an IT manager had available for install, so I gave it a try.  It was one version out of date so after the install, it suggested I upgrade, which I was okay with. After giving the go ahead, I was shown that on a rather fast connection, the process would  take over four hours and decided it would be better to use my computer at least part of  the day since it was my first day on site; I’d run the upgrade overnight.  I killed the  process after it started  downloading, but surely not after enough to have really done anything to the system.  Things stopped working, so I rebooted and voila, no longer did the login manager work.  I was presented with no options and a broken GDM login manager.

Could I have fixed it using a virtual terminal?  Yes, but how is that even needed on a Linux made for desktops since a normal user wouldn’t want to control-alt-f1, login, sudo apt-get anything?  Before anyone comments on that to themselves, consider the newest or least technical Linux user you’ve ever met, then ask yourself what would they at that point do?

Canceling the process may be unusual and unpredicted, but so are power outages.  To the system, the power could have been cut or a child or pet could have bumped the system. It doesn’t know I killed it, so it wasn’t punishing me for breaking “the process” because it doesn’t know I did anything wrong.  It also never warned me not to interrupt the process and never said it was changing the installed system: it said it was downloading files, and it was only perhaps 30 seconds into a process it said would take 4+ hours, or .2% complete.  That one fifth of one percent was enough to fail the distribution for me based on lack of communication and inability to effectively handle an interruption of process; and the failure is heavily underscored by the fact the distribution is so commonly recommended to new users.  New users cannot fix distribution failures and experienced users should not be expected to tolerate them.

Let’s return to focus now.  What will I use to manage the distribution packages on my desktop?  Something besides the Ubuntu label and their affiliated single click auto-magic process.

After wondering how difficult it would be to configure my own web server that could also handle mail, I decided to start a small project at home involving my desktop. I wanted to see if I could replicate the servers that I currently use to host this site, but on a much smaller scale in terms of hardware. Until now, I didn’t realize how simple it was to actually configure a server with apache, mysql, php, and roundcube (for webmail).

This post will cover how I configured my Arch linux desktop to function as a web server and webmail server. Arch linux has provided a detailed guide that was used and helped out greatly. Although it proved a great help, this post is a summary of it and a few other miscellaneous articles.

The basic requirements for a linux box to function as a web server are apache, sql and php.  In Arch linux, you can install the required packages using the following command:

Next, you will need to configure a couple of things. (Most of the packages come pre-configured, however, you will just need to verify the configuration.)  First, you need to make sure that your ‘HOSTNAME’ configurations match in both /etc/rc.conf and /etc/hosts.

Next, you will need to comment the following line in /etc/httpd/conf/httpd.conf (should be around line 91).

At the end of the LoadModule section (around line 121) add the following:

and add this line to the end of the Include section (around line 473):

This will get the basic functions in place to start your Apache server running PHP. This is in no way a secure setup, and you will need to make any additional changes to your httpd.conf and other security files to make your system more secure. To test your install, first start your services with:

# /etc/rc.d/httpd start

and then you need to make a simple index.php file in ‘/srv/http/’ and point your browser to http://localhost/.

A good example for a PHP page is the following:

The Next section will cover mysql, myphpadmin and roundcube webmail server setup.