mod_disk_cache enabled globally by default

I cannot reproduce this -- on both fresh installs of Hardy and Dapper->Hardy upgrades, the disk_cache module is not enabled.

That's really strange. So there's no disk_cache.conf or disk_cache.load in your /etc/apache2/mods-enabled? Did you use the command-line upgrade tool (do-release-upgrade)? I had very little else installed on this machine at the time.

Obviously this is the best kind of bug. The kind we can't reproduce.

In any case I think the disk_cache.conf file should be changed to not actually enable caching. If the user wants caching she'll want to enable it for specific directories, certainly not for the entire server. Would you consider changing the .conf file?

On Mon, Apr 21, 2008 at 03:49:40PM -0000, Andrew Jorgensen wrote:
> In any case I think the disk_cache.conf file should be changed to not
> actually enable caching. If the user wants caching she'll want to
> enable it for specific directories, certainly not for the entire server.
> Would you consider changing the .conf file?
>

Considering that the disk_cache module is not enabled by default, I
don't think we should change the .conf file. Doing so would mean that a
user has to do two things to enable disk caching: load the module *and*
configure the urls to cache.

We'd rather provide a default setup that works out of the box - thus caching
/.

  status wontfix

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

This is very simple to reproduce. Take a dapper box, enable mod proxy
and upgrade to hardy. The following code in the postinst will then
kick in.

| if [ $UPGRADE = from_2_0 ]; then
| # Module replacements from previous versions of apache2
| if mod_is_enabled proxy; then
| a2enmod proxy_http
| a2enmod disk_cache
| fi

It's completely unacceptable for disk caching to be unconditionally
enabled across all sites on upgrade just because I was using mod proxy
previously. Please fix this.

Wow, thanks for tracking that down James. I knew I wasn't crazy.

Marking as critical for 8.04.1, since we don't have a good way to fix this for users after they've upgraded from dapper and .1 will turn on our LTS upgrades for all users.

Chuck, Kees nominated you to take care of this package today for hardy SRU; please unassign yourself if you aren't going to be able to get to this.

According to the Debian bug, enabling the disk_cache module on upgrade is the right thing to do. The proxy.load file in dapper loads mod_disk_cache. Not enabling it on upgrade would break existing system (as reported in the debian bug).

However, the apache2.2 package comes with disk caching enabled by default as of 2.2.4-2:

  * Disk caching is now enabled by default if mod_disk_cache is enabled. If
    you don't want to use disk caching, check that mod_disk_cache is disabled
    (it was enabled automatically by previous versions when mod_proxy was
    enabled). In this case, you might also want to remove any cache files from
    /var/cache/apache2/mod_disk_cache .

    To ensure that the disk cache does not grow indefinitely, htcacheclean is
    now started when mod_disk_cache is enabled. The details can be configured
    in /etc/default/apache2 .

This is done by using "EnableCache disk /" in disk_cache.conf (the same applies to mem_cache.conf). Removing this directive would not enable caching of / by default, but disk_cache would still be loaded if the proxy module was enabled in dapper. That way existing configurations using disk_cache won't break (mod_disk_cache is loaded), but existing configuration not using disk_cache won't have caching turned on by default.

This behavior is because in 2.0, proxy.load and proxy.conf contained the "LoadModule disk_cache_module" and the mod_disk_cache config. Not enabling mod_disk_cache on upgrades would break caching for proxies (debian bug 407171).

Maybe enabling mod_disk_cache on upgrades only if something like

