Testing new feature: Self-Service On-demand tasks

[Gregory Neagle]

In case you missed it this weekend, I've started a feature branch to explore a possible new Munki feature, which would allow Munki admins to create items for optional_installs that performed some task as root. Together with Managed Software Center, this would allow admins to offer tools for their users to perform basic maintenance tasks (that would usually require root or admin permissions) on their own.

Initial stab at this functionality is here: 

https://github.com/munki/munki/tree/one-time-tasks

This adds support for a new key in pkginfo items: "OnDemand" (I'm not married to this key name and may well change it in the future)

If this key is present:

1) The item is never considered installed. This means Munki will never think it needs to be removed, either (because it's not installed!)

2) If you add such an item to a regular manifest:

a) In managed_installs: you are likely to be sad, as Munki will try to install it over and over and over since it is never considered installed.

b) In managed_updates: it will never be updated, since it is never considered installed.

c) in managed_uninstalls: it will never be removed, since it is never considered installed.

d) In optional_installs: congratulations, you made the only functional choice!

3) If chosen by the user for optional install, the item will be installed, then removed from the local SelfServeManifest, making it available for a future re-install.

This new functionality implies some additional nice-to-have changes, for example, specifying some alternate labels for the "Install" button in MSC.app; perhaps something like "Run" and "Running"; of course that then opens localization issues...

But this is a start. Play with it and give me your feedback.

-Greg

[Rick Heil]

I am unreasonably excited to test this out this week - many of the one-time scripts that we would usually run via ARD to fix specific issues (Office database rebuilds, anyone?) will be perfect for this. 

Thank you Greg and everyone else who brainstormed this one up!

-Rick

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Batye]

Greg, 

Tested and confirmed new feature works for me. 

I was doing something similar for VMs to allow users to install multiple times by having a post-install script to remove the item name from SelfServeManifest. 

Thanks for implementing this! 

[Ronald Carter]

This is exactly what I am looking for.

Will be testing shortly

[Vaughn Miller]

I got a change to play with this a little bit this afternoon, and I like it!  I'll keep poking at it to make sure I'm giving it a thorough test.

Vaughn Miller

Desktop Engineer 

Lafayette College

On Thu, Mar 19, 2015 at 4:37 AM, Ronald Carter <ronald.ca...@gmail.com> wrote:

This is exactly what I am looking for.

Will be testing shortly

--

[Allister Banks]

I'm still not totally sold on the utility of this, but I wanted to try a task to direct folks to the MacAppStore with a simple

open https://itunes.apple.com/us/app/garageband/id682658836

It works... but it's weird to have a 45 second+ lag after folks click 'run' (since we are configured to check for Apple Updates through Munki as well), and I even feel like pre-flight tasks could potentially be unnecessary in this use case. It's not very 'onDemand' if a relatively unrelated progress bar appears and seemingly out of nowhere an action occurs.
Allister

[Gregory Neagle]

On Mar 24, 2015, at 7:45 AM, Allister Banks <a...@aru-b.com> wrote:

I'm still not totally sold on the utility of this,

I promise not not make you use it, then.

but I wanted to try a task to direct folks to the MacAppStore with a simple

open https://itunes.apple.com/us/app/garageband/id682658836

The way Munki currently works, something like that is going to be problematic if for no other reason that the managedsoftwareupdate process runs as root, not as the user interacting with Managed Software Center.app.

This particular example (providing a link to a specific item in the App Store) seems not to be the best fit for the intention behind the new OnDemand functionality (which is to provide a way for non-admin users to perform tasks that normally need root or admin), but of course people always find unusual ways to use software.

It works... but it's weird to have a 45 second+ lag after folks click 'run' (since we are configured to check for Apple Updates through Munki as well), and I even feel like pre-flight tasks could potentially be unnecessary in this use case. It's not very 'onDemand' if a relatively unrelated progress bar appears and seemingly out of nowhere an action occurs.

