[Httpd Wiki] Trivial Update of "CommonMisconfigurations" by MarkWatts

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "CommonMisconfigurations" page has been changed by MarkWatts.
The comment on this change is: Added comment about webmin..
http://wiki.apache.org/httpd/CommonMisconfigurations?action=diff&rev1=8&rev2=9

--------------------------------------------------

  ## page was renamed from Info/CommonMisconfigurations
  = Common Apache Misconfigurations =
- 
  This page will describe common misconfigurations as seen in #apache as well as describe why these are wrong.
  
  <<TableOfContents(4)>>
  
  === Name Based Virtual Host ===
- 
  ==== Not matching the value of NameVirtualHost with a corresponding <VirtualHost> block. ====
  Example:
+ 
  {{{
  NameVirtualHost *:80
  
@@ -25, +24 @@

    # Options and stuff defined here.
  </VirtualHost>
  }}}
+ Why is the first virtual host wrong? It's wrong on a couple of levels. The most obvious is that some.domain.com used in the first <!VirtualHost> block doesn't match *:80 used in !NameVirtualHost. The other being that !NameVirtualHost refers to an interface, not a domain. For instance using *:80, means catch all interfaces on port 80. !NameVirtualHost 1.1.1.1:80, would mean to catch the interface defined as 1.1.1.1 on port 80. While you can use a "!NameVirtualHost some.domain.com/<!VirtualHost some.domain.com>" combination, it doesn't really make sense and is not used... at least not used by anyone who's experienced with Apache administration.<<BR>><<BR>>
  
- Why is the first virtual host wrong? It's wrong on a couple of levels. The most obvious is that some.domain.com used in the first <!VirtualHost> block doesn't match *:80 used in !NameVirtualHost. The other being that !NameVirtualHost refers to an interface, not a domain. For instance using *:80, means catch all interfaces on port 80. !NameVirtualHost 1.1.1.1:80, would mean to catch the interface defined as 1.1.1.1 on port 80. While you can use a "!NameVirtualHost some.domain.com/<!VirtualHost some.domain.com>" combination, it doesn't really make sense and is not used... at least not used by anyone who's experienced with Apache administration.<<BR>><<BR>>
+ Reports in #httpd suggest that Webmin 1.510 (at least) may cause this issue. <<BR>><<BR>>
  
  ==== Not setting a ServerName in a virtual host. ====
  Example:
+ 
  {{{
  NameVirtualHost *:80
  
@@ -44, +45 @@

    # Options and stuff defined here, but no ServerName
  </VirtualHost>
  }}}
- 
  The second virtual host is wrong because when using name based virtual hosts, the !ServerName is used by Apache to determine which virtual host configuration to use. Without it, Apache will never use the second virtual host configuration and will use the default virtual host. The default virtual host when using name based virtual hosts is the first defined virtual host.<<BR>><<BR>>
  
  ==== Mixing non-port and port name based virtual hosts. ====
  Example:
+ 
  {{{
  NameVirtualHost *
  NameVirtualHost *:80
@@ -63, +64 @@

    # Options and stuff defined here.
  </VirtualHost>
  }}}
- 
  Because !NameVirtualHost * means catch all interfaces on all ports, the *:80 virtual host will never be caught. Every request to Apache will result in the some.domain.com virtual host being used.<<BR>><<BR>>
  
  ==== Using the same Listen and/or NameVirtualHost multiple times. ====
  Example:
+ 
  {{{
  # Can happen when using multiple config files.
  # In one config file:
- Listen 80 
+ Listen 80
  # In another config file:
- Listen 80 
+ Listen 80
  
  # Like above, can happen when using multiple config files.
  # In one config file:
  NameVirtualHost *:80
- # In another config file: 
+ # In another config file:
- NameVirtualHost *:80 
+ NameVirtualHost *:80
  }}}
- 
  In the case of multiple Listen directives, Apache will bind to port 80 the first time and then try to bind to port 80 a second time. This yields a nice "Could not bind to port" error on start up. This seems to happen with newbies and Debian based distros, where Debian based distros have Listen 80 defined in ports.conf. Newbies don't realize this and create another Listen 80 line in apache2.conf.<<BR>><<BR>>
  
  Multiple !NameVirtualHost lines will yield a "!NameVirtualHost *:80 has no !VirtualHosts" warning. Apache will ignore the second directive and use the first defined !NameVirtualHost line, though. This seems to happen when one is using multiple virtual host configuration files and doesn't understand that you only need to define a particular !NameVirtualHost line once. As above, this can occur in the debian ports.conf file, especially after an upgrade.<<BR>><<BR>>
  
  ==== Multiple SSL name based virtual hosts on the same interface. ====
  Example:
