gonchik / munki

Automatically exported from code.google.com/p/munki
Other
0 stars 0 forks source link

Criticality key in pkginfo #75

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I propose flushing out the details of adding a criticality key to the pkginfo 
.plist.  

This key would allow the munki admin to controll how important a package is to 
be installed on their systems.  If it is a critical security threat, the 
machine MUST install it now, but if it is a minor update to non-essential 
application, the user should be able to ignore it until tomorrow or at least 
later in the day.  Depending on the value of the key, the user will be provided 
with escalating types of responses.

There are four values that I'm currently proposing.  

Ignore - This value would allow the user to do exactly what is done now.  They 
can choose later and it will pop-up again around the same time tomorrow.

Postpone - This value would allow the user to postpone the install until a 
later time (admin configurable) via choosing "Install in x minutes/hours".  
After that duration, the MSU dialog would pop up again and ask the user what to 
do and again, the user would be able to postpone if they would like.  They 
would also be able to keep working over top of the MSU dialog if they would 
like.  

The admin could define the available postpone options in a dictionary set in 
the ManagedInstalls.plist file under a PostponeOptions key.  Each subentry 
would have 2 values: Length (in minutes) and DisplayName (as string) ie. 
Length: 120, DisplayName: "2 hours".

RequireGentle - This value would initiate a dialog that says the system has 
important updates that need to be installed now and will initiate a soft 
logout.  If the user is working on something they would be allowed to save 
changes and exit.  We would have to hash out  if we want it to escalate to 
force logout after 15 or 30 minutes of inactivity.  

RequireForce - As you would expect, this value would tell the user that 
critical updates need to be installed, and they will be forced to logout 
immediately and will loose any changes.

The system will act with the highest level of criticality in a string of 
packages that need to be installed.  So... if you have two packages that are 
set to Ignore, one that is set to Postpone, and one that is set to 
RequireGentle, the system will RequireGentle.  If the Criticality key is not 
set, Ignore will be assumed.

I recognize that currently, only a small subset of this functionality currently 
exists within the code base and in order to facilitate this functionality, some 
major work/research will need to be done.  However, based on the commercial 
products I've seen, these features are big selling points and will help munki 
gain wider acceptance long term.  I'm interested in working on this but would 
like to hear others responses and would like to see if this is an exhaustive 
list of functionality that users would like in this area of munki.

Original issue reported on code.google.com by ricky.ch...@gmail.com on 3 Apr 2011 at 3:21

GoogleCodeExporter commented 8 years ago
This seems to overlap with the existing forced_install and forced_uninstall 
keys and some in-development work around force installing after a certain date.

Original comment by gregnea...@mac.com on 4 Apr 2011 at 3:35

GoogleCodeExporter commented 8 years ago
http://code.google.com/p/munki/wiki/PkginfoFiles#Forced_Installs_and_Uninstalls 
I've seen this before, but there are some questions I have about this that 
aren't clear in the docs..  If a given installer does not need to logout, what 
does it do?  If it needs to logout, what does it do? Same for restart?  Does it 
do these things gently or more forcefully?

Original comment by ricky.ch...@gmail.com on 5 Apr 2011 at 2:43

GoogleCodeExporter commented 8 years ago
It appears that unattended_installs and force_install_after_date are sufficient 
for most of the real-world scenarios; there have been no additional requests 
along these lines.

Original comment by gregnea...@mac.com on 13 Mar 2013 at 4:30