A much-overlooked perk of Mac OS X’s BSD underpinnings is the presence of full-fledged support for NFS (network file system) in every shipping version of the operating system. This support serves as the underlying technology for the “Network Domain,” the fourth member of a family of directory hierarchies that also includes the System, Local, and User domains. Within each of these domains, a predictable directory layout allows for the storage of applications, preferences, fonts, etc., in such a way that a properly-written application can transparently make such resources available to the user as a unified whole.
Most users are probably not familiar with the concept of file-system domains at all. Among those who are, it probably boils down to a vague understanding that stuff in /Library is shared, stuff in the home directory is private, and stuff in /System should not be modified. The mysterious /Network directory is occasionally used to sluggishly locate shared directories from other computers on the LAN (local area network), but is rarely configured to fulfill its complete potential as the Network domain.
A FastScripts user recently contacted me. He works in a newspaper office, and is curious about whether there is any facility in FastScripts for sharing a directory of scripts to his entire team. Frustratingly, I have to tell users like this one that there is support for just such a setup – the network domain – but that setting it up is about the most convoluted Mac OS X task imaginable. It’s so beyond the scope of what any average user should be asked to do, that I’m tempted to implement a custom inter-computer sharing system, just so I can offer my customers a “do it for me” switch. Apple’s advice? “Implementation of the network domain is the responsibility of the network administrator.”
But the network domain is an awesome idea! So it looks like you get to be the network administrator. By setting it up correctly you gain a centralized share for all users of a LAN that benefits not only FastScripts, but any other application that correctly iterates the four domains for supporting files! For this reason, it’s worth knowing how to set up, and worth pressuring Apple to make the setup easier for everyday users. The remainder of this article details the steps you may take to both publish a shared “Library” folder from one computer and subscribe to it from any number of other computers on your LAN.
Configuration: A High Level Overview
Before you tackle the task of setting up your network domain Library folder, you should be familiar with some terms used by the technologies on the Mac.
NetInfo is a unique Mac OS X technology inherited from NeXT. NetInfo is a database that manages many of the attributes of a computer and network that would, on more conventional UNIX systems, be managed entirely with text-based configuration files. Among NetInfo’s many responsibilities is the management NFS automount server and client information for particular machines on a network.
NFS is a UNIX technology for exposing shared directories from one system and mounting them to another. Unlike Apple’s legacy AppleShare system, where mounted servers appear functionally identical to mounted disks, NFS volumes can be attached virtually anywhere in the filesystem you desire (this is true for regular disks as well, but is rarely exploited). For instance, if you want to publish your music collection from one computer and have it show up on all other computers at the path “/MyStuff/ObscurePath/Whatever/Music/”, NetInfo can make that happen. The arbitrary location at which you decide to attach the shared directory is called a “mount point.”
A cool feature of NFS is a sort-of lazy loading technique whereby a mount point can remain unconnected until it is actually needed by some application. The technology responsible for this magic is called “automount.” What’s really cool about automounting an NFS shared volume is that it gracefully handles the absence of either the server or the client. So when you wander outside the realm of your LAN, the funky Music mount point described above simply fails to locate the network resource. Instead of starting a 4-alarm fire, you simply get an “empty” directory.
So bringing this all together, how do we employ the underlying technologies such that we achieve our primary goal? We want a shared network domain Library folder, and the way to do that is by publishing an NFS volume that gets subscribed to with an automount mount point at “/Network/Library”.
On the Server: Publish an NFS Volume
First things first, we need to pick a directory on our “server” box and publish that to the LAN via NFS. In NFS terminology this is called an “export,” and the way this is configured on Mac OS X is via a top-level NetInfo directory entry called “exports.” NetInfo can get really complicated and to make things simple I’m just going to show you how you can add a plain-vanilla NFS export for a folder located at “/Library/MyNetworkShares/Library”. The “nicl” command-line utility makes this relatively straightforward:
sudo nicl . -create /exports/\\/Library\\/MyNetworkShares\\/Library opts alldirs maproot=nobody
Note the crazy backslash overload. That’s because we want to get slashes into the actual name of the directory entry in NetInfo. The same task could be accomplished from the NetInfo Manager application, where you can also confirm visually that the configuration has been made as expected:
Once the NetInfo database has been updated, you can either attempt to ensure that all of the required daemons are reset and recognize the new exports settings, or you can just reboot, which should get the NFS startup item to reload and configure everything corectly. By default the NFS server is enabled, and starts at boot time if there are any exports defined.
To confirm the NFS export is set up and your daemon is operational, simply run the showmount command from the command line on the server:
showmount -e
Exports list on localhost:
/Library/MyNetworShares/Library Everyone
Now from another machine (or the same – doesn’t really matter), confirm the ability to actual mount the “volume”. My server machine is identifiable on the local network as “danielG5.local”, so I mount the exported directory on my laptop with:
mkdir /tmp/testmount
mount_nfs danielG5.local:/Library/MyNetworkShares/Library /tmp/testmount
Et voila! /tmp/testmount now looks and acts exactly as the /Library/MyNetworkShares/Library folder on the server.
On the Client: Configure the Network Mount Point
Now that we’ve confirmed the ability to mount the server on a whim, we need to arrange for the client machine to automatically “wire up” to the server whenever the /Network/Library directory is accessed. We do that by configuring a similar NetInfo node to the “exports” item above.
This time, the node resides in “mounts” and serves to inform the automounter about where the network resource is and where it should appear on the local machine. Run the following commands in the terminal, substituting the appropriate computer name for “danielG5.local”:
sudo nicl . -create /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library type nfs
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library dir /Network/Library
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library opts ""
And another visual confirmation from NetInfo Manager puts me at ease:
Again, rebooting is probably the safest way to ensure that the changes are picked up by the automount daemon, but since automount is normally running by default, you should be able to simply restart the daemon:
sudo kill -1 `cat /var/run/automount.pid`
Go ahead and try it out – navigate in the Finder to /Network/Library. You should see the contents of “/Library/MyNetworkShares/Library” from the server computer. I have found the Finder’s concept of /Network to sometimes be a little flakey, so if it doesn’t seem to be working, try changing to the directory from the Terminal instead. I think this kind of thing irons itself out after a reboot. Once you’ve got it wired up, you can start putting junk in the folder that you want to have at your disposal on all machines on the LAN. Fonts, Scripts, etc. If an application doesn’t behave as you expect it to with the Network domain, let the application’s author know (in fact, FastScripts could benefit from a few tweaks to improve its functionality, though it basically works). This is a powerful and very cool infrastructure that more of us should be taking advantage of.
Simplifying the Process
If repeating this process on all the clients in your LAN sounds daunting, fear not. A real network administrator would probably have some kind of sophisticated NetInfo hierarchy through which she could easily manipulate the “mounts” values for all of the machines in the network, but I’m going to assume you’re like me and are just hacking together a solution for a few machines in your house. We can use the “nidump” and “niload” commands to essentially copy and paste the successful settings from one client to another. First, obtain a raw text format copy of the mounts data:
nidump -r /mounts . > MyEasyMounts.txt
Now take that text file to whatever client you like, and load it into that client’s NetInfo database:
sudo niload -m -r /mounts . < MyEasyMounts.txt
Don’t forget to either reboot or confidently reset the automount daemon again.
The process described above can be repeated for other top-level Network domain folders like “Applications.” Just make a different folder on the server and add appropriate exports and mounts entries to the server and clients. Have fun, and enjoy your Network domain!
