/var/www is depracated, which directory to use?

[Holger Levsen-2]

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#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, no package should remove files there, but placing files there
should be fine. What's more important, I don't see which location is better
suited.

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?


regards,
        Holger

[Russ Allbery-2]

Holger Levsen <holger@...> 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/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, no package should remove files there, but placing files there
> should be fine. What's more important, I don't see which location is better
> suited.

My recommendation would be for it to install its static files in
/usr/share/munin, put its generated graphs in /var/lib/munin, and provide
example configuration for common web servers such as Apache that explain
how to serve out the appropriate files.

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 web server has a virtual host configuration and anything
that packages try to do to control what my web server serves out is broken
and undesireable.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[sean finney]

hi holger, russ,

On Sun, Sep 27, 2009 at 12:36:43AM -0700, Russ Allbery wrote:
> Holger Levsen <holger@...> 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.

take a look at http://webapps-common.alioth.debian.org/draft/html/ , which
covers most of the stuff you're asking about.

> My recommendation would be for it to install its static files in
> /usr/share/munin, put its generated graphs in /var/lib/munin, and provide
> example configuration for common web servers such as Apache that explain
> how to serve out the appropriate files.

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.

> 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 web server has a virtual host configuration and anything
> that packages try to do to control what my web server serves out is broken
> and undesireable.

i'd have to disagree there.  i think anything that might serve up content
while unconfigured is a horrible idea (one more reason to avoid /var/www
and /usr/lib/cgi-bin), but if someone installs an application that can
behave sanely out of the box, i don't see why one shouldn't go out of
their way to do so.


        sean
--

[Holger Levsen-2]

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.
> take a look at http://webapps-common.alioth.debian.org/draft/html/ , which
> covers most of the stuff you're asking about.

I've skimmed it and neither 3.1 nor 5.1.1 covers what I'm interested at. Where
to put static files is easy... but not my main question :)

> 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.

> > 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 web server has a virtual host configuration and anything
> > that packages try to do to control what my web server serves out is
> > broken and undesireable.
> i'd have to disagree there.  i think anything that might serve up content
> while unconfigured is a horrible idea

I think having munin working out-of-the-box is a very neat feature.

> (one more reason to avoid /var/www
> and /usr/lib/cgi-bin), but if someone installs an application that can
> behave sanely out of the box, i don't see why one shouldn't go out of
> their way to do so.

munin can. I just dont know where to go ;-)


regards,
        Holger

[Russ Allbery-2]

Holger Levsen <holger@...> 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 the package and put it there,
and you put the dynamically generated data in /var/lib/munin, following
the FHS.

You don't need to put all the web files in the same place.  There's no
correlation between where files are located on disk and what URLs they're
exposed as.

> 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, so that those
who want to do things like this can add the necessary URL mappings to the
default site and those of us who are doing anything more complex and who
are therefore disabling the default site anyway don't have random packages
suddenly taking over portions of our URL space.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tollef Fog Heen]

]] 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, no package should remove files there, but placing files there
| should be fine. What's more important, I don't see which location is better
| suited.

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).

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stig Sandbeck Mathisen]

Holger Levsen <holger@...> 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 in
documentation or examples.

The package should generate html and graphs somewhere in /var/lib/munin,
possibly /var/lib/munin/html, and provide configuration examples for the
most common web servers.

A possible conflict:

Munin uses /var/lib/munin as the root of its dbdir, and if someone makes
a "html" domain for web servers, confusion may occur, as that directory
will store both the RRD files for that domain, as well as the generated
HTML.

Moving old data:

There should be no need to move old data.  munin-graph should re-create
missing graphs on the first run.  munin-html updates all web pages every
run.

We'll add a notice to NEWS.Debian:

,----[ NEWS.Debian ]
| The munin web root default location has moved from /var/www/munin to
| /var/lib/munin/html.  To do this manually, you can:
|
| * Update "htmldir" in /etc/munin/munin.conf to point to
|   /var/lib/munin/html.
|
| * Add configuration to your web server, see fragments in
|   /usr/share/doc/munin/examples for your web server
|
| * Remove /var/www/munin when convenient.
`----

Configuration examples for common web servers:

The following configuration fragments could be placed in
/usr/share/doc/munin/examples/

This is for apache httpd.  Add to /etc/apache2/conf.d/ to cover all
virtual hosts, or include in a virtual host:

,----[ /etc/apache2/conf.d/munin.conf ]
| Alias /munin /var/lib/munin/html
| <Directory /var/lib/munin/html>
|         Order allow,deny
|         Allow from localhost 127.0.0.0/8 ::1
|         Options None
| </Directory>
`----

For nginx, you will have to add the following to an existing
virtualhost.  

nginx in sid has ipv6 support, and this was enabled in the upload
yesterday, I guess an extra "allow ::1;" (or "allow [::1];") would do
the trick.

,----[ /etc/nginx/sites-enabled/default ]
| location /munin {
|         alias /var/lib/munin/html;
|         allow 127.0.0.0/8;
|         deny all;
| }
`----

For lighttpd, we need something like the following.  Note that this acl
example may not work with IPv6 enabled, since lighttpd does not do
subnet matching on IPv6 (http://redmine.lighttpd.net/issues/385)

,----[ /etc/lighttpd/conf-enabled/munin.conf ]
| alias.url += ( "/munin" => "/var/lib/munin/html" )
|
| $HTTP["url"] =~ "^/munin" {
|   $HTTP["remoteip"] != "127.0.0.0/8" {
|     url.access-deny = ( "" )
|   }
| }
|
`----

--
Stig Sandbeck Mathisen

[Holger Levsen-2]

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#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...


regards,
        Holger

[Gabor Gombas]

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 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?

IMHO the only safe way to populate /srv is inside the Debian Installer
(and even then there can be issues when the user selects to mount a
pre-existing file system over /srv).

Gabor

--
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tollef Fog Heen]

]] 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?
|
| http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1192

That's a footnote, and in most standards, footnotes are not
normative.

If they are, I think we have a few RC bugs to file for stuff living in
/sbin and /usr/sbin which should go in /bin or /usr/bin as appropriate.
(See http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1058).

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve McIntyre]

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 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...

--
Steve McIntyre, Cambridge, UK.                                steve@...
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Steve McIntyre <steve@...> 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 our users...

I don't think /srv is the answer to any question about "where do Debian
packages put data in their default configuration."  /srv is really
intended to be a place where the local system administrator organizes
their service data, which means we need to let them choose to organize it
however they wish.

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 sort of provides a way to do that, but it isn't very good.
Other web servers in Debian so far as I know don't at all.  And there
isn't a common interface supported by all of them.

I think we need to put together a standard definition of how a Debian
package can specify "please serve out this data and this CGI script at
these URLs unless the sysadmin has said to leave the web configuration
alone," using a standard API implemented by all web servers in Debian.  I
suspect that will get everyone what they want.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Russ Allbery wrote:

> Steve McIntyre <steve@...> 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 our users...
>
> I don't think /srv is the answer to any question about "where do Debian
> packages put data in their default configuration."  /srv is really
> intended to be a place where the local system administrator organizes
> their service data, which means we need to let them choose to organize it
> however they wish.
>
> 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 sort of provides a way to do that, but it isn't very good.
> Other web servers in Debian so far as I know don't at all.  And there
> isn't a common interface supported by all of them.
>
> I think we need to put together a standard definition of how a Debian
> package can specify "please serve out this data and this CGI script at
> these URLs unless the sysadmin has said to leave the web configuration
> alone," using a standard API implemented by all web servers in Debian.  I
> suspect that will get everyone what they want.
>

I agree on this one.

I personally prefer to keep files served by a webserver in /var/www/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

"mlists@..." <mlists@...> 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 static files in
/usr/share/<package> and their data files in /var/lib/<package> just like
every other package does, and then use the web configuration to serve out
the correct parts of the file system.  That way there's never any
accidental, unexpected results from dropping files into an area that a
sysadmin may think they can use for some other purpose.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[sean finney]

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 sort of provides a way to do that, but it isn't very good.
> Other web servers in Debian so far as I know don't at all.  And there
> isn't a common interface supported by all of them.

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.


        sean

[1] http://webapps-common.alioth.debian.org/draft-wac/html/
--

[Russ Allbery-2]

sean finney <seanius@...> 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 over
>> the URL space.  Apache sort of provides a way to do that, but it isn't
>> very good.  Other web servers in Debian so far as I know don't at all.
>> And there isn't a common interface supported by all of them.

> 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.

Yeah, that looks like the right direction to go.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tollef Fog Heen]

]] 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 don't think this is progress for most of our users...

I'm not opposed to making stuff work out of the box, but I think using
/srv as a default location is wrong, since its structure is explicitly
undefined.  I haven't looked at webapps-common, and I also believe this
problem is a bit larger than just webapps, though web applications are
much more common than say, services that lie on top of XMPP.  Hopefully
there are good thoughts there that can be generalised a bit further so
we can have a «app/vhost service» policy.

(I'd be quite happy for us to get rid of ENABLED=[01] in /etc/default/*
for instance.)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stig Sandbeck Mathisen]

sean finney <seanius@...> 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 Sandbeck Mathisen

[Frank Lin PIAT]

On Sun, 2009-09-27 at 01:45 -0700, Russ Allbery wrote:

> Holger Levsen <holger@...> 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, so that those
> who want to do things like this can add the necessary URL mappings to the
> default site and those of us who are doing anything more complex and who
> are therefore disabling the default site anyway don't have random packages
> suddenly taking over portions of our URL space.

The URL namespace isn't "suddenly" taken over:
1. The admin deliberately install the package.
2. The admin choose to use the default settings of the package.
   (editing the conf files is usually trivial)

Personally, on my modest production websites, I always disable the
default website (a2dissite 000-default), then disable the "Include"
lines in /etc/apache2/apache2.conf... So I can cherry pick (Include or
copy) the configuration files snippets in my vhosts.
On some other machines, I am often very happy to just "apt-get install"
and simply _read_ the fine manual.

I would be really annoyed I had to manually configure and enable
ssh-server on every machine (generating the host key, configure sshd,
enabling sshd in /etc/default/ssh, then start the service).
Same applies to most webapps.

Regards


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[sean finney]

hi stig,

(sorry for the late reply)

On Wed, Sep 30, 2009 at 09:23:17AM +0200, Stig Sandbeck Mathisen wrote:
> sean finney <seanius@...> 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?

if you (or anyone else) are interested in helping webapps-common, then
my first suggestion is to join up on debian-webapps@....  
if there's enough interest we can hammer out a roadmap for what needs to
be done to get the package into a release-quality state.


        sean