ntp problems
in [Linux Networking]
|
Prev: ntp problems
Next: gateway setup
From: Bonno Bloksma on 19 Apr 2010 11:24 Hi, Using Debian Lenny, default install of ntp on several servers. The only change applied on most servers is to add a line to a nearby startum 2 server. Somehow is looks as if the ntp server is running ok but clients cannot connect. Can I assume rdate is a proper ntp client? And if rdate -p 127.0.0.1 fails that there is a problem? ----------<quote>------------------------------- linbobo:~# rdate -p 127.0.0.1 rdate: Could not connect socket: Connection refused ----------<quote>------------------------------- iptables is running full open as this is an internal server. ----------<quote>------------------------------- linbobo:~# iptables -L -v Chain INPUT (policy ACCEPT 137K packets, 58M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 370K packets, 115M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 134K packets, 16M bytes) pkts bytes target prot opt in out source destination linbobo:~# ----------<quote>------------------------------- The entire /etc/ntp.conf file (without the comment and blank lines) is: ----------<quote>------------------------------- driftfile /var/lib/ntp/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 0.debian.pool.ntp.org iburst dynamic server 1.debian.pool.ntp.org iburst dynamic server 2.debian.pool.ntp.org iburst dynamic server 3.debian.pool.ntp.org iburst dynamic restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 ----------<quote>------------------------------- The syslog file shows this after a stop/start of the service ----------<quote>------------------------------- [....] Apr 19 17:10:59 linbobo ntpd[9084]: ntpd exiting on signal 15 Apr 19 17:11:25 linbobo ntpd[9167]: ntpd 4.2.4p4(a)1.1520-o Sun Nov 22 17:34:54 UTC 2009 (1) Apr 19 17:11:25 linbobo ntpd[9168]: precision = 1.000 usec Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #1 wildcard, ::#123 Disabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #2 lo, ::1#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #3 eth0, fe80::21c:c0ff:fe72:997f#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #5 eth0, 192.168.1.10#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #6 eth0, 172.16.17.1#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: Listening on interface #7 tun0, 172.16.1.138#123 Enabled Apr 19 17:11:25 linbobo ntpd[9168]: kernel time sync status 0040 Apr 19 17:11:25 linbobo ntpd[9168]: frequency initialized -11.117 PPM from /var/lib/ntp/ntp.drift Apr 19 17:11:32 linbobo ntpd[9168]: synchronized to 85.17.133.31, stratum 2 Apr 19 17:11:32 linbobo ntpd[9168]: kernel time sync status change 0001 Apr 19 17:11:44 linbobo ntpd[9168]: synchronized to 79.141.36.205, stratum 2 Apr 19 17:17:01 linbobo /USR/SBIN/CRON[9198]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) [....] ----------<quote>------------------------------- As you can see the rdate command leaves no trace in the log. Now why would a simple rdate command on the local command line fail? the iptables INPUT chain is set to ACCEPT and the ntp config file has almost no restrictions to the loopback address. In the end I want to allow client from the local 172.16.0.0/16 network, but that should allready be allowed by the restict -4 default .... line as far as I can see, right? Anyone any idea what is going wrong? Bonno Bloksma
From: David Schwartz on 19 Apr 2010 11:37 On Apr 19, 8:24 am, "Bonno Bloksma" <bblok...(a)xs4all.nl> wrote: > Can I assume rdate is a proper ntp client? No, rdate is an RFC868 time client with no relationship whatsoever to ntp. Use 'ntpdate'. > And if rdate -p 127.0.0.1 fails that there is a problem? It would be surprising if it succeeded since most Linux boxes stopped supporting that protocol around the same time they stopped running 'inetd' by default. DS
From: David Schwartz on 20 Apr 2010 15:05 On Apr 19, 7:13 pm, Sidney Lambe <sidneyla...(a)nospam.invalid> wrote: > I don't run a timeserver here. I set the gateway computer's clock > using rdate and then use scripts calling date on the other > boxes on the LAN to read and set their time from the gateway > box. It is possible to bash in a screw with a hammer, yes. > Now you are going to tell me that it doesn't work when it works > perfectly well. Yep, it works perfectly well to bash in screws with hammers. It just doesn't make any sense when screwdrivers are just as widely available. > You are a dumb sheep who does things the way others do it > because you don't like to think for yourself. Right, I'm a sheep because I use the best available tools the way they are designed to be used rather than trying to cobble together a half- assed solution myself. Believe me, I am perfectly willing to tell everyone else they are doing it wrong when that is what I believe. DS
From: Bonno Bloksma on 19 Apr 2010 12:05 Hi, >> Can I assume rdate is a proper ntp client? >No, rdate is an RFC868 time client with no relationship whatsoever to >ntp. Use 'ntpdate'. Ok, that explains a lot. >> And if rdate -p 127.0.0.1 fails that there is a problem? >It would be surprising if it succeeded since most Linux boxes stopped >supporting that protocol around the same time they stopped running >'inetd' by default. On a HP switch there is the option TimeP or SNTP. Eventhough TimeP is still the default it seems I then need to use SNTP to talk to a NTP server. If I have other hardware that only understands RFC868, can I service them as well, is there a converter available I can install on my Debian Lenny servers? Bonno Bloksma
From: Tauno Voipio on 20 Apr 2010 11:54
On 20.4.10 5:30 , Bonno Bloksma wrote: > Hi, > >> I am confused. You have Linux machines on which you want to have >> accurate ( say better than 1msec) time, and some network devices which >> you want time to say 1 sec. So on the Linux machines you can run ntpd or >> chrony with some network sources (eg pool.ntp.org sources). > > I'de like to have a good timesource in my network. For those machines/devices capable I would like > those to have a proper time by using the (s)ntp protocol. > For machines/devices that only understand the old time protocol I want them to be able to use my > Linux servers as a time source too. The ones using the older time protocol are usualy the ones where > a few (hundred) miliseconds do not matter. > >> If your >> "network devices" only understand the time, not the ntp protocol, you >> could always run the time servers. > > Ok, which daemon do I install on my Linux server so it will provide the local time, which has been > set acurately by the ntp daemon, to other devices via the older time protocol? > I do NOT want that daemon to modify the time of my Linux servers, it is to use the local time as a > source. > Did I make more sense this time? > >> Not sure what you mean by "entire >> xinetd environment". You just run one daemon. Or you can run the time >> daemon directly. > > I probably do not know enough about (x)inet, I have allways understood it to be some framework that > launches other daemons. If I don't need the complete framework to run just one daemon then why > should I do so? Is there an advantage to that? > >> Either way. But since the Linux machine is already >> running ntp, use ntp on the "network devices" or use ntpdate from >> crontab. It is definitely a second best-- the time becomes a sawtooth, >> as the local clock is stepped. > > You are right, I don't want the local clock modified by the older time protocol daemon. > > Bonno Bloksma If your servers are running Debian Lenny, they probably are already using inetd as the network super-server. Check with ps -ef if there is an inetd process running. Then, check the file /etc/inetd.conf for the lines time stream tcp nowait root internal #time dgram udp wait root internal If they are like above, the time service is enabled for TCP but not for UDP. Change the lines as you feel needed and re-start inetd. The time server takes its reference from the host clock, so it is OK, if you have a synchronized NTP running on the server. I'd set up NTP daemons (ntpd) on all servers, peer them together and with some outside references. One good candidate is pool.ntp.org. -- Tauno Voipio tauno voipio (at) iki fi |