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