locking screen at loginwindow

Nate,

Just curious, how does Munki handle this, via it's own framework or what? You could also script it, where you use a manual trigger policy to run software update then force a reboot, and it should work.

-Tom

i got it to work sort of reliably yesterday with a login trigger, but i'd rather be able to install at the loginwindow as soon as the machine is booted. in this case, i'll probably use whatever works for my client, using casper.

munki checks whether there's nobody logged in, runs the Managed Software Update.app within the loginwindow context to install/uninstall anything pending, and then either drops back to the loginwindow or reboots (as required by any updates). there are no special frameworks, really. the entire munki tools client install is pretty small -- basically some launchd jobs, a bunch of python scripts, and the MSU.app. it's a pretty seamless process. in the background, at least once a day, munki checks for updates/installs/uninstalls/removals via launchdaemon, downloads via curl and caches any payload locally, then at some point once that day pops up a Managed Software Update.app window with the items waiting to be acted on. the UI looks almost like apple's software update, so people are generally familiar with it and do the right thing.

i have a long, unscripted, and possibly boring screencast for basic munki setup here: http://vimeo.com/23595634

feel free to skip past the long boring parts where i should have cut (vs. all the other boring parts) …

Does it actually kill the loginwindow process, and then bring it back
upon completion? I got a feeling this could all be scripted and I also
got a feeling a lot of Munki stuff is probably built in Python given
Google's love affair with Python.

-Tom

yes, munki kills the loginwindow. it's also not developed by google, though they are using it internally.

check the source here: http://code.google.com/p/munki/source/browse/

I haven't looked at munki beyond checking out the web site, but this sounds
On Wed, Aug 17, 2011 at 9:41 AM, Nate St. Germain <nate at techsuperpowers.com>wrote:
like it behaves a lot like Radmind.

I have a hunch that you could probably use iHook to lock the login window,
or hide it, so that a user could not login while you were performing
updates. The part I'm unsure about is how to "watch" for the machine to be
at the login window. Of course, that might just be because I've been
battling with my servers and desktops this week and haven't had time to
think clearly.

I'll try to squeeze some time later this morning to test iHook and reply
back to the list.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

Radmind watches the file system and triggers policy, install, or
whatever on file system changes. It also has the ability to "roll
back," file systems. I played with it briefly not too long ago out of
interests of another job i was looking at. Munki is more a client based
(similar to Casper in that regard) that then does installs based on
manifest lists on the Munki Server. So you have catalog files the
client compares to, and then installs based on that.

At least that is how I understand it, and I will like to put forth the
disclaimer that I haven't really used either at all professionally, and
just barely looked into them out of curiosity.