Hi,
> On Wed, Nov 4, 2009 at 5:12 PM, Holger Levsen wrote:
>> Hi Tom,
>>
>> On Montag, 2. November 2009, Tom Feiner wrote:
>>> Is /var/cache really such a bad option? I mean, the entire web content
>>> is re-generated from templates & graphs are re-generated from the rrd
>>> databases every 5 min
Hi,
On Mittwoch, 4. November 2009, Stephen Gran wrote:
> _contents_ of /var/cache/munin, and I don't recall the FHS saying that
> it expected applications to cope gracefully with the directory structure
> being yanked out from under them by addled admins.
Right. (It only says apps have to cope gr
This one time, at band camp, Holger Levsen said:
> Hi Tom,
>
> On Montag, 2. November 2009, Tom Feiner wrote:
> > Is /var/cache really such a bad option? I mean, the entire web content
> > is re-generated from templates & graphs are re-generated from the rrd
> > databases every 5 minutes. So even
Hi Tom,
On Montag, 2. November 2009, Tom Feiner wrote:
> Is /var/cache really such a bad option? I mean, the entire web content
> is re-generated from templates & graphs are re-generated from the rrd
> databases every 5 minutes. So even if someone did delete the directory,
> it'll just be recreate
This one time, at band camp, Tom Feiner said:
> On Mon, Nov 2, 2009 at 3:48 PM, Stig Sandbeck Mathisen
> wrote:
> > Tom Feiner writes:
> >
> >> Is /var/cache really such a bad option? I mean, the entire web content
> >> is re-generated from templates & graphs are re-generated from the rrd
> >> da
hi stig,
On Mon, Nov 02, 2009 at 02:48:56PM +0100, Stig Sandbeck Mathisen wrote:
> Tom Feiner writes:
>
> > Is /var/cache really such a bad option? I mean, the entire web content
> > is re-generated from templates & graphs are re-generated from the rrd
> > databases every 5 minutes. So even if s
Tom Feiner writes:
> Sorry for the newbie question (I'm not that familiar with debconf).
> Will debconf be able to manage upgrade from current munin version?
> Changing the current 'htmldir /var/www/munin' to the new user
> specified one?
Debconf asks questions and stores them. However, with th
Neil McGovern writes:
> Have a read of
> http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html
Useful, thanks. :)
--
Stig Sandbeck Mathisen
pgph88QZYVl0o.pgp
Description: PGP signature
On Mon, Nov 2, 2009 at 3:48 PM, Stig Sandbeck Mathisen
wrote:
> Tom Feiner writes:
>
>> Is /var/cache really such a bad option? I mean, the entire web content
>> is re-generated from templates & graphs are re-generated from the rrd
>> databases every 5 minutes. So even if someone did delete the
>
On Mon, Nov 02, 2009 at 02:48:56PM +0100, Stig Sandbeck Mathisen wrote:
> Should the web configuration be enabled by default? Assume apache2, and
> add configuration to /etc/apache2/conf.d/munin.conf?
>
Have a read of
http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html
Neil
--
aut
Mike Hommey writes:
> * /usr/share/munin.
Would not work well for variable data, I think. The graphs and HTML is
updated every 5 minutes.
--
Stig Sandbeck Mathisen
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...
Tom Feiner writes:
> Is /var/cache really such a bad option? I mean, the entire web content
> is re-generated from templates & graphs are re-generated from the rrd
> databases every 5 minutes. So even if someone did delete the
> directory, it'll just be recreated up to 5 minutes later.
Apart fro
On Mon, Nov 02, 2009 at 02:27:16PM +0100, Mike Hommey wrote:
> On Mon, Nov 02, 2009 at 01:30:37PM +0100, Stig Sandbeck Mathisen wrote:
> > Manoj Srivastava writes:
> >
> > > As I mentioned on IRC, look at trac. The trick is put configuration
> > > files in /etc/munin/, and symlink it back into /v
On Mon, Nov 2, 2009 at 2:30 PM, Stig Sandbeck Mathisen
wrote:
> All munin needs is a place to write static html and png files.
>
> * /var/lib/munin is already used as top level for munin's data files.
> If we add a web root there, it may cause collisions.
>
Right.
> * /var/cache may not be the
On Mon, Nov 02, 2009 at 01:30:37PM +0100, Stig Sandbeck Mathisen wrote:
> Manoj Srivastava writes:
>
> > As I mentioned on IRC, look at trac. The trick is put configuration
> > files in /etc/munin/, and symlink it back into /var/lib/munin if munin
> > needs that.
>
> All munin needs is a place t
Manoj Srivastava writes:
> As I mentioned on IRC, look at trac. The trick is put configuration
> files in /etc/munin/, and symlink it back into /var/lib/munin if munin
> needs that.
All munin needs is a place to write static html and png files.
* /var/lib/munin is already used as top level for
On Sat, Oct 31, 2009 at 05:51:26PM +0200, Holger Levsen wrote:
> /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)
IMHO that's not different from some user wanting to
On Sat, Oct 31, 2009 at 06:46:42PM +0200, Holger Levsen wrote:
> On Samstag, 31. Oktober 2009, sean finney wrote:
> > if it's regenerable, then i'd say /var/cache/munin/something is the
> > right place, and if isn't /var/lib/munin/something. if you seperate
> > the things that the user might want
On Sat, Oct 31 2009, Holger Levsen wrote:
> 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 del
On Sat, Oct 31, 2009 at 06:46:42PM +0200, Holger Levsen wrote:
> On Samstag, 31. Oktober 2009, sean finney wrote:
> > if it's regenerable, then i'd say /var/cache/munin/something is the
> > right place, and if isn't /var/lib/munin/something. if you seperate
> > the things that the user might want
Hi sean,
On Samstag, 31. Oktober 2009, sean finney wrote:
> if it's regenerable, then i'd say /var/cache/munin/something is the
> right place, and if isn't /var/lib/munin/something. if you seperate
> the things that the user might want to configure (css, etc), where's
> the problem[1]?
that it's
hi holger,
On Sat, Oct 31, 2009 at 05:51:26PM +0200, Holger Levsen wrote:
> +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/li
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 th
sean finney wrote:
> On Mon, Oct 05, 2009 at 08:14:19AM +, Tzafrir Cohen wrote:
>> I believe most (or at least many) of those only support a single web
>> root. If you want to serve munin's static content from /usr/share/munin
>> and foo's static content from /usr/share/foo , you'll probably ju
hi,
On Mon, Oct 05, 2009 at 08:14:19AM +, Tzafrir Cohen wrote:
> I believe most (or at least many) of those only support a single web
> root. If you want to serve munin's static content from /usr/share/munin
> and foo's static content from /usr/share/foo , you'll probably just
> symlink both f
On Sun, Sep 27, 2009 at 04:15:42PM +0800, Holger Levsen wrote:
>
> On Sonntag, 27. September 2009, sean finney wrote:
> > > I personally do not believe that serving anything from a package via the
> > > web by default is a good goal. Certainly for my systems, any system
> > > that's running a we
hi stig,
(sorry for the late reply)
On Wed, Sep 30, 2009 at 09:23:17AM +0200, Stig Sandbeck Mathisen wrote:
> sean finney writes:
>
> > there is, it's called webapps-common[1]. unfortunately what *is*
> > missing is developers with time to put into maintaining it, which is
> > why it has not b
On Sun, 2009-09-27 at 01:45 -0700, Russ Allbery wrote:
> Holger Levsen writes:
>
> > I think having munin working out-of-the-box is a very neat feature.
>
> I think we need better support in the Apache package for adding particular
> aliases and similar URL configuration into the default site, s
sean finney writes:
> there is, it's called webapps-common[1]. unfortunately what *is*
> missing is developers with time to put into maintaining it, which is
> why it has not been uploaded or integrated with support for more httpd
> services.
That looks useful. What can I do to help?
--
Stig
]] Steve McIntyre
(Please respect my m-f-t, I read the list. :-)
| 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
sean finney writes:
> On Tue, Sep 29, 2009 at 04:12:58PM -0700, Russ Allbery wrote:
>> I think the real problem here is that we have some missing integration
>> glue. A lot of packages want to serve things out via the web by
>> default unless the sysadmin has indicated that they want control ove
On Tue, Sep 29, 2009 at 04:12:58PM -0700, Russ Allbery wrote:
> I think the real problem here is that we have some missing integration
> glue. A lot of packages want to serve things out via the web by default
> unless the sysadmin has indicated that they want control over the URL
> space. Apache
"mli...@stacktrace.us" writes:
> I personally prefer to keep files served by a webserver in /var/www/
Local sysadmins can of course use that path, but Debian packages aren't
allowed to according to the way most of us have read the FHS.
Debian web application packages should really put their sta
Russ Allbery wrote:
Steve McIntyre writes:
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
Steve McIntyre writes:
> 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 ou
Tollef wrote:
>
>I realise you've had good an constructive responses for webapps, so
>commenting on /srv in particular:
>
>As I read it, putting stuff there is absolutely not fine. It's even
>more off-limits than /usr/local (where you can create directories, but
>not remove them).
I'm still uncon
]] Holger Levsen
| Hi,
|
| On Montag, 28. September 2009, Tollef Fog Heen wrote:
| > I realise you've had good an constructive responses for webapps, so
| > commenting on /srv in particular:
| >
| > As I read it, putting stuff there is absolutely not fine.
|
| Where do you read this?
|
| htt
On Mon, Sep 28, 2009 at 10:19:22PM +0800, Holger Levsen wrote:
> > 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 explicitly
> says: "This is particularly important as these areas will often co
Hi,
On Montag, 28. September 2009, Tollef Fog Heen wrote:
> I realise you've had good an constructive responses for webapps, so
> 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
Holger Levsen writes:
> http://lintian.debian.org/tags/dir-or-file-in-var-www.html nor
> debian-policy is helpful to resolve this issue - so I would like to
> discuss this here and come up with a good solution.
>
> Suggestions?
No package may touch /srv, but we could perhahs recommend its usage
]] Holger Levsen
| The way I read
|
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
| /srv/munin would be the proper location for our purpose, but I know that some
| people disagree, claiming that /srv is only to be used by the local admins.
|
| As I read it
Holger Levsen writes:
>> i would recommend similar, but with the modification that you use a
>> dedicated subdirectory (i.e. /usr/share/munin/site), so that you still
>> have /usr/share/munin for other uses as well.
> Thats for read-only data only.
Right, you take the static data shipped with t
Hi Sean,
On Sonntag, 27. September 2009, sean finney wrote:
> > > currently munin ships some file(s) in /var/www/munin/ and also puts its
> > > generated graphs there. This location has been depracted and we, the
> > > munin maintainers, would like to come up with a new location for
> > > squeeze.
hi holger, russ,
On Sun, Sep 27, 2009 at 12:36:43AM -0700, Russ Allbery wrote:
> Holger Levsen writes:
>
> > currently munin ships some file(s) in /var/www/munin/ and also puts its
> > generated graphs there. This location has been depracted and we, the
> > munin maintainers, would like to come
Holger Levsen writes:
> currently munin ships some file(s) in /var/www/munin/ and also puts its
> generated graphs there. This location has been depracted and we, the
> munin maintainers, would like to come up with a new location for
> squeeze.
> The way I read
> http://www.pathname.com/fhs/pub
Hi,
currently munin ships some file(s) in /var/www/munin/ and also puts its
generated graphs there. This location has been depracted and we, the munin
maintainers, would like to come up with a new location for squeeze.
The way I read
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVI
46 matches
Mail list logo