Hi Joe,
Amazing how time goes by. It’s about a year ago that we wrote about a possible improvement of the Fedora Apache default configuration. I was quite busy with various issues with Fedora Server Edition and some accidents, too, that handicapped me.
But now Server WG is dealing with httpd config again. And I wrote a reworked installation documentation for Fedora Server, which details the ideas we have for web service in Fedora. Some are very Server specific, e.g. the part about storage organizations and LVM volumes. Others are more httpd specific, e.g. SSL and vhosts.
See: https://docs.stg.fedoraproject.org/en-US/fedora-server/services/httpd-basic-...
The article includes some downloadable config file modifications (currently on my development server until we find a place in Fedora infrastructure).
It’s just the first part. Further parts deal with specific uses cases, especially with configuration as reverse proxy for containerized apps, classic web applications as Wildly, etc.
I would be happy if we could manage to discuss about it and find a way for Server WG to avoid having to tinker with the default configurations. I would very much appreciate it if we could work together to coordinate the configuration requirements. I have three potential applications scenarios in mind (full-fledged standalone servers, reverse proxies, and backend communicators for web apps like WordPress in a container). Different Apache modules could be put together for this and Apache could be made leaner. This would counter the criticism of sluggishness and a heavy footprint compared to alternatives such as nginx and lighttpd.
Thanks in advance
Peter
P.S. Maybe, we could write together a Fedora Magazine article? Or a series thereof?
P.P.S Are you attending FOSDEM in Brussels this year by any chance?
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.
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:
- 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.
b) Can & should we retain a default :443 vhost with generated certs? I *think* yes, but am quite open to persuasion on this.
- 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.
- 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.)
- Backwards compatibility is important and hopefully everybody agrees
that we shouldn't break the upgrade path (beyond maybe removing or moving ssl.conf itself).
- 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?
Regards, Joe
server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org 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/server@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
— 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