Pre- and Post- Install scripts just not working

[Daniel McDonnell]

Hi,

I've set up an apache with an smb share on a linux machine and I'm feeding it with packages via my mac.
All of this is working really well so far and I'm really happy with the possibilitys munki offers.
However, I've been trying to add a preinstall script to one of the packages and it results in the installation of the package just failing every time and the script also doesn't run.
Basically users should be able to install Firefox, Chrome, etc but when it comes to things that cost money and require authorization I want just that, a login prompt which requires credentials of an admin.
I've resulted in just trying this 

<key>preinstall_script</key>
<string>#!/bin/bash echo test > /tmp/1.txt</string>

to test it.
But again the install fails and no file is created in the temp folder.
Any ideas ? Or is there another way to restrict certain packages ? I know I could create other manifests but that would mean having to mess around with the plist everytime someone wants a different set of software.

Thanks

Daniel

Geometry Global GmbH, Rosenthaler Straße 51, 10178 Berlin, HRB: 159846B, Amtsgericht: Berlin Charlottenburg, 
Geschäftsführer: Stefan Knieß (CEO), Christian Mommertz (CCO), Frank Wolfram (CTO), Eugen Kern, Peter Mergemeier, Diego Miranda.

[Gregory Neagle]

On Oct 23, 2014, at 8:12 AM, Daniel McDonnell <daniel.m...@geometry.com> wrote:

Hi,

I've set up an apache with an smb share on a linux machine and I'm feeding it with packages via my mac.
All of this is working really well so far and I'm really happy with the possibilitys munki offers.
However, I've been trying to add a preinstall script to one of the packages and it results in the installation of the package just failing every time and the script also doesn't run.
Basically users should be able to install Firefox, Chrome, etc but when it comes to things that cost money and require authorization I want just that, a login prompt which requires credentials of an admin.
I've resulted in just trying this 

<key>preinstall_script</key>
<string>#!/bin/bash echo test > /tmp/1.txt</string>

to test it.

Several problems there.

#1 -- as written, that's not a a proper script; it should look more like

<string>#!/bin/bash

echo test > /tmp/1.txt</string> 

Scripts like line breaks, and the "shebang" line does need to be on a line by itself.

#2: you are embedding the script within a plist, which is a special type of XML. If your script contains characters that the XML parser is looking for, bad things will happen.

Generally you must escape "<" and "&" and it's best to also escape ">".

So now we're at:

<string>#!/bin/bash

echo test &gt; /tmp/1.txt</string> 

#3: Munki runs scripts as root. You can't be sure what root's environment or path is; but you definitely should not assume it is the same as yours. So you should refer to all tools by their full paths. That gets us to:

<string>#!/bin/bash

/bin/echo test &gt; /tmp/1.txt</string> 

See https://github.com/munki/munki/wiki/Pre-And-Postinstall-Scripts for more info.

-Greg

But again the install fails and no file is created in the temp folder.
Any ideas ? Or is there another way to restrict certain packages ? I know I could create other manifests but that would mean having to mess around with the plist everytime someone wants a different set of software.

Thanks

Daniel

Geometry Global GmbH, Rosenthaler Straße 51, 10178 Berlin, HRB: 159846B, Amtsgericht: Berlin Charlottenburg, 
Geschäftsführer: Stefan Knieß (CEO), Christian Mommertz (CCO), Frank Wolfram (CTO), Eugen Kern, Peter Mergemeier, Diego Miranda.

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

[Brandon Kerns]

So, I'm sure different folks do different things, but I use Munki's built in option for custom conditions to control whether licensed applications can be installed or not.

Essentially, I have a folder of what I call "Software Markers" that is available to our Support desk. This is just a term I made up for them to understand - the files are just tiny script files that set custom conditions that Munki can read and evaluate against.

As an example, in the "Software Markers" folder there is a file called "adobecc.sh", which contains the following script (pretty much straight form the Munki documentation):

#!/bin/sh

