[PATCH] busybox: drop net-tools from defconfig

[PATCH] busybox: drop net-tools from defconfig

[Enrico Jörns]

The 'net-tools' have been deprecated 15 years ago! [1]
Let's remove their busybox pendants from the defconfig to prevent people
from accidentally starting projects with ancient technology.

[1] https://lists.debian.org/debian-devel/2009/03/msg00780.html

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
---
 meta/recipes-core/busybox/busybox/defconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
index 38b82457b7..22c9dafcb3 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -899,11 +899,11 @@ CONFIG_FEATURE_HTTPD_PORT_DEFAULT=0
 # CONFIG_FEATURE_HTTPD_LAST_MODIFIED is not set
 # CONFIG_FEATURE_HTTPD_DATE is not set
 # CONFIG_FEATURE_HTTPD_ACL_IP is not set
-CONFIG_IFCONFIG=y
-CONFIG_FEATURE_IFCONFIG_STATUS=y
+# CONFIG_IFCONFIG is not set
+# CONFIG_FEATURE_IFCONFIG_STATUS is not set
 # CONFIG_FEATURE_IFCONFIG_SLIP is not set
 # CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set
-CONFIG_FEATURE_IFCONFIG_HW=y
+# CONFIG_FEATURE_IFCONFIG_HW is not set
 # CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set
 # CONFIG_IFENSLAVE is not set
 # CONFIG_IFPLUGD is not set
@@ -950,7 +950,7 @@ CONFIG_NC=y
 # CONFIG_NC_SERVER is not set
 # CONFIG_NC_EXTRA is not set
 # CONFIG_NC_110_COMPAT is not set
-CONFIG_NETSTAT=y
+# CONFIG_NETSTAT is not set
 # CONFIG_FEATURE_NETSTAT_WIDE is not set
 # CONFIG_FEATURE_NETSTAT_PRG is not set
 CONFIG_NSLOOKUP=y
@@ -964,7 +964,7 @@ CONFIG_PING=y
 CONFIG_PING6=y
 CONFIG_FEATURE_FANCY_PING=y
 # CONFIG_PSCAN is not set
-CONFIG_ROUTE=y
+# CONFIG_ROUTE is not set
 # CONFIG_SLATTACH is not set
 # CONFIG_SSL_CLIENT is not set
 # CONFIG_TC is not set
-- 
2.39.5

Re: [OE-core] [PATCH] busybox: drop net-tools from defconfig

[Richard Purdie]

On Sun, 2025-01-26 at 12:51 +0100, Enrico Jörns via
lists.openembedded.org wrote:
> The 'net-tools' have been deprecated 15 years ago! [1]
> Let's remove their busybox pendants from the defconfig to prevent
> people
> from accidentally starting projects with ancient technology.
> 
> [1] https://lists.debian.org/debian-devel/2009/03/msg00780.html
> 
> Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
> ---
>  meta/recipes-core/busybox/busybox/defconfig | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

I did a quick grep of OE-Core and we still have a handful of sites
using this on target, particularly but not limited to our QA, the ones
that caught my eye:

meta/recipes-core/udev/udev-extraconf/network.sh:    	ifconfig | grep -q "^$INTERFACE" || ifup $INTERFACE
meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig
meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig
meta/recipes-core/busybox/files/simple.script:                                /SBIN_DIR/ifconfig $interface 0.0.0.0
meta/recipes-core/busybox/files/simple.script:                        /SBIN_DIR/ifconfig $interface $ip $BROADCAST $NETMASK
meta/lib/oeqa/selftest/cases/devtool.py:            result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ifconfig -a', ignore_status=True)
meta/lib/oeqa/selftest/cases/devtool.py:                self.skipTest('Failed to determine if tap devices exist with ifconfig or ip: %s' % result.output)
meta/lib/oeqa/utils/qemurunner.py:                    cmd = "ifconfig eth0 %s netmask %s up\n" % (self.ip, self.netmask)
meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0 | grep 'inet ' | awk '{print $2}'")
meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0:1 %s netmask 255.255.255.0 && sleep 2 && ping -c 5 %s && ifconfig eth0:1 down" % (virtual_ip,virtual_ip))

but there are others too. We probably need to finish resolving these to
other commands before we can turn this off.

If you aren't able to help with that, we should at least have an open
bug to sort it out.

Cheers,

Richard

Re: [OE-core] [PATCH] busybox: drop net-tools from defconfig

[Enrico Jörns]

Hi Richard,

