Gentoo: Apache 2.4.2 – Analysis of possible solution to config changes

My head is dizzy from thinking about this, can’t even explain it so someone smart to get help. Time to write things down …

Introduction

Apache 2.4 needs some new modules. Some are really critical, some are just used for good reason in Gentoo’s default apache config – which won’t work without them.
For details see Upgrading to 2.4 from 2.2.
Normally the new flags/modules would just be handled like IUSE="+newflag", but Apache installation is different.
I already proposed a fix for the ebuild, but it’s not completely satisfying: Bug 410607 – www-servers/apache 2.4.1-r2 will not start with default conf

Current Apache installation process

Simplified … module dependency ignored here, etc.

• IUSE_MODULES: The ebuild defines modules in IUSE_MODULES, which are expanded in the eclass to flags like “apache2_modules_${module}”.
• MODULE_CRITICAL: If a module listed here is missing, apache-2_pkg_setup() will display a warning.
• Default flags/modules: All defined in the base profile (dating from 2007), nowhere else.
• Apache config: Loaded from a gentoo source. httpd.conf is adapted dynamically based on IUSE_MODULES.

This works perfect as long as all modules used in Gentoo’s Apache config are listed as flags in the base profile.
Anyone who changes default flags is stupid or can edit Apache config himself.
If he disables one of the critical flags, he will at least get a warning.
Basically it works out-of-the-box but you can do stupid things.

Issue with Apache 2.4

Apache 2.4.2 changed some modules, split existing modules, etc.
So now we have modules which are either critical or used in Gentoo’s config, which are NOT activated by default.

Simplified: Default setup will not work-out-of-the box and all I can do about it is display warnings. Or mask functionality in a way that no-one will notice it does not work.

Examples

1. unixd: Really needed
2. authn_core: Replaces previous critical module authn_alias
3. socache_shmcb: Used for SSLSessionCache in the config. Currently the only socache module in Gentoo.
4. proxy_balancer: Won’t work without 1 of 4 lbmethod-modules since 2.3

Possible solution parts

Possible ways of treating the several issues.

1. Updating base profile: Not likely to happen, is it?
2. Changing apache-2.eclass: So it expands IUSE_MODULES="+mymod" into IUSE="+apache2_modules_mymod"
3. <IfModule> in config: The enclosed functionality will depend on the module being present
4. REQUIRED_USE: Hard-disabling certain flag combinations
5. Dependent MODULE_CRITICAL: Like use ssl && MODULE_CRITICAL+=" socache_shmcb" thus triggering a warning in pkg_setup().
6. Special warnings in pkg_postinst(): Since some new flags must be set manually – they are not in the base profile – at least display warnings where they won’t be missed.

Pros/Cons

Pros and Cons of the above:

1. Updating base profile: Easy/smooth solution, but unlikely to happen.
2. Changing apache-2.eclass: A one-line change to the eclass might do it, but will it happen? I could do it ;)
3. IfModule: <IfModule socache_shmcb>SSLSessionCache</IfModule> in 40_mod_ssl.conf is tempting, but module socache_shmcb is not known to base profile. So most will think everything is fine and never notice they don’t have SSLSessionCache.
4. REQUIRED_USE: Prevent people from being stupid?
   We don’t do that for single critical modules at the moment and that’s the way it should stay imho.
   On the other hand we do that for module dependencies in MODULE_DEPENDS – you can’t install dav_fs without dav for ex.
   REQUIRED_USE is more flexible for situations like the split-off lb-methods from module proxy_balancer.

   REQUIRED_USE="${REQUIRED_USE}
       apache2_modules_proxy_balancer? ( || (
           apache2_modules_lbmethod_byrequests
           apache2_modules_lbmethod_bytraffic
           apache2_modules_lbmethod_bybusyness
           apache2_modules_lbmethod_heartbeat
       ) )"

   is something the eclass with MODULE_DEPENDS cannot do.
   But we’d have to lift EAPI from 2 to 4 … the eclass can handle it in my tests :)
   And the error-message is not apache-specific like from the eclass.

5. Dependent MODULE_CRITICAL: Well, a warning in pkg_setup() is not cutting it for important stuff everyone has to add manually.
6. Special warnings in pkg_postinst(): Better, but not enough. But we can issue warnings dynamically for specific flag combinations – might be slighty messy.

My proposal

A. Non intrusive approach

Not altering profile defaults or eclass …
I see only partial/non-satisfying solutions, where everyone will run into an error and then has to set flags manually.

I’d combine these approaches:

1. REQUIRED_USE: Not for critical flags, but for a “need 1 out of 4” solution like proxy_balancer. Implies changing EAPI from 2 to 4. That would be congruent with current behaviour – modules can depend on each other, MODULE_DEPENDS is just not flexible enough atm. proxy_balancer module can be activated without them – no warning/error – but Apache states explicitly that you need one of them (Apache Module mod_proxy_balancer)
2. Warnings in pkg_postinst(): At least we can write “we told you” to every bug report :)
3. IfModule: Used sparingly! An error on apache-start is likely to get people to look at flags/modules – thus for SSLSessionCache let there be errors until the base profile is adapted. But everyone will run into them!

B. Altering eclass/profile

I could propose patches to both … should I? ;-)

Update:
I did, see Bug 427946 – apache-2.eclass: Proposed enhancement: USE_EXPAND of APACHE2_MODULES should support IUSE-DEFAULTS

Random things

1. OpenSSL: Why is this inherited unconditionally? Not dependent on ssl? Probably because the eclass inherits ssl-cert, also unconditionally => Change that in eclass?
2. My tests: Using my clumsy Ebuild Test Suite, I currently loop over ~80 different combinations of use flags, installing each, restarting apache, then testing wget localhost. If ssl is active, I also test wget --no-check-certificate https://localhost. This is by no means a test of the modules functionality, but I can expand the tests and repeat them anytime although a full run takes hours.