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
Attachment:
signature.asc
Description: Digital signature