Check JSS Connection in Bash Script

el2493
Contributor III

I'm on 10.3.1, and I need a command to check a computer's connection to the JSS in a bash script. I've read about the /usr/local/bin/jamf checkJSSConnection command, but is there a way to limit how many times it will check the connection before it times out? I'm writing a script where I want it to do one thing if there is a JSS connection and do something else if there isn't.

#!/bin/sh

checkJSSConnection=$(/usr/local/bin/jamf checkJSSConnection)

if [[ $checkJSSConnection != *"The JSS is available"* ]]; then
    echo "run local script"
    sh /path/to/local_script.sh 
else
    echo "run JSS policy"
    jamf policy -event customtrigger
fi

If the JSS is available, it takes only a few seconds to confirm that. If the JSS isn't available it retries for 55-60 seconds, which is longer than I'd like it to take. Any ideas on how to get a quicker response? I talked with Jamf Support and they recommended using jamf recon instead, like this:

#!/bin/bash -v

checkJSSConnection=$(jamf recon)

if [[ $checkJSSConnection != *"There was an error"* ]]; then
    echo "run JSS Policy"
    jamf policy -event customtrigger
else
    echo "run local script"
    #sh /path/to/local_script.sh
fi

That has the opposite problem of the prior command, where if the JSS can't recon, it takes only a few seconds to confirm that. If the JSS can recon it takes around 40 seconds for the recon to complete and the script to recognize that, which is a little better but still longer than I'd like it to take.

1 ACCEPTED SOLUTION

dan-snelson
Valued Contributor II

@el2493 Take a look at jamf help checkJSSConnection

Usage: jamf checkJSSConnection [-retry x] -retry The number of times the connection should be tested If nothing is specified, the connection will be tested 12 times before exiting. Returns 0 if the JSS is available Returns 1 if the JSS is not available

View solution in original post

10 REPLIES 10

dan-snelson
Valued Contributor II

@el2493 Take a look at jamf help checkJSSConnection

Usage: jamf checkJSSConnection [-retry x] -retry The number of times the connection should be tested If nothing is specified, the connection will be tested 12 times before exiting. Returns 0 if the JSS is available Returns 1 if the JSS is not available

dan-snelson
Valued Contributor II

@el2493 My test machine is currently on the same network as my server and looks like it's taking less than 3 seconds:

time sudo jamf checkJSSConnection -retry 1
Checking availability of https://jamfpro.server.goes.here/...
The JSS is available.

real    0m1.696s
user    0m0.369s
sys 0m0.499s

mm2270
Legendary Contributor III
I talked with Jamf Support and they recommended using jamf recon instead

You spoke with someone in Jamf Support and they weren't aware of the -retry flag in their own binary? Really? That's kind of disturbing. It's not like it's new. The flag's been there for ages.

Just to offer another possible solution to this - call a simple policy set up with a custom trigger that does basically nothing, no installs, no scripts, not even a recon. If it fails to run, your JSS is not accessible. If the policy runs, it's available. As long as the scope to the policy is All Managed Macs and set to Ongoing but with only the custom trigger, it should always run when a Mac calls it within a script, but never at any other time.

dan-snelson
Valued Contributor II

@el2493 Piggy-backing off @mm2270, would sudo jamf policy -id 0 meet your needs?

el2493
Contributor III

@dan.snelson , thanks very much, that's exactly what I was looking for!

@mm2270 , in the tech's defense (for better or worse) they didn't even mention checkJSSConnection, I only found that myself later when looking for an option other than recon. Thanks for your recommendation, though, that also sounds like a totally valid way to do it.

mm2270
Legendary Contributor III

@el2493 Ah, ok, that makes more sense. Still, a recon has overhead and adds bloat to the db, so it's not a great method of checking a connection to the JSS, in my opinion.
Anyway, glad you got it worked out. I will say that @dan.snelson's suggestion of calling policy -id 0 is actually pretty good too. That's actually easier than setting up a distinct policy to call by a custom trigger just for checking connectivity.

marklamont
Contributor III

is id 0 meant to be a null policy? I tried this and it started delivering an actual policy.

el2493
Contributor III

@marklamont , if you try to open the policy in a browser (https://yourjss.com/policies.html?id=0&o=r) does it open anything? I tried it and just got one of the JSS "The page you requested could not be found" pages. I haven't tested @dan.snelson's method, but I assume if I get that message that his method would work.

dan-snelson
Valued Contributor II

@marklamont Yes, Policy ID 0 should be a "null" policy; which version of Jamf Pro are you running?

Does sudo jamf policy -id -1 act like a "null" policy?

troyewebster
New Contributor III

related question: if checkjssconnection times out ... what does that indicate in terms of the client device network configuration? We are trying to introduce Apple devices for the first time into an enterprise network, and are having a hard time getting the firewall rules correct. What port/ips does checkjssconnection need opened up so that it doesn't time out?