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?
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.
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? --- Thanks, Franta Hanzlik
On Sat, 2023-08-26 at 20:29 +0200, Franta Hanzlík via users wrote:
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?
That's generally how such things are done, one file in conf.d per thing.
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.
Are you sure? You can always do some tests, mock up some examples and see what happens.
I've only got Squirrel Mail installed on my LAN as an extra through Apache, and I can see that any virtual host domain with /webmail tacked on the end of it goes into the local Squirrel Mail site (the same one on each virtual host).
It'll depend how they're written. If they're similarly constructed as the virtual host configurations, they only apply to themselves.
You could put virtual host parameters into them. You could shift them out of conf.d and have a specific virtual host include them into itself. You could forbid the path within your virtual hosts.
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.
Unfortunately that's down to how those packages are written.
* They may realise there's custom config files and leave yours alone adding some conf.rpmnew files for you to compare new against old and update your own conf files. * They may do nothing if there's an existing .conf file. * They may move your config files to conf.rpmold and implement their new conf files. * They may simply bulldoze through existing config files and replace them.
If you feel it's going to do something along the lines of the last two things, you'd want to keep back-up files ready to reimplement after any updates.
I've generally found that Apache's conf.d/conf files didn't get stomped on by updates.
I’m not sure, if I really understood the issue, you want to resolve
Am 26.08.2023 um 20:29 schrieb Franta Hanzlík via users users@lists.fedoraproject.org:
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.:
- http://intranet.mydom - zoneminder.conf
- https://intranet.mydom - mrtg.conf
- http://www.mydom - geoip.conf + apcupsd.conf
- 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 (https://docs.stg.fedoraproject.org/en-US/fedora-server/services/httpd-basic-...) 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.
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.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org mailto:PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
Hi Tim and Peter, thank you for the appreciated answers.
On Sun, 27 Aug 2023 07:22:57 +0200 Peter Boy pboy@uni-bremen.de 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@lists.fedoraproject.org:
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.:
- http://intranet.mydom - zoneminder.conf
- https://intranet.mydom - mrtg.conf
- http://www.mydom - geoip.conf + apcupsd.conf
- 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 (https://docs.stg.fedoraproject.org/en-US/fedora-server/services/httpd-basic-...) 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: https://httpd.apache.org/docs/2.4/mod/core.html https://httpd.apache.org/docs/2.4/vhosts/details.html 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
On 27 Aug 2023, at 16:40, Franta Hanzlík via users users@lists.fedoraproject.org wrote:
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.
The HTTP Host header is also used to match to the ServerName of the VirtualHost. I host 2 domains on the same IP and port, as is typical for web hosting services.
When you browse to a url like https:/example.com/stuff what browser will do is Do a DNS look of the domain name, example.com, and connect to that IP address. It will use the default port if an explicit one is not in the url, 443 is this case. The HTTP request will start like this
GET /stuff Host: example.com
All browsers and HTTP libraries will put the Host header in these days because if virtusl hosting.
Barry
On Sun, 27 Aug 2023 22:48:28 +0100 Barry barry@barrys-emacs.org wrote:
On 27 Aug 2023, at 16:40, Franta Hanzlík via users users@lists.fedoraproject.org wrote:
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.
The HTTP Host header is also used to match to the ServerName of the VirtualHost. I host 2 domains on the same IP and port, as is typical for web hosting services.
When you browse to a url like https:/example.com/stuff what browser will do is Do a DNS look of the domain name, example.com, and connect to that IP address. It will use the default port if an explicit one is not in the url, 443 is this case. The HTTP request will start like this
GET /stuff Host: example.com
All browsers and HTTP libraries will put the Host header in these days because if virtusl hosting.
Hi Barry, thank for reply. I agree, legitimate clients will use this "Host" header (including SNI in HTTPS requests). But "bad" attacking clients probably won't, they'll probably only scan and use IP addresses.
This is clear to me anyway, my point was how to optimally use the layout used in Fedora to design robust and secure virtual websites. And perhaps even including the use of the mod_security module in all VirtualHosts, but with different rules and exceptions in each VirtualHost ... ;) --- Frant HanzlIk
On Sun, 2023-08-27 at 17:39 +0200, Franta Hanzlík via users wrote:
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?
Correct that attacks will go to the IP address, and you're probably more likely to get IP scanning finding you than someone targeting a particular domain. Though the reverse may be true if you publish anything that triggers the dingbats on the internet.
Also correct that you may want to ensure a particular virtual host is your default one. You may want that to be your main website, you may want that to be some kind of defensive configuration. There's another advantage in the default virtual host being the wrong website, it may aid you in checking you've configured things right for your real website.
The conf.d/*.conf files are processed in alphabetical order, so name your default virtual host's configuration file to be picked first (e.g. 000-default.conf). Filenames don't have to be the same as the domain name, by the way.
On Mon, 28 Aug 2023 12:13:35 +0930 Tim ignored_mailbox@yahoo.com.au wrote:
On Sun, 2023-08-27 at 17:39 +0200, Franta Hanzlík via users wrote:
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?
Correct that attacks will go to the IP address, and you're probably more likely to get IP scanning finding you than someone targeting a particular domain. Though the reverse may be true if you publish anything that triggers the dingbats on the internet.
Also correct that you may want to ensure a particular virtual host is your default one. You may want that to be your main website, you may want that to be some kind of defensive configuration. There's another advantage in the default virtual host being the wrong website, it may aid you in checking you've configured things right for your real website.
The conf.d/*.conf files are processed in alphabetical order, so name your default virtual host's configuration file to be picked first (e.g. 000-default.conf). Filenames don't have to be the same as the domain name, by the way. --
IMO this alphabetical order processing (assuming that provided the conf.d/*.conf files are either vhost-only, or no-vhost-only (ie the definition for the "main" server)) is only relevant for determining what the "default" virtual server (serving to other vhost unassigned requests) will be. Because according to https://httpd.apache.org/docs/2.4/vhosts/details.html: "Essentially, the main server is treated as "defaults" or a "base" on which to build each vhost. But the positioning of these main server definitions in the config file is largely irrelevant -- the entire config of the main server has been parsed when this final merging occurs. So even if a main server definition appears after a vhost definition it might affect the vhost definition."
So the process of building the configuration of individual vhosts looks like this (IMO): - After loading all .conf files, the "main" server configuration is created - which serves as default parameters for all vhosts.
- Then the configuration of individual vhosts is built, where the definition from the alphabetically first file (matching the IP:port request) determines the "default" server.
- So when all vhosts listen on all interfaces and all their IPs and using only standard ports 80/http and 443/https there will be one "default" server for http and one "default" for https.
--- Franta Hanzlik
Tim:
The conf.d/*.conf files are processed in alphabetical order, so name your default virtual host's configuration file to be picked first (e.g. 000-default.conf). Filenames don't have to be the same as the domain name, by the way.
Franta Hanzlík:
IMO this alphabetical order processing (assuming that provided the conf.d/*.conf files are either vhost-only, or no-vhost-only (ie the definition for the "main" server)) is only relevant for determining what the "default" virtual server (serving to other vhost unassigned requests) will be.
If you look at the main httpd.conf file, this is at the very end:
---- begin my paste ----
# Supplemental configuration # # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf
---- end of my paste ----
In essence there's just one big configuration file, composed of the main file with all the conf.d entries as a part of it. They're included into it (which will be an alphabetically ordered import). But since the main configuration file doesn't have anything else after it (as mine currently stands), they're simply appended to it (in alphabetic sorted order). And THEN that conglomeration is parsed (which will have its own set of rules).
So, the alphabetical sorting should only make any difference where...
Something that's found first is considered first for something, or something that's found last gets to override a previous settings.
Though many things don't have any priority.
The default virtual host is simply the first virtual host defined, and any traffic that doesn't appear to belong to any particular virtual host is dealt with by it. In the past, that would have been a server in the main configuration, these days it's the first virtual host.
Either way, it may be prudent to make it serve an error notice.
- So when all vhosts listen on all interfaces and all their IPs and
using only standard ports 80/http and 443/https there will be one "default" server for http and one "default" for https.
I think it's more a case of Apache listens, and is the handler to deal with this traffic goes here or there. Rather than multiple Apaches listening to everything to see if something is supposed to be for them, and ignoring what isn't. I have more virtual hosts configured then there are Apache processes running.
But yes, there could be one default HTTP and one default HTTPS, and you could define them both with just one conf file.
The confusing thing is when someone is simply going to serve one website, doesn't really need virtual hosts, yet has to delve into them because of some outside requirement (such as some oddball requirements of one of the certificate issuers).
-
Barry -
Franta Hanzlík -
Peter Boy -
Tim