Posted on 07-03-2018 08:58 AM
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.
Solved! Go to Solution.
Posted on 07-03-2018 09:27 AM
@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
Posted on 07-03-2018 09:27 AM
@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
Posted on 07-03-2018 09:30 AM
@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
Posted on 07-03-2018 09:41 AM
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.
Posted on 07-03-2018 09:51 AM
Posted on 07-03-2018 11:00 AM
@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.
Posted on 07-03-2018 03:16 PM
@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.
Posted on 07-04-2018 10:33 PM
is id 0 meant to be a null policy? I tried this and it started delivering an actual policy.
Posted on 07-05-2018 05:55 AM
@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.
Posted on 07-05-2018 08:11 AM
@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?
Posted on 11-07-2018 06:49 AM
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?