broadcastclient ?

[Eric S. Raymond]

Dealing with somw older mail I've been meaning to get to.

Hal Murray <hmurray at megapathdsl.net>:
> 
> [moved from users@]
> 
> esr at thyrsus.com said:
> > That is correct.  Broadcast client mode has been removed because it is
> > impossible to secure. 
> 
> We really should have a single top-level file that covers all the simple 
> differences from ntp-classic.

It's a section on docs/index.txt.  I'm careful to keep it up to date.

> We should probably patch the parser to emit an error message with a pointer 
> to that file.  Or is the whole message (above) for this case simple enough 
> that we should include it inline?

I think it is.  Matt Selsky has been helpfully patching in some parse error
messages for removed features.

> Should that sort of trap fail to start?  Will users get surprised when they 
> miss the error message or annoyed when they know what to expect but they have 
> to work harder to try it?

I'm a big fan of failing noisily and early in circumstances like these.

That said. I don't think it matters very much whether ntpd terminates
immediately afterwards.  The important thing is that the parse error
is logged and/or visible on stderr right after startup; it should be made
easy to notice what has gone wrong.

Now that I think about it more, staying up in order to do time sync from
local clocks and unicast peers is probably the more useful thing.  You
probably wanted to do that even if your server config went sproing.

> I took a quick look at the code.  There is quite a bit of broadcastclient 
> cruft that didn't get removed.  Any reason not to nuke it?

No.  I think I've removed it all since you wrote it.

> What's the story on broadcast/multicast server mode?  If we don't have a 
> client, is there any reason for a server?

Mark thinks a lot of shops using Windows edge nodes rely on
broadcast-server.  So even if broadcast client is seldom or never used
in Unix-land (and Mark and I both think that is so) there is some
reason to support it.

I'm interested in your opinion about this (and I'm sure Mark will be
too), as you have a depth of operational experience I can't match by
trawling for evidence with a search engine.

I don't know whether or how long we'll keep brodcast-server support.
On the one hand, the additional complexity coast of broadcast server
is low. On the other hand, the client mode cannot be secured and there is an
argument that we shouldn't be encouraging people to maintain dangerous
practices.

All the multicast stuff is now gone, client and server side both. My
original plan was to keep multicast server just in case, though I can
find zero evidence anywhere of production use.  But it turned out to
be too entangled with things we wanted to drop.  Daniel's comment from
his infosec perch was "Good riddance."

I would have been more worried about dropping these things, but it
seems to me from search-engining the issue that to the extent
automatic server discovery was ever actually used in Unix-land, those
use cases have largely been taken over by pool-style DNS
round-robining.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>