#1652 Issue closed: In SLE15 'net-tools' (ifconfig, netstat, route, ...) will be deprecated¶
Labels: cleanup, fixed / solved / done
jsmeix opened issue at 2017-12-20 11:55:¶
In the upcoming SUSE Linux Enterprise 15 (SLE15)
'net-tools' will move to the so called 'legacy' module.
In SLE15 a so called 'module' is some kind of
software repository for a particular purpose.
The 'legacy' module is for outdated/deprecated software
that still can be installed and used (for some time)
but in the end it will fade out of support in SLE15.
This means we have to check all ReaR scripts
to use the equivalence provided by iproute2.
The list of binaries we have to check:
# rpm -qvl net-tools | grep 'bin/' | cut -d '/' -f3 | sort arp dnsdomainname -> hostname domainname -> hostname ether-wake hostname ifconfig ipmaddr iptunnel nameif netstat plipconfig rarp route slattach
iproute2 documentation can be found here:
http://baturin.org/docs/iproute2/
gozora commented at 2018-12-06 18:41:¶
Just hit this issue with my newly installed SLE15:
sle15:~ # rear mkrescue
ERROR: Cannot find required programs: bc route
Some latest log messages since the last called script 950_check_missing_programs.sh:
2018-12-06 19:19:19.717942431 Including init/default/950_check_missing_programs.sh
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: bc: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: route: not found
Aborting due to an error, check /var/log/rear/rear-sle15.log for details
sle15:~ # zypper search --provides --match-exact /usr/bin/route
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+----------------------+---------------------------------+--------
i+ | net-tools-deprecated | Deprecated Networking Utilities | package
jsmeix commented at 2018-12-07 10:57:¶
I was not hit by such an issue with my yesteday newly installed SLE15
at
https://github.com/rear/rear/issues/1998#issuecomment-444896544
gozora commented at 2018-12-07 11:07:¶
Maybe you have some inside info on how to install SLE15 to fit better with ReaR ;-).
V.
gozora commented at 2018-12-07 11:45:¶
I went for following module selection (on SLE-SAP) and end up with system without bc and route
sle15:~ # bc; route
If 'bc' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf bc
If 'route' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf route
Btw. I'm not complaining, just saying ;-)
V.
jsmeix commented at 2018-12-07 12:34:¶
Feel free to complain about that SLE15 modules stuff ...
I had selected two of them (that were "just selectable" for me)
and in the next step the installer complained at me about conflicts ;-)
I found the reason why my ReaR did not complain:
I used the SUSE rear23a RPM package for SLE15 which does not yet
contain
https://github.com/rear/rear/pull/1961
I have no route installed (things work for me with DHCP
but missing route may cause unexpected failures otherwise).
I have bc (RPM package 'bc') installed because
# rpm -e --test bc
error: Failed dependencies:
bc is needed by (installed) rear23a-2.3.a-7.3.x86_64
cf. "I use my own rear.spec for the official rear RPM in openSUSE" in
https://github.com/rear/rear/issues/1855#issuecomment-404100990
I think as log as we did not fix this issue here it is o.k.
that ReaR insists on the tools that current ReaR needs
even if some of those tools are considered "outdated".
gozora commented at 2018-12-07 12:43:¶
I'm not complaining about SLE15 modules stuff now, (but you should listen to me yesterday evening as I was installing SLE15 for first time in my life :-D), it is innovative (despite a bit nonstandard :-)) approach.
I'm not used to install ReaR from RPM, that's why I need to install all the related progs separately, so now it is clear why you did not met this problem ...
V.
petroniusniger commented at 2019-05-14 13:50:¶
Please note that this problem also affects openSUSE Leap 15. Testing a dev branch rebased to rear-2.5 on a Leap 15 VM, I get this error:
pc-pan:/home/philipa/projets/rear # ./usr/sbin/rear -v mkbackup
Relax-and-Recover 2.5 / Git
Running rear mkbackup (PID 27773)
Using log file:
/home/philipa/projets/rear/var/log/rear/rear-pc-pan.log
ERROR: Cannot find required programs: route
And as @jsmeix pointed out above:
pc-pan:/home/philipa/projets/rear # cnf route
The program 'route' can be found in the following packages:
- net-tools-deprecated [ path: /bin/route, repository: zypp (repo-oss) ]
- net-tools-deprecated [ path: /usr/bin/route, repository: zypp (repo-oss) ]
The requirements in ReaR is expressed in ./usr/share/rear/conf/GNU/Linux.conf
crogonint commented at 2020-02-02 17:56:¶
What in the unholy hell??
Did you pick a package to replace the functionality of net-tools before you decided to deprecate basic command line network tools that have existed since the dawn of time? Sorry for sounding catty, but it sounds absolutely ridiculous to deprecate net-tools.
Seriously. I installed the root package because it's still available (thankfully), and now I can't locate netstat in the default sources. (I haven't looked for the other packages yet.) Could you kindly point me to a semi-reputable source where I can pick up the other packages needed to complete the functionality for net-tools?
Also, if you don't have an alternative that replicates the functionality, I highly recommend you at least put the packages in to some sort of alt-repository where people can find it. Are Pac-man and those guys still around? It's been about 5 years since I installed a SUSE desktop, so I'm a bit out of touch.
Thanks so much!
theAkito commented at 2020-02-02 19:39:¶
Sorry for sounding catty, but it sounds absolutely ridiculous to deprecate net-tools.
Why? It's old, not maintained and the current tools are just plain
better. Why stick to old shit if you can use something newer, that is
actually better? Yeah, you have to learn and use it as a new thing, but
guess what, ifconfig was new at some point, as well.
crogonint commented at 2020-02-02 21:27:¶
Well, that's why I started off asking what is replacing it. What are you guys using to replace the functionality of it?
gozora commented at 2020-02-03 20:50:¶
@crogonint @theAkito you guys are barking up the wrong tree ...
We in ReaR are neither maintaining nor
deciding about obsolescence of net-tools package. Unfortunately we are
just "victims" of software development, just as your (and many other
users) are.
Well, that's why I started off asking what is replacing it. What are you guys using to replace the functionality of it?
I think iproute2 package (at least on Debian) should sufficiently well replace net-tools.
V.
theAkito commented at 2020-02-03 22:22:¶
We in ReaR are neither maintaining nor deciding about obsolescence of net-tools package. Unfortunately we are just "victims" of software development, just as your (and many other users) are.
I'm fully aware of it. In fact I am not even a ReaR user, I just found
this discussion regarding ifconfig, etc. as it is being deprecated in
general.
github-actions commented at 2020-07-01 01:33:¶
Stale issue message
crogonint commented at 2020-07-01 06:01:¶
Why?
Sorry I missed this earlier, @theAkito
I can't recall the exact pakcages, but something I considered critical was dependent on it. Probably some sort of network administration tracking tool I used for virtual machines or some such.
As a best practice, they shouldn't deprecate these things until some level of functionality has been patched over upstream. I actually abandoned my SLED 15 administration install over it. It's a sad sad day when I have to relegate network administration to a Windoze machine because Linux can't hack it any more.
IMHO, the entire foundation of the Linux movement is falling apart because of this stagnation and finger pointing. Windows is poised to fall on it's face, dead of old age, and Linux can't muster a single user ready desktop to present to the masses.. let alone something to keep advanced users and corporate administrators happy for a few generations.
jsmeix commented at 2020-07-01 06:34:¶
Since
https://github.com/rear/rear/pull/2297
was merged
what belongs to ReaR of this issue is fixed in ReaR 2.6 and
https://github.com/rear/rear/issues/1652#issuecomment-581611893
explains the rest.
[Export of Github issue for rear/rear.]