Mark Atwood via devel <devel@ntpsec.org>: > I still want to strip it all and delegate it to iptables, case OMEGA. > > But I do understand the pushback against that from GEM, and have been > thinking about it for the past few days. > > As I type and think: one of the fundamental problems with having longrunner > daemons try to keep track of addresses, address masks, and interface names > is that interfaces can go down, come up, get renamed, and have address > masks added and removed from each, and trying to keep track of that in > userspace is a nightmare. Sysadmins are used to having to bounce a > database server when listener interface has an address event, but bouncing > ntpd is much less okay.
That - "bouncing ntpd is much less okay" - is a telling point that hadn't occurred to me. I'm not much of an admin and am not used to having to handle these large-site problems. Please everyone bear that ignorance in mind; it may mean you need to beat me over the head with facts you think are obvious. > As I type and think more, I ask, "What does Chrony do?", and I look at [ > https://chrony.tuxfamily.org/doc/3.3/chrony.conf.html]. It has a > "bindaddress" directive, which uses IP address, not interface name. And > only one bind address can be specified. It freely admits that that means > Chrony is not the correct solution for serving down multiple controlled > interfaces at once. Very simplifying, but not what we want. > > This reinforces my decision. Rip it. Maybe in the future we can carefully > build back up to case Gamma. I thank you *very much*, Mark. This kind of firm leadership on the product-strategy level makes it easier for me to do my job, and I appreciate that a lot. I'm hearing assent to this direction from Hal and me, and a slightly qualified assent from Gary. I hope we hear from Matt, too. I'm going to take this as direction to start by ripping out the interface directive in ntp.conf; that's orthogonal to the rest of this mess because it's restrictive and default behavior without it won't change. We can deal with -I and -L and multi-binding behavior in a later step. I'm inclined to think we ought to scrap -I and -L and support a bindaddr directive (to make the chrony fans happy) allowing multiple IP addresses (to make Gary happy :-)). But we don't need to commit to that decision yet, and I need to understand virtual IPs (that is, why -L differs from -I) better before we do. There's an implementation issue with SINGLESOCK. We can't actually go to single socket unless we can get the source address of a packet, so we know where the other end of the association is. IP_PKTINFO turns out not to be fully portable. (It is disturbing that some BSD man pages falsely claim to support it.) I've turned up the following, at https://k5wiki.kerberos.org/wiki/Portability_research This table combines their table with the footnotes. Platform IPV6_PKTINFO IPV6_RECVPKTINFO IP_PKTINFO Linux 2.6.32 yes yes yes Solaris 10 yes yes no Solaris 11 yes yes yes FreeBSD 8.1-1 yes yes no* Hurd-0.3 yes no no OSX 10.9 yes yes yes AIX 6.1 yes yes no HP-UX B.11.11 yes yes no NetBSD ? ? yes (2013) * FreeBSD still does not implement IP_PKTINFO, but implements an alternative using IP_RECVDSTADDR. It looks like we're OK (wrapper code that uses the FreeBSD alternative should be trivial) but I think testing on our target platforms is indicated before we commit to this. Hal, can you check the assertion about FreeBSD? Do we have a NetBSD system to test on? -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
