This page collects work needed towards the Wheezy release in preparation of the Apache 2.4 transition and associated packages.
Contents
-
Apache
- Migrated release goals from Lenny -> Squeeze
- Let the MPM packages die
- Drop unwanted -dev packages
- Streamline binary packages built from the source package
- Streamline the envvars approach
- Streamline the package building process
- systemd support
- Drop unneeded patches
- Improve conf.d mechanism
- Fix boot / init script issues or document solutions
- Use new access control config
-
Make policy for modules/webapps maintainer scripts configurable
- when are dependencies allowed to change the MPM
- how to deal with module dependencies in web applications
- Should we support a transitional fallback configuration which allows web apps to work with both 2.2 and 2.4 packages
- When to disable modules and web app confs in maintainer scripts (similarly, when to enable)
- TODO
- Rethink virtual hosts
- Web application policy
- Add more docs / example configs
- Transition
- Add entry to the release notes
- Make upstream happier
- Add hints to the Release Notes
- APR / APR-UTIL
- ssl-cert
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.
Done as of 2.4.1-1 (in experimental).
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.
Done as of 2.4.1-1 (in experimental). There is an experimental patch available, which needs to be carefully tested for 2.4 compatibility. Thus, ITK may or may not come back again.
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.
Done as of 2.4.1 (in experimental). Packagers should use "a2query" via our apache2-maintscript-helper.
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.
Done as of 2.4.1 (in experimental).
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.
Done as of 2.4.1 (in experimental).
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
Our side is ready and uploaded to experimental. Now, package maintainers need to update their packages and test whether their modules work with 2.4.
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
We try to help developers by providing a debhelper to get things right.
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.
The new 2.4 package is much easier to be understood than the 2.2 package. That helps.
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.
Mostly done. Patches may need some polishing perhaps.
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.
Configuration files were migrated to the new authorization system. Still needs a migration to an inherited permission system
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.
Frankly, a yellow box is a bit optimistic. Nothing is done yet. However, our new postinst policy asks reverse dependencies to use our apache2-maintscript-helper. Thus, a configurable policy can be amended by extending our helper more easy than before.
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)
Work on dh_apache2 has begun, talking to nginx folks they seem interested to consolidate dependencies as well. Hopefully we get some feedback on our d-d-a announcement.
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)).