FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-06-2009, 11:34 AM
The Fungi
 
Default common, FHS-compliant, default document root for the various web servers

On Fri, Nov 06, 2009 at 01:11:47PM +0100, Harald Braumann wrote:
> /debian/ seems to be the de facto standard for Debian archives. So I
> guess it wouldn't be such a good idea to use it for something else
> (sorry, can't really come up with a better name myself).

Something short, generic and distro-neutral like /app/ would be my
personal preference if I were developing a standard for my servers.
Unfortunately, going that direction as also increases the chances of
remapping a path the admin was already using...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(fungi@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-06-2009, 11:53 PM
Manoj Srivastava
 
Default common, FHS-compliant, default document root for the various web servers

On Fri, Nov 06 2009, The Fungi wrote:

> On Fri, Nov 06, 2009 at 01:11:47PM +0100, Harald Braumann wrote:
>> /debian/ seems to be the de facto standard for Debian archives. So I
>> guess it wouldn't be such a good idea to use it for something else
>> (sorry, can't really come up with a better name myself).
>
> Something short, generic and distro-neutral like /app/ would be my
> personal preference if I were developing a standard for my servers.
> Unfortunately, going that direction as also increases the chances of
> remapping a path the admin was already using...

/vendor-apps/ ?

manoj
--
I used to be Snow White, but I drifted. Mae West
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-09-2009, 08:15 AM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
> > Something short, generic and distro-neutral like /app/ would be my
> > personal preference if I were developing a standard for my servers.
> > Unfortunately, going that direction as also increases the chances of
> > remapping a path the admin was already using...
>
> /vendor-apps/ ?

I find it ugly (de gustibus), but that's not really an argument;
moreover your suggestion perfectly embodies the proper meaning of that
URL prefix.

To try making it a bit less ugly (and hard to type due to the moving
nature of "-" as others have pointed out), I just try to mediate with
"/vendor/".

Given that such a prefix would actually be non Debian-specific, if we
settle with it I believe it would be a good idea to try pushing it
outside our borders, for instance proposing it on the
distributions@freedesktop list.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 
Old 11-09-2009, 12:56 PM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

On Mon, Nov 09, 2009 at 10:15:00AM +0100, Stefano Zacchiroli wrote:
> On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
> > > Something short, generic and distro-neutral like /app/ would be my
> > > personal preference if I were developing a standard for my servers.
> > > Unfortunately, going that direction as also increases the chances of
> > > remapping a path the admin was already using...
> >
> > /vendor-apps/ ?
>
> I find it ugly (de gustibus), but that's not really an argument;
> moreover your suggestion perfectly embodies the proper meaning of that
> URL prefix.
>
> To try making it a bit less ugly (and hard to type due to the moving
> nature of "-" as others have pointed out), I just try to mediate with
> "/vendor/".

FWIW, I'm fine with /vendor.

> Given that such a prefix would actually be non Debian-specific, if we
> settle with it I believe it would be a good idea to try pushing it
> outside our borders, for instance proposing it on the
> distributions@freedesktop list.

Just sent it to freestandards-fhs-discuss@lists.sourceforge.net. Let's
see if someone else is interested in this...

Hauke
 
Old 11-09-2009, 09:50 PM
sean finney
 
Default common, FHS-compliant, default document root for the various web servers

hi guys,

On Mon, Nov 09, 2009 at 02:56:59PM +0100, Jan Hauke Rahm wrote:
> > To try making it a bit less ugly (and hard to type due to the moving
> > nature of "-" as others have pointed out), I just try to mediate with
> > "/vendor/".
>
> FWIW, I'm fine with /vendor.

personally, beyond the aesthetically displeasing name, i'm really
skeptical that this will accomplish anything useful.

* most apps require extra config and splitting out of stuff into other
directories for fhs compliance anyway, thus requiring some level of
webserver configuration, meaning this adds no benefit (beyond 1 line
fewer in the server config).
* this encourages a "working in unconfigured state" for packages, which
seems very sketchy wrt security (similarly, to apps dropping random
publically executable scripts in /usr/lib/cgi-bin.

tbh this seems closer to the "solution looking for a problem" rather than
the other way around.

sean

--
 
Old 11-10-2009, 07:29 AM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

On Tue, Nov 10, 2009 at 09:49:10AM +0800, Paul Wise wrote:
> On Tue, Nov 10, 2009 at 6:50 AM, sean finney <seanius@debian.org> wrote:
>
> > personally, beyond the aesthetically displeasing name, i'm really
> > skeptical that this will accomplish anything useful.
> >
> > * most apps require extra config and splitting out of stuff into other
> > *directories for fhs compliance anyway, thus requiring some level of
> > *webserver configuration, meaning this adds no benefit (beyond 1 line
> > *fewer in the server config).
> > * this encourages a "working in unconfigured state" for packages, which
> > *seems very sketchy wrt security (similarly, to apps dropping random
> > *publically executable scripts in /usr/lib/cgi-bin.
> >
> > tbh this seems closer to the "solution looking for a problem" rather than
> > the other way around.
>
> I have to agree with sean here.

I don't as I was definitely not looking for a problem but you get a full
ack. So let's talk business...

> I'd instead like to see each webapp come with stuff to make a
> sysadmin's life easier:
>
> Support for multiple independent instances configured to use arbitrary
> locations for data/configuration, arbitrary vhosts and arbitrary
> sub-paths of those vhosts.

That means: as many files reusable by each instance as possible, those
in /usr/share/, and instance specific files in /var/{lib,cache}/package/
and /etc/package/. Right?

> Scripts that can be used to setup an instance, configure it and
> register it with the package and with the available and
> sysadmin-selected web servers.

And I think a webapp should configure the first instance during
postinst. Applications should be able to run after installation.

> Support for automatically upgrading the database structures (or
> similar) for each registered instance when the package is upgraded.
> This could include backups of the pre-upgrade data, disabling the
> instance during the upgrade process and other things.

dbconfig-common for multiple instances? Nice idea.

> Ways to easily relocate an instance; between directories on one server
> and between servers.

That should be possible if web applications comply with FHS.

> And my personal nitpick; PHP should be off by default so that php
> scripts in configured data locations are not executed by web servers
> by default. PHP files/dirs in webapp packages should be whitelisted
> for execution rather than each webapp needing to blacklist their
> configured data locations.

Fine with me. I'm not sure every web server supports such feature,
though.

Hauke
 
Old 11-10-2009, 07:48 AM
sean finney
 
Default common, FHS-compliant, default document root for the various web servers

hi!

On Tue, Nov 10, 2009 at 09:29:13AM +0100, Jan Hauke Rahm wrote:
> > Support for multiple independent instances configured to use arbitrary
> > locations for data/configuration, arbitrary vhosts and arbitrary
> > sub-paths of those vhosts.
>
> That means: as many files reusable by each instance as possible, those
> in /usr/share/, and instance specific files in /var/{lib,cache}/package/
> and /etc/package/. Right?

right. while the devil is in the details (wrt writeable on-disk files
etc), there's no technical reason why multiple instances can't be supported
by a single installation. the existing code in webapps-common should have
(very basic) examples of doing this even. what's missing from there is
support for creating per-instance /var/{lib,cache}/foo subdirectories,
but there's not a huge technical problem there either.

> > Scripts that can be used to setup an instance, configure it and
> > register it with the package and with the available and
> > sysadmin-selected web servers.
>
> And I think a webapp should configure the first instance during
> postinst. Applications should be able to run after installation.

yes. i'm all for sane defaults out of the box.

> > Support for automatically upgrading the database structures (or
> > similar) for each registered instance when the package is upgraded.
> > This could include backups of the pre-upgrade data, disabling the
> > instance during the upgrade process and other things.
>
> dbconfig-common for multiple instances? Nice idea.

dbconfig-common already has some under-the-hood support for multiple
instances, even it's not in the documentation because it's pretty
experimental but webapps-common was using it.

> > Ways to easily relocate an instance; between directories on one server
> > and between servers.
>
> That should be possible if web applications comply with FHS.

right. it *should* be a matter of dropping in multiple httpd config files,
which point the app at different app config files, which in turn specify
different subdirectories of the FHS-compliant locations of non-read-only
data. of course *should* doesn't necessarily imply *is*

> > And my personal nitpick; PHP should be off by default so that php
> > scripts in configured data locations are not executed by web servers
> > by default. PHP files/dirs in webapp packages should be whitelisted
> > for execution rather than each webapp needing to blacklist their
> > configured data locations.
>
> Fine with me. I'm not sure every web server supports such feature,
> though.

someone ought to file a wishlist bug against php5. at the very least there
could be a debconf prompt controlling the global status of php, and i think
there's a strong case for arguing that apps shouldn't assume that it's on
by default.


sean
--
 
Old 11-10-2009, 11:26 AM
Stefan Fritsch
 
Default common, FHS-compliant, default document root for the various web servers

On Tuesday 10 November 2009, sean finney wrote:
> someone ought to file a wishlist bug against php5. at the very
> least there could be a debconf prompt controlling the global
> status of php, and i think there's a strong case for arguing that
> apps shouldn't assume that it's on by default.

I have filed #555606 for that. Everybody interested may post their
thoughts there. I would especially like to have php disabled for
userdirs by default.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-13-2009, 08:09 AM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

Sorry for the delay in replying to this. I've just re-read all the
disagreements with the original proposal and they all seem to be related
to this main counter-argument by Sean, hence I'll reply here.

On Mon, Nov 09, 2009 at 11:50:11PM +0100, sean finney wrote:
> > FWIW, I'm fine with /vendor.
>
> personally, beyond the aesthetically displeasing name, i'm really
> skeptical that this will accomplish anything useful.
>
> * most apps require extra config and splitting out of stuff into other
> directories for fhs compliance anyway, thus requiring some level of
> webserver configuration, meaning this adds no benefit (beyond 1 line
> fewer in the server config).
> * this encourages a "working in unconfigured state" for packages, which
> seems very sketchy wrt security (similarly, to apps dropping random
> publically executable scripts in /usr/lib/cgi-bin.

I understand this problem, but I think you're shooting at the wrong
target. The advanced proposal (beside the aesthetically displeasing
name) is about standardizing a default vendor document root on disk so
that packages can install content in it, as well as defining a base URL
that maps to it.

Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static
content.

So, regarding your "working in unconfigured state" I think we should
rather just be clear that CGI should not be enabled by default, if this
is actually a concern. Personally, while I understand it, I wouldn't
like carving that in stone: maintainers should be free to decide whether
their applications have a sane default that enable apps to work out of
the box or not. I easily see both apps that can work without any conf
(e.g. CGI-based doc browsers for the local machine) and apps that would
forcibly require conf (e.g. multi-intance blog engines or other
webapps).

All in all, I don't see why adding a default root for static content
make things worse wrt your problems.

A couple of other misc remarks:

- Stating that those defaults should be enabled only for the localhost
virtual host will help a lot. For web servers with no virtual host
support we can simply state that they should not have the proposed
vendor document root enabled by default.

- We already have a de facto default vendor dir rooted at /doc/, why
should this be a special case? Implementing the advanced proposal
would enable generalizing that unfortunate ad-hoc case.

Of course, thanks to all the participants for their feedback!
Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 
Old 11-15-2009, 09:15 PM
sean finney
 
Default common, FHS-compliant, default document root for the various web servers

hi stefano,

On Fri, Nov 13, 2009 at 10:09:20AM +0100, Stefano Zacchiroli wrote:
> I understand this problem, but I think you're shooting at the wrong
> target. The advanced proposal (beside the aesthetically displeasing
> name) is about standardizing a default vendor document root on disk so
> that packages can install content in it, as well as defining a base URL
> that maps to it.
>
> Inherently, such a proposal applies to static content, not CGI
> applications. I fail to see where lay problems about unconfigured static
> content.

read-only static content unpacked from packages is certainly not an
issue wrt being "unconfigured", but i was given the impression by other
folks in this thread that the scope was not this narrow.

but at the same time, if we're only talking about static content at this
filesystem location, i wonder about the overall utility/benefit of
standardizing on a location in the first place. how many webapp packages
in debian consist of only read-only static content, which would be helped
by such a standardization?

wrt the issue about namespacing and default URL's (i guess this is
a seperate issue from fs location, really) i'm unconvinced about the
benefits outweighing the costs. has anyone considered putting up the
arguments for it in a DEP?


sean
 

Thread Tools




All times are GMT. The time now is 10:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org