Yo Hal!
On Tue, 05 Jun 2018 14:56:18 -0700
Hal Murray wrote:
> Gary said:
> > But in the case of ntp.conf, the 'interface' is taking IPv4
> > addresses, IPv6 addresses, and hostnames. So the ntp.conf
> > 'interface' has nothing at all like an interface. It is an
> > address.
>
> Are you
Hal Murray :
>
> e...@thyrsus.com said:
> > I thought interface was restrictive rather than additive - I've never seen a
> > configyration that uses it. I'll look into this; it might be that parts of
> > it shouldn't be removed.
>
> I think it is both. The first parameter can be "listen |
e...@thyrsus.com said:
> I thought interface was restrictive rather than additive - I've never seen a
> configyration that uses it. I'll look into this; it might be that parts of
> it shouldn't be removed.
I think it is both. The first parameter can be "listen | ignore | drop".
The default
Gary said:
> But in the case of ntp.conf, the 'interface' is taking IPv4 addresses, IPv6
> addresses, and hostnames. So the ntp.conf 'interface' has nothing at all
> like an interface. It is an address.
Are you sure about that?
I think that "name" in that context refers to an interface name
Matthew Selsky :
> What does a "bindaddr" keyword get us that "interface" doesn't?
I thought interface was restrictive rather than additive - I've never
seen a configyration that uses it. I'll look into this; it might be that
parts of it shouldn't be removed.
--
Yo Eric!
On Tue, 5 Jun 2018 05:20:56 -0400
"Eric S. Raymond via devel" wrote:
> Matthew Selsky :
> > interface listen 127.0.0.1
> > interface listen ::1
> > interface listen address
Oh, I'm starting to see the confusion. The terminology in ntp.conf
is just wrong. I should have checking the
Yo Matthew!
On Tue, 5 Jun 2018 15:02:38 +
Matthew Selsky via devel wrote:
> On Tue, Jun 05, 2018 at 05:20:56AM -0400, Eric S. Raymond wrote:
> > Matthew Selsky :
> > > I guess I'll replace -I with this in ntp.conf:
> > >
> > > interface listen 127.0.0.1
> > > interface listen ::1
> > >
On Tue, Jun 05, 2018 at 05:20:56AM -0400, Eric S. Raymond wrote:
> Matthew Selsky :
> > I guess I'll replace -I with this in ntp.conf:
> >
> > interface listen 127.0.0.1
> > interface listen ::1
> > interface listen address
> >
> > This means that I'll need to template /etc/ntp.conf instead of
On Wed, May 30, 2018 at 03:08:42PM -0400, Eric S. Raymond wrote:
> Matthew Selsky :
>
> > We also use "-I address" on multi-homed hosts to attempt to ensure
> > that ntpd is only listening on the private side and is not even
> > bound to the port on the public side.
>
> Do you also use filter
> Hal, can you check the assertion about FreeBSD? Do we have a NetBSD system
> to test on?
>> I can't think of why we actually need it. I would have to scan
>> the code to look.
> If you have the bandwidth, please do check that premise.
I really want to get away from the SINGLESOCK stuff
>> Maybe we should make a plan with a list of changes that
>> all have to get done before we can do another release.
> I want to do a triage pass over the bug list. That's about it.
Sorry I wasn't clear. I was thinking of releasing SINGLESOCK. Can we
release it in pieces or should we
Hal Murray :
>
> e...@thyrsus.com said:
> > 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 should consider the
Hal Murray :
> Are you trying to say that we can drop the interface tracking if we switch to
> listening on a single wildcard socket? (If so, I'd missed that in any
> previous discussions.)
Yes. I did say that before - it's the main reason I think SINGLESOCK
needs to be done early, in order
e...@thyrsus.com said:
> Isn't such state retention something that should be keyed by server IP
> address? I don't really see how the interface can be relevant.
Yes, there is state for each server ntpd is using stored by the server's IP
address.
Currently, part of that state is the interface
e...@thyrsus.com said:
> 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 should consider the timing on this. Do we want to
Hal Murray :
> > I don't undetstand why the tracking is needed.
>
> If an interface goes away, you want to forget all the state you have for
> servers that was collected using that interface.
Isn't such state retention something that should be keyed by server IP address?
I don't really see how
Gary said:
> You may say that can be duplicate in your firewall settings. But maybe you
> want to run two ntpd ...
I assume firewalls are smart enough to allow different rules for different
servers.
"firewall" is potentially ambiguous in this discussion. It could refer to a
package running
Yo Eric!
On Sat, 2 Jun 2018 15:08:52 -0400
"Eric S. Raymond" wrote:
> > You may say that can be duplicate in your firewall settings. But
> > maybe you want to run two ntpd, one leap smeared, one normal. And
> > you want to put one on one interface/address, and the other on
> > another
> I don't undetstand why the tracking is needed.
If an interface goes away, you want to forget all the state you have for
servers that was collected using that interface.
--
These are my opinions. I hate spam.
___
devel mailing list
Gary E. Miller via devel :
> Yo Eric!
>
> On Sat, 2 Jun 2018 10:27:05 -0400
> "Eric S. Raymond via devel" wrote:
>
> > Hal Murray via devel :
> > > One interesting case is the home user. Roughly, they don't have
> > > sysadmins and they only have one interface. (Laptops might have
> > > both
Hal Murray :
>
> [Home case - no admin]
> > For them, just defaulting to listen on the wildcard address is OK. I think.
> > Am I missing something?
>
> I think the listen part is simple. We still need to track interfaces.
I don't undetstand why the tracking is needed.
--
Yo Hal!
On Sat, 02 Jun 2018 00:38:36 -0700
Hal Murray via devel wrote:
> We still have the restrict stuff. They are pretty powerful. If you
> are willing to translate interface names to IP Address ranges, I'll
> bet they can cover many/most cases.
Almost, but not quite, sufficient. ntpd
Yo Eric!
On Sat, 2 Jun 2018 10:27:05 -0400
"Eric S. Raymond via devel" wrote:
> Hal Murray via devel :
> > One interesting case is the home user. Roughly, they don't have
> > sysadmins and they only have one interface. (Laptops might have
> > both WiFi and Ether, but I'll bet somebody turns
[Home case - no admin]
> For them, just defaulting to listen on the wildcard address is OK. I think.
> Am I missing something?
I think the listen part is simple. We still need to track interfaces.
--
These are my opinions. I hate spam.
___
Hal Murray via devel :
> One interesting case is the home user. Roughly, they don't have sysadmins
> and they only have one interface. (Laptops might have both WiFi and Ether,
> but I'll bet somebody turns off WiFi if the Ether gets plugged in.)
For them, just defaulting to listen on the
Mark Atwood via devel :
> 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
>
Richard Laager via devel :
> On 06/01/2018 10:06 PM, Mark Atwood via devel wrote:
> > 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
fallenpega...@gmail.com said:
> I still want to strip it all and delegate it to iptables, case OMEGA.
I'm happy with that. It may not be my first choice, but it's a decision we
can all understand and get back to work.
Thanks.
Eric said:
> Case OMEGA:
> -I, -L, and the interface config
Richard Laager said:
> FWIW, for me, at least, the typical cases for daemons are:
> A) bind to localhost only (preferably at least ::1, else 127.0.0.1)
> B) bind to everything (with additional control happening in the kernel)
ntpd has 2 cases.
A) Client only - leaf node on the tree.
On 06/01/2018 10:06 PM, Mark Atwood via devel wrote:
> 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
Yo Mark!
On Fri, 1 Jun 2018 20:06:44 -0700
Mark Atwood via devel wrote:
> But I do understand the pushback against that from GEM, and have been
> thinking about it for the past few days.
I'm all for iptables, or at least the modern equivalent. But iptables
does not adress the issue of binding
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,
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
On 05/30/2018 02:45 PM, Hal Murray via devel wrote:
It can be done in two steps. First is to dump the work-queue but still make
each packet get a buffer from the free queue and go back there. The second
is to remove the free queue.
Looking at the code, I believe this is the proper action
Hal Murray :
> > What makes it a better idea to wait?
>
> I don't see any clean solution.
>
> There are actually two separate areas. One is a single socket. The other is
> interface tracking.
>
> FreeBSD doesn't support single socket.
>
> The interface cleanup gets tangled up with cleaning
> What makes it a better idea to wait?
I don't see any clean solution.
There are actually two separate areas. One is a single socket. The other is
interface tracking.
FreeBSD doesn't support single socket.
The interface cleanup gets tangled up with cleaning up the UI. I don't see
any
Hal Murray:
>As much as I'd like to clean up this area, I think we should put it on the
>back burner for now.
What makes it a better idea to wait?
>There is a slightly related area that needs cleaning up. There are no
>externally visible impacts so there is no reason not to do it. I don't
Matthew Selsky :
> We use "-L" on hosts with hundreds of virtual IPs to avoid errors
> about "out of file descriptors".
I see. OK, that problem would go away under SINGLESOCK - just one socket
for all IP addresses.
> We also use "-I address" on multi-homed hosts to attempt to ensure
> that ntpd
As much as I'd like to clean up this area, I think we should put it on the
back burner for now.
Maybe we should put a note in devel/ with a summary of what we have learned.
Actually, I'd like to see a class of notes there. We should use this as a
good example. I'm interested in things that
On Wed, May 30, 2018 at 05:11:23AM -0400, Eric S. Raymond via devel wrote:
> >If you were an admin and wanted to take packets from the red cable and
> >ignore packets from the blue cable, how would you set things up? Would you
> >filter by interface name or IP Address?
>
> Ask a large-site
Hal Murray :
>
> e...@thyrsus.com said:
> > >Is there a clean way to get notified when an interface comes or goes?
> > Yes, that's what routing sockets gives you - notification when there's a
> > routing change. (I don't understand the details well, but this seems to be
> > the big picture.)
>
e...@thyrsus.com said:
> >Is there a clean way to get notified when an interface comes or goes?
> Yes, that's what routing sockets gives you - notification when there's a
> routing change. (I don't understand the details well, but this seems to be
> the big picture.)
Are routing sockets
(Consolidating replies to three messages.)
>recvmsg() gets you the interface index, not name. If you want to filter by
>name, you have to maintain a index to name array. Doing that once is
>probably reasonably clean. Keeping it up to date might get interesting.
You're talking about case ALPHA
Focusing on the single in SINGLESOCK...
That doesn't work in FreeBSD. (see my previous message about no IP_PKTINFO)
Is that fatal?
Even if we have a single socket, do we still need to track interface changes?
If so, should we be discussing how to clean up that code?
---
The
We can filter by IP Address using the restrict command. We may have to add a
new flag that says don't poke any holes in me.
Case ALPHA:
> Nothing visible changes. Packet filtering by interface name is still
> supported by using IP_PKTINFO to get the interface of incoming packets.
The discussion of how to do SINGLESOCKET has become rather splintered.
This is an attempt to pull it back together by presenting different
scenarios about how to do it.
In all scenarios, the per-interface sockets go away; all UDP listening
is done on what is now the wildcard socket.
Case ALPHA:
46 matches
Mail list logo
