Tag: mac

Sarbanes–Oxley Act and Lion

Ok, take that back.

Apple probably do have to charge for Mountain Lion because of the Sarbanes-Oxley Act, which basically means you can’t add additional functionality to something you’ve already sold.  They get around this with iOS devices because Apple account for them over 2 years in a subscription model – you get free updates because Apple treat it as if you’re still paying for it!  The Mac isn’t accounted for like this so thus they can’t do free updates.

Rats. Maybe it’ll just be a token cost?

Mountain Lion

So, Mountain Lion is coming this summer.  Woo!  I personally like how they’re unifying different ideas and sorting out weird inconsistencies between iOS and OSX (like making Notes separate rather than part of Mail, creating a separate Reminders app, and renaming iCal to just Calendar). Messages also is pretty handy, and now available in beta form.  The way it was announced was also interesting: no press event, but instead one-to-one presentations with key Apple writers.

My prediction is that it will be a free update to all users of Lion. The benefits of having everyone on the latest OS release far outweigh any revenue they may get from the update. iOS updates are free for this very reason.

iMovie haters?

I’m probably alone in this, but I find software like iMovie amazing. As a teen making films on a Hi-8 camera, we had to edit either in camera with some judicial timing of the record button or try and stitch clips together with a hopelessly inaccurate VHS machine. We then graduated to using a two-deck VHS assemble editor when at Sixth-form college, which gave us the semblance of accuracy. The pinnacle of control was filming with Super-8 and then manually splicing together film, holding up frames to a lightbulb (hello burnt retina!) to find the perfect cut. So the fact you put together a video in iMovie insanely quickly is pretty insanely great.

When Apple ditched the traditional timeline with iMovie ’08, there was much uproar. Admittedly iMovie ’08 lost quite a lot of features and was a bit confusing, but over the next few updates it regained its skills and took things further. Tools like the precision editor and the advanced ‘cutaway’ option when inserting a clip let you do things that would be fiddly and confusing when using an older ‘timeline’ editor. I’ve never used Final Cut Pro X, but I can completely see why they’ve taken the iMovie ideas and extended them.

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.

Lion and interactive whiteboards

Today I made the happy discovery that even our aged 580 series Smartboards work with Lion. Yay! Our school has been gradually buying Smartboards over the last decade, which means some classrooms have some very antique models (with serial to USB cables and the old-style round erasers.  I once rang Smart’s UK technical support about one of these boards and they were in complete shock that they still worked at all…). I was not looking forward to paying thousands to replace them when we either bought new Lion Macs or upgraded from Snow Leopard.

Smart still claim that OSX 10.7 isn’t officially supported by their Notebook software, but they have released a patch that fixes things up well enough.

London Mail made useful!

LGfL (London Grid for Learning) offer a wide variety of services for schools, including a Microsoft-hosted ‘London Mail’ for use by children in schools. This includes features such as ‘safe mail’ where you can control who the user can send and receive email with.

The only problem is that it requires children to remember their USO login details to access it, which is not the most memorable string of letters and numbers in the world. My experience is that email for children is therefore often underused in the classroom.

At our school we’re running a trial classroom with an emphasis on more independent learning. Part of this was to email work to groups of children that they can then access at one of the classroom iMacs. But with email access requiring putting in obscure usernames and passwords and visiting obtuse websites, it never really happened.

Whilst perusing LGfL’s website, I discovered a new section about London Mail where they promised access for smartphones and with Outlook, so I contacted Atomwide and they sent me the login details.

It requires Outlook IMAP access, which can be done natively in Apple’s Mail, and was very easy to sort out. Now one child just has to log onto one of the iMacs and open Mail – easy!

For this interested, here are the server details:

  • username: uso.account@lgflmail.net
  • Incoming hostname: imap.outlook.com
  • Outgoing hostname: amsprd0102.outlook.com

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.

The curse of .local

When Toucan first installed our suite of iMacs, we had a simple Active Directory (AD) integration setup, authenticating and accessing network home folders from our Windows Server 2003  Active Directory.  This worked well, with fast log-on speeds and generally playing properly.  However, over the year the login speeds started to deteriorate.  I originally thought this was because we had installed a Mac Mini server to add some golden triangle goodness to our network, so didn’t investigate much further.  Unfortunately, things took a turn for the worse at the end of October 2011 when all the Macs decided that they wouldn’t log onto our AD any more, instead just showing the red light and ‘Network accounts not available’.

Understandably, this wasn’t so great, especially as one of the reasons for getting some Macs in the first place was that they ‘just work’.  Really bad is probably a better way to put it.

After much Internet research, we managed to get things working a little bit by doing the following:

  • creating computer accounts for each Mac on the AD before binding each machine
  • rebinding each machine, making sure we put in the IP address in Directory Utility where it says ‘Prefer this domain server’ and unchecking the box for ‘allow authentication from any domain in the forest’

This still wasn’t a very reliable solution, with the dreaded network red light still appearing regularly and log-on times taking up to six minutes.  It was like returning to the good old bad days of a decrepit ICT suite of aged XP machines…nooooo!

It turned out that the problem was because our internal domain ended with .local.  Apple uses this for its Bonjour technologies and, despite several possible hacks suggested by Apple (involving mdns_timeout and IPv6), things weren’t getting any better or likely to anytime soon.  Apparently Apple changed the way Macs resolve DNS around 10.6.7/8 in order to get ready for Lion.  The couple of Lion machines we had weren’t working at all with our AD so something needed to be done.

In the end we decided to change our domain.  Not an easy task (so I’m told) so our technician suggested buying a cheap new Windows 2008 Server and setting up a new .sch domain on it.  We would bind all the Macs to that server, leaving the PCs as they were and with the old server still doing all the file sharing for the network homes and shared drives.

We did the transition on a day when no teachers were in and managed to set up a new server and bind 50 machines in a day…not bad!  The only major snag was that all the home folder permissions on any existing network accounts on a machine didn’t work any more, resulting in not being allowed to look in the ~/Pictures, ~/Library folder etc.  Looking back we probably could have figured out how to reset the permissions, but instead we just deleted every account off every machine so that they would get freshly created on login.  Most children’s work gets saved to network folders so we only had to make sure we rescued any iMovie projects or important files saved to teacher’s desktops.

It was a bit of a job to sort out, and we now have two independent yet interconnected domains on our curriculum network, but things are now working much, much better (including our now fully-functioning Lion machines). Our technician is planning to wipe the old server during a holiday so we only have one domain, but I’m sure that’ll be another tale.