This is an initial implementation, leveraging current Munki functionality (which is to check what needs to be installed/removed, and then perform those actions. Munki doesn't currently treat items marked for "OnDemand" install as special in any way other than forgetting they are installed and removing them from SelfServeManifest's managed_installs.

One could imagine in the future taking advantage of scripts built into the pkginfo and running them right away (skipping the check phase), but for OnDemand items that contain an actual pkg or dmg that must be downloaded, a check-and-download phase seems like it would always be needed -- I don't think we'd want to pre-emptively cache an arbitrary number of possible OnDemand downloads.

Again, if this feature is of no use to you, don't use it.

If there are enhancements that could make it more useful, make suggestions.

-Greg

Allister

On Monday, March 16, 2015 at 9:58:59 AM UTC-4, gregn...@mac.com wrote:

In case you missed it this weekend, I've started a feature branch to explore a possible new Munki feature, which would allow Munki admins to create items for optional_installs that performed some task as root. Together with Managed Software Center, this would allow admins to offer tools for their users to perform basic maintenance tasks (that would usually require root or admin permissions) on their own.

Initial stab at this functionality is here: 

https://github.com/munki/munki/tree/one-time-tasks

This adds support for a new key in pkginfo items: "OnDemand" (I'm not married to this key name and may well change it in the future)

If this key is present:

1) The item is never considered installed. This means Munki will never think it needs to be removed, either (because it's not installed!)

2) If you add such an item to a regular manifest:

a) In managed_installs: you are likely to be sad, as Munki will try to install it over and over and over since it is never considered installed.

b) In managed_updates: it will never be updated, since it is never considered installed.

c) in managed_uninstalls: it will never be removed, since it is never considered installed.

d) In optional_installs: congratulations, you made the only functional choice!

3) If chosen by the user for optional install, the item will be installed, then removed from the local SelfServeManifest, making it available for a future re-install.

This new functionality implies some additional nice-to-have changes, for example, specifying some alternate labels for the "Install" button in MSC.app; perhaps something like "Run" and "Running"; of course that then opens localization issues...

But this is a start. Play with it and give me your feedback.

-Greg

[Kirk Parrish]

This is exactly what I've been looking for in Munki. I've dabbled a bit on getting a "Self Help" package to work (can't get it to stay "uninstalled") for users to be able to trouble shoot their own computer before calling IT. I know JAMF has a feature like this (got to help implement that at my last job), and would be an excellent feature to have in Munki.

Here's the Install Script I was working on, just the start of a few cleanup items I thought would be useful (runs the default cleanup logs and caches, repairs disk permissions and reboot, so basically your typical "Have you tried turning it off and on again"):

#!/bin/bash 

periodic daily weekly monthly

diskutil reapirPermissions /

osascript -e 'tell application "System Events" to restart'

Looking forward to testing out the OnDemand feature, I think it could be amazingly useful. Thanks.

-Kirk:P

[Gregory Neagle]

On Mar 24, 2015, at 9:22 AM, Kirk Parrish <invad...@gmail.com> wrote:

This is exactly what I've been looking for in Munki. I've dabbled a bit on getting a "Self Help" package to work (can't get it to stay "uninstalled") for users to be able to trouble shoot their own computer before calling IT. I know JAMF has a feature like this (got to help implement that at my last job), and would be an excellent feature to have in Munki.

Here's the Install Script I was working on, just the start of a few cleanup items I thought would be useful (runs the default cleanup logs and caches, repairs disk permissions and reboot, so basically your typical "Have you tried turning it off and on again"):

#!/bin/bash 

periodic daily weekly monthly

diskutil reapirPermissions /

osascript -e 'tell application "System Events" to restart'

Looking forward to testing out the OnDemand feature, I think it could be amazingly useful. Thanks.

When you say "looking forward to testing..." does this mean you haven't had time yet, or you don't know that you can test it now?

-Greg

[Jason Hatman]

It works great in my testing!  Great feature.  The word "Install" is a bit misleading here since it's a repeatable function.  Can the button be labeled differently if it detects the "OnDemand" key?  Perhaps to "Execute" or something along those lines.

[Gregory Neagle]

On Mar 25, 2015, at 8:15 AM, Jason Hatman <jason....@gmail.com> wrote:

> It works great in my testing! Great feature. The word "Install" is a bit misleading here since it's a repeatable function. Can the button be labeled differently if it detects the "OnDemand" key? Perhaps to "Execute" or something along those lines.

Perhaps you missed this in my initial announcement:

> This new functionality implies some additional nice-to-have changes, for example, specifying some alternate labels for the "Install" button in MSC.app; perhaps something like "Run" and "Running"; of course that then opens localization issues...

There are several things to be decided.

Currently the button for all items reads "Install" . When you click it, the label changes to "Cancel" and a "Downloading" message is displayed near the button.
Once the item is downloaded, the button label changes to "Installing".

Any alternate labeling would at a minimum, have to specify replacements for "Install" and "Installing".

Additionally, MSC.app is localized into many languages, and the "Install" and "Installing" labels are currently translated into the appropriate languages. It would be expected, I think, to have this localization happen for the replacement labels.

Finally, it's not clear to me that a hard-coded replacement label of "Run/Running" or "Execute/Executing" will be appropriate for all possible uses of the on-demand tasks; one might expect that the admin would be able to choose a set of labels.

So more consideration must go into this before implementation.

-Greg

[Erik]

On Wednesday, March 25, 2015 at 10:43:44 AM UTC-5, gregn...@mac.com wrote:

There are several things to be decided.

Currently the button for all items reads "Install" . When you click it, the label changes to "Cancel" and a "Downloading" message is displayed near the button.
Once the item is downloaded, the button label changes to "Installing".

Any alternate labeling would at a minimum, have to specify replacements for "Install" and "Installing".

Given that this will any items will trigger managedsoftwareupdate, we still need to keep the Cancel and Downloading phrases. While it may not make as much sense, the behavior is consistent to the user. I agree that "Install" could be changed to "Execute" and "Installing" can be "Executing".
 

Additionally, MSC.app is localized into many languages, and the "Install" and "Installing" labels are currently translated into the appropriate languages. It would be expected, I think, to have this localization happen for the replacement labels.

 

Sounds about right.
 

Finally, it's not clear to me that a hard-coded replacement label of "Run/Running" or "Execute/Executing" will be appropriate for all possible uses of the on-demand tasks; one might expect that the admin would be able to choose a set of labels.

 Sounds like a lot of unneeded overhead. :). While it would possibly be a nice feature to dynamically change the labels at a pkginfo level, I can't see myself using the feature that often.

 

[Gregory Neagle]

On Mar 26, 2015, at 7:46 PM, Erik <eriknico...@gmail.com> wrote:

Given that this will any items will trigger managedsoftwareupdate, we still need to keep the Cancel and Downloading phrases. While it may not make as much sense, the behavior is consistent to the user. I agree that "Install" could be changed to "Execute" and "Installing" can be "Executing".
 

I dislike those labels a lot. I don't think "normal" people would use those terms to mean "perform a task'.

Additionally, MSC.app is localized into many languages, and the "Install" and "Installing" labels are currently translated into the appropriate languages. It would be expected, I think, to have this localization happen for the replacement labels. 

 

Sounds about right.
 

Finally, it's not clear to me that a hard-coded replacement label of "Run/Running" or "Execute/Executing" will be appropriate for all possible uses of the on-demand tasks; one might expect that the admin would be able to choose a set of labels. 

 Sounds like a lot of unneeded overhead. :). While it would possibly be a nice feature to dynamically change the labels at a pkginfo level, I can't see myself using the feature that often.

