Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• Apache2Transition

Wiki/

This page collects work needed towards the Wheezy release in preparation of the Apache 2.4 transition and associated packages.

Apache

Below a list of proposals of tasks to be addressed towards Apache 2.4

Migrated release goals from Lenny -> Squeeze

(see also Apache2SqueezeGoals)

• Migrate to 3.0/quilt: Done as of 2.2.21-4
• Interface with other packages
• Allow to run several instances of apache: Done as of 2.2.14-6, bugfixes in 2.2.19-1. Maybe some improvements are possible.

Let the MPM packages die

The separate mpm packages should go away. All mpm modules should go into the -bin package.

Drop the ITK MPM

There is mod_privileges in 2.4 which uses Solaris privileges to achieve something like mpm-itk. Maybe mpm-itk for 2.4 can use a similar approach and exist as a normal module instead of as an mpm. But that's something itk upstream has to worry about. Until that's decided, we may just drop ITK for now.

Dealing with MPMs as simple modules

Some modules (aka: PHP) do still not work with some MPMs, e.g. threaded and require the prefork MPM. As MPMs are simple modules in 2.4 we do not have conflicting packages anymore a reverse dependency could depend on. Thus, we need to provide a runtime configuration check packages can make use of. For example the a2enmod mechanism could be extended by a conflicts declaration.

We also may provide a little helper script in apache2-dev reverse dependencies can use in their postinst script to find out about the MPM used.

Drop unwanted -dev packages

We also want only one -dev package. This might cause some troubles to PHP maintainers either them or we need to sort out. Probably mod_php should still be compiled without thread support and abort with an error message if used with a threaded mpm.

Streamline binary packages built from the source package

The fact that apache2.2-common contains the apache2 config files creates some problems. Suppose it is replaced with apache2.4-common, which would conflict with apache2.2-common and also contain the config files. This means that the config files have to move from one package to the other during update. During the upgrade from 2.0 to 2.2 this has caused problems because apt-get --purge dist-upgrade then apt-get purges the old package first (including any user-modified config) and only then installs the new package. We will have to work around that during the 2.2 to 2.4 upgrade, too, but maybe we can get rid of the problem for the future. I was thinking of something like:

• apache2 contains the config and the init scripts.
• apache2-bin contains all the binaries and provides apache2-mmn-20120123 or whatever the module magic number will be in 2.4.
• apache2-common (or apache2-data) would contain all the arch-independent files (mostly icons and error documents, I guess).

Module packages would only depend on apache2-mmn-20120123. This would mean we wouldn't need to rename packages if there is ever a 2.6 (and also not when going from 2.3 in experimental to 2.4). There should be a script or another easy way for module packages to add the correct dependency.

Cross/Circular Dependencies

• apache2 provides all HTTP virtual packages. Users are expected to install this particular package to get a working Apache instance. Web applications who want to setup a running Apache instance shall do likewise. This package pulls in apche2-bin as dependency.

• apache2-bin provides a magic module name (e.g. apache2-mmn-xxx) reverse dependencies which link against Apache should depend on. This package pulls in apache2-common as dependency

Thus, it is fully intentional that depending on apache2-bin does not setup a fully working web server, only required binaries. That way packages can setup their own instance of Apache as they need it (e.g. as gnome-user-share does). Web scripts (e.g. phpmyadmin) which want a fully working Apache instance shall depend on apache2 instead

Dealing with reverse dependencies

Special care must be taken when depending on Apache. A reverse dependency can be either a web script or an Apache server module which links against a particular version of the Apache web server.

• No package except of our own packages may depend on apache2-bin or apache2-common directly
• Web scripts must depend on apache2. If they depend on Apache by a transitional dependency (e.g. libapache2-mod-php5) they must declare a dependency against apache2 too.

• Packages linking against Apache (e.g. those who do declare a build dependency against apache2-dev or install something to /usr/lib/apache2/modules) must not depend on apache2 but apache2-mmn-xxx instead

Streamline the envvars approach

Instead of defining lots of stuff in the envvars file and using that in scripts and the config, it should be possible to get most infos from the output of "apache2 -t -DDUMP_RUN_CFG" and use that in scripts.

Streamline the package building process

The current rules file is complicated to say the least. Having MPMs integrated as module might simplify the rules file a lot. Make it more readable and usable.

