Script runs locally, but not when run via Jamf Server

[Taylor_Armstron]

Running into a new one - think I've just never hit this combination of issues before.

Have a script that works 100% when run locally, essentially to modify my /etc/hosts file. When run locally, it obviously requires sudo.

When I run it via Jamf, it fails, but I have next to no feedback in my logs other than failure, with the following details:

Executing Policy Fix host (edit /etc/hosts) Checking for patches... No patch policies were found.

Script itself is below - any advice appreciated. Again, works perfectly when run locally if I hard-code the variables, but no feedback when run locally other than "failed"

#!/bin/bash

# adapted from https://gist.github.com/irazasyed/a7b0a079e7727a4315b9

# PATH TO YOUR HOSTS FILE
HOSTS=/etc/hosts

# DEFAULT IP FOR HOSTNAME
IP=$4

# Hostname to add.
HOSTNAME=$5

# Add host

HOSTS_LINE="$IP $HOSTNAME"
if [ -n "$(grep $HOSTNAME $HOSTS)" ]
    then
        echo "$HOSTNAME already exists"
    else
        echo "Adding $HOSTNAME to your $HOSTS";
        echo $HOSTS_LINE | tee -a $HOSTS;
        if [ -n "$(grep $HOSTNAME $HOSTS)" ]
            then
                echo "Host was added succesfully: $(grep $HOSTNAME $HOSTS)";
            else
                echo "Failed to Add $HOSTNAME, Try again!";
        fi
fi

exit 0

[mm2270]

Just curious, but why use tee for this when a simple >> would work? tee is usually used when there's a need to pipe the output to 2 locations at once, for example, on screen to stdout and to a file simultaneously.

Also, I would enclose the $HOSTS_LINE in double quotes since there's white space in the variable between the IP and the hostname. I would change that line to look like this and try it again

echo "$HOSTS_LINE" >> "$HOSTS"

[Taylor_Armstron]

Thanks @mm2270 .

Re: tee. Honestly? Not sure :). Think I was using it while testing initially and just never changed it back once I got the script itself working. The script is mostly borrowed from one I found on GitHub, just made some changes to allow $4 and $5 for the most part.

Changed both items per your suggestion, but symptoms still occurring - Locally works 100%. Fails with no feedback when run via a policy.

[cpdecker]

Starting off small--did you remember to attach it to the policy as a script? :)

What happens if you run the script via Casper Remote?

[Taylor_Armstron]

I'll admit, @cpdecker ... I laughed. Then I stopped and checked, because with the way today has gone...

But yes. Script IS attached, $4 and $5 parameters set. Hadn't tried via Remote, good call, but no change. Tried with a couple of other parameters other than the actual ones I'm trying to do just in case, but no change.

Again, nothing in the log that jumps out at me:

Sending Wake On LAN command... Opening SSH Connection to <IP>... Accepting authentication method... Authenticating... Successfully authenticated. Verifying Computer's Identity... The MAC Address has been verified. Checking Operating System Version... Running Mac OS X 10.12.6 (16G1036) Verifying /usr/local/jamf/bin/jamf... /usr/local/jamf/bin/jamf is current (10.0.0-t1508873342) Verifying /usr/sbin/jamf... /usr/sbin/jamf does not exist. Verifying /Library/Preferences/com.jamfsoftware.jamf.plist... Preparing Policy... The management framework will be enforced as soon as all policies are done executing. Executing Policy 2017-12-04 at 3:20 PM | Taylor.Armstrong | 1 Computer Running Recon... Retrieving inventory preferences from <server>:8443/... Finding extension attributes... Locating applications... Searching path: /Applications Locating hard drive information... Locating package receipts... Locating software updates... Locating plugins... Searching path: /Library/Internet Plug-Ins Locating printers... Locating hardware information (Mac OS X 10.12.6)... Gathering application usage information... Submitting data to <server>:8443/... 142 Submitting log to <server>:8443/... Finished.

[cpdecker]

Hmm...feeling a little stumped too. Have you tried deleting and re-uploading your script via Casper Admin? Looks like there was just no attempt to run the script at all, even when separating it from the policy.

[Taylor_Armstron]

Just to rule out the obvious "duh" elements, tested against a different machine (currently testing against a VM, but tried actual physical box with same results) and then tested another couple of scripts and verified they ran normally. Mostly just mystified by the absolute lack of feedback in the logs themselves.

[Taylor_Armstron]

OK... this REALLY bugs me. But along the lines of what you suggested, @cpdecker ... I went and edited the script - just deleted a blank line or two, and changed the name (took out "/etc/hosts" from the name and just made it "host file".)

Saved.

Now it runs.

REALLY don't like stuff like that. Going to see if I can re-create the issue and trace it to a bug somewhere... but can confirm it is working as intended now.

[A_H]

Years later, but I was also having this problem.

Turns out I was using a slash / in my script name. That is, the name in Settings > Computer Management > Scripts. I didn't have to re-upload to the distribution point.

Took out the / and everything starts working. Looks like they forgot to put quotes around something in the jamf code...