+ 
  {{{
  NameVirtualHost *:443
  
@@ -101, +102 @@

    # SSL options, other options, and stuff defined here.
  </VirtualHost>
  }}}
- 
- Because of the nature of SSL, host information isn't used when first establishing a SSL connection. Apache will always use the certificate of the default virtual host, which is the first defined virtual host in name based virtual hosts. While this doesn't mean that you won't ever be able to access the second virtual host, it does mean your users will always get a certificate mismatch popup warning when trying to access some.domain2.com. Read more about this at [[http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2]].<<BR>><<BR>>
+ Because of the nature of SSL, host information isn't used when first establishing a SSL connection. Apache will always use the certificate of the default virtual host, which is the first defined virtual host in name based virtual hosts. While this doesn't mean that you won't ever be able to access the second virtual host, it does mean your users will always get a certificate mismatch popup warning when trying to access some.domain2.com. Read more about this at http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2.<<BR>><<BR>> Also, note that the configuration above isn't something someone would normally use for SSL, which requires a static, non-shared IP address -- !NameVirtualHost 127.124.3.53:80 is a more likely format. However, using !NameVirtualHost *:443 is commonly seen in howtos for Debian/Ubuntu.<<BR>><<BR>>
- Also, note that the configuration above isn't something someone would normally use for SSL, which requires a static, non-shared IP address -- !NameVirtualHost 127.124.3.53:80 is a more likely format. However, using !NameVirtualHost *:443 is commonly seen in howtos for Debian/Ubuntu.<<BR>><<BR>>
  
  === Scope ===
- 
  ==== Adding/Restricting access and options in <Directory /> ====
  Example:
+ 
  {{{
  <Directory />
    # This was changed from the default of AllowOverride None.
@@ -116, +115 @@

    # Default directives defined below.
  </Directory>
  }}}
- 
  <Directory /> is not a URL path. It is a filesystem path. Making changes in this <Directory> block will have no effect on your website !DocumentRoot. In the example above, what might have been attempted was being able to use htaccess in the !DocumentRoot. The problem being that the htaccess file will still be ignored because the !AllowOverride is set in the wrong <Directory> block.<<BR>><<BR>>
  
  ==== Changing the DocumentRoot value without updating the old DocumentRoot's <Directory> block ====
  Example:
+ 
  {{{
  # Your old DocumentRoot value was /usr/local/apache2/htdocs
  DocumentRoot /var/www/html
@@ -131, +130 @@

    # Options and access set here.
  </Directory>
  }}}
- 
  Access and options in Apache must be expressly given. Since there is no <Directory> block for the new document root that grants any access or options, you will get a permission error when you try to access your site.<<BR>><<BR>>
  
  ==== Trying to set directory and index options in a script aliased directory. ====
  Example:
+ 
  {{{
  ScriptAlias /cgi-bin/ /var/www/cgi-bin/
  <Directory /var/www/cgi-bin>
@@ -145, +144 @@

    # Other options defined.
  </Directory>
  }}}
+ Script aliased directories do not allow for directory listings specified with Options Indexes. This is a security feature. Also, script aliased directories automatically try and execute everything in them. So, Options ExecCGI is unnecessary. The DirectoryIndex directive also does not work in a script aliased directory. The workaround for this if you really need directory listings or other directory indexing options is to use Alias instead of ScriptAlias.<<BR>><<BR>> Example:
  
- Script aliased directories do not allow for directory listings specified with Options Indexes. This is a security feature. Also, script aliased directories automatically try and execute everything in them. So, Options ExecCGI is unnecessary. The DirectoryIndex directive also does not work in a script aliased directory. The workaround for this if you really need directory listings or other directory indexing options is to use Alias instead of ScriptAlias.<<BR>><<BR>>
- Example:
  {{{
  Alias /cgi-bin/ /var/www/cgi-bin/
  <Directory /var/www/cgi-bin>
@@ -158, +156 @@

    # Other options defined.
  </Directory>
  }}}
+ The options above will now work.<<BR>><<BR>>
  
- The options above will now work.<<BR>><<BR>>
-   
  (!) TODO (!)
  
  Add some more commonly seen stuff