[lopsa-tech] NTP

[Yves Dorfsman]

I'm thinking there might be other people as confused as me "out here", so
I'll try here before I go the newsgroup way...

Here's my understanding of current ntp, and would love to hear where I'm
wrong, or comment about it:

1) ntpdate is bad and shouldn't be used

2) ntpd talks over UDP, and on port 123 on BOTH side

3) contrary to ntpdate, nptd uses two connections, one going out, one
coming in (if I close connections coming in on port 123, ntpd -gq doesn't
work) ?

4) the "restrict" command in ntp.conf is very powerfull (read dangerous),
widely misunderstood, badly documented, and affects ntpd not only as a
server, but as a client as well. Therefore, and contrary to what is
written in the comments of ntp.conf, "restrict default ignore" prevents
anybody from accessing your ntpd server, but ALSO prevents ntpd to
function as a client unless you add a restrict command for the server(s)
you are going to talk to.

5) you should really use *.pool.ntp.org rather than specific servers from
th internet

6) because of 2), 3) 4) and 5), you cannot use ntpd to sync your machine
from the internet, without allowing other machines from the internet to
use you a time server.

7) if you use "restrict default kod nomodify notrap nopeer noquery"
you're limiting the type of DoS attacks that can be done against you on
port 123, but some are still possible ???


Thank you !

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[Brad Knowles]

Post by Yves Dorfsman
I'm thinking there might be other people as confused as me "out here", so
I'll try here before I go the newsgroup way...

If you have any questions regarding NTP that are not answered by the
Official Documentation (see
<http://www.eecis.udel.edu/~mills/ntp/html/index.html>), or the FAQ
(see <http://www.ntp.org/ntpfaq/NTP-a-faq.htm>), or the Community
Supported Documentation (see
<http://support.ntp.org/bin/view/Support/WebHome>), or the archives
of the mailing list ***@ntp.org (which is gatewayed to the
USENET newsgroup comp.protocols.time.ntp, see
<https://lists.ntp.org/mailman/listinfo/questions>), then you should
post those to the mailing list.

Asking questions regarding NTP elsewhere is not as likely to get you
any useful response. I am very sorely tempted to not respond further
on this matter.

Post by Yves Dorfsman
1) ntpdate is bad and shouldn't be used

Correct.

Post by Yves Dorfsman
2) ntpd talks over UDP, and on port 123 on BOTH side

Correct.

Post by Yves Dorfsman
3) contrary to ntpdate, nptd uses two connections, one going out, one
coming in (if I close connections coming in on port 123, ntpd -gq doesn't
work) ?

Not correct. There is no such thing as a "connection" within UDP
parlance. You have incoming packets and you have outgoing packets,
and that's it. This is true for both ntpdate as well as ntpd.

Some firewalls might recognize that some incoming packets appear to
be a response to earlier outgoing packets, but that's just a
convenience.

Post by Yves Dorfsman
4) the "restrict" command in ntp.conf is very powerfull (read dangerous),
widely misunderstood, badly documented, and affects ntpd not only as a
server, but as a client as well. Therefore, and contrary to what is
written in the comments of ntp.conf, "restrict default ignore" prevents
anybody from accessing your ntpd server, but ALSO prevents ntpd to
function as a client unless you add a restrict command for the server(s)
you are going to talk to.

Correct. Among other things, the "restrict" command only works by IP
address and not host/damain name, so if you don't know in advance
what the specific IP address is for a given upstream server, then you
can't list that IP address as one that you should actually listen to.

Post by Yves Dorfsman
5) you should really use *.pool.ntp.org rather than specific servers from
th internet

Not correct. The *.pool.ntp.org servers should be used to fill out
your list of time servers, which you first populate from other
sources. Your first source should be your network provider. Your
second source should be their upstream network provider. Your third
source can be from other appropriate servers that are topologically
close to you, which you may hear about in a variety of ways.

If you still don't have enough servers, you can fill in from the
lists at
<http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers>,
<http://support.ntp.org/bin/view/Servers/StratumOneTimeServers>, and
the *.pool.ntp.org servers, but make sure that you read, understand,
and agree to operate by all the appropriate "Rules of Engagement"
before you do so.

See also <http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers>.

Post by Yves Dorfsman
6) because of 2), 3) 4) and 5), you cannot use ntpd to sync your machine
from the internet, without allowing other machines from the internet to
use you a time server.

Also not correct. With the Reference Implementation of ntpd as
supported by the NTP Public Services Project at www.ntp.org, there is
one program that is as a persistent background daemon, and it acts as
both NTP client as well as NTP server. However, with careful use of
the "restrict" command you can set up your time servers so that they
only serve time to local clients, although that does require that you
explicitly allow packets to come through from your configured
upstream servers.

In other words, if you do want to configure your time server(s) to
serve time only to local clients, then you can't configure your time
server(s) to use upstream time servers where you do not know in
advance what their IP address is. So, you could not use any of the
*.pool.ntp.org servers, and you probably could not use any of the
other time servers listed under
<http://support.ntp.org/bin/view/Servers/>.


This is easily enough solved at your firewall/NAT box. Just don't
automatically forward all incoming UDP/123 connections to your
back-end time server(s). Most firewalls (even the most basic ones)
do have a concept of an "established connection" even when applied to
UDP communications, and you should make use of this feature. You
could allow all UDP port 123 traffic out, and you could allow
incoming UDP port 123 traffic through the firewall, if it was part of
an "established connection", i.e., a response to an outgoing packet
that was recently seen.

By default, most firewall/NAT boxes should automatically "Do The
Right Thing", and you shouldn't have to worry about anything else.

Post by Yves Dorfsman
7) if you use "restrict default kod nomodify notrap nopeer noquery"
you're limiting the type of DoS attacks that can be done against you on
port 123, but some are still possible ???

Sure. Attacks are always possible. Remote clients or servers could
always ignore the KOD packet, and they could flood you with traffic.
Just ask Dave Plonka at UWisc (see
<http://pages.cs.wisc.edu/~plonka/netgear-sntp/>), and the list of
incidents at
<http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse>.

[Derek J. Balling]

Post by Brad Knowles

Post by Yves Dorfsman
1) ntpdate is bad and shouldn't be used

Correct.

Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or something
like that to keep your clock in sync".

Because I've got ntpdate in the startup scripts of nearly every box I
manage right before they start ntp (in case the onboard clock is off
by more than ntp is willing to slew in a single move).

Cheers,
D

[Theo Van Dinter]

Post by Derek J. Balling

Post by Brad Knowles

Post by Yves Dorfsman
1) ntpdate is bad and shouldn't be used

Correct.

Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or something
like that to keep your clock in sync".

There are also situations where this is necessary, such as when the clock skew
is so much that ntpd gives up. (I see this a lot w/ VMWare instances.)

[Brandon S. Allbery KF8NH]

Post by Theo Van Dinter

Post by Derek J. Balling
Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something
like that to keep your clock in sync".

There are also situations where this is necessary, such as when the clock skew
is so much that ntpd gives up. (I see this a lot w/ VMWare
instances.)

And crappy low-end Dell hardware (which we get a lot of, for free.
sometimes free is annoyingly expensive...).

[Derek J. Balling]

Post by Theo Van Dinter
There are also situations where this is necessary, such as when the clock skew
is so much that ntpd gives up. (I see this a lot w/ VMWare
instances.)

Well, in fairness, VMWare does say, in all the docs, not to use NTP
inside of a VM, because of some conflict between :
(a) the way the tools try to keep the clock in sync
(b) the way Linux tries to keep its clock "accurate"
(c) the way NTP will adjust the clock to keep it in sync

The "official" answer on guest OSes is to use the tools to keep the
clock in sync and nothing else, but your mileage may vary...

Cheers,
D

[Yves Dorfsman]

Well, in fairness, VMWare does say, in all the docs, not to use NTP inside of
(a) the way the tools try to keep the clock in sync
(b) the way Linux tries to keep its clock "accurate"
(c) the way NTP will adjust the clock to keep it in sync
The "official" answer on guest OSes is to use the tools to keep the clock in
sync and nothing else, but your mileage may vary...

What are the tools ?

We've been through this scenario:
-ntpd couldn't keep up, had to run ntpdate every 3 minutes
-VMWare (EMC I guess) said, yes we know we have an issue on VMs with more
than one (virtual) processor, please loose one processor
-We need/want two processors, so not an option
-VMWare said don't run NTP, trust the (virtual) hardware clock
-still didn't work
-VMWare finally came up with a patch
-Worked for a few hours, but then drifted enough to break kerberos

We're now running "ntpd -gq" via cron eveyr hour, and that seems enough to
keep kerberos happy. Looking at the log, the delta is always under a
second, but greater than 128 ms, so ntpd makes a skip. I don't like doing
skip except on startup, in case the skip goes backwards and it is now
confusing for some apps. I've been wanting to try "ntpd -xq", so it will
skew the clock all the time, but I'm just not sure there is enough time
inside an hour to skew the clock enough to take it where it should be.

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[Derek J. Balling]

Post by Yves Dorfsman
What are the tools ?

VMWare guest tools. They run inside the guest OS and talk to the
outside world. Essentially they "know" they're in a VM and can make
necessary tweaks. They make things like VMotion a whole lot easier,
can handle memory management easier, and can do things like keeping
the clock in step.

Post by Yves Dorfsman
-VMWare (EMC I guess) said, yes we know we have an issue on VMs with more
than one (virtual) processor, please loose one processor

You don't want a 2-cpu virtual anyway, unless you've got a lot of CPUs
in the physical host. When last I went round and round with VMWare on
this, an SMP virtual won't get clock cycles unless - by coincedence -
there are two simultaneous chips available to dedicate to it at the
same time. The odds of this happening are reduced as other VMs compete
for CPU resources. VMware doesn't (or didn't) handle this situation
well and know to "grab two before someone else did", and dual-CPU VMs
would actually have *worse* performance than single-CPU VMs. No joke.

Post by Yves Dorfsman
-VMWare said don't run NTP, trust the (virtual) hardware clock
-still didn't work
-VMWare finally came up with a patch
-Worked for a few hours, but then drifted enough to break kerberos

You should use the VMWare guest tools. If you're running Linux,
there's some kernel options to feed into the kernel at boot-time via
(lilo,grub)[rand]. VMWare shouldn't have a hard time locating these
settings for you, they were #2 on the FAQ list on the support site
when I was looking at it this morning. :-)

Cheers,
D

[Brad Knowles]

Post by Theo Van Dinter
There are also situations where this is necessary, such as when the clock skew
is so much that ntpd gives up. (I see this a lot w/ VMWare instances.)

For one thing, you could start ntpd with a -g option, so that it will
go ahead and make those changes anyway, regardless of the size of the
jump.

For another thing, you shouldn't be trying to run ntpd under VMWare
-- see
<http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.1.>.

[Brandon S. Allbery KF8NH]

Post by Derek J. Balling

Post by Brad Knowles

Post by Yves Dorfsman
1) ntpdate is bad and shouldn't be used

Correct.

Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something like that to keep your clock in sync".
Because I've got ntpdate in the startup scripts of nearly every box
I manage right before they start ntp (in case the onboard clock is
off by more than ntp is willing to slew in a single move).

Theoretically you're supposed to use iburst on your peer definitions
instead. I'm still seeing situations where an ntpdate -b at boot
works better, though, and think this whole changeover has not been
thought through fully.

[Doug Hughes]

Post by Brandon S. Allbery KF8NH

Post by Derek J. Balling

Post by Brad Knowles

Post by Yves Dorfsman
1) ntpdate is bad and shouldn't be used

Correct.

Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something like that to keep your clock in sync".
Because I've got ntpdate in the startup scripts of nearly every box
I manage right before they start ntp (in case the onboard clock is
off by more than ntp is willing to slew in a single move).

Theoretically you're supposed to use iburst on your peer definitions
instead. I'm still seeing situations where an ntpdate -b at boot
works better, though, and think this whole changeover has not been
thought through fully.

iburst is part of the picture. It allows your initial synchronization on
startup with something else to be much quicker than the normal 5 minute
exchange cycle. -b is for synchronizing to broadcast servers. Neither of
these is suited to solve the 'large difference' thing though. For that,
you need the (newish) -g flag:

-g, --panicgate
Allow the first adjustment to be Big.

Normally, ntpd exits with a message to the system log
if the
offset exceeds the panic threshold, which is 1000 s by
default.
This option allows the time to be set to any value
without
restriction; however, this can happen only once. If the
thresh-
old is exceeded after that, ntpd will exit with a
message to
the system log. This option can be used with the -q
and -x
options. See the tinker configuration file directive for
other
options.

so, ntpd -g is roughly equivalent to ntpdate followed by ntpd..

I agree with your assessment though. ntpdate is a wholly reasonable
utility and getting rid of it seems of dubious value. If one were to
continue to use it until it is finally and forceably removed, no
resulting calamity of evil would befall you. (in the end, it may all end
up failing like the attempt to remove nslookup)

[Brandon S. Allbery KF8NH]

Post by Doug Hughes

Post by Brandon S. Allbery KF8NH
Theoretically you're supposed to use iburst on your peer
definitions instead. I'm still seeing situations where an
ntpdate -b at boot works better, though, and think this whole
changeover has not been thought through fully.

iburst is part of the picture. It allows your initial
synchronization on startup with something else to be much quicker
than the normal 5 minute exchange cycle. -b is for synchronizing to
broadcast servers.

buh? ntpdate -b ("boot") makes ntpdate force the clock instead of
trying to slew it (and failing if the offset is too large).

I admit I'd thought ntpd -g did something different related to iburst
mode, though; if it enables ntpd to do the equivalent of ntpdate -b
and stomp the clock immediately instead of trying to slew it, then it
might be a reasonable replacement for most uses of ntpdate.

That still leaves the problem of machines whose hwclocks are so
messed up that you need to forcibly ntpdate -b them periodically
(e.g. the aforementioned Dells)... but then, you need to shut down
ntpd when you ntpdate -b them anyway, so I suppose ntpd -g would work
there too.

[Brad Knowles]

Post by Brandon S. Allbery KF8NH
buh? ntpdate -b ("boot") makes ntpdate force the clock instead of
trying to slew it (and failing if the offset is too large).

Check the Official Documentation at
<http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html>. The
command-line options have changed over time.

Post by Brandon S. Allbery KF8NH
I admit I'd thought ntpd -g did something different related to iburst
mode, though; if it enables ntpd to do the equivalent of ntpdate -b
and stomp the clock immediately instead of trying to slew it, then it
might be a reasonable replacement for most uses of ntpdate.

If you really want a single command you can run that will update the
clock and then quit, you could always use "ntpd -gqx". The "-q"
option will cause ntpd to exit after it gets the initial sync. The
"-x" option will allow ntpd to step the clock instead of skewing it.
The "-g" option allows that initial step to be much larger than would
otherwise be accepted.

