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...@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
> 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
>> 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
No. rdate has absolutely nothing to do with ntp. It is an ancient time
deamon/proceedure.
> And if rdate -p 127.0.0.1 fails that there is a problem?
No, rdate has nothing to do with ntp. It does NOT use the ntp protocol.
YOu could try ntpdate.
Yes. You should use SNTP rather than TimeP
> 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?
You could install/enable xinted - not sure if it has a date/time
built-in service like most inetds or not but that should become
obvious in short order. I wouldn't count on "great" time
synchronization that way though.
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Or ntpd, or chrony, both of which will discipline your local time to
better than a ms.
sntp is a cutdown implimentation of ntp for use for final leaves in a
tree ( ie it shoulc not be used as a server for anything else). Your
switch may well be something you use to then discipline other clocks on
your network.
>
>> 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?
>
> You could install/enable xinted - not sure if it has a date/time
> built-in service like most inetds or not but that should become
??? What has xinetd to do with time? Or inetd?
> Or ntpd, or chrony, both of which will discipline your local time to
> better than a ms.
Have you ported chrony to HP ProCurve switches?-)
rick jones
--
I don't interest myself in "why". I think more often in terms of
"when", sometimes "where"; always "how much." - Joubert
What operating system do they run? If it is linux or bsd then it might
well work. If not, then no.
>
> rick jones
> 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?
I don't specifically know Debian Lenny, but whatever inetd-equivalent
is supplied on that platform should have that capability. If you have
xinetd, follow this process:
1) Make sure no xinetd services are enabled that you don't want
enabled. Check each file in '/etc/xinetd.d'. (Only needed if xinetd is
not running already.)
2) Edit 'time-dgram' and 'time-stream' to enable these services and,
if desired, restrict them.
3) If needed, start xinetd and configure it to self-start on reboots.
DS
IF all you want is time to withing 10s to 100s of ms, then this will
work, sort of ( results in a sawtooth behaviour of your clock). If you
want better accuracy and a clock that runs at the correct rate to PPM,
then use the ntp process to set your clock (ntpd, chrony,...)
The time protocol is an ancient protocol which has been supersceded by
ntp.
> If all you want is time to withing 10s to 100s of ms, then this will
> work, sort of ( results in a sawtooth behaviour of your clock). If you
> want better accuracy and a clock that runs at the correct rate to PPM,
> then use the ntp process to set your clock (ntpd, chrony,...)
> The time protocol is an ancient protocol which has been supersceded by
> ntp.
Worst of all, if your hardware clock is fast, setting the clock using
rdate may result in repeated backwards jumps in wall clock time. I
should have pointed out that a much better solution is to relegate
RFC868 to the dustbin of history.
DS
> On Apr 19, 8:24=A0am, "Bonno Bloksma" <bblok...@xs4all.nl>
You are mistaken. It comes with the latest Debian, for starters:
http://packages.debian.org/lenny/rdate
(This will work just fine on any distro. Is a simple utility
needing only the basic libs to function.)
For the newbies:
ar x whatever.deb
will give you three files. You only want data.tar.gz.
Put it in / and run:
tar xvzf data.tar.gz
and it will install itself.
I have been using rdate, running from a cron job, for years, with
no problem at all.
Why hassle with a complex app like NTP for such a simple
task?
For the OP:
Just go to:
http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers
And find a nearby time server.
There are at least two versions of rdate around. The one I
use requires the -s option to actually set the time. -p
just displays the time given by the remote timeserver.
The newer version of rdate supports both RFC 868 and 2030.
And alternate ports.
Sid
> >> 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.
> You are mistaken. It comes with the latest Debian, for starters:
>
> http://packages.debian.org/lenny/rdate
>
> (This will work just fine on any distro. Is a simple utility
> needing only the basic libs to function.)
Even if you have 'rdate', 'rdate -p 127.0.0.1' will fail if you're not
running the 'rdate' server. When most distributions stopped enabling
'inetd' by default, they generally also stopped providing 'rdate'
service by default. This applies whether or not you have a client or
server installed.
> I have been using rdate, running from a cron job, for years, with
> no problem at all.
You're getting sucky performance and risking a number of known
problems.
> Why hassle with a complex app like NTP for such a simple
> task?
Clock synchronization is not simple. It's very simple to do a mediocre
job of it though.
DS
Another fatheaded idiot telling me that something I have been doing
successfully for years doesn't work.
I have just given him the score that tells me that his technical
advice is to be approached with caution.
Sid
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.
Now you are going to tell me that it doesn't work when it works
perfectly well.
Do you have a Schrader valve on your head to relieve the
pressure when it gets too fat?
You are a dumb sheep who does things the way others do it
because you don't like to think for yourself.
[delete]
Sid
>>> 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.
>>
>> Yes. You should use SNTP rather than TimeP
>
> Or ntpd, or chrony, both of which will discipline your local time to
> better than a ms.
> sntp is a cutdown implimentation of ntp for use for final leaves in a
> tree ( ie it shoulc not be used as a server for anything else). Your
> switch may well be something you use to then discipline other clocks on
> your network.
No, the Linux machines are at the heart of all the site networks and wil be the time reference for
all machines** at that site. I have several network devices that need a somewhat accurate time in
order to have a proper timestamp in the logs. If that means that by using the only available but old
protocol it is even a second of I still would not care. ;-)
I want the Linux machines to be a good time source for my network. Anything that pulls the time
needs only be as good as it needs to be. So if the server itself is using ntp to reference several
servers on the internet and a nearby stratum 2 server it can then use something else to service
devices which use only the older time protocol, if need be.
I would rather not run an entire xined environment just to provide the old time protocol but if that
is what it takes.... If someone knows a better way I'd like to know about it.
Bonno Bloksma
** Except the Windows machines that are part of the Active Directory which will use the AD internal
timesync.
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). If your
"network devices" only understand the time, not the ntp protocol, you
could always run the time servers. Not sure what you mean by "entire
xinetd environment". You just run one daemon. Or you can run the time
daemon directly. 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.
>
Why are you so auto-aggressive?
Why do you need to start flaming all the time?
Why can't you stay technical?
Why confront all the world with your negative emotions?
Why not stay friendly?
What's so hard about it?
What would the groups look like if everyone would be battlesome like you?
> On 20.04.2010 03:42, Sidney Lambe wrote:
> [...]
>>
>> Another fatheaded idiot telling me that something I have been doing
>> successfully for years doesn't work.
>>
>> I have just given him the score that tells me that his technical
>> advice is to be approached with caution.
>>
>> Sid
>
> Why are you so auto-aggressive?
> Why do you need to start flaming all the time?
Simple: He is Alan Connor
Easily one of the dumbest kooks on usenet of all time
--
The nice thing about standards is that there are so many of them
to choose from. -- Andrew S. Tanenbaum
Well, that's just the negative projection in the reverse direction.
Don't judge one as an idiot for judging others as idiots. You'd do just
the same. That's moving around the hate.
Characters are not static, they can change.
Most likely this person didn't get enough love in hist life.
Calling him dumb cannot create a constructive reaction.
> On 20.04.2010 10:35, Peter Köhlmann wrote:
>> Mart Frauenlob wrote:
>>
>>> On 20.04.2010 03:42, Sidney Lambe wrote:
>>> [...]
>>>>
>>>> Another fatheaded idiot telling me that something I have been doing
>>>> successfully for years doesn't work.
>>>>
>>>> I have just given him the score that tells me that his technical
>>>> advice is to be approached with caution.
>>>>
>>>> Sid
>>>
>>> Why are you so auto-aggressive?
>>> Why do you need to start flaming all the time?
>>
>> Simple: He is Alan Connor
>>
>> Easily one of the dumbest kooks on usenet of all time
>
> Well, that's just the negative projection in the reverse direction.
> Don't judge one as an idiot for judging others as idiots.
Just read "Sidneys" history in other newsgroups.
He *is* Alan Connor.
And that twit is easily one of the dumbest kooks in usenet history
> You'd do just
> the same. That's moving around the hate.
> Characters are not static, they can change.
> Most likely this person didn't get enough love in hist life.
Well, I guess even his mother would be disgusted by that guy
> Calling him dumb cannot create a constructive reaction.
It is just the most polite way to describe "Sidney". He isn't smart. Dirt
has a higher IQ
--
I say you need to visit Clues 'R' Us. They are having a special on
slightly used clues.
> 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
> 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
> Now you are going to tell me that it doesn't work when it works
> perfectly well.
You can bash in every screw you ever put in with a hammer if you want.
But if you suggest other people do that, when screwdrivers are easily
available, you are the kook.
> You are a dumb sheep who does things the way others do it
> because you don't like to think for yourself.
Quite the contrary, I do things the way others do it because it makes
sense. Screws and screwdrivers are designed to work together
perfectly. There's no genius of independent thinking in bashing screws
in with hammers. If you want to do things an objectively inferior way
just to be different, that's your business.
DS
While the description might have been more polite, it would be difficult
to make it more accurate. And while it's certainly possible he might
change (and we would all rejoice if he did), there's no evidence of it
happening in the posts he's contributed to this thread.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
My killfile is feeding well on this thread. Another batch of
dickless losers who get their little rocks off insulting people
while they hide behind the Internet.
Scum like this are a dime-a-dozen on the Usenet.
Sid
And all 12 of those aliases usually belong to the same mentally
creep.
And the poor feeb thinks he's accomplishing something.
>
> Sid
>
>
>
There was only a tcp line and it was commented out. I now have both a tcp and udp time setup.
Restarted inetd and it all works :-)
>
> 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.
>
Yup, that is the way I have it set up.
Thanks for all the help, once you know the way it is supposed to be done, it is so simple. But to
find out how to do it..... :-)
And there wasn't a HOWTO for this, or at least I did not find it.
Bonno Bloksma
> My killfile is feeding well on this thread. Another batch of
> dickless losers who get their little rocks off insulting people
> while they hide behind the Internet.
>
> Scum like this are a dime-a-dozen on the Usenet.
>
> Sid
You're so full of hate, it really is sad to see :/
Don't you see, you are the one insulting in the first place in all the
posts I've read from you yet.
Then people react on you with insulting back, which causes more
insulting from you, and so on....
Will it ever stop?
Do you want to spend the rest of your life in flame-wars?
I got some homework for you!
Every time you are about to insult someone, rest for a moment, and write
the exact opposite. Write as friendly, respectful and loving as you can.
See if it changes things...
Wish u well
Mart
___________________________
/| /| | |
||__|| | Please don't |
/ O O\__ feed |
/ \ the trolls |
/ \ \ |
/ _ \ \ ----------------------
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________
--
Jon Solberg (remove "nospam." from email address)
I just discovered my memory was faulty. Each box on the LAN hits
the pool once an hour at different times using rdate. Been working
just fine for years. The orignal scripts that worked as described
above are in the same file, commented out. Don't remember when
I abandoned them.
I laughed when I read the OP saying that it was all so simple.
Right. Everything is once you know how to do it. Sure didn't
seem simple to him when he posted here after being unable to
make it work for so long.
And ntpd sure isn't simpler than cron calling simple rdate
scripts. I've never had ANY problems and never will. And
it takes a tiny fraction of the system resources by comparison.
Sid
From man rdate:
-n Use SNTP (RFC 2030) instead of the RFC 868 time protocol.
Open mouth, insert foot. And this is the second time (at least) this
has been posted on this thread.
Sid
> I just discovered my memory was faulty.
Your entire brain is "faulty", Alan Connor. You're a certified nutjob,
and a well-known Usenet Kook.
Fuck off and get back in your room.
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as the Facehugger impregnated him.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg
Actually it is, and it keeps the clocks running far more accurately than
your system does. That may not be important for you, so keep going with
your approach. For example if the network goes down for a day, you will
typically be out by many seconds by the end of the day. And ntp machine
would be out by milliseconds. But if you do not care about that, fine.
also, if the machine you get your time from goes down, or worse, its
clock goes nuts for some reason, so will yours. ntpd has backups to
detect crazy source. Again, if you do not care about this, use your
technique.
>
> Sid
>
>
Are you serious?
> and it keeps the clocks running far more
> accurately than your system does. That may not be important
> for you, so keep going with your approach.
Like I need your permission.
"My system" (which you obviously don't understand) has been
working fine for years. Never had a problem with anything.
> For example if the network goes down for a day, you will
> typically be out by many seconds by the end of the day.
It went down for 5 days once and was only off by an average
of 7 seconds.
> And ntp machine would be out by milliseconds.
And this accomplishes what when the network is down anyway?
> But if you do not
> care about that, fine. also, if the machine you get your time
> from goes down, or worse, its clock goes nuts for some reason,
> so will yours.
That explains why your article here makes no sense. Try actually
reading the post your are replying to. Each machine here contacts
the ntp pool independently.
> ntpd has backups to detect crazy source. Again, if you do not
> care about this, use your technique.
How good of you to give me permission to do what I do. I am so
greteful.
And all this from the guy who told everyone that rdate doesn't
do SNTP.
I go with what works best. And ignore the advice of fatheaded geeks like
you. _That's_ my system. It works very well indeed.
If I listened to people like you I'd be bogged down with so much
unnecessary software that my network would require constant
attention. As it is now, it is, literally, maintenance free.
Sid
It accomplishes your machine only being off by milliseconds after 5 days
even though the network is down. It also accomplishes making sure that
the clock does not step backwards and have later files timestamped with
earlier times.
Actually it does not on Linux
(at least the distros I have seen). On openbsd apparently it has been
rewitten so it does.
>>
>> I go with what works best. And ignore the advice of fatheaded geeks like
>> you. _That's_ my system. It works very well indeed.
Fine, as I pointed out, you have my permission to do whatever you want
on your system. When you advise other people, as you have done here,
I will continue to point out the problems with your solution.
I know your type. You couldn't admit you were wrong about something
if your life dependended in it.
[delete]
Sid
> From man rdate:
>
> -n Use SNTP (RFC 2030) instead of the RFC 868 time protocol.
>
> Open mouth, insert foot. And this is the second time (at least) this
> has been posted on this thread.
I know you're trolling, but for the benefit of everyone else, this is
a completely different 'rdate' than the one the OP (and everyone else
but Sidney Lambe) was talking about.
DS
Here is the man page for rdate from Mandriva 2010.0, the latest
distribution.
Note the absense of anything about ntp.
OpenBSD seems to use a different one, which you quoted from. Since this
is a discussion in a Linux newsgroup, ....
RDATE(1) Red Hat
RDATE(1)
NAME
rdate - get the time via the network
SYNOPSIS
rdate [-p] [-s] [-u] [-l] [-t sec] [host...]
DESCRIPTION
rdate connects to an RFC 868 time server over a TCP/IP network,
print-
ing the returned time and/or setting the system clock.
OPTIONS
-p Print the time returned by the remote machine.
-s Set the system time to the returned time.
-u Use UDP instead of TCP as the transport.
-l Use syslog to output errors (cron.warning) and output
(cron.info).
-t Set timeout in seconds for every attempt to retreive date.
HISTORY
2004-03-16 Johan Nilsson <joh-...@dsv.su.se>
Timeout support added.
2002-11-06 Elliot Lee <sop...@redhat.com>
Patch from Tomek Orzechowski <orz...@pld.org.pl> - alarm(10) to
not wait forever for connections.
2001-05-23 Phil Knirsch <pkni...@redhat.com>
Added UDP protocol support. Close the connection after message
handling in conformance to RFC 868.
2002-03-07 Elliot Lee <sop...@redhat.com>
Add syslog functionality.
2000-02-04 Elliot Lee <sop...@redhat.com>
Wrote it (previous incarnation had license problems, all 200
lines of it).
Utilities May 2001
RDATE(1)
~
[delete]
Think you are so smart, David?
On your system, using ntp, if the box running ntpd goes down you
are screwed. If ntpd goes down you are screwed.
On my system, all the boxes get their time independently with
rdate. It is decentralized. It is far more secure than yours.
No. I am not going to read your reply. I already know that
you are never wrong.
You and unruh. Boring fatheads.
Sid
> You and unruh. Boring fatheads.
>
> Sid
You're losing your touch. You were much funnier when you suggested an
email system that would solve everyone's spam problems. The system had
one minor flaw though-- a minor scaling problem. Specifically, it
wouldn't scale to more than one user.
DS
It would be really really nice if you knew even a little bit about ntp.
If ntp on his box goes down, the box keeps the correct time to seconds
per week or better for a long time. If ntp goes down on the server, then
the other servers he has back it up. ntp is far more decenterised than
rdate. On rdate if one box goes nuts, then when that box is queried,
your computer's time is set to that weird date/time. Then when the next
one is queried, the time jumps to whatever time it has, etc.
>
> On my system, all the boxes get their time independently with
> rdate. It is decentralized. It is far more secure than yours.
Far less decenteralised than ntp.
I see that both of these would-be bullies have replied to this.
They actually think I am going argue with them forever.
Pay attention, fatheads: I have heard your advice. It is lousy.
That's what I think and you'll just have to live with it.
Yes, there are actually people who disagree with you. And that
you can't bully into seeing things your way.
Life's a bitch.
Too bad. Maybe you could complain to your mommies or something.
Sid
with all do respect, i use openntpd on slackware and when my machine
crashes or gets halted.
it drifts a lot of seconds: 11
then when i restart the machine it gets adjusted by openntpd
with very small increments a lot of times untill it is synced again
after an hour or two
same happens when i lose network connection.
> with all do respect, i use openntpd on slackware and when my machine
> crashes or gets halted.
>
> it drifts a lot of seconds: 11
> then when i restart the machine it gets adjusted by openntpd
> with very small increments a lot of times untill it is synced again
> after an hour or two
>
> same happens when i lose network connection.
That's one of the many reasons not to use OpenNTPd.
DS