Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-09 14:11:09 +0200, Vincent Lefevre wrote: After installing the new kernel 2.6.39-2-amd64 and rebooting, I got in /var/log/boot: Thu Jun 9 13:41:49 2011: Starting web server: apache2apache2: apr_sockaddr_info_get() failed for ypig Thu Jun 9 13:41:51 2011: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Thu Jun 9 13:41:51 2011: . Same problem just after I installed the new kernel linux-image-3.0.0-1-amd64 and rebooted. I also had the same problem on Jul 22 (though I hadn't changed the kernel). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
retitle 629899 ap_get_local_host is broken (can't always determine the server's FQDN) severity 629899 important thanks with potential security implications (depending on what Apache does with the FQDN). After reading the source, it appears that the ap_get_local_host function in server/util.c is broken: it uses apr_sockaddr_info_get to get the FQDN (thus does a network access) instead of using gethostbyname (possibly an APR limitation); if gethostbyname is not available on some systems, Apache could still use the current method. On my machine, the FQDN is specified via /etc/hosts, thus doesn't depend on the network being set up. For instance, here we apparently have dynamic DNS set-up, so that resolving the host name during the boot via the DNS system may fail because the request is done too early after the DHCP client has started. Moreover, from a security point of view, it is a bad idea to use the DNS system when the FQDN is defined locally, because the DNS system may give incorrect information (e.g. when connecting via a public access point). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
Package: apache2.2-common Version: 2.2.19-1 Severity: normal After installing the new kernel 2.6.39-2-amd64 and rebooting, I got in /var/log/boot: Thu Jun 9 13:41:49 2011: Starting web server: apache2apache2: apr_sockaddr_info_get() failed for ypig Thu Jun 9 13:41:51 2011: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Thu Jun 9 13:41:51 2011: . This error didn't occur with previous kernels, and doesn't occur after a manual restart with: /etc/init.d/apache2 restart My /etc/hosts contains: 127.0.0.1 localhost 127.0.1.1 ypig.lip.ens-lyon.frypig # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters and /etc/nsswitch.conf contains the line: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 -- Package-specific info: List of enabled modules from 'apache2 -M': alias auth_basic authn_file authz_default authz_groupfile authz_host authz_svn authz_user autoindex cgi cgid dav dav_svn deflate dir env mime negotiation perl python reqtimeout setenvif status -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2 depends on: ii apache2-mpm-worker2.2.19-1 Apache HTTP Server - high speed th ii apache2.2-common 2.2.19-1 Apache HTTP Server common files apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.19-1 utility programs for webservers ii apache2.2-bin 2.2.19-1 Apache HTTP Server common binary f ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii mime-support 3.51-1 MIME files 'mime.types' 'mailcap ii perl 5.12.3-7 Larry Wall's Practical Extraction ii procps1:3.2.8-10 /proc file system utilities Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.28 simple debconf wrapper for OpenSSL Versions of packages apache2.2-common suggests: ii apache2-doc 2.2.19-1 Apache HTTP Server documentation pn apache2-suexec | ap none (no description available) ii chromium [www-brows 11.0.696.71~r86024-1 Chromium browser ii epiphany-browser [w 2.30.6-2 Intuitive GNOME web browser ii iceape-browser [www 2.0.14-2 Iceape Navigator (Internet browser ii iceweasel [www-brow 3.5.19-2 Web browser based on Firefox ii links [www-browser] 2.3~pre1-1+b1Web browser running in text mode ii links2 [www-browser 2.3~pre1-1+b1Web browser running in both graphi ii lynx-cur [www-brows 2.8.8dev.8-1 Text-mode WWW Browser with NLS sup ii midori [www-browser 0.3.6-1 fast, lightweight graphical web br ii uzbl [www-browser] 0.0.0~git.20110412-1 Lightweight Webkit browser followi ii w3m [www-browser] 0.5.3-2+b1 WWW browsable pager with excellent -- 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
I've run into the same problem recently upgrading to Linux 2.6.38 on my home's computer. Symptoms are the shell prompt doesn't show the hostname I had assigned at install time, being the hostname displayed instead then one passed through dhcp by the router. A similar problem doesn't occur at work where we run our own dhcp server and names passed by dhcp match consistently the ones in /etc/hosts Could a possible explanation for the workaround you found a latency in the dhcp negotiation at boot time? I mean that by the time apache2 is started the interface could be not yet configured and the name 'ypig' not yet assigned to it. By the time you manually restart apache2 the interface is most likely configured and the problem goes away. If my hypothesis is correct the bug should be filed against the kernel e/o the libc packages. hoping to be helpful -- Massimo On 06/09/2011 02:11 PM, Vincent Lefevre wrote: Package: apache2.2-common Version: 2.2.19-1 Severity: normal After installing the new kernel 2.6.39-2-amd64 and rebooting, I got in /var/log/boot: Thu Jun 9 13:41:49 2011: Starting web server: apache2apache2: apr_sockaddr_info_get() failed for ypig Thu Jun 9 13:41:51 2011: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Thu Jun 9 13:41:51 2011: . This error didn't occur with previous kernels, and doesn't occur after a manual restart with: /etc/init.d/apache2 restart My /etc/hosts contains: 127.0.0.1 localhost 127.0.1.1 ypig.lip.ens-lyon.fr ypig # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters and /etc/nsswitch.conf contains the line: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-09 14:41:45 +0200, Massimo Manghi wrote: I've run into the same problem recently upgrading to Linux 2.6.38 on my home's computer. Symptoms are the shell prompt doesn't show the hostname I had assigned at install time, being the hostname displayed instead then one passed through dhcp by the router. A similar problem doesn't occur at work where we run our own dhcp server and names passed by dhcp match consistently the ones in /etc/hosts Could a possible explanation for the workaround you found a latency in the dhcp negotiation at boot time? Here DHCP *must not* be used to determine the FQDN. It is specified locally in the /etc/hosts file. This is important, in particular because one may want to run local services depending on it even when the external network is not available (the administrator may choose to use DHCP for the FQDN, but should not be forced to). I mean that by the time apache2 is started the interface could be not yet configured and the name 'ypig' not yet assigned to it. By the time you manually restart apache2 the interface is most likely configured and the problem goes away. If my hypothesis is correct the bug should be filed against the kernel e/o the libc packages. I tried to do an strace to see what was used by apache, but it didn't succeed. I have a laptop with the 2.6.39-1-amd64 kernel where DHCP is not used and /etc/hosts is sufficient to determine the FQDN. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 06/09/2011 03:32 PM, Vincent Lefevre wrote: On 2011-06-09 14:41:45 +0200, Massimo Manghi wrote: I've run into the same problem recently upgrading to Linux 2.6.38 on my home's computer. Symptoms are the shell prompt doesn't show the hostname I had assigned at install time, being the hostname displayed instead then one passed through dhcp by the router. A similar problem doesn't occur at work where we run our own dhcp server and names passed by dhcp match consistently the ones in /etc/hosts Could a possible explanation for the workaround you found a latency in the dhcp negotiation at boot time? Here DHCP *must not* be used to determine the FQDN. It is specified locally in the /etc/hosts file. This is important, in particular because one may want to run local services depending on it even when the external network is not available (the administrator may choose to use DHCP for the FQDN, but should not be forced to). I agree with what you say and it doesn't rule out my hypothesis. I don't mean dhcp is needed, what I meant is that the problem is in the way the hostname and domain are fetched from the configuration. Using DHCP was illuminating because I was able to tell where the hostname returned came from (and didn't come from /etc/hosts as expected) More specifically: definitions in /etc/hosts (that were part of the determination of the name returned by 'gethostname' prior to the kernel upgrade) are now are ignored and the proof is that not only Apache is affected but also other applications. Once again my question is: should the bug be moved against the kernel or libc? -- Massimo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-09 15:46:40 +0200, Massimo Manghi wrote: I agree with what you say and it doesn't rule out my hypothesis. I don't mean dhcp is needed, what I meant is that the problem is in the way the hostname and domain are fetched from the configuration. Using DHCP was illuminating because I was able to tell where the hostname returned came from (and didn't come from /etc/hosts as expected) OK. More specifically: definitions in /etc/hosts (that were part of the determination of the name returned by 'gethostname' prior to the kernel upgrade) are now are ignored and the proof is that not only Apache is affected but also other applications. You may see a different bug. On my machine, /etc/hosts is used by both my fqdn program[*] and by ping. Indeed, just after changing ypig.lip.ens-lyon.fr to ypig-test.lip.ens-lyon.fr in /etc/hosts, I get: ypig:~ fqdn Nodename: ypig FQDN: ypig-test.lip.ens-lyon.fr ypig:~ ping ypig PING ypig-test.lip.ens-lyon.fr (127.0.1.1) 56(84) bytes of data. 64 bytes from ypig-test.lip.ens-lyon.fr (127.0.1.1): icmp_req=1 ttl=64 time=0.029 ms [...] But how can I see what Apache chooses? [*] #!/usr/bin/env perl use strict; use POSIX; my $nodename = (POSIX::uname)[1]; print Nodename: $nodename\n; my @ghbn = gethostbyname $nodename; print FQDN: $ghbn[0]\n; Once again my question is: should the bug be moved against the kernel or libc? Definitely not the kernel or libc, unless something wrong occurs at boot time. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On Thu, 9 Jun 2011 16:08:49 +0200, Vincent Lefevre wrote: Definitely not the kernel or libc, unless something wrong occurs at boot time. It's probably so, because I don't see why apache2 is getting it right after the boot is over and you have gained access to the shell. That's why I thought you were using dhcp at first. -- Massimo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-09 15:20:00 +0100, Massimo Manghi wrote: On Thu, 9 Jun 2011 16:08:49 +0200, Vincent Lefevre wrote: Definitely not the kernel or libc, unless something wrong occurs at boot time. It's probably so, because I don't see why apache2 is getting it right after the boot is over and you have gained access to the shell. That's why I thought you were using dhcp at first. Yes, I confirm a possible problem with a recent libc or kernel at boot time, but this isn't related to DHCP. On my laptop, on which I do not use DHCP when I'm at home, with the kernel 2.6.38-2: Thu Mar 31 21:53:49 2011: Starting HTTP cache proxy server: wwwoffled (offline mode) done. and with the kernel 2.6.39-1: Sun Jun 5 22:50:14 2011: Starting HTTP cache proxy server: wwwoffled wwwoffled[5199] Warning: Failed to get name/IP address for host 'xvii' [No address associated with hostname]. Sun Jun 5 22:50:14 2011: (offline mode) done. and no problems with a manual restart. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On Thu, 9 Jun 2011 16:40:07 +0200, Vincent Lefevre wrote: On 2011-06-09 15:20:00 +0100, Massimo Manghi wrote: On Thu, 9 Jun 2011 16:08:49 +0200, Vincent Lefevre wrote: Definitely not the kernel or libc, unless something wrong occurs at boot time. It's probably so, because I don't see why apache2 is getting it right after the boot is over and you have gained access to the shell. That's why I thought you were using dhcp at first. Yes, I confirm a possible problem with a recent libc or kernel at boot time, but this isn't related to DHCP. I have no doubt: this has nothing to do with DHCP per se. DHCP was useful to understand that gethostname (or uname) is not working properly. I looked up a possible bug already in the database against libc6 or the kernel-image, but I haven't found any. I think the bug should have 'critical' as severity, since it can break applications started at boot time that relay on the FQDN to work properly. On my laptop, on which I do not use DHCP when I'm at home, with the kernel 2.6.38-2: Thu Mar 31 21:53:49 2011: Starting HTTP cache proxy server: wwwoffled (offline mode) done. and with the kernel 2.6.39-1: Sun Jun 5 22:50:14 2011: Starting HTTP cache proxy server: wwwoffled wwwoffled[5199] Warning: Failed to get name/IP address for host 'xvii' [No address associated with hostname]. Sun Jun 5 22:50:14 2011: (offline mode) done. and no problems with a manual restart. If this is the case the kernel-image package must clearly be the targed of the bug report. Do you want to file it yourself? This bug (#629899) could be merged later with it as soon as it's been registered in the database. -- Massimo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-09 16:09:29 +0100, Massimo Manghi wrote: On Thu, 9 Jun 2011 16:40:07 +0200, Vincent Lefevre wrote: On 2011-06-09 15:20:00 +0100, Massimo Manghi wrote: It's probably so, because I don't see why apache2 is getting it right after the boot is over and you have gained access to the shell. That's why I thought you were using dhcp at first. Yes, I confirm a possible problem with a recent libc or kernel at boot time, but this isn't related to DHCP. I have no doubt: this has nothing to do with DHCP per se. DHCP was useful to understand that gethostname (or uname) is not working properly. Actually I don't think this is the same bug. I cannot reproduce this bug 629899 concerning apache2, while the bug with wwwoffle has occurred every time since I upgraded to libc6 2.13. and with the kernel 2.6.39-1: Sun Jun 5 22:50:14 2011: Starting HTTP cache proxy server: wwwoffled wwwoffled[5199] Warning: Failed to get name/IP address for host 'xvii' [No address associated with hostname]. Sun Jun 5 22:50:14 2011: (offline mode) done. After I looked in the logs, I got this actually for the first time after I upgraded to libc6 2.13. If this is the case the kernel-image package must clearly be the targed of the bug report. Do you want to file it yourself? This bug (#629899) could be merged later with it as soon as it's been registered in the database. I've reported the wwwoffle problem against wwwoffle because apache2 on the same machine doesn't have any problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629923 wwwoffle may do something special, and the maintainer could reassign the bug to libc6 (with a testcase) if it appears that the problem comes from libc6. I suggest that you report a bug for the problem you get. If you can reproduce it, you'll have at least more information than me... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On Thu, 9 Jun 2011 19:27:23 +0200, Vincent Lefevre wrote: On 2011-06-09 16:09:29 +0100, Massimo Manghi wrote: On Thu, 9 Jun 2011 16:40:07 +0200, Vincent Lefevre wrote: On 2011-06-09 15:20:00 +0100, Massimo Manghi wrote: It's probably so, because I don't see why apache2 is getting it right after the boot is over and you have gained access to the shell. That's why I thought you were using dhcp at first. Yes, I confirm a possible problem with a recent libc or kernel at boot time, but this isn't related to DHCP. I have no doubt: this has nothing to do with DHCP per se. DHCP was useful to understand that gethostname (or uname) is not working properly. Actually I don't think this is the same bug. I cannot reproduce this bug 629899 concerning apache2, while the bug with wwwoffle has occurred every time since I upgraded to libc6 2.13. OK. Wasn't this bug filed against apache2.2-common? Anyway I expect every application based on apr calling apr_sockaddr_info_get to fail with a similar reason. and with the kernel 2.6.39-1: Sun Jun 5 22:50:14 2011: Starting HTTP cache proxy server: wwwoffled wwwoffled[5199] Warning: Failed to get name/IP address for host 'xvii' [No address associated with hostname]. Sun Jun 5 22:50:14 2011: (offline mode) done. After I looked in the logs, I got this actually for the first time after I upgraded to libc6 2.13. I've reported the wwwoffle problem against wwwoffle because apache2 on the same machine doesn't have any problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629923 wwwoffle may do something special, and the maintainer could reassign the bug to libc6 (with a testcase) if it appears that the problem comes from libc6. I suggest that you report a bug for the problem you get. If you can reproduce it, you'll have at least more information than me... I would file it against libc6 because my conjecture is that different components layered on libc6 are failing when they probably call something like uname or gethostname. I cannot image what apr_* and tcsh have in common except for libc6 when they are unable to determine the correct hostname. Anyway, the bug seems not to be reproducible, not in a deterministic way at least: tonight I booted my home machine and the hostname was displayed correctly. I'll keep an eye on it to see if it shows up again. -- Massimo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN
On 2011-06-10 00:05:31 +0100, Massimo Manghi wrote: On Thu, 9 Jun 2011 19:27:23 +0200, Vincent Lefevre wrote: Actually I don't think this is the same bug. I cannot reproduce this bug 629899 concerning apache2, while the bug with wwwoffle has occurred every time since I upgraded to libc6 2.13. OK. Wasn't this bug filed against apache2.2-common? I did reportbug apache2, but the bug was indeed files against apache2.2-common. Anyway I expect every application based on apr calling apr_sockaddr_info_get to fail with a similar reason. I filed a second bug against wwwoffle (which isn't based on libapr, BTW). [...] wwwoffle may do something special, and the maintainer could reassign the bug to libc6 (with a testcase) if it appears that the problem comes from libc6. I suggest that you report a bug for the problem you get. If you can reproduce it, you'll have at least more information than me... I would file it against libc6 because my conjecture is that different components layered on libc6 are failing when they probably call something like uname or gethostname. Perhaps, but one needs to know precisely which function is failing. I doubt the libc6 developers know the wwwoffle internals. I upgraded another machine (kernel and libc6), and this time, that's spamassassin that was affected (spamassassin was not upgraded between the two reboots). But again, I don't know whether this is related to the problems with apache2 and wwwoffle (apparently not a hostname problem, but still network related). Just in case: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629984 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire 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
