Wandering Thoughts archives

How Solaris matches names in NFS exports

Recently, I accidentally found out which of two options Solaris uses for matching names in NFS exports. As traditional, I did this by stubbing my toe.

Given a name in an /etc/dfs/sharetab line, there are two possible ways of checking if it matches an incoming NFS request: you could resolve the sharetab name to its IP addresses and see if the request's IP address matched, or you could take the request's IP address and try to turn it into a hostname and see if the resolved hostname is the same. There are good reasons and complexities in both approaches, and I've run into software that does name checks both ways.

(And when I wrote software that did tcpwrappers-style permissions checks I put in options to do both sorts of verification, which came in handy more than once.)

It turns out that Solaris does sharetab name checks by resolving incoming IP addresses to names (now that I look carefully at the share_nfs(1M) manpage, this is more or less implied by the phrasing of some stuff).

I discovered this by adding DNS name resolution to a system that was NFS-exporting filesystems using a sharetab something like this:

/data - nfs ro=backup,root=backup

When I added DNS name resolution to /etc/nsswitch.conf, I followed the example in the nsswitch.dns file and put 'dns' before 'files' in the hosts: entry. The NFS mount the backup server was trying to do promptly broke. While the short name 'backup' was the name of the IP address in /etc/hosts, the system was now using DNS first, and DNS said that the name of the IP address was actually 'backup.mumble.utoronto.ca'.

(I can be sure it was doing the IP to name check because a DNS lookup was happy to turn a plain 'backup' into the right IP address, due to an appropriate domain directive in /etc/resolv.conf.)

The bonus embarrassment is that our Linux nfsswitch.conf configuration is careful to check files before DNS, for much the same reason. I just didn't think about the issue when I was making the change on the Solaris machine.

Public interfaces and Solaris 9 patchadd exit codes

A commenter on an earlier entry noted that patchadd's exit codes are apparently not documented because they're considered an internal implementation detail that might change at some point. Unfortunately this is bogus logic.

There's a simple rule: once you explicitly expose something to users, it ceases to be an internal implementation detail in practice no matter what you want (and no matter what you may claim in documentation, although Sun does not explicitly claim this in the patchadd manpage).

Solaris 9 manifestly exposes patchadd's exit codes, since they are reported as is by things like the Solaris 9 recommended patch cluster installation script, as I found out. If Sun wanted system administrators to remain blithely ignorant of patchadd's fine details, all of the higher level tools should have hidden them; as it is, we won't be very happy if Sun were to turn, eg, 'return code 2' from something harmless to something that indicated a real problem.

I consider exposing things to people different from exposing them to programs. It's very hard to hide internal details from programs that go poking, but it's a quite different thing to shove those details under people's noses. And once you do the latter, you lose grounds to complain about programs using the information too. (In effect the programs have stopped being nosy parkers and have become our agents.)

(Disclaimer: I don't know if Sun really considers Solaris 9 patchadd exit codes to be just an implementation detail. The manpage doesn't document them, but then it doesn't say that they're private. Besides, it just makes a convenient example; the attitude is unfortunately somewhat generic.)

Some things about smpatch

smpatch is the official Sun thing for dealing with Solaris patches for Solaris 8 and 9 (Solaris 10 apparently has an all new system, hopefully better). I got interested in smpatch not just because it's the official Sun tool for this stuff, but because it has one feature that pca doesn't: it can reliably tell what patches are safe to be installed on a live multiuser system.

(While pca can skip patches that require reboots, it doesn't currently have a 'skip patches that claim to require single user mode' option. Although the information is theoretically there in the patch READMEs.)

My first smpatch surprise was how you get it. For Solaris 9, it isn't distributed as a download; instead the download page blandly tells you to install three patches. (For more fun, it gives specific revisions of those three patches, one of which is now obsolete.)

So I did the smart thing and used pca, whereupon it cheerfully told me that I already had a current version of patch 112945, the main Sun Patch Manager 2.0 software patch (according to the download page). It turns out 112945 is actually a general patch that is part of the recommended patch set, so I had it installed long ago.

After that there are a number of other things:

• smpatch needs you to be root. For everything.
• smpatch is achingly slow, even assuming it downloads the patch database from Sun every time.
• there seems to be no way to get detailed information about a patch that smpatch analyze tells you about, such as whether it wants reboots or single-user mode or whatever. (I checked and smpatch analyze always produces the same output; it appears that only smpatch update will do anything different.)
• there's no way to restrict smpatch to just recommended and/or security patches.

Overall grade: less than compelling. There seems to be no reason not to use pca instead, unless you think that smpatch has better information on what patches are safe to install on live multiuser systems than is in the patch READMEs.

(Hat tip to Matty's blog, where I read enough about smpatch to make it worth checking out.)