Split LoadModules out of apache 2.4's httpd.conf

[mat]

Summary

Apache now installs one file per module in DATADIR/modules.d, and uses the
@sample mechanism to have them appear magically in ETCDIR/modules.d.

Apache has had an internal way of knowing in which order to load modules since
2.0 (or 2.2) so there is no reason to add numbers to the file names.

They're installed in DATADIR/modules.d because there is a lot of them, and
they would only clutter ETCDIR.

[mat]

It needs a patch for apxs, so that it gets aware of the new scheme, I'm having a look at what Debian did.

[mat]

Also, I removed the pkg-install/deinstall because the mpm didn't need to be "fixed" now, but I may put back a pkg-install, or a pkg-message to tell people that THINGS CHANGED(tm) and that everything is fine.

[ohauer]

Apache has had an internal way of knowing in which order to load modules
since 2.0 (or 2.2) so there is no reason to add numbers to the file names.

No entry true, specially in combination with third party modules (that's the reason I've added numbers in the name)

Personally I dislike the idea to chop non third party modules into dedicated configs, and it is one of the reason all my apache servers don't run on RHEL, or (specially) Debian.

I have to look if I can find my unfinished protype from Mk/bsd.apache.mk, on my old laptop (dedicated Uses/apache.mk, similar to the change of php, bsd.apache.mk was only used for the server side)
I've thrown it away because no time and I wanted to build it in a way that is friendly to manage with salt, puppet and so on

Before we chop the server modules we have to chop the third party modules in Mk/bsd.apache.mk (.elif defined(AP_PORT_IS_MODULE) ... ).

[mat]

In D7460#155185, @ohauer wrote:

Apache has had an internal way of knowing in which order to load modules
since 2.0 (or 2.2) so there is no reason to add numbers to the file names.

No entry true, specially in combination with third party modules (that's the reason I've added numbers in the name)

Personally I dislike the idea to chop non third party modules into dedicated configs, and it is one of the reason all my apache servers don't run on RHEL, or (specially) Debian.

The idea is that the main httpd.conf never gets changed by the user, so that pkg upgrade always update it.

If you dislike mixing the apache modules with the third parties modules, we can put them in different directories, one for the apache ones, and one for the third parties.

[ohauer]

Found the module ID part:
http://people.freebsd.org/~ohauer/diffs/patch-Mk__bsd.apache.mk

The idea is that the main httpd.conf never gets changed by the user, so that pkg upgrade always update it.

In this case we have to chop httpd.conf into dedicated files, users will enable in httpd.conf maybe additional file includes like autoindex.conf, userdir.conf change the logging section and so on, going the RHEL way and enabling per default all modules and additional include files is the easy but in my opinion the wrong way.

For example I'm overwriting always the log_config section (cronolog and logging additional the virtual server name)

[mat]

In D7460#155209, @ohauer wrote:

Found the module ID part:
http://people.freebsd.org/~ohauer/diffs/patch-Mk__bsd.apache.mk

The idea is that the main httpd.conf never gets changed by the user, so that pkg upgrade always update it.

In this case we have to chop httpd.conf into dedicated files, users will enable in httpd.conf maybe additional file includes like autoindex.conf, userdir.conf change the logging section and so on, going the RHEL way and enabling per default all modules and additional include files is the easy but in my opinion the wrong way.

For example I'm overwriting always the log_config section (cronolog and logging additional the virtual server name)

Mmmm, ok, so, let me rephrase my earlier answer. It's not so much about the user not having to touch httpd.conf, it's more about reducing POLA, thus the extensions not being in it. For example, say, the user uses the official packages:

• pkg install apache24
• edit httpd.conf to enable a few extensions, like, say, ssl and socache_shmcb
• some updates are done to apache, some more extensions are now built with it
• pkg upgrade
• the new extensions are in not in httpd.conf, but they are in httpd.conf.sample, so, the user will have to go look around in the sample file (and know it exists) to get the new LoadModule lines into his httpd.conf. This is not good.

Other example:

• pkg install mod_php56
• I uncomment the LoadModule line in httpd.conf that mod_php56 magically added
• some time later, after php has been updated
• pkg upgrade
• the LoadModule php line is gone, or has been commented out, I'm not happy :-)

With one LoadModule (it being commented or not) per file, using @sample, what the user comments or uncomments never gets changed.

What might change is the default state of enabledness of a module, but that could already have happened before.

[mat]

• rebase.

[mat]

• Put apache's own modules in a separate directory.