How do you deal with unreliable peers?

OtagoHarbour · 07-04-2014, 03:14 PM

I ran lynis 1.5.6 and got the following log message.

Code:

[07:39:52] Performing test ID TIME-3120 (Check unreliable NTP peers)
[07:39:52] Test: Checking unreliable ntp peers
[07:39:52] Result: Found one or more unreliable peers (marked with a minus or dash sign)
[07:39:52] Unreliable peer: 50.7.96.4
[07:39:52] Suggestion: Check ntpq peers output for unreliable ntp peers and correct/replace them [TIME-3120]

I ran

Code:

 sudo ntpq -i

and it gives the commands explained here. However, it does not say how to correct or replace a peer.

Thanks,
OH

dijetlo · 07-04-2014, 05:46 PM

I normally add a local loopback to avoid having NTPD flip out

Quote:

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

The rest depends on whether you're using a regional pool (in which case, that's probably the best that's available in your area) or are you specifying individual time servers (in which case, I'd switch to the regional pool) or perhaps it's your network connection, in which case the best is probably the loopback.
Take a look here

OtagoHarbour · 09-14-2014, 02:09 PM

Quote:

Originally Posted by dijetlo

I normally add a local loopback to avoid having NTPD flip out

The rest depends on whether you're using a regional pool (in which case, that's probably the best that's available in your area) or are you specifying individual time servers (in which case, I'd switch to the regional pool) or perhaps it's your network connection, in which case the best is probably the loopback.
Take a look here

Thank you for your reply and sorry about the delay. I missed your reply for some reason. Could have been when early lynis suggestion were causing me problems. I will check your link out.

Thanks,
OH

OtagoHarbour · 09-14-2014, 02:37 PM

Quote:

Originally Posted by dijetlo

I normally add a local loopback to avoid having NTPD flip out

The rest depends on whether you're using a regional pool (in which case, that's probably the best that's available in your area) or are you specifying individual time servers (in which case, I'd switch to the regional pool) or perhaps it's your network connection, in which case the best is probably the loopback.
Take a look here

I made the changes at the link you suggested but still get the lynis suggestion. I looked in /var/log/ntpstats and there was nothing there. I did give the unreliable peer as 50.7.0.147 which is Abovenet Communications according to isc.sans.edu.