From Electron Cloud
Jump to: navigation, search
(xinetd)
Line 13: Line 13:
  
 
Security wonks have been spoiling a lot of the fun on the Internet for a while now, so useful little gems like this tend to be disabled by default lest they be exploitable.  Somehow I doubt this one poses much risk, since it's a one-way conversation.  Hopefully xinetd's implementation doesn't have buffer-overflow bugs.
 
Security wonks have been spoiling a lot of the fun on the Internet for a while now, so useful little gems like this tend to be disabled by default lest they be exploitable.  Somehow I doubt this one poses much risk, since it's a one-way conversation.  Hopefully xinetd's implementation doesn't have buffer-overflow bugs.
 +
 +
===it doesn't work===
 +
 +
$ rdate time.iastate.edu
 +
rdate: Unable to connect to remote host (129.186.1.199): Connection refused
 +
 +
That's quite likely a firewall issue (again, the security wonks tend to believe every open port should be on an as-needed basis only.  Thousands are available, but you can only use HTTP, through a proxy, and please bow in gratitude for that.)  All the more reason to install your own rdate server locally. 
 +
 +
$ rdate 10.x.x.x
 +
rdate: 10.x.x.x did not send the complete time
 +
 +
That would probably be xinetd denying the connection; you can watch this happen in <tt>/var/log/everything/current</tt> or some such (depending which syslogd you are running):
 +
 +
Jan  9 16:33:08 [xinetd] FAIL: time-stream address from=10.x.x.y
 +
 +
which is fixed by permission settings in <tt>/etc/xinetd.conf</tt> and/or <tt>/etc/xinetd.d/time-stream</tt>.

Revision as of 17:04, 9 January 2008

rdate is an antiquated method of time and date synchronization between Unix machines. The service is a daemon listening on port 37, which when you connect to it, returns 4 bytes: the Unix timestamp (number of seconds since Jan 1 1970) and then drops the connection. The client program (rdate) doesn't try to account for network delays, nor continuously correct the clock, like the more modern ntpd (network time protocol daemon): it's just a one-shot synchronization. However it can be useful on embedded systems because busybox conveniently provides the rdate client.

So how do you set up an rdate server? This page says "don't bother," but I didn't find that a very acceptable answer.

xinetd

xinetd has rdate support built-in. The conf file /etc/xinetd.d/time-stream describes how it is to be offered. The default configuration is OK except that you need to change the line

disable = yes

to disable = no. And also comment out this line in /etc/xinetd.conf:

#       only_from       = localhost

Security wonks have been spoiling a lot of the fun on the Internet for a while now, so useful little gems like this tend to be disabled by default lest they be exploitable. Somehow I doubt this one poses much risk, since it's a one-way conversation. Hopefully xinetd's implementation doesn't have buffer-overflow bugs.

it doesn't work

$ rdate time.iastate.edu
rdate: Unable to connect to remote host (129.186.1.199): Connection refused

That's quite likely a firewall issue (again, the security wonks tend to believe every open port should be on an as-needed basis only. Thousands are available, but you can only use HTTP, through a proxy, and please bow in gratitude for that.) All the more reason to install your own rdate server locally.

$ rdate 10.x.x.x
rdate: 10.x.x.x did not send the complete time

That would probably be xinetd denying the connection; you can watch this happen in /var/log/everything/current or some such (depending which syslogd you are running):

Jan  9 16:33:08 [xinetd] FAIL: time-stream address from=10.x.x.y

which is fixed by permission settings in /etc/xinetd.conf and/or /etc/xinetd.d/time-stream.