On Fri, Apr 25, 2025 at 10:10:32PM -0600, Theo de Raadt wrote:
> Sebastian Benoit <benno@openbsd.org> wrote:
> 
> > Claudio Jeker(cjeker@diehard.n-r-g.com) on 2025.04.25 13:31:32 +0200:
> > > On Fri, Apr 25, 2025 at 11:36:50AM +0100, Stuart Henderson wrote:
> > > > On 2025/04/25 12:04, Henning Brauer wrote:
> > > > > * Stuart Henderson <stu@spacehopper.org> [2025-04-25 03:25]:
> > > > > > On 2025/04/24 10:38, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > > > > > > This is great!  Some quick testing shows it correctly sees
> > > > > > > all the Fortinet and Juniper hardware on my networks.
> > > > > > > 
> > > > > > > But I would suggest just calling it lldp[d] right from the
> > > > > > > start.  I don't see a conflict as it's makes no sense to 
> > > > > > > run both this and ports at the same time.  And if they
> > > > > > > are both installed, the ports cli names don't collisde
> > > > > > > with this one's.
> > > > > > 
> > > > > > The rc.d scripts conflict.
> > > > > 
> > > > > then the ports one needs to be adjusted.
> > > > > 
> > > > > our ntpd is ntpd, not ontpd.
> > > > 
> > > > yes and we had a problem with that around 5.0-5.1
> > > > 
> > > > > our ldapd is ldapd, not oldapd.
> > > > 
> > > > no conflict
> > > > 
> > > > > our smtpd is smtpd, not osmtpd.
> > > > 
> > > > no conflict
> > > > 
> > > > > our bgpd is bgpd, not obgpd.
> > > > 
> > > > the possibly-conflicting rc script was named quagga_bgpd from the start
> > > > 
> > > > > and so on and so on.
> > > > 
> > > > the rc-script could be renamed, but:
> > > > 
> > > > 1. what to?
> > > > 
> > > > 2. unless it's renamed in the release _before_ this is added, upgrades
> > > > will be broken. user updates base from a version with ports lldpd
> > > > installed to a version with lldpd from base, so overwriting rc.d/lldpd.
> > > > updating packages at that point will _remove_ the rc.d/lldpd script.
> > > > 
> > > > if we want to reuse existing names of things from ports in base we
> > > > could really do with a separate namespace for ports and base rc.d scripts.
> > > 
> > > Would it be acceptable to use lldpd as program name but use rc.d/lldp as
> > > startup script?
> > > 
> > > The only other problem point would be the file in /var/run but I think
> > > that implies that someone wants to run both tools at the same time which
> > > IMO makes little sense and people can then use an overwrite to toggle the
> > > control socket path.
> > > 
> > > I would really like to see dlg's tool in our tree and it seems this is the
> > > main pain point.
> > 
> > Does the daemon need to have a "d" at the end?
> > 
> > If not, how about
> > 
> > lldp	- the daemon binary
> > lldpctl	- the tool
> > lldp	- rc-script
> > _lldp	- username
> 
> I think we've been here before.  When we write our own components, eventually
> people stop using the ports components because ours are good enough.
> 
> Sometimes, it was an external component, which we modified iteratively until
> we had to throw it away, and our own system matured once we dogfooded it.
> 
> This lldp is not as feature complete, but it's privsep design is stronger,
> perhaps even strong enough that it can be run by default.  It probably doesn't
> need to be feature complete.  lldp protocol is supposed to, over time, replace
> all the other legacy things like cdp.  Noone wants a daemon on OpenBSD that
> does all the features.  Noone wants a speaker on a vendor device that speaks
> their custom protocol, since so many have had scary bugs, and they don't
> interoperate.  So can we say, bye by legacy, at the same time?  Us making such
> a decision also partly feeds into the internet culture and allows others to
> consider making the same decision (lldp, only).
> 
> With the ports lldp code, running it by default is not going to happen.
> 
> So I'm confused about why we are bending over backwards for a ports daemon.
> 
> Let's just take over the naming and keep it simple.

so the plan is i rename olldpd to lldpd?

lldp(8) stays as lldp(8)? do i use _lldp for the user the daemon runs
as or take over _lldpd too? what's the rc.d script called?

users will just have to deal with the conflict if they have the port
already installed?