[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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,


Attachment: signature.asc
Description: Digital signature

Reply to: