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


Attachment: signature.asc
Description: Digital signature

Reply to: