ADPassMon updated to 1.8

This version brings official OS X 10.8 compatibility and uses Notification Center instead of Growl for alerts when running on Mountain Lion.

Download it here.

Update NFS automounts from the terminal

If you’ve used Disk Utility¹ to set up automounts — or you recently upgraded to Mountain Lion and found that the GUI for editing NFS mounts has disappeared — and find yourself needing to quickly update the records, this tip is for you.

We moved a bunch of NFS shares from one server to another over the weekend and needed to update the mount records on all clients that aren’t using our LDAP-based automount records. A handful of Macs with manually-configured NFS shares had lost access to these relocated shares. Disk Utility stores its mount records as (non-binary) plists in  /var/db/dslocal/nodes/Default/mounts. One of the lines in a mount plist contains the server:/path/to/share line for that automount.

To update the mount record, do the following using root privileges:

1. Find the plist that contains the path you need to update in /var/db/dslocal/nodes/Default/mounts.
2. Use your favorite text editing tool to update the path record, or replace the entire plist with one that contains the updated record.
3. Run automount -vc to flush the cache and read in the updated information.

That’s all there is to it. I leave it as an exercise for the reader to combine all the steps into a deployable, scripted solution.

_____
1. If you’re using OS X 10.5, it’s in Directory Utility.

ADPassMon updated to 1.7

Bug fix: The Change Password dialog now opens in the foreground.

Download it here.

Automount NFS in OS X

I work in a mixed Mac/Windows/Linux environment. The majority of our fileshares are located on Isilon gear and are accessible over SMB with AD authentication, and over NFS with LDAP authentication. Our Macs bind to AD and therefore use SMB to access fileshares. As the size of the scientific datasets people use grow, the (lack of) performance of SMB in Mac OS X becomes more of an issue — especially for people who know they can get far better performance in Windows and Linux. To remedy this, with the help of my colleague and Mac admin, Rich Trouton, we’ve started to migrate certain Mac users away from AD and SMB to LDAP and NFS. Because our Mac users have mobile accounts with local homes, the move requires a bit of finagling, which is why Rich scripted the process.

Once a Mac user’s account has been migrated to LDAP, s/he can use NFS URLs in the Finder’s Connect to Server window and will see vastly superior performance to the previous SMB connections. The more Macs we convert to LDAP/NFS, the more active connections we’ll have to our fileservers. At a certain point, this will become a problem. Fortunately, there’s a way around this that all our linux computers already use: autofs. Autofs will automatically mount fileshares on an as-needed basis and will automatically disconnect fileshares after an idle timeout period (which defaults to one hour). Another benefit of autofs is that users no longer have to mount shares manually. Simply by navigating to where the share is supposed to be will mount it there. Automount is clearly the best solution going forward.

My primary goals for this NFS automounting solution was to make it easy to manage and update — we sometimes add and remove fileshares — and to have the Macs mount fileshares at exactly the same paths as in Linux, inside a root-level directory called ‘groups’. Because of a peculiarity in OS X Lion’s Finder (that I’ll discuss later), this goal precluded the use of the automount maps that our linux hosts get from LDAP. My solution (which works with OS 10.6 through 10.8) adds entries to /etc/auto_master that reference files in a new /etc/automounts directory.

Example Scenario

Let’s say my Isilon cluster is called shares.example.com and it is exporting a number of NFS shares with root paths beginning with /ifs/groups/foo, /ifs/groups/bar, and /ifs/groups/baz. Each of these directories contains at least two subfolders which are the actual shares. I want these shares to mount inside /groups/foo, /groups/bar, and /groups/baz. To do this, I need to create three files inside a new /etc/automounts directory called foo, bar, and baz containing the respective automount maps. Because I’m working outside the user space, I’ll need root/admin privileges.

Here’s what /etc/automounts/foo looks like:

*        -fstype=nfs,rw,bg,hard,intr,tcp share.example.com:/ifs/groups/foo/&

The asterisk at the beginning and the ampersand at the end of the line tell automount to mount any shares it finds inside /ifs/groups/foo with the same name as the share. This saves me from having to specify each share individually. (The mount options are beyond the scope of this post, but go here if you want to learn more about them.) The other two mounts follow this same pattern. You can, of course, specify each share individually. These mount files can have any number of lines in them.

When all the mount files are written, I need to add one line per file to my /etc/auto_master file. It ends up looking like this:

#
# Automounter master map
#
+master # Use directory service
/net -hosts -nobrowse,hidefromfinder,nosuid
/home home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -static
## everything above this line is in the default auto_master file ##
/groups/foo /etc/automounts/foo
/groups/bar /etc/automounts/bar
/groups/baz /etc/automounts/baz

Looks pretty straightforward, right? After these modifications are in place, I check to make sure all files are root:wheel owned, the automounts directory has rwxr-xr-x (755) permissions and /etc/auto_master and all files within /etc/automounts have rw-r–r– (644) permissions. Now I need to restart the automounter so it sees the new mount maps:

sudo automount -vc

When this command runs, it should output all the new mounts it has created. The first three lines are from Apple’s default mounts:

automount: /net updated
automount: /home updated
automount: /Network/Servers updated
automount: /groups/foo mounted
automount: /groups/bar mounted
automount: /groups/baz mounted
automount: no unmounts

Now, even though it says “mounted”, nothing has actually been mounted. If you look in the Finder, you should see that autmount has created the mount  points, but nothing else. This is an important concept to understand. A share will not actually mount until you traverse its mount point. This is confusing for anyone who has not wrapped their head around autofs — and I’m staring in the general direction of most Mac users, here. For example, let’s say you want to get to /groups/foo/images. If you look inside /groups/foo in the Finder or the Terminal, you will see an empty directory. To go that next step, you’ll need to either use “Go to Folder” and specify “/groups/foo/images” or use the terminal and cd into that directory.

One last thing to mention. You will probably wish to disable the creation of .DS_Store files on network volumes when using automounts. The Finder has a bad habit of leaving these files open, so your automounted shares will not unmount after set idle times like they’re supposed to. To keep your Mac from writing .DS_Store files to network drives, run the following defaults command in the terminal. This is a per-user setting.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Deploying this solution

As I mentioned earlier, because we add and remove new shares semi-regularly, I needed this solution to be manageable. If you’re already using configuration management tools in your Mac environment — be it Casper, Puppet, or anything else — you’re probably already familiar with the best way to deploy and manage a small collection of files. My colleague Rich just wrote up how to wrap all this into a package that you can deploy with your tool of choice. Any time we add or remove a share, we can push out a new package with the changes and the packages postinstall script will reload automount. The reload process won’t affect any active mounts so we can push the package out at any time.

Appendix: Why not use LDAP?

Because the Finder (at least since 10.7) will rename mount points to match the filename that contains the autofs mapping. Our LDAP server’s maps are named with a format of auto.groups.foo. As soon as you go into a share inside /groups/foo, e.g. /groups/foo/images, the Finder renames the foo directory to auto.groups.foo. Directory names viewed from the Terminal are unaffected.

ADPassMon updated to 1.6

New feature: “Launch Ticket Viewer” menu item, launches Ticket Viewer.app.

Download it here.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/username/.ssh/known_hosts:42
RSA host key for 10.1.2.3 has changed and you have requested strict checking.
Host key verification failed.

If you use ssh — if you’re reading this blog, you likely count yourself as a member of that group — you’ve seen this warning. If you bring up and take down vms regularly, or replace servers regularly, or use dhcp on your network with short lease times, you might see this warning more than others. Regardless of how or when you’ve seen the warning, you probably find it annoying. “No, computer, I’m not being hacked. A different host has this IP now. Just let me in already, ok?” At this point, you open the known_hosts file in your editor of choice, find the offending line, delete the line, save the file, and try your ssh command again. Tedious, right?

We can all agree that simply turning off this warning is not the best idea, so how can we deal with it efficiently? (HINT: check this posts categories.) That’s right, we script it. We don’t need any more than a simple one-liner, and the best place to keep your one-liner scripts is in your .bashrc file (or the shell of your choice’s rc file).

Do you see how the error kindly tells you which line of the known_hosts file is the offender? This makes our job extremely easy. Both sed and perl can easily delete a given line from a file. (NOTE: Mac users will need to use perl, since BSD version of sed does not include the functionality shown here.) Both of the following commands will delete line 42 from the file.

sed -i '42 d' ~/.ssh/known_hosts

perl -i -ne 'print unless 42 .. 42" ~/.ssh/known_hosts

These are nice, but we need to wrap the command in a function that takes the line number as an argument. Let’s call the function rmhost.

rmhost () { sed -i "$1 d" ~/.ssh/known_hosts; }

rmhost () { perl -i -ne "print unless $1 .. $1" ~/.ssh/known_hosts; } # for Macs

And there we have it. Put your command in your .bashrc, source it (i.e. load the changes by running ‘source ~/.bashrc’), and the next time you see the above warning (and you know the reason you’re getting it), just type rmhost [line #] and you’re good to go.

ADPassMon updated to 1.5

ADPassMon now works with multi-domain AD forests.

Download version 1.5 here.

ADPassMon updated to 1.4

This update makes ADPassMon compatible with Growl 1.3. If you’re still using an older version of Growl, you do not need this update, but it is also compatible with older versions of Growl.

Download version 1.4 here.

 

ADPassMon updated to 1.3

This minor update fixes an error that affects Macs with only one DNS server configured.

Download ADPassMon v1.3

ADPassMon and FileVault 2

+

ADPassMon user Cesar Gonzalez sent me a nice note to let me know that Apple engineers suggested using ADPassMon to work around a problem he encountered after deploying FileVault 2. Due to the EFI boot authentication passthrough, his users are no longer notified of the pending password expirations at the login screen. Since ADPassMon runs after the login process, it works whether FileVault 2 is enabled or not.

Adding to ADPassMon’s feature list without any additional work seems like a big win to me. :) Thanks again, Cesar!