Re: ISC's EoL dhcp suite, including dhcpd

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 25 Jun 2025 20:40:19 -0700
    From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
    Message-ID:  <202506260340.55Q3eJIu006828%server.cornerstoneservice.ca@localhost>

  | } I think we should just drop isc-dhcpd from the base system and let
  | } users install a DHCP server package if they want.

I disagree, particularly about that one - a site needs one of two
things to be able to "install a DHCP server package if they want".
They either need to have a DHCP server already (in which case they
probably don't really want it, and whether it is there or not,
unconfigured, and not enabled, is irrelevant) or they need someone
knowledgeable enough about network setup to configure everything
manually.   That second one is becoming rarer.

A dhcp relay is even more likely to be needed, it allows any NetBSD
host with 2 (or more) interfaces to configure itself as a router,
and connect one stub lan to the main one - but for that to work,
dhcp requests on the stub lan need to be relayed (and the responses
returned) to whatever dhcp server is on the main LAN.

So, while replacing dhcpd with something else is certainly an option,
removing it isn't.   "How do I fetch package whatever?"  Just "pkg_add..."
(or whatever method you prefer to suggest".   But that says "network
unreachable".   "What does your network configuration look like?"
"My what?" ...   What is needed is to fetch a dhcp server, but to do
that the network needs configuring, which really needs a dhcp server.
The perfect illustration of a catch-22.   If you don't need it, you
can have it, if you need it, you don't qualify to get it.

  | Personally, I would be inclined to remove all servers from base.

I wouldn't.   If anything I might add more - but they only need to be
basic ones, not with every imaginable frill - as an example, bogohttpd
is an ideal HTTP server to include, but probably isn't what you'd want
to be running if you're making a fully fledged web server.   But it works
well enough to serve HTML versions of man pages (etc) to browsers running
on local tablets or phones (or even TVs) (and more than that).

  | Very few machines actually need to provide services to other
  | machines.

That's certainly true, very few machines need scsi, or most of the LAN
cars drivers we support, or all kinds of other stuff that (I hope) we're
never going to drop.   The point is that some do, it doesn't need to be
many - but that whatever your system needs (unfortunately, unless it is
very new) NetBSD is just going to have it, is one big feature.

I don't want to go the route of many linux distributions, where they assume
that the only thing the user really needs is a browser, and just maybe,
some kind of file manager, and just about everything else can be shoved
off to some external backage, that when a user used to some command tries
to run it, just gets told they need to add package pqr first.   And that
is for servers as well as more trivial applications.

  | (not to mention, much easier to keep up to date).

Why?   The fetish for "keeping stuff up to date" I have never
understood -- I understand it from android app designers, every time
a package updates itself, it gets the latest ads (and drops any the
developer is no longer being paid for) - but here?   If it works,
leave it alone.   Updates are only usually needed (for the vast majority
of applications) when they fail to do something that's needed, but
a newer version would.   (Occasionally, but much less often than seems
to be most people's view, something actually has a security problem
that should be fixed.)

  | The only exception should be things like basic network services
  | (sshd, r*, telnetd, etc.)

Why an exception for those (and as Mouse asked, what aren't you excepting
there?)   It seems like you mean "If I sometimes enable this, it should
remain, otherwise it should go away".   I can't think of the last time I
enabled telnetd, or the r*d's - but I see no need to delete them just because
I don't use them, someone probably does (or at least might) - and there is
some comfort to knowing that I could enable any of them, trivially easily,
should I ever have a need.   I do often enable ftpd however.  It isn't
clear if that one is part of your "etc" or not.

  | along with a mail server that is only capable of local delivery
  | and maybe hand-off to a smart mailer (no need for postfix in base).

But that one I do agree with - and that's back to the above point,
simple servers that are enough to do basic things, but no more, are
all that's really needed.

  | The other execeptions would be things like mountd/nfsd which are
  | tightly integrated to the OS.

If "everything should go" it could include those as well, most systems
these days are not running nfs servers, those could be add-ons, if we
really wanted to go that route.

Taylor's (February 4) message included:

  } A DHCP _server_ (or relay) isn't necessary for the kind of system
  } integration that justifies the maintenance burden of having it in the
  } base system

What maintenance burden?   dhcpd hasn't been touched since early 2022 (when
it was last updated to a new version) and if ISC have stopped making new
versions of it, then it really never needs to be touched again (at most,
its Makefile might need to be told to turn off warnings, or at least not
treat them as errors, and perhaps to use an older C standard version than
whatever becomes the default in the future).  Last time I used it, it worked.
Is there any evidence that has changed?

Just leave it there, if someone prefers something newer, or needs some
new option handling or something for some particular purpose, or just
feels the need to always have the newest everything, they can then fetch
some newer one (from pkgsrc, hopefully, if not, from elsewhere and build
it themselves).

  } -- unlike say, a DHCP _client_, which is needed to get
  } connected to the network and download packages in the first place.

And to return to the point above, just what use is a DHCP client unless
we can expect there to be a DHCP server for it to communicate with?
Kind of like supplying ssh, but not sshd, right?

Certainly some sites, perhaps most sites, have a dhcp server elsewhere,
but can anyone say with certainty that all do?

kre