This will be the functional equivalent of ntpdate, but done in a much
more sane (and secure) manner, and avoiding all the really ugly nasty
horrible code inside of ntpdate that no one has wanted to touch or
even look at for over ten or fifteen years.

[Yves Dorfsman]

Post by Brad Knowles
If you really want a single command you can run that will update the
clock and then quit, you could always use "ntpd -gqx". The "-q"
option will cause ntpd to exit after it gets the initial sync. The
"-x" option will allow ntpd to step the clock instead of skewing it.
The "-g" option allows that initial step to be much larger than would
otherwise be accepted.

You mean -x allows ntpd to skew the clock for delta bigger than normally
allowed, right ?

What does -gx do ?
An initial jump, and then skew rather than give up ?

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[Ted Cabeen]

Post by Yves Dorfsman

Post by Brad Knowles
If you really want a single command you can run that will update the
clock and then quit, you could always use "ntpd -gqx". The "-q"
option will cause ntpd to exit after it gets the initial sync. The
"-x" option will allow ntpd to step the clock instead of skewing it.
The "-g" option allows that initial step to be much larger than would
otherwise be accepted.

You mean -x allows ntpd to skew the clock for delta bigger than normally
allowed, right ?
What does -gx do ?
An initial jump, and then skew rather than give up ?

Actually, from reading the man page, you don't want -x, as it prevents
time stepping, rather than forcing it. What you want (which Brad posted
earlier) is -gnq, which is -g (allow large changes >1000s) -n (do not
background) and -q (quit after initial run).

One difference between ntpd and ntpdate is that ntpd is much much faster
than ntpd. ntpd -gnq takes about 9 seconds to run on my ubuntu box.
Now that's not too long, and is probably how long it takes to send the
necessary queries to get a good time sync, however it is a difference in
behavior for people used to a quick interactive sync with ntpdate.

Finally, ntpdate doesn't require as much configuration as ntpd does.
ntpd doesn't allow you to specify time servers on the command line.
Instead they have to be configured in your ntpd.conf. Now with modern
packaging systems, that's not a big deal, but it is a difference. Also,
you can't query a specific timeserver with ntpd. I use ntpdate -q to
check my time against other servers sometimes. I know the quality of
such a sync is bad, but sometimes it just doesn't matter.

--Ted

[Brad Knowles]

Post by Ted Cabeen
Actually, from reading the man page, you don't want -x, as it prevents
time stepping, rather than forcing it. What you want (which Brad posted
earlier) is -gnq, which is -g (allow large changes >1000s) -n (do not
background) and -q (quit after initial run).

I looked at the Official Documentation at
<http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html>, and realized
that my previous response was in error.

You are correct. In this instance, you want "-gnq".

Post by Ted Cabeen
Also,
you can't query a specific timeserver with ntpd.

No, for that you use "ntpq", or "ntpdc", depending on what
information you want and what version of the software is running on
the remote end (and therefore what query protocol version it
supports). If you want mode 6 answers, go with ntpq. If you want
mode 7, then ntpdc.

At least, I think that's the way the mode versions break down. To be
sure, you'd have to ask Harlan or someone who knows the code better
than I do.


The last time the Official Documentation for ntpdate was changed (see
<http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html>) was 8:44
UTC Thursday, July 28, 2005, according to the web page. At the top,
it says:

Disclaimer: The functionality of this program is now available
in the ntpd program. See the -q command line option in the
ntpd - Network Time Protocol (NTP) daemon page. After a suitable
period of mourning, the ntpdate program is to be retired from
this distribution


It shouldn't be too much longer now.

[Brad Knowles]

Post by Yves Dorfsman
You mean -x allows ntpd to skew the clock for delta bigger than normally
allowed, right ?
What does -gx do ?
An initial jump, and then skew rather than give up ?

Quoting from the Official Documentation at
<http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html>:

-g Normally, ntpd exits with a message to the system log
if the offset exceeds the panic threshold, which is
1000s by default. This option allows the time to be
set to any value without restriction; however, this
can happen only once. If the threshold is exceeded
after that, ntpd will exit with a message to the
system log. This option can be used with the -q and
-x options. See the tinker command for other options.

-q Exit the ntpd just after the first time the clock is
set. This behavior mimics that of the ntpdate program,
which is to be retired. The -g and -x options can be
used with this option. Note: The kernel time discipline
is disabled with this option.

-x Normally, the time is slewed if the offset is less
than the step threshold, which is 128 ms by default,
and stepped if above the threshold. This option sets
the threshold to 600s, which is well within the
accuracy window to set the clock manually. Note:
Since the slew rate of typical Unix kernels is limited
to 0.5 ms/s, each second of adjustment requires an
amortization interval of 2000s. Thus, an adjustment
as much as 600s will take almost 14 days to complete.
This option can be used with the -g and -q options.
See the tinker command for other options. Note: The
kernel time discipline is disabled with this option.

[Jo Rhett]

Post by Brad Knowles
If you really want a single command you can run that will update the
clock and then quit, you could always use "ntpd -gqx". The "-q"

...

Post by Brad Knowles
This will be the functional equivalent of ntpdate, but done in a much
more sane (and secure) manner, and avoiding all the really ugly nasty

Command and configuration file. Last time I tested it, this command
would fail if the ntp.conf didn't exist - even if you supplied the
server name on the command line.

So, no, sorry, it's much easier to add a line crontab line that works
than it is to distribute ntp.conf files as well.

[Brad Knowles]

Post by Doug Hughes
iburst is part of the picture. It allows your initial synchronization on
startup with something else to be much quicker than the normal 5 minute
exchange cycle.

Actually, without iburst and without a "drift file", it can take up
to 24 hours (or more) to get a good initial sync. With iburst but no
drift file, it can take up to a couple of hours before you get a good
initial sync. With iburst and a drift file, I can usually get a good
initial sync in less than fifteen seconds.

And that's with a conservative configuration file that makes the
system work harder to gather more data before it makes a final
determination with regards to the initial sync.

Post by Doug Hughes
I agree with your assessment though. ntpdate is a wholly reasonable
utility and getting rid of it seems of dubious value. If one were to
continue to use it until it is finally and forceably removed, no
resulting calamity of evil would befall you. (in the end, it may all end
up failing like the attempt to remove nslookup)

The whole concept of ntpdate is fundamentally flawed. You really,
really don't want large discontinuous jumps in your system clock.
With regards to security, accounting, monitoring, and many other
factors, that's just about one of the worst low-level things you
could do to the system.

The whole algorithm of ntpdate is fundamentally flawed. It sends out
a UDP packet, it gets back a UDP packet, it sets the clock. Period.
End of story. There's no attempt to check to see if the response is
anywhere remotely close to "sane" (by comparing that response with
responses from a selection of other servers), there's no attempt to
see if the response came from a server that has been
cryptographically authenticated to the client, there's no attempt at
anything remotely resembling robustness in case the one server so
specified happens to be down, there's no attempt to gather
statistical information over even a short period of time to make sure
that you're not being unduly affected by temporary network problems,
or anything else.

The whole implementation of ntpdate is also fundamentally flawed.
The code is ancient, it hasn't been touched in many years, it doesn't
make use of any of the more recent libraries or the more recent
network code, or anything else. Even if you refuse to accept the two
above arguments for the "termination with extreme prejudice" of
ntpdate, you should accept this one.

[Derek J. Balling]

Post by Brad Knowles
For one thing, ntpdate is absolutely going away. No ifs, ands, or
buts.

Near as I can tell from the license for ntpdate that's unlikely. Even
if the original maintainers stop supporting it, my guess is that the
code is useful enough to some people that it will continue to live on.

Post by Brad Knowles
The whole concept of ntpdate is fundamentally flawed. You really,
really don't want large discontinuous jumps in your system clock.

Completely and wholeheartedly disagree. I want *accuracy* in my clock.

Is it *better* if that skew is mitigated by noticing it "sooner rather
than later"? Absolutely. But, in the end, I want my clock to be
accurate at all times. And that means that if my syslog server starts
up and is ten minutes off on its timestamps, then by god it better
change its time IMMEDIATELY to be accurate, and not "ahhhhh, I'll make
it up over time".

I want my clock to be "accurate" the instant I notice that it's not.
Anything else is just recording borked data with no frame of reference
that it's borked.

Post by Brad Knowles
With regards to security, accounting, monitoring, and many other
factors, that's just about one of the worst low-level things you
could do to the system.

Again, I cannot disagree with you more on this topic. :-)

Post by Brad Knowles
The whole algorithm of ntpdate is fundamentally flawed. It sends
out a UDP packet, it gets back a UDP packet, it sets the clock.
Period. End of story. There's no attempt to check to see if the
response is anywhere remotely close to "sane" (by comparing that
response with responses from a selection of other servers), there's
no attempt to see if the response came from a server that has been
cryptographically authenticated to the client, there's no attempt at
anything remotely resembling robustness in case the one server so
specified happens to be down, there's no attempt to gather
statistical information over even a short period of time to make
sure that you're not being unduly affected by temporary network
problems, or anything else.

Assuming I'm talking to an NTP server I trust, why do I care about any
of that?

Post by Brad Knowles
The whole implementation of ntpdate is also fundamentally flawed.
The code is ancient, it hasn't been touched in many years, it
doesn't make use of any of the more recent libraries or the more
recent network code, or anything else. Even if you refuse to accept
the two above arguments for the "termination with extreme prejudice"
of ntpdate, you should accept this one.

If it still works, why do I care?

D

[Brad Knowles]

Near as I can tell from the license for ntpdate that's unlikely. Even if
the original maintainers stop supporting it, my guess is that the code
is useful enough to some people that it will continue to live on.

It won't be part of the Reference Implementation, and if someone else
wants to take the code and continue to maintain it, I guess they'd be
free to do that. I can't imagine that anyone would want to do so,
based on what I know of the code, but there you go.

On the other hand, if you want something that completely asinine
stupid, you could write a five-line perl script that does the same
thing and operates by the same name, and at least avoids all the
issues with the code itself.

Completely and wholeheartedly disagree. I want *accuracy* in my clock.

With a single large discontinuous jump, you cannot possibly get
accuracy in your clock. Period.

Is it *better* if that skew is mitigated by noticing it "sooner rather than
later"? Absolutely. But, in the end, I want my clock to be accurate at all
times.

Then you absolutely don't want to be running ntpdate. It doesn't
make any attempt to keep your clock accurate over time. It simply
makes a single large discontinuous jump, and then it goes away. If
your clock naturally runs a little slow or a little fast, that
inaccuracy will accumulate over time, at least until you run ntpdate
again.

This is the kind of reasoning (from people who fundamentally do not
understand how the code works) is one of the main factors behind the
drive to kill ntpdate with extreme prejudice.

And that means that if my syslog server starts up and is ten
minutes off on its timestamps, then by god it better change its time
IMMEDIATELY to be accurate, and not "ahhhhh, I'll make it up over time".

So just start up ntpd with a -g option and be done with it.

Again, I cannot disagree with you more on this topic. :-)

You clearly don't understand how the code works or how the algorithms
work, so it's not clear to me how you can possibly have any basis for
disagreeing with me.

Assuming I'm talking to an NTP server I trust, why do I care about any
of that?

Right. See above.

If it still works, why do I care?

How can you be sure it's working?

[Derek J. Balling]

Seriously, Brad, you're a really smart guy, and at LISA I plan to find
you and give you a copy of a certain Dale Carnegie book.

Post by Brad Knowles
On the other hand, if you want something that completely asinine
stupid, you could write a five-line perl script that does the same
thing and operates by the same name, and at least avoids all the
issues with the code itself.

Some times you want to sync the clock "at start" and never again
(e.g., in an environment like say, VMware, where there's other
mechanisms at work to handle clock slew). You seem to live in this
vacuum where "if Brad doesn't have to deal with that situation, nobody
does."

"There are more things in Heaven and Earth..."

Post by Brad Knowles
With a single large discontinuous jump, you cannot possibly get
accuracy in your clock. Period.

The current "real" time is 5:00:00.00.
My clock says it is "2:30:00.00".

Is my clock accurate? Nope.

If I make a single large discontinuous jump to 5:00:00.00 is it now
accurate? Yep.

Will it *stay* accurate? Who knows. That's a different matter
entirely, and *not* a question ntpdate attempts to answer.

Post by Brad Knowles
Then you absolutely don't want to be running ntpdate. It doesn't
make any attempt to keep your clock accurate over time.

And I never claimed it did. In fact, I explicitly agreed with you on

Post by Brad Knowles

Post by Derek J. Balling
Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something like that to keep your clock in sync".

It would be accurate to say "don't use ntpdate in your cron job",
that's silly. But to say that ntpdate has no useful purpose is simply
not true.

Post by Brad Knowles
This is the kind of reasoning (from people who fundamentally do not
understand how the code works) is one of the main factors behind the
drive to kill ntpdate with extreme prejudice.

This is the kind of rushed judgement, including misinterpretation
(willful or accidental) of what people are saying, that can cause
people to not listen to portions of what you say that make a lot of
sense. :-)

Post by Brad Knowles
So just start up ntpd with a -g option and be done with it.

That's not always been an option.

Post by Brad Knowles

Post by Derek J. Balling
Again, I cannot disagree with you more on this topic. :-)

You clearly don't understand how the code works or how the
algorithms work, so it's not clear to me how you can possibly have
any basis for disagreeing with me.

No, actually, I don't need to know anything about the algorithms or
the code to disagree with you and state unequivocally that "sometimes
a large single discontinuous jump is better than a lot of little
steps". That's simply a matter of "how does a person want their clock
to be brought into sync". Now there may be easier ways to do it using
the new ntp code to (essentially) simulate the functionality of a
deprecated ntpdate (e.g., by taking a single god-only-knows-how-large
step at initial start time), but you've made an assertion that this
single large step is "bad" and that's simply not true for a lot of
purposes.

Cheers,
D

[Richard Chycoski]

For VMware, you still need ntp (or equivalent) for the host OS, and
there are solutions for the 'guests' to keep in sync with the host. The
synchronisation of the guests isn't perfect, but typically stays within
seconds rather than minutes, which keeps Kerberos happy even if 'make'
has the occasional hiccup due to small skews. (Using distcc rather than
sharing filesystems via NFS can eliminate these skews for big builds.)

I do use ntpdate to set the initial clock on my VMware hosts, then start
up the ntp daemon to keep the host clock in sync. The guests just follow
along. They don't see the initial time skew on the host because it
happens before I start up VMware.

For non-virtual hosts, I still use ntpdate to set the time initally,
then use ntp to keep it there.

It doesn't have to be ntpdate *or* ntp. Using both can be useful. For
cases where ntp gets upset (it doesn't like clocks that get into the
future), a belt-and-suspenders approach might be to run an occasional
job to check the time skew and use ntpdate to force it if things get too
far off, but I haven't had to resort to this yet (so I haven't written
one :-).

I do recommend against just running ntpdate to reset the clock. Any
processes that are time dependent can get upset at the missing/added
clock cycles, ntp's 'kindler,gentler' method of skewing the clock is
much less intrusive. That shouldn't stop you from using ntpdate at
system startup however, if you keep the event out of the way of any
other time-sensitive initialisation that may be going on.

- Richard

Post by Derek J. Balling
Seriously, Brad, you're a really smart guy, and at LISA I plan to find
you and give you a copy of a certain Dale Carnegie book.

Post by Brad Knowles
On the other hand, if you want something that completely asinine
stupid, you could write a five-line perl script that does the same
thing and operates by the same name, and at least avoids all the
issues with the code itself.

Some times you want to sync the clock "at start" and never again
(e.g., in an environment like say, VMware, where there's other
mechanisms at work to handle clock slew). You seem to live in this
vacuum where "if Brad doesn't have to deal with that situation, nobody
does."
"There are more things in Heaven and Earth..."

Post by Brad Knowles
With a single large discontinuous jump, you cannot possibly get
accuracy in your clock. Period.

The current "real" time is 5:00:00.00.
My clock says it is "2:30:00.00".
Is my clock accurate? Nope.
If I make a single large discontinuous jump to 5:00:00.00 is it now
accurate? Yep.
Will it *stay* accurate? Who knows. That's a different matter
entirely, and *not* a question ntpdate attempts to answer.

Post by Brad Knowles
Then you absolutely don't want to be running ntpdate. It doesn't
make any attempt to keep your clock accurate over time.

And I never claimed it did. In fact, I explicitly agreed with you on

Post by Brad Knowles

Post by Derek J. Balling
Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something like that to keep your clock in sync".

It would be accurate to say "don't use ntpdate in your cron job",
that's silly. But to say that ntpdate has no useful purpose is simply
not true.

Post by Brad Knowles
This is the kind of reasoning (from people who fundamentally do not
understand how the code works) is one of the main factors behind the
drive to kill ntpdate with extreme prejudice.

This is the kind of rushed judgement, including misinterpretation
(willful or accidental) of what people are saying, that can cause
people to not listen to portions of what you say that make a lot of
sense. :-)

Post by Brad Knowles
So just start up ntpd with a -g option and be done with it.

That's not always been an option.

Post by Brad Knowles

Post by Derek J. Balling
Again, I cannot disagree with you more on this topic. :-)

You clearly don't understand how the code works or how the algorithms
work, so it's not clear to me how you can possibly have any basis for
disagreeing with me.

No, actually, I don't need to know anything about the algorithms or
the code to disagree with you and state unequivocally that "sometimes
a large single discontinuous jump is better than a lot of little
steps". That's simply a matter of "how does a person want their clock
to be brought into sync". Now there may be easier ways to do it using
the new ntp code to (essentially) simulate the functionality of a
deprecated ntpdate (e.g., by taking a single god-only-knows-how-large
step at initial start time), but you've made an assertion that this
single large step is "bad" and that's simply not true for a lot of
purposes.
Cheers,
D
------------------------------------------------------------------------
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Brad Knowles]

Some times you want to sync the clock "at start" and never again (e.g., in
an environment like say, VMware, where there's other mechanisms at work to
handle clock slew).

With regards to VMWare, you really should re-read that page I linked
to before. I'll post the URL again:
<http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.1.>.

The current "real" time is 5:00:00.00.

By what standard?

My clock says it is "2:30:00.00".
Is my clock accurate? Nope.
If I make a single large discontinuous jump to 5:00:00.00 is it now
accurate? Yep.

No, because by the time you make that change, the reference you're
comparing again will have moved on.

It's a moving target, and you have to know that and calculate how
much latency there is in the process of your asking it what time it
is and it telling you what time it was (as of the time it processed
your request), and how long it takes you to process the reply, before
you can then estimate what value you should plug in for setting the
time.

Before you can make that jump with any kind of accuracy, you need to
take sufficient statistical measurements of the situation to have
some idea of what the various factors are in the process. And you
need to know what those processes are that need to be measured.


And that's just one small part of the overall picture.

There's also security -- since UDP is trivially easy to spoof, how
can you be sure that the response you got really was from the clock
it says it was?

And there are many other factors, too.

Will it *stay* accurate? Who knows. That's a different matter entirely,
and *not* a question ntpdate attempts to answer.

Before you start getting pedantic on me, you should understand the
terms you're arguing about. See the "NTP-related definitions" page
at <http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions>.

It would be accurate to say "don't use ntpdate in your cron job",
that's silly. But to say that ntpdate has no useful purpose is simply
not true.

If you want to use rdate, then use rdate. But ntpdate has no valid use.

At least with rdate you won't be making any claims to using a valid
timekeeping protocol like NTP.

This is the kind of rushed judgement, including misinterpretation (willful
or accidental) of what people are saying, that can cause people to not
listen to portions of what you say that make a lot of sense. :-)

Dr. Mills and Harlan Stenn have been trying to kill ntpdate for many
years now. They are the ones with their hands in the code, and with
a single rm command from either of them, ntpdate is gone. I believe
that they are closer to being able to kill ntpdate now than ever
before, and that ntpdate will be dying a horrible and very complete
death in the very near future.

For those who don't know those names, Dr. David Mills created NTP
many years ago, and has been "Dr. NTP" ever since. He is also the
owner of the ntp.org domain, with DNS managed by UDel.edu, and web &
mail services provided by the NTP Public Services project. Harlan
Stenn has been the Release Engineer for the Reference Implementation
for many years, and the guy who is primarily responsible for pulling
together all the code contributions from all the various authors of
the different components, including all of the changes from Dr. Mills
throughout the system.

However, if you don't believe me, you're always welcome to go ask them.

No, actually, I don't need to know anything about the algorithms or the
code to disagree with you and state unequivocally that "sometimes a
large single discontinuous jump is better than a lot of little steps".

That's a completely different statement from holding onto the
existing ntpdate code with a deathgrip.


If you have a situation where you require a single large
discontinuous jump, you can get that with ntpd. That doesn't require
you to force us to continue to provide the current ntpdate code ad
infinitum.

Of course, if you're going to continue to want large discontinous
jumps, then you really should be using a different protocol -- say,
rdate.

That's simply a matter of "how does a person want their clock to be
brought into sync". Now there may be easier ways to do it using the new
ntp code to (essentially) simulate the functionality of a deprecated
ntpdate (e.g., by taking a single god-only-knows-how-large step at
initial start time), but you've made an assertion that this single large
step is "bad" and that's simply not true for a lot of purposes.

For NTP, just about the single biggest crime that can be committed is
to step the clock instead of slewing, and virtually everything that
can possibly be done to avoid stepping will be done.

If that is antithetical to the way you want to run your systems, then
you most definitely should not be running NTP at all.

[Derek J. Balling]

Post by Brad Knowles
If you want to use rdate, then use rdate. But ntpdate has no valid use.

(*sigh*)

Plonk.

[Richard Chycoski]

Derek, I agree.

Until a viable alternative to ntpdate comes along (and ntp -gnq or other
alphabet soup is not it), we do need ntpdate.

Required action: Set the system clock, right now, to a known, good
reference. I don't want to wait 14 days (or even 14 minutes) for a badly
skewed clock to get back in sync - it must happen *right now*. If this
is done at a safe time, in known conditions during booting up, slewing
the clock over time is not necessary - and is, in fact, detrimental to
system operation.

Once this is done, ntpd can happily take over keeping the clock in sync.

Brad - telling us that we're wanting the wrong thing is ignoring the
real world. Sometimes you just need to set the d*** clock. Now. Period.
If ntp is not willing to do this, then it is not sufficient to keep
pointing to it as *the* answer. Come up with a solution using ntp (or
other utility), and ntpdate can be happily retired. I've yet to see you,
or anyone else, suggest a *viable* alternative solution to this problem
(and don't tell us that we're trying to solve the wrong problem!).

This is why you see ntpdate used on many systems in boot scripts, and
will continue to do so for the foreseeable future - the ntp folk have
not produced a truly viable alternative, no matter how much they tell us
that they have.

- Richard

Post by Derek J. Balling

Post by Brad Knowles
If you want to use rdate, then use rdate. But ntpdate has no valid use.

(*sigh*)
Plonk.
------------------------------------------------------------------------
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Yves Dorfsman]

Post by Richard Chycoski
Derek, I agree.
Until a viable alternative to ntpdate comes along (and ntp -gnq or other
alphabet soup is not it), we do need ntpdate.

I don't agree with evrything Brad is saying here, but, "ntpd -gq" takes
less than a minute, we're talking somewhere between 5 and 15 seconds (my
experience, not sure what is the real window). Isn't that good enough ?

As I said it has the advantage of hilighting bad ntp.conf. Since I've
started to look into this, and talk to people about it, a few people
realised that their ntpd was not doing anything because badly configured.
ntpd -gq will tell you what's it's doing, if not, it means it's not doing
anything (the bad thing is that it returns 0 even in that case).

Post by Richard Chycoski
Required action: Set the system clock, right now, to a known, good
reference. I don't want to wait 14 days (or even 14 minutes) for a badly
skewed clock to get back in sync - it must happen *right now*. If this

What about 14 seconds ?

[Derek J. Balling]

Post by Yves Dorfsman
I don't agree with evrything Brad is saying here, but, "ntpd -gq" takes
less than a minute, we're talking somewhere between 5 and 15 seconds (my
experience, not sure what is the real window). Isn't that good
enough ?

For my purposes, yeah. It's fine. Even if it is an evil single large
incongruous step. :-)

Cheers,
D

[Brad Knowles]

Post by Richard Chycoski
Until a viable alternative to ntpdate comes along (and ntp -gnq or
other alphabet soup is not it), we do need ntpdate.

Why isn't ntpd a viable alternative?

Have you actually looked into all the various options available to
you with ntpd? Hint: if you can't correctly explain what all the
various different options to the "tinker" command do, then you have
not actually explored all the options available to you.

Until you've actually explored all the options that are available to
you, everything else is just a knee-jerk reaction out of ignorance
and fear.

Post by Richard Chycoski
Required action: Set the system clock, right now, to a known, good reference.

What is a "known good reference"? How can I prove that?

What is "right now"?

Post by Richard Chycoski
Once this is done, ntpd can happily take over keeping the clock in sync.

See above. Once you have actually fully explored all the options
available to you, it will become obvious that ntpd really can
completely and totally fulfill both roles.


You are being told these things by people who wrote the code, who
created the algorithms, who wrote the RFCs. There is no one on the
planet who understands these topics better than they do. They really
do know what ntpdate does and how it does it (and the full panoply of
really horribly heinous things it does), and they really do know what
ntpd does and how it does it.

I'm just relaying to you what I've been told by the people who are
hip deep in the code, algorithms, and RFCs.

If you don't like the message you are receiving, then perhaps you'd
better go talk to those people yourself. Maybe they'd say the exact
same thing in a slightly different way that you would find much more
palatable.


And *THIS* is why I really, really want to direct all further
conversation on this topic over to ***@ntp.org, because I know
I am a really bad first-level tech support guy, and I am very clearly
not getting my message through to you.

You're wasting your time and mine by continuing this diatribe on this
list, and you're just continuing to make us both madder and madder
because obviously neither of us is able to communicate with the other
person in a way that they can understand. And you're fueling the
fire of hatred of everyone else on this thread.


So can we *PLEASE* take this conversation over to another mailing
list where there are literally dozens or even hundreds of other
people who can explain this situation to you, in a way that is
obviously better than I am able to do?

Post by Richard Chycoski
This is why you see ntpdate used on many systems in boot scripts, and
will continue to do so for the foreseeable future - the ntp folk have
not produced a truly viable alternative, no matter how much they tell
us that they have.

Yes, we have. Actually, we did it a couple of years ago.

However, for reasons I cannot begin to comprehend, you seem to be
completely unwilling (or unable) to accept that fact.

[Brad Knowles]

Post by Derek J. Balling
Plonk.

When presented with facts that you don't like, you certainly do have
the option of burying your head in the sand. It's not a particularly
productive option, but it does exist.

If that's what you want to do, there's not anything I can do to stop
you, nor would I try. But I'm certainly not going to bend the facts
to try to make them more pleasing to you.

[Brandon S. Allbery KF8NH]

Post by Derek J. Balling

Post by Brad Knowles
The whole concept of ntpdate is fundamentally flawed. You really,
really don't want large discontinuous jumps in your system clock.

Completely and wholeheartedly disagree. I want *accuracy* in my clock.
Is it *better* if that skew is mitigated by noticing it "sooner
rather than later"? Absolutely. But, in the end, I want my clock to
be accurate at all times. And that means that if my syslog server
starts up and is ten minutes off on its timestamps, then by god it
better change its time IMMEDIATELY to be accurate, and not "ahhhhh,
I'll make it up over time".

And even more so when Kerberos auth has just broken because the clock
drifted more than 5 minutes out of sync despite ntpd running: I need
to kick it back into sync *immediately*, not at some indefinite point
in the future (if at all, given that ntpd failed to keep it from
happening in the first place!).

[Brad Knowles]

Post by Brandon S. Allbery KF8NH
And even more so when Kerberos auth has just broken because the clock
drifted more than 5 minutes out of sync despite ntpd running: I need
to kick it back into sync *immediately*, not at some indefinite point
in the future (if at all, given that ntpd failed to keep it from
happening in the first place!).

You can get that with ntpd, today. Nothing you've said requires that
we keep the ancient crusty dreckage and bletchery known as "ntpdate".

[Michael T. Halligan]

Post by Brad Knowles

Post by Brandon S. Allbery KF8NH
And even more so when Kerberos auth has just broken because the clock
drifted more than 5 minutes out of sync despite ntpd running: I need
to kick it back into sync *immediately*, not at some indefinite point
in the future (if at all, given that ntpd failed to keep it from
happening in the first place!).

You can get that with ntpd, today. Nothing you've said requires that
we keep the ancient crusty dreckage and bletchery known as "ntpdate".

Watch that scene in Wayne's World: "We Fear Change". I'm willing to
bet 99.999% of the users of ntpdate will
be blindsided if it disappears one day in their next OS release.
They'll gripe about their OS vendor. Their OS
vendor will issue it in a service pack, and the credibility of NTP
will be shot due to the extra amount of work
they caused by living in their bubble on their little elitist island.

[Brad Knowles]

Post by Michael T. Halligan
They'll gripe about their OS vendor. Their OS
vendor will issue it in a service pack, and the credibility of NTP
will be shot due to the extra amount of work
they caused by living in their bubble on their little elitist island.

If that's what it takes to finally and permanently slay this beast,
then I personally think that would be a small price to pay. At least
we would have forced them to wake up and actually pay attention to
something for once.


We've been around for over twenty years. We'll be here for many
years to come. In another twenty years, no one will remember this
argument. Hell, in another twenty weeks I doubt that anyone will
remember this argument.

But the heinous beast known as ntpdate must die.

[Brad Knowles]

Post by Derek J. Balling
Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or something
like that to keep your clock in sync".

For one thing, ntpdate is absolutely going away. No ifs, ands, or buts.

For another, it does a lot of things in a very stupid way, and you
most definitely should not be using it in a cron job to try to keep
your clock in sync.

Post by Derek J. Balling
Because I've got ntpdate in the startup scripts of nearly every box I
manage right before they start ntp (in case the onboard clock is off by
more than ntp is willing to slew in a single move).

Start ntpd with a -g option instead.

[Michael T. Halligan]

Post by Brad Knowles

Post by Derek J. Balling
Are you saying "it's bad and shouldn't be used *at all*", or simply
(more accurately) "don't keep using ntpdate in a cron job or
something
like that to keep your clock in sync".

For one thing, ntpdate is absolutely going away. No ifs, ands, or buts.

I remember being told that about ntpdate late in the last century..
Someone mentioned that
about ipv4 before I was old enough to drive.

Post by Brad Knowles
For another, it does a lot of things in a very stupid way, and you
most definitely should not be using it in a cron job to try to keep
your clock in sync.

Post by Derek J. Balling
Because I've got ntpdate in the startup scripts of nearly every box I
manage right before they start ntp (in case the onboard clock is off by
more than ntp is willing to slew in a single move).

Start ntpd with a -g option instead.
--
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[David Parter]

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

If the questions and discussion drift to where they would be more
appropriate on a technology-specific list (such as the ntp mailing list
for NTP), it is appropriate at that point to move the conversation.

--david

[Brad Knowles]

Post by David Parter

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

As a long-time member of the NTP Public Services Project, I violently
disagree. These are all basic questions that could be answered by
looking through the Official Documentation, the FAQ, the Community
Supported Documentation, or the archives of the mailing list
***@ntp.org.

There is absolutely no sense whatsoever in continuing to repeat all
this same stuff all over again in a different place.


Moreover, there are dozens (or more) people on
***@ntp.org/comp.protocols.time.ntp who know this stuff a lot
better than I do, and many more than that who know it roughly as well
as I do. Any of them could answer basic questions like these very
quickly, and you'd be much more likely to get a good response a lot
faster.


So, virtually the entire repository of all knowledge in the world
regarding NTP can be found on that mailing list/newsgroup, or in the
various bits of documentation we link to from the web pages at
ntp.org.

Remind me again why you'd want to be looking anywhere else for answers?

If the problem is that you're overwhelmed with documentation, then
let us know that, and we'll see what we can do about helping to set
up a simplified version.

[n***@museverte.net]

Hey folks,

The way I see it, asking questions along these lines in this forum is
appropriate and useful. Why do we even have a list like this list if we
should all "go to the appropriate source" in the first place? Because we
generate additional discussion and find out how other admins do things.
We learn from each other. Otherwise, we may as well do away with this list
and just go to the official site for every product we use because "they
know best" and no one else could possibly have any valid input.

This discussion has already brought to light how some people use ntpdate
and why. It's useful to me to see how someone does things and then to
hear from others (you in this case) why you think it is a good or bad
idea. These are design and implementation questions that administrators
want to hear about and this seems like a good place to have that
discussion.

That doesn't mean we should not be referring to the official documentation
and forums, but this is another good forum for these topics. Besides, I
do not want to track changes on tens or hundreds of different lists and
discussion forums in order to keep up to date on the various products and
systems that I use. Some of them, yes. The same questions that were
posted here could have been posted on the ntp lists, but perhaps this is
the preferred forum.

I find this list and others like it to be a great place to hear summaries
and to hear discussion on topics that I might not have considered, yet are
important and useful. I say keep the questions coming!
-Nate

Post by Brad Knowles

Post by David Parter

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

As a long-time member of the NTP Public Services Project, I violently
disagree. These are all basic questions that could be answered by
looking through the Official Documentation, the FAQ, the Community
Supported Documentation, or the archives of the mailing list
There is absolutely no sense whatsoever in continuing to repeat all
this same stuff all over again in a different place.
Moreover, there are dozens (or more) people on
better than I do, and many more than that who know it roughly as well
as I do. Any of them could answer basic questions like these very
quickly, and you'd be much more likely to get a good response a lot
faster.
So, virtually the entire repository of all knowledge in the world
regarding NTP can be found on that mailing list/newsgroup, or in the
various bits of documentation we link to from the web pages at
ntp.org.
Remind me again why you'd want to be looking anywhere else for answers?
If the problem is that you're overwhelmed with documentation, then
let us know that, and we'll see what we can do about helping to set
up a simplified version.

[Yves Dorfsman]

Post by n***@museverte.net
This discussion has already brought to light how some people use ntpdate
and why. It's useful to me to see how someone does things and then to

Yes, that's why I asked here, I was fairly certain I couldn't be the only
one confused on this. The problem about the documentation of "restrict"
has made me waist a few hours, in the end I had to go to the archives of
the newsgroup to find the answer (groups.google).

Add to that, that I do not want to subscribe to one more mailing list, I
don't want to follow one more newsgroup.

Finally, there's been lots of discussion here that I followed from a
distance but remembering somebody mentioning something in them saved me a
lot of time later when faced with the same issue.

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[Michael T. Halligan]

Post by Brad Knowles

Post by David Parter

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

As a long-time member of the NTP Public Services Project, I violently
disagree. These are all basic questions that could be answered by
looking through the Official Documentation, the FAQ, the Community
Supported Documentation, or the archives of the mailing list

So rather than ask a trusted group of peers, he should join Yet
Another Mailing List? Doesn't this
somewhat go against the nature of LOPSA's unofficial philosophy of
encouraging genralists?

Such Violence.

[Brad Knowles]

Post by Michael T. Halligan
So rather than ask a trusted group of peers, he should join Yet
Another Mailing List? Doesn't this
somewhat go against the nature of LOPSA's unofficial philosophy of
encouraging genralists?

There's no where else on the planet that you have the assembled
knowledge of RFC authors, algorithm experts, and systems programmers
who are literally hip-deep in the system and have been for many years.

Remind me again why there is anywhere else on the planet where you'd
actually trust anything that anyone says on this subject?

[Michael T. Halligan]

Post by Brad Knowles

Post by Michael T. Halligan
So rather than ask a trusted group of peers, he should join Yet
Another Mailing List? Doesn't this
somewhat go against the nature of LOPSA's unofficial philosophy of
encouraging genralists?

There's no where else on the planet that you have the assembled
knowledge of RFC authors, algorithm experts, and systems programmers
who are literally hip-deep in the system and have been for many years.
Remind me again why there is anywhere else on the planet where you'd
actually trust anything that anyone says on this subject?

I fear that on that mailing list, it's hundreds of RFC authors,
algorithm experts, and systems programmers with the same miserable
anti-social, anti-business, anti-everybody-but-us attitude that you
have about the subject.

Gee, did I say that out loud? My apologies.

[Brad Knowles]

Post by Michael T. Halligan
I fear that on that mailing list, it's hundreds of RFC authors,
algorithm experts, and systems programmers with the same miserable
anti-social, anti-business, anti-everybody-but-us attitude that you
have about the subject.

That's certainly possible. It's also possible that you might run
into some people who can tell you the same things I've been telling
you, but in a way that you actually understand what they're trying to
say.

But if you're unwilling or unable to give them a try, then you have
only yourself to blame.

[Michael T. Halligan]

Post by Brad Knowles

Post by Michael T. Halligan
I fear that on that mailing list, it's hundreds of RFC authors,
algorithm experts, and systems programmers with the same miserable
anti-social, anti-business, anti-everybody-but-us attitude that you
have about the subject.

That's certainly possible. It's also possible that you might run
into some people who can tell you the same things I've been telling
you, but in a way that you actually understand what they're trying
to say.
But if you're unwilling or unable to give them a try, then you have
only yourself to blame.

For the rest of time, I shall live with this shame and mystery hanging
over my head... but I won't have yet another mailing list to read. woot!

[John Stoffel]

Ok, I've kinda had enough with this ntpdate
debate/flamefest/arguement and I'm sure a bunch of others have too.
In my mind what is boils down to is this:

Brad hates the old ntpdate code and lack of precision and reliability
that the new 'ntpd -gqn'.


Most SysAdmins seem to *love* the *concept* of ntpdate, which means
set my clock NOW to something accurate, and then let me run ntp to
*keep* it syncronized.

And when they notice that clocks are out of date by more than 15
seconds, even if ntpd is slewing the time to match, they'd like the
ability to *force* the clock to jump to the correct time.

BUT! Most sysadmins couldn't care a rat's ass about the code
underlying that process. Just that it works.


It's all a matter of perspective.


Heck, I've learned something here, and that is that 'ntp -gqn' might
be a better way to get my systems up and running with a good time AND
to make sure I have a correct ntpd.conf file. But what about if I
need a system up with correct time even if the ntpd.conf file is
borked? What happens then? With ntpdate I at least new I had
reasonably correct time (within 5 seconds) so I could get in there and
fix it if I had to.

But I would still like the functionality of ntpdate which lets me, the
SysAdmin, choose to do something when *I* want it. C'mon, it's the
unix philosophy to give us enough rope to get the job done, and even
more rope to let us build a bridge across a chasm and yet still more
rope to hang ourselves. But it's *MY* choice.

See?

John

[Lamont Granquist]

Post by John Stoffel
Heck, I've learned something here, and that is that 'ntp -gqn' might
be a better way to get my systems up and running with a good time AND
to make sure I have a correct ntpd.conf file. But what about if I
need a system up with correct time even if the ntpd.conf file is
borked? What happens then? With ntpdate I at least new I had
reasonably correct time (within 5 seconds) so I could get in there and
fix it if I had to.

That issue occured to me as well, but I manage both ntpd.conf and
step-tickers with cfengine, so if one is broken, the other is probably
broken too.

[Brandon S. Allbery KF8NH]

Post by Brad Knowles
There's no where else on the planet that you have the assembled
knowledge of RFC authors, algorithm experts, and systems programmers
who are literally hip-deep in the system and have been for many years.

But have they been in the trenches for any appreciable length of
time? For 99%+ of ntpd's users, atomic clock precision is not
necessary --- and not desirable, if it comes with that kind of
attitude. Push the elitism too far and ntpd will be dropped in favor
of something that doesn't get in the way in the name of unnecessary
precision for the job (not to mention decidedly unfriendly support).

P.S. no, still more ranting won't help your argument.

[Brad Knowles]

Post by Brad Knowles
There's no where else on the planet that you have the assembled
knowledge of RFC authors, algorithm experts, and systems programmers
who are literally hip-deep in the system and have been for many years.

But have they been in the trenches for any appreciable length of time?

Many of them, yes. Of course, there's always a wide array of less
experienced types, too.

For 99%+ of ntpd's users, atomic clock precision is not necessary --- and
not desirable, if it comes with that kind of attitude. Push the elitism
too far and ntpd will be dropped in favor of something that doesn't get
in the way in the name of unnecessary precision for the job (not to
mention decidedly unfriendly support).

Those who truly need the precision will always know where to find us.

For everyone else, if we're not providing the solutions they think
they need, then maybe they really should be looking somewhere else.

[Robert N. Waybright]

Of Michael T. Halligan
So rather than ask a trusted group of peers, he should join Yet
Another Mailing List? Doesn't this
somewhat go against the nature of LOPSA's unofficial philosophy of
encouraging genralists?
Such Violence.

I agree with your assessment. I am already straining near my limit to cover
what I have now.

I am surprised that nobody has mentioned OpenNTPD from the OpenBSD crowd
(http://www.openntpd.org/). There are some interesting presentations on
from conferences (http://quigon.bsws.de/papers/21c3/mgp00040.html). The
team concentrated on security, functionality, and performance first, and the
ultimate last degree of time-keeping accuracy as a lesser priority. I think
your choice would depend on what your functional requirements drive you
toward. They are looking at timekeeping from the viewpoint that host
systems need sub-second accuracy on their time (they claim 50ms typical),
and can't afford to be compromised. OpenNTPD implements privilege
separation and all of the other security aspects one would expect of an
OpenBSD project. Beware, they don't support GPS clocks, IRIG, etc yet. If
you have to have your own stratum 1 source, you will have to use the uDel
NTP code.

I think it will be good to have competing implementations available.
Competition usually helps us get better, and do so faster than we would have
otherwise....

Neil

[Brandon S. Allbery KF8NH]

Post by Robert N. Waybright
I am surprised that nobody has mentioned OpenNTPD from the OpenBSD crowd

Lessee, the ntpd folks' attitude vs. Theo's attitude. I choose
someone who can leave the attitude at home instead.

[Brad Knowles]

Post by Robert N. Waybright
I am surprised that nobody has mentioned OpenNTPD from the OpenBSD crowd
(http://www.openntpd.org/).

This is an implementation of SNTP, not NTP. Time and time again,
they reference RFCs like 4330, 4075, 2030, and 1769.

If you want that, then they may have a good option for you. But you
should be fully aware of what it is that they're really selling.
It's not full NTPv3, and certainly not NTPv4.

Post by Robert N. Waybright
There are some interesting presentations on
from conferences (http://quigon.bsws.de/papers/21c3/mgp00040.html). The
team concentrated on security, functionality, and performance first, and the
ultimate last degree of time-keeping accuracy as a lesser priority.

Their concept of security is one that I find ... interesting, at
best. They make some interesting claims regarding security for which
they have absolutely no supporting evidence.

Post by Robert N. Waybright
Beware, they don't support GPS clocks, IRIG, etc yet. If
you have to have your own stratum 1 source, you will have to use the uDel
NTP code.

And if you have "real" NTP clients, it is a violation of the protocol
standards to point them at an SNTP server, and unless you've done
something really screwy they should refuse to sync to an SNTP server.

I don't understand the full details of how this can do horrible
things to the clocks on your clients. That's one of those things
where you really will have to talk to Harlan or Dr. Mills or one of
those other people who really do understand this subject better than
I do.

If you're going to go with OpenNTPd, then you need to implement it
across the board and don't try to mix-n-match the two different types
of programs.

Post by Robert N. Waybright
I think it will be good to have competing implementations available.
Competition usually helps us get better, and do so faster than we would have
otherwise....

You may find this difficult to believe, but I actually agree. I do
believe strongly in the concept of multiple conforming and
interoperable implementations. Unfortunately, when it comes to NTP,
there aren't any other full implementations.


I worked pretty hard to explain the differences between RFCs 2030 and
1305, and how they could not legitimately claim to be implementing
NTP when they took their entire implementation model from the wrong
RFC, and the initial authors were ... intractable ... as could be
expected for most OpenBSD projects.

Now that the original authors have declared this problem to have been
solved and have moved on to other projects, we hope that we'll be
able to build better bridges with the current maintainer.

[Benjamin Feen]

Post by David Parter

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

[...]

Remind me again why you'd want to be looking anywhere [other than the NTP docs/lists]
for answers?

LOPSA (and SAGE) are communities of people with:

* a broad but specific set of shared interests
* ongoing relationships.
* a desire to learn by watching over the shoulders of others

These questions we raise, these topics we discuss -- they're the
medium through which we build a community. Any one question, taken by
itself, could probably be answered somewhere else more efficiently...
but there's an inverse correlation between efficiency and serendipity.
Serendipity is much, much more precious than having the right answer.

[Tom Limoncelli]

Post by Brad Knowles

Post by David Parter

Post by Brad Knowles
Asking questions regarding NTP elsewhere is not as likely to get you
any useful response.

I strongly disagree. Asking operational questions on lopsa-tech is 100%
appropriate, and likely to provide useful, technically accurate
answers from colleagues who can probably understand that situations we
are in. And the rest of us can often learn something at the same time.

As a long-time member of the NTP Public Services Project, I violently
disagree. These are all basic questions that could be answered by

Even if the question is, "Where do I find the NTP FAQ?"

While I agree that people should find their answers in the docs for a
product (especially in the age of open source and wikis), LOPSA should
be a community that supports each other, and that means questions that
may be answered anywhere else.

Time? Let me tell you about time...
Tom

[r***@anl.gov]

Post by Brad Knowles
The whole implementation of ntpdate is also fundamentally flawed.
The code is ancient, it hasn't been touched in many years, it doesn't
make use of any of the more recent libraries or the more recent
network code, or anything else. Even if you refuse to accept the two
above arguments for the "termination with extreme prejudice" of
ntpdate, you should accept this one.

I ran into this on the ntp list a year++ ago now. I came to the
conclusion that it takes some effort to crack the attitude of
the people doing development of the new versions of NTP and have
them understand the basic concept of what is needed in the real world.

As a number of people have indicated ntpdate IS very functional. I'd
go so far as to say that it serves a purpuse that the other tools
do not achieve. I don't want my machine to reboot and take 15 minutes
or longer to get into sync. I want something that is the equal to
ntpdate, with all the new bells/whistles/security/support to set
my clock to something really close to reality so that I can then
fire up ntpd and have it work as expected. I run ntpdate as soon
as I have a reasonable network connection before any other services
are started. That way I don't jump my clock after the fact. I don't
know how many times I've found machines that have some hardware clock
problem when the machine is turned off. When that machine reboots, ntpd
says the clock is to far off and aborts. The machine now comes up
the rest of the way and everything else is messed up. Chances are
I can't even login to fix it since the clock is to far out of sync
for my authentication services to properly sync. Ouch.

If I could equate this to the issues that many of us remember when
we used rlogin to get from machine to machine. Some users really
complained that they didn't want to learn something new, even if
it was more secure, etc etc. To 'fix' this problem for these
troublesome users, '/bin/rm /bin/rlogin; ln -s /bin/ssh /bin/rlogin"
Most users never knew they were using SSH instead of rlogin.
To them the functionality was the same. It did all they cared about.

IF the ntp developers recognize the need for a quick and maybe just
get the clock close enough tool that could be called ntpdate. I'd be
happy.

--Gene

[Doug Hughes]

Post by r***@anl.gov
IF the ntp developers recognize the need for a quick and maybe just
get the clock close enough tool that could be called ntpdate. I'd be
happy.

I bet if they made a shell script called ntpdate with ntpd -gnq $1 in
it, nobody would notice. :)
(hint, hint to any of NTP developer team listening)

[Derek J. Balling]

Post by Doug Hughes

Post by r***@anl.gov
IF the ntp developers recognize the need for a quick and maybe just
get the clock close enough tool that could be called ntpdate. I'd be
happy.

I bet if they made a shell script called ntpdate with ntpd -gnq $1 in
it, nobody would notice. :)
(hint, hint to any of NTP developer team listening)

And I bet none of them would care, either. :)

They could even be slick about it.... just make ntpdate a symlink to
ntpd and have ntpd do a look at $0 to see how it was called (the way
sendmail symlinks mailq to sendmail and handles it)

Cheers,
D

[Brad Knowles]

They could even be slick about it.... just make ntpdate a symlink to ntpd
and have ntpd do a look at $0 to see how it was called (the way sendmail
symlinks mailq to sendmail and handles it)

That is precisely one method that has been seriously discussed.

My suspicion is that the code and program name will be killed
outright, and only if there is a massive hue and cry from the entire
Universe, will we then take the step of shipping an "ntpdate-ng"
which amounts to nothing more than a hardlink to the same inode which
is also known by the name "ntpd".

But we'll have to see.

[Jo Rhett]

Post by Doug Hughes
I bet if they made a shell script called ntpdate with ntpd -gnq $1 in
it, nobody would notice. :)
(hint, hint to any of NTP developer team listening)

Doesn't work, complains about lack of ntp.conf and dies.

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness

[Brad Knowles]

Post by Jo Rhett
Doesn't work, complains about lack of ntp.conf and dies.

It's your network, you're free to do whatever you want.

But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.

Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

[Sami Juvonen]

Post by Brad Knowles
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.

Hold on right there pardner. I don't work for a law enforcement agency
so I don't see how whatever CALEA and FBI say have a mandate on my
environments. And who exactly would be affected by the proposed FCC
regulations?

Post by Brad Knowles
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

I am not to blame, btw, and I have documentation to show for it ;-)

Any link to something explaining where and when that is applicable
would be appreciated. Especially as I am looking for ammunition to
make management see the light (or a faint glow) here.

-sam.

[Brad Knowles]

Post by Sami Juvonen
Hold on right there pardner. I don't work for a law enforcement agency
so I don't see how whatever CALEA and FBI say have a mandate on my
environments. And who exactly would be affected by the proposed FCC
regulations?

Anyone who is in any kind of a situation where a customer or an
employee might be participating in illegal activity, or be in
partnership with someone participating in an illegal activity, and
therefore might reasonably expect to have law enforcement come knock
on your door -- you're subject to CALEA, FBI, DOJ, and FCC
regulations, and in 2006 the rules regarding accurate time sync were
extended to cover all IP based networks.

This also means that anyone using VOIP or where VOIP or VOIP-like
technology is used on your networks, you're subject to all CALEA
regulations, just like any other telco.


Basically, anyone anywhere that owns or uses a computer that connects
to any other computer through IP protocols, is subject to the
above-named laws.


Now, you can decide to ignore these laws. You may feel that there is
virtually no risk that you will have a dawn raid by the FBI -- or
RIAA, MPAA, or SPA.

But the cost of failure to be in compliance with these laws in case
they do come knocking at your door at oh-shit-dark-thirty in the
morning, well ... that's pretty high.

So, you need to weigh your risk of being caught against the
catastrophic cost of failure to be in compliance, if the dice really
do come up snake-eyes.

Post by Sami Juvonen
Any link to something explaining where and when that is applicable
would be appreciated. Especially as I am looking for ammunition to
make management see the light (or a faint glow) here.

I've added the "Legal Requirements" section (with as many links as I
can provide) to the Community Supported Documentation at
<http://support.ntp.org/bin/view/Main/WebHome#Legal_Requirements>.

[Brad Knowles]

Post by Brad Knowles
So, you need to weigh your risk of being caught against the
catastrophic cost of failure to be in compliance, if the dice really
do come up snake-eyes.

BTW, I am not a lawyer. What I say in this matter cannot be
construed to be legal advice. I can tell you what I think the
potential risks are, but you will need to consult with your lawyers
before you decide what your appropriate actions are.


However, being married to a lawyer and a former General Counsel and
Chief Compliance Officer of an international investment bank
operation, I can tell you that if you are the CCO (and therefore
potentially on the hook to go to jail for any crimes that your
company or your employees commit), you're going to want to look very,
very closely at anything your employees do -- or don't do -- that
could wind up with you landing in jail. You're going to want to feel
really comfortable about the risks you're taking and what the
potential consequences are.

I've been instructed in how to handle a dawn raid situation. It
basically amounts to taking the cats and putting them in their
respective carriers (so that they don't escape while all your worldly
possessions are being carted out the door by people whose primary
motivation is to get the removal process over as quickly as possible
and don't care what state those worldly possessions are in
afterwards), find a nice comfy spot on the bare floor to sit down on
(don't sit on any furniture or on top of any carpets or other
flooring that could be removed), and bend over and kiss your ass
goodbye. Oh, and if they don't take the phone away immediately, make
sure to call the outside counsel to let them know that they will need
to start proceedings, and ask them to call your pet sitter to come
take care of the cats, because you're not going to get a second call.

But if you're not the CCO or otherwise on the hook to go to jail as a
result of illegal activity on the part of your company or your
employees, then maybe you don't care about a dawn raid situation, and
maybe you don't want your CCO to know about the risk they may be
taking -- or maybe they don't want you to tell them, because they've
got enough other stress in their lives right now.


It's your choice. You pays your money, and you takes your chances.

[Michael T. Halligan]

Brad,

You might want to remember that you are not a lawyer, and state such
while spreading your FUD.

Repeat after me

I Am Not A Lawyer (IANAL)

Post by Brad Knowles

Post by Sami Juvonen
Hold on right there pardner. I don't work for a law enforcement agency
so I don't see how whatever CALEA and FBI say have a mandate on my
environments. And who exactly would be affected by the proposed FCC
regulations?

Anyone who is in any kind of a situation where a customer or an
employee might be participating in illegal activity, or be in
partnership with someone participating in an illegal activity, and
therefore might reasonably expect to have law enforcement come knock
on your door -- you're subject to CALEA, FBI, DOJ, and FCC
regulations, and in 2006 the rules regarding accurate time sync were
extended to cover all IP based networks.
This also means that anyone using VOIP or where VOIP or VOIP-like
technology is used on your networks, you're subject to all CALEA
regulations, just like any other telco.
Basically, anyone anywhere that owns or uses a computer that connects
to any other computer through IP protocols, is subject to the
above-named laws.
Now, you can decide to ignore these laws. You may feel that there is
virtually no risk that you will have a dawn raid by the FBI -- or
RIAA, MPAA, or SPA.
But the cost of failure to be in compliance with these laws in case
they do come knocking at your door at oh-shit-dark-thirty in the
morning, well ... that's pretty high.
So, you need to weigh your risk of being caught against the
catastrophic cost of failure to be in compliance, if the dice really
do come up snake-eyes.

Post by Sami Juvonen
Any link to something explaining where and when that is applicable
would be appreciated. Especially as I am looking for ammunition to
make management see the light (or a faint glow) here.

I've added the "Legal Requirements" section (with as many links as I
can provide) to the Community Supported Documentation at
<http://support.ntp.org/bin/view/Main/WebHome#Legal_Requirements>.
--
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Brad Knowles]

Post by Michael T. Halligan
You might want to remember that you are not a lawyer,

Obviously your hair-trigger is set a little too lightly, because you
clearly missed the message I sent right afterwards that did clearly
state that I am not a lawyer.

Post by Michael T. Halligan
and state such
while spreading your FUD.

But it's not FUD. We're talking about upcoming significant changes
to the NTP protocol and all the code in order to implement all the
cryptographically auditable, verifiable, and authenticated time
information, and while you could argue that was needed anyway (for
liability purposes), a good part of that is clearly being driven by
changes in the laws -- both here in the US and overseas. And any
company or group that has dealings with any international clients
could potentially be subject to both laws overseas as well as laws
here in the US.


We don't really know what all is going to happen, but anyone who
attended the "Legal Issues/Forensics" Guru-is-in talk at LISA'07 got
a small taste of what the Federal Rules of Evidence are, and what
kind of a whole field of landmines this topic is.

One of the speakers was Jason Park from MD5Group, and you can see
their website at <http://www.md5group.com/>. They had a nice little
handout that showed all the various major steps in a legal proceding
where you might be required to follow the FRE, and a single mistake
at any of those steps could have very dire consequences for you, your
group, your company, any lawsuits or criminal cases against you,
etc....

And they didn't even get into the stuff that we've seen developing
recently regarding legal requirements for time synchronization,
because bad time stamps can throw off everything else.


These are legitimate issues that we need to be aware of, even if we
don't think that they apply to us today.

[Michael T. Halligan]

Post by Brad Knowles

Post by Michael T. Halligan
You might want to remember that you are not a lawyer,

Obviously your hair-trigger is set a little too lightly, because you
clearly missed the message I sent right afterwards that did clearly
state that I am not a lawyer.

You are correct, and I apologize. That being said, IANAL but I'm
willing to be $50,000 that I will not be arrested if the timestamps in
my logs are off for the next 23 years.

Post by Brad Knowles

Post by Michael T. Halligan
and state such
while spreading your FUD.

But it's not FUD. We're talking about upcoming significant changes
to the NTP protocol and all the code in order to implement all the
cryptographically auditable, verifiable, and authenticated time
information, and while you could argue that was needed anyway (for
liability purposes), a good part of that is clearly being driven by
changes in the laws -- both here in the US and overseas. And any
company or group that has dealings with any international clients
could potentially be subject to both laws overseas as well as laws
here in the US.
We don't really know what all is going to happen, but anyone who
attended the "Legal Issues/Forensics" Guru-is-in talk at LISA'07 got
a small taste of what the Federal Rules of Evidence are, and what
kind of a whole field of landmines this topic is.
One of the speakers was Jason Park from MD5Group, and you can see
their website at <http://www.md5group.com/>. They had a nice little
handout that showed all the various major steps in a legal proceding
where you might be required to follow the FRE, and a single mistake
at any of those steps could have very dire consequences for you,
your group, your company, any lawsuits or criminal cases against
you, etc....
And they didn't even get into the stuff that we've seen developing
recently regarding legal requirements for time synchronization,
because bad time stamps can throw off everything else.
These are legitimate issues that we need to be aware of, even if we
don't think that they apply to us today.

So, what you've just told me is :

- We need to be concerned of how unknown and the state of flux that
the uknown legislation of timestamps in logs is going to affect us
(Fear)
- You don't know what's going to happen (Uncertaintly, Doubt)

[Brad Knowles]

You are correct, and I apologize. That being said, IANAL but I'm willing to
be $50,000 that I will not be arrested if the timestamps in my logs are
off for the next 23 years.

You may very well be right. Or wrong. You won't know until the time
comes, and the rest of us may never find out.

Those in situations where you might be in higher risk of an NSL or
dawn raid, might not be willing to make that same bet, especially
since the price tag for some of them would be likely to be much
higher.


Would you be willing to bet a million dollars? Ten million dollars?
The entire future of your company and/or all your personal property
and other assets? How much would be too high of a price, even if you
did think the risk was minimal?

- We need to be concerned of how unknown and the state of flux that the
uknown legislation of timestamps in logs is going to affect us (Fear)
- You don't know what's going to happen (Uncertaintly, Doubt)

You give every appearance to have intentionally mis-understood and
mis-represented what I was trying to say, and I don't understand what
you're getting out of this.

Are you just arguing for the sake of arguing, or is there some real
tangible value that you're getting out of this process that I'm not
seeing?


There's a very real risk here. Unless you are a lawyer specializing
in this particular area, or a compliance officer yourself, then
neither you nor I are qualified to determine what the probable cost
would be, if you got hit. Likewise, neither you nor I are likely to
be qualified to determine what the probability is that you'd get hit.

And unless you are a sole proprietorship or unemployed, neither you
nor I are likely to be in a position where we would personally be the
ones on the hook for monetary damages or being sent to jail, if we
did get hit.

Actually, I probably am on the hook for these things, so long as I
continue to try to maintain my own consulting company. But that
still doesn't help me with the other two parts of the problem.


I'm just trying to identify the potential problem here. The rest is
between you, your lawyers, and your compliance officer(s).

If your lawyers and your compliance officer(s) determine that this is
nothing to worry about, then you're covered.

Otherwise, you may have to take another look at your systems
infrastructure in order to determine how you can bring your systems
into compliance with these regulations.

[d***@lang.hm]

Post by Sami Juvonen
Hold on right there pardner. I don't work for a law enforcement agency
so I don't see how whatever CALEA and FBI say have a mandate on my
environments. And who exactly would be affected by the proposed FCC
regulations?

<FUD about NTP being alegal requirement snipped>

given that people don't go to jail for 'loosing' peoples credit card info
on the public Internet I hardly think that having your clocks off by a
half second will land you in jail.

David Lang

[Clif Smith]

<IANAL>
Here here!

Can we please stop talking about going to jail should our clocks be
out of whack. You've stated the point over and over, we get it. I
doubt many of us believe it, but we get it. I believe 99% of us
simply want our clocks to be synced...even if we use, eek!, ntpdate.

Is the Quick Start at http://www.eecis.udel.edu/~mills/ntp/html/build/quick.html
still valid? I ask as it's dated March 20, 2004.
</IANAL>

cjs

Post by d***@lang.hm

Post by Sami Juvonen
Hold on right there pardner. I don't work for a law enforcement agency
so I don't see how whatever CALEA and FBI say have a mandate on my
environments. And who exactly would be affected by the proposed FCC
regulations?

<FUD about NTP being alegal requirement snipped>
given that people don't go to jail for 'loosing' peoples credit card info
on the public Internet I hardly think that having your clocks off by a
half second will land you in jail.
David Lang
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Brad Knowles]

Can we please stop talking about going to jail should our clocks be out
of whack. You've stated the point over and over, we get it. I doubt
many of us believe it, but we get it. I believe 99% of us simply want
our clocks to be synced...even if we use, eek!, ntpdate.

You might want to check with your lawyers and your compliance office
before you go down that route, but as I said, you pays your money and
you takes your chances.

Is the Quick Start at
http://www.eecis.udel.edu/~mills/ntp/html/build/quick.html still valid?
I ask as it's dated March 20, 2004.

I think we're still linking to that as the "official" quickstart
guide, but there are others that we also link to from
<http://support.ntp.org/bin/view/Support/QuickStartIndex>.

[Brad Knowles]

Post by d***@lang.hm
<FUD about NTP being alegal requirement snipped>

As I said before, it's not FUD. It's ironic that immediately after
my NTP Guru-is-in session, they held the Legal/Forensics Guru-is-in
session. Before you start making any claims in this matter and
nervously claiming "FUD", you really should have all your facts, and
the first step in that process would be acquainting yourself with the
Federal Rules of Evidence, which you could have gotten if you had
attended that session.

Post by d***@lang.hm
given that people don't go to jail for 'loosing' peoples credit card info
on the public Internet I hardly think that having your clocks off by a
half second will land you in jail.

It all depends on the judge, and the nature of the civil or criminal
case against you. Witness the Lorraine v. Markel case, where both
sides got all their e-mail thrown out of court because they didn't
follow the FRE.

My understanding is that this was a case worth hundreds of thousands
of dollars, regarding the damage that occurred to a boat. If you're
the person who's trying to collect insurance damage to your boat,
that hundreds of thousands of dollars could be a huge impact on your
financial situation.

Scale up or down as appropriate, depending on who the respective
parties are and what they're arguing about in court.

[d***@lang.hm]

Post by d***@lang.hm
<FUD about NTP being alegal requirement snipped>

As I said before, it's not FUD. It's ironic that immediately after my NTP
Guru-is-in session, they held the Legal/Forensics Guru-is-in session. Before
you start making any claims in this matter and nervously claiming "FUD", you
really should have all your facts, and the first step in that process would
be acquainting yourself with the Federal Rules of Evidence, which you could
have gotten if you had attended that session.

Post by d***@lang.hm
given that people don't go to jail for 'loosing' peoples credit card info
on the public Internet I hardly think that having your clocks off by a
half second will land you in jail.

It all depends on the judge, and the nature of the civil or criminal case
against you. Witness the Lorraine v. Markel case, where both sides got all
their e-mail thrown out of court because they didn't follow the FRE.
My understanding is that this was a case worth hundreds of thousands of
dollars, regarding the damage that occurred to a boat. If you're the person
who's trying to collect insurance damage to your boat, that hundreds of
thousands of dollars could be a huge impact on your financial situation.

there is a HUGE difference between having evidence thrown out of court and
a dawn raid confescating everything you own and landing you in jail.
claiming one and then using evidence of the other _is_ FUD.

they aren't going to legaly mandate that everyone use NTP any more then
they are going to mandate that everyone use windows, or even that everyone
who uses windows have an up-to-date anti-virus/anti-spyware package
installed (and the latter would make far more difference then any time
sync issues ever would)

I happen to run ntp syncing to GPS receivers, but I do that becouse I want
reliable time for my own comfort, not becouse I fear that I'll be put in
jail if I don't.

the feds can mandate what goverment agencies do with their computers, they
can't control the rest of the country (let alone the rest of the world)

you can point at court cases where evidence has been thrown out becouse it
wasn't perfect, but for every case like that there are many others where
imperfect evidence was recognised as being imperfect and still allowed in.

if you think having your log timestamps being a half second off is enough
to invalidate your logs, you better be printing them out in real-time (on
a line-based printer like an old dot matrix, not on a page-based printer
like a laser or modern inkjet) becouse the vunerability of storing your
logs on re-writable media (where they can be changed with no forensics
traces being left behind), as the problems involved are much larger.

if you make _no_ attempt to maintain your clocks, and all your servers
have wildly different times you can expect everyone to question your logs,
but nobody is advocating that, they are just disputing the claim that you
will go to jail for having a system clock drift by 11ms.

David Lang

[Brad Knowles]

Post by d***@lang.hm
there is a HUGE difference between having evidence thrown out of court
and a dawn raid confescating everything you own and landing you in jail.
claiming one and then using evidence of the other _is_ FUD.

They were two totally separate issues in my mind. I'm sorry if I
gave any other impression.

Post by d***@lang.hm
they aren't going to legaly mandate that everyone use NTP any more then
they are going to mandate that everyone use windows, or even that everyone
who uses windows have an up-to-date anti-virus/anti-spyware package
installed (and the latter would make far more difference then any time
sync issues ever would)

Actually, they do effectively mandate NTP. Check the documents I
referenced. They clearly indicate a current requirement to meet
200ms accuracy standards, and since 2006 that has applied to both
telephony situations as well as situations where traffic is
transmitted or received via IP-based protocols. The base law is
CALEA, but the FCC is given the mandate to interpret the law in
accordance to what is practical and feasible, with input from the
DOJ, FBI, etc....

What's going on now is that the FBI and DOJ are going back to the FCC
to try to get the particular ANSI standard declared insufficient for
the needs of meeting CALEA requirements, so that they can come up
with some tighter requirements, such as 10ms accuracy standards.

Read The Fine Documents.

Post by d***@lang.hm
the feds can mandate what goverment agencies do with their computers,
they can't control the rest of the country (let alone the rest of the
world)

In this case, CALEA applies to all communications that occurs in or
passing through the boundaries of the USA. And the FCC gets to
interpret what the specific standards are that are designated to meet
those standards.

Post by d***@lang.hm
you can point at court cases where evidence has been thrown out becouse
it wasn't perfect, but for every case like that there are many others
where imperfect evidence was recognised as being imperfect and still
allowed in.

True, but this is a watershed -- this case has set a legal precedent.
So far as I know, there have not yet been any other cases decided
where this precedent could have been considered before the decision
was handed down, so there is no counter-precedent, and this case has
not been overturned.

Once something gets accepted by a single court as part of the
fact-finding process, that usually has a strong impact on all
following cases throughout the country. Not always, but usually.

Which is why I'm making such a big deal out of this issue.


As for the rest, this is CALEA. It applies to all communications
that originates in, terminates in, or passes through the USA. If you
wish to be in violation of that law, that's your risk. As to what
the potential consequences could be if you get hit with an NSL or a
dawn raid and you're not in compliance with CALEA, that's up to the
judge.


I've said it before, and I'll say it again. You pays your money, and
you takes your chances.

[Doug Hughes]

Post by Brad Knowles

Post by d***@lang.hm
there is a HUGE difference between having evidence thrown out of court
and a dawn raid confescating everything you own and landing you in jail.
claiming one and then using evidence of the other _is_ FUD.

They were two totally separate issues in my mind. I'm sorry if I
gave any other impression.

Post by d***@lang.hm
they aren't going to legaly mandate that everyone use NTP any more then
they are going to mandate that everyone use windows, or even that everyone
who uses windows have an up-to-date anti-virus/anti-spyware package
installed (and the latter would make far more difference then any time
sync issues ever would)

Actually, they do effectively mandate NTP. Check the documents I
referenced. They clearly indicate a current requirement to meet
200ms accuracy standards, and since 2006 that has applied to both
telephony situations as well as situations where traffic is
transmitted or received via IP-based protocols. The base law is
CALEA, but the FCC is given the mandate to interpret the law in
accordance to what is practical and feasible, with input from the
DOJ, FBI, etc....

CALEA explicitly makes this clear that this is for common carriers such
as AT&T, Verizon, etc. They are defined in CALEA 107(8)(A) as "fee
charging common carriers", including mobile phone operators and
telecommunication carries.. It's in the section on call metadata
(source, destination, length) in relation to wiretaps. Nowhere,
*nowhere* does it cover home or work computers outside of that context.

Sure, they can grab your stuff, but that's a totally different matter.
This is way outside the FCC's jurisdiction.

Post by Brad Knowles
What's going on now is that the FBI and DOJ are going back to the FCC
to try to get the particular ANSI standard declared insufficient for
the needs of meeting CALEA requirements, so that they can come up
with some tighter requirements, such as 10ms accuracy standards.
Read The Fine Documents.

I have a sysadmin turned lawyer friend who has read all the fine
documents. These claims are way outside what the law states and require
some suspension of disbelief.

Further excerpts:
"18 USC 2511 and 18 USC 2701 allow the Feds to sniff traffic/wiretap or
seize stored electronic communications with the correct warrant. 18 USC
3127 allows the Feds to either require you to store metadata about
communications (to/from/time/duration) or install gear that takes the
same information if you lack the capability. "
(note, this second part is "after" being served with a warrant - and,
likely, under the patriot act, without one, but still after they tell
you to, not before)

Now, if you deliberately distort your time to impede an investigation,
that's a totally different matter.

Post by Brad Knowles

Post by d***@lang.hm
the feds can mandate what goverment agencies do with their computers,
they can't control the rest of the country (let alone the rest of the
world)

In this case, CALEA applies to all communications that occurs in or
passing through the boundaries of the USA. And the FCC gets to
interpret what the specific standards are that are designated to meet
those standards.

in the context of common carriers where the FCC has jurisdiction yes,
not in your work environment unless you work for a common carrier (and
no, VOIP does not make you a common carrier unless you are a company
like Vonage - so far...)

Post by Brad Knowles
As for the rest, this is CALEA. It applies to all communications
that originates in, terminates in, or passes through the USA. If you
wish to be in violation of that law, that's your risk. As to what
the potential consequences could be if you get hit with an NSL or a
dawn raid and you're not in compliance with CALEA, that's up to the
judge.

common carriers and telecommunication providers. See above. Check the
sections. The FCC can only modify standards where it has jurisdiction
and that is not in the common workplace except as pertains to common
carriers.

P.S. he (the lawyer) believes that
http://support.ntp.org/bin/view/Main/WebHome#Legal_Requirements is a
misrepresentation of currently operative law.

P.P.S my first, last, only post on the matter.

[Yves Dorfsman]

Post by Doug Hughes
I have a sysadmin turned lawyer friend who has read all the fine
documents. These claims are way outside what the law states and require
some suspension of disbelief.

Can we (LOPSA) pay the sysadmin-turned-lawyer-friend to write short
explanation for us that we can post on our website and use as a reference ?

I'm not asking Doug here, I'm asking all of us if this is the sort of
thing that WE want LOPSA to be doing ? Is this what we want our membership
money to be used for (I personally vote yes here) ?

I understand the current discussion is very US centric, but this would be
a good way to kickstart the same initiative for other countries, and we
could update the website as we find out.


Yves.

PS: I realiase this does not belong to ***@lopsa any more, but thought
it'd be better to stick to the current thread.

[John Jasen]

Post by Yves Dorfsman
Can we (LOPSA) pay the sysadmin-turned-lawyer-friend to write short
explanation for us that we can post on our website and use as a reference ?
I'm not asking Doug here, I'm asking all of us if this is the sort of
thing that WE want LOPSA to be doing ? Is this what we want our membership
money to be used for (I personally vote yes here) ?

After an $INTERESTING_EVENT, I began to hold the thought that IT
professionals may be well-served to have a technologically savvy lawyer on
retainer (and sometimes speed-dial ....).

I, for one, second the idea of LOPSA having a 'legal expert' option.

[Richard Chycoski]

<IANAL> [This should be a standard HTML markup code that makes text
bold, a fluorescent colour, and blinking, with a public health warning
watermark. :-]