managedinstalldir="$(defaults read /Library/Preferences/ManagedInstalls ManagedInstallDir)"

plist_loc="$managedinstalldir/ConditionalItems"

defaults write "$plist_loc" "adobecc" -bool Yes

plutil -convert xml1 "$plist_loc".plist

exit 0

When an authorized, licensed user need Adobe Creative Cloud installed the Support Tech send this file to the machine in question (always copied to /user/local/munki/conditions, where these things "live"). 

The package in the manifest is set with a condition of adobecc = YES. 

Now, the next time the user runs MSU (or MSC) munki will check if the "adobecc" condition is true (which it will be), and the software will be offered up to the user along with anything else that is appropriate.

The user can then still self-service install the app along with any of the non-licensed apps, in the fashion they are already used to. If they are authorized it is presented to them, if they are not, they see nothing.

The for us, then, is essentially: The user calls support and requests the software; Support confirms the user is eligible; The Support Tech sends the marker file to the user's machine;  They then inform the user that they can now launch MSU (MSC) and install the application at their convenience.

It really sounds more complicated than it is, once you do it. :)

[Brandon Kerns]

I hate that you can't edit these things after you hit "Post" ... always find mistakes afterwords. Please forgive the typos ;)

And the path to the conditions is /usr/local/munki/conditions - not "user" which I accidentally typed.

[Gregory Neagle]

An alternate approach would be to have a manifest per machine.

Then:

When an authorized, licensed user needs Adobe Creative Cloud installed the Support Tech adds AdobeCC to managed_installs (or optional_installs) in that machine's manifest.

-Greg

[Brandon Kerns]

I thought about that route, but I don't trust our Support Techs quite enough to let them edit the manifests directly.

Perhaps I am unaware of a way to granularly control what they can and can't make changes to.

[Gregory Neagle]

On Oct 23, 2014, at 9:36 AM, Daniel McDonnell <daniel.m...@geometry.com> wrote:

Ok, great so my test "script" is working, thank you for that and the quick response.
My initial idea however is not really working

Basically it's this
<string>#!/bin/bash
        /usr/bin/osascript -e 'do shell script "echo" with administrator privileges'
        </string>
What I want to achieve with this is a prompt for admin credentials when trying to install a certain package.

Yeah, that's not going to work and is counter to how Munki is intended to operate. If you are going to do that, just put your packages on a fileshare that only admins can get to.

The script seems to run, however due to munki running scripts as root anyway as you stated, this doesn't really make much of a difference to the whole install procedure.
Is there any other way to restrict certain packages, without using manifests and messing about with the plists ?

Since manifests control what packages are installed on a given system, manifests _are_ the primary way of "restricting" what packages go to which machines.

Thanks
Daniel

[Brandon Kerns]

If you're referring to the code that I posted as messing with plists, don't focus on that. That just how the background works. All you do when you want a new condition is copy an existing one, rename it, and change the variable name its using. Then start using it.

If you're worried about editing plists referring to the xml that makes up a manifest, I highly recommend you check out MunkiAdmin - a fantastic native GUI app for Munki. I RARELY edit the manifest files directly...

I think you're hung up on getting it to prompt for an admin account - with the way Munki works it isn't necessary. Munki runs under root so that it can facilitate installs/removals on behalf of the user. They see/get what they are entitled to based on your manifests, catalogs, conditions, etc. and installs, or restricts installs accordingly.

[Daniel McDonnell]

Sorry, I posted my last post without having read your answers, I didn't notice them just ignore it.
Thanks anyway for the quick responses, yes you're right I am a bit fixated on the idea of having an admin prompt. :-)
I don't mind working in a terminal or editing the plist files, just thought it would be easier with an admin prompt, but I'll check out MunkiAdmin.
I think I'll just set up various manifests for different user groups.
default-client
creative-client
account-client
shouldn't be to much of a problem, especially with being able to include manifests into manifests.
Thanks for the help.