AutoFS and NFS improvements in Leopard
It’s fair to say that I’ve been disenchanted with my Leopard upgrades. My gripes are documented in these very pages. Recently, though, I’ve found some stuff in which Leopard is a real improvement over Tiger.
NFS
NFS support is much improved. NFSv3 with options tcp,rw,intr
is massively more reliable. I don’t remember the last time the system completely hung and while it’s still possible to upset a Mac by killing its NFS server, a Leopard machine can now actually recover – perhaps with the help of a umount -f
– when the file server comes back.
Leopard even has rudimentary NFSv4 support but this is little more than a novelty given that it has no idmapd, Kerberos doesn’t appear to work (at least for me, against a known working Red Hat system) and Apple force you to use ridiculous syntax to mount.
# mkdir nfsv4 # mount -o nfsvers=4 filer:/stuff nfsv4 mount_nfs: sorry, you must specify vers=4.0alpha to use the alpha-quality NFSv4 support # mount -o nfsvers=4.0alpha filer:/stuff nfsv4 #
AutoFS
The Leopard automounter is also much better. Apple’s proprietary nonsense has been replaced with a real RFC2307bis implementation which is compatible with your existing LDAP rules.
Leopard’s stock /etc/auto_master looks like this:
# # Automounter master map # +auto_master # Use directory service /net -hosts -nobrowse,nosuid /home auto_home -nobrowse /Network/Servers -fstab /- -static
This is interesting for a number of reasons. First of all it includes a /net entry allowing you to do something like the following, just like on a Linux or Solaris system:
# cd /net/filer/share
Secondly you’ll notice the /Network/Servers entry which ensures back-compatibility with your Tiger mounts. There’s also a /home rule which is unexciting in itself but which influenced my choice of mount rules when I was configuring this.
The most important entry in the file is the first one.
+auto_master
This tells the automounter to look for a map called auto_master in the directory service. Let’s call this the map_name
. Leopard will therefore go and make the following LDAP query:
base="automountMapName=<map_name>,<mount_base>" filter="(&(|(objectClass=automount)))"
We’ve already seen that the map_name
is auto_master. By default the thing I’ve called mount_base
is just the search base configured when the LDAP server was added with Directory Utility. So on my network that would mean a search base of automountMapName=auto_master,dc=iain,dc=cx.
This wasn’t what I wanted. My AutoFS mounts were all under ou=mounts,dc=iain,dc=cx. Luckily you can change this in Directory Utility by editing the search base for the Automount and AutomountMap record types.
Gotcha!
Now’s probably a good time to mention that if you configure your LDAP server with macosxodconfig, ie From Server and it was last configured from Tiger, you won’t have the automount record types and AutoFS won’t work at all! It took me a while to figure this one out. Depending on how many tweaks you’ve made to the stock mappings you might find it easier to create a brand new LDAP server configuration and re-apply your changes than to retrofit these mappings.
Automount => automount AutomountInformation => automountInformation Comment => description RecordName => automountKey AutomountMap => automountMap Comment => description RecordName => automountMapName
Another gotcha!
The AutoFS schema that ships with Linux AutoFS5 has different OIDs for the automount objects to the ones in Apple’s schema. I had to slapcat my directory, delete the database, remove the autofs.schema
from slapd.conf and slapadd the database so that the entries were catalogued correctly.
Furthermore the apple.schema
in Leopard no longer has apple-user-homeDirectory but that’s OK because you’ll want to revert the mapping of NFSHomeDirectory to homeDirectory once you have AutoFS working properly.
Sharing automount entries with Linux
Now that OS X understands the same mount syntax as everyone else and we have it looking in the same search base, we can ditch (almost) the two copies of every map and share things. I decided to map /home
to auto_home
instead of auto.home
as I had been, because that way it will actually work out of the box on Leopard even if auto.master
doesn’t.
See, I told you the auto_home
line in /etc/auto_master was interesting.
Here’s my schema.
dn: automountMapName=auto_master,ou=mounts,dc=iain,dc=cx automountMapName: auto_master objectClass: top objectClass: automountMap dn: automountKey=/home,automountMapName=auto_master,ou=mounts,dc=iain,dc=cx objectClass: top objectClass: automount automountKey: /home automountInformation: auto_home dn: automountMapName=auto_home,ou=mounts,dc=iain,dc=cx automountMapName: auto_home objectClass: top objectClass: automountMap dn: automountKey=/,automountMapName=auto_home,ou=mounts,dc=iain,dc=cx objectClass: top objectClass: automount automountKey: / automountInformation: -fstype=nfs,rw,intr files:/home/& dn: automountKey=*,automountMapName=auto_home,ou=mounts,dc=iain,dc=cx objectClass: top objectClass: automount automountKey: * automountInformation: -fstype=nfs,tcp,rw,intr files:/home/&
Note I have two wildcard rules (hence the comment about almost ditching duplicate entries. Leopard understands * as a wildcard, like in flat files, but my Fedora 7 test clients still want / as a wildcard. In the future they might not need the workaround.
The final step on my Fedora clients was to play with /etc/sysconfig/autofs to uncomment the record mappings corresponding to this schema. But they might actually be the default on Fedora. I probably already changed them last time!
Can you give some hints for autofs4 records I need to purge from my linux ldap server before using the macosx autofs schema ?
Comment by chuntera — 2008-05-20 @ 21:44:22
Anything that appears in both the apple.schema file (from the schema directory of any Mac) and your Linux schema should be checked. If the OIDs are different you’ll want to pick one before installing the apple.schema. automountKey, automountInformation, automountMapName etc are the things to look for.
If you already have both schemas installed you shouldn’t have a problem as the server would have complained before now that you tried to redefine an attribute if there were any conflict.
In my case the OIDs for the attributes were different so I couldn’t just remove the old schema and add the new one; the raw data was stored against the old OIDs.
Comment by iain — 2008-05-20 @ 22:07:55