Leopard and NIS and NFS

April 2008

Our Situation

I work at a research facility that does astrophysical research. Our users are scientists engaged in various research projects. Much of the software they use is developed within the community, and often the software is dedicated to individual projects. It's almost entirely Unix-based software, so, we're primarily a Solaris and Linux shop.

We still use NIS for our use authentication, and for distributing sun-style automount maps for NFS-mounted filesystems. Without getting into debates, we primarily still use NIS because we've dodged the bullet with respect to PC integration. We don't have to support single-sign-on for the PCs we have, and we don't have to export most of our filesystems to them. So, NIS still servers our needs.

NIS can also be perfectly secure, when used properly with firewalls, and securenets. It also helps to add in the Sun's c2 security on the NIS maps, which is a process we're working on now.

Mac laptops have been the preferred laptops amoung our users for some time now. All of the scientist's software can be ported and run on the macs. They generally have the horsepower the scientists need. The operating system is well-supported and does not have the sometimes complex support and configuration issues of Linux. It's also easier to use - while all of our scientists use Unix, many of them would prefer to learn as little as possible about the computer, and spend more time on astrophysics.

These laptops are typically self-supported by the users, and are not allowed access to the secure, NIS portion of our network. However, as more users become familiar with Macs, they are interested in using them as their desktop machines. Macs are as powerful, and arguably more powerful than Linux-based choices. The OS matches what they are used to on their laptops, and all the software has been ported.

We also have one group that has chosen Macs as their primary platform for software development, in support of the Hinode solar satelite.

In short, we are seeing a growing need to treat OS X systems as if they are traditional Unix-login desktops.

Tiger

Our process began with Tiger. Tiger would in theory work with NIS, however we ran into several problems. Tiger didn't support the sun-style automount maps. We worked on several methods to automout our maps.

Using scripts to convert our NIS maps into local automount maps in the default format. This worked more or less. But there was no clean way to make the automounter notice changes. A reboot worked, of course, but that wasn't fun. Killing and restarting the automounter seemed to work, but had problems.
Set up an fstab-style NIS map called mounts.byname. Tiger automount does support one NIS map for automounting. But it was a ridiculously large map when all of our other maps were combined into this one. And changes in the NIS map were apparently never noticed. And, it seemed generally buggy and unreliable.
am-utils' amd software. This is what we ended up using. amd would directly use our NIS maps, without changes. It generally worked ok. It was more configuration and setup than we would have liked. You end up with icons for your mount points, but I was never able to make these things browsable.

Throughout all of these solutions, we found the Finder to be very buggy with respect to automounted filesystems. You couldn't reliably click through a mount point to get a mount (in some of the above methods, this was simply impossible). And when an automounted directory was unmounted, this really left Finder in a very confused state.

Leopard

Leopard replaces it's old automount software with autofs. This is perfect for us. Autofs is the same system solaris uses. It understands all the same NIS maps that we're already using, with no changes. Indeed, we found that as soon as NIS was turned on with these systems, the immediately began automounting using our NIS maps. There was much rejoicing.

But this road has not been without bumps.

As soon as we also turned on NIS authentication, our Finder began crashing. After much work, we traced this down to the fact that one of our automount maps was attempting to mount under /network. It turns out this conflicts with the Mac's /Network (duh). Fortunately for us, this was a vestigial map, no longer used. It's unclear why the crashing only occurred when NIS authentication was used, as the conflict should occur in either case. But the solution was straightforward.

Another bump in the road came with our desire to switch to sun's c2-secure NIS maps. This system puts the password information into a different map called "passwd.adjunct". The map is only accessible from reserved ports, which means only root (on a trusted subnet) can read this map.

Unfortunately, neither Tiger nor Leopard seemed to support this map. But after reviewing Leopard source code, there was support there for a NIS map named shadow.byname. So I duplicated the secure NIS map passwd.adjunt as shadow.byname, and Leopard picked it up immediately and used it. Unfortunately Tiger also does not support this map. We will have to run a temporary NIS domain only for Tiger systems, and work to upgrade all of our Tiger systems to Leopard. We can live with this since it is only temporary.

The third problem we ran into was with bugs in Mac's autofs. We use replicated servers -- that is, some of our filesystems are available from more than one server. But whenever we attempted to mount one of these filesystems, the mount attempt would hang for two minutes and then fail.

Because autofs is part of Darwin open sources, we reviewed the code, and found that autofs had support for this, but it simply had bugs. We've been able to fix these bugs and build a working autofs (specifically automountd) with Xcode.

Finder

Finder in Leopard continues to have problems. With autofs, you do not get (or even have the option of getting) browsable icons for the mount point of each automount map. That would be nice, but it's a minor detail. The more major problem is that after going to one of those mount points by hand (command-shift-g), you can see a nice list of mountable directories (yay!), but when you click on them they don't mount; instead you get an error message. Actually they do mount, but Finder doesn't notice right away. If you click on them again, then sometimes you get the contents. But sometimes you don't, especially after they've been unmounted due to timeout.

In the PC and Mac world, the existence of hardware has always been part of the normal expectation. If the user has a hard drive they'll know about it, and look for it in a directory full of mounted volumes. If they are looking for a network drive, they'll look through network volumes and mount it.

This is an antiquated model. The superior model used by unix systems for years is that you can mount anything anywhere you like, and the user doesn't really need to know when they go from one piece of storage to the next. /foo might be on the system drive, /foo/bar is on an external drive, and /foo/bar/baz is on another computer entirely. Automounting takes care of everything, and the user doesn't care where anything lives, and doesn't have to "mount" anything. Of course, the old model can still exist in this newer more powerful structure. If they stick in a thumbdrive, it should naturally appear in their Volumes directory. But if their system administrator wants to have them all mount their Applications directories from a central server, in a seamless and invisible way for the user, that should work too.

This is what the people at Apple don't seem to get. They really had to go out of their way to break the Finder with respect to automounted directories. I mean, as soon as you try to look for a file, the kernel mounts it for you. If the Finder sat properly on top of the operating system's filesystem semantics, it would work fine. The Finder shouldn't even have to know about mountpoints.

For us, fixing the Finder's antiquated notions about mounting things is the last piece that needs to be fixed before OS X can be casually tossed into a traditional UNIX NIS environment.

Fine's Home

Send Me Email