On Tue, Nov 10, 2009 at 09:49:10AM +0800, Paul Wise wrote: > On Tue, Nov 10, 2009 at 6:50 AM, sean finney <sean...@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
signature.asc
Description: Digital signature