Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On Mon, Jul 28, 2014 at 03:40:46PM +0200, Joachim Breitner wrote: > Unfortunately, the upstream author believes that programs expecting a > fully qualified domain names to exist are broken. So I guess we should > add a conflicts to affected packages. One of the affected packages happens to be Debian's default MTA. If the exim maintainers add that conflicts, you can most probably directly pull the package from Debian. Do you want that? fwiw, this bug has wasted about an hour of my time in handling exim4 "bugs" this week alone. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Still not added as a conflict with exim4, I believe (at least not reported by apt-listbugs to me): > What programs are affected? exim4 > What precisely do these program look up, what do they expect, and what > do they get with libnss-myhostname? After installing libnss-myhostname, exim failed to send emails, the receiving smtp servers said: 2016-05-25 09:26:37 [...]: 504 5.5.2 : Helo command rejected: need fully-qualified hostname > Did they previously work out-of-the box without libnss-myhostname and an > unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add > the FQDN there)? Worked until the day libnss-myhostname was installed, worked again after removing it. > If so, what happens if you still add them to /etc/hosts? My /etc/hosts looks like this, "hostname -f" gave the FQDN with and without libnss-myhostname: 127.0.0.1 localhost 134.76.21.124 my-not-full-name.gwdg.de my-not-full-name # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters -- Max-Planck-Institute for Dynamics and Self-Organization Research Group Biomedical Physics Am Fassberg 17 D-37077 Goettingen (+49) 551 5176 373 You can obtain my public key 0xF197B128 from all keyservers, e.g. pgp.mit.edu Fingerprint: 9698 BDD4 71CC 1274 B7E2 2049 1EDD 012D F197 B128 signature.asc Description: This is a digitally signed message part.
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. DHCP almost always hands out a domain which is used to create an FQDN for devices connected to that network. If the DHCP server does not auto-update the DNS server with the client supplied hostname from the laptop then it is possible you will fail to have DNS resolution but that is because DNS doesn't know about your laptop not because you don't and/or can't have an FQDN. The issue with laptops and mobile devices is not that that they do not have a domain (and hence FQDN) but that not all routers automatically create local DNS entries AND the domain depends on what work the device is attached to and hence is a changeable beast. From the perspective of the network administrator of properly administred network the FQDN makes perfect sense, the issue is that on a lot of home networks the FQDN is of little value - OTOH the hostname is also of little or no value on such network and really that isn't a good argument for ditching FQDN. The changeable nature of FQDN for mobile devices means that it would be silly to rely on client-reported FQDN without some sort of verification of the device, but that is an entirely separate issue from having an FQDN in the first place. The fact is that any argument against FQDN on a mobile device could be made about hostname on mobile device. So forget about mobile devices in the argument and consider that lack of FQDN breaks important and core things like email on permanently connected networks. Dealing with mobile devices is what things like SMTP-AUTH are for, but that does not invalidate the usefulness or importance of FQDN as a concept nor as something that should be considered broken any more than hostnames themselves. Regards, Daniel Re signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 08/09/14 01:18 PM, Daniel Dickinson wrote: I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Sorry, I meant completely different... Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 08/09/14 01:18 PM, Daniel Dickinson wrote: I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). They are completely configuration items in the dhclient and similar tools. Speaking of which, perhaps to resolve this libnss-myhostname issue perhaps libnss-myhostname should *only* touch hostname and have a separate libnss-mydomain for getting FQDN via same mechanism, in the absence of it being defined elsewhere (like DHCP), though obviously myhostname and mydomain shouldn't be lowest on the totem pole. Regards, Daniel Regards, Daniel On 08/09/14 05:54 AM, Vincent Lefevre wrote: On 2014-09-08 04:53:08 -0400, Daniel Dickinson wrote: On 28/07/14 09:40 AM, Joachim Breitner wrote: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Actually unless your laptop is not connected to a network via DHCP there is a 90% probability that if libnss-hostname is not installed that you will resolve to DHCP-hostname.DHCP-handed-out-domain. I disagree on this probability. At the Debian installation, the FQDN (specified at the installation) is put in /etc/hosts on the 127.0.1.1 line (unless this has changed recently). This means that the nodename will resolve to the configured FQDN and won't depend on DHCP, unless the DHCP client has been configured to update the nodename from the DHCP server, which is a very bad idea as this breaks various programs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635322 Well, that's for IPv4. I'm wondering whether there's a glibc bug, which does not make the nodename resolvable with IPv6 via files as well. Otherwise one might be able to see problems similar to what libnss-hostname gives. signature.asc Description: OpenPGP digital signature
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-09-08 13:18:17 -0400, Daniel Dickinson wrote: I think you're wrong. Setting hostname via dhcp (usually not enabled) is different than getting domain from dhcp (usually enabled AIUI). I meant that if the hostname (nodename) is not changed, then it will resolve with the right domain via /etc/hosts, which may be different from the domain obtained via DHCP. And I could verify that with my laptop, while I connected to many wifi access points. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-07-28 15:40:46 +0200, Joachim Breitner wrote: Unfortunately, the upstream author believes that programs expecting a fully qualified domain names to exist are broken. In any case, this is unrelated to the problem here. Without libnss-myhostname, there was a working FQDN on my machine. After libnss-myhostname got installed (automatically, due to some dependency), exim4 failed to provide the FQDN, just the short name. It shouldn't have broken a correctly configured machine! So I guess we should add a conflicts to affected packages. Please, conflict with exim4. Otherwise the issue remains unnoticed by apt-listbugs. BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. You may find the concept dubious on a laptop (though setting up a resolvable FQDN is very easy for programs that need one), but libnss-myhostname also breaks machines on a fixed network with a FQDN resolvable everywhere. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Control: tag -1 + help Hi, Am Dienstag, den 02.09.2014, 17:43 +0200 schrieb Vincent Lefevre: BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. You may find the concept dubious on a laptop (though setting up a resolvable FQDN is very easy for programs that need one), but libnss-myhostname also breaks machines on a fixed network with a FQDN resolvable everywhere. yes, that shouldn’t happen. I need to investigate this carefully (but that won’t happen for at least one week or more). Also it seems that upstream has stopped publishing nss-myhostname release on their own; the code is part of systemd now. Maybe the systemd source package should build libnss-myhostname. Anyways, I’m happy to receive help maintaining this package! Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-07-29 23:27:27 +0200, Joachim Breitner wrote: So what is the suggested fix? I would say: if there is already a FQDN[*] without libnss-myhostname, then do not try to change anything. Really, users should have a (locally) resolvable FQDN by default e.g. just with something like: 127.0.1.1 nodename.domain.tld nodename in the /etc/hosts file (if the user doesn't own a domain and doesn't have a fixed FQDN assigned by the network provider, he can choose an arbitrary value, but it should be used only locally and/or with the SMTP smarthost of his ISP). [*] not necessarily resolvable, because this may occur during a temporary network problem. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Dienstag, den 02.09.2014, 18:00 +0200 schrieb Vincent Lefevre: On 2014-07-29 23:27:27 +0200, Joachim Breitner wrote: So what is the suggested fix? I would say: if there is already a FQDN[*] without libnss-myhostname, then do not try to change anything. Really, users should have a (locally) resolvable FQDN by default e.g. just with something like: 127.0.1.1 nodename.domain.tld nodename in the /etc/hosts file (if the user doesn't own a domain and doesn't have a fixed FQDN assigned by the network provider, he can choose an arbitrary value, but it should be used only locally and/or with the SMTP smarthost of his ISP). Well, if you have that in /etc/hosts, you don’t need libnss-myhostname. The whole point of the package is that you do _not_ need a /etc/hosts. Maybe something about the order in /etc/nsswitch.conf can be tweaked. But note that this was changed in 0.3-1: Install myshostname directly after files in /etc/nsswitch.conf. This avoids an annoying delay when dns fails and one wants to use sudo to fix it. Is also closer to having the hostname in /etc/hosts, which is the behaviour myhostname tries to mimic. Existing installations are not modified. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-09-02 17:49:10 +0200, Joachim Breitner wrote: yes, that shouldn’t happen. I need to investigate this carefully (but that won’t happen for at least one week or more). If I have some time, I'll try to see what happens. Also it seems that upstream has stopped publishing nss-myhostname release on their own; the code is part of systemd now. Maybe the systemd source package should build libnss-myhostname. This would probably be much better. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 2014-09-02 18:07:44 +0200, Joachim Breitner wrote: Well, if you have that in /etc/hosts, you don’t need libnss-myhostname. So, the Recommends: by gnome-control-center should be dropped. Then installing libnss-myhostname or not should be the job of the Debian installer, because /etc/hosts is created or not at this time. The whole point of the package is that you do _not_ need a /etc/hosts. Maybe something about the order in /etc/nsswitch.conf can be tweaked. I had files first in hosts: (I suppose that this corresponds to /etc/hosts), and still first after libnss-myhostname got installed. This means that libnss-myhostname overrode it. But I'll try to look what is done with strace. But note that this was changed in 0.3-1: Install myshostname directly after files in /etc/nsswitch.conf. This avoids an annoying delay when dns fails and one wants to use sudo to fix it. Is also closer to having the hostname in /etc/hosts, which is the behaviour myhostname tries to mimic. Existing installations are not modified. What does Existing installations are not modified. mean? I ask this because /etc/nsswitch.conf got modified. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname causes apps that need FQDN to fail
Put the FQDN into /etc/hostname
tom ~ # dpkg-query -W -f '${Status}\n' libnss-myhostname
install ok installed
tom ~ # cat /etc/hosts
127.0.0.1 localhost
tom ~ # cat /etc/hostname
tom.deb.sid
tom ~ # hostname
tom.deb.sid
tom ~ # hostname -s
tom
tom ~ # hostname -f
tom.deb.sid
tom ~ # hostname -d
deb.sid
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Dienstag, den 02.09.2014, 18:33 +0200 schrieb Vincent Lefevre: The whole point of the package is that you do _not_ need a /etc/hosts. Maybe something about the order in /etc/nsswitch.conf can be tweaked. I had files first in hosts: (I suppose that this corresponds to /etc/hosts), and still first after libnss-myhostname got installed. This means that libnss-myhostname overrode it. But I'll try to look what is done with strace. not sure what you mean. libnss-myhostname currently installs itself always directly after files. But note that this was changed in 0.3-1: Install myshostname directly after files in /etc/nsswitch.conf. This avoids an annoying delay when dns fails and one wants to use sudo to fix it. Is also closer to having the hostname in /etc/hosts, which is the behaviour myhostname tries to mimic. Existing installations are not modified. What does Existing installations are not modified. mean? I ask this because /etc/nsswitch.conf got modified. Existing installations of libnss-myhostname, i.e. if it is already present in /etc/nsswitch.conf. If you move it to the end of the line there, does it work better for you? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, On 2014-09-02 23:03:50 +0200, Joachim Breitner wrote: Am Dienstag, den 02.09.2014, 18:33 +0200 schrieb Vincent Lefevre: I had files first in hosts: (I suppose that this corresponds to /etc/hosts), and still first after libnss-myhostname got installed. This means that libnss-myhostname overrode it. But I'll try to look what is done with strace. not sure what you mean. libnss-myhostname currently installs itself always directly after files. I meant that I have hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 without libnss-myhostname, and hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4 with libnss-myhostname. In both cases, files has the precedence over everything else, and the FQDN can be obtained from /etc/hosts, so that it is strange that libnss-myhostname changes the behavior. See below for the explanation. What does Existing installations are not modified. mean? I ask this because /etc/nsswitch.conf got modified. Existing installations of libnss-myhostname, i.e. if it is already present in /etc/nsswitch.conf. What if libnss-myhostname is installed but the user has removed myhostname from /etc/nsswitch.conf? If you move it to the end of the line there, does it work better for you? No, same problem with: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 myhostname With strace -o strace.out exim4 -bP, I can see that /etc/hosts is read, but I don't know whether this is meaningful. Exim does the following: it first calls gethostbyname2(nodename, AF_INET6) and if it returns NULL, it calls gethostbyname2(nodename, AF_INET) When myhostname is not used, the first call (with AF_INET6) fails (because in /etc/hosts, only IPv4 is set up as this is sufficient locally), and the second call returns the FQDN ypig.lip.ens-lyon.fr. When myhostname is used, the first call succeeds, but once just gets ypig. So, the problem seems to be that myhostname adds a host for IPv6, overriding the IPv4 user's /etc/hosts setting when IPv6 is tried first. IMHO, before changing anything, libnss-myhostname should first detect whether the nodename is resolvable with either IPv4 or IPv6 (checking for IPv4 only should be sufficient in practice, but this might change in a distant future once IPv4 has disappeared). If it is, then it should not change anything. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname causes apps that need FQDN to fail
On 2014-09-02 15:29:28 -0400, Tom H wrote: Put the FQDN into /etc/hostname No, that's not the usual way of configuring the machine. Some software may break. FYI, the hostname(1) man page says: /etc/hostname Historically this file was supposed to only contain the hostname and not the full canonical FQDN. Nowadays most software is able to cope with a full FQDN here. This file is read at boot time by the system initialization scripts to set the hostname. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname causes apps that need FQDN to fail
On 2014-09-03 02:04:58 +0200, Vincent Lefevre wrote: On 2014-09-02 15:29:28 -0400, Tom H wrote: Put the FQDN into /etc/hostname No, that's not the usual way of configuring the machine. Some software may break. FYI, the hostname(1) man page says: /etc/hostname Historically this file was supposed to only contain the hostname and not the full canonical FQDN. Nowadays most software is able to cope with a full FQDN here. This file is read at boot time by the system initialization scripts to set the hostname. Moreover, I've just tried with exim, and this doesn't work: ypig:~ cat /etc/hostname ypig.lip.ens-lyon.fr ypig:~ exim4 -bP | grep '^primary' primary_hostname = ypig instead of the FQDN. This confirms that hacks are bad ideas. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
For me the installation of libnss-myhostname as a Recommends of gnome-control-center broke local mail delivery to a smart host using aliases in /etc/aliases and exim. Purging libnss-myhostname fixes the problem. Interesting is that the position of myhostname in the following ~$ grep myhostname /etc/nsswitch.conf hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4 ~$ contradicts the recommendation in /usr/share/doc/libnss-myhostname/README.gz: It is recommended to put myhostname last in the nsswitch.conf line to make sure that this mapping is only used as fallback, and any DNS or /etc/hosts based mapping takes precedence. Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Package: libnss-myhostname Version: 0.3-9 Followup-For: Bug #756224 Dear Maintainer, * What led up to the situation? upgrading my testing system yesterday * What exactly did you do (or not do) that was effective (or ineffective)? only normal upgrade and it looks gnome-control-center pull libnss-myhostname * What was the outcome of this action? since upgrade, every comming emails are frozen and not delivered * What outcome did you expect instead? want to read email as usual! After investigating upgraded packages, I suspect libnss-myhostname might be culprit. And after removing it, emails are delivered. Error messages looks lowest numbered MX record points to local host. But the problem occurs only on a system where exim4 is configured as internet site, as smart host (the machine runs as a smart host for other machines), deliver emails with procmail to my other machines. Other machines which get emails by procmail or fetchmail work fine. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnss-myhostname depends on: ii libc6 2.19-7 ii multiarch-support 2.19-7 libnss-myhostname recommends no packages. libnss-myhostname suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Dienstag, den 29.07.2014, 00:22 -0400 schrieb Daniel Dickinson: Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. and I won’t discuss technical issues on this level. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Fair enough, but the argument seems to consist of 'if you don't obey the rules bad behaviour results, ergo the rule is bad' which is kind of like arguing that making people obey the law is bad because some people got to jail. Basically the arguments are political not technical, even if it is dressed up as technical, which is why the arguments end up being political. Regards, Daniel On 29/07/14 03:22 AM, Joachim Breitner wrote: Hi, Am Dienstag, den 29.07.2014, 00:22 -0400 schrieb Daniel Dickinson: Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. and I won’t discuss technical issues on this level. Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Here is a specific for-instance: Evolution does not send a FQDN in EHLO unless it has an FQDN. Postfix for example is generally configured to require an FQDN from email sender (as a spam prevention measure). Therefore sending mail from Evolution via a reasonably configured Postfix fails with libnss-myhostname. Regards, Daniel On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Might I add that even Winblows systems that are attached to a network with DHCP-supplied domain name (or which are configured manually with a domain name and use static addresses) have FQDN's The only things that don't have FQDN on normal networks are link-local networks and brokenly configured *nix systems (or systems not actually on a network). Also there seems to be some trouble so at risk of repeating mysql: Evolution fails to send FQDN in EHLO to SMTP server when using libnss-hostname. This break SMTP to sites that require FQDN (which is a common spam prevention measure). Regards, Daniel On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Dienstag, den 29.07.2014, 11:10 -0400 schrieb Daniel Dickinson: Here is a specific for-instance: Evolution does not send a FQDN in EHLO unless it has an FQDN. Postfix for example is generally configured to require an FQDN from email sender (as a spam prevention measure). Therefore sending mail from Evolution via a reasonably configured Postfix fails with libnss-myhostname. thanks; that is a concrete example, and I find reports of this problem. So what is the suggested fix? It would be interesting to see what happens in Fedora (which usually support GNOME well, and possibly have libnss-myhostname by default). It wold also be interesting to see if the libnss-myhostname code included in the systemd code base has this fixed. There is a longish thread on d-devel about /etc/hosts: https://lists.debian.org/debian-devel/2013/07/msg00809.html But it does not touch on the issue of the FQDN. I guess we want libnss-myhostname to do whatever the default installation does right now... What would be a precise specification of that? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Please note there are other 'basic networking type apps (which is what I consider email/postfix)' that break without FQDN I just cannot remember the details since at the time I was more concerned with getting my network behaving and I thought libnss-myhostname was a fringe project that sounded good but wasn't worth pursuing or spending time on because of the issues that became readily apparent. I guess it's not as fringe as I thought and should have filed bug reports then. On Sun, 2014-07-27 at 20:25 +0200, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
On 27/07/14 02:25 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? I don't remember exactly which ones they were; there were a few and it was a hard to debug problem. I think one of them may have been amanda. I ditched libnss-hostname which I was installing myself sometime ago because of this issue. What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? They look up a hostname using glibc. You can get the same result by doing hostname --fqdn and observing that there is no domain part to returned hostname. THIS IS BROKEN. --fqdn should *always* have a domain part. Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? They worked out-of-the box without libnss-myhostname, with the DNS setup I had. If so, what happens if you still add them to /etc/hosts? It is actually the local hostname that is the issue and I have actually tried modifying /etc/hosts with ip-address name.domain name however hostname --fqdn *still* returns name with NO domain. libnss-hostname is BROKEN WRT to FQDN. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Yeah but the guy claiming FQDN broken is the same Lennart who seems hell bent on destroying every *nix idiom. I wouldn't go by his opinion. Regards, Daniel On 28/07/14 09:40 AM, Joachim Breitner wrote: Hi, Am Montag, den 28.07.2014, 09:21 -0400 schrieb Daniel Dickinson: On 27/07/14 02:25 PM, Joachim Breitner wrote: They look up a hostname using glibc. You can get the same result by doing hostname --fqdn and observing that there is no domain part to returned hostname. THIS IS BROKEN. --fqdn should *always* have a domain part. Thanks. I can reproduce it here. It is actually the local hostname that is the issue and I have actually tried modifying /etc/hosts with ip-address name.domain name however hostname --fqdn *still* returns name with NO domain. libnss-hostname is BROKEN WRT to FQDN. Unfortunately, the upstream author believes that programs expecting a fully qualified domain names to exist are broken. So I guess we should add a conflicts to affected packages. If this causes problems with other packages depending on libnss-hostname, then maybe the dependency needs to be revisited. BTW, what should the FQDN even be here? My laptop doesn’t have a FQDN that resolves to it, so the concept seems to be dubious at least. Related references: https://bugzilla.redhat.com/show_bug.cgi?id=726054 Greetings, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). This is now pulled in by Gnome which means it's bad behviour will break a lot of people -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnss-myhostname depends on: ii libc6 2.19-7 ii multiarch-support 2.19-7 libnss-myhostname recommends no packages. libnss-myhostname suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756224: libnss-myhostname: Causes apps that need FQDN to fail
Hi, Am Sonntag, den 27.07.2014, 13:53 -0400 schrieb Daniel Dickinson: Package: libnss-myhostname Version: 0.3-6 Severity: serious Takes over names resolution of local host's name and causes apps that need FQDN instead of just hostname to fail (becuase myhostname fails to include a domain). Can you explain the problems in more detai: What programs are affected? What precisely do these program look up, what do they expect, and what do they get with libnss-myhostname? Did they previously work out-of-the box without libnss-myhostname and an unmodified /etc/hosts, or did you have to modify /etc/hosts (i.e. add the FQDN there)? If so, what happens if you still add them to /etc/hosts? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
