On Tue, 8 Jan 2019 at 03:43, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
>
> On Mo, 07.01.19 16:58, Stephen John Smoogen (smooge@xxxxxxxxx) wrote:
>
> > > I wonder if it is worth introducing an entirely new tracking concept
> > > here if you actually don't want to track but just count. The NTP
> > > approach has the benefit that you introduce no new tracking concept at
> > > all, but you just use the data that is pretty much generated
> > > anyway. It also makes this all feel less one-sided, after all you
> > > provide them with a deal: fedora gives the user correct time, the user
> > > is therefore counted.
> >
> > The problems with NTP are the following:
> > 1. The administrative headaches of regular
> > blocks/takedowns/ill-advised security emails because our servers are
> > attacking someone's box on port 123. [As funny as this sounds, getting
> > regular angry emails from some site whose security tool has decided
> > that 123/{tcp,udp} is a major threat still occurs. ]
>
> This is not realistic. NTP is not really just an option, it's pretty
> much a must-have in todays's Internet. You cannot properly validate
> SSL certs if you don't have correct time, which shuts you out of a
> good part of the Internet, including typical download servers that do
> https.
I don't disagree that it should be unrealistic. I also know that it
still gets reported regularly as an attack and sites get dropped
off/spam blocked because some antivirus/firewall router reported it to
<fill in major cyber security company>. As such it needs to be listed
as a possible problem. [This is just the usual risk management CYA so
that when it does happen we can say 'we considered it a risk and
mitigated it with X'. I just don't have an X when I wrote that list
and don't want it to be 'spend 2 hours a day calling clients who can't
connect to RH data-centers because someone thought 123 was a hacker
attack.' ]
>
> If a system doesn't do NTP then it will cetrainly encounter a lot more
> problems then are created by switching from NTP pool servers to Fedora
> servers by default.
>
> Moreover, afair we install and enable NTP clients by default on all
> our installations, no? just like pretty much any other OS these days
> does... counting by NTP mostly just means switching from NTP pool
> servers to fedora's own servers.
>
> > 2. NTP bandwidth while small per system grows a lot as you wrack up
> > servers randomly checking in. Having a pool of servers around the
> > world would require us to get NTP GPS clocks, getting the datacenters
> > to put the antenae out and a bunch of other items. [The budget for
> > this is non-zero.]
>
> Nah, that's not how NTP works, you don't have to have a "GPS clock",
> you can simply replicate the time of a set of upstream servers, that's
> totally OK.
I expect I am running off of old knowledge as I got out of running NTP
servers 10 years ago. At that time it was 'required' that a stratum 1
clock was supposed to have a GPS, atomic or similar solid time. If you
are just relaying you are supposed to be a stratum 2 clock. If you are
the main clock for a large set of systems you should be a stratum 1
system. If you ran a dedicated system you wanted to have 3-5 systems
spread out.
For how the old way of doing things was
https://www.endruntechnologies.com/stratum1.htm
I expect with a large pool of stratum 2, the noise between them is
averaged out of over time lowering the need for a clock. I will go
look at current best practices and revise.
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