Legal opinions are just that - opinions. No individual opinion is worth
anything (as I've discovered when involved with lawyers over the years).

Laws have to be tested in the courts before they get any real teeth.

Individual or organisation need to operate based on the best legal
opinions that they can, but it is never safe to rely upon such opinions.

My $WORK retains a bevy of creatures who pontificate on every relevant
legal subject, but even if they were to make a pronouncement that I were
allowed to make public (which is NOT going to happen :-), you should
never rely on this as for CYA, but you might want to take such opinions
to your own lawyers to evaluate. You're also likely to find it difficult
to get a lawyer to render a public opinion on the subject, as most of
them don't want to get sued in case someone uses the opinion (correctly
or incorrectly).

The worth of such opinions also change continuously with time, so they
become stale very quickly.

</IANAL>

I wouldn't suggest that we spend LOPSA money to get such an opinion, but
it's certainly useful if members who see related court cases bring them
to our attention. We do need to see how the rubber meets the road. It
*is* part of our due diligence to make sure that we keep up with the
law, and if people or companies outside the common carriers start to get
into troubles for logging with less than stellar time, it will be time
to show that we're doing everything we can to fix the problem. Until
then, it really is FUD.

- Richard

Post by John Jasen

Post by Yves Dorfsman
Can we (LOPSA) pay the sysadmin-turned-lawyer-friend to write short
explanation for us that we can post on our website and use as a reference ?
I'm not asking Doug here, I'm asking all of us if this is the sort of
thing that WE want LOPSA to be doing ? Is this what we want our membership
money to be used for (I personally vote yes here) ?

After an $INTERESTING_EVENT, I began to hold the thought that IT
professionals may be well-served to have a technologically savvy lawyer on
retainer (and sometimes speed-dial ....).
I, for one, second the idea of LOPSA having a 'legal expert' option.

[Brad Knowles]

Post by Doug Hughes
CALEA explicitly makes this clear that this is for common carriers such
as AT&T, Verizon, etc. They are defined in CALEA 107(8)(A) as "fee
charging common carriers", including mobile phone operators and
telecommunication carries..

That's where it started, but I believe it has been amended to cover
anyone with a PBX or carries VOIP or VOIP-like services over their
network, at the very least.

Post by Doug Hughes
It's in the section on call metadata (source, destination, length) in
relation to wiretaps. Nowhere, *nowhere* does it cover home or work
computers outside of that context.

You can't just read the one law in isolation. You've also got to
read all the other associated rules, regulations, etc... that have
been put into force by the FCC and others. The original law was
relatively restricted in terms of who it covered, but I believe it
has since been amended to cover a much broader range of potential
targets.

Oh, and you also need to consider all pending rules & regulations, too.

Post by Doug Hughes
Sure, they can grab your stuff, but that's a totally different matter. This
is way outside the FCC's jurisdiction.

Right, that's where the DOJ, FBI, and the courts come into play,
which is also part of that "other associated rules & regulations" bit
that I referred to above.

Post by Doug Hughes
I have a sysadmin turned lawyer friend who has read all the fine
documents.

All of them? Every single law, rule, or regulation that has been put
into force that relates to CALEA, from all the various different
government agencies and departments?

Post by Doug Hughes
These claims are way outside what the law states and require
some suspension of disbelief.

I'm clearly concerned about this issue, and I would love to hear the
opinion of someone who really has read all the various laws, rules,
and regulations that are associated with CALEA, including everything
on this subject from the FCC, FTC, DOJ, FBI, and any other government
entity, and who really can give us a pretty authoritative answer on
who is affected, what the potential liabilities are, etc....

Failing an authoritative answer that covers the full breadth of all
laws, rules, and regulations on this subject, I hope you'll forgive
me if I'm a little skeptical about what someone says about what they
have been told by a friend of theirs.


I'm doing the best I can, based on the original source documents that
I can find, and I'm finding it hard slogging. It's not like these
are RFCs where each document tells you at the top which other
documents it updates or obsoletes, and where each updated or
obsoleted document at least has an index somewhere that also refers
to the newer ones which are doing the updating or obsoleting.

Post by Doug Hughes
(note, this second part is "after" being served with a warrant - and,
likely, under the patriot act, without one, but still after they tell
you to, not before)

The ability to do a trap & trace, or a pen register, is something
that the common carriers have had for a long time. It takes
virtually no time to enact these things, and much of the information
they're likely to be able to hand over would be based on extensive
call detail information that they have to keep anyway.

So, one call from law enforcement (presumably with a supporting
warrant, or at least a promise that you'll get a suitable National
Security Letter at some point in time in the future), and they've not
only got all the information from that point going forward, but also
a great deal of historical information.

My understanding is that the DOJ & FBI are looking to extend those
same requirements to other parties and other forms of communication,
under CALEA and how the law says it is to be interpreted and enforced.


As an interesting side note, a cousin of mine did software
development for AT&T, specifically their billing software. It really
is true that about 90% of your bill is just paying for the massive
amounts of data that they are required to keep about each and every
call, and for how long they are required to keep it.

Post by Doug Hughes
common carriers and telecommunication providers. See above. Check the
sections. The FCC can only modify standards where it has jurisdiction
and that is not in the common workplace except as pertains to common
carriers.

That may be how you interpret that portion of the law that you've
read, but my understanding is that the DOJ and FBI don't see it that
way, and there's at least question as to how expansive the
interpretation is going to be.


For example, if someone in the White House commits High Treason by
causing "Very Grave Harm to National Security Interests" through
exposing an undercover CIA operative, and yet no one even gets tried
for that crime. Morever, the only person who gets convicted is
merely caught up in perjury and obstruction of justice related to the
suspected crime, and then his sentence gets commuted, then what
happens to the original crime?

Is it then no longer a crime to expose an undercover CIA operative?

It all depends on how expansive the interpretation is of the laws.

[Richard Chycoski]

<IANAL>

From: <http://www.fcc.gov/calea/>

" In response to concerns that emerging technologies such as digital and
wireless communications were making it increasingly difficult for law
enforcement agencies to execute authorized surveillance, Congress
enacted CALEA on October 25, 1994. CALEA was intended to preserve the
ability of law enforcement agencies to conduct electronic surveillance
by requiring that telecommunications carriers and manufacturers of
telecommunications equipment modify and design their equipment,
facilities, and services to ensure that they have the necessary
surveillance capabilities. Common carriers, facilities-based broadband
Internet access providers, and providers of interconnected Voice over
Internet Protocol (VoIP) service – all three types of entities are
defined to be “telecommunications carriers” for purposes of CALEA
section 102, 47 U.S.C. § 1001 – must comply with the CALEA obligations
set forth in CALEA section 103, 47 U.S.C. § 1002. See CALEA First Report
and Order
<http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-153A1.pdf>
(rel. Sept. 23, 2005). ."

So, if you're a phone company, big ISP, or *provider* of VOIP services,
CALEA applies to you. For the rest of us (and our companies) who consume
and use these services, it appears that CALEA does not apply.

</IANAL>

So, *FUD ALERT*. Unless you're a common carrier or reasonable facsimile
thereof.

YMMV, CMHSDS.

- Richard

Post by Brad Knowles

Post by d***@lang.hm
there is a HUGE difference between having evidence thrown out of court
and a dawn raid confescating everything you own and landing you in jail.
claiming one and then using evidence of the other _is_ FUD.

They were two totally separate issues in my mind. I'm sorry if I
gave any other impression.

Post by d***@lang.hm
they aren't going to legaly mandate that everyone use NTP any more then
they are going to mandate that everyone use windows, or even that everyone
who uses windows have an up-to-date anti-virus/anti-spyware package
installed (and the latter would make far more difference then any time
sync issues ever would)

Actually, they do effectively mandate NTP. Check the documents I
referenced. They clearly indicate a current requirement to meet
200ms accuracy standards, and since 2006 that has applied to both
telephony situations as well as situations where traffic is
transmitted or received via IP-based protocols. The base law is
CALEA, but the FCC is given the mandate to interpret the law in
accordance to what is practical and feasible, with input from the
DOJ, FBI, etc....
What's going on now is that the FBI and DOJ are going back to the FCC
to try to get the particular ANSI standard declared insufficient for
the needs of meeting CALEA requirements, so that they can come up
with some tighter requirements, such as 10ms accuracy standards.
Read The Fine Documents.

Post by d***@lang.hm
the feds can mandate what goverment agencies do with their computers,
they can't control the rest of the country (let alone the rest of the
world)

In this case, CALEA applies to all communications that occurs in or
passing through the boundaries of the USA. And the FCC gets to
interpret what the specific standards are that are designated to meet
those standards.

Post by d***@lang.hm
you can point at court cases where evidence has been thrown out becouse
it wasn't perfect, but for every case like that there are many others
where imperfect evidence was recognised as being imperfect and still
allowed in.

True, but this is a watershed -- this case has set a legal precedent.
So far as I know, there have not yet been any other cases decided
where this precedent could have been considered before the decision
was handed down, so there is no counter-precedent, and this case has
not been overturned.
Once something gets accepted by a single court as part of the
fact-finding process, that usually has a strong impact on all
following cases throughout the country. Not always, but usually.
Which is why I'm making such a big deal out of this issue.
As for the rest, this is CALEA. It applies to all communications
that originates in, terminates in, or passes through the USA. If you
wish to be in violation of that law, that's your risk. As to what
the potential consequences could be if you get hit with an NSL or a
dawn raid and you're not in compliance with CALEA, that's up to the
judge.
I've said it before, and I'll say it again. You pays your money, and
you takes your chances.

[Josh Smift]

RC == Richard Chycoski <***@chycoski.com>

RC> So, if you're a phone company, big ISP, or *provider* of VOIP services,
RC> CALEA applies to you. For the rest of us (and our companies) who consume
RC> and use these services, it appears that CALEA does not apply.

As far as I can tell, Brad's argument is that some other law or regulation
might extend CALEA to apply to the rest of us (and our companies), and
that unless you've read every single other law or regulation that might
extend CALEA, you can't be sure that CALEA doesn't apply to you.

I'm inclined to trust that my company has lawyers who keep on top of these
things (they're certainly happy to tell us about a variety of other stupid
laws and regulations that we have to comply with), and that if there were
such laws, they'd be keenly interested in preventing our company from
being shut down and our employees sent to prison.

But, I haven't read every single law or regulation that might extend
CALEA, so I guess I can't be sure.

-Josh (***@infersys.com)

[Derek J. Balling]

Post by Josh Smift
I'm inclined to trust that my company has lawyers who keep on top of these
things (they're certainly happy to tell us about a variety of other stupid
laws and regulations that we have to comply with), and that if there were
such laws, they'd be keenly interested in preventing our company from
being shut down and our employees sent to prison.

<aol>

The reality is, to me, that if this concern were *real*, e.g.,
"founded", that someone more competent (from a legal perspective) than
Brad would be the canary in the coal mine :-)

Yes, it is possible some law nobody has seen has extended CALEA to us
regular folks, and we'd never know it unless we read every line of
every law. It's also possible some crazy law has made IPv4 a forbidden
protocol and we'd never know it without checking every line of every
law.

But it does yield one interesting note... I'd love to have a CVS
repository of the USC. "Hey, what law added THAT verbiage?" "Diff the
code against the same section last week", etc.

Now there's an interesting project.... anyone know of anything like
that? :-)

Cheers,
D

[Brad Knowles]

have the necessary surveillance capabilities. Common carriers,
facilities-based broadband Internet access providers, and providers
of interconnected Voice over Internet Protocol (VoIP) service - all
three types of entities are defined to be "telecommunications carriers"
for purposes of CALEA

Okay, so narrowing down to this specific section of the language you
quote yourself, how is this not applicable to all ISPs and IAPs, and
anyone who provides a VOIP or VOIP-like connection for their
employees or partners (which I believe would cover anyone with a PBX
or Asterix server)?

It seems to me that what's important here is how this particular
section (and any other rules and regulations that might relate to it)
would be interpreted by the courts.


Since IANAL and I don't have direct first-hand experience with
regards to how the courts would be likely to interpret this language,
it seems to me that the best thing to do would be to err on the side
of caution and go ask the people in your company (or whom your
company employs) who do have this kind of experience as to what their
official legal opinion is?

What's do hard about that? What's wrong with recommending that
people go talk to their lawyers if they don't have the kind of direct
first-hand experience as to how the courts would be likely to
interpret this language?

[Richard Chycoski]

Post by Brad Knowles

have the necessary surveillance capabilities. Common carriers,
facilities-based broadband Internet access providers, and providers
of interconnected Voice over Internet Protocol (VoIP) service - all
three types of entities are defined to be "telecommunications carriers"
for purposes of CALEA

Okay, so narrowing down to this specific section of the language you
quote yourself, how is this not applicable to all ISPs and IAPs, and
anyone who provides a VOIP or VOIP-like connection for their employees
or partners (which I believe would cover anyone with a PBX or Asterix
server)?

'Providers' usually does not refer to internal use of services - it
generally means 'providing to others'. It may not mean that in this
case, but as IANAL, I can't prove this either way. OTOH, I'm not trying
to spread FUD that the sky is falling, either.

Post by Brad Knowles
It seems to me that what's important here is how this particular
section (and any other rules and regulations that might relate to it)
would be interpreted by the courts.
Since IANAL and I don't have direct first-hand experience with regards
to how the courts would be likely to interpret this language, it seems
to me that the best thing to do would be to err on the side of caution
and go ask the people in your company (or whom your company employs)
who do have this kind of experience as to what their official legal
opinion is?
What's do hard about that? What's wrong with recommending that people
go talk to their lawyers if they don't have the kind of direct
first-hand experience as to how the courts would be likely to
interpret this language?

This is always a good idea. And *after* getting a legal opinion, or
general consensus, it might be worth considering the implementation of
better time stamp control for legal reasons. Again, the sky is not yet
falling, and while due diligence is always in order, your suggestion
that everyone had better get all of their timestamps in line with CALEA
is premature.

If you'd merely pointed to the law suggesting that there might be
something coming that could require better timestamp control, I doubt
that anyone here would have even raised an eyebrow. It's provocative

Post by Brad Knowles
It's your network, you're free to do whatever you want.
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

and

Post by Brad Knowles
Anyone who is in any kind of a situation where a customer or an
employee might be participating in illegal activity, or be in
partnership with someone participating in an illegal activity, and
therefore might reasonably expect to have law enforcement come knock
on your door -- you're subject to CALEA, FBI, DOJ, and FCC
regulations, and in 2006 the rules regarding accurate time sync were
extended to cover all IP based networks.
This also means that anyone using VOIP or where VOIP or VOIP-like
technology is used on your networks, you're subject to all CALEA
regulations, just like any other telco.

that caused all the ruckus. These kind of pronouncements, not backed up
by the facts, are the quintessential examples of FUD.

They also cause all of your comments to be taken with several grains of
salt, so that when you really do have good points (and sometimes you
do!) they are not believed without much confirmation.