egrep -iq '^[[:space:]]*cacheenable' /etc/apache2/apache2.conf /etc/apache2/mods-enabled/* /etc/apache2/sites-enabled/* /etc/apache2/conf.d/* /etc/apache2/httpd.conf

(in preinst) gives true would be better.

I've attached a debdiff that fixes the issue for intrepid.

I've attached a debdiff for hardy-proposed. It includes sf suggestion to not enable disk_cache on upgrades from 2.0. As suggested by elmo, even if we don't set EnableCache in disk_cache.conf, have disc_cache.load will start htcacheclean automatically.

As per above, enable mod_cache can have adverse side effects for websites. This is a regression from dapper to hardy upgrade due to mod_cache been enabled globally.

STEPS TO REPRODUCE THIS:

1. Install dapper apache with mod_proxy enabled.
2. Upgrade to hardy.
3. Check to see if caching is enabled on all sites.

If you have any questions please let me know.

Thanks
chuck

That looks alright to me. Is there any way to find out whether the admin configured caching for / after installation, or whether that happened autoamtically during dapper -> hardy upgrade? In the latter case it would be better to disable it again in the postinst. But if that is tricky, I'm fine with uploading this current patch and err on the side of caution.

Martin,

Not easily I have tested the debdiff and it does have the desired effect. For intrepid we could probably make it a bit smarter.

Thanks
chuck

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package apache2 - 2.2.9-2ubuntu1

---------------
apache2 (2.2.9-2ubuntu1) intrepid; urgency=low

  * debian/config-dir/mods-available/disk_cache.conf:
    Don't enable caching of the root URL by default when disk_cache is
    enabled. (LP: #219914).
  * debian/control: Update Maintainer field.

 -- Mathias Gug <email address hidden> Tue, 24 Jun 2008 15:03:27 -0400

apache2-mpm-itk (universe) needs also a new rebuild-only SRU because of this apache2 SRU. It's tracked in bug #243012.

Here are the two test cases I've run for this SRU:

Test 1
======

Enable dapper-proposed and dist-upgrade.
Install update-manager-core, apache2.

Enable proxy module:
  sudo a2enmod proxy

Do release upgrade:
  do-release-upgrade -d

Check that the disk_cache module is not enabled after the upgrade (and that proxy_http is):
 * Upgrade logs:
Module alias installed; run /etc/init.d/apache2 force-reload to enable.
Module autoindex installed; run /etc/init.d/apache2 force-reload to enable.
Module dir installed; run /etc/init.d/apache2 force-reload to enable.
Module env installed; run /etc/init.d/apache2 force-reload to enable.
Module mime installed; run /etc/init.d/apache2 force-reload to enable.
Module negotiation installed; run /etc/init.d/apache2 force-reload to enable.
Module setenvif installed; run /etc/init.d/apache2 force-reload to enable.
Module status installed; run /etc/init.d/apache2 force-reload to enable.
Module auth_basic installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_default installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_user installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_groupfile installed; run /etc/init.d/apache2 force-reload to enable.
Module authn_file installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_host installed; run /etc/init.d/apache2 force-reload to enable.
Enabling proxy as a dependency
This module is already enabled!
Module proxy_http installed; run /etc/init.d/apache2 force-reload to enable.

 * $ ls /etc/apache2/mods-enabled/*cache*
   ls: cannot access /etc/apache2/mods-enabled/*cache*: No such file or directory

 * $ ls /etc/apache2/mods-enabled/*proxy_http*
   /etc/apache2/mods-enabled/proxy_http.load

Test 2
======

Enable dapper-proposed and dist-upgrade.
Install update-manager-core, apache2.

Enable proxy module:
  sudo a2enmod proxy

Enable disk caching for the root url:
 * edit /etc/apache2/sites-enabled/000-default
   to add "CacheEnable disk /" to the VirtualHost section:

  <VirtualHost *>
    [...]

+ CacheEnable disk /

  </VirtualHost>

Check that caching works:
 * Load the index.html page from the web server in a browser.
 * $ ls /var/cache/apache2/proxy/
   0g E3 jM

Delete cache:
 rm -rf /var/cache/apache2/proxy/*

Do release upgrade:
  do-release-upgrade -d

Check that disk_cache and proxy_http modules are enabled after the upgrade:
 * Upgrade logs:
Module alias installed; run /etc/init.d/apache2 force-reload to enable.
Module autoindex installed; run /etc/init.d/apache2 force-reload to enable.
Module dir installed; run /etc/init.d/apache2 force-reload to enable.
Module env installed; run /etc/init.d/apache2 force-reload to enable.
Module mime installed; run /etc/init.d/apache2 force-reload to enable.
Module negotiation installed; run /etc/init.d/apache2 force-reload to enable.
Module setenvif installed; run /etc/init.d/apache2 force-reload to enable.
Module status installed; run /etc/init.d/apache2 force-reload to enable.
Module auth_basic installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_default installed; run /etc/init.d/apache2 force-reload to enable.
Module authz_us...

In the second test case described above, the first occurence of "load the index.html page in browser" should be load "/apache2-default/" as index.html doesn't exist in dapper.

Thanks for your detailled test report!

Mathias Gug [2008-06-25 19:33 -0000]:
> In the second test case described above, the first occurence of "load
> the index.html page in browser" should be load "/apache2-default/" as
> index.html doesn't exist in dapper.

Does that mean, it was just a copy&paste error in the bug followup, or
there is actually something wrong in the package?

On Thu, Jun 26, 2008 at 06:53:00AM -0000, Martin Pitt wrote:
> Thanks for your detailled test report!
>
> Mathias Gug [2008-06-25 19:33 -0000]:
> > In the second test case described above, the first occurence of "load
> > the index.html page in browser" should be load "/apache2-default/" as
> > index.html doesn't exist in dapper.
>
> Does that mean, it was just a copy&paste error in the bug followup, or
> there is actually something wrong in the package?

It was a copy&paste error in the bug followup. There is nothing wrong in
the package as this operational step relates to the existing package in
dapper and is done _before_ the upgrade.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Copied to hardy-updates.