From: David Gwynne Subject: Re: LLDP daemon and display tool To: tech@openbsd.org Date: Mon, 28 Apr 2025 10:19:47 +1000 On Fri, Apr 25, 2025 at 10:10:32PM -0600, Theo de Raadt wrote: > Sebastian Benoit 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 [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?