Re: best practices for configuring multiple VirtualHost Apache WWW servers in Fedora?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Tim and Peter, thank you for the appreciated answers. 

On Sun, 27 Aug 2023 07:22:57 +0200
Peter Boy <pboy@xxxxxxxxxxxxx> wrote:

> I’m not sure, if I really understood the issue, you want to resolve

Excuse my not good english... But:

> > Am 26.08.2023 um 20:29 schrieb Franta Hanzlík via users <users@xxxxxxxxxxxxxxxxxxxxxxx>:
> > 
> > Hi,
> > how is it possible to best configure multiple virtual servers, given
> > how Fedora has organized configuration files for inclusion in Apache
> > httpd.conf? Especially if I want some configuration files to be used
> > by only some VirtualHost sites?
> > 
> > Example - I want to have 4 web servers (VirtualHost), and I want each
> > one to use a different /etc/http/conf.d/*.conf file (and not another)
> > - e.g.:
> > 1) http://intranet.mydom   - zoneminder.conf
> > 2) https://intranet.mydom  - mrtg.conf
> > 3) http://www.mydom        - geoip.conf + apcupsd.conf
> > 4) https://www.mydom       - geoip.conf + roundcubemail.conf 
> > 
> > I suppose I will create four configuration files for each Virtualhost 
> > in the /etc/httpd/conf.d/ directory (eg srv1_intranet.mydom_ssl.conf, 
> > srv2_intranet.mydom.conf, srv3_www.mydom_ssl.conf, srv4_www.mydom.conf).
> > But how best to proceed?  
> Yes, you create a configuration file for each Virtualhost. Maybe the server doc provides some useful information for you ( And I would be interested, which information or explanation your are missing. We are still in the process to complete that article.
> > IMO if I leave zoneminder/mrtg/apcupsd/geoip/roundcubemail as they are,
> > in /etc/http/conf.d/, they will apply in all VirtualHost - which I
> > don't want.  
> Not exactly. They provide configuration for the „main“ server. But the (formerly) „main“ server is not used anymore. Instead, best practice is to define a virtual host in a configuration file for each domain for which you want to provide a web service - even if the (physical or virtual) server is to provide only one single domain, and that may or may not have the same DNS name as the server.
> The Virtualhost defined in the alphabetically first of those files which define a Virtualhost, becomes the „default“ host and replaces the „main“ host.  
> In that case the zoneminder/mrtg/… configuration file provides default values for configuration parameters specified in this file.
> They have only an effect inside the virtual host(s) if the parameter(s) are inherited. And in this case you overwrite them in your virtual host configuration.   

>From Apache 2.4 docs:
  it seems as (freely drawn):

- The main server consists of all the definitions appearing outside of <VirtualHost> sections. This main server is treated as "defaults" or a "base" for each vhost.
- When a request is received, the server first maps it to the best matching <VirtualHost> based on the local IP address and port combination only. Non-wildcards have a higher precedence.
    - If no match based on IP and port occurs at all, the "main" server configuration is used.
    - If multiple virtual hosts contain the best matching IP address and port, the server selects from these virtual hosts the best match based on the requested hostname.
        - If no matching name-based virtual host is found, then the first listed virtual host that matched the IP address will be used.
          As a consequence, the first listed virtual host for a given IP address and port combination is the default virtual host for that IP and port combination.

>From this it seems to me that all .conf files in the directory will be applied
in all VirtualHost.

Therefore, the conf.d/*.conf files mentioned by me should not be in the definition
of the "main" server - they should only be in the definition of the specific
vhost that uses them.

And the requirement that package updates do not change the Apache httpd 
configuration leads me to have these .conf files exist but be empty 
(no effect). 

And either rely on the fact that the update will not overwrite them (the files
in the package are saved as .rpmnew and will not affect anything), or somehow
ensure that they are not overwritten - with the immutable attribute.

There is also the question of security and resistance to attacks from
the Internet. And since the attacks will most likely go to the IP address
(not the ServerName), it might be a good idea to make one more (fake)
Virtualhost as the default ("first listed")  VirtualHost - and on it have
minimal configuration, secure DocumentRoot and so on). Or am I mistaken?

> > And if I put each one in its VirtualHost and delete the original in
> > /etc/httpd/conf.d/, it reappears there when its RPM package will be
> > updated.  
> > 
> > Am I thinking correctly? Is there an elegant solution to this?
> > 
> > What about leaving empty files of the same name in /etc/httpd/conf.d/
> > (mrtg.conf, geoip.conf, ...) and setting the immutable attribute to
> > them (i'm on ext4), so that package updates don't overwrite them?  
> I think that’s not a good idea. The update program compares determines whether the config fils was changed. It not, it replaces the file, otherwise it creates a  .newrpm file of the same name. An administrator use to check for those files after an updates and will decide how to deal with it.

IMO for various reasons, the administrator (I ;) will not notice that something
has changed, that the daemon has stopped working, or that some security hole
 has appeared.

> --
TIA, Franta Hanzlík
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux