Snow Leopard Server with Mavericks clients, and why to avoid Mac Server
Note: the below text was written in 2014 but never posted. I have kept the same tense since I don’t want to rewrite it.
Our lab has a setup where we have multiple workstation iMacs that connect to a Mac Mini server, with network accounts stored on the server. Previously, both server and clients were running Snow Leopard, but I’ve just upgraded two of the clients to Mavericks while keeping the server on Snow Leopard. (Upgrading to Mavericks server costs money). I’ve been running this setup for a few weeks now and nothing major seems to have broken. For details of our lab’s setup, and why you should avoid Mac Server, read on…
In 2011 my advisor purchased an expensive Mac Mini Snow Leopard server for the lab, to store data generated by the lab and do other things that only servers can do. The lab had several iMacs that served as workstations for lab members, as well as a Mac Pro used for data analysis. Data were originally stored on the Mac Pro as well, but with the new server we could separate those tasks and use the Mac Pro only for analysis work.
At the time, I didn’t do too much research into Mac Server and assumed that things would “just work” out of the box. I also figured that the best way to handle the “data storage” aspect was to store everything on the server, including user accounts. In essence, this means that user home directories were stored server-side and all home folder access and user authentication is done over the network.
The network account system has a couple of advantages. Every member of the lab could have their own account, files, and settings, that would work regardless of which computer they signed in on. It’s actually really cool to be able to just sign out of one computer and then sit down at another and keep going right where you left off. Central control of user data and user accounts also meant that backups were also centralized, hopefully insuring against data being lost because it was on an old machine that was rarely used.
However, the drawbacks are pretty significant. The major one is that the server is a single point of failure for every single person. Originally, if the file server was down, you couldn’t get access to the shared lab data, but your own data were still intact on your workstation. Now, if either the server or the network were down, you couldn’t login to your own computer, never mind access your files.
Other quality of life issues include:
- Time Machine backups won’t work on the server due to bad interactions with Open Directory databases. We use rsnapshot to the other internal drive and CCC to an external drive.
- Home directories served over AFP prevent multiple accounts being signed into the same workstation. This is because the first user signed in will mount the AFP share under /Users with their own permissions, so the second user will try to mount the same share, fail due to permission issues, and throw a cryptic error message confusing everyone.
- Home directories served under NFS don’t play nice with many programs, especially ones that assume that all user directories on Macs is stored under /Users. I also encountered a bug with Dropbox not working since it was trying to acquire a file lock and failing (probably because Apple’s NFS implementation was bad, or perhaps that NFS in general is bad). To Dropbox’s credit, I emailed their support team and they eventually fixed the bug.
- Every client computer’s DNS must point to the server computer. This actually isn’t necessary if your upstream DNS assigns a fixed hostname for your server. Ours does, but the problem is that I originally configured the server to have a different hostname than its actual name. Once past the initial setup, changing the server’s name is so onerous that most guides I consulted recommended doing a clean install of Mac Server with the correct hostname. By running your own DNS and pointing all client computers to your server, the server can lie to itself and its connecting clients about its own name and thus everyone is happy. Note that it’s actually possible to change the hostname: during initial setup I made a typo in one of the boxes that you must enter the hostname into and in doing so created a difficult to track down bug that caused client computers to sometimes stall during login for minutes at a time. Tracking down this one involved looking at a lot of log files and noticing attempts to connect to an incorrectly-spelled host. I fixed this one by looking through all the configuration files for the misspelled name and correcting it.
- You will be terrified of restarting the server for updates. Every time I have updated the server, it refuses to work correctly in spectacular and exciting new ways. This one has probably shortened my life expectancy by a couple of years, at least.
Update 2015: Basically, I don’t think using OS X server is Worth It. Thankfully Apple seems to have scaled back their server offerings so hopefully no one else is falling into this trap. Our new setup uses a dedicated network appliance (Synology NAS) to serve files, combined with several (quite beefy) shared Linux workstations. All devices can connect to the Synology NAS over NFS. The issue of having shared desktops but personal accounts is no longer a problem, since all analyses are performed on the workstations, and everyone has their own personal laptop that they used to remotely login to the shared workstations. Although this is less secure in the sense that it’s possible for people to trample over each other’s files, in practice this hasn’t really been that big of an issue. There are separate horrors associated with accessing an NFS share on Linux systems with automount, but I’ll save that for a separate post.