Run script one time

[Demiyo]

Is there a way, to run a script one time when i press "install". I write a self service script with some cleaning for the clients, make a pkg with "Payload-Free Package Creator" but munki run this "install" all the time because it think its not install.

Greetings

[A.E. van Bochoven]

Munki needs a way to know that the package is installed. You can use the installcheck_script to check if the package needs to run or not.

https://github.com/munki/munki/wiki/How-Munki-Decides-What-Needs-To-Be-Installed#install-check-script

-Arjen

On 14 Mar 2015, at 10:56, Demiyo <er...@demiyo.de> wrote:

Is there a way, to run a script one time when i press "install". I write a self service script with some cleaning for the clients, make a pkg with "Payload-Free Package Creator" but munki run this "install" all the time because it think its not install.

Greetings

--
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.

[sondjata]

Yup. As a part of your script use a check file ( I usually dump an invisible file in a stable location) that it writes when the script runs successfully. The next time a managed update runs it'll look for that check file and exit (exit >0 = no install).

[Demiyo]

And if i want to run this script again after one run ? My problem is, that munki run the script in a loop after check for updates. But i want to run ist as a self service for one time, until i press "install". I saw this by "Casper".

[Gregory Neagle]

So I think what I'm hearing is this:

You want to make a script available as an optional install that performs an action. It's not a permanent action; whatever the script does, a user might want to run the script again in the future. So Munki should "install" the item (which might actually run a script), but then forget it has done so, so that a user can decide to run/install this item again in the future.

Munki's current model is not a good fit for this. Munki was designed to manage software installation. Its model is to inspect the system to see if the software is installed; depending on the results of that inspection, it decides to install the software (or not). It does this every time it runs. It _manages_ the installed software. You don't really tell Munki directly to install or remove something, instead you tell Munki: "On this system, the following software should be present, and this other software should not be present." Munki then works out what to do to get to that state.

What you want to do would require some new features to be added to Munki: we'd need a special type of item (that would really only work for self-service installs). For this type of item:

1) Munki would just add the item to the list of things to be installed without checking any receipts or installs items.

2) After installation, it would remove the item from the SelfServiceManifest's managed_installs (so Munki would not try to install it again and again on subsequent runs). Since it's the _client_ doing the removing from a manifest, this could _only_ work with the SelfServiceManifest.

We'd need to think about some of the other implications around this -- here's a few off the top of my head:

a) How do we handle this if the admin (mistakenly) adds one of these items to a manifest stored on the Munki repo (this would be an error, since the client would not be able to remove the item from the manifest and therefore Munki would install it over and over)

b) Should this type of item support uninstalls? How might those work?

Start the discussion!

-Greg

[Erik Gomez]

This would be a great option. One immediate "tool" that comes to mind is repairing hard drive permissions. 

a) treat it similar to the icons - perhaps makecatalogs is ran and it automatically looks at a "selfservicescripts" folder and brings them into the catalogs. The name could be based on the name of the script. This would prevent an admin from adding it to any manifest. 

I see issues with this approach as well though (admins who use catalogs incorrectly or want want to test prior to production). Scripts inserted directly into catalogs will need to be validated for XML issues as well. 

B) I vote no. 

[Gregory Neagle]

I took an initial stab at implementing this functionality; it's usually easier to discuss a concrete working example: 

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

[zack.m...@bsd7.org]

This would be sweet. Another thing might be a key that is like a delay key. You can only run this N number of times within N amount of time. Might be too much but would be a potential safeguard for excess amounts of tasks.

[zack.m...@bsd7.org]

On Saturday, March 14, 2015 at 8:43:01 PM UTC-6, gregn...@mac.com wrote:

I took an initial stab at implementing this functionality; it's usually easier to discuss a concrete working example: 

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!

Maybe have manifestutil detect the "OnDemand" key and present and error if it is any other choice besides optional install? 

[Gregory Neagle]

On Mar 14, 2015, at 7:59 PM, zack.m...@bsd7.org wrote:

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

Maybe have manifestutil detect the "OnDemand" key and present and error if it is any other choice besides optional install? 

1) manifestutil (and any other manifest editor) may not have enough info to give accurate feedback, as we don't know which pkginfo will be used until runtime on the client, and this can change over time even with no changes to the manifest. 

2) this would be helpful to the handful of people using manifestutil; it would not, for example, help users of MunkiAdmin or MunkiWebAdmin. 

[Gregory Neagle]

On Mar 14, 2015, at 7:55 PM, zack.m...@bsd7.org wrote:

This would be sweet. Another thing might be a key that is like a delay key. You can only run this N number of times within N amount of time. Might be too much but would be a potential safeguard for excess amounts of tasks.

This is not something I plan to implement. 

On Saturday, March 14, 2015 at 8:35:47 PM UTC-6, Erik wrote:

This would be a great option. One immediate "tool" that comes to mind is repairing hard drive permissions. 

a) treat it similar to the icons - perhaps makecatalogs is ran and it automatically looks at a "selfservicescripts" folder and brings them into the catalogs. The name could be based on the name of the script. This would prevent an admin from adding it to any manifest. 

 

I see issues with this approach as well though (admins who use catalogs incorrectly or want want to test prior to production). Scripts inserted directly into catalogs will need to be validated for XML issues as well. 

B) I vote no. 

--

[Jason Hueske]

I've been doing this in postinstallscript for quite a while:

sed -i "" ‘/packagename/d' "/Library/Managed Installs/manifests/SelfServeManifest”

Followed by other cleanup if necessary (hurray for nopkg):

pkgutil --forget com.packagename.receipt.pkg

I use it for various maintenance scripts - one to reset keychains (archive then delete everything ~/Library/Keychains except login.keychain), one to reset caches (system font, adobe/ms font, browser, spotlight, etc), one to reset printers (which munki then replaces on the next run). I’ve never had any weirdness emerge but have wondered whether I might be running afoul of cprefsd. Those pkginfos include a required restart so that’s probably been moot in my case and I’ve never looked into it further. In my environ there’s almost no end user glitch that can’t be mitigated by running the reset caches and keychains. :)

I would definitely welcome a “supported” way to do this. The OnDemand key might be a little confusing with launchd - perhaps a key that reminds the admin it can only be optional? OptOnlyOnce, more like the LaunchOnlyOnce key?

- Jason

[Gregory Neagle]

I don't think there is going to be a key name that is instantly intuitive and understandable; since one of purposes of this new functionality is to allow a user to choose to run/install an item more than once (without a "removal" step) any key name containing "Once" might confuse as well.

I could be evil and name the key "DoASpecialThingYouReallyShouldReadTheDocumentation" or something that doesn't even attempt to evoke the functionality like "BlueHarvest".

I chose the "OnDemand" name to imply that these items were meant to be installed on user demand, so maybe "OnUserDemand" or "on_user_demand_only"...

Or "GroundhogDay"

-Greg

[Jason Hueske]

The User in OnUserDemand implies the optional install pretty clearly, so I like it.

I think you should reserve GroundhogDay for a feature that parses the Install.log for consecutive matching “successfuls” and then preemptively opens this. 

[Josh Malone]

I always like the sendmail-style "dont_blame_munki" :-)

[Chase Thompson-Baugh]

If this functionality is going to be added to Munki, that would be awesome. In the meantime, you can check out Graham Gilbert's mactech_2014 repo. I use a variation of his "Repair Permissions" item to do maintenance on troublesome Macs.