I'm reading the current version of nts.doc in conjunction with the RFC.
Thanks to everybody who's been working on this; we're not far from the
point at which starting to write code makes sense.
I want to put arrows on the flow diagram.
I see no Bravo-to-Alpha initiation of requests, though there
Richard Laager via devel :
> docs/driver_local.adoc has a typo: disctplined
Fixed, thanks.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save
I have converted ENABLE_LOCKCLOCK to a runtime option. Following a
review suggestion, it is controlled by flag1 of the localclock driver.
Please test carefully. I think I avoided breaking the loopfilter
code, but there;s always that outside chance...
--
http://www.catb.org/~esr/"
Hal Murray :
> It's not obvious what the parameters are. Looks like the code sends back
> ntp_minpoll. Is that documented?
I don't think it is.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please
After staring at the code and reading some documentation, I've pushed
a fix for Achim's bug. I'm not certain it's optimal, but I'm pretty
sure that it fixes the pegged-interval problem and does no harm
otherwise.
The change comment describes both old states of the code and
documents the problem.
Hal Murray :
> Looks like the idea in the old code was to set the minpoll to the polling
> interval from the KoD packet.
>
> Looks like Daniel changed that to 10. I'd guess that's a hack defense
> against
> something worse from a forged packet. 10 seems safe for the server but not
> nice to
ntp_proto, line 518:
if(is_kod(rbufp)) {
if(!memcmp(rbufp->pkt.refid, "RATE", REFIDLEN)) {
peer->selbroken++;
report_event(PEVNT_RATE, peer, NULL);
if (peer->cfg.minpoll < 10) { peer->cfg.minpoll = 10;
Achim Gratz via devel :
> So again, a rate_exceeded event is logged and hpoll has moved up to 10.
> Note that both ntpq and ntpmon show the poll interval still as 16s and
> full reachability, which isn't true. Also, looking at the peer stats
> you'll see that the effective poll interval actually c
Gary E. Miller via devel :
> > Why are you fighting so hard for the reuse case?
>
> Because the Proposed RFC allows for it, so some will use it. We need to
> be interroperable. It may be useful for bad connections.
While I concded your point that we need to plan for interoperability, Gary,
I'm
Hal Murray :
>
> > Good to know. Yeah, NTP at that volume is sure not going to saturate even a
> > smartphone, let alone anything you'd put in a desktop or server case.
>
> I can get 20k pkt/s through a Pi 3.
So, to a reasonable first approximation, a RasPi 3 could handle PTB's
load with 50% h
Achim Gratz via devel :
> Answer from PTB: Current packet rate is still lower than 10k/s peak over
> all three servers. Not sure how well balanced that is, but I guess it's
> safe to say that it's less than 5k/s on each server.
Good to know. Yeah, NTP at that volume is sure not going to saturate
Udo van den Heuvel via devel :
> On 14-01-19 08:14, Mark Atwood via devel wrote:
> > NTPsec 1.1.3 has been released.
> > https://blog.ntpsec.org/2019/01/13/version-1.1.3.html
>
> Thanks.
>
> The pic directory in the source tree holds the panda.adoc file that
> should be located one level higher
Hal Murray via devel :
>
> I'm setup to test things and/or can be good at proofreading, but I don't know
> how to work with merge requests.
>
> I assume there is a simple way to pull them to my local setup. How do I undo
> that if I don't like it?
The MR should have "Check out branch" tha pop
Hal Murray via devel :
> The draft has links to two chunks of software.
> https://gitlab.com/MLanger/nts/
> https://github.com/dfoxfranke/nts-hackathon
>
> I started with the second one. It's written in python, looks good. But it's
> client only.
>
> So I looked at the first one. It's c++
This is good feedback. Exactly the sotrt of thing that should come up
in review.
Richard Laager via devel :
> On 1/12/19 8:10 AM, Eric S. Raymond via devel wrote:
> > Please review and test.
>
> Can you please post this as a merge request, so we can use GitLab
> comme
Please review and test.
--
http://www.catb.org/~esr/";>Eric S. Raymond
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.
>From d244049234e3ae7ed7fcde9f19ac0447cc231e9b
Hal Murray :
>
> >> If we are serious about supporting lockclock, we have to figure out a way
> to
> >> test it. We can probably make something that supports GPSDOs with PPS.
>
> > That, on the other hand, seems to me like a good idea. But I don't have the
> > domain expertise to do it.
>
> I
Hal Murray :
>
> e...@thyrsus.com said:
> > Not only is it possible, I wrote a patch to do it today. Complete with
> > documentation changes. I'll post it shortly - I want it carefully reviewed
> > and tested by others before we merge it, as it touched the loppfilter code.
>
> Are you planning
Achim Gratz via devel :
> > The biggest problem with any attempt to break up ntpd into multiple
> > separate programs is that it would almost necessarily force changes in
> > the way NTP configuration works that would be (a) user-visible, and
> > (b) not backward compatible. The only ways around h
Achim Gratz via devel :
> Hal Murray via devel writes:
> > devel@ntpsec.org said:
> >> It doesn't recover at all (well, not over the course of two weeks, that was
> >> the longest time I watched it without restarting) and there is no code I
> >> could find that would allow it to recover. I'm almos
Gary E. Miller via devel :
> "Eric S. Raymond via devel" wrote:
>
> > That doesn't seem to me like it's going to load a modern processor a
> > lot. Even my RasPis could handle that action.
>
> I have a RasPi in the ntp pool. Typically around 200 kbps
Hal Murray via devel :
>
> devel@ntpsec.org said:
> > Is it possible to make lockclock a run-time-only option, instead of a
> > compile-time + runtime otion?
>
> I think so. That will require adding something to ntp.conf to turn it on.
Not only is it possible, I wrote a patch to do it today. C
"CCured: Type-Safe Retrofitting of Legacy Software"
https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf
This article describes CCured, a program transformation system that
adds type safety guarantees to existing C programs. CCured attempts to
verify statically that memory errors can
Gary E. Miller via devel :
> Yo Matthew!
>
> On Fri, 11 Jan 2019 17:44:42 +
> Matthew Selsky via devel wrote:
>
> > Is it possible to make lockclock a run-time-only option, instead of a
> > compile-time + runtime otion?
>
> I'd love to get rid of every compile time option. They confuse
> d
Hal Murray via devel :
>
> Gary said:
> > The client does not update his cookie(s), he just asks the NTS-KE for new
> > ones when the NTPD NAKs the one he has been using.
>
> Not quite. An important idea is that cookies are only used once. That
> prevents bad guys from tracking you.
>
> In t
Achim Gratz via devel :
> Mark Atwood, Project Manager via devel writes:
> > Everyone, please chime in, let me know if you think No Go or otherwise have
> > concerns.
>
> I want to mention that the bug (and regression w.r.t. NTP classic) I
> reported that effectively drops configured servers by ch
Hal Murray :
>
> Eric said:
> > Heh. I've been pretty ruthless about dropping every line of code I could.
> > Did it occur to you to wonder why I hadn't already nuked this?
>
> > It's because the only way this code makes any sense to me is if at one point
> > NIST was running NTP Classic on the
Achim Gratz via devel :
> By the end of 2016 the request rate grew to about 7000 per second (not
> specified which server, so I assume for all three). The paper didn't go
> into any further details of the NTP service.
OK, then, say, 2.5K requests per second per server. That means to stay ahead
o
Achim Gratz via devel :
> I could try to contact the responsible person for NTP at PTB if you
> can't get at information from NIST.
Probably a good idea to have PTB figures even if we *can* get some from NIST.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by th
Hal Murray :
>
> Eric said:
> > I concur. I would need to see actual measurements before I've convinced
> > that
> > ntpd with even a thosand client connections is a performance-degrading
> > load.
>
> I think there are two cases: popular public servers like NIST and everybody
> else.
>
> I
Gary E. Miller via devel :
> Yo All!
>
> I do not like this in nts.adoc:
>
> 4 boxes. My ASCII art is weak. C for client, S for server.
>
>Bravo Delta
>NTS client NTS server
> | |
>Alpha
Gary E. Miller via devel :
> As for Alice and Charlie, please pick previously unused first names.
> Alice and Charlie are standard terms of cryptography, but are being used
> differently here in a confusing way.
I don't see this as a real problem. If you do, feel free to edit.
--
Sanjeev Gupta via devel :
> Interface is 100Mbps
> ntpsec is the only network service on the machine. gpsd runs locally
> CPU load is under 3%
> Hardware is a dual-core Pentium 4, 2800MHz, from about 2006
> Network traffic is under 100kbps
> PPS is about 500/s, RX is 10% more than TX
>
> Current
This email is an attempt to bring together two different discussion
threads, one that I've been having with Hal Murray via private email and one
on signal chat.
We have our SOW from Cisco. It's time to get serious about
implementing NTS.
Everybody who hasn't hasn't should read the NTS draft:
ht
Achim Gratz via devel :
> > Anyway, I think that thinking about them as separate parts will help our
> > discussions.
> > We should be able to improve performance on busy servers.
>
> It's been decades since I looked at an NTP server that has enough
> clients to make me wonder about performance,
Gary E. Miller via devel :
> Yo Hal!
>
> On Sat, 05 Jan 2019 01:25:57 -0800
> Hal Murray via devel wrote:
>
> > The current code is a combined client and server. I think we should
> > split that into separate programs. Maybe not right away, but we
> > should at least start thinking that way.
>
Hal Murray via devel :
>
> The current code is a combined client and server. I think we should split
> that into separate programs. Maybe not right away, but we should at least
> start thinking that way.
>
> The server side is simple. It gets time from the system. There are a few
> other p
Gary E. Miller via devel :
> Lockclock mode is very important to the PTP people. They use PTP to
> distribute time on the local net to the clients. Then a PTP client can
> use NTP to server time to not PTP clients.
While I have no doubt you are correct about the PTP deployment, I see hints
in th
Hal Murray via devel :
>
> Context is Issue #524, NTPsec daemon hangs after startup
>
> The problem is that if configured with --enable-lockclock, ntpd doesn't work
> as a server if you don't activate the local clock driver in your ntp.conf.
> (It doesn't work as a client either.)
>
> ---
Matthew Selsky via devel :
> > What do you think of this policy?
>
> That still makes this table a maintainence headache. Can we instead say that
> we built on modern/supported-by-upstream releases of popular operating
> systems and distributions. And we build test on the platforms supported b
Hal Murray via devel :
>
> We need a mechanism to review/update things occasionally and a list of things
> that need occasional review.
>
> Here is a starter:
> https://www.ntpsec.org/supported-platforms.html
> Under test status, it says:
> Fedora 26 and 25 (i686, x86_64)
> and lots more.
>
Gary E. Miller via devel :
> ntpmon should not required, but very strongly encouraged. So test for
> pythong curses, complain loudly when not found, but do not fail at that
> point.
+1
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Enginee
Hal Murray via devel :
>
> Eric said:
> >> So what we have is a run-time problem, not an install time problem.
> > Alas, I have to agree with this.
>
> Would you please say more. I don't see any problem.
As Gary pointed out, sometimes having multiple copies installed is deliberate.
--
Gary E. Miller via devel :
> So what we have is a run-time problem, not an install time problem.
Alas, I have to agree with this.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site
Hal Murray via devel :
> The old buffer allocation pool is still there. That could be cleaned up.
>
> refclock_generic still calls get_free_recv_buffer
> There are 2 calls in ntp_io
> I think they could be replaced by chunks on the stack or globals.
>
> Checking/understanding the data input path
Ian Bruene via devel :
>
>
> On 10/30/18 3:32 PM, Mark Atwood, Project Manager via devel wrote:
> > Looks straightforward enough. Ian?
>
> Will look into in a little while.
Invoke me if you run into trouble, but this should be pretty sreaightforward.
--
http://www.catb.org/~esr
James Browning via devel :
> I assume you mean something probably not quite completely unlike.
> * NTS-ke will require listening to a TCP port (possibly 123) and spinning
> up a new thread for each client. (or risk blocking the process)
> * NTS-ke willl require hooks to automtical reconfigure a cur
Ian Bruene via devel :
> I'm told that there is a document written by the resident crypto expert
> describing NTS. Does anyone have it? We might need to see it if we are
> planning on implementing what is in it you know...
We don't just need a description of NTS is, we need an interface contr
Hal Murray :
>
> > # Requests are automatically retried once, so total timeout with no
> > # response is a bit over 2 * DEFTIMEOUT, or 10 seconds.
>
> Thanks. That sounds reasonable, but I can't translate that into what I'm
> seeing.
>
> Did you check the code? Does it bail on the second tim
Hal Murray via devel :
>
> Anybody familiar with the retransmission code?
I think I'm the only person who has touched it.
> It seems to hang occasionally. A wild guess, there is some backoff code in
> there that increases the retransmission timer. That's good. I'm guessing
> that my problem
Richard Laager via devel :
> On 09/18/2018 05:04 PM, Richard Laager wrote:
> > I'm doing some digging, and from what I can see Debian/Ubuntu added
> > support for shared linking Go libraries and then removed it a couple
> > years later. I'm asking in IRC to try to get a more
> > conclusive/authorit
Paul Theodoropoulos via devel :
> Uniformity of presentation seems like a desireable goal - are there any
> objections to following these particular guidelines?
Not fro me. Go to it.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineeri
Apologies for the daelay on this. Blame it on the Venusian Death Flu.
We have several tasks in front of us on NTPsec. I want to get some
consensus from the tech team, and a strategy call from Mark, on how to
priority-order these things.
1. NTS
We have a funding offer from Cisco.
Blocker: To mo
Gary E. Miller via devel :
> Yo Eric!
>
> On Thu, 30 Aug 2018 15:35:46 -0400
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > I'm seeing something new and odd with NTPsec git head. When I kill
> > > the old ntpd to start a new one, this is in my logs:
> > >
> > > [834374.55966
Gary E. Miller via devel :
> I'm seeing something new and odd with NTPsec git head. When I kill
> the old ntpd to start a new one, this is in my logs:
>
> [834374.559668] ntpd[8904]: segfault at 88 ip 5581071fb466 sp
> 7fff53c460c0 error 4 in ntpd (deleted)[5581071c2000+7f000]
That is n
Hal Murray :
> > Moving to a single select. Daniel wants this for the NTS work.
>
> Please say more. How many selects are there currently?
Three. The two of interest are for network sockets and refclocks.
Also, we want to elminate once-per-second time ticks and move to an
event-queue-based arch
Ian Bruene via devel :
> On 08/29/2018 01:26 PM, Eric S. Raymond via devel wrote:
> > Those projects do tend to blur tigether in my mind.
> > You were planning to do quue removal at one point. Is that still on
> > your list?
>
> I've poked at both of those over th
Hal Murray :
> > Oh good. I can get to serious work on the ntp_io.c refactoring now.
>
> What do you have in mind?
Moving to a single select. Daniel wants this for the NTS work.
Mark wants filter-by-interface featurectomied.
> There is also the queue removal cleanups, but that's in ntpd.c rath
Hal Murray :
> It makes us look sloppy. We worked hard to get (almost) no warnings. We
> should maintain that reputation.
And we will. But I'm reluctant to turn off -Wformat; that treats a symptom.
not the problem, and might supress real bug warnings.
I think eliminating the warnings can wait
Hal Murray via devel :
>
> systemd has the option to support code that doesn't fork/daemonize. Taking
> advantage of that could clean up some of our code.
>
> That would break the -w option.
>
> Of course, this doesn't work on systems that don't have systemd. Is there a
> commonly used way t
Hal Murray via devel :
>
> What's the story?
>
> I'm catching up after being off line for several weeks. I updated a NetBSD
> box to 8.0 and now it produces lots and lots of warnings that I expect would
> get fixed before a release.
>
> Most are complaining about %m. Sample:
> ../../libntp
Richard Laager via devel :
> On 08/17/2018 11:56 AM, Eric S. Raymond via devel wrote:
> > There has been some minor debubbling surgery done on the master
> > branch. To avoid problems,
> How far back did this change go? Does this affect tags for previous
> releases, for examp
There has been some minor debubbling surgery done on the master
branch. To avoid problems,
git reset --hard 163297
and re-pull from the public repo.
--
http://www.catb.org/~esr/";>Eric S. Raymond
...Virtually never are murderers the ordinary, law-abiding people
against whom gun
MIKE MAJOR via devel :
> The first edits I propose are to massage the TOC indentations and add section
> numbers.
>
> First, the TOC indentations. The major sections should not be indented. By
> major section I mean mainly the phases called out like Early Configuration,
> Smoke-test the SBC/HA
Gary E. Miller via devel :
> Yo James/Eric!
>
> Looks like MR 748 broke BSD. See below.
Well, shit. Reverting gives me this:
esr@snark:~/software/ntp-rescue/ntpsec$ git revert
1b8554c85b2c292c94b00aab5d3596d78530b230
error: could not revert 1b8554c85... add new -d option to ntpfrob
hint: afte
Richard Laager :
> I would delete the piece of the comment that I quoted.
>
> If you're asking whether the PYTHONDIR -> PYTHONARCHDIR change breaks
> CentOS, I have no idea, but that is immaterial. That code change was
> made, so the comment should be updated to match the current reality of
> the
Richard Laager via devel :
> Side note: when this was changed, the comment in libntp/wscript was not
> updated to match the code change.
>
> Current:
> # In theory this should use PYTHONARCHDIR, but that doesn't work on
> # CentOS (at least), for some as-yet-undetermined reason. On most
>
I've been bug-stomping a lot recently. We're down from 23 issues to
13, 12 once Ian finishes work on Hal's most recent RFE. None look
like blockers to me, it's been about three months, and the
data-minimization implementation makes a good headline feature.
That says to me that it's time for anoth
James Browning via devel :
> On Thu, Aug 9, 2018, 5:55 AM Udo van den Heuvel via devel
> wrote:
>
> > Hello,
> >
> > Why is NTP in uppercase?
> >
> > statistics directory /var/NTP/ does not exist or is unwriteable, error
> > No such file or directory
> >
> Probably because someone typod it wrong
MIKE MAJOR via devel :
>
>
> On Wednesday, August 8, 2018 12:01 AM, Gary E. Miller via devel
> wrote:
>
> On Wed, 8 Aug 2018 03:15:54 + (UTC)
> MIKE MAJOR via devel wrote:
>
> >> In the HOWTO section "Live-test the GPS", the reader is instructed to
> >> build gpsd using: $scons tim
Paul Theodoropoulos via devel :
> Good catch. I thought that I had corrected that in one of the diffs I sent
> to ESR, but I only compounded the incongruity. You are correct - the
> libncurses5-dev Debian package is required. I can throw a diff at Eric now -
> or if he's 'watching' perhaps he'll pu
MIKE MAJOR via devel :
> Thank you for the opportunity to learn and to help out. I am quite looking
> forward to it. I believe I have found the end of the firehose and have begun
> to drink. :)
I will await your patch submissions with interest.
--
http://www.catb.org/~esr/";>Eri
Paul Theodoropoulos via devel :
> I'm unclear here. All the Etcher app does is burn the bare image to the sd
> card. I'm not suggesting eliminating the cli instructions for doing so,
> just a small optional component that can shave a chunk of effort cli that
> isn't really 'reusable' in the rest o
Paul Theodoropoulos via devel :
> I don't disagree. My thinking is more along the lines of _formatting_ than
> anything else. The page is very bare in most respects, and at times it's
> fatiguing to be piecing through part of it, and not having a visual anchor
> to hold onto as you switch between h
Paul Theodoropoulos via devel :
> On 7/30/18 20:46, Gary E. Miller via devel wrote:
> > We found a lot of people that wanted a cheap stratum 1 had not clue
> > how to get a RasPi to work. Thus the completer instructions.
> ...
> > Please do. Especialy with a fresh eye. We dont know what newbies
Hal Murray via devel :
> Would somebody please eyeball these changes. Thanks.
>
> - unsigned char rnd[sizeof(uint32_t)];
> - RAND_bytes(rnd, sizeof(rnd));
> - return (int32_t)ntp_be32dec(rnd);
>
> + int err;
> + uint32_t rnd;
> + err = RAND_bytes((unsigned cha
John D. Bell :
>
> Gentlemen,
>
>
> *Years* ago I used to use yacc, but I quit before bison became the
> _de-facto_ standard. Thus, upon reading its man page I was surprised
> and pleased to see the following command-line options available:
>
> --debug
>
> --report=THINGS
>
> THINGS
Hal Murray :
>
> e...@thyrsus.com said:
> > If we had introspection in the target language we would automatically get
> > the
> > entire parse structure when we dumped each syntax tree, rather than an
> > ad-hoc
> > representation that's mostly leaf nodes. We would also get things like
> > dump
Hal Murray :
>
> e...@thyrsus.com said:
> > I thought about that back when I was looking at this code. Concluded it
> > wouldn't be that useful to (effectively) just dump the input tokens with a
> > slightly different syntax.
>
> How else would you check/test a parser?
If we had introspection
Ian Bruene via devel :
> I need to sanity check this first: Am I correct in thinking that tests
> should be arranged as 1 file of tests corresponds to 1 file of code, rather
> than the test files corresponding to this or that concept which is scattered
> over various source files?
That's a good ru
Gary E. Miller via devel :
> Git relatively new to all of us.
>
> > ESR suggested I perform a 'pull', and request that Gary have a look
> > at it. Herewith. I've probably overlooked some other step, but
> > perhaps not.
>
> 'git pull' just gets you an up to date copy of the master repo. Then
> y
Hal Murray :
>
> e...@thyrsus.com said:
> > What I think one needs for a test harness is the ability to dump the parse
> > tree structure in a textual form. Changing parser generators won't give us
> > that. What really matters is whether our target language has introspection
> > capability and d
Richard Laager via devel :
> On 06/19/2018 01:27 AM, Hal Murray via devel wrote:
> > Currently, we require Bison in the build environment. We don't really need
> > that. We only need Bison to run on some system we have access to. Then we
> > could treat the output as source and put it in git.
Hal Murray :
>
> Eric said:
> > The problem with the new-parser-generator theory is that as much fun as I'd
> > have doing it, the net effect on stability and maintainability would
> > probably
> > be negative. There's that how-do-you-know-you-specced- the-same-grammar
> > problem again.
>
> A
Hal Murray via devel :
>
> Gary said:
> > In a perfect world someone rewrites ntp_parser.tab.c in a modern language.
>
> What are the options in that area?
Not so great. Nothing but Bison really makes strategic sense.
(Hey, Ian! Pay attention. Lore of some significance about to be spoken.)
Hal Murray :
>
> devel@ntpsec.org said:
> >> It only generates warnings on a few systems. I don't see why not
> >> on the others. ??
> > I looked at the code. Noting mysterious or suspcious there; has to be some
> > kind of compiler version-skew issue.
>
> Or a glitch in my brain.
>
> I'm s
Hal Murray via devel :
> This one looks more complicated:
> ntp_parser.tab.c:1469:3: warning: switch missing default case
> [-Wswitch-default]
> It only generates warnings on a few systems. I don't see why not on the
> others. ??
I looked at the code. Noting mysterious or suspcious there; has
Gary E. Miller via devel :
> Until the big boys decide what to do with openssl, maybe we should avoid
> getting in the middle?
Concur. It's not like our local copies are costing us much bulk.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil E
Gary E. Miller via devel :
> Not sure what that all means, much of it is junk, but a couple of eye openers
> in there.
I can make sense of almost all of those, and I agree.
One reason to consider dropping Python 2 support is so we can use the Python 3
type-annotation syntax.
--
h
Gary E. Miller via devel :
> > Do any of our current targets not support Python 3?
>
> I think all our current targets support 2 and 3. But these frequently
> break.
Nothing but the last LTS of Fedora still fails to support Python 3.
I think it's almost time to pull the trigger and drop Python
Hal Murray via devel :
> I occasionally add msyslog lines when debugging. The DPRINTF stuff isn't
> interesting - too much junk I don't want. When I'm cleaning up, should I
> disable them with "if (0)", or delete them? Is there a better way? ...
What I do is delete them unless I think they m
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 | igno
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.
--
http://www.catb.o
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
> /etc/default/ntp... no big deal. As long as I get a deprecation warning, etc.
T
Hal Murray :
> > I want to do a triage pass over the bug list. That's about it.
>
> There is a RFC close to release that requires some changes in the crypto
> area. Gary forwarded the announcement few days ago. I'll dig out the
> details if anybody can't find it.
>
> They aren't complicated.
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 timing
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 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 t
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 on
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.
--
http:
401 - 500 of 866 matches
Mail list logo
