For a project at work, we decided to use Mac minis as clients. They’re small, cheap, and quiet, and they have enough horsepower to run the applications we wanted to test.
In order to build a stand-alone classroom, we decided to drive them with a Mac mini server running the server version of OS X. This has caused me no end of amusement, frustration, and bemusement, so naturally I thought I’d write about it from the perspective of an experienced Windows admin.
Summary: OS X Server gives you a lot of functionality out of the box, but much of it is feature-poor compared to Windows, or buggy enough to make it useless. Documentation is scanty, and Apple’s support resources are poor compared to Microsoft’s.
Installation is simple, with no worries about drivers or any of the other niggling little hassles attendant on installing Windows Server. OS X asks for an install key code, but it doesn’t validate it with a central server or phone home for activation.
The default installation ships with a large number of services, including DNS, DHCP, netboot, mail, iChat, calendaring, SMB and AFP file sharing, and web publishing. You have to enable and configure each of these services separately through the Server Admin application. I’ll go out on a limb and say that this is roughly the equivalent of the ubiquitous Microsoft Management Console, except that the MMC has an open plug-in architecture that means any vendor can write snap-ins for it. The Server Manager interface is straightforward: servers and services appear in a tree on the left, and details of the selected services appear in a tabbed view on the right. Service status is shown with a small icon next to the service name, and there are controls at the bottom of the window for adding, starting, and stopping services.
Setting up the server with the services I wanted (AFP, netboot, Open Directory, WWW, and Software Update) was a breeze… until I wanted to change the DNS name of the machine. I tried without success to do this; the changeip -checkhostname command reported that my hostname was correct, but it remained stubbornly wrong according to the clients, which could no longer find the original server and refused to try finding the new name. I eventually decided to demote the server from an Open Directory master to standalone and back again– the equivalent of decomissioning a Windows DC and then re-running dcpromo.
Good idea in theory. In practice, the conversion process threw tons of errors, none of which were documented anywhere. (Does “-14893” mean anything to you? Me neither.) The solution: pave the box and start over.
Normally I would have been throwing fits about this, but the installation process was fast and smooth enough that I didn’t mind; I had plenty of other work to occupy me in the meantime. After the reinstall, I gave the server the correct new name, converted it to an Open Directory master, and was off to the races.
In the meantime, some other people had been unpacking and setting up the clients. Now it was time to join them to the Open Directory server. This is like joining a domain in Windows, except that it isn’t much like that at all. Joining a client to OpenDir is more like telling it “hey, look here for account data.” There’s no machine account or object in the sense we think of them in Windows unless you manually create one. When you first boot a virgin Mac OS X client, if it sees an OpenDir server it will offer you the opportunity to connect to it. Once that’s done you can use OpenDir accounts for logon. If not, you can manually join it at any time from the Login Items pane in the Accounts preferences item.
One of the big reasons we wanted to use OS X Server is so we could push policies to the client machines. Apple calls these preferences, and they can be applied to individual user accounts, user groups, computers, or computer groups. There are all sorts of policies; the ones we were interested in were for controlling logon, access to removable media, and a few other related things. Setting up policies is trivial: find the scope you want the policy to apply to, click the appropriate icon (helpfully, these match the icons used in the System Preferences app), and choose which settings to enforce.
In our case, we wanted policies to be applied to computers. Registering a computer requires you to look up the computer’s unique ID and its MAC address, then enter both of these when you create the computer object. At that point you can assign policies to individual computers or computer groups. It was never clear to me when policies were actually applied: some seemed to take effect immediately, others only after a reboot of the client. (No doubt it’s documented somewhere and I just haven’t found it yet.)
The policies themselves are a mix of the obvious (“don’t allow users to mount USB devices”) and the Apple-only (disable Front Row, for example, or force the use of Mac OS X parental controls.) However, there are only a few settings compared to the huge number available in Windows. However, there’s an escape hatch: you can modify the contents of any preference plist file, so even options that can’t normally be changed through the GUI on a local machine can be managed. This is a handy feature.
Unlike Windows group policy there’s no way to push or publish applications to the clients. For this, you need Apple Remote Desktop, for which no precise equivalent exists in the Windows world. It is a combination of a management and inventory tool, a remote shell, and a desktop support application. You can use it to push files, remotely install applications, run arbitrary shell commands, and watch or control a user’s desktop. In our application, we use it to push a bootstrap installer, run it, and take care of some assorted housekeeping. It also has a neat-o mode that lets you observe multiple clients at once in a grid display. This is extremely useful for our environment, because it lets us see a classroom full of client desktops at once.
It’s easy to use ARD for a building-block approach: test a command on one machine, save it for later, run it on multiple machines when needed, and then string it together with other actions into a single set of actions. This made bootstrap setup of our clients much, much easier.
Next: time sync. OS X Server has an NTP service, and it’s easy to turn on and run. You cannot, however, easily instruct clients to use it. You have to push an update to /etc/ntp.conf onto every machine. That’s a pain. Apple Remote Desktop to the rescue, again.
Now, for the complaints, in no particular order.
The Software Update service is balky and buggy. Essentially it’s a custom CGI that runs on the built-in Apache installation. You can pull updates from Apple, choose which ones you want clients to get, and then allow clients to pull them. Great idea in theory, but it just doesn’t work well. Some clients see the right updates, and some don’t. The interface for choosing which updates you want to pull in the first place doesn’t let you select or deselect updates until after you’ve downloaded them, which means you have to wait for your server to sync before you can choose which updates you’d like. I spent about an hour trying to figure out why none of the clients could pull updates, only to learn that the path suggested in the setup dialog is wrong.
Logging is a mess. There are about two bajillion log files, each in a different location, each with different formats. The system console log can be searched, as can the individual component logs shown in Server Manager. However, the event management tools in Windows are easier to use and more complete. The bigger issue is that Windows event log messages are usually quite detailed. Microsoft’s gotten pretty good at writing meaningful event log entries over the years. Apple, not so much.
Bugs! I mentioned the problem I had with OpenDir master-ism earlier. I didn’t run across any show-stopping bugs, but there are still a fair number of rough edges. In fairness, some of these were probably due to me bumbling around.
Documentation: it’s a set of PDF files. I much prefer Microsoft-style layouts that have an easily accessible table of contents in one pane and the content in another. My preferences aside, the docs are nowhere near as detailed as Microsoft’s. You would be hard pressed to deploy Mac OS X Server in an enterprise without an awful lot of around-the-campfire knowledge passed down from greybeards, because the docs don’t include many of the things you’d want to know before basing your business networks on OS X.
Having said that, I found the Mac Enterprise mailing list to be extremely helpful, though I wasn’t always sure what they were talking about. They were able to efficiently answer the few questions I asked, not at all unlike the golden days of mailing lists for Exchange. From reading the list I learned about two very cool system management technologies I plan to make use of: Puppet (a cross-platform scripting language for system management) and Sikuli, which is hard to describe except to say that it’s a screenshot-based scripting environment.
Thus far everyone is happy: the client Macs work, they’re being managed the way we want them, and life is good. As I learn more about how to make OS X Server do cool tricks, I’ll try to post them here.
Paul's Down-Home Page 