Packaging Web Applications and Modules for Apache HTTPD 2.4 in Jessie

Contents

  1. Packaging Web Applications and Modules for Apache HTTPD 2.4 in Jessie
    1. General instructions
    2. Upgrading notes
    3. Maintainer scripts
    4. Packaging Modules and Web Applications
      1. Modules
      2. Web applications
        1. Web Applications in a nutshell (without dh_apache2)
        2. Web Applications in a nutshell (with dh_apache2)
        3. Making web applications compatible to both, Apache 2.2 and 2.4
    5. Changes to modules' source code

This Wiki page is intended to give practical hands on experience how to package modules and web applications in Debian. Jessie is supposed to ship Apache HTTP 2.4 which requires a major rework of reverse dependencies in Debian.

General instructions

Generally, instructions for packaging modules and are documented in the PACKAGING file included within the apache2 binary package. The latest revision is also available in our version control system under

https://salsa.debian.org/apache-team/apache2/blob/master/debian/PACKAGING

Please refer there for the reference documentation. This Wiki page is meant as a practical hands-on tutorial extended by some more explanations. It does not replace the packaging hints.

Upgrading notes

Maintainer scripts

Aside of changed dependencies, the biggest change involves maintainer scripts. We intend to consolidate behavior of maintainer scripts, to make it predictable and configurable how modules and web applications behave after the installation.

To achieve this, you should not decide yourself when and if to enable a given piece of configuration or whether or not to restart the web server after installation of your configuration snippet. Likewise, do not decide yourself whether or not to enable a particular module you install in your package.

Instead, call our helper scripts which will behave in a predictable and configurable behavior. In the end, we want to let the site administrator to decide how modules and web applications should behave. Thus, see our documentation how to use apache2-maintscript-helper.

Packaging Modules and Web Applications

Below you find some simple tutorials to get started to build packages which shall depend on apache2 in one or another way.

Modules

Modules should really use dh_apache2 to get things right. It makes packaging Apache2 modules easy, otherwise you need to be especially careful to get dependencies right. Take special care not to depend' on apache2 or apache2-bin. Your module binary package must depend on the virtual API version package we provide instead. In a nutshell, this is how to create a module package:

Web applications

If you are upgrading your package from Wheezy you probably need to move your configuration files from /etc/apache2/conf.d/yourpackage to /etc/apache2/conf-available/yourpackage.conf. You can use dpkg-maintscript-helper(1) to move configuration files properly. It supports a mv_conffile function you can call. If you are using debhelper, consult dh_installdeb(1) how to automate interaction with dpkg-maintscript-helper.

You can, but you don't need to install your configuration files yourself. It is suggested to use dh_apache2 instead by build-depending on dh-apache2. Don't worry if this pulls apache2-dev for now, dh_apache2 should be shipped within the regular debhelper at some point if everything goes well.

Do not interact with Apache wrapper scripts in your maintainer scripts directly. It can be complex and complicated to decide when to enable a particular piece of configuration. You should use apache2-maintscript-helper instead. Doing that you do not need to worry whether and when to enable a given configuration. If you are using dh_apache2 it does the job for you. Be careful when writing your own maintainer scripts, web applications generally should not depend unconditionally on apache2. Thus, neither our maintscript-helper nor our a2enmod and friends tool will be available at runtime.

Web Applications in a nutshell (without dh_apache2)

    if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
        . /usr/share/apache2/apache2-maintscript-helper
        apache2_invoke enconf yourapplication.conf || exit $?
    fi

    if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
        . /usr/share/apache2/apache2-maintscript-helper
        apache2_invoke disconf yourapplication.conf || exit $?
    fi

Web Applications in a nutshell (with dh_apache2)

Making web applications compatible to both, Apache 2.2 and 2.4

It is possible to web applications to make them compatible to both, Apache 2.2 and Apache 2.4. That's useful until Apache 2.4 reaches Testing, or you want to support Wheezy backports of your shiny new upstream version of your web application.

Special must be taken when considering dependencies. Do depend or recommend on the apache2 web server package. Do not declare any package relation towards apache2.2-common. For the 2.2 package the dependency pulls apache2.2-common, for the 2.4 package it pulls the respective equivalent, too.

You can use dh_apache2 if you want, but you shouldn't rely on its maintainer script hooks as they won't cope with 2.2 packages. Aside, make your package as usual. If you are using dh_apache2, you may want to use this rules file: 

%:
        dh $@  --with apache2

override_dh_apache2:
        dh_apache2 --noscripts

Chances are, your configuration needs some adaption whether it is running under Apache 2.2 or 2.4. In that case you can use the <?IfVersion> clause, for example like this: 

<Directory /usr/share/foo>
  ...
  <IfVersion >= 2.3>
    Require local
  </IfVersion> 
  <IfVersion < 2.3>
     Order Deny,Allow
     Deny from all
     Allow from 127.0.0.1
  </IfVersion>   
</Directory>

But please note: You must have the "version" module enabled to do so. We did so for the Apache 2.2 version shipped in Wheezy, and Apache 2.4 (starting with version 2.4.1-3, which was available in Experimental only). Thus, typically no action from your side is required.

In your maintainer scripts, the bottom line is to detect whether the site administrator runs Apache 2.2 or 2.4. Moreover, you should note it's intentional that the link in prerm is always removed:

This is a postinst fragment (assuming your configuration file is foo/foo.conf): 

if [ "$1" = "configure" ] ; then

        CONF="foo"
        COMMON_STATE=$(dpkg-query -f '${Status}' -W 'apache2.2-common' 2>/dev/null | awk '{print $3}' || true)

        if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
                . /usr/share/apache2/apache2-maintscript-helper
                apache2_invoke enconf $CONF || exit $?
        elif [ "$COMMON_STATE" = "installed" ] || [ "$COMMON_STATE" = "unpacked" ] ; then
                if [ -d /etc/apache2/conf.d/ -a ! -L /etc/apache2/conf.d/$CONF.conf ]; then
                    ln -s ../conf-available/$CONF.conf /etc/apache2/conf.d/$CONF.conf
                fi
        fi

fi

And this the prerm counterpart: 

if [ "$1" = "deconfigure" ]  ; then

        CONF="foo"
        COMMON_STATE=$(dpkg-query -f '${Status}' -W 'apache2.2-common' 2>/dev/null | awk '{print $3}' || true)

        if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
                . /usr/share/apache2/apache2-maintscript-helper
                apache2_invoke disconf $CONF || exit $?
        elif [ "$COMMON_STATE" = "installed" ] || [ "$COMMON_STATE" = "unpacked" ] ; then
                [ ! -L /etc/apache2/conf.d/$CONF.conf ] || rm /etc/apache2/conf.d/$CONF.conf
        fi

fi

Changes to modules' source code

Some hints are available at http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html . Even if your module compiles and works without changes, you should at least add the APLOG_USE_MODULE statement described in that page to take advantage of per-module loglevel configuration.