JSS epoch error

[lisacherie]

Hello All,

Over the last couple of days I have noticed a number of polices failing when submitting logs with the error:

The JSS did not return an epoch to compare for time skew. The data can not be trusted and will not be used.

- The maximum clock skew in management framework settings is set to: Do Not Verify
- The JSS is also the NTP server
- The time, date, and timezone on the JSS are all correct.
- JSS recently updated to 8.21

Any suggestions appreciated.

Thanks,

Lisa.

Lisa Davies
ICT Client Services Manager
Saint Ignatius' College, Riverview
Phone: 02 9882 8413
Mobile: 0417 005 735

[Matt]

I have these on random machines as well. Never really figured out the issue other than reimaging fixed it.

--
Matt Lee, CCA/ACMT/ACPT/ACDT
Senior IT Analyst / Desktop Architecture Team / Apple S.M.E / JAMF Casper Administrator
Fox Networks Group

[rmanly]

Anyone seen this again lately?

I just noticed it for the first time today on a machine. It logs about 30
messages at login/logout and during the every15.

My JSS is NOT the NTP server.

Ryan M. Manly
Glenbrook High Schools

[lisacherie]

Hi Ryan,

In the last couple of days the epoch problem has come up to bite us again. There were a small number of clients that although set to use the NTP server, the clock had drifted between 10 - 20 minutes, and although our NTP server is configured to correct time with a greater difference than this, for an as yet unknown reason these clients would not correct the time.

We have so far seen a few clients with this problem sending large amounts of data to our JSS after updating to 8.31. (JAMF support were very helpful in assisting us with this issue).

Please note the verify skew is not enabled on our JSS.

The following extension attribute will find clients with the epoch problem:

#!/bin/sh

EPOCHVAR=/usr/bin/tail -50 /private/var/log/jamf.log | grep "The epoch on the JSS is more than 300 seconds different than local epoch. The data can not be trusted and will not be used." | wc -l | cut -d " " -f 7

echo "<result>$EPOCHVAR</result>"

With the result returned an integer, a smart group then can provide a list of all the clients with the epoch issue where greater than 0.

I was able to resolve on clients this time by turning network time off, setting the time, turning back on. Unfortunately the clients were not properly executing policies whilst having this error making more difficult to fix (ie. i couldn't just scope a policy to the smart group). If you are confident in scripting, as they do run inventory reports properly you could possibly make the extension attribute script a bit longer to fix the clients.

systemsetup -setusingnetworktime off
systemsetup -settime "HH:MM:SS"
systemsetup -setusingnetworktime on

I hope this helps.

Lisa.

Lisa Davies
ICT Client Services Manager
Saint Ignatius' College, Riverview
Phone: 02 9882 8413
Mobile: 0417 005 735

[sean]

Ryan,

What is your NTP server, internal or external. We run an internal NTP server and we don't see this. Our NTP server is a round robin of linux boxes that all machines in the company point at.

Although Lisa's idea of using an EA may help, it isn't really fixing the problem. It may be more useful to try and work out when and why machines aren't syncing, which of course because of the randomness of time drift may be quite tricky.

I would suggest writing something that looks at the difference between your machines time and your NTP server.

ntpq -p

will show you your NTP server and 'offset' between your machine and your NTP server.

ntpdc -p

should print the list of peers known to the server.

run

ntpq -p [hostname]

hostname from a peer from the previous command should potentially list a bunch of time servers. NB. the character before the servers,

* or + for example

For an explanation of these, check out:

http://support.ntp.org/bin/view/Support/TroubleshootingNTP

The 'offset' should be consistent. You could maybe run a periodic policy/launchd that analyses the offset, looks for change and then if it does differ, start checking the communication to the NTP server.

If there is deviation, you could output this to the log file yourself. Set a variable with your offset, eg. timeOffset and then run something like:

logger -t ntp_drift message I have drifted by $timeOffset

The tag (-t) could be $0, which would return the name of the script that the command was run from. Add to the log any information about testing your time server as well.

Just an idea.

Sean

[SIXfoot5ins]

We had a small number of machines producing this epoch error, thanks for the pointers above.

Our machines had the wrong network time server, once I checked it with the ntpq -p command
I then sudo systemsetup -setnetworktimeserver <timeservername> to set the time server to what it should be

Then..
sudo systemsetup -setusingnetworktime off
sudo systemsetup -settime "HH:MM:SS"
sudo systemsetup -setusingnetworktime on

...to set the correct time

Hope this helps someone

[SIXfoot5ins]

We had a small number of machines producing this epoch error, thanks for the pointers above.

Our machines had the wrong network time server, once I checked it with the ntpq -p command
I then sudo systemsetup -setnetworktimeserver <timeservername> to set the time server to what it should be

Then..
sudo systemsetup -setusingnetworktime off
sudo systemsetup -settime "HH:MM:SS"
sudo systemsetup -setusingnetworktime on

...to set the correct time

Hope this helps someone

[#8]

I've seen this error off and on for awhile now; the only reliable solution I've found so far is to use Recon.app from another machine. After that, running ```
jamf recon
``` works fine.