MacEnterprise: Snow Leopard Scavenger Hunt

Changes in OS 10.6 of interest to systems administrators

By Greg Neagle, MacEnterprise.org

Introduction

With each new release of OS X, systems administrators have a bit of a scavenger hunt: hunting for what's new, what's changed, what's fixed, what's broken, what's moved, and what's gone. I have to admit that I find the hunt kind of fun - Apple's given us a new toy, and we get to find all the surprises inside. So instead of a column on a single topic or tool, this month we will be hunting through the new OS, looking for what's new and of interest to enterprise systems administrators!

Launchd

In a recent MacEnterprise column on launchd, I covered some of the changes to launchd in Snow Leopard. The most important change of interest to systems administrators is the change in how launchd handles the Disabled key in launchd plists.

In Tiger and Leopard, if you disabled a launchd job using launchctl like this:

launchctl unload -w /path/to/launchd.plist

The job would be unloaded, and the Disabled key in the launchd plist would be set to true. In Snow Leopard, the job is still marked as disabled, but the plist is not changed. The value of the Disabled key is stored elsewhere. The launchctl man page doesn't say where it is stored, but some hunting finds it in /private/var/db/launchd.db/.

The com.apple.launchd directory holds info for LaunchDaemons, and the com.apple.launchd.peruser.* directories hold info for LaunchAgents. Each of these directories contains an overrides.plist file. This file contains the current "effective" value of the Disabled key for each launchd job:

To determine the current enabled/disabled state of a given launchd job, an admin must check the value of the Disabled key in the launchd job's plist, and then also check for an override in /private/var/db/launchd.db/.

An effect of this change is it now possible for non-admins to disable LaunchAgents that run when they login, by running

launchctl unload -w /Library/LaunchAgents/some_launchd.plist

This might be a problem if you rely on LaunchAgents to run at login and perform certain tasks for the user - the user can now turn these off.

Networksetup

OS X systems administrators should be familiar with the networksetup command, which allows you to configure network-related settings from the command line. This tool is ideal for use in setup scripts, or for remote configuration via SSH. In Snow Leopard, networksetup gains a few new tricks.

AirPort options

The AirPort options in networksetup have changed. If you have AirPort configuration scripts, you may need to revise them for Snow Leopard. The -getairportnetwork, -setairportnetwork, -getairportpower, and -setairportpower options all now require a hardware port to be specified. An example:

Prior to Snow Leopard:

networksetup -setairportpower off

Snow Leopard:

networksetup -setairportpower "AirPort" off

Does this change portend Macs with multiple AirPort interfaces? Your guess is as good as mine.

There are four new options dealing with preferred wireless networks, which could be useful in a setup script that automatically added your organization's wireless network(s) to the preferred list:

networksetup has gained the ability to work with 802.1X-secured networks. You can set the System profile, the login profile, or user profiles:

-listalluserprofiles
-listloginprofiles service
-enablesystemprofile service on | off
-enableloginprofile service profile on | off
-enableuserprofile profile on | off
-import8021xProfiles service path
-export8021xProfiles service path yes | no
-export8021xUserProfiles path yes | no
-export8021xLoginProfiles service path yes | no
-export8021xSystemProfile service path yes | no
-settlsidentityonsystemprofile service path passphrase
-settlsidentityonuserprofile profile path passphrase

These new options don't help with the actual creation of 802.1X profiles, but with the import and export options, you should be able to create them on one machine and deploy them on others.

For more details on all of the new networksetup options, type "man networksetup" at a command prompt.

Cisco VPN Support

Since we're talking about network configurations, this is a good time to note that Snow Leopard now has Cisco VPN support, accessible from the Network preferences pane. When adding a VPN interface, "Cisco IPSec" now appears as an available VPN Type.

With Cisco's client, an administrator could distribute the client software and some pre-configured profiles. Administrative configuration looks to be more difficult with Apple's built-in client. networksetup did not gain any new capabilities as far as VPN configuration, so that's no help. You can export and import configurations, and since they are XML files, you might be able to generate configurations programmatically.

Figure 1 - Cisco VPN support

Mcxrefresh

mcxrefresh is a new command-line tool to cause a client machine to re-read its MCX settings from the directory services. It must be run as root. You can specify a user id or shortname to refresh the Managed Preferences for a specific user as well as the computer settings. This might be useful when testing changes to MCX settings - you can instantly force a machine to refresh its Managed Preferences.

mcxrefresh -n joeuser

Directory Utility

You've booted up your first Snow Leopard machine and you want to point it at your Open Directory or third-party LDAP server for directory services. In Leopard, you'd head to the /Applications/Utilities folder and look for Directory Utility. But on your Snow Leopard machine, it seems to be missing. Instead, you can open the Accounts pane in System Preferences as in Figure 2.

Figure 2 - Accounts Preference Pane

