Repository navigation
Remove legacy tools #363
Description
-
ninfod
Is it still relevant and should be kept? It's packaged for Packaged for Fedora as a separate package (@jsynacek). -
rarpd
Reason: obsoleted by BOOTP and later DHCP protocols. Packaged for openSUSE as a separate package (@pevik).
Debian has very old version from the same author, as a separate package. -
rdisc
Is it still relevant and should be kept? Packaged for Fedora (@jsynacek) and openSUSE (@pevik). -
tftpd
requires inetd to run, that is quite a rarity nowadays,dnsmasqis much better alternative, but maybe the size is relevant (dnsmasq: 432K,tftpd: 60K). Packaged for openWRT (@nmeyerhans)
UPDATE: PR Remove tftpd #369 -
traceroute6
Packaged for Debian (@nmeyerhans), which traceroute from Dmitry Butskoy.
UPDATE removed in: [RFC] Remove traceroute6 #362.
@jsynacek @nmeyerhans @okias @nmav @vapier @yurchor @neheb @6eh01der @sevan @zenczykowski @floppym could you please note what you prefer keep and what to remove?
Activity
jsynacek commentedon Jul 28, 2021
I'm fine with removing
ninfodandrdisc. Note that I'm not a Fedora/RHEL maintainer anymore and I've stopped working on anything packaging related.6eh01der commentedon Jul 28, 2021
rdisc has no alternatives (i mean something that implements ICMP router discovery protocol) and i think that it may be useful in some scanarios. It's very simple and stable tool. I don't know how widely it is used but recently i had need to build deb package for work purposes. It does not exist in ubuntu and debian repos. But it included by default in all rpm distros that i know.
floppym commentedon Jul 28, 2021
I'm fine with dropping all of these.
nmeyerhans commentedon Jul 30, 2021
ninfod implements an obsolete experimental protocol that hasn't seen any activity since 2006. It's pretty dead at this point. In the unlikely event that anybody ever starts work on this protocol again, the code will still exist in git history, and I think that's enough. We should drop this.
There are additional tftp implementations besides dnsmasq as well. I usually reach for hpa's implementation if I need one, but atftp is another option.
It's only been obsolete since 1985! Maybe if somebody out there needs to bootstrap a 1970's era VAX or something, this might be useful, but I don't see it being worth much maintainer attention. Historical versions of the code are always available in git.
There is an ancient request to package this for Debian, but I've never gotten around to it. I can't envision a scenario where IRDP is preferable in any way to DHCP for these purposes. I'd love to hear a legitimate use case for it.
Drop it. There's another implementation, and we've got tracepath anyway.
6eh01der commentedon Jul 30, 2021
@nmeyerhans DHCP is more complex to configure and it will not save your machines from gateway death and also for DHCP server failover scenarios you should implement some reserve instance and some kind of replication between them in some scenarios. I don't think that all dns server implementations support automatic failover... About gateway - yes, you could announce some VIP for clients,(for example if you have two gateways with keepalived), but not allways you could have a keepalived or something similar,(i know only one another VRRP implementation - vrrpd, for Windows there is no VRRP at all, but with Routing and Remote Access it can act as IRDP server). And so in some situations it may be appropriate to have some routers with IRDP server and rdisc as client at other machines. Gateway will be chosen by annoucement preference, so if announcement with higher preference is no more seen another with lower will be applied. Work and simple gateway failover. Also i see that IRDP present in Juniper, Cisco and Ruckus documentation and it looks like their devices still support it.
Amanuense-del-diavolo commentedon Sep 15, 2021
to be honest I've just finished writing the systemd units for tftpd, if possible I'd much rather have a tftp server installed with iputils that having to install another package, it's small, it's usable, and it gets the job done
vapier commentedon Sep 16, 2021
the canonical one (tftp hpa) is more featureful. I don't see value in competing in this space, especially when the iputils one is uncommon. just drop it and don't waste more time on it.
pevik commentedon Sep 16, 2021
@Amanuense-del-diavolo "it's small: our
tftpdhas 60K, exactly the same size asin.tftpdfrom hpa. Anyway, really going to remove as agree with @vapier.Remove tftpd
Amanuense-del-diavolo commentedon Sep 16, 2021
oh well, the irony of implement a thing and the next day it gets dropped, 😂
I admit I wasn't checking tftpd-hpa's dimension but the dnsmasq implementation
cheers
pevik commentedon Sep 16, 2021
@Amanuense-del-diavolo I'm sorry to drop your work, but this is a result of considering a time which requires maintaining things which aren't widely used because others project are more mature. Would you please consider contributing systemd service to hpa project which also lack it? (NOTE dnsmasq - a live project which implements tftpd - already has systemd service).
Remove tftpd
Remove tftpd
Remove tftpd
4 remaining items
README.md: Add removed tools
README.md: Add removed tools
pevik commentedon Oct 15, 2021
FYI I plan release during November, after that I'll remove other legacy tools.
sevan commentedon Nov 21, 2021
Apologies for never chiming in, I leave it to you to decide. I would've preferred traceroute6 stayed as that makes things easier to jump between different envs (the BSDs and macOS by heritage ship with traceroute6) but I'll seek out the other implementation mentioned here or just pull the removed copy from here back in.
Remove ninfod
Remove rarpd
Remove rdisc
Remove rdisc
Remove rarpd
Remove rdisc
README.md: Update removed tools
main/iputils: Don't build legacy tools
Remove ninfod