Am Sonntag, dem 26.01.2025 um 12:58 +0000 schrieb Richard Purdie:
> On Sun, 2025-01-26 at 12:51 +0100, Enrico Jörns via
> lists.openembedded.org wrote:
> > The 'net-tools' have been deprecated 15 years ago! [1]
> > Let's remove their busybox pendants from the defconfig to prevent
> > people
> > from accidentally starting projects with ancient technology.
> > 
> > [1] https://lists.debian.org/debian-devel/2009/03/msg00780.html
> > 
> > Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
> > ---
> >  meta/recipes-core/busybox/busybox/defconfig | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> I did a quick grep of OE-Core and we still have a handful of sites
> using this on target, particularly but not limited to our QA, the ones
> that caught my eye:

thank you for looking into this!

Well, not that I hadn't done a grep before. 😉
I looked through the occurrences of 'ifconfig' but concluded that starting with disabling it for
busybox could be an initial step that should not break most setups. But not sure if I was too
optimistic..

I started working on a few patches to address occurrences of ifconfig, but I ran into challenges
with testing my changes. I decided to send this patch on its own, hoping it doesn’t break the
autobuilder, and also to check if there are any objections to removing net-tools in general.


I've now had a second look to see what could be affected by the busybox config change.

> meta/recipes-core/udev/udev-extraconf/network.sh:       ifconfig | grep -q "^$INTERFACE" || ifup $INTERFACE

Wasn't sure about this one but it seems to be used by the initramfs framework and thus probably with
busybox.

-> Probably affected. Might make sense to replace it with ip anyway.

> meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig
> meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig

Documentation that hasn't been touched since 2016.
Also, the commands mentioned there are for the host machine commands.

-> Unrelated. ifconfig could be easily removed here, though.

> meta/recipes-core/busybox/files/simple.script:                                /SBIN_DIR/ifconfig $interface 0.0.0.0
> meta/recipes-core/busybox/files/simple.script:                        /SBIN_DIR/ifconfig $interface $ip $BROADCAST $NETMASK

Both are guarded by 'if [ $have_bin_ip -eq 1 ]; then' and should also work with iproute2 equivalents
though.

-> Related but no need to fix. Fallback could be removed maybe.

> meta/lib/oeqa/selftest/cases/devtool.py:            result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ifconfig -a', ignore_status=True)
> meta/lib/oeqa/selftest/cases/devtool.py:                self.skipTest('Failed to determine if tap devices exist with ifconfig or ip: %s' % result.output)

This is fallback handling for missing 'ip' on the host.

-> Unrelated. Could be removed anyway maybe (already had a patch for this).

> meta/lib/oeqa/utils/qemurunner.py:                    cmd = "ifconfig eth0 %s netmask %s up\n" % (self.ip, self.netmask)

This I had overseen and it actually seems to be called on the target.

-> Probably affected and should be changed.

> meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0 | grep 'inet ' | awk '{print $2}'")
> meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0:1 %s netmask 255.255.255.0 && sleep 2 && ping -c 5 %s && ifconfig eth0:1 down" % (virtual_ip,virtual_ip))

I had made a patch for this but did not figure out how to run this test or if it is actually used by
CI.

-> Probably affected and needs more research.

> but there are others too. We probably need to finish resolving these to
> other commands before we can turn this off.
> 
> If you aren't able to help with that, we should at least have an open
> bug to sort it out.

I'd try to address the potential issues first.

Another challenge would be to remove the actual 'net-tools' package because ltp still seems to rely
on it (with explicit RDEPENDS).
But we could start with removing it from packagegroup-core-{base-utils,full-cmdline}.bb IMHO.

Do you have an opinion about the host tooling? Could we drop net-tools here, too?


Regards, Enrico

> Cheers,
> 
> Richard
> 

-- 
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |

Re: [OE-core] [PATCH] busybox: drop net-tools from defconfig

[Richard Purdie]

On Sun, 2025-01-26 at 21:30 +0100, Enrico Jörns wrote:
> Am Sonntag, dem 26.01.2025 um 12:58 +0000 schrieb Richard Purdie:
> > On Sun, 2025-01-26 at 12:51 +0100, Enrico Jörns via
> > lists.openembedded.org wrote:
> > > The 'net-tools' have been deprecated 15 years ago! [1]
> > > Let's remove their busybox pendants from the defconfig to prevent
> > > people
> > > from accidentally starting projects with ancient technology.
> > > 
> > > [1] https://lists.debian.org/debian-devel/2009/03/msg00780.html
> > > 
> > > Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
> > > ---
> > >  meta/recipes-core/busybox/busybox/defconfig | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > I did a quick grep of OE-Core and we still have a handful of sites
> > using this on target, particularly but not limited to our QA, the ones
> > that caught my eye:
> 
> thank you for looking into this!
> 
> Well, not that I hadn't done a grep before. 😉
> I looked through the occurrences of 'ifconfig' but concluded that starting with disabling it for
> busybox could be an initial step that should not break most setups. But not sure if I was too
> optimistic..

The udev/initramfs and some of the QA references do worry me a bit.

> I started working on a few patches to address occurrences of ifconfig, but I ran into challenges
> with testing my changes. I decided to send this patch on its own, hoping it doesn’t break the
> autobuilder, and also to check if there are any objections to removing net-tools in general.

I don't see a problem with switching the references over and
personally, I think we'll need to remove net-tools but one step at a
time I guess.

I think what I'd suggest is sending a series of what you have removing
the references you can. We can then test that on the autobuilder and
see what it shows. Please just make it clear you're asking for help
with testing. Copying Mathieu as he may be able to help.

> I've now had a second look to see what could be affected by the busybox config change.
> 
> > meta/recipes-core/udev/udev-extraconf/network.sh:       ifconfig | grep -q "^$INTERFACE" || ifup $INTERFACE
> 
> Wasn't sure about this one but it seems to be used by the initramfs framework and thus probably with
> busybox.

Right, that was my worry.

> -> Probably affected. Might make sense to replace it with ip anyway.
> 
> > meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig
> > meta/recipes-core/images/build-appliance-image/README_VirtualBox_Toaster.txt:    $ ifconfig
> 
> Documentation that hasn't been touched since 2016.
> Also, the commands mentioned there are for the host machine commands.

Agreed, those ones aren't a blocker.

> 
> -> Unrelated. ifconfig could be easily removed here, though.
> 
> > meta/recipes-core/busybox/files/simple.script:                                /SBIN_DIR/ifconfig $interface 0.0.0.0
> > meta/recipes-core/busybox/files/simple.script:                        /SBIN_DIR/ifconfig $interface $ip $BROADCAST $NETMASK
> 
> Both are guarded by 'if [ $have_bin_ip -eq 1 ]; then' and should also work with iproute2 equivalents
> though.

Good, I didn't check that, I was just trying to see what references we
had left.

> -> Related but no need to fix. Fallback could be removed maybe.
> 
> > meta/lib/oeqa/selftest/cases/devtool.py:            result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ifconfig -a', ignore_status=True)
> > meta/lib/oeqa/selftest/cases/devtool.py:                self.skipTest('Failed to determine if tap devices exist with ifconfig or ip: %s' % result.output)
> 
> This is fallback handling for missing 'ip' on the host.

Ok.

> -> Unrelated. Could be removed anyway maybe (already had a patch for this).
> 
> > meta/lib/oeqa/utils/qemurunner.py:                    cmd = "ifconfig eth0 %s netmask %s up\n" % (self.ip, self.netmask)
> 
> This I had overseen and it actually seems to be called on the target.

Right, that one does seem potentially problematic. I didn't look into
which set of runner options trigger it though.

> 
> -> Probably affected and should be changed.
> 
> > meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0 | grep 'inet ' | awk '{print $2}'")
> > meta/lib/oeqa/runtime/cases/ethernet_ip_connman.py:        (status, output) = self.target.run("ifconfig eth0:1 %s netmask 255.255.255.0 && sleep 2 && ping -c 5 %s && ifconfig eth0:1 down" % (virtual_ip,virtual_ip))
> 
> I had made a patch for this but did not figure out how to run this test or if it is actually used by
> CI.

I'd guess a "bitbake XXX-image-XXX -c testimage" where the image
contains connman?

> -> Probably affected and needs more research.
> 
> > but there are others too. We probably need to finish resolving these to
> > other commands before we can turn this off.
> > 
> > If you aren't able to help with that, we should at least have an open
> > bug to sort it out.
> 
> I'd try to address the potential issues first.
> 
> Another challenge would be to remove the actual 'net-tools' package because ltp 
> still seems to rely on it (with explicit RDEPENDS).

I'd guess there are tests in ltp which call ifconfig and friends?

> But we could start with removing it from packagegroup-core-{base-utils,full-cmdline}.bb IMHO.

Yes, definitely agreed.

> Do you have an opinion about the host tooling? Could we drop net-tools here, too?

If we don't need it anywhere now, I'd be fine with that.

Cheers,

Richard