systemd support

Provide systemd support, as an alternative to sysvinit for those who want and like it.

Drop unneeded patches

Some patches shouldn't be patches really. We can probably get rid of the config.sub/config.guess patch by using "dh --with autotools_dev" after sorting out it is still needed at all. Probably there are still some patches left that could be integrated upstream, too.

Improve conf.d mechanism

Automatically enabling config snippets provided by other packages is not suitable for all sites. A way to configure some choices would be nice:

• automatically enable globally
• automatically enable for default vhost (or for admin selected vhosts)
• don't enable automatically

Also, maybe only *.conf files should be included, to reduce conflicts with backup files.

Fix boot / init script issues or document solutions

There are some issues with boot dependency ordering if a webapp requires e.g. an SQL server to run. This should be fixed or the necessary configuration changes should be documented. See #610297.

There are some issues on systems with network manager. Maybe one could add a scriptlet that makes network-manager trigger a graceful reload when the network configuration changes. Maybe this is also fixed by fixing #629899 in apr

Maybe make the init script wait until apache2 has started. This would make it less likely that the init script is not printing an error but apache2 does not start. Also it would be good for cluster control scripts. See #645460.

Use new access control config

The access control config should probably use the new mechanisms. This would make it possible to only allow access to certain dirs (e.g. /var/www, /usr/share) while still making it easy for the admin to override what "allow access" means. This would probably require "?AuthMerging And" to be set.

Make policy for modules/webapps maintainer scripts configurable

Restarting or reloading apache when installing a new module/webapp is not suitable for all sites, especially large production sites. Maybe provide a config option for the admin to disable this and provide a script for other packages to easily use that config.

Result from some discussion:

when are dependencies allowed to change the MPM

Only modules should be allowed to switch the MPM, web applications must not switch the MPM at runtime (but see TODOs below).

To actually switch the MPM, packagers can use a2query to find out whether it is necessary, and if it is try to switch it. By "switching" using the corresponding API call is meant, under no circumstances packages should try to do their own. If that one fails (i.e. config-test fails) the maintainer script should emit a big warning but not fail.

how to deal with module dependencies in web applications

One possible solution would be too support Depends in conf-available files (if we manage to mitigate its abuse).

Problem: We don't want a webapp to enable a dependency, which switches MPMs, ... but simply enabling mod_alias or mod_rewrite seems ok.

Should we support a transitional fallback configuration which allows web apps to work with both 2.2 and 2.4 packages

in postinst: check for 2.2 with dpkg-query, if yes: create symlink from conf.d/XXX to conf-available/XXX in prerm: remove symlink during remove or purge in config: use <?IfVersion> guard if necessary, then the package has to a2enmod version if 2.2 is installed. For 2.4, we will compile mod_version in statically.

A simple example how to use such a fallback:

        if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
                . /usr/share/apache2/apache2-maintscript-helper
                apache2_invoke enconf package.conf
        elif  dpkg-query -f '${Version}'  -W 'apache2.2-common' > /dev/null 2>&1 ; then
              # if the configuration uses <IfVersion> uncomment the next line
              # a2enmod -q version
              [ -d /etc/apache2/conf.d/ ] && [ ! -l /etc/apache2/conf.d/package.conf ] && ln -s ../conf-available/package.conf /etc/apache2/conf.d/package.conf
        fi

NOTE: The above is broken because it will also go into the else branch if apache2 is not installed at all. dpkg-query should be used instead.

QUESTION: Is the above note still correct? The code seems to handle the "apache absent" case just fine? -ZugSchlus 20130903

and in postrm:

     [ -l /etc/apache2/conf.d/package.conf ] && rm /etc/apache2/conf.d/package.conf

When to disable modules and web app confs in maintainer scripts (similarly, when to enable)

modules

modules should unconditionally call apache2_invoke (unless a maintainer or debconf script verified not to install any configuration at all, e.g. for scripts supporting several web servers), it will obey site local policies in future. The maintainer helper will make sure that during upgrade of a module package, disabled modules are not enabled again.

modules need to be disabled on removal (and purge anyway), or config will be broken (?LoadModule would fail)

webapps

Derive the same behavior as modules IF the web application can be run with a feasible out-of-box configuration, don't enable it otherwise Should also be disabled on removal (and purge anyway), because important files may be missing (and that's the point of package removal, anyway).

