Bug#508144: bad description of libapr1-dbg

Package: libapr1-dbg Version: 1.2.12-5 Severity: minor The current description of libapr1-dbg is: The Apache Portable Runtime Library - Development Headers It should be something like: The Apache Portable Runtime Library - debugging symbols -- System Information: Debian Release: 5.0 APT

Bug#508145: bad description of libaprutil1-dbg

Package: libaprutil1-dbg Version: 1.2.12+dfsg-8 Severity: minor The current description of libaprutil1-dbg is: The Apache Portable Runtime Utility Library - Development Headers It should be something like: The Apache Portable Runtime Utility Library - debugging symbols -- System

Bug#584298: apache2: Apache should not send a 304 response code if the Content-Type has changed

Package: apache2.2-common Version: 2.2.15-5 Severity: normal One can change the Content-Type of a file in the .htaccess, e.g. with ForceType. But if: 1. a browser sends a request corresponding to some file, 2. one changes the Content-Type of the file, 3. the browser sends another request

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

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

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

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

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

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

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

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

Bug#653801: apache2.2-common: typo in /etc/apache2/apache2.conf

Package: apache2.2-common Version: 2.2.21-5 Severity: minor In the /etc/apache2/apache2.conf file: # It is also possible to omit any default MIME type and let the # client's browser guess an appropriate action instead. Typically the # browser will decide based on the file's extension then. In

Bug#629899: ap_get_local_host is broken

