munkitools-0.8.2.1425.0.mpkg.dmg available
Greg Neagle
http://munki.googlecode.com/files/munkitools-0.8.2.1425.0.mpkg.dmg
This is a preview release of munkitools 0.8.2.
Changes in this release:
- managedsoftwareupdate now uses an HTTP user-agent string compatible with Apple's software update client when requesting software update catalogs. This should allow use of "unified" catalog URLs, which use server-side Apache rewrite rules.
- Support for a new installer_environment dictionary which contains key/value pairs to set environment variables for use by /usr/sbin/installer
- MSU.app now warns if a user decides to update while on battery power and less than 50% of battery power remains.
- Changes to Adobe CS4 installs -- will attempt to kill stalled Adobe AIR installations at the loginwindow
- makecatalogs now warns if it would overwrite an existing catalog. This partially addresses an issue with munki server data on a case-insensitive volume and catalog names that differ only by case.
- MSU.app now not called to notify the user until after the postflight script has finished executing.
- Application inventory now written to /Library/Managed Installs/ApplicationInentory.plist for use by reporting scripts.
- Other miscellaneous tweaks and bug fixes. See the change list at http://code.google.com/p/munki/source/list for more detail. This release's changes are from late November 2011 through Feb 10, 2012.
-Greg
Childress, Matt
If managedsoftwareupdate is called via a script that presents no user interface, is there any sort of override setting based on battery percentage (or a plan in the works)? The release notes aren't very specific on how this operates but the feature request (http://code.google.com/p/munki/issues/detail?id=109) seems to indicate there's either more happening behind the scenes than the notes indicate or to-be-developed.
I could work on implementing it into my login/logout hooks (if battery < 50 and not ExternalPowerConnected, then don't run munki), but...
Scenario:
Mac laptop cart at a school (ie, can't count on user doing the updates via GUI). Laptops only have network connectivity (wireless) once the user logs in (802.1x authentication using the loginwindow credentials). Class periods are about 50 minutes long.
So I'm figuring rather than letting munki randomize the execution time to instead use a Loginhook to call managedsoftwareupdate --checkonly (nice'd it) to check and download updates as soon as the user logs in (when there should be network). Then a logouthook to run managedsoftwareupdate --installonly.
But I don't want either process to run if battery isn't >50% full... definitely not the install logouthook as I don't want to risk corruption, but also the --checkonly/download so that I'm not running the battery down during class time.
M@
Greg Neagle
No additional logic around battery power exists anywhere in the code.
At the time I was implementing that, I asked for opinions on whether or not the behavior for background/automatic runs should be altered depending on power status:
http://groups.google.com/group/munki-dev/browse_thread/thread/0c7d0bf2b72ff848
There was no real consensus on that, so I left the behavior unchanged.
See some more comments in-line below.
On Feb 25, 2012, at 9:45 PM, Childress, Matt wrote:
> Regarding the battery warning option in 0.8.2 release notes:
>
> If managedsoftwareupdate is called via a script that presents no user interface, is there any sort of override setting based on battery percentage (or a plan in the works)? The release notes aren't very specific on how this operates but the feature request (http://code.google.com/p/munki/issues/detail?id=109) seems to indicate there's either more happening behind the scenes than the notes indicate or to-be-developed.
>
> I could work on implementing it into my login/logout hooks (if battery < 50 and not ExternalPowerConnected, then don't run munki), but...
>
> Scenario:
> Mac laptop cart at a school (ie, can't count on user doing the updates via GUI). Laptops only have network connectivity (wireless) once the user logs in (802.1x authentication using the loginwindow credentials). Class periods are about 50 minutes long.
>
> So I'm figuring rather than letting munki randomize the execution time to instead use a Loginhook to call managedsoftwareupdate --checkonly (nice'd it) to check and download updates as soon as the user logs in (when there should be network).
Couldn't that dramatically delay the login? Loginhooks run to completion before allowing login. Or are you kicking it off in the background from a loginhook?
> Then a logouthook to run managedsoftwareupdate --installonly.
Better probably to just touch "/Users/Shared/.com.googlecode.munki.installatstartup", which will cause Munki to install any available updates at the next logout or restart.
>
> But I don't want either process to run if battery isn't >50% full... definitely not the install logouthook as I don't want to risk corruption, but also the --checkonly/download so that I'm not running the battery down during class time.
I'm not sure managedsoftwareupdate could be easily modified to meet your needs without causing issues for others. Consider this:
Right now, managedsoftwareupdate does not check for or react to power source at all.
The GUI Managed Software Update.app does check, and warns the user if they elect to update and they are on battery power and the battery level is under 50%.
Since it's just a warning, users can elect to proceed anyway.
This means we cannot have managedsoftwareupdate 'automatically' skip installs when a machine is on battery power and the battery level is under 50% -- it would fail to install even when the user told it to.
So instead we have to be more selective about which mode we are in when running managedsoftwareupdate; for example, doing the power source check and reacting to it only during an "--auto" run.
But that's _not_ what you are using for your updates -- you'd be doing it during a "custom" run of the tool, or possibly during a "logoutinstall" type run. If we refuse to install on low battery during a "logoutinstall", then we're back to the original problem of managedsoftwareupdate skipping installs even when the user has indicated to install anyway.
If we refuse to install during a "custom" run, we take away the ability for admins to run updates via command-line even if the battery is under 50%.
We could add a new option: --bailonlowbattery (or similar) that admins could include in custom scripts, or perhaps a new preference in ManagedInstalls.plist to control this behavior, but it seems that this will require additional discussion and thought.
Since I am unaware of a single problem caused by Munki attempting to install software on low battery, this hasn't been very high on my list of things to work on.
-Greg