Script Execution after PKG install

Try dropping your built printer package into Composer and then expanding it on the left column of Composer. It will look like the picture below and one of the options/folders is labeled "Scripts". Then right click and you should see two sections that ask if you want to add a "Perl Script" or "Shell Script"

and you would then copy and paste your post install script into composer. Create a new PKG and scrope new PKG and scope it via a policy.

@jared_f I tested this previously but the PKG failed to install. I downloaded the PKG directly from the vendor, uploaded to Composer and did the post install script but still failed.

I was hoping to accomplish it with the policy script with the "after" action. I was under the impression that is how that worked but maybe not ?

@Chuey have you tried installing just the PKG file without the script? I would verify that the driver installs via policy. Also on the system that the install failed on, check the jamf.log and install.log files for errors.

The way you are attempting to install, with the script set to after, is the way to do this.

If your package fails to install, that's your problem. It has nothing to do with the script payload in your policy... that part isn't even executing, because the policy fails out at the package payload stage.

You'll need to troubleshoot your package to figure out what's wrong with it. Some ways you can troubleshoot a package:
1. Read through the logs, specifically /var/log/install.log. There should be some sort of message there that indicates why the install failed. One of many possibilities is that that the developer did something "naughty" that allows it to work when double clicked and run as user would, but causes it to fail when run from the command line.
2. If you haven't, try to run the package "normally" -- that is, on a test machine, double click and run through it the way a user normally would. If it fails that way, it's going to fail no matter what, and you'll either need to do some work to extract the payload and re-package it, or you'll need to contact the developer.
3. Use a piece of software like Suspicious Package or Pacifist to look through the package without installing it. That said, if you aren't familiar with the structure of a package and/or you don't know what you're looking for, the problem might not be immediately obvious.

In any case, it doesn't sound like it has anything to do with your script.

@stevewood @georgecm12 The PKG installs fine, it's the script that is not executing. I will check the jamf.log to see if anything appears there.

@Chuey can you post the script you are trying to run?

@stevewood Yes so just to clarify when I watch the policy get executed the PKG downloads, verifys, and installs just fine and that's all the output shows. It does not show any indication of the script being executed that I have set to "After"

Here is the script:

#!/bin/bash

cancel -a -

lpstat -p | awk '{print $2}' | while read printer
do
echo "Deleting Printer:" $printer
lpadmin -x $printer

done
echo "Adding HP400"
/usr/sbin/lpadmin -p A140 -o printer-is-shared="False" -E -v http://printserver/printers/SHARPMX3100N/.printer -P /Library/Printers/PPDs/Contents/Resources/HP LaserJet 400 M401dne.gz -D "HP 400 (Library)"

echo "Adding Sharp MX3100N"
/usr/sbin/lpadmin -p COPY -o printer-is-shared="False" -E -v http://printserver/printers/SHARPMX3100N/.printer -P /Library/Printers/PPDs/Contents/Resources/SHARP MX-3100N.PPD.gz -D "Color Copier (Library)"

When I send this to a computer via ARD with drivers installed it works just fine. For the time being I created a PKG that just has a post install script in it and first I have the printer drivers install then the script PKG and it works that way but I'd like to get it working with the script enabled via policy.

Most of the script looks ok, the only bit I don't recognise is the - after cancel -a.

The quickest way to confirm which bit of the script isn't running, is to save it as a script file locally on your Mac and run each piece in turn.

The first script would be:

#!/bin/bash

cancel -a -

exit $?

then

#!/bin/bash
lpstat -p | awk '{print $2}' | while read printer
do
echo "Deleting Printer:" $printer
lpadmin -x $printer
done
exit $?

followed by the two commands to add the printers.

One of these commands should fail.

@davidacland Both ran successfully. With the second one when I run from terminal it states "lp stat: no destinations added" but they were indeed added when I go under Sys Prefs > Printers.

I've just tested the script out (the full script you posted) on my Mac, substituting the drivers with some I already had installed. It ran fine.

If you have the drivers installed ok on a Mac and you run a policy that only executes the script, does that add the printers ok?

Could there be some nasty hidden character in your script text on the JSS? You could try copying the contents of your script to textedit or some other plain text editor, then create a second script with the results and run it instead.

If you can get the script running then you could try redirecting the output of the script to a file to see what is failing.

Something like this at the top of your script would output every command it attempts to run afterwards to /var/log/scriptlog.log (or whatever file you want to use):-

#!/bin/sh

set -x
exec 1>/var/log/scriptlog.log
exec 2>&1

<commands...>

Incidentally I tried out the lpstat -p | awk '{print $2}' command on my local workstation and it showed me 2 printers; Sandwiched between them was a line telling me "authentication required" so it would have tried to delete a printer called "required". Doubt it would cause the script to fail or even if you would have the same results but without checking the input it would attempt that command.

@davidacland So I just set the policy to execute the script only and it's still failing, but works when ran locally or through ARD. . .

The main differences with a policy running the script is the user account, although root would also be able to run the commands.

You could try a few echos to see what bit it doesn't like:

#!/bin/bash

cancel -a -

echo "Exit code from cancel command $?"

lpstat -p | awk '{print $2}' | while read printer
do
echo "Deleting Printer:" $printer
lpadmin -x $printer
echo "Exit code when deleting $printer $?"
done
echo "Adding HP400"
/usr/sbin/lpadmin -p A140 -o printer-is-shared="False" -E -v http://printserver/printers/SHARPMX3100N/.printer -P /Library/Printers/PPDs/Contents/Resources/HP LaserJet 400 M401dne.gz -D "HP 400 (Library)"
echo "Exit code adding HP400 $?"

echo "Adding Sharp MX3100N"
/usr/sbin/lpadmin -p COPY -o printer-is-shared="False" -E -v http://printserver/printers/SHARPMX3100N/.printer -P /Library/Printers/PPDs/Contents/Resources/SHARP MX-3100N.PPD.gz -D "Color Copier (Library)"
echo "Exit code adding MX3100N $?"

The results should appear in the policy log

@davidacland Weird thing is it's showing no output with echos or set -x in the jamf policy log.

@Chuey You could try putting the script in a policy all on its own and setting it to run with a custom trigger then manually launching it on the client from a console session. Thats if you are 100% sure there aren't any weird line breaks hidden in the script causing it to fail.

Also, it shouldn't matter but does it exhibit the same behaviour if you create a new policy with the exact same settings? Possibly something corrupt with the policy in MySQL. Clutching at straws really - something isn't right.

@nigelg I've created a new test policy, added the script, set it to execute before any other actions although it's the only action, and I double checked there were no weird characters or line breaks in the script. I then enabled the trigger for recurring check in, remote into the machine and initiate the policy by ID. Fails to run and none of my echos are logged in the policy. . . . I'm running 9.9.6 and wondering if something happened when I upgraded. . .

I'd probably try and get back to a working point and then build it back up from there.

Try swapping out the printer script with one that just runs:

#!/bin/bash

echo "Hello World"

exit 0

If that works, you can move the other commands across bit by bit.

If it can't run that script, there'll be something very wrong with the server or the client's connection to it.