When you select Login Options, you'll see a new section for a "Network Account Server." Click Edit, and you'll see the sheet in Figure 3.

Figure 3 - Directory Services pane

From this pane, you can add directory servers, or open Directory Utility for more options. Or you can just skip all this, and go directly to the new location of Directory Utility: /System/Library/CoreServices/Directory Utility.app.

Keychain password Enhancements

A common problem in enterprise environments is keeping the login keychain password in sync with the directory services password. Many environments use a web page to allow their users to change passwords. In other environments, users may have access to multiple machines (say a Mac and a Linux box), sharing a common directory service. If they change their password on their Linux box, or use a web page to change their password, the login keychain on the Mac is not updated with the new password. When the user then logs into their Mac, the login keychain is not unlocked, and access to mail accounts, web pages, file servers and the like might be affected. Prior to Snow Leopard, many administrators used AFP548.com's Keychain Minder to handle this situation. When configured to run as a login item, Keychain Minder would check to see if the login keychain was unlocked at login, and offer to help the user reset the login keychain password if needed.

Snow Leopard builds in most of Keychain Minder's functionality. If the user password is changed, and the login keychain can't be unlocked at login, you'll see a dialog like the one in Figure 4.

Figure 4 - Update Keychain Password dialog

You can then update your keychain password, create a new keychain, or ignore the issue.

Screen Saver

Since the release of OS X 10.0, large organizations have wanted the ability to run a screen saver when the machine is at the login window. Apple's opinion always seemed to be that you should have your machines (or at least the displays) sleep when idle at the loginwindow for a long time. High schools, colleges, and other organizations instructional labs often wanted the machines to stay on with active displays so students could quickly identify available machines. When presented with a machine that was asleep, or with a darkened display, many students assumed the machine was broken. In my organization, we had a number of Macs connected to color-calibrated CRT monitors. These monitors needed to be left powered up and with an active display in order to maintain their calibration.

Whatever the reason, when an organization wanted/needed the display to remain active when the machine was at the loginwindow, they had a new challenge to deal with: screen burn-in. A machine left for hours or days at the loginwindow could burn the image of the loginwindow into the phosphors. (And although LCDs are supposedly immune to the effects of burn-in, I've seen evidence to the contrary.) So it's understandable to want the screen saver to run over the loginwindow to prevent burn-in. Some organizations also saw this as an opportunity to run a screensaver that presented news or announcements about the organization.

Unfortunately, Apple did not support running the screen saver at the login window. Various workarounds were developed. An application called Screen Preserver could be used to display slideshows over the loginwindow. In 10.3 and 10.4, enterprising administrators developed scripts that allowed Apple's screen saver to run over the login window. But Leopard brought that practice to an end, as the built-in screen saver no longer would run over the loginwindow.

So it was with some surprise when testing Snow Leopard this summer that I noticed the screen saver kick in while I was logged out. This new behavior persisted into the final release. There's no user interface to control which screen saver runs, or how long to wait until activation. I haven't yet figured out any other way to control these options, but I'm sure someone will before long. Still, this is a welcome change, and only took eight years for Apple to implement!

Exchange integration

We can't finish our scavenger hunt without mentioning a new feature of great interest to many enterprise systems administrators (and regular users!) - support for Microsoft Exchange. If your organization is running Exchange Server 2007 (and alas, my organization isn't yet...), you can configure Mail, iCal, and Address Book to talk to your organization's Exchange server. While this doesn't give you the full range of functionality you can get from Entourage 2008 Web Services Edition (let alone Outlook on Windows), it may be sufficient for some user's needs.

The Exchange integration in Snow Leopard is based on Exchange Web Services, a new protocol first available in Exchange Server 2007 SP1. Older Exchange servers support only MAPI (a protocol extremely difficult to replicate outside of Windows - even Entourage, a Microsoft product, doesn't use it), or the limited OWA (Outlook Web Access) protocol, which is on its way out. For this reason, the Exchange integration in Snow Leopard doesn't work with older Exchange servers.

Since this is a new feature, and Exchange support is notoriously difficult to implement (otherwise, why would Entourage still have issues?), it may work well in your environment, or not at all. Early reactions on the MacEnterprise mailing list are mixed: some organizations are reporting great success; others are having difficulties. If your organization is running Exchange 2007, try it yourself and see.

Figure 5 shows the dialog in Mail.app for adding an Exchange 2007 account. Note the options to also setup Address Book and iCal. If you don't configure them here, each of these applications also has an interface for configuring Exchange 2007 accounts.

Figure 5 - Mail setup for Exchange 2007

Conclusion

That concludes our scavenger hunt. If there's a theme to the changes in Snow Leopard, it's "refinement". Lots of little things have been subtly refined, providing a better user experience, or making things work the way they should have earlier. We have by no means covered all the changes in OS X 10.6 - there are many more. Have fun on your hunt!