Bug#716880: Solutions for the Apache upgrade hell
Hi Arno,
On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote:
> Hello,
>
> we've got a problem with Apache that causes problems during upgrades
> (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
> changed ABIs, so that we need to ensure that dpkg properly removes
> packages linking against the obsolete ABIs at upgrade time. This is the
> first time this happened since Debian Etch, so this brings a problem to
> the spotlight, that hasn't been one for a long time.
>
> To summarize the bug reports: The problem is, that Apache package
> maintainers at that time decided, that third party modules shall depend
> on apache2.2-common, by guaranteeing ABIs remain stable as long as the
> package name does not change. This is, so far policy compliant. However,
> by now ABIs did change and we were forced to rename the package (we did
> so, by providing a virtual API package third parties must depend on. At
> time of writing this is apache2-api-20120211). Unfortunately,
> apache2.2-common also contains conffiles and configuration file handling
> in postinst/postrm ...
>
> I spent a lot of time to properly transition to a new state with
> conffiles/configuration separated from ABI handling, and this works well
> enough for regular updates by now.
>
> Unfortunately it turns out, that /a lot/ of people use "aptitude
> --purge-unused safe-upgrade", or the apt equivalent "apt-get
> dist-upgrade --purge" which causes dpkg to purge the user's
> configuration, in particular enabled modules, during the upgrade because
> apache2.2-common disappears in that step. Those people end up with
> effects as described in the bugs outlined above, for example with
> incomplete installations because our maintainer scripts had no chance to
> properly detect the state of the /etc/apache2 directory before the
> upgrade.
>
> This gives us three possibilities which all have unwanted side effects
> (unless you come up with an idea that all of us makes happy). I'm
> writing to this list in hope that someone has a very smart idea to make
> everyone happy, or express your support for either alternative to give
> us some insights what people think would be the best alternative.
>
> * Add a apache2.2-commmon transitional package. This gives us a chance
> to inspect /etc/apache2 in spite of --purge-unused and properly
> transition to Apache 2.4. HOWEVER, this has the nasty side effect that
> modules ABIs are considered compatible as far as dpkg is concerned.
> Therefore, old module packages aren't forced to be removed and this
> breaks at runtime when people try to start their upgraded web server
> with incompatible modules. As a workaround we could add a versioned
> "Breaks" for all modules in Wheezy (~ 75) in the apache2.2-common
> transitional package, and in addition for packages that existed in
> Squeeze or Etch only (no, really). That said, this still won't help for
> third party modules outside Debian which people might use (and to my
> best knowledge, they do a lot) and it's generally problematic in view of
> the policy with respect to library packaging (even though we're not a
> library strictly speaking)
This + BIG FAT WARNING in release notes seems to be the best option
to me.
People's configuration will probably break anyway due custom
configuration
files, etc. or manually compiled modules[1][2].
Also if people have custom modules that will get removed in the upgrade,
they wouldn't want to start the apache without those modules anyway -
this could have all kind of security implications - exposing the raw
source
files of interpreted languages, etc.
1. As an option you can walk through all enabled modules in apache2.4
postinst and detect incompatible ABI in /usr/lib/apache2/modules/*.so
files.
2. As a thought did you think about moving the modules under
/usr/lib/apache2/20120211/ (e.g. similar to what PHP has). You still
have time for that and it would make the transition easier in the future
(also with third party modules).
Cheers,
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: