FS#24647 - [net-tools] behavior change of hostname, and missing dnsdomainname

Attached to Project: Arch Linux
Opened by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 12:04 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 15:49 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Gaetan Bisson (vesath)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

[Rephrased by tomegun:]

After the move of hostname/domainname to coreutils/yp-tools the following bugs occur:

- dnsdomainname is nowhere to be found
- hostname does not support the -f parameter (used for getting the fully qualified domain name)
This task depends upon

Closed by  Tom Gundersen (tomegun)
Thursday, 09 June 2011, 15:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fix for dnsdomainname in [testing]. For the hostname issue, open a new bug as this is to littered with irrelevant stuff.
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 12:11 GMT
BTW, simply enabling dnsdomainname in your coreutils build would be a poor solution to this problem. Please bring back the hostname and dnsdomainname from the net-tools package. The hostname tool from net-tools is superior to the coreutils version in every way, and that's what the main distros use.
Comment by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 12:44 GMT
net-tools has been unmaintained for more than a decade, so relying on it is out of the question.

dnsdomainname is provided by yp-tools, not coreutils (see the http://www.archlinux.org/).

If you have a suggestion for versions of these tools that are better than what we provide, and still maintained, feel free to suggest them.

That said, as a matter of principle, I don't spend more than five seconds dealing with bug reports containing phrases like "what the hell?!", so if you have further questions you'd have to ask someone else.
Comment by mangust (mangust) - Thursday, 09 June 2011, 13:00 GMT
Grnch, you should read the output of pacman. Issuing pacman -Syu will give additional information what you should do further (read 'administer your system'). Ain't a bug!
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 13:08 GMT
I thought yp-tools is only for systems using NIS. Is it OK to install it on non-NIS systems anyway?

The phrase "what the hell" was utterred in momentary frustration, but it was more than justified considering that you broke a major package at the core of the system without warning. If yp-tools must now be installed to retain the same functionality (dnsdomainname), you could have at least added a courtesy dependency on yp-tools to the net-tools package in order to ease the transition, or at the very least printed a warning message about the change during net-tools package installation, which is what other packages do when there is some important change in a new version.

I could understand this kind of silent and abrupt change if it was some peripheral package, but in case of a core part of the system I'm sure there are ways the transition could have been handled smoother and more thoughtful.

If you are going to act like a primadonna and refuse to answer the questions of users whose systems you broke and who got understandably (and briefly) pissed off about it, then you are not fit to be a maintaner of such core packages. Please check your ego at the door and consider the higher goals of Arch Linux, which is to provide a good, stable and simple distribution for everyone.

This type of careless patching of core packages is exactly what drove me away from Gentoo.
Comment by Kevin (anonymous_user) - Thursday, 09 June 2011, 13:12 GMT
FWIW, they did post about this on the front page:

http://www.archlinux.org/news/deprecation-of-net-tools/
Comment by Karol Błażewicz (karol) - Thursday, 09 June 2011, 13:14 GMT
Not exactly a silent change, as the announcement is on the main page.
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 13:16 GMT
I cannot be expected to read the home page every time I do update, but I do read the output of "pacman -Syu" thoroughly each time I upgrade the system, and absolutely no warning was given about dnsdomainname/hostname, sorry.

If there were such a warning, there would have been no frustration. I would immediately know what to do instead of wondering why a bunch scripts stopped working, and this bug report probably wouldn't have been filed at all.
Comment by Karol Błażewicz (karol) - Thursday, 09 June 2011, 13:21 GMT
New optional dependencies for initscripts
net-tools: legacy network support

That should prompt you to look deeper into the matter but indeed it could be phrased better.
Comment by Ionut Biru (wonder) - Thursday, 09 June 2011, 13:28 GMT
hold your horses.

imo old tools shouldn't be removed unless it has a name clash. dnsdomainname should be bring back since it doesn't clash with anything even if it has a replacement from yp-tools
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 13:28 GMT
Quoting Karol Błażewicz (karol):

"New optional dependencies for initscripts
net-tools: legacy network support"

Yeah, right... that's very obvious. Sorry, vague mentions in unrelated packages are useless. I would have never connected the problem to that message in a million years, until I went through the trouble of debugging it myself.

However, the comment I eventually found in net-tools/PKGBUILD explicitly spelled out the change, and that's the type of warning that should have been explicitly output during installation.

But it wasn't.

And that's a problem.

Plus, there is still the question of the missing -f parameter to hostname. What do we about that? It's a gratuitous incompatibility with all the major Linux distros (RedHat, SuSE, Debian, Ubuntu).
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 13:31 GMT
I also have to ask, what exactly was wrong with net-tools beside the fact that it was old? So what if it's old, it still works well. Why fix something that wasn't broken?

Was the "elegance" of not relying on old tools really worth the breakage and incompatibility with other major distros?
Comment by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 13:56 GMT
Here is the situation:

initscripts needs "hostname" and don't want to rely on net-tools
yp-tools needs "nisdomainname" and don't want to rely on net-tools

We solved this now by moving ypdomainname/nisdomainname/domainname (which are all links to the same binary) to yp-tools (not sure what happened to dnsdomainname, I have asked the packager, probably a bug), and moving hostname to coreutils.

As I said before: feel free to suggest a better solution, within these constraints. I'm assigning this bug to the relevant packagers so they can have a look. I will also take the liberty of rephrasing your report, this way it should be more that people will spend time on it.

Did you check how the other distro's do this in their most recent releases? I just had a quick look now at Fedora: <http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=blob;f=coreutils.spec;h=729c14943cca283310655b717d9863c37e5931d0;hb=HEAD>. Looks like they use the hostname from coreutils.

It would be helpful if you check what SuSE, Debian and Ubuntu do as well, if you have not already done so, and provide links to their package sources.
Comment by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 14:05 GMT
[For the record, the original report:]



Description:

Guys, what the hell? The latest net-tools update completely broke hostname/dnsdomainname. I see the PKGBUILD contains a comment that they are now provided by coreutils, but that's just not true:

- dnsdomainname is nowhere to be found in coreutils
- hostname from coreutils is very basic and doesn't support the -f parameter for getting the fully qualified hostname of the machine

What this means is that you are left with no way of determining the fully qualified hostname of an Arch box! As things currently stand, neither `hostname -f` nor `hostname`.`dnsdomainname` work.

This caused all kinds of scripts to fail on my build box for work.

Please be more careful when ripping out files from core packages...


Additional info:
* package version(s)

net-tools 1.60-16
coreutils 8.12-2

Steps to reproduce:

[root@buildbox ~]# pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
there is nothing to do

[root@buildbox ~]# hostname -f
hostname: invalid option -- 'f'
Try `hostname --help' for more information.

[root@buildbox ~]# dnsdomainname
-bash: dnsdomainname: command not found
Comment by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 14:35 GMT
dnsdomainname: just use domainname instead. it used to be the same binary (you need yp-tools).
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 14:46 GMT
I was just about to write that installing yp-tools doesn't solve the dnsdomainname problem, you beat me to it.

Thanks for the acknowledging the problem, and thanks for the hint about Fedora. We are actually using the enterprise version of RedHat where this change hasn't trickled in yet. I will check the other distros and let you know.
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 14:49 GMT
There is one more thing that should be added to the bug description: an explicit warning should be printed during net-tools installation that hostname and dnsdomainname are no longer provided by net-tools and that they are now provided by coreutills and yp-tools with possible changes in functionality and supported options.

In fact, I would urge you to push out an immediate update to net-tools that just adds this warning, so that other users at least have a fair warning before they fall in the same trap as me.
Comment by Gaetan Bisson (vesath) - Thursday, 09 June 2011, 14:51 GMT
There is no bug: users are expected to read the announcements and, if you want domainname, just install yp-tools.
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 14:53 GMT
I tried "domainname" as a replacement for "dnsdomainname" but it doesn't work. On my machine "domainname" prints "(none)" whereas "dnsdomainname" printed the actual DNS name.

I think "domainname" relies on explicitly setting the domain name using yp-tools or in some config file, whereas "dnsdomainname" actually looks up the current domain name of the machine from DNS or /etc/hosts. I believe that's a significant change in functionality, therefore "domainname" is not a suitable replacement for "dnsdomainname".
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 14:58 GMT
Gaetan, that is a completely unreasonable expectation. If that were so, then no Arch package would have ever printed any warning during installation and all packages would have expected users to read the home page every time. Since this is patently false (many packages print their upgrade-related warnings during installation), the expectation by sysadmins is that they will be warned during installation of potentially system-breaking changes.

I don't understand this apparent resistance to simply printing a warning about hostname/dnsdomainame during net-tools installation?

It can be something as short as: hostname and dnsdomainname have been removed from net-tools, please see http://www.archlinux.org/news/deprecation-of-net-tools/

Why is this such a problem?
Comment by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 15:48 GMT
Tom, Gaetan,

I took a second look at the Fedora link you provided and in fact they DO NOT use hostname from coreutils. So Arch will indeed be incompatible with all major distros if it decides to use hostname from coreutils.

If you look further down in the Fedora coreutils.spec you will find this:

----------------------------
# These come from util-linux and/or procps.
for i in hostname uptime kill ; do
rm $RPM_BUILD_ROOT{%_bindir/$i,%_mandir/man1/$i.1}
done
---------------------------

So as you can see they in fact remove /bin/hostname from the coreutils build before packaging it, and they explicitly state that they expect "hostname" to be supplied by some other package.

Digging further, you will see that their "hostname" does not come from net-tools either:

http://pkgs.fedoraproject.org/gitweb/?p=net-tools.git;a=blob;f=net-tools.spec;h=3c0520e88fd325e993663cd0eb7be906019bd334;hb=HEAD

-------------------
#remove hostname (has its own package)
rm %{buildroot}/bin/dnsdomainname
rm %{buildroot}/bin/domainname
rm %{buildroot}/bin/hostname
rm %{buildroot}/bin/nisdomainname
rm %{buildroot}/bin/ypdomainname
------------------

As you can see, they expect all these hostname related tools to come from a third package called "hostname". Now if you look inside that package:

http://pkgs.fedoraproject.org/gitweb/?p=hostname.git;a=blob;f=hostname.spec;h=c80d2b05ee17d8dca948a447d1aaaec9f0ca59dc;hb=HEAD

you will see that its source code ultimately comes from Debian:

http://packages.qa.debian.org/h/hostname.html

I downloaded this Debian package and confirmed that the "hostname" command indeed supports the -f option, so it is functionally equivalent to the one from net-tools. In fact it's very likely that Debian took the hostname-related tools from net-tools and assigned someone to properly maintain them.
Comment by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 15:49 GMT
I rebuilt net-tools with dnsdomainname, and a short notice about the change. This will probably hit testing soon.

@Ivan: it is not a problem to print a warning. It is a judgement call when we package whether or not to do it (if we add too many people will not read them all). However, we _do_ expect people to follow the announcements, so complaining about this after the package has left [testing] is not very helpful.

What to do with hostname is still being discussed. Please open a new bug report if you want to track it, but this time please try to be concise and restrain yourself in your comments, as your flaming is deterring other devs from joining the discussion. We want to fix all bugs, just provide the technical details, and we will do our best.

Loading...