Me, neither, yet it has been asked for.

-Greg

[Adam M. Anklewicz]

I haven’t tested it yet, want to… but as for labels, I’d use Run and Running. Execute sounds like a Dalek.

Now if it can be Exterminate and play a sound file when you click it, then THAT!

Dynamic labels sounds weird in a multi-lingual environment like my own. Would we have to make the labels in both languages, possibly the third if I ever get around to localizing for that language (last I checked, Munki didn’t have Hebrew). 

--
Adam M. Anklewicz

ad...@anklewicz.com
http://www.neverhadtofight.com

[Gregory Neagle]

On Mar 27, 2015, at 8:35 AM, Adam M. Anklewicz <ad...@anklewicz.com> wrote:

I haven’t tested it yet, want to… but as for labels, I’d use Run and Running. Execute sounds like a Dalek.

Now if it can be Exterminate and play a sound file when you click it, then THAT!

Dynamic labels sounds weird in a multi-lingual environment like my own. Would we have to make the labels in both languages, possibly the third if I ever get around to localizing for that language (last I checked, Munki didn’t have Hebrew). 

But that's the exact reason you'd want that capability ("a multi-lingual environment").

[Adam M. Anklewicz]

Sorry, I guess I’m confused, or didn’t state it properly.

I imagine that if we have a singular phrase, then that can be handled with the standard localization, allowing our users to select their own language. 

If we have a custom phrase that can be enacted in the pkginfo file, would that not be unilingual; literally saying what is typed in the key?

--
Adam M. Anklewicz

ad...@anklewicz.com
http://www.neverhadtofight.com

[Gregory Neagle]