modules and webapps must call apache2_invoke dis* both on removal and on purge. apache2_invoke will remember stuff it removed during removal and will reenable it during reinstall.

For that, the maint-script-helper needs to store $@ somewhere when it is first sourced. Document somewhere that $@ must be intact at that time. Complain if $1 is empty (that's meant as sanity check because $1 contains the maintainer script argument and is guaranteed to be set by dpkg).

The rembering could be done like: touch /var/lib/apache2/modules_disabled_by_maintscript/$module purge should then do rm -f /var/lib/apache2/modules_disabled_by_maintscript/$module in addition.

TODO

• Think when/whether to purge the conf.d directory, e.g. in apache2' postinst
• change the API of apache2_invoke to be more easily extensible (maybe only one module/conf per invocation, this would allow adding optional parameters later)
• change dh_apache2 accordingly (which is not that trivial as there is no easy way to source script fragments in autoscripts)
• If the complexity overboards, the maint-helper can be changed to a shell wrapper that calls a perl script later on (but hopefully not for wheezy).
• the maint helper should log problems into some dedicated log file in /var/log/apache2

(in addition to printing them to the screen unless the maintainer set APACHE2_MAINTSCRIPT_HELPER_QUIET=1)

• Ask mod_perl guys about what MPM requirements they usually have. It seems that mod_perl does support threading, but some mod-perl webapps don't.

Rethink virtual hosts

There is a not very well known way to use one virtualhost section for both ssl and non-ssl. We could consider if we want to use that (quite possibly a bad idea because it would collide with basically all how-tos out there) or provide it as an alternative config example. If not, it may make sense to move most of the settings of the default vhost to a separate include file.

Also see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/332087

Web application policy

Together with maintainers of other web servers we should approach a "web application policy". For reasons outlined above a web application need to depend on web servers this way (or recommend - that's subject to discussion):

• libapache2-mod-whatever | any-alternative, apache2 | httpd

On the other hand packages which build-depend on apache2-dev need to declare dependencies to

• apache2-mmn-xxx

instead. We may write a static Lintian check which checks whether dependencies are in place. For example we could check for a build-dependency on apache2-dev or whether a package installs files to /usr/lib/apache2/modules. Furthermore, we could write a script in apache2-dev (or eventually debhelper, say dh_apache2) which fills in the right dependency automatically.

See the mailing list for ongoing discussion on possible web application policies (http://lists.debian.org/debian-devel/2012/01/msg00148.html)

Add more docs / example configs

• For using php with FCGI (together with the PHP maintainers)
• For running apache2 with the chroot directive configured

Transition

Filed some bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24transition;users=debian-apache@lists.debian.org

Add entry to the release notes

Upgrading will need manual changes by the admin in most cases. Document that in the release notes

Make upstream happier

It turned out, upstream is very unhappy with the Apache configuration for Debian. That's mostly a heritage dating back to Etch days and things slightly improved since then. Some of their critics is summarized in http://wiki.apache.org/httpd/DebianDeb0rkification. Maybe we could take the opportunity and improve things again. Maybe we can make upstream happy happier. These are things suggested by upstream:

• Don't do global <Directory /> stuff in the default vhost. Maybe we should combine that with permission inheritance which is planned anyway.

• Provide a summary in apache2.conf how our maintainer scripts should be used (a2enmod, a2ensite, conffiles ...)

• Make a more sane (i.e. actually enabled directives) conf.d/security file.

• Provide a /usr/sbin/httpd symlink to your apache2ctl

• Get rid of the (intentionally left blank) httpd.conf or document it is not the actual configuration file. Maybe we should find out whether this file is still needed at all.

Finally, the current configuration contains lots of bug references involving configuration changes. These need to be triaged.

Add hints to the Release Notes

Apache2 is an important package where every change affects lots of users. The release notes should feature a (brief) hint about this change.

APR / APR-UTIL

• Switch to format 3.0 (quilt)
• Add support for multi-arch
• Migrate repositories to git
• Depend on libtool and use system libtool or document why it is not possible and close #489625

ssl-cert

Fix some bugs (see BTS):

• Check if we can provide utf8 support even if the locale is not utf8
• ...

Maybe migrate to git (it's already format 3.0 (native)).