Hi, On Mon, May 09, 2005 at 12:30:55PM +0200, Tore Anderson wrote: > * Marc Haber > > (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.
I find it quite straightforward. > It makes the actual > permissions on the filesystem diverge from what dpkg believes (can be > handled by using dpkg-statoverride instead of chown though), dpkg doesn't know about the dynamically generated files anyway. > 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. How about having a munin-cgi and a munin-static package? That way the permissions could be right in the package, and maintainer scripts could handle everything. > 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. Right. > 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. Yes, but since you don't do that all day, I think the drawback is ok. A pity would be the space wasted for two versions, but that could be solved by having two different packages so that the package leaving the system could clean up its pngs. > 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. The two-package approach would probably mean more work, but is a lot more elegant, IMO. I can try patching if you want me to. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
