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

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

 



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@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 (https://docs.stg.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/) 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@xxxxxxxxxxxxxxxxx

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast





_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[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