Hi, On 2012-02-19 01:12:17 +, Jean-Michel Vourgère wrote: I recently found some strange behavior in dns resolution at boot time, when eth0 has no ipv4 yet. (#500558) Do you use DHCP for your other interface (eth0)? Yes. What is the result of `grep CONCURRENCY /etc/init.d/rc' ?

Bug#629899: ap_get_local_host is broken (can't always determine the server's FQDN)

retitle 629899 ap_get_local_host is broken (can't always determine the server's FQDN) thanks I'll try to do some tests when I have the time. But there's no reason eth0 would be IPv6 only here (unless there's a huge bug in the kernel). -- Vincent Lefèvre vinc...@vinc17.net - Web:

Bug#629899: ap_get_local_host is broken (can't always determine the server's FQDN)

On 2012-02-22 02:58:04 +, Jean-Michel Vourgère wrote: This bug is actually the same as 500558. Actually the error I get is different from the one in 500558. Note that in my case, apache2 starts, but without being able to get the fqdn. -- Vincent Lefèvre vinc...@vinc17.net - Web:

Bug#664867: libapr1: after upgrade to libapr1 1.4.6-1, properties in svn dump are in a random order

Package: libapr1 Version: 1.4.6-1 Severity: important After the upgrade to libapr1 1.4.6-1, the properties in the svn dump output are now in a random order. I don't think their order is specified, but IMHO, they should be in a consistent order to allow conventional tools like diff, MD5 checking

Bug#664867: libapr1: after upgrade to libapr1 1.4.6-1, properties in svn dump are in a random order

reassign 664867 libsvn1 found 664867 1.6.17dfsg-3 tags 664867 upstream forwarded 664867 http://subversion.tigris.org/issues/show_bug.cgi?id=4134 -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670518: apache2: should provide security information w.r.t. scripting modules

Package: apache2.2-common Version: 2.2.22-4 Severity: wishlist The latest upgrade has the following in the ChangeLog: apache2 (2.2.22-4) unstable; urgency=high * CVE-2012-0216: Remove Alias /doc /usr/share/doc from the default virtual hosts' config files. If scripting modules like

Bug#675184: apache2.2-common: ambiguous comment in /etc/apache2/apache2.conf

Package: apache2.2-common Version: 2.2.22-6 Severity: minor In /etc/apache2/apache2.conf, just after the upgrade: # * apache2.conf is the main configuration file (this file). It puts the pieces # together by including all remaining configuration files when starting up the # web server. # #

Bug#676975: apache2.2-common: contradictory comment in /etc/apache2/apache2.conf about the .load suffix

Package: apache2.2-common Version: 2.2.22-7 Severity: minor /etc/apache2/apache2.conf has the following comment: # Yet we strongly suggest that all configuration files either end with a # .conf or .load suffix in the file name. The next Debian release will # ignore files not ending with

Bug#676975: apache2.2-common: contradictory comment in /etc/apache2/apache2.conf about the .load suffix

On 2012-06-11 00:10:39 +0200, Arno Töll wrote: Hi, On 10.06.2012 23:49, Vincent Lefevre wrote: /etc/apache2/apache2.conf has the following comment: # Yet we strongly suggest that all configuration files either end with a # .conf or .load suffix in the file name. The next Debian

Bug#676975: apache2.2-common: contradictory comment in /etc/apache2/apache2.conf about the .load suffix

Hi Arno, On 2012-06-11 00:26:27 +0200, Arno Töll wrote: On 11.06.2012 00:23, Vincent Lefevre wrote: I'm not sure I've understood. You meant that 2.4 will still include /etc/apache2/mods-enabled/*.(conf|load)? Then... Yes. Right that. But it won't include conf.d/* at all (but conf-enabled

Bug#678740: apache2.2-common: bad comment in /etc/apache2/conf.d/security

Package: apache2.2-common Version: 2.2.22-8 Severity: minor /etc/apache2/conf.d/security contains: # Some browsers have a built-in XSS filter that will detect some cross site # scripting attacks. By default, these browsers the the suspicious part of

Bug#663530: apache2.2-common: Spurious warning NameVirtualHost *:80 has no VirtualHosts in cron/logrotate output

found 663530 2.2.22-11 thanks On 2012-03-12 01:45:12 +0100, Vincent Lefevre wrote: In the last cron output, I got: /etc/cron.daily/logrotate: [Sun Mar 11 05:00:44 2012] [warn] NameVirtualHost *:80 has no VirtualHosts This has just occurred again (perhaps for the second time since March 2012

Bug#663530: Spurious warning NameVirtualHost *:80 has no VirtualHosts in cron/logrotate output

Hi, On 2012-12-01 21:02:45 +, Jean-Michel Vourgère wrote: Do you still have the bug repported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663530 ? No, the last time I got it was on 13 August 2012. What is the content of your /etc/apache2/ports.conf file? It has: # If you just

Bug#716880: apache2 upgrade failed

Package: apache2 Version: 2.4.4-6 Severity: grave Justification: renders package unusable The apache2 upgrade failed: (Reading database ... 475293 files and directories currently installed.) Removing libapache2-svn ... Module authz_svn already disabled Module dav_svn already disabled Purging

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-06-11 10:02:21 +0200, Arno Töll wrote: # env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin /usr/sbin/apache2ctl configtest AH00526: Syntax error on line 1 of /etc/apache2/conf-enabled/apache2-doc.conf: Invalid command 'Alias', perhaps misspelled or defined by a module not

Bug#716880: apache2 upgrade failed

On 2013-07-14 01:51:55 +0200, Vincent Lefevre wrote: Package: apache2 Version: 2.4.4-6 Severity: grave Justification: renders package unusable The apache2 upgrade failed: [...] And when I tried to remove it, this failed: The following packages will be REMOVED: apache2* apache2-bin

Bug#716880: apache2 upgrade failed

Control: retitle -1 apache2 upgrade fails when apache2.2-common is purged in the process On 2013-07-14 09:47:04 +0200, Helmut Grohne wrote: You are likely using --purge-unused something similar causing the no longer needed package apache2.2-common to be purged. Yes, actually I marked it as

Bug#717666: apache2: Internal Server Error when using an option that doesn't change anything

Package: apache2 Version: 2.4.6-1 Severity: normal My ~/public_html/.htaccess file has: Options +MultiViews to make sure that MultiViews is enabled. But this yields the following error: Internal Server Error The server encountered an internal error or misconfiguration and was unable to

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-07-24 10:12:56 +0200, Arno Töll wrote: THere have been several reports, mine, another in the bug report, that confirm that mods get disabled by upgrading. I did not say your issue does not exist. But it does not happen under normal circumstances. The bug occurred for me in an

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-07-24 21:13:53 +0200, Stefan Fritsch wrote: Do you maybe still have the apt-get/aptitude output from the upgrade? There should be a copy in /var/log/apt/term.log* if the relevant file has not been rotated away, yet. Log started: 2013-07-14 01:37:08 (Reading database ... (Reading

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-07-24 22:07:02 +0200, Stefan Fritsch wrote: Am Mittwoch, 24. Juli 2013, 21:37:18 schrieb Vincent Lefevre: dpkg: apache2.2-common: dependency problems, but removing anyway as you requested: apache2-mpm-worker depends on apache2.2-common (= 2.2.22-13). apache2 depends

Bug#711925: apache2-doc's config file breaks apache itself

Hi, On 2013-07-25 12:16:20 +0200, Arno Töll wrote: On 25.07.2013 11:52, Vincent Lefevre wrote: thus depends on the alias module being there, but the dependency is not enforced anywhere. What if for some reason the alias module gets disabled in the future? Shouldn't a IfModule directive

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-07-25 13:13:18 +0200, Arno Töll wrote: On 25.07.2013 13:02, Vincent Lefevre wrote: Then wouldn't it be possible during an upgrade of some packages (e.g. apache2, apache2-doc) to make sure that these modules are enabled, and re-enable them if they aren't? As said, unless due

Bug#711925: apache2-doc's config file breaks apache itself

On 2013-07-25 13:51:13 +0200, Arno Töll wrote: On 25.07.2013 13:39, Vincent Lefevre wrote: If users are allowed to disable these modules in compliance with the policy, then you need to make sure that Apache still works in such a case (e.g. for a personal website that doesn't need

Bug#717666: apache2: Internal Server Error when using an option that doesn't change anything

On 2013-08-28 22:43:38 +, Jean-Michel Vourgère wrote: I believe this is the expected behavior: I suppose your error.log contains something like : /home/xxx/public_html/.htaccess: Option MultiViews not allowed here Tuning Multiview option is forbidden inside an .htaccess unless you

Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation

Source: apache2 Version: 2.4.6-3 Severity: grave Justification: renders package unusable I had the following problem when upgrading Ubuntu from 13.04 to 13.10, and since Debian has more or less the same packages (stable sid), I think it can be affected too. After the upgrade, Apache was no

Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation

On 2013-11-07 14:20:30 +0100, Arno Töll wrote: On 07.11.2013 03:08, Vincent Lefevre wrote: Severity: grave Justification: renders package unusable Your issue renders the package no way unusable, or causes data loss, or introduces a security hole allowing access to the accounts of users

Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation

On 2013-11-07 16:29:22 +0100, Arno Töll wrote: On 07.11.2013 16:06, Vincent Lefevre wrote: In fact, it's not even a bug since you installed a leaf package directly which is not meant to be used standalone. You're wrong. Users are not forced to install metapackages. I probably did apt

Bug#759382: do not keep so much logs

On 2014-08-26 14:28:48 -0700, Antoine Beaupré wrote: Apache, at least in Wheezy, seems to be configured by default to keep 52 log files, rotated on a weekly basis, meaning that logs are kept for a year. This is a long time to keep longs. It exposes our users unduly to surveillance and

Bug#759382: do not keep so much logs

On 2014-09-22 09:23:11 -0400, Antoine Beaupré wrote: On 2014-09-22 05:29:10, Vincent Lefevre wrote: Not your users, but people who connect to the web server. But the French law requires (required?) / advises to keep the logs for one year. There's a discussion in French here: http

Bug#759382: do not keep so much logs

On 2014-09-22 10:23:05 -0400, Antoine Beaupré wrote: On 2014-09-22 10:14:34, Vincent Lefevre wrote: On 2014-09-22 09:23:11 -0400, Antoine Beaupré wrote: On 2014-09-22 05:29:10, Vincent Lefevre wrote: Not your users, but people who connect to the web server. But the French law requires

Bug#759382: do not keep so much logs

On 2014-09-22 11:13:22 -0400, Antoine Beaupré wrote: On 2014-09-22 10:52:48, Vincent Lefevre wrote: I don't know where you live, but this is the same in most countries, except that the period varies. Where I live is irrelevant. It is not the same in all countries: some have more or less

Bug#759382: do not keep so much logs

On 2014-09-23 11:25:53 +0200, ilf wrote: Vincent Lefevre: On http://forum.ovh.com/archive/index.php/t-47594.html someone said A link to a five year old thread on some random webforum is not exactly a convincing argument. If you want to have a discussion on law, please link to the legal text

Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2

Package: apache2 Version: 2.4.10-2 Severity: important Preliminary note: this particular bug is not about the default, but silent configuration change. Due to * Keep fewer logs by default. Instead of 52 weekly logs, keep 14 daily logs. The daily graceful restart also has the advantage of

Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2

On 2014-09-23 14:43:49 +0200, Arno Töll wrote: We install this file through dh_installlogrotate and it is listed as a conffile in the binary package of apache2. That means, it will be handled like any other configuration file in Debian with special care and it won't overwrite changes YOU made.

Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2

On 2014-09-23 15:06:08 +0200, Arno Töll wrote: On 23.09.2014 15:01, Vincent Lefevre wrote: On 2014-09-23 14:43:49 +0200, Arno Töll wrote: We install this file through dh_installlogrotate and it is listed as a conffile in the binary package of apache2. That means, it will be handled like

Bug#777149: libapr1: apr_sockaddr_info_get() fails when eth0 has IPv6 only (can't determine the FQDN), e.g. with DHCP at boot

Package: libapr1 Version: 1.5.1-3 Severity: normal After the latest reboot, I have the following errors in /var/log/boot for apache2: AH00557: apache2: apr_sockaddr_info_get() failed for ypig AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using

Bug#792225: apache2: /etc/apache2/mods-available/ident.load is missing via upgrades

Package: apache2 Version: 2.4.12-2 Severity: normal While I've never touched it manually, the file /etc/apache2/mods-available/ident.load is missing on machines on which apache2 was upgraded. In particular, it was removed after upgrade to apache2 2.4.10-3, and not re-added later. On a machine

Bug#868656: apache2: maintainer scripts should tell when apache2 is stopped/started

Package: apache2 Version: 2.4.27-2 Severity: wishlist In the past, the maintainer scripts were telling when apache2 was stopped and (re)started. This is no longer the case. This would be useful information. -- Package-specific info: -- System Information: Debian Release: buster/sid APT

Bug#663530: apache2.2-common: Spurious warning "NameVirtualHost *:80 has no VirtualHosts" in cron/logrotate output

Control: reopen -1 Reopening bug closed by a spammer. Note: this bug had been reopened on 2018-02-20: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663530#63 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

Package: apache2 Version: 2.4.25-3+deb9u7 Severity: important I sometimes get SEC_ERROR_OCSP_TRY_SERVER_LATER errors in Firefox when I connect to my web server. The apache log shows errors like [Fri Jul 26 20:01:31.355081 2019] [ssl:error] [pid 13552:tid 139871725876992] [client

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

Control: found -1 2.4.38-3+deb10u1 On 2019-07-26 22:30:00 +0200, Vincent Lefevre wrote: > I sometimes get SEC_ERROR_OCSP_TRY_SERVER_LATER errors in Firefox > when I connect to my web server. The apache log shows errors like > > [Fri Jul 26 20:01:31.355081 2019] [ssl:error] [p

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

On 2019-09-26 23:40:45 +0200, Vincent Lefevre wrote: > Control: found -1 2.4.38-3+deb10u1 > > On 2019-07-26 22:30:00 +0200, Vincent Lefevre wrote: > > I sometimes get SEC_ERROR_OCSP_TRY_SERVER_LATER errors in Firefox > > when I connect to my web server. The apache

Bug#663530: apache2.2-common: Spurious warning "NameVirtualHost *:80 has no VirtualHosts" in cron/logrotate output

Control: reopen -1 Reopening bug closed by a spammer. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

I eventually had to disable OCSP stapling on my server: errors occur too frequently, even just after restarting apache. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

The upstream bugs to watch for: https://bz.apache.org/bugzilla/show_bug.cgi?id=57121 "ocsp stapling should not pass temporary server outages to clients" https://bz.apache.org/bugzilla/show_bug.cgi?id=60182 "SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being

Bug#663530: apache2.2-common: Spurious warning "NameVirtualHost *:80 has no VirtualHosts" in cron/logrotate output

Control: reopen -1 On 2021-09-22 10:30:17 +0200, Vincent Lefevre wrote: > Reopening as this bug was closed again by a spammer. ... without the typo this time. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blo

Bug#663530: apache2.2-common: Spurious warning "NameVirtualHost *:80 has no VirtualHosts" in cron/logrotate output

Controkl: reopen -1 Reopening as this bug was closed again by a spammer. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)