Hi, On Mittwoch, 30. September 2009, Steve McIntyre wrote: > I'm still unconvinced by /srv personally - we've strived for years in > Debian to make things work as much as possible straight from initial > installation, yet now we're expected to deliberately leave services > unconfigured. I don't think this is progress for most of our users... +1 from yet. Yet I still don't know how to configure munin, so that it works out of the box (and so that the webpages it generates are served by a webserver) and conforms to FHS like some people read it. /var/lib/munin/www is wrong (FHS says: "Users must never need to modify files in /var/lib to configure a package's operation." since users might want to modify the css files) /var/cache/munin/www feels very wrong, but might work, with static files like css files coming from /etc/munin/www or such. what other options do you see? On Montag, 28. September 2009, Gabor Gombas wrote: > > http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1192 explicitly > > says: "This is particularly important as these areas will often contain > > both files initially installed by the distributor, and those added by the > > administrator." which to me very much sounds like the distributor > > (=Debian here) can place directories there... > The problem is that people already put a lot of things under /srv and > therefore it is really hard to make sure you do not overwrite anything. > What do you do e.g. if the name of the directory you want to create > already exists as a file? Simple: leave it as it is and don't provide a working configuration out of the box. I doubt that many people will have /srv/munin and if they have, they can very probably configure munin themselves. On Montag, 28. September 2009, Tollef Fog Heen wrote: > | > commenting on /srv in particular: > | > > | > As I read it, putting stuff there is absolutely not fine. > | > | Where do you read this? > | > | http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1192 > > That's a footnote, and in most standards, footnotes are not > normative. Hm, point taken, I guess. So, atm I only see one way out of this: ask other distributions how they handle this and (then) talk with the FHS people to clarify usage of /srv and what to do with webapps. regards, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.