Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80

2013-07-22 Thread Edward Welbourne
 That being said please note, that NameVirtualHost itself is deprecated
 and not used anymore in Apache2 2.4.

That's good to hear.  Having to hae two things exactly in sync is always
a bit weird; might as well eliminate the redundancy instead !

Eddy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80

2013-07-21 Thread Edward Welbourne
Package: apache2.2-common
Version: 2.2.22-13
Followup-For: Bug #663530

Dear Maintainer,

I finally decided to work out why I was getting grumbles from apache
about a NameVirtualHost *:80 directive.  The only configuration I've
actually got enabled (i.e. symlinked from sites-enabled/ to
sites-available/) has an explicit IP address rather than a wildcard, so
I was initially at a loss.  It's based on an old default config, in
which the NameVirtualHost line appeared immediately before the
VirtualHost directive; and I'd ensured that the two gave the same
host:port details, not the default's *:80 but 127.0.0.1:80 in both
places.  However, closer investigation revealed that
/etc/apache2/ports.conf *also* contains a NameVirtualHost *:80 line,
which is what the complaints relate to.  Commenting it out fixed the
warnings about this directive - and fixed several other things that had
mysteriously broken some months ago.  My configuration's
  ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
and
  Alias /doc/ /usr/share/doc/
directives weren't being honoured; I got 404 errors when accessing URLs
that should have been resolved by these.  These things are all now back
to working normally - yay !

The problem is that the NameVirtualHost directive *must* exactly match
the VirtualHost directive's parameter.  Putting the two in separate
files just ensures that the person configuring the server can't actually
see that there's a second place that the address:port has to appear,
identically, so won't naturally keep the two in sync.  Even though I
actually have a NameVirtualHost in my enabled sites-available file,
matching exactly the same file's VirtualHost parameter, my configuration
was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing
about.

Given that the VirtualHost directive lives in a user-configurable file
and *must* exactly match the NameVirtualHost directive, it strikes me
that the old way, having the later also in the user-configurable file,
was a better approach than the present, where the user must - in fact -
edit a file that's not in sub-directory in which user-configuration
normally takes place.  If there's genuinely a compelling reason to put
the NameVirtualHost somewhere other than *right next to* the
VirtualHost directive (as I'm fairly sure it used to be), where it'll
be obvious that they need to stay in sync, please add a comment to
default, immediately before the VirtualHost directive, saying be sure
to keep ports.conf's NameVirtualHost in sync; the host:port must match
exactly.

*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- Package-specific info:
List of enabled modules from 'apache2 -M':
  actions alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgi deflate dir env include mime
  negotiation python reqtimeout rewrite setenvif status userdir

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.22-13
ii  apache2.2-bin  2.2.22-13
ii  lsb-base   4.1+Debian12
ii  mime-support   3.54
ii  perl   5.14.2-21
ii  procps 1:3.3.4-2

Versions of packages apache2.2-common recommends:
ii  ssl-cert  1.0.32

Versions of packages apache2.2-common suggests:
ii  apache2-doc 2.2.22-13
pn  apache2-suexec | apache2-suexec-custom  none
ii  chromium [www-browser]  28.0.1500.71-2
ii  opera [www-browser] 12.16.1860
ii  opera-next [www-browser]12.16.1860
ii  w3m [www-browser]   0.5.3-8

Versions of packages apache2.2-common is related to:
pn  apache2-mpm-eventnone
pn  apache2-mpm-itk  none
ii  apache2-mpm-prefork  2.2.22-13
pn  apache2-mpm-worker   none

-- Configuration Files:
/etc/apache2/mods-available/userdir.conf changed:
IfModule mod_userdir.c
UserDir web
UserDir disabled root
Directory /home/*/web
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
# Ignore default's allow/deny: over-ridden by server config.
/Directory
/IfModule

/etc/apache2/ports.conf changed:
Listen 80
IfModule mod_ssl.c
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to VirtualHost *:443
# Server Name Indication for SSL named virtual hosts is 

Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80

2013-07-21 Thread Arno Töll
Hi,

On 21.07.2013 17:32, Edward Welbourne wrote:
 Even though I
 actually have a NameVirtualHost in my enabled sites-available file,
 matching exactly the same file's VirtualHost parameter, my configuration
 was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing
 about.
 ...
 Given that the VirtualHost directive lives in a user-configurable file
 and *must* exactly match the NameVirtualHost directive, it strikes me
 that the old way, having the later also in the user-configurable file,
 was a better approach than the present, where the user must - in fact -
 edit a file that's not in sub-directory in which user-configuration
 normally takes place.  If there's genuinely a compelling reason to put
 the NameVirtualHost somewhere other than *right next to* the
 VirtualHost directive (as I'm fairly sure it used to be), where it'll
 be obvious that they need to stay in sync, please add a comment to
 default, immediately before the VirtualHost directive, saying be sure
 to keep ports.conf's NameVirtualHost in sync; the host:port must match
 exactly.


First, let me point out that also ports.conf is a user-configurable
file. You can safely edit and adapt it to your needs. That what it is
meant for.

Having NameVirtualHost in 000-default though is dangerous, at is a
directive being _shared_ across virtual hosts. It is used by all sites,
including but not limited to the default site. Assuming you deactivate
the default site, this causes undefined and broken behavior if you have
other name based virtual hosts.

This is a major problem lots of Debian users stumbled upon over the
years. Thus, we're more than glad and very happy NameVirtualHost is no
more in 000-default.conf and we are definitely not going back that road.


That being said please note, that NameVirtualHost itself is deprecated
and not used anymore in Apache2 2.4. There is no chance to fix this in
Debian Stable anyway due to our freezing policy, and the next Debian
release will have Apache2 2.4 only, not using NameVirtualHost at all
anymore.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature