installing updates at login + lockscreen

[rockpapergoat]

I'm looking to mimic the functionality Munki has for installing updates but using Casper's built-in tools.

Basically, with Munki, the user will see a window once a day that looks similar to Apple's Software Update. The options at that point are to cancel (defer the install till later), logout and install (recommended for most installs), or stay logged in and install (not recommended, generally). It's also possible to force a logout, just to be safe. Upon logout, the user will see a progress dialog until the updates are done installing, then the machine will drop back to the login window or reboot, as needed.

I've done some experimenting with jamfHelper to pop up a full screen window, similar to what happens for firstboot installs via Casper Imaging. The problems I see there are:

1. jamfHelper will only run within the login context, so it requires a logged in user. Triggering a login policy to install updates should satisfy this requirement.
2. The user can quit the jamfHelper window. If there's a way to prevent this until the updates are finished (or the machine reboots), please let me know.

How and when do you install OS and other major app updates in your environments? What do you find works best?

Thanks,

Nate

[tlarkin]

Looks like Mr Neagle just announced it today

http://groups.google.com/group/reposado?pli=1

haha

[bentoms]

So you could use Munki to install os & application updates... with user notification.

Could you then use casper's nw segments & a script to point the Munki app at the local sites Munki server (& Casper distro point) to stop it pulling data across a wan?

Regards,

Ben.

[golbiga]

One more step towards my JSS running on a linux box.

On Apr 26, 2011, at 3:05 PM, Thomas Larkin wrote:

Looks like Mr Neagle just announced it today

http://groups.google.com/group/reposado?pli=1

haha

