installonly options
Greg Neagle
unattended_install (formerly "forced_install") is one approach to this problem, but the item he wanted to install actually required a couple of other items, and until recently, unattended_installs did not work with items that depended on other items. I've since addressed that.
Still the original request seems reasonable. The Managed Software Updates GUI probably will never allow users to cherry-pick updates, since the idea is that _you_ are managing the updates (at least for those items in managed_installs and managed_updates); Managed Software Updates.app merely allows the user some flexibility as far as the timing of the updates. But when an admin runs managedsoftwareupdate from the command line, it might make sense to allow the admin to pick and choose among the available updates.
One solution right now that doesn't require any code changes is to simply edit the /Library/Managed Installs/InstallInfo.plist and remove the items you do not wish to install before invoking /usr/local/munki/managedsoftwareupdate --installonly. But that's a pain and easy to screw up.
So it might be nice to be able to do something like `/usr/local/munki/managedsoftwareupdate --installonly Firefox` and have managedsoftwareupdate install only Firefox.
The problem is a bit harder than it appears at first because you must take into account dependencies -- there may be items ready to install that require other items that are also ready to install. If "Office2011-14.0.0" and "Office2001Update-14.1.0" are both waiting to be installed, `/usr/local/munki/managedsoftwareupdate --installonly Office2001Update-14.1.0` is not going to do the right thing.
I tried one approach to the problem. I modified updateCheck to take a list of catalogs and a package name to install and it would treat them like a virtual manifest. You could say:
managedsoftwareupdate --catalogs='testing, production' --pkg='Firefox"
which would generate a virtual manifest:
<key>catalogs</key>
<array>
<string>testing</string>
<string>production</string>
</array>
<key>managed_installs</key>
<array>
<string>Firefox</string>
</array>
If you left out the catalogs flag, it would just use the catalogs from the "normal" manifest (from the server) for that machine.
The advantage of this approach was that when processing "Firefox" for install, it would be checked for dependencies those would be downloaded and queued as needed.
But I realized a serious issue with this approach, which led me to abandon it. This approach would allow anyone with sudo access to install absolutely anything from your munki repo:
sudo /usr/local/munki/managedsoftwareupdate --pkg="AdobeCS5MasterCollection"
In my opinion, this is bad. I think in some ways, this is almost exactly what Gary L and others looking to mate Munki and Puppet would like to see, but I think it is too dangerous.
There are other approaches I could take, but right now I'm looking for reactions and feedback.
-Greg
Justin McWilliams
> A colleague asked me if there was a way, when running managedsoftwareupdate from the command-line, to cherry-pick the available updates. His case was that a machine needed five updates. One required a reboot. He wanted to install one specific update right away without rebooting the machine.
>
> unattended_install (formerly "forced_install") is one approach to this problem, but the item he wanted to install actually required a couple of other items, and until recently, unattended_installs did not work with items that depended on other items. I've since addressed that.
>
> Still the original request seems reasonable. The Managed Software Updates GUI probably will never allow users to cherry-pick updates, since the idea is that _you_ are managing the updates (at least for those items in managed_installs and managed_updates); Managed Software Updates.app merely allows the user some flexibility as far as the timing of the updates. But when an admin runs managedsoftwareupdate from the command line, it might make sense to allow the admin to pick and choose among the available updates.
>
> One solution right now that doesn't require any code changes is to simply edit the /Library/Managed Installs/InstallInfo.plist and remove the items you do not wish to install before invoking /usr/local/munki/managedsoftwareupdate --installonly. But that's a pain and easy to screw up.
>
> So it might be nice to be able to do something like `/usr/local/munki/managedsoftwareupdate --installonly Firefox` and have managedsoftwareupdate install only Firefox.
>
> The problem is a bit harder than it appears at first because you must take into account dependencies -- there may be items ready to install that require other items that are also ready to install. If "Office2011-14.0.0" and "Office2001Update-14.1.0" are both waiting to be installed, `/usr/local/munki/managedsoftwareupdate --installonly Office2001Update-14.1.0` is not going to do the right thing.
>
> I tried one approach to the problem. I modified updateCheck to take a list of catalogs and a package name to install and it would treat them like a virtual manifest. You could say:
> managedsoftwareupdate --catalogs='testing, production' --pkg='Firefox"
>
> which would generate a virtual manifest:
>
> <key>catalogs</key>
> <array>
> <string>testing</string>
> <string>production</string>
> </array>
> <key>managed_installs</key>
> <array>
> <string>Firefox</string>
> </array>
>
> If you left out the catalogs flag, it would just use the catalogs from the "normal" manifest (from the server) for that machine.
>
> The advantage of this approach was that when processing "Firefox" for install, it would be checked for dependencies those would be downloaded and queued as needed.
>
> But I realized a serious issue with this approach, which led me to abandon it. This approach would allow anyone with sudo access to install absolutely anything from your munki repo:
If they can sudo they can do this anyways if they just modify the
Python, no? Sure... it's a higher bar to entry, but it's still
possible.
> sudo /usr/local/munki/managedsoftwareupdate --pkg="AdobeCS5MasterCollection"
>
> In my opinion, this is bad. I think in some ways, this is almost exactly what Gary L and others looking to mate Munki and Puppet would like to see, but I think it is too dangerous.
>
> There are other approaches I could take, but right now I'm looking for reactions and feedback.
>
> -Greg
>
>
> --
> You received this message because you are subscribed to the Google Groups "munki-dev" group.
> To post to this group, send email to munk...@googlegroups.com.
> To unsubscribe from this group, send email to munki-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/munki-dev?hl=en.
>
>
Greg Neagle
On Apr 12, 2011, at 3:31 PM, Justin McWilliams wrote:
>> If you left out the catalogs flag, it would just use the catalogs from the "normal" manifest (from the server) for that machine.
>>
>> The advantage of this approach was that when processing "Firefox" for install, it would be checked for dependencies those would be downloaded and queued as needed.
>>
>> But I realized a serious issue with this approach, which led me to abandon it. This approach would allow anyone with sudo access to install absolutely anything from your munki repo:
>
> If they can sudo they can do this anyways if they just modify the
> Python, no? Sure... it's a higher bar to entry, but it's still
> possible.
Sure, but
sudo /usr/local/munki/managedsoftwareupdate --pkg="AdobeCS5MasterCollection"
is well within the reach of K-12 students, and almost trivial. Higher bar to entry == good.
-Greg
dayglojesus
I see your concerns, but despite thisI think this would provide a useful way to test installation of individual packages.
On the Windows side, WPKG operates very similarly, and has the same problem. Personally, I would be perfectly happy with an on-demand install from the client's assigned catalogue. It still leads to better flexibility with less security concerns.
Per Olofsson
> But I realized a serious issue with this approach, which led me to abandon it. This approach would allow anyone with sudo access to install absolutely anything from your munki repo:
>
> sudo /usr/local/munki/managedsoftwareupdate --pkg="AdobeCS5MasterCollection"
You could ensure that the virtual manifest is a subset of the original client manifest. It would require juggling two manifests in the codebase though.
--
Per Olofsson
System Administrator, ITS, University of Gothenburg