* Marc Haber > I just found out that munin can run as a CGI, while avoiding > re-generating the graphs every five minutes regardless of a browser > actually asking for them. > > That option is very well hidden in the docs, and activating it means > to do deep changes inside the package.
Sadly, documentation is sub-par for the entire package. :-( I'll try to document it better, at least how to enable it in a Debian environment. > (3) > Have the cron job > (3a) run as root > (3b) drop privileges before invoking one of the four munin scrips > (3c) chown /var/log/munin_graph.log and the appropriate files in > /var/www/munin either to www-data or munin regarding on whether > graph_strategy is cron or cgi > (3d) only run munin_graph and munin_html if graph_strategy is cron. > > With the Hack in (3c), you don't need to worry about updates, and the > local user can even change her preferences any time. The cron job will > then just do the right thing. I don't really like this idea, too hacky. It makes the actual permissions on the filesystem diverge from what dpkg believes (can be handled by using dpkg-statoverride instead of chown though), and needs to implement its own config file parser (htmldir and logdir can be changed to whatever in /etc/munin/munin.conf - I would need to handle that as well), and finally, it will break setups where someone is already using some technique to run the CGI as the munin system user (SuEXEC, the Perchild MPM in Apache2, sudo, whatever). That's almost impossible to spot in a exact manner. I believe a better idea is what I discussed with you on IRC: Change the location where the CGI stores the PNGs to outside of the HTML directory. This requires upstream changes, but I've got a quite nice relationship to Jimmy so that shouldn't be a problem. :-) I've got a proof of concept patch that seems to work just fine already, placing the PNG's in $cgicachedir/<domain>/, where $cgicachedir can be defined in munin.conf to be /var/cache/munin-cgi or something like that. I belive this is a more correct way of doing it in any case, as the purpose of the PNGs change slightly when run through the CGI - without it they are just static files that take part in a static web page which are supposed to be served by a web server and therefore needs to be found within the DocumentRoot, but when the CGI is in use, they're just cache files for a stand-alone application (the CGI itself), and not something the web server cares about at all. The only drawback, as I see it, is that when you change from one graph_strategy to another, the first graph process with the new strategy won't be able to use the PNGs from the old directory and will therefore need to regenerate all of them. But I'm not too concerned about that, one's presumably not changing that setting all the time anyway. This approach will only require changes to the permissions on the log files and directories, which I don't have a problem with at all. > It is my opinion that CGI mode should be the default, but with the > cron magic in place, it doesn't really matter since changing is easy. I think I'll just go for the upstream default here, which currently is the static pages. Seems easier, and works with all webservers that have a absolute minimum feature set (able to serve static files). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