On Mar 27, 2015, at 10:05 AM, Adam M. Anklewicz <ad...@anklewicz.com> wrote:

Sorry, I guess I’m confused, or didn’t state it properly.

I imagine that if we have a singular phrase, then that can be handled with the standard localization, allowing our users to select their own language. 

If we have a custom phrase that can be enacted in the pkginfo file, would that not be unilingual; literally saying what is typed in the key?

That was my entire point: if we allow admins to specify custom terms/labels/phrases, we'd also need to provide localization options.

[tackyy]

Instead of phrases that need to be localized, would play/stop button iconography be a suitable choice? It’s familiar from audio/video contexts and if the “play” button turned into a “stop” button when you clicked it people may generally understand something is in progress.

tack

[Gregory Neagle]

You want to hack together a visual representation of what you have in mind?

[Matthias Choules]

Am 27.03.2015 um 18:06 schrieb Gregory Neagle <gregn...@mac.com>:

That was my entire point: if we allow admins to specify custom terms/labels/phrases, we'd also need to provide localization options.

We don't have those localization options for the categories as well. But - in fact - they would be great!

-- 

Matthias Choules

Mobil erreichbar über

+49 171 7800114

oder via E-Mail

[Gregory Neagle]

On Mar 27, 2015, at 11:17 AM, Matthias Choules <cho...@wycomco.de> wrote:

Am 27.03.2015 um 18:06 schrieb Gregory Neagle <gregn...@mac.com>:

That was my entire point: if we allow admins to specify custom terms/labels/phrases, we'd also need to provide localization options.

We don't have those localization options for the categories as well. But - in fact - they would be great!

It has been requested to allow localizations of display name, description and category as well.

-- 

Matthias Choules

Mobil erreichbar über

+49 171 7800114

oder via E-Mail

[Erik Gomez]

This sounds rather complex... 

An admin would need to create an array of some kind for every pkginfo file if they wanted to support this with localization. Doesn't it make more sense to just have a set of phrases (as currently setup)?

I love customization in general but this doesn't seem worth the effort. 

Sent from my iPhone

[Gregory Neagle]

On Mar 27, 2015, at 12:24 PM, Erik Gomez <eriknico...@gmail.com> wrote:

This sounds rather complex... 

An admin would need to create an array of some kind for every pkginfo file if they wanted to support this with localization.

An admin has to create a pkginfo file containing display_name, description, etc anyway... if they want to/need to support additional languages why not?

Doesn't it make more sense to just have a set of phrases (as currently setup)?

Still need to indicate in the pkginfo you want to use an alternate label; it's not clear to be that every use of these proposed OnDemand tasks would make sense with a single alternate label that is automatically applied. Might as well stick with "Install/Installing" then.

[Stefan Vogel]

Hi pros

Here a too supid question, but as a newbee I need to know how to install this extension to my munki repo. Could anybody give me a starting-kick?

We could use this feature very much, because we'd also like to implement self-help-tasks (delete caches, fsck, repair permissions, ...)

Thanks in advance - Stefan

[Allister Banks]

Hey Mr. Vogel,

It's not something you install server-side, the client uses the new code in the one-time-tasks tree, which previously was limited to just installer.py and updatecheck.py, so you'd just replace those in your testing client. No re-building of the client or other changes should be necessary, besides actually having a pkginfo with the script you want to run with the OnDemand designation, of course. 

I haven't followed all of the more recent commits(although I think it's basically makepkginfo conveniences), but those two files should be about it, but to be sure I'd look at what's changed commit-wise here: https://github.com/munki/munki/tree/one-time-tasks although it may be somewhat out-of-date with the master branch.

Allister

--

[Gregory Neagle]

This code has been merged into the master branch. It’s still a work-in-progress, but should now be available from builds at munkibuilds.org, which should make testing easier for many.

-Greg

[Stefan Vogel]

Dear Greg

I tried to test it now, as you have implemented it to the builds. I guess the one from today has it? Nevertheless, I downloaded it, installed it on my testclient (thanks to Allister!). On the server I produced the following pkg-plist, which shows up on the client as optional install, but as "already installed". So unfortunately, I can't install it again. Is there something else that needs to be configured?

o-o Stefan

<?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

    <plist version="1.0">

    <dict>

        <key>catalogs</key>

        <array>

<string>basecatalog</string>

        </array>

<key>category</key>

<string>Support</string>

        <key>description</key>

<string>Bereinigung von Logs. Reparatur von Zugriffsrechten. Neustart.</string>

        <key>display_name</key>

