Managing without the Mac server

A few weeks ago, we discovered that the second hard drive on our Mac mini server was failing.  Which isn’t good.  It’s still under warranty though so won’t cost anything to fix, apart from the inconvenience of having it taken away from our school for a few days.

And an inconvenience it certainly has been!  The Mac server has been brilliant for managing all the little settings and preferences on the Macs and I’ve made much use of Workgroup Manager for tweaking this and fixing that.  This makes it all the more painful when it is removed, especially with a large school full of an ever-increasing number of Macs.

All the Macs are bound to two servers: the Open Directory (OD) on the Mac server and the Active Directory (AD) on the Windows server. The AD manages usernames and passwords and serves up all the network drives, but the OD tells the Macs what to put in the dock, what drives to mount on login, and where Microsoft Office can put all its first-run registration windows (i.e. not on my screen!). Without the Mac server, the Mac will still let users login, but the dock will be empty, network drives won’t be mounted and everyone will come running to find me and demand access to their shared folders.

After some very helpful support from our wonderful reseller Toucan, I settled upon this plan:

  1. Make a local account and set it up just how I wanted it, i.e. applications in the dock and network drives mounted on login with credentials on the keychain.
  2. Log in as root and copy this home folder to all the Macs using Apple Remote Desktop.
  3. Tell teachers to login with the local account only.

The first part was fairly straightforward.

The second part was a little more tricky as it involved logging in as root, something I had not done before.  But Apple give some easy-to-follow instructions how to do it.   This gives the user unlimited powers to look in any folder and move anything anywhere, without running into permission errors all the time.  Once logged in as root, I used Apple Remote Desktop to copy the home directory of the local user to all the Macs. I had already set up a local user previously, so I just reused that name and didn’t have to go to each machine and add a local account.

The annoying problem I ran into was that some Macs were still remembering all their managed preferences, even though the Mac server was unavailable.  This would have been fine if every Mac was doing this, but it was inconsistent across the school and gave an uneven user experience.  Thankfully, I found an article explaining how to flush the MCX cached settings. Et voilà, everything working fine.  Or at least good enough.

I hope the Mac server gets fixed quickly!

It does make me realise why Apple is moving to profiles for managing preferences on a Mac, just like with iOS.  That way, the client machine remembers the settings it’s been given, rather than relying on a continuous connection to a server.  It’s just a shame that Profile Manager isn’t quite up to the job as of yet, particularly with OSX.

Ricoh Printer Driver Fix

Workgroup Manager is wonderful, but it doesn’t tell computers which printer drivers to use.  Which is annoying when a certain Ricoh printer/copier doesn’t work with the default OSX supplied driver (unless you have postscript fonts installed on the printer) and instead just spews out pages of garbled nonsense.

Thankfully, there is a reasonably easy fix!

1. Follow this page to create a custom PPD file, with exactly the driver you do want to use.  Gutenprint ones work fine!

2. Follow this page to point your Macs to that custom PPD file using Workgroup Manager.

Tada!

Munki and automatic updates

Apple’s approach to software updates betrays their consumer-centric view of computing: on a Windows PC, updates can be set to automatically install and in fact your system administrator can take that power off you and install updates whether you like it or not; on the Mac, it’s up to the user to install updates when they want to, and there are no official ways to fully automate this process.

This is all very well, but is a bit of a pain when managing a school-full of Macs, especially when all the remaining PCs happily pull updates off the Windows Software Update Service without anyone lifting a finger.  In a bid to keep everything reasonably up to date, I would use Apple Remote Desktop (ARD) to send a UNIX command to run software update every now and again.  This worked reasonably well, but required each machine to be unoccupied and for me to keep an eye to check everything was working ok.  I also tried setting machines to wake up in the night and then scheduled ARD to send the update command at that time, but this would never quite work properly with machines losing their connection or going to sleep etc.

I then stumbled upon a program called Munki, which describes itself as ‘Managed software installation for OSX’. It’s a pretty powerful bit of software, but with quite a steep learning curve and no friendly GUI to get things going.  However, after a bit of reading of the help files I realised that it could quite easily be set up to automatically install software updates whenever the Mac was idle at the login screen.  Here’s how (using a Mac OSX Server to manage preferences):

  1. Install the Munki package on a Mac.
  2. Open Workgroup Manager and then add a managed preference, using the ‘Managed Software Update’ application to provide an MCX .plist manifest.
  3. Add the following keys:
  • AppleSoftwareUpdatesOnly = true
  • InstallAppleSoftwareUpdates = true
  • SoftwareUpdateServerURL = your own Apple Software Update Server or just leave blank to use Apple’s
  • SuppressUserNotification = true

Tada, it should work!

Unfortunately for me it didn’t, not straightaway.  It turned out that I was having problems with our Software Update on our Mac server because the DNS wasn’t sorted correctly.  A useful tool in terminal is ‘changeip’ for that…

But it all seems to be working now.  Hurrah.