Hi Joe,
Many thanks for your feedback. I am very excited that we can now make a positive impact together and pushing things forward.
Am 14.02.2024 um 17:01 schrieb Joe Orton jorton@redhat.com:
On Tue, Feb 13, 2024 at 10:36:44AM +0100, Peter Boy wrote:
Hi folks,
We have a serious issue with the current Apache httpd package, which is an indispensable service for a server these days.
The issue is basically the default configuration as provided by the package:
- if you create just one server in den .conf directory, it results in a non-functional https configuration
- the configuration uses items, that are deprecated since version 2.4
- the default layout of the default configuration is currently not suitable
I wrote a bug report about it: https://bugzilla.redhat.com/show_bug.cgi?id=2258121
Hi Peter,
This is definitely an interesting & complex topic. Sorry nobody has replied on your bug, I did read it but... it's a big area and haven't had time to think it through properly.
Yes, probably every one of us gets swamped at times. I was probably a bit too impatient and too keen to improve our server edition.
Do you have a concrete proposal on exactly what you'd like to do differently? I'm guessing you do but it's not really laid out in the bug. Going through some of my thoughts:
Yes, I do or better we, as Server WG do. And because httpd is such an important service I would we ready to create a PR for a new or adjusted configuration. And also assist with the configuration part (The last time I compiled a C program is back more then one decade).
- The default ssl.conf & vhost definition is difficult/awkward, I
definitely agree here. I suppose there are several parts to this -
a) All the stuff outside the vhost in ssl.conf should be a hard-coded default or unnecessary - some coding probably required, e.g. I already made SSLRandom a no-op upstream since it doesn't make sense with modern OpenSSL.
Yes, I agree here. We should remove the vhost part, but retain it and put it elsewere.
As far as I understand (but am really not sure I do) the openssl package provides a system wide default and secure configuration, e.g. the optimal cipher list and anything like that. If this is indeed the case, wouldn't it make sense to use this in ssl.conf or to refer to it? And to point out that you should not make any changes that you might find in any instructions on the Internet. What I keep finding in discussions about this is often adventurous and a bad improvement or outdated. Such a centrally maintained and tested security configuration would be a distinguishing feature for Fedora as a whole. (Sorry, I’m not a marketing guy, but have to promote Fedora and Fedora Server as part of my engagement in Server WG).
b) Can & should we retain a default :443 vhost with generated certs? I *think* yes, but am quite open to persuasion on this.
I agree. We should ensure, that httpd is ready to work out of the box after installation. And today it is (quite predominantly) https with automatic forwarding http.
- Including mod_ssl as part of httpd I definitely don't agree with and
is technically not necessary; it may be better to argue that we should "Recommends: mod_ssl". We will never make https:// "work" out of the box without active user intervention, at least since ACME CAs require a subscriber agreement contract.
Well, I think we can and should treat mod_ssl the same way as a lot of other modules, e.g proxy, mod_auth and anything else that we currently install as part of the httpd package, and activate and configure in ~/conf.modules.d/. I suppose, mod_ssl is used much more frequently today than many of the modules that we already install and configure. Virtually no web server can manage without https - except for backend servers in containers or internal VMs (Perhaps we should offer a separate configuration for this, which is much more slim and streamlined).
And we make it work out of the box as we currently do, using self signed certificates for a start, and provide info how to improve with md and „real“ certificates.
- In thinking about how we do SSL vhost config, I think it's important
to consider all use cases - mod_md-managed, certbot-driven configs, or "traditional CA" users. (Particularly for ACME with DNS validation it's easier to get going with certbot than mod_md.)
My idea / wish is to provide a minimal but complete default vhost configuration, that works out of the box with self-signed certificates to start with and contains templates how to engage md-managed and certbot-driven configs and various additional services.
You can find a first try of such a vhost config file in our Server documentation "Setting up a basic web server" (https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setu...) or download the file (https://docs.fedoraproject.org/en-US/fedora-server/_attachments/services/htt...) to inspect it.
Im currently working on a Guide to configure an Apache proxy and html backend server and a proxy for a Java backends via ajp protocol. Currently, I’m planning this for server documentation, but we can also revive the Web part of the Fedora Administrator’s Guide and provide documentation and sample configuration files for various typical purposes there.
The key point is to include a sample configuration that is a good starting point for administrators to customize for their own purposes.
- Backwards compatibility is important and hopefully everybody agrees
that we shouldn't break the upgrade path (beyond maybe removing or moving ssl.conf itself).
This is also an essential requirement for Server WG.
Perhaps it is best to leave the existing directory structure as it is for existing installations, and to introduce a new configuration directory for vhosts that is included in http.conf after conf.d. On my servers I use ~/conf.vhosts.d/*.vhost files. And we can deprecate ~/conf.d for vhost and specific server configuration, but leaving it for general, cross-vhost basic configurations. Application programs such as wordpress can continue to store their basic configuration there.
- Not sure about anybody else, but I'm still not a fan of the Debian
style split -enabled/-available config directories which has always seemed over-engineered to me. I'm open to being convinced we should have a new config directory in /etc/httpd which is included by default if necessary.
So, thoughts?
I totally agree regarding the Debian configuration system. I find this not only over-engineered but also very confusing.
Even with Debian's system, you will eventually reach the point where you have to write a configuration file. It is then more effective to write a configuration file that combines everything necessary in one place and can be easily adapted and extended. To deactivate, simply add an .OFF to the file name. I also find this clearer, you have everything in one place.
I think it is still important to "officially" introduce a directory structure in /var/www for web server data that is vhost or domain-oriented. For example /var/www/<domain[1..x]/[htdocs|auth.d|cgi|...] "officially". Most installations will host more than one domain and even with a proxy server you need a separate data area for each proxy domain.
Maybe I'm thinking too much as a system administrator and trying to make it as easy as possible for them. But maybe that's not entirely wrong.
Best Peter
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy 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