<string>Systemputz</string>

<key>name</key>

<string>Systemputz</string>

<key>OnDemand</key>

<string></string>

<key>minimum_os_version</key>

<string>10.7.0</string>

<key>installer_type</key>

<string>nopkg</string>

        <key>postinstall_script</key>

        <string>#!/bin/bash

    # Run default cleanup logs and caches

periodic daily weekly monthly

    # Repair permissions on bootvolume

diskutil reapirPermissions /

    # Restart mac

osascript -e 'tell application "System Events" to restart'</string>

        <key>version</key>

        <string>1.0</string>

    </dict>

    </plist>

[Gregory Neagle]

On Apr 15, 2015, at 12:07 PM, Stefan Vogel <s.v...@powersolutions.ch> wrote:

Dear Greg

I tried to test it now, as you have implemented it to the builds. I guess the one from today has it? Nevertheless, I downloaded it, installed it on my testclient (thanks to Allister!). On the server I produced the following pkg-plist, which shows up on the client as optional install, but as "already installed". So unfortunately, I can't install it again. Is there something else that needs to be configured?

o-o Stefan

<?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

    <plist version="1.0">

    <dict>

        <key>catalogs</key>

        <array>

<string>basecatalog</string>

        </array>

<key>category</key>

<string>Support</string>

        <key>description</key>

<string>Bereinigung von Logs. Reparatur von Zugriffsrechten. Neustart.</string>

        <key>display_name</key>

<string>Systemputz</string>

<key>name</key>

<string>Systemputz</string>

<key>OnDemand</key>

<string></string>

Should be <true/> and not an empty string!

<key>minimum_os_version</key>

<string>10.7.0</string>

<key>installer_type</key>

<string>nopkg</string>

        <key>postinstall_script</key>

        <string>#!/bin/bash

    # Run default cleanup logs and caches

periodic daily weekly monthly

    # Repair permissions on bootvolume

diskutil reapirPermissions /

    # Restart mac

osascript -e 'tell application "System Events" to restart'</string>

        <key>version</key>

        <string>1.0</string>

    </dict>

    </plist>

[Jason Hueske]

Typo just in case you missed it:

reapirPermissions should be repairPermissions

[Rick Heil]

I haven’t had the time to test on more than 10.10 yet, but it appears that MSU.app retains a (1) notification on the icon in the dock after “installing” an OnDemand resource. It seems that causing a check to the munki server with the “update” button or the usual schedule will clear out the notification.

-R

[Gregory Neagle]

Pretty sure this is unrelated to the OnDemand functionality, but connected to the new in-progress Notification Manager and dock-badging-when-the-app-is-not-running support.

But thanks for reporting it.

-Greg

[Stefan Vogel]

Perfect - thanks. I extended the script a bit with caches cleaning and a restart definition in the pkg info manifest. So far so good.

One problem I encountered is a preinstall info, that I intended to set in the pkg info manifest. As soon as it is set, I can't hit the installation button on the client. It looks like installable, but there is no effect when clicking on it.

o-o Stefan

[Gregory Neagle]

On Apr 15, 2015, at 2:36 PM, Stefan Vogel <s.v...@powersolutions.ch> wrote:

Perfect - thanks. I extended the script a bit with caches cleaning and a restart definition in the pkg info manifest. So far so good.

One problem I encountered is a preinstall info, that I intended to set in the pkg info manifest. As soon as it is set, I can't hit the installation button on the client. It looks like installable, but there is no effect when clicking on it.

I’ll probably need more details to understand what you mean.

-Greg

o-o Stefan

[Gregory Neagle]

Should be addressed in this build: https://munkibuilds.org/2.2.4.2461/

-Greg

[Stefan Vogel]

I typed in the manifest the following 2 keys:

<key>RestartAction</key>

<string>RequireRestart</string>

<key>preinstall_alert</key>

<string>Bitte schliessen Sie alle Programme. Lorem ipsum.</string>

After that, nothing happens if I hit "installieren" on the on-demand-icon. If I take the preinstall_alert key out, it works.

[Rick Heil]

Yep, confirmed this resolves that issue. Thanks Greg!

-R

[Kirk Parrish]

For a restart I found this handy line to add to the bash script, it will bring a popup asking for a restart (I know, most users will click cancel, but forcing a restart might cause more user panic then I'm willing to deal with).

osascript -e 'tell app "loginwindow" «event aevtrrst»’