net-tools-deprecated

Had we not learned from the past when dig was set to replace nslookup? I support multiple Unix operating systems at work and this set of common tools across Unix is heavily used. Pulling them will cause me to rewrite HUNDREDS of scripts just so we can keep using Suse at work. This may push us over to Big Blue owned RedHat. Please stop trying to fix things that are not broken.

Any link? I’m on Tumbleweed and see this:


knurpht@Knurpht-HP:~> rpm -qa | grep net-tools
net-tools-2.0+git20180626.aebd88e-1.1.x86_64
net-tools-deprecated-2.0+git20180626.aebd88e-1.1.x86_64
net-tools-lang-2.0+git20180626.aebd88e-1.1.noarch
knurpht@Knurpht-HP:~> 

Here’s a copy paste of the release notes.

"The package net-tools-deprecated contains the obsolete tools that can be replaced with ip subcommands as below:

  • [FONT=inherit]arp -> ip [r] neigh
  • route -> ip route
  • netstat -> ss -r]
  • iptunnel -> ip tunnel
  • ipmaddr -> ip maddress
  • ifconfig -> ip address

[/FONT]
The tools hostname, domainname, dnsdomainname have been moved to the package hostname which is required bynet-tools and net-tools-deprecated."

Now what is the question?

I admit that one should read the release notes (or get a hint here on the forums) to know that one must install net-tools-depricated to have those tools. But after that, they work as they did for 40+ years.

And when we take the history of the depricated (also by RedHat IIRC) nslookup as an example, It is still there after so many years, so why should the future of these toold not be bright?

I also admit that I do not quite understand why something that is not broken is replaced. Even if one decides that the code is old and not easy adaptable to new extensions needed, then IMHO programming new code to provide the old user interface must be possible. After all the same was done when these tools were rebuild as GNU versions of the original Unix ones.

On Fri, 04 Jan 2019 15:56:03 +0000, evicmar wrote:

> Had we not learned from the past when dig was set to replace nslookup? I
> support multiple Unix operating systems at work and this set of common
> tools across Unix is heavily used. Pulling them will cause me to rewrite
> HUNDREDS of scripts just so we can keep using Suse at work. This may
> push us over to Big Blue owned RedHat. Please stop trying to fix things
> that are not broken.

I’m not sure what the purpose is for telling a community of openSUSE
users “don’t do this or I might have to go to another distribution”. If
you feel a change to RedHat/Fedora/whatever is appropriate for you, then
by all means, make the change. You have to do what’s right for you.

Like you, we’re users here, not developers. You might ask a question on
the openSUSE mailing list about the lifetime of the tool and when it’s
planned to be removed.

Further, though, I’m not sure that replacing the use of ‘nslookup’ (which
has been known to be on the way out for years now, and not just in
openSUSE) in even hundreds of scripts is less work than replacing entire
operating system installations.

“Threats” like this really serve little purpose. I would instead suggest
asking something around how long nslookup is likely to be supported, what
strategies others are using to migrate to more modern tools like dig, and
if there are other ways to mitigate the eventual migration and removal of
a venerable tool like that.

I can only add this, though - I’ve used ifconfig for years, and it has
long since been replaced by the ip command.

I still use ifconfig to this day, even on Leap 15.0.


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

First, regarding the use of dig vs nslookup, people would have to “dig” all the way back in history to 2002/2004 to re-discover details on that effort. I can’t even get details on the very earliest origins of each, I only remember that it seems to me that dig has always existed since my earliest exposure to *NIX when the Web hardly existed and the Internet was purely bulletin boards and search servers you submitted a query one day and checked for results the following day. I learned about nslookup much later, so I personally <suspect> that dig existed prior to nslookup despite the effort to deprecate nslookup. In any case, the very fact that nslookup does not rely heavily on the system’s name configuration is critical to troubleshooting problems and might be a major drawback using dig (I don’t use it for troubleshooting).

https://en.wikipedia.org/wiki/Nslookup

Regarding the utilities in net-tools-deprecated, I think I understand the solid reasons for deprecating, it was done during a time when major efforts were made to transfer User-mode tools into Kernel-mode. The consequences for the entire effort as a whole resulted in better security, QA control, simplified management and distribution, and simplified commands which are also more informative… Basically, a time when every aspect of these long-used tools could undergo a once-in-a-lifetime review to evaluate how they work and what they do, and make changes from the ground up which might not be done again for generations of Users.

But, I think that people like yourself who have built up major libraries and apps that rely on original methods have not been forgotten, and it’s why packages like net-deprecated-tools exist and won’t likely disappear for decades to come.

