Differences between revisions 9 and 10
Revision 9 as of 2012-01-31 22:37:12
Size: 10717
Editor: ?ArnoToell
Comment:
Revision 10 as of 2012-02-12 00:10:53
Size: 11759
Editor: ?ArnoToell
Comment:
Deletions are marked like this. Additions are marked like this.
Line 184: Line 184:
== 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.

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.

Done as of 7adf400f42a6ace8599a91c8b836ddf82e2a8826.

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 7adf400f42a6ace8599a91c8b836ddf82e2a8826.

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.

Done as of 7adf400f42a6ace8599a91c8b836ddf82e2a8826.

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.

Work in progress. Essentials are there

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. However, reverse dependencies need a transition. That can not be addressed until there is a uploadable package ready.

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.

The new 2.4 package is much easier to be understood than the 2.2 package. That helps.

Use debhelper executable configuration files

Currently, we're moving some files directly into binary packages at build time. This is, because debhelper couldn't rename files in the past. Now it can by using executable configuration files. Make use of that feature in debhelper 9 compatibility mode

Seems not needed anymore

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.

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 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.

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.

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

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.

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)).