Apache httpd configuration @ SUSE
Hi, I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable. To recap, there are two levels: higher one represented by systemd service apache2 (and apache2@ for instances), as known as start_apache2, which takes sysconfig variables -- eventually set by yast httpd module -- into account. Lower level is represented by running just httpd, which is not influenced by sysconfig variables. This separation was driven by illogical behaviour when mixing these two approaches together. Both positive and negative feedback is welcome before we consider what we can do better. Petr -- Have a lot of fun!
pgajdos wrote:
Hi,
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
The current openSUSE config setup works very well for me, has done for years. -- Per Jessen, Zürich (5.2°C) Member, openSUSE Heroes
Hi, Am 16.02.21 um 09:14 schrieb pgajdos:
Hi,
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
To recap, there are two levels: higher one represented by systemd service apache2 (and apache2@ for instances), as known as start_apache2, which takes sysconfig variables -- eventually set by yast httpd module -- into account. Lower level is represented by running just httpd, which is not influenced by sysconfig variables. This separation was driven by illogical behaviour when mixing these two approaches together.
Both positive and negative feedback is welcome before we consider what we can do better. Please don't break it.
What I like: - It's been the same for years - It's very straightforward WRT vhosts. I see no benefit in the debian/ubuntu way. Both ways work. What could be more clear/straightforward: - enabling modules and flags. - Container use case (no-systemd country) Maybe I missed some memos along the way because over many years, it just worked and I did not need to learn new tricks. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Tue, Feb 16, Ralf Lang wrote:
Maybe I missed some memos along the way because over many years, it just worked and I did not need to learn new tricks.
That's true for somebody coming from openSUSE for many years. Now think about an admin, who has to maintaine Debian, Ubuntu, Fedora and openSUSE apache configurations. Does it also just work for him on openSUSE? Or isn't openSUSE the one he always need to remember how it is done different there? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Tuesday 2021-02-16 10:07, Thorsten Kukuk wrote:
On Tue, Feb 16, Ralf Lang wrote:
Maybe I missed some memos along the way because over many years, it just worked and I did not need to learn new tricks.
That's true for somebody coming from openSUSE for many years. Now think about an admin, who has to maintaine Debian, Ubuntu, Fedora and openSUSE apache configurations. Does it also just work for him on openSUSE? Or isn't openSUSE the one he always need to remember how it is done different there?
Given that the openSUSE installation works out of the box and the Debian one does not, I'd say we're just fine ;-) opensuse# httpd -S VirtualHost configuration: ServerRoot: "/srv/www" [...] debian# apache2 -S [Tue Feb 16 10:35:40.693583 2021] [core:warn] [pid 5993] AH00111: Config variable ${APACHE_RUN_DIR} is not defined apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot
On 2/16/21 10:07 AM, Thorsten Kukuk wrote:
On Tue, Feb 16, Ralf Lang wrote:
Maybe I missed some memos along the way because over many years, it just worked and I did not need to learn new tricks.
That's true for somebody coming from openSUSE for many years. Now think about an admin, who has to maintaine Debian, Ubuntu, Fedora and openSUSE apache configurations.
Basically every Apache httpd distro configuration seriously sucks, no matter which distro. Especially I consider it to be a security risk that things might get enabled by default for public access which shouldn't. The paradigm of making *something* work with none or only minimal admin intervention is IMO simply wrong. So personally I don't care what the distros are providing and I generate monolithic custom httpd.conf, custom systemd units and custom AppArmor profiles with config management for different distros. But it's really interesting how much Linux distros differ even in simple details like names and paths etc. So my only concern is that executable and modules paths are changed again... Ciao, Michael.
Hi, Am 16.02.2021 um 10:07 schrieb Thorsten Kukuk:
On Tue, Feb 16, Ralf Lang wrote:
Maybe I missed some memos along the way because over many years, it just worked and I did not need to learn new tricks. That's true for somebody coming from openSUSE for many years. Now think about an admin, who has to maintaine Debian, Ubuntu, Fedora and openSUSE apache configurations. Does it also just work for him on openSUSE? Or isn't openSUSE the one he always need to remember how it is done different there?
Thorsten
You are right, being compatible with either upstream defaults or other distros is good. However, last time I configured a debian (yesterday) or a rhel/centos (some months ago), they looked incompatible both to each other AND suse. And people already built their tools and docs for this situation. It's good to eliminate the need to remember details and have a smooth experience for new users but this should not break older setups unless needed. Some time ago, a tumbleweed based container broke because it used one of the older commandline tools, I think a2enmod. That tool either moved to a subpackage or it was in the subpackage all along but the subpackage was no longer installed with the same commands as before. Easy to fix, just explicitly require the subpackage. So how can we transition to debianish layouts without breaking stuff, at least for a while? 1) Create a sites-available dir on install or update 2) Either move existing vhosts.d to sites-enabled or create it from scratch. 3) Make vhosts.d a symlink to sites-available. Same should work for config snippets (conf.d) Should I build a SR? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi! On Wed, Feb 17, 2021 at 09:09:20AM +0100, Ralf Lang wrote:
Some time ago, a tumbleweed based container broke because it used one of the older commandline tools, I think a2enmod. That tool either moved to a subpackage or it was in the subpackage all along but the subpackage was no longer installed with the same commands as before. Easy to fix, just explicitly require the subpackage.
<offtopic> This is just guess, but perhaps you required apache2-$MPM? If I recall correctly, that was done along by rewrite apache2 source package to _multibuild and an assumption that someone, for example Michael Ströder, could want to install apache2-$MPM alone, without any distro provided stuff and just run httpd -f /own/httpd.conf </offtopic>
So how can we transition to debianish layouts without breaking stuff, at least for a while?
1) Create a sites-available dir on install or update 2) Either move existing vhosts.d to sites-enabled or create it from scratch. 3) Make vhosts.d a symlink to sites-available.
Same should work for config snippets (conf.d)
Should I build a SR?
I would be very glad, yes, as it seems it is wanted feature. Bye and thanks, Petr -- Have a lot of fun!
Hi, On Tue, Feb 16, pgajdos wrote:
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
To recap, there are two levels: higher one represented by systemd service apache2 (and apache2@ for instances), as known as start_apache2, which takes sysconfig variables -- eventually set by yast httpd module -- into account. Lower level is represented by running just httpd, which is not influenced by sysconfig variables. This separation was driven by illogical behaviour when mixing these two approaches together.
I'm using meanwhile nginx, since this is closer to upstream. Which means third party tools, configurations and documentations work normally out of the box. And this is the biggest complain I continously get: if you diverge, you have to adjust all the third party tools, configurations and documentations, too. And that's something we don't do. So people are lost, and the comment is not "I see the advantages of your way" but "it does not work on openSUSE". So: if there are good reasons to diverge from upstream and the rest of the world, we need to make pretty clear to everybody what the advantage for them is. If we don't do this, we are just incompatible. And it doesn't matter if it is the way how we start Apache (systemd unit, as many tools start/stop/disable/enable apache), the filesystem layout of the configuartion files or how we configure it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Tue, Feb 16, 2021 at 5:14 AM pgajdos
Hi,
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
After spending years maintaining this thing (albeit much less in the recent times) I'm of the idea of adopting the Debian/Ubuntu way. while it can be made a mess if you wish so, it is a much nicer and structured way to *start* with, not mention familiar to users. Fedora/RHEL have nothing other than the standard configuration files, so I do not have other example to compare to.
Hi Petr, El mar, 16-02-2021 a las 09:14 +0100, pgajdos escribió:
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
As someone that comes from debian/ubuntu, I only would like to have sites-enabled, sites-available and a2ensite, a2dissite. And, I think this can be done without breaking the current behavior. sites-enabled could just be a symlink to vhosts.d or vice versa. Kind Regards -- Sergio Lindo Mansilla Software developer with DevOps tendencies Portfolio: http://binary-sequence.github.com/
Am Dienstag, 16. Februar 2021, 17:09:20 CET schrieb Sergio:
Hi Petr,
El mar, 16-02-2021 a las 09:14 +0100, pgajdos escribió:
I got indicies that some people do not like SUSE httpd configuration mechanism, for example wrt diverging from other distros. What do you think? Your opinion is valuable.
As someone that comes from debian/ubuntu, I only would like to have sites-enabled, sites-available and a2ensite, a2dissite. And, I think this can be done without breaking the current behavior. sites-enabled could just be a symlink to vhosts.d or vice versa.
Kind Regards
I agree, I'm using nginx myself but the idea of symlinking _sites-available_ to _sites-enabled_ is so neat that I add it to the nginx config on all my Tumbleweed servers. regards
participants (9)
-
Cristian Rodríguez -
Jan Engelhardt -
Maximilian Trummer -
Michael Ströder -
Per Jessen -
pgajdos -
Ralf Lang -
Sergio -
Thorsten Kukuk