Because this is integral to the Linux kernel, I don’t know how you can avoid the way these tools are provided or used unless you just don’t use Linux altogether. Enough time has passed (approx 4 years now) since this whole thing happened that I doubt even RHEL is any different except maybe that they provide the deprecated tools by default instead of as a separate package. If this really bothers you, it’s not difficult to create your own customized openSUSE distribution for your own use with Kiwi or SUSE Studio with net-deprecated-tools already installed. Personally, it’s just on my list of packages to install(among others, I also install mlocate, tree) after any new TW install today if a solution requires it so it’s not like it’s any more effort than usual.

TSU

I’m not sure what’s the fuss here.

I routinely install “net-tools-deprecated” so that old scripts will still work. I’ll eventually get around to rewriting the scripts, but there does not seem to be any urgency.

As for “dig” and “nslookup” – I have been using “dig” for at least 25 years now, and “nslookup” still exists. Use whichever you prefer. I’m not seeing an issue.

I’m guessing this became visible to the @OP only recently and so was surprised and possibly assumed that anything deprecated had limited time to live.

Deprecated does usually mean that it will disappear “soon,” but in this case not likely.
And, the @OP may not be aware that the changeover actually happened almost half a decade ago, he just had not run into it popping up in any apparent way. If RHEL is still providing User-mode net tools by default, I endorse the openSUSE way instead… Providing deprecated tools by default only perpetuates its use because new code will continue to use those old tools. the openSUSE way continues to support what has always existed but makes a clear sign that new code ought to use the new tools instead.

TSU

Hi
Isn’t that why alias was invented?


alias arp='ip neigh'
alias rarp='ip -r neigh'
...
...

boven:~ # arpAddress                  HWtype  HWaddress           Flags Mask            Iface
beneden.henm.xs4all.nl   ether   a0:d3:c1:3d:3f:bc   C                     enp1s8
adsl.henm.xs4all.nl      ether   c0:25:06:4e:59:81   C                     enp1s8
boven:~ # ip neigh
fe80::c225:6ff:fe4e:5981 dev enp1s8 lladdr c0:25:06:4e:59:81 router STALE
10.0.0.155 dev enp1s8 lladdr a0:d3:c1:3d:3f:bc STALE
10.0.0.138 dev enp1s8 lladdr c0:25:06:4e:59:81 REACHABLE
boven:~ #

That is not the same formatted output. And the OP wrote in post #1

Pulling them will cause me to rewrite HUNDREDS of scripts just so we can keep using Suse at work.

I doubt an alias will help him (or me) in adapting the scripts easy.

It is probably the dumb Microsoft Effect - if it works - change it so it doesn’t or make it so it requires newer hardware. We are at the point where Linux is forgetting about 32 bit systems - we have already forgotten about 16 bit systems which I learned on. Tandy and Convergent had nice 16bit Unix in the late 1970’s and early 1980’s.

Or the Intel effect - if we add memory - we need applications to use it all - everyone should have to use Unix on a 16 bit computer with 16K of ram and disks that were 5MB (2.5mb of 16bit words) - then you would understand why we had seperate file systems. I started with Unix on a PDP11-30 in 1973 with 2 5MB hard drives and 16K of ram. Had to compile all the pieces on a PDP11-45 as it had enough memory to comple the Unix kernel the PDP11-30 did not. For the newbees - the RK05 hard disk took about 15 minutes to write all 5MB of data. It was a lot faster than the cassette tape drives we ran programs from.

Nothing added to Unix/Linux since System V except the removal of the system panics and the conversion to streams have made any sense.

Unix added sysadmin to allow non-unix systems programmers to admin their Unix and not know why it works - now we have YAST - another crutch that allows the same thing - the sad part is everyting the YAST GUI does is a command line instruction that should have been done from a command prompt. Learn Unix/Linux.

We had X - but we want to make it look like Windows - why? I have moved to MATE because it feels like old gnome - the new gnome feels like Microsoft Windows - the worlds worst virus.

We had C and C+ but it was too compact, protable, and hard to learn - so we replaced it with oversized slow Java - the most easily to compromise a system with language with her is a jar that does what you need - sorry it it spys on you. If you could program you wouldn’t be spyed on.

We had init - but we wanted to remove it for systemd - for a few seconds more startup time?

We had lpadmin - now we have Apple’s crutch CUPS - still does lpadmin commands but hidden from the user.

We have cron - but we replace it with systemd timers - If we wanted smaller timers - we wrote our own schedulers to do that.

Now the old Ethernet tools are being replace with a one size fits all replacement.

If you have to support 1,000’s of Unix/Linux systems spread around the world like I had to - you would discover the the GUI cannot do the job - It all has to be scripted and every possible error has to be scripted for.

I agree with those that are complaining about the “new and improved” commands - are they better? The still haven’t made it user freindly.

It is sad that the GeckoLinux distribution with MATE is easier to install than the Opensuse Distributions. I have install that for many Windows 8 and 10 users that hated the new interface. It looks more like the XP and Vista interface. It is sad that there still over 250 Million Windows XP still running. Almost every ATM and Cash Register is running XP beneith the surface.

End of rant.

Eh, feel free to use the credentials you use here and login on build.opensuse.org, branch the net-tools-deprecated package and it’s deps and keep building and maintaining it for as many future versions as you like. That will buy you the time to rearrange your hundreds of scripts ( hint: salt stack, change a couple of states and all back to normal ) . You even have the option to build your own openSUSE based distro incl. your own modifications, scripts etc.

Another thing that comes to mind is admtinistration / maintenance. We all rely on 3rd party stuff, i.e. things we do not develop ourselves. Part of the maintenance and administration of software should be the keeping up with reliability of underlying technology. Which for me f.e. means that using Flash on a website is a no go. This implies that maintenance also should involve these scripts IMNSHO. Meaning they should be/have been planned to be rewriten, or at least evaluated.

Please do consider that the openSUSE Project had the decency to provide the net-tools-deprecated package, instead of simply announcing removal, removing. The fact that the package also exists for Tumbleweed to me means there’s no reason for panic or ranting.

End of rant.

Thank you, larryr. I appreciate rants like yours immensely and unironically. Many users today (no matter what platform) have no idea how all this modern information technology originated from, and it’s veterans of the industry like you who can put things into perspective.

»When I was a boy…« (cue fireplace-guitar music), I’ve learned K&R C and Unix (well, Minix/MiNT/Linux68k) on my Atari ST until I was properly introduced to Digital Unix, HP/UX and finally S.u.S.E. Linux 4.1 in the 1990s, and from time to time, I enjoy reminding my fellow computerised humans around me where it all came from myself.

If it ain’t broken, don’t fix it. It’s true, but in the case of systemd I’d like to make an exception. I despised hacking those startup/shutdown shellscripts on some of these Unix/Linux systems with a passion, and systemd made me motivated again to optimize my boots after a long while. My main rig at home (5 years old i5, SSD, nothing special) boots into KDE/Plasma5 with NetworkManager (wicked would be too slow) in about 3 seconds: »Startup finished in 233ms (kernel) + 691ms (initrd) + 491ms (userspace) = 1.415s« according to systemd-analyze was my personal record a few days ago, on average it’s more like 1.6 to 1.7 seconds.

Aside from learning about concurrency within the boot processes, I also shut my rig down more often than before, because a cold boot is virtually as fast as a wake from hibernation – which is also nice for my peace of mind. Again, thanks for the awesome rant. Cheers!

… yes, indeed.

Why, ah’ll tell ya, young feller …

Back in mah day, when ah was knee-haigh to a grasshopper, the peoples did not have no such thing as computers, nary a one!

Things were jes’ fine, like that, in them days, nuthin’ was broke in thet way, ah declare!

Wish they would have followed the “if it ain’t broke, don’t fix it” mantra, 'cause there would be no Facebook, no Twits, no Hackers and no Spammers.

If memory serves the init scripts went deprecated, default became systemd but you could still install init scripts and it would not install systemd. Also OpenSuSE promised that they would not remove init scripts till the next major number release(12). A few months later in the same major number release(11) it was systemd only.

Yes aliases are great. The listed example of ss -r to replace netstat just is nothing like the original at ALL. None of the common flags used on the original commands would carry over as expected. That is not a solution and clearly not thought out.

I am fully aware of the other commands that came out. However in a mixed environment common commands are crucial for success. The beauty of Unix and Unix based operating systems is that the commands should mostly be the same. Up until recently ifconfig existed by default on ever distribution I support (Solaris, AIX, HP-UX, RHEL, SLES) at work.

I fought to get SuSE back in house after the systemd conversion happened and our company dropped SLES. Once RHEL7 came out that made it real easy to get SLES back in. If SuSE does the same with the common network tools in every distro it did with systemd and init scripts…I may no longer be supporting SuSE at work. I will not have a say in the matter.

As others have described, I doubt that aliasing the new tools is a workable solution. As I described in my earlier post it appears that the various network tools were re-built completely from the ground up in every way without regard to backwards compatibility, only to provide better tools for the future.

So, if you have legacy scripts which require the old network tools, the only workable solution should be what SUSE is doing, which is to provide the old tools when needed.
I’m not aware of any situation where a legacy script would be broken when net-tools-deprecated is installed… and I can’t think of a reason why anything else would be expected.

On the other hand,
On the general subject of new replacing old (The net tools change should be considered a kernel project while systemd does not include the kernel), other commands and subsystems replaced by systemd may not be as backwards compatible… In the Forums over the years there have been the few incidences where maybe an old init command might work without arguments, but if you try to pass the command with arguments, that won’t work. You just have to update to the systemd Unit file instead, but usually those changes are almost trivial (but yes, has to be done even if the required effort is minimal).

TSU