LEGO WeDo and Munki

As part of Mr Gove’s wonderful new Computing Curriculum in Primary schools, we’ve invested in some LEGO WeDo kit to teach some simple robotics stuff to KS2. It’s basically a USB hub which connects to a computer, into which you can plug a motor, a distance sensor or a tilt sensor. You can then program these sensors using LEGO’s own WeDo software (or MIT’s Scratch!) to build cool stuff like a spinning top, an aeroplane or an automatic goalie.

So far so good.

Then I came to trying to install the software on all the Macs in the school using Munki. I love Munki as it means I can remotely install and update stuff on all the Macs in the school really quickly. But it does rely on software coming in a reasonably decently packaged form. Which LEGO WeDo does not. Rather than using a sensible .pkg file, it instead has an Installer App (I know!) which then asks you to choose a language, which then opens up a meta package (.mpkg) which runs 6 different installers, each with various pre and post-flight scripts that liberally sprinkle files across various parts of your system.

Lovely.

Having used Pacifist to look inside the meta-package to see what was being installed, I tried using Munki to install each of these packages remotely. Except this didn’t work – the App icon for WeDo stopped working and you couldn’t view all the build instructions (leaving the dreaded greyed-out LEGO head).

So I tried a different tack. I downloaded Packages, a brilliant package-builder for Mac, and decided to build my own package for the software. The LEGO installer handily gave a list of all the files to delete to uninstall it, so I just added those to my package. And this worked. Kinda, only the LEGO head was stilled greyed out.

[Incidently, making changes to a package and changing the version number of the package, makes it keep testing an installation on Munki. Because Munki checks package receipts, it won’t reinstall a package it’s already installed. But it will install a package with a higher version number.]

Having spent far to much time on this problem already, I decided to give LEGO support a call. They were quite helpful, and suggested I try log in with an administrator account and see if that worked. Lo and behold, it did. They then suggested I tweak permissions on different files and folders to see if that helped. I basically gave write permissions to anyone on all files and that seemed to fix it. Not ideal really.

Munki really does work!

Munki really is brilliant. From the user’s end, it is basically invisible, installing software when the computers are sitting logged out and never bothering anyone. From the admin side, it is super quick to import a package file and super easy to add it to the list of files to be installed. This week alone I have been able to push out three different installs, confident that, by the next day, they will be installed on all the machines.

The only problem with it is that the admin backend is not hugely user-friendly, relying on setting up your own webserver, typing stuff into Terminal and editing a .plist file of software to be installed. I would love it if someone might perhaps consider building a beautiful and simple GUI backend too. Anyone offering?

Flash vs. Safari

Upon arriving at school today, teachers started telling me that they couldn’t view their Flash content because Safari was saying that the plugin was out of date and therefore blocked. Some had the initiative and had download and install the update because they knew the admin credentials, but it wasn’t looking good for everyone else.

Thankfully, Munki was there to the rescue! I managed to quickly download the Flash installer (using the volume distribution link on Adobe’s website – long story) and then uploaded it to our Munki repository. Our Macs are set to update every morning using Munki, but that was no good in this situation as everyone was already logged in. Instead I had to post some instructions for staff on how to use the ‘Managed Software Update’ app which comes with Munki to manually activate the installation.

Simples. Kinda.

The reason this is all happening is because of Apple’s XProtect software, which downloads a list of software to watch out for and then proceeds to block it as it comes across it. Which includes any out-of-date versions of Flash.

I guess the annoying part of this is that there is no automatic way of downloading and installing Flash updates, particularly on a network and particularly because Adobe specialise in inventing their own balmy and non-standard installer files.

Maybe Safari should join Chrome and offer automatic updates of plugins (particularly Flash). Or maybe Flash should just hurry up and be replaced by HTML5.

First day back…

I went back to school today to try and get ready for the beginning of term. As always, there’s lots of jobs that come up along the way, but here are a few things I managed to accomplish today:

Apply for some ‘up-to-date’ Mountain Lion licences for some Mac Minis that we bought after Mountain Lion was finally announced. I had to go into school to get some serial numbers and to get invoices from our reseller, but it was pretty straightforward. Today’s the last day that you can apply so I was cutting it a bit fine.
Set up a repository for Munki on our Mac Mini server. We’ve been using Munki with much success just as a way to automatically install Apple’s software updates when the computer is logged out. It’s pretty handy! However, I’ve been wanting to use it update other software (such as Microsoft Office and Adobe Flash Player), rather than having to push out packages using Apple Remote Desktop. I followed a really clear guide on the Munki website, which took a bit of time to get my head around but seems to have worked fine.

It ‘Just Works’

The latest point update to OSX 10.7 was released last week and I was pleasantly surprised today to discover that all of the Lion machines had already updated themselves thanks to Munki.

I know this is not the most exciting news in the world, but I was happy to see it as our Mac server is only running 10.6 and had to be fiddled with to get it to dish up Lion updates. I followed Apple’s instructions on how to do this but at first I didn’t think it had worked. Now I guess it was just caching them all as Lion clients now seem to be happily updating themselves. Yay!

I guess that now frees up my half term to do the LGfL 2.0 switchover with our trusty IT technician Ji. Looking forward to that job…

Munki Munki Munki

When wandering around school, my heart is warmed whenever I see a Mac quietly updating itself via the unassuming genius that is Munki. (Yes, I know that I am a geek!) Usually it’s only the latest iTunes release, but even that is helpful, if only to prevent a ‘download update?’ nag screen for the user.

The only main sticking point has been with the Mac Minis that teachers use. These tend to be on all day long with very little time sitting on the login screen, which is the only time I’ve set Munki to run. I’ve set the Macs, via managed preferences, to turn themselves on at the weekend, which does help with most. The problem comes when one of the updates fail, leaving that machine increasingly behind on its update schedule. The only solution for that is to manually sit there with the computer and run a few updates at a time until it gets past the dodgy package. Whilst being a minor pain, it’s much more preferable that sending a UNIX command with Apple Remote Desktop every half-term holiday and spending a morning making sure everything has updated properly.

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):

Install the Munki package on a Mac.
Open Workgroup Manager and then add a managed preference, using the ‘Managed Software Update’ application to provide an MCX .plist manifest.
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.