SINGLESOCK - How much to strip away?

[Mark Atwood]

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.

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.

..m

On Thu, May 31, 2018 at 9:55 PM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> Ian Bruene said:
> > 1. Stop using work queue. Handlers are called directly by the receivers.
> > 2. Remove work queue checking by mainloop()
>
> The receive loop is several layers down.  The handler dispatching is up in
> the main loop.
>
> You may want to move the receive loop up to the main loop rather than
> moving
> the handler dispatching down to someplace obscure.  Whatever looks best
> after
> you find all the tail.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20180601/69b96470/attachment.html>