Please - in the future, don't make sweeping generalisations based on
your ISP experience. Yes, most large ISPs are treated as 'common
carriers' in the legal sense - which ISPs use to their benefit (e.g.,
usually absolving themselves of responsibility for content) as well as
being saddled with the extra legal requirements (e.g., gotta log like a
phone company). Corporations that don't provide common carrier services
to others (that's why they're not 'common') usually have less stringent
rules, although laws *can* change to be more invasive of everyone's
freedom over time.

(My previous $WORK included responsibility for the first regional ISP in
Canada, so I do have some experience with the concept of common carrier
rules too - if in a different country.)

- Richard

[Brad Knowles]

Post by Richard Chycoski
'Providers' usually does not refer to internal use of services - it
generally means 'providing to others'.

Okay, so in your opinion this does at least cover all ISPs and IAPs,
right? I mean, they're all providing services to others, using
IP-based protocols, right?

Okay, so how many of them do you think are actually complying with
the current CALEA requirements? How many of them do you think are
likely to be able to comply with some of the new requirements that
the DOJ & FBI are pressing for?

And how many people on this list are likely to be working at ISPs or
IAPs where this should be an issue of concern, or perhaps using ISPs
or IAPs where they should be looking at these sorts of things?


I'm sorry, I still don't see how I am somehow the world's worst
criminal by bringing this to everyone's attention.

[Richard Chycoski]

Post by Brad Knowles

Post by Richard Chycoski
'Providers' usually does not refer to internal use of services - it
generally means 'providing to others'.

Okay, so in your opinion this does at least cover all ISPs and IAPs,
right? I mean, they're all providing services to others, using
IP-based protocols, right?

I didn't say *all* ISPs. The law and government do not always treat
small, local providers the same way they treat large, regional or
national companies. Much more draconian rules are usually applied to
AT&T or AOL sized providers than "Bob's Internet Cafe" or "Sycamoose
dialup Internet, Email, and Computer Repair (ask for Joe at Flo's
Cafe)". Scale matters.

Post by Brad Knowles
Okay, so how many of them do you think are actually complying with the
current CALEA requirements? How many of them do you think are likely
to be able to comply with some of the new requirements that the DOJ &
FBI are pressing for?

I suspect that most companies that are truly covered by CALEA are
probably close to compliance. Most of them are very large companies,
with numerous lawyers on salary or retainer, and lots of formal company
policy. However, there are probably some of these that haven't yet
complied with all of the rules yet - just like not everyone has perfect
Sarbanes Oxley compliance at public companies, or evaded stock option
backdating.

Post by Brad Knowles
And how many people on this list are likely to be working at ISPs or
IAPs where this should be an issue of concern, or perhaps using ISPs
or IAPs where they should be looking at these sorts of things?

Probably lots - but my point is that you were positing that *EVERYONE*
on this list is covered (or will shortly be covered) by this law. That
simply does not appear to be true.

Post by Brad Knowles
I'm sorry, I still don't see how I am somehow the world's worst
criminal by bringing this to everyone's attention.

No one is calling you criminal - just unnecessarily alarmist. Don't cry
'wolf' when you see a puppy!

- Richard

[Clif Smith]

Post by Brad Knowles
--
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

Please stop.

cjs

[Charles Hutchinson]

Post by Clif Smith

Post by Brad Knowles
--
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

Please stop.
cjs

I concur.

CVH

[Trey Harris]

This thread has gone on long enough and everyone has had a chance to be
heard. If individuals want to take it to separate email, feel free to do
so, but please let the tech@ list move on to other topics before people
start to unsubscribe.

Thanks,

Trey Harris
President, LOPSA

[Yves Dorfsman]

Post by r***@anl.gov
IF the ntp developers recognize the need for a quick and maybe just
get the clock close enough tool that could be called ntpdate. I'd be
happy.

It's (fairly) new and it's called "ntpd -gq", and has the added benefit of
telling you if your /etc/ntp.conf is properly configured.

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[unix fan]

Post by Brad Knowles

Post by Jo Rhett
Doesn't work, complains about lack of ntp.conf and dies.

It's your network, you're free to do whatever you want.
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

Let's try to take this conversation in a new direction.

I use ntpdate now both for slammin' the time and for a reference check.
I'll figure out what to do when it's no longer there, especially after
this enlightening thread.

In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much
it fluctuates. I've gone to the VMware site, done what limited things I
could according to the knowledege base (on RHEL 5 with a current 2.6
kernel). E.g., we are told to _not_ run NTP and to install vmware
tools. Check.

At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.

[Yves Dorfsman]

Post by unix fan
In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much

Couldn't ntpdc -p give you the same (actually better) information ? (I
am assuming you are running ntpd here).

Post by unix fan
it fluctuates. I've gone to the VMware site, done what limited things I
could according to the knowledege base (on RHEL 5 with a current 2.6
kernel). E.g., we are told to _not_ run NTP and to install vmware
tools. Check.
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.

At the site I mentioned earlier, the VMware guys added a bunch of patches,
the UNIX guys addded a bunch of patches to RedHat, I am now running ntpd
on my guests which has kept up time to an acceptable level for about a
week now.

I don't about XEN but will be checking soon.... I'm running KVM at home
right now, and I can't get the guests keep time, they loose several
seconds every seconds.

Yves.
----
Yves Dorfsman ***@zioup.com
http://www.SollerS.ca

[Chris Ricker]

Post by Yves Dorfsman
I don't about XEN but will be checking soon.... I'm running KVM at home
right now, and I can't get the guests keep time, they loose several
seconds every seconds.

Xen "just works", at least with Linux as the Dom0 -- I run ntp in the Dom0
only, and the DomUs stay reasonably close automatically

VMWare ESX hasn't been problematic for me once I moved to 3.x

later,
chris

[Richard Chycoski]

The VMware ESX Server-based VM guests @ $WORK keep very good time
(sub-millisecond sync) - with the VMware tools installed.

My VMware Workstation guests keep reasonable time - within a second.
Good enough for test machines that get to experience Groundhog Day deja
vu all over again...

Neither the ESX or VMware workstation guests is running NTP. The hosts
*are* running NTP.

I don't know exactly how our ESX guests are configured, but I can
investigate if there is interest. I've been told by our VMware support
staff that ESX does a better job of keeping the time in sync than the
other VMware products. We may also have some extra patches on ESX
Server, which I would need to verify.

Which VMware product and version are you using? This may have something
to do with how good your time is kept in sync.

Keeping good time is important for a lot of reasons - one of the least
of which is to keep the government happy. Keeping the users happy is
much more immediate - when their builds fail or they have trouble
logging in because of sloppy time, the pain is immediate. Yah, the feds
will get you eventually, but the guys down the hall will get you
*today*. :-)

- Richard

Post by unix fan

Post by Brad Knowles

Post by Jo Rhett
Doesn't work, complains about lack of ntp.conf and dies.

It's your network, you're free to do whatever you want.
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

Let's try to take this conversation in a new direction.
I use ntpdate now both for slammin' the time and for a reference check.
I'll figure out what to do when it's no longer there, especially after
this enlightening thread.
In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much
it fluctuates. I've gone to the VMware site, done what limited things I
could according to the knowledege base (on RHEL 5 with a current 2.6
kernel). E.g., we are told to _not_ run NTP and to install vmware
tools. Check.
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Brad Knowles]

Post by unix fan
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.

At the NTP Guru-is-in session (which I presented), this topic also
came up. I pointed people at the NTP Community Supported
Documentation on this subject, which you can find at
<http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.1.>.

My understanding is that, with these instructions, most people do
reasonably well if they have installed the appropriate tools.

Post by unix fan
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.

My understanding is that Xen "just works" with regards to this
subject, but I don't know about Solaris containers.


If you, or anyone else, knows anything more on this subject that is
not referenced at the URL given above, please feel free to fill in
the appropriate information in the CSD TWiki or pass that information
on to me or one of the other members of the NTP Public Services
Project, and we'll try to make sure it gets into the right place.

[Brad Knowles]

Post by unix fan
In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much
it fluctuates.

BTW, ntpdate is not a particularly good tool for doing NTP debugging.
For that, you really want ntpq or ntpdc, depending on whether you
want mode 6 or mode 7 support.

Most of what you want to debug will probably be available with ntpq
(using mode 6), but if you want to control your NTP daemon
interactively, or you want to query some of the newer (more
esoteric?) stuff, then you'll probably want/need ntpdc (using mode 7).

[apostolos pantazis]

All, I would also be interested in any long term solutions as I am
struggling with keeping time on my Linux VM's.

Thanks.

Post by unix fan

Post by Brad Knowles

Post by Jo Rhett
Doesn't work, complains about lack of ntp.conf and dies.

It's your network, you're free to do whatever you want.
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

Let's try to take this conversation in a new direction.
I use ntpdate now both for slammin' the time and for a reference check.
I'll figure out what to do when it's no longer there, especially after
this enlightening thread.
In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much
it fluctuates. I've gone to the VMware site, done what limited things I
could according to the knowledege base (on RHEL 5 with a current 2.6
kernel). E.g., we are told to _not_ run NTP and to install vmware
tools. Check.
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.
_______________________________________________
Tech mailing list
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[Rowan Littell]

Post by unix fan
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.

Solaris containers (non-global zones) should not try to run NTP
themselves -- that should be left to the global zone on any given
hardware. The reason being that zones don't actually run full virtual
machines, they're just highly isolated instances of the same kernel.
Obviously, two ntpds trying to modify the same kernel's idea of the time
would be a Bad Thing.

I tell my global zones to run NTP, and then the non-global zones on each
of them inherit the time just fine, with the same kind of accuracy and
precision that the global zone gets.

--rowan

[David Bronder]

Post by unix fan
In the meantime, I'm more worried about the dung infested time that
VMware linux guests keep. I use repeated "ntpdate -q <time_server>" to
keep track of the offset from my reference, and I'm amazed at how much
it fluctuates. I've gone to the VMware site, done what limited things I
could according to the knowledege base (on RHEL 5 with a current 2.6
kernel). E.g., we are told to _not_ run NTP and to install vmware
tools. Check.
At the LISA ATW, I was informed by others that lousy time under VMware
is the state of things, and I should set my expectations accordingly.
Anybody else keeping accurate time with their VM systems? I suspect the
problem is not VMware specific, but also extends to Xen and possibly
Solaris containers - but that's a conjecture.

Here's what I did with ESX 2.5.3 on HP Proliant DL585's, which seemed
to keep time well for Linux guests with 2.6 kernels (the 2.4 kernels
never seemed to have problems). YMMV, since I'm sure things like the
hardware in use play a factor, but this worked for me when it was an
issue.

On the ESX server:
- set Misc.TimerHardPeriod to 333
- add tools.synctime = "TRUE" to the guests's .vmx file

On the guest:
- add clock=pit to the kernel options for each kernel (grub/LILO)
- install VMware Tools on the guests

I also ran NTP on the guests, though I didn't compare how well the
guests kept time with vs. without.

The above is all based on the VMware whitepaper on timekeeping.

As I said, never noticed problems with 2.4 kernels, and since moving
to ESX 3.0.2, the clocks on my 2.6 kernels seem to be behaving without
the above steps (the Misc.TimerHardPeriod option was split into two
options in ESX 3, and I'm not sure which I'd need to tweak now if it
were an issue). Admittedly, I'm not validating my clocks to Brad's
level of precision, but very few of my systems might be susceptible to
the list of acronyms and court cases he referenced, so I'm not losing
sleep.

[Brad Knowles]

Post by David Bronder
I also ran NTP on the guests, though I didn't compare how well the
guests kept time with vs. without.

If you really want to know how everyone is
performing, you need to have an external system
monitor all the machines in question, and then
produce rrdtool-based graphs like what Ask Bjørn
Hansen is doing for pool.ntp.org.

For examples, see
<http://www.pool.ntp.org/zone/>,
<http://www.pool.ntp.org/zone/europe>, and
<http://www.pool.ntp.org/zone/be>. If you sign
up to provide a pool server yourself, you can get
access to the internal statistics that Ask keeps
about the servers in the pool and which are used
to determine which machines should be removed
from the pool due to excessive inaccuracy, etc....

We also link to a wide variety of scripts and
statistics monitoring pages at
<http://support.ntp.org/bin/view/Support/MonitoringAndControllingNTP>.


If you do this, you should be able to easily see
things like offset, stratum, state, jitter, root
dispersion, noise, stability, and other
statistical items of interest, and you should be
able to see them vary over time. And you should
be able to do this for all your machines.


Actually, to avoid bias in the system that is
doing the monitoring, you should probably have
multiple external servers perform that task, but
that's a different issue.


In my experience, good timekeeping is one of the
most sensitive things that is done by most
computers. Problems almost always seem to show
up as "bad time" before they show up anywhere
else.

Dr. Mills has some very interesting tests showing
how jitter, noise, and other statistical
measurements can be used as a very good system
thermometer, even when your machine doesn't have
any built-in temperature sensors -- it turns out
that thermal variations in the CPU tend to mess
up your clock in some pretty interesting and
relatively predictable ways. And this happens
before anything else on the system is noticeable.

I believe that this is a very good canary in the
coal mine. You're welcome to use it if you want,
and we'll be more than happy to point you at the
tools you will probably want to check out if you
do want to try to use this tool. OTOH, there's
not much we can do to help you if you choose to
ignore it.

[Joseph Noonan]

Post by Brad Knowles
But when you get hit for non-compliance with CALEA, FBI, and FCC
requirements for timestamps that are guaranteed to be within 200ms,
or the new FCC Docket RM-11376 proposed requirements for timestamps
guaranteed to be within 10ms, you will only have yourself to blame.
Or if you get nailed under the the new requirements under the Federal
Rules of Evidence for the storage of electronic information regarding
the provable authenticity of the information (in Lorraine v. Markel
American Ins. Co., PWG-06-1893), again you will only have yourself to
blame.

Sometimes the INBOX gods have a truly remarkable and timely sense of humor.
The message immediately after this one in my mailbox was a piece of spam that
contains this:


<spam>
Recent amendments to the Federal Rules of Civil Procedure present major
challenges to in-house lawyers and compliance professionals' budgets and
resources. These changes dramatically alter the management of medical
information and pose new challenges for document retention policies for
all healthcare providers. In this 60-minute audio conference program our
topic expert will discuss:

"Record Retention & eDiscovery: What Healthcare Administrators Need to Know"
Wednesday, December 19, 2007 1:00-2:00 p.m. ET
http://www.phconferences.com/RRHC1C?ID=-923170023

</spam>


Granted, Brad is pretty funny all by himself, but the FUD in this spam so
closely mirroring the effluence from his keyboard, really makes it a thigh
slapper!


Heh.

Every time I have seen someone using the phrase "Federal Rules of Civil
Procedure" in the same paragraph with something IT related (and I have seen it
many times in spam), I have felt the need to check and see if my wallet was
where I left it. This time, however, I'm moved to giggle.