[#5]

I'm thinking Munki is actually exactly what you want. It's a shame it's so lacking in documentation, and that it takes so much effort to set up. Munki can be configured to only handle updates from Apple (or whatever update server you point it at) and nothing else.

At some point I plan to figure out how I want to set this up, then I'll start pushing out Munki to all the Macs here.

[rockpapergoat]

Right. I use munki pretty much everywhere else, but my one big client uses Casper, and resources in house are more familiar with it than munki. I'm looking to keep moving parts to a minimum here.

If Casper can do this, I'd rather use the tools at hand.

Otherwise, I know munki does exactly what I want and what the client needs. It's more of a supportability issue than a "right tool for the job" issue right now.

There's lots of documentation for munki and a very active user community. It's also open, so you can change and submit patches as you see fit.

[tlarkin]

Sorry if this has been mentioned, but have you looked at Growl Notify, self service and a Casper policy to trigger updates with users?

[#8]

I'm pretty sure Casper does not provide a solution for this, unfortunately.

It only seems to have two user-facing applications: Self Service and jamfHelper. I suspect JAMF decided somewhere along the line that they don't want to get into user-facing notifications themselves, beyond providing a simple dialog box. After all, they are clearly not UI experts (no offense intended).

Munki seems a natural way to fill this gap, if only it could be easily integrated...

[rockpapergoat]

Self Service and an update policy are in place already.

Security and other updates need to be installed for security policy compliance, so we need to ensure this happens.

growlnotify doesn't provide the functionality I'm looking for here.

Basically, munki works. I need Casper to do the same, if possible.

[#10]

Hmm, can you point me to a good tutorial?

[#11]

I think you'll need to write your own application, then. Or modify Munki...

[tlarkin]

I am looking at Radmind with Casper as a tripwire, so when systems don't have proper configurations they get it (like mismatching versions or lack of updates) but I haven't had time to build a test environment yet.

I have read the documentation of Munki and it seems alright, but would you also use puppet for the silent installs?

[rockpapergoat]

I think it can be integrated, even if it's clunky, like using Casper to trigger manual munki runs at scheduled times/login or something.

It should also be possible to install it on the same server and use the same repository. When using munki, there's almost no reason to use Casper for app installs or updates, though.

Hence, another reason for my hopes that Casper can provide this functionality in some fashion…

[rockpapergoat]

This one's okay: http://www.osxdeployment.info/wiki/Munki_Guide

Direct questions to the list, which is full of great information: http://groups.google.com/group/munki-dev/topics

The "getting started" wiki page walks through a quick setup: http://code.google.com/p/munki/wiki/GettingStartedWithMunki

If you're interested, participate in the list discussion. You'll learn quickly.

The fact that Google's using this stuff should say something about its effectiveness.

[tlarkin]

What I do is set a self service policy for software update, then set
growl to notify the user of the updates and give them 5 days to install
said update. After 5 days their system gets it as a forced policy.

[rockpapergoat]

I'd use puppet over radmind, but that's only because I have more experience there (and the community is way more active).

When using munki, I would only use puppet for configuration management, not installs or updates. There's too much overlap, and munki handles those aspects more smoothly.

It sort of depends on how much user interaction you want. If you want some, use munki. If you want none and need to manage the machines more closely, use puppet for installs and updates.

So, to answer your question, I'd use one or the other, not just puppet for silent installs.

Basically, once you're on the path to using either munki or puppet, you're firmly on the modular path and in a good spot to use either however makes sense.

[tlarkin]

I was looking at Radmind as a tripwire to detect misconfiguration, ie non approved software installed, or a system is not up to date, and would use it to trigger an update. I looked at Munki and puppet, as well as Radmind but never dove too deep into it. With budget issues you never know where the bean counters will cut funding, so I was looking for back up plans just in case.

I feel that Munki has a higher learning curve in some regards. Radmind seems pretty straight forward once you dive into it. I have a 1 server and 2 client test environment set up with Radmind right now. However, the UI seems a bit convoluted if I were to add 6,000 computer entries into it.

How well does Munki scope out? I have 8,000 Macs in about 15 different buildings that need different software packages, and how well would Munki play with Casper you think?

thanks, tom

[#18]

Munki ignores Casper, and Casper ignores Munki. In that respect, they play nicely together, but it also means you'd have a hard time unless you set a clear divide on which one manages which packages.

On Apr 26, 2011, at 2:22 PM, Thomas Larkin wrote:

I was looking at Radmind as a tripwire to detect misconfiguration, ie non approved software installed, or a system is not up to date, and would use it to trigger an update. I looked at Munki and puppet, as well as Radmind but never dove too deep into it. With budget issues you never know where the bean counters will cut funding, so I was looking for back up plans just in case.

I feel that Munki has a higher learning curve in some regards. Radmind seems pretty straight forward once you dive into it. I have a 1 server and 2 client test environment set up with Radmind right now. However, the UI seems a bit convoluted if I were to add 6,000 computer entries into it.

How well does Munki scope out? I have 8,000 Macs in about 15 different buildings that need different software packages, and how well would Munki play with Casper you think?

thanks,
tom

[tlarkin]

So you could use Munki for software update and ditch your SUS? Right now I use Apple's SUS and my policy works as it is user triggered and after a week it is forced update.

[rockpapergoat]

No, munki uses your SUS (or apple's, if you don't define that).

If you want to download all the apple updates and have munki install them, I guess, technically, the answer is yes.

Greg is working on a software update server replacement. I'm eagerly awaiting the release.

[#21]

Munki can be pointed at your SUS. SUS is the backend, Munki is the frontend.

If you set it up to do so, Managed Software Update will launch automatically on the client when your SUS has an update available. It then allows the user to install the update similarly to the built-in Software Update, but without requiring an admin.

Managed Software Update can also be configured to distribute other packages in the same way, without having to deal with multiple applications. It all shows up in the same list.

Your SUS continues to play its part; Munki just allows the user experience to be better and more secure.

On Apr 26, 2011, at 2:37 PM, Thomas Larkin wrote:

So you could use Munki for software update and ditch your SUS? Right now I use Apple's SUS and my policy works as it is user triggered and after a week it is forced update.