Fwd: [munki] push by gregnea...@mac.com - MSU.app now displays a warning if user chooses to update while on batt... on 2011-12-06 22:29 GMT
Greg Neagle
From: mu...@googlecode.comSubject: [munki] push by gregnea...@mac.com - MSU.app now displays a warning if user chooses to update while on batt... on 2011-12-06 22:29 GMTDate: December 6, 2011 2:30:18 PM PSTTo: gregn...@mac.comRevision: 69419d939b35
Author: Greg Neagle <Gregn...@mac.com>
Date: Tue Dec 6 14:29:53 2011
Log: MSU.app now displays a warning if user chooses to update while on battery power.
http://code.google.com/p/munki/source/detail?r=69419d939b35
Modified:
/code/Managed Software Update/MSUAppDelegate.py
/code/Managed Software Update/munki.py
=======================================
--- /code/Managed Software Update/MSUAppDelegate.py Tue Dec 6 14:00:08 2011
+++ /code/Managed Software Update/MSUAppDelegate.py Tue Dec 6 14:29:53 2011
@@ -641,11 +641,11 @@
power_info = munki.getPowerInfo()
if power_info.get('PowerSource') == 'Battery Power':
alert = NSAlert.alertWithMessageText_defaultButton_alternateButton_otherButton_informativeTextWithFormat_(
- NSLocalizedString(u"Your computer is not connected to a power source", None),
+ NSLocalizedString(u"Your computer is not connected to a power source.", None),
NSLocalizedString(u"Cancel", None),
NSLocalizedString(u"Continue", None),
objc.nil,
- NSLocalizedString(u"For best results, you should connect your computer to a power source before updating. Are you sure you want to continue the update?", None)
+ NSLocalizedString(u"For best results, you should connect your computer to a power source before updating. Are you sure you want to continue the update?", None))
munki.log("MSU", "alert_on_battery_power")
buttonPressed = alert.runModal()
if buttonPressed == NSAlertDefaultReturn:
=======================================
--- /code/Managed Software Update/munki.py Mon Dec 5 11:16:12 2011
+++ /code/Managed Software Update/munki.py Tue Dec 6 14:29:53 2011
@@ -434,7 +434,7 @@
if not matching_items:
# try adding '.app' to the name and check again
matching_items = [item for item in proc_list
- if '/'+ appname + '.app/' in item]
+ if '/' + appname + '.app/' in item]
matching_items = set(matching_items)
for path in matching_items:
@@ -457,7 +457,7 @@
cmd = ['/usr/bin/pmset', '-g', 'ps']
proc = subprocess.Popen(cmd, bufsize=-1, stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
- (output, error) = proc.communicate()
+ (output, unused_error) = proc.communicate()
if proc.returncode:
# handle error
return power_dict
@@ -465,22 +465,22 @@
# output from `pmset -g ps` looks like:
#
# Currently drawing from 'AC Power'
- # -InternalBattery-0 100%; charged; 0:00 remaining
+ # -InternalBattery-0 100%; charged; 0:00 remaining
#
# or
#
# Currently drawing from 'AC Power'
- # -InternalBattery-0 98%; charging; 0:08 remaining
+ # -InternalBattery-0 98%; charging; 0:08 remaining
#
# or
#
# Currently drawing from 'Battery Power'
- # -InternalBattery-0 100%; discharging; (no estimate)
+ # -InternalBattery-0 100%; discharging; (no estimate)
#
# or
#
# Currently drawing from 'Battery Power'
- # -InternalBattery-0 100%; discharging; 5:55 remaining
+ # -InternalBattery-0 100%; discharging; 5:55 remaining
#
line = output.splitlines()
if 'AC Power' in line[0]:
@@ -506,7 +506,7 @@
except (IndexError, ValueError):
pass
- return power_dict
+ return power_dict
def setupLogging(username=None):
Justin McWilliams
> As of git revision 69419d939b35, Managed Software Update.app now displays a
> warning if a user chooses to update while the machine is on battery power.
> The user can choose to Continue or Cancel.
>
> Some possible refinements, up for discussion:
>
> 1) Should we always display this warning when on battery power, or only if
> the battery charge percentage is below a certain level or if the estimated
> runtime is less than a certain number of minutes?
I would say only bail if battery power is below a threshold, except in
the case of firmware updates. I don't feel strongly though.
> 2) Should auto/periodic runs of managedsoftwareupdate perhaps bail out early
> once we get below a certain percentage/time remaining? Should we check the
> battery again if we have a list of installs/removals before we start any
> installs or removals?
I would prefer to not exit in this case. Do we have evidence of what
amount of battery an average execution uses? I would imagine it's not
even measurable since it's so small. Installs/removals may use a bit
more, but I'd prefer to continue onward regardless if they're
unattended/forced.
Edward Marczak
> On Tue, Dec 6, 2011 at 2:36 PM, Greg Neagle <gregn...@mac.com> wrote:
>> As of git revision 69419d939b35, Managed Software Update.app now displays a
>> warning if a user chooses to update while the machine is on battery power.
>> The user can choose to Continue or Cancel.
>>
>> Some possible refinements, up for discussion:
>>
>> 1) Should we always display this warning when on battery power, or only if
>> the battery charge percentage is below a certain level or if the estimated
>> runtime is less than a certain number of minutes?
>
> I would say only bail if battery power is below a threshold, except in
> the case of firmware updates. I don't feel strongly though.
Agreed. Firmware updates are the only real 'special' ones here. Even
an Xcode install will complete on
30%. (Not counting really old, unreliable batteries, although you can
get those type of stats, too.)
>> 2) Should auto/periodic runs of managedsoftwareupdate perhaps bail out early
>> once we get below a certain percentage/time remaining? Should we check the
>> battery again if we have a list of installs/removals before we start any
>> installs or removals?
>
> I would prefer to not exit in this case. Do we have evidence of what
> amount of battery an average execution uses? I would imagine it's not
> even measurable since it's so small. Installs/removals may use a bit
> more, but I'd prefer to continue onward regardless if they're
> unattended/forced.
Also agreed.
--
Edward Marczak
w: http://www.radiotope.com/writing
p: http://profiles.google.com/edwardmarczak
Greg Neagle
On Dec 6, 2011, at 6:20 PM, Edward Marczak wrote:
> On Tue, Dec 6, 2011 at 8:49 PM, Justin McWilliams <og...@google.com> wrote:
>> On Tue, Dec 6, 2011 at 2:36 PM, Greg Neagle <gregn...@mac.com> wrote:
>>> As of git revision 69419d939b35, Managed Software Update.app now displays a
>>> warning if a user chooses to update while the machine is on battery power.
>>> The user can choose to Continue or Cancel.
>>>
>>> Some possible refinements, up for discussion:
>>>
>>> 1) Should we always display this warning when on battery power, or only if
>>> the battery charge percentage is below a certain level or if the estimated
>>> runtime is less than a certain number of minutes?
>>
>> I would say only bail if battery power is below a threshold, except in
>> the case of firmware updates. I don't feel strongly though.
>
> Agreed. Firmware updates are the only real 'special' ones here. Even
> an Xcode install will complete on
> 30%. (Not counting really old, unreliable batteries, although you can
> get those type of stats, too.)
Just to clarify: the current implementation only warns – it doesn't "bail". So my question is should we always display a warning if we are on battery power, or only if we have less than a certain amount of runtime? This is more of a user experience question.
>>> 2) Should auto/periodic runs of managedsoftwareupdate perhaps bail out early
>>> once we get below a certain percentage/time remaining? Should we check the
>>> battery again if we have a list of installs/removals before we start any
>>> installs or removals?
>>
>> I would prefer to not exit in this case. Do we have evidence of what
>> amount of battery an average execution uses? I would imagine it's not
>> even measurable since it's so small. Installs/removals may use a bit
>> more, but I'd prefer to continue onward regardless if they're
>> unattended/forced.
>
> Also agreed.
Thanks for your votes!
-Greg
John Randolph
Just to clarify: the current implementation only warns – it doesn't "bail". So my question is should we always display a warning if we are on battery power, or only if we have less than a certain amount of runtime? This is more of a user experience question.
On Dec 6, 2011, at 6:20 PM, Edward Marczak wrote:
> On Tue, Dec 6, 2011 at 8:49 PM, Justin McWilliams <og...@google.com> wrote:
>> On Tue, Dec 6, 2011 at 2:36 PM, Greg Neagle <gregn...@mac.com> wrote:
>>> As of git revision 69419d939b35, Managed Software Update.app now displays a
>>> warning if a user chooses to update while the machine is on battery power.
>>> The user can choose to Continue or Cancel.
>>>
>>> Some possible refinements, up for discussion:
>>>
>>> 1) Should we always display this warning when on battery power, or only if
>>> the battery charge percentage is below a certain level or if the estimated
>>> runtime is less than a certain number of minutes?
>>
>> I would say only bail if battery power is below a threshold, except in
>> the case of firmware updates. I don't feel strongly though.
>
> Agreed. Firmware updates are the only real 'special' ones here. Even
> an Xcode install will complete on
> 30%. (Not counting really old, unreliable batteries, although you can
> get those type of stats, too.)
Thanks for your votes!
>>> 2) Should auto/periodic runs of managedsoftwareupdate perhaps bail out early
>>> once we get below a certain percentage/time remaining? Should we check the
>>> battery again if we have a list of installs/removals before we start any
>>> installs or removals?
>>
>> I would prefer to not exit in this case. Do we have evidence of what
>> amount of battery an average execution uses? I would imagine it's not
>> even measurable since it's so small. Installs/removals may use a bit
>> more, but I'd prefer to continue onward regardless if they're
>> unattended/forced.
>
> Also agreed.
-Greg
John Randolph -- Google New York -- Corp Platforms Eng
Anurag Mohanty
Justin McWilliams
And I would vote the other way. I think the less times we warn users
unnecessarily the better. If we warn people every time they're on
battery, they'll learn to ignore the warnings and miss those that
really matter, like when battery is dangerously low.
John Randolph
Greg Neagle
Greg Neagle
> My point is that the warning calculation is more complicated than we should attempt to model, especially since we know we are about to kick up installers which will change battery usage rate.
The calculation doesn't have to be very clever or accurate. We could just decide to display the warning only when we were under 50% charge. This would have the effect of not bugging most users most of the time, while causing them to think a bit when their battery was less than half charged.
We will also need a way to say an update _requires_ AC power; for normal Munki updates, this could be a new key in the pkginfo. If we ever implement auxiliary info for Apple updates, we could use the same key there, too. But we may want Munki to be conservative and insist on power for all Apple firmware updates.
-Greg
Mike Pullen
Mike
Justin McWilliams
for two different laptops, the vast majority of the time this will be
sufficient to perform any install. For the cases where batteries that
have 50% only last a few minutes, the user is likely already aware of
this and probably not on battery for extended periods anyways. I'd
rather have less than ideal experience for the edge cases and less
warnings for the masses.
Nate
Childress, Matt
Speaking of batteries and the concerns about installing updates when on battery…
I’ve been working on setting up a Mac Laptop cart with the newly hardware refresh of the MacBook Pro (trying to get them to netboot was a major nightmare – literally up til 3am and still not working ideally off the DHCP server options)
With regards to Munki, I’m trying to figure out the best way to setup munki for a high school laptop cart:
* In our environment we have 802.1X/WPA2 enterprise wireless network
* Due to security policy coming down from up above, we’ve set the machines up so that the credentials
entered at the login window are used to login to the wireless network
* That means that unless there’s a user logged in, the machine will not be connected to the network
* so we need to download the updates when a user is logged in
The goals are the usual, but with a little more constraints:
As little impact as possible on teaching/learning time.
As automated as possible so little impact on IT staff time.
Questions/thoughts:
The discussion about battery and updates is interesting: I *think* I want to download the updates but most likely not install them until the cart is back in its home and plugged into power (that way if the cart is used in back-to-back-to-back classes, I’m not needlessly sucking down the battery).
* but will this work if the laptop goes to sleep once it’s closed (to be put away in the laptop cart)?
* what are the heat implications of running updates with a closed screen and on AC power?
* what options are available through munki (and elsewhere) to configure this? I think the new power/battery option will be very helpful, as well as the SuppressUserNotification option -- but is there network/cpu throttling (so the updates don’t suck up all the available wireless networking)?
Basically I’m asking has anyone else been down this road before with munki (and other tools) and what worked/works best… feel free to point me to the stuff I couldn’t find on google… my google fu is off this morning L
M@
Greg Neagle
I'd prefer to simply wait for AC power to install the firmware update rather then bug the user with it. I agree that they will eventually just treat it as another "Don't bother reading and just click-later" type dialog.As far as auto-installs are concerned, I wasn't clear if anything was being changed in regards to firmware. I'd prefer if on battery, munki would not do firmware updates. I've already bootstrapped a machine whilst on battery and it got stuck in a loop as a result of a Firmware update that required AC power to install.
Greg Neagle
Speaking of batteries and the concerns about installing updates when on battery…I’ve been working on setting up a Mac Laptop cart with the newly hardware refresh of the MacBook Pro (trying to get them to netboot was a major nightmare – literally up til 3am and still not working ideally off the DHCP server options)With regards to Munki, I’m trying to figure out the best way to setup munki for a high school laptop cart:* In our environment we have 802.1X/WPA2 enterprise wireless network* Due to security policy coming down from up above, we’ve set the machines up so that the credentialsentered at the login window are used to login to the wireless network* That means that unless there’s a user logged in, the machine will not be connected to the network* so we need to download the updates when a user is logged inThe goals are the usual, but with a little more constraints:As little impact as possible on teaching/learning time.As automated as possible so little impact on IT staff time.Questions/thoughts:The discussion about battery and updates is interesting: I *think* I want to download the updates but most likely not install them until the cart is back in its home and plugged into power (that way if the cart is used in back-to-back-to-back classes, I’m not needlessly sucking down the battery).* but will this work if the laptop goes to sleep once it’s closed (to be put away in the laptop cart)?
* what are the heat implications of running updates with a closed screen and on AC power?* what options are available through munki (and elsewhere) to configure this? I think the new power/battery option will be very helpful, as well as the SuppressUserNotification option -- but is there network/cpu throttling (so the updates don’t suck up all the available wireless networking)?Basically I’m asking has anyone else been down this road before with munki (and other tools) and what worked/works best… feel free to point me to the stuff I couldn’t find on google… my google fu is off this morning L
Raúl Cuza
Ultimately, the only 100% reliable solution is to exclude firmware updates from the Software Update catalog Munki uses and to handle firmware updates outside of Munki. Anything else is a partial solution only and still requires admin vigilance.
Sent from my eMate 300
Greg Neagle
Ultimately, the only 100% reliable solution is to exclude firmware updates from the Software Update catalog Munki uses and to handle firmware updates outside of Munki. Anything else is a partial solution only and still requires admin vigilance.A package blacklist on the client would be one way to prevent Apple firmware updates from being installed. It would also give environments who allow their clients some autonomy a way for clients to op out of a package without having to make a special manifest for them.
Raúl Cuza
Sent from my eMate 300
Greg Neagle
I agree that we need to control which packages the client sees using reposado or other manages ASU.I was thinking the blacklist would allow the firmware update to be available in the repo so it can be installed outside of munki (e.g. manually) but not installed by munki. With just controlled repos, the manual run would have to point to a different repo than a munki run.
