By default, debian's munin is not ready for switching html_strategy and
graph_strategy to cgi because of a lack of access permission for the (apache2)
www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .

This can be resolved by allowing the respective owner groups write access

.. and adding the www-data user to the owning groups for both:

With this, the cgi strategies work beautifully, including dynazoom.

Hello Marcel,

thank you for your bug report!


Am Tue, 14 Apr 2020 16:40:12 +0200
schrieb Marcel Partap <mpartap@gmx.net>:

are you really sure, that these steps are necessary?

The munin package uses autopkgtests. One of the tested scenarios is the switch
to the CGI-based rendering. The preparations for this step are quite trivial:
* change the strategies to "cgi"
* toggle the enabled line in the apache configuration (as documented there)

(see
https://salsa.debian.org/debian/munin/-/blob/debian/debian/tests/enable_cgi_strategy.inc)

Afterwards it should work. At least the current tests do not fail ...


The permissions should be handled automatically during package installation:

   touch /var/log/munin/munin-cgi-html.log
   chown www-data:adm /var/log/munin/munin-cgi-html.log
   chmod 640 /var/log/munin/munin-cgi-html.log

   touch /var/log/munin/munin-cgi-graph.log
   chown www-data:adm /var/log/munin/munin-cgi-graph.log
   chmod 640 /var/log/munin/munin-cgi-graph.log

   mkdir -p /var/lib/munin/cgi-tmp
   chown munin:www-data /var/lib/munin/cgi-tmp
   chmod 775 /var/lib/munin/cgi-tmp
(see the postinst script)


Maybe you are cleaning up the log directory (e.g. on a read-only system) during
a reboot?
In this case it would indeed fail. I guess, it would be nice for the package to
also work in such situations (e.g. non-permantent /var/log/).

Or do you have another idea, what could be wrong?

Cheers,
Lars

I have this issue too, and was able to diagnose the cause and (probably) why
the autopkgtest did not discover it.

The relevant portion of the postinit script is this:

```
case "$1" in
        configure)
                if [ -z "$2" ] ; then
                        initperms
                        apache_install "$@"
                fi
                ;;
esac
```

So, it only runs the `initperms` on new installs (`$2` is the previous
version, if any).

This is a problem specific to upgrades of existing installs AFAICT.

Running `sudo bash -x /var/lib/dpkg/info/munin.postinst configure` gets
through enough of the init script to do the permissions fix before crapping
out on the debhelper stuff (which expects a proper set of env vars that
aren't set).