Debian Developers - Web applications

Author

Web applications

Kai Hendry

2004-08-19, 7:49 am

Web applications as packages in Debian suck.

They're often a pain to install and remove. Please lets not discuss the
quality of the actual Web applications themselves! ;)

They're usually the LAMP(Linux, Apache, Mysql, PHP/Python/Perl) sort and
when it comes to setup a mysql root password needs to be asked and an
apache config include question. These questions are avoidable.

Christian Hammer's package mysql-server (>= 4.0.20-8) now features a
debian-sys-maint super user which can setup mysql users and databases.
My NMU of Wordpress is the first package to do this [1]. I hope other
packages will follow suit and improve the usability of the package. Mass
bug file?

The apache question. I've mailed already to debian-apache [2] with no
reply. Perhaps we can discuss Web Applications right here on
debian-devel? I would like to eventually see a policy of how they should
be deployed in Debian. Then the apache include question can be avoided.

My suggestion [3] would need probably another configuration dependency
of DNS authoritative server API of some sort. :/ Thoughts?

My timing is pretty bad. I should bring this up again post-release.

[1] http://svn.natalian.org/debian/word...debian/postinst
[2] http://people.debian.org/~terpstra/...3.10c9e911.html
[3] http://natalian.org/archives/2004/0...ropping-the-www

Pierre Habouzit

2004-08-19, 7:49 am

sean finney

2004-08-19, 7:49 am

hey guys,

i totally agree, and have had an inkling to bring this up for some time.
web apps are totally un-standardized in how they install themselves,
bad enough in some cases to actually do damage (to themselves, at
least).

in my eyes, the following should be dictated by a "web apps policy",
or at least "reference".

- whether/how to prompt for database usernames/passwords via debconf
(if necessary), and how not to store the root password.
- whether/how to prompt for whether to leave the database after purge
- default settings, disallowing default username/passwords for
web-accessible services.
- how to get a list of different installed web servers, and how to
select which ones to target for installation.
- whether/how to include one's configuration with apache. ideally there'd be
a conf.d style directory, though if the apache folks could settle
on a name for their config script calling that in postinst would work
too

- php ought to have a php.d directory
- whether/how to restart the web server
- fhs-compliant layout for sites, examples of how to seperate the config
from the rest of the site. what constitutes something that ought to
be in /var/cache, /var/lib, et c.
- debhelper macros for as much as possible

there's probably more.... anyway, i'd be very interested in discussing
this further, as i think it's an area that could use a lot of work
(post-sarge, of course

sean

Matthew Palmer

2004-08-19, 7:49 am

On Thu, Aug 19, 2004 at 12:58:58PM +0300, Kai Hendry wrote:
> Web applications as packages in Debian suck.

Testify, my friend! (And that's coming from a guy with two of them in
Debian).

> They're usually the LAMP(Linux, Apache, Mysql, PHP/Python/Perl) sort and
> when it comes to setup a mysql root password needs to be asked and an
> apache config include question. These questions are avoidable.
>
> Christian Hammer's package mysql-server (>= 4.0.20-8) now features a
> debian-sys-maint super user which can setup mysql users and databases.

But only if you're setting up the DB on the local machine, presumably.
Which, if you want to be proper about it, isn't necessarily a good idea.

For this, I've envisaged some sort of ODBC-alike registry of available
database engines (which is why it's not ODBC) where we have the
configuration for each DB server available to the machine, and when a
package is installed, a list of the available database servers comes up and
asks "where do you want this?". If there's only one (as there would be by
default if you've installed a local {postgresql,mysql}-server) then the
question can be skipped and everyone's happy.

> The apache question. I've mailed already to debian-apache [2] with no
> reply. Perhaps we can discuss Web Applications right here on
> debian-devel? I would like to eventually see a policy of how they should
> be deployed in Debian. Then the apache include question can be avoided.

The apache include question is, AFAICT, basically solved. Drop a symlink
in /etc/apache/conf.d and let $DEITY sort them out.

> My timing is pretty bad. I should bring this up again post-release.

Probably. But what the hell. We're talking about it now.

- Matt

Isaac Clerencia

2004-08-19, 7:49 am

Kai Hendry

2004-08-19, 7:49 am

On Thu, Aug 19, 2004 at 09:31:18PM +1000, Matthew Palmer wrote:
> But only if you're setting up the DB on the local machine, presumably.
> Which, if you want to be proper about it, isn't necessarily a good idea.

Mysql on a remote machine sounds less proper to me.

But good point.
This problem needs to be solved.

> asks "where do you want this?". If there's only one (as there would be by
> default if you've installed a local {postgresql,mysql}-server) then the
> question can be skipped and everyone's happy.

This sounds good. No questions.

> The apache include question is, AFAICT, basically solved. Drop a symlink
> in /etc/apache/conf.d and let $DEITY sort them out.

Urgh, questions. The user has to tell what apache they're using!? Are
you running apache, apache2, or apache-ssl? This sort of question must
be avoided.

I have just come across wwwconfig-common. Perhaps it just needs some
patches regarding the new powers of debian-sys-maint of mysql-server,
its importance re-instated and the "apache type" (httpd) question
scrutinised (again).

Isaac Clerencia

2004-08-19, 7:49 am

Pierre Habouzit

2004-08-19, 7:49 am

Pierre Habouzit

2004-08-19, 5:58 pm

Kai Hendry

2004-08-19, 5:58 pm

On Thu, Aug 19, 2004 at 03:48:02PM +0300, Kai Hendry wrote:
> mysql on a remote machine sounds less proper to me.

But good point.
> This problem needs to be solved.

How about a mysql virtual package for a debian package to depend on
whereby if a mysql-server at al is not installed a dialogue (questions!)
are posed to the administrator.

These questions are simply informing the system where the mysql server
is and it's debian-sys-maint super user details. This is for for
dependent packages to use with the minimum of fuss.

With ODBC in mind, I don't think we should waste time abstracting for
other DBMSs for the moment.

Kai Hendry

2004-08-19, 5:58 pm

On Thu, Aug 19, 2004 at 02:57:31PM +0200, Isaac Clerencia wrote:
> On Thursday 19 August 2004 14:48, Kai Hendry wrote:
> How can that question be avoided? You can have several of that apache's
> installed. Choose a random one? :P

It would be great if whatever was at the filesystem location:
/web/mywebapp.example.com

Just got served from http://mywebapp.example.com

Btw I found nothing in the fhs about web stuff.

Web apps should not be dependent on apache, but just httpd.

Justin Pryzby

2004-08-19, 5:58 pm

On Thu, Aug 19, 2004 at 05:02:10PM +0300, Kai Hendry wrote:
> On Thu, Aug 19, 2004 at 02:57:31PM +0200, Isaac Clerencia wrote:
>
> It would be great if whatever was at the filesystem location:
> /web/mywebapp.example.com
>
> Just got served from http://mywebapp.example.com
>
> Btw I found nothing in the fhs about web stuff.
>
> Web apps should not be dependent on apache, but just httpd.
But the FHS says that the web root is /var/www/
Justin

Pierre Habouzit

2004-08-19, 5:58 pm

sean finney

2004-08-19, 5:58 pm

hi guys,

On Thu, Aug 19, 2004 at 09:31:18PM +1000, Matthew Palmer wrote:
>
> But only if you're setting up the DB on the local machine, presumably.
> Which, if you want to be proper about it, isn't necessarily a good idea.

also, that makes the assumption that the local database server is
mysql, and not pgsql or something else...

> For this, I've envisaged some sort of ODBC-alike registry of available
> database engines (which is why it's not ODBC) where we have the
> configuration for each DB server available to the machine, and when a
> package is installed, a list of the available database servers comes up and
> asks "where do you want this?". If there's only one (as there would be by
> default if you've installed a local {postgresql,mysql}-server) then the
> question can be skipped and everyone's happy.

i think having something like a dh_installdb script for package
maintainers would be ideal. the trouble is i'm sure some of these
webapps use database-specific extensions, and someone would have to
put code into the script to figure that out. or perhaps we could have
dh_installmysql, dh_installpgsql, et c.?

also, if none are found, it could ask for the remote server, or perhaps
by default include "remote server" in the debconf prompt.

>
> The apache include question is, AFAICT, basically solved. Drop a symlink
> in /etc/apache/conf.d and let $DEITY sort them out.

i think their preferred method is to use the "modules-config" (or
whatever they've renamed it to) which is designed to work with the many
incarnations of the apache server config setup. wwwconfig-common
is a parallel method which behaves differently, but Ola is fairly
responsive in my experience and could probably be convinced to rework the
guts so that people currently using that system would be transparently
brought along, assuming we could come to some working conclusion.

>
> Probably. But what the hell. We're talking about it now.

yeah, it'd be insane to try and cram this into sarge, but there's never
a bad time to start discussing it!

On Thu, Aug 19, 2004 at 02:57:31PM +0200, Isaac Clerencia wrote:
> On Thursday 19 August 2004 14:48, Kai Hendry wrote:
> How can that question be avoided? You can have several of that apache's
> installed. Choose a random one? :P

if there are multiple httpd providing packages installed, i'd prompt
the user. if there's only one, i think it'd be safe to default to
using it.

On Thu, Aug 19, 2004 at 05:02:10PM +0300, Kai Hendry wrote:
> Btw I found nothing in the fhs about web stuff.
>
> Web apps should not be dependent on apache, but just httpd.

well, there's the /srv directory, but it doesn't go into a lot of
specifics.

On Thu, Aug 19, 2004 at 03:14:30PM +0200, Pierre Habouzit wrote:
> I guess there are plenty other questions, sean listed quite a lot of them
> (but not all of them I believe). maybe we should just make a good list of
> them, sort them between db engines questions, web apps questions, http
> server questions, etc ... and then write a policy for each sort of
> problem, should we ?

that sounds like a great plan. we should also try and solicit more
input from the maintainers of these various packages (web servers,
database engines, and web apps) before solidifying on anything.

On Thu, Aug 19, 2004 at 04:57:51PM +0300, Kai Hendry wrote:
> On Thu, Aug 19, 2004 at 03:48:02PM +0300, Kai Hendry wrote:
>
> How about a mysql virtual package for a debian package to depend on
> whereby if a mysql-server at al is not installed a dialogue (questions!)
> are posed to the administrator.

i think in general packages generating and installing other packages
isn't that graceful of an idea. something that would have more or
less the same result could be:

- Suggests: database-server (new virtual package?)
- in the maintainer script, if no db server is installed, prompt for
a remote server, with the addendum "if you don't have a database
server, stop now and install one". if multiple database servers
are installed, prompt for which one to use.

> These questions are simply informing the system where the mysql server
> is and it's debian-sys-maint super user details. This is for for
> dependent packages to use with the minimum of fuss.
>
> With ODBC in mind, I don't think we should waste time abstracting for
> other DBMSs for the moment.

i don't see why we shouldn't keep it in mind at least when designing
the outward interface. it'd be about the same amount of code,
underneath, and could save headaches later on.

sean

--

Zac Sprackett

2004-08-19, 5:58 pm

* Kai Hendry wrote:
> Christian Hammer's package mysql-server (>= 4.0.20-8) now features a
> debian-sys-maint super user which can setup mysql users and databases.
> My NMU of Wordpress is the first package to do this [1]. I hope other
> packages will follow suit and improve the usability of the package. Mass
> bug file?

How does this deal with database servers on a different machine than
the webserver? Should users with this common configuration be left on
their own?

-z
--
zac sprackett zac at sprackett dot com
ottawa, canada http://zac.sprackett.com
gpg fingerprint: cc8a db41 4b47 abd0 c6ce befc 5fcc fdf4 4de6 f9ce

Thomas Viehmann

2004-08-19, 5:58 pm

Pierre Habouzit wrote:
[a neat collection]
> (2) WEB SERVERS RELATED
[...]
> * whether/how to include one's configuration with apache. ideally
> there'd be a conf.d style directory, though if the apache folks could
> settle on a name for their config script calling that in postinst would
> work too

Yes, please! Calling one script with only the config snippet as
parameter and not having to change stuff every time a new webserver gets
packaged...

Cheers

T.
--
Thomas Viehmann, <http://thomas.viehmann.net/>

Pierre Habouzit

2004-08-19, 5:58 pm

Thomas Viehmann

2004-08-19, 5:58 pm

Pierre Habouzit wrote:
> * most of web apps I know are not compatible with all dbms existing on
> earth, but only for mysql or pgsql, sometimes both. So we have to be more
> granular
Well, let the user choose default and if you're package is not up to it,
let your package handle it.

> * dbms engines are splitted into server and cli client package. having
> the server installed is great, but the user may want to use a remote
> instead, and in order to use a remote, you have to have the cli client
> installed (btw the server depends on the cli client so no problem for
> local server)...
Hmm? Is this for mysql or for all databases?

> moreover I know (myself for example) a lot of pple that hosts some db on
> one host, and the second on another, ... and I don't want a packaging
> script make that choice for me. That's why I find the resource index
> thing quite sexy : it offers you by default things that you have, and
> don't do silent installation without any consentement that you have to
> dpkg-reconfigure afterwards.
I think that letting the user choose *the* database (as in host and
software) and *the* webserver where all webapps (that are capable of
doing so) install themselves is best. Detailed tweaking of the
configuration is not the domain of the packaging. That's why we consider
the user's config files sacred.

> please remember that web apps configuration HAS TO BE flexible enough. I
> know that asking too many questions to the user is not good. But asking
> him to few and doing things he doesn't want is painfull, and I assume we
> certainly don't want to do this.
No. Packaging should create a REASONABLE DEFAULT with as little input as
possible (see all the debconf abuse threads). Let's just give people the
coice of MySQL/PostGreSQL/None, local and remote if you wish, and
webapps foo and bar make themselves comfortable there. If you want fancy
stuff, you know how to start $EDITOR.

Kind regards

Thomas
--
Thomas Viehmann, <http://thomas.viehmann.net/>

Peter Palfrader

2004-08-20, 2:52 am

On Thu, 19 Aug 2004, Kai Hendry wrote:

> Web applications as packages in Debian suck.

Yes, and they suck even more if they are setup in such a way that you
can only run one instance of it. I often find myself installing a
package and then want the service configured differently for different
vhosts, or just have two instances of it.

For instance installing a wiki should make it possible to have
wiki1.example.com, wiki2.example.com which have almost nothing in
common. If the package hardcodes paths into /var/foo this is quite
difficult to make.

One piece of software that does it very well is viewcvs

--
Peter

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Palmer

2004-08-20, 2:52 am

On Thu, Aug 19, 2004 at 03:48:02PM +0300, Kai Hendry wrote:
> On Thu, Aug 19, 2004 at 09:31:18PM +1000, Matthew Palmer wrote:
>
> Urgh, questions. The user has to tell what apache they're using!? Are
> you running apache, apache2, or apache-ssl? This sort of question must
> be avoided.

Aah. I've given up trying to support every variant of apache out there,
it's just not worth the hassle. If the Apache people come up with something
to manage all their variant web servers, wonderful.

- Matt

Matthew Palmer

2004-08-20, 2:52 am

On Thu, Aug 19, 2004 at 05:02:10PM +0300, Kai Hendry wrote:
> On Thu, Aug 19, 2004 at 02:57:31PM +0200, Isaac Clerencia wrote:
>
> It would be great if whatever was at the filesystem location:
> /web/mywebapp.example.com

And the first package that goes over whatever I've got installed at
/web/mywebapp.example.com, unless there's FHS approval for it, gets a HEOE.

> Just got served from http://mywebapp.example.com

But I want my shiny new webapp to be at example.com/mywebapp -- no, wait,
make that vhost12.com/preproduction/mywebapp.

> Btw I found nothing in the fhs about web stuff.

You need to look harder. /srv is The Way Of The Future, apparently.

> Web apps should not be dependent on apache, but just httpd.

Riiiight. Is there any requirement for a package providing httpd to even
*have* CGI capabilities? Once you give a complete API for managing the
configuration of every httpd-providing package in the archive, let me know.

- Matt

Matthew Palmer

2004-08-20, 2:52 am

On Thu, Aug 19, 2004 at 04:57:51PM +0300, Kai Hendry wrote:
> On Thu, Aug 19, 2004 at 03:48:02PM +0300, Kai Hendry wrote:
>
> How about a mysql virtual package for a debian package to depend on
> whereby if a mysql-server at al is not installed a dialogue (questions!)
> are posed to the administrator.

That's a pretty damn cool idea. You'd probably want the ability for the
admin to bomb out on it, too -- perhaps he's got his mysql server locked
down so that remote users can't create accounts or databases (that's a
clever admin).

> With ODBC in mind, I don't think we should waste time abstracting for
> other DBMSs for the moment.

I don't think it's worth it at all. I'd say the majority of webapps / other
database-liking things don't work with multiple DBMS' anyway.

- Matt

Matthew Palmer

2004-08-20, 2:52 am

On Fri, Aug 20, 2004 at 07:25:36AM +0200, Peter Palfrader wrote:
> On Thu, 19 Aug 2004, Kai Hendry wrote:
>
>
> Yes, and they suck even more if they are setup in such a way that you
> can only run one instance of it. I often find myself installing a

s/setup/written/ typically. I've noticed that webapp authors typically
don't have much of a grasp of (a) packaging concepts and (b) why you'd want
to run multiple instances of something from one copy of the code. There's
also the problem that, for webapps, it can be difficult to work out how to
support multiple different configurations from a single copy of the code
securely. Certainly you can't go with trusting anything the client gives
you, but deciding in a general sense when to use which config can be tough.

> For instance installing a wiki should make it possible to have
> wiki1.example.com, wiki2.example.com which have almost nothing in
> common. If the package hardcodes paths into /var/foo this is quite
> difficult to make.

PHPWiki makes it relatively simple if you follow the instructions in
README.Debian. IRM is a royal PITA for this (and basically anything else
installation-related, too, but it's neat and simple, and I know how to use
it and hack it). I can't speak of too many other webapps -- oh, Diogenes is
getting there, but it's got some ways to go, and MySource is pretty good at
it, but it's grown a lot of complexity in the code to be able to supply it.

- Matt

Kai Hendry

2004-08-20, 2:52 am

On Fri, Aug 20, 2004 at 04:48:35PM +1000, Matthew Palmer wrote:
> And the first package that goes over whatever I've got installed at
> /web/mywebapp.example.com, unless there's FHS approval for it, gets a HEOE.

What does HEOE mean? I tried looking it up. Acronyms slow down readers
and I don't think we desperately need to save space. There is enough
acronyms as it is. IMO. ;)

> But I want my shiny new webapp to be at example.com/mywebapp -- no, wait,
> make that vhost12.com/preproduction/mywebapp.

Then use for example on the file system:
/web/example.com/mywebapp
/web/vhost12.com/preproduction/mywebapp
What's the problem?

> You need to look harder. /srv is The Way Of The Future, apparently.

Ok future. I read pg15 of http://www.pathname.com/fhs/pub/fhs-2.3.pdf
and it doesn't really help all that much. So we could put "web" in
/srv/web. Then we're left with the "no consensus" bit. Uh oh...

This demands some serious thinking. I'll mail W3-TAG for an opinion.

> Riiiight. Is there any requirement for a package providing httpd to even
> *have* CGI capabilities? Once you give a complete API for managing the
> configuration of every httpd-providing package in the archive, let me know.

Can't we assume web apps use CGI?

So what's the point of the virtual package httpd?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Palmer

2004-08-20, 7:50 am

On Thu, Aug 19, 2004 at 11:25:07AM -0400, sean finney wrote:
> well, there's the /srv directory, but it doesn't go into a lot of
> specifics.

It goes into enough specifics that we know it's not going to be useful for
us. "This setup will differ from host to host. Therefore, no program should
rely on a specific subdirectory structure of /srv existing or data
necessarily being stored in /srv." Oh, and "Distributions must take care
not to remove locally placed files in these directories without
administrator permission." which basically means that we can't use dpkg to
put anything in there, because dpkg will blot an existing file. Everything
in there would have to be conffiles or protectively managed. Blergh.

- Matt

sean finney

2004-08-20, 7:50 am

On Thu, Aug 19, 2004 at 10:06:30PM +0200, Hilko Bengen wrote:
>
> What do you mean by that?

the same as apache's conf.d directory. this is in fact already
supported by upstream (a ./configure option), i really don't see
why we haven't already started supporting it and i filed a bug
some time ago....

>
> wwwconfig-common provides a way to do this. Perhaps it needs some more
> documentation.

as some other folks brought up, wwwconfig-common is a hack that
arose from necessity because there wasn't anything else out
there to do it. ola himself is open to finding a better way to
do things.

sean

--

sean finney

2004-08-22, 6:11 pm

hi pierre,

i'm going to take the step of cc'ing folks who might not be following
this thread but would probably be interested. namely, the debian
maintainers for any "httpd" package[1], php, mysql,
and postgresql.

anyway, i think it's a good idea to distinguish the different areas
that we're trying to address like you have. now, to add more to this
growing document...

On Thu, Aug 19, 2004 at 03:41:34PM +0200, Pierre Habouzit wrote:
> my english was horrible, wasn't it ?
>
> well, I'll try to make a list of what should be unified (I'll use a lot of
> Sean's list, but not only)
>
> (1) DATABASE RELATED
>
> * whether/how to prompt for database usernames/passwords via debconf
> (if necessary), and how not to store the root password.

we could make the package databasename/username/password prompt a low
priority question, and if the user skips those questions, they could be
created automatically with a format something like
$package/debian-$package/$randompw.

> * having a list of available ressource (local or distant)

it wouldn't be too hard to do something like this. get a list
of the installed db servers, previously entered remote servers
from the debconf cache, and finally provide "add a new remote server"

> (2) WEB SERVERS RELATED
>
> * how to get a list of different installed web servers, and how to
> select which ones to target for installation.

again, i think a low priority debconf question would be appropriate.
the question on my mind is, should it default to (when lowest prompt priority
> low) not activating it for any sites, an arbitrary site, or activating
it for all sites?

> * whether/how to include one's configuration with apache. ideally
> there'd be a conf.d style directory, though if the apache folks could
> settle on a name for their config script calling that in postinst would
> work too

> * whether/how to restart the web server

and what the default action should be...

> (3) WEB APPS ADMIN RELATED
>
> * fhs-compliant layout for sites, examples of how to seperate the config
> from the rest of the site. what constitutes something that ought to be
> in /var/cache, /var/lib, et c.

i don't think we'd have to go too much into this, since we already have
the fhs to point to, but a few reminders to package maintainers wouldn't
hurt. for example, i upgraded a certain mail-graphing package which
stored some databases in /var/cache, and upon upgrading the package i
lost 3 months of unrecoverable accumulated data.

> * find solution for themeable sites (we don't want the admin to create
> custom files into /usr/share or to patch sites by hand !!!)

this really dips into the software design of the packages themselves,
unfortunately. no reason not to include guidelines though. for example,
i really like the way request-tracker does this[2], but other packages
provide different ways that i think are equally acceptable (like
providing the header/footers as config files, "theme" directories, et c).

> (4) WEB APPS PACKAGING RELATED (aka MISC ;p)
>
> * whether/how to prompt for whether to leave the database after purge
> (or uploaded files, or any local ressource generated by the app)

again and what the default action should be. i think we should get a
general clarification on what policy really says we should do, especially
given all the hoo-hah lately about logfiles being removed on purge.
also, what if the database is remote? tricky...

> * default settings, disallowing default username/passwords for
> web-accessible services.
> * have the possibility to install as a subdirectory of or as a pure vhost

there's no real way to have a clean and automagic vhost install, because
external changes in dns are usually involved. i think what would be
the closest thing we could do would be to provide a sample configuration.

> (5) WEB SCRIPTING LANGAGES RELATED
>
> * php ought to have a php.d directory
> * php PEAR packaging should have a policy

this has been brought up a few times in the past, and it was the
general consensus that there *should* be (similar to how debian
gracefully co-exists with CPAN), but i don't know that anything
further has been done.

sean

[1] grep-available -F Provides -s Maintainer httpd | sed -e 's/[^:]*://' | \
sort | uniq
[2] there's a mirrored directory structure in /usr/local, and if a
corresponding file exists there it is given preference to the
one in /usr/share.

--

Matthew Palmer

2004-08-22, 6:11 pm

On Fri, Aug 20, 2004 at 10:54:17AM +0300, Kai Hendry wrote:
> On Fri, Aug 20, 2004 at 04:48:35PM +1000, Matthew Palmer wrote:
>
> What does HEOE mean? I tried looking it up. Acronyms slow down readers
> and I don't think we desperately need to save space. There is enough
> acronyms as it is. IMO. ;)

Hot Enema Of Enlightenment. One of the many tools in the good BOFH toolkit.
I keep mine next to the Wire Brush of Knowledge (which is best applied to
the Foreskin of Ignorance).

>
> Then use for example on the file system:
> /web/example.com/mywebapp
> /web/vhost12.com/preproduction/mywebapp
> What's the problem?

The fact that there then has to be (at least) two places to install the
package's files. Remember we're talking about placement of files in the
filesystem to make them visible in webspace. Basically I'm railing against
webservers which don't have an alias method -- if I want my files to appear
somewhere else in such a system, I have to move them. That makes it nigh-on
impossible to get a decent default config.

I would certainly not recommend a subdomain default policy, because that
requires DNS cooperation.

>
> Can't we assume web apps use CGI?

Yes, but we can't assume that httpd provides it.

> So what's the point of the virtual package httpd?

To speak the HTTP protocol -- hence the name 'httpd' for HTTP Daemon. CGI
is only ephemerally related to HTTP in the sense that HTTP is the usual way
that CGI scripts end up being executed.

- Matt

Francesco P. Lovergine

2004-08-22, 6:11 pm

On Thu, Aug 19, 2004 at 03:41:34PM +0200, Pierre Habouzit wrote:
> my english was horrible, wasn't it ?
>
> well, I'll try to make a list of what should be unified (I'll use a lot of
> Sean's list, but not only)
>

(6) SECURITY ASPECTS
--------------------

A lots of applications (mainly php ones) out there have very bad archs,
they mix together site-related code and core code in the same tree
and often in the same files (sigh!). They require manual editing
of files to prevents local information loss during upgrades...
I thought to use ucf for that, but it's really a ugly solution.
Security upgrades in this conditions are painful. This is exactly the
reason I did not yet packaged applications like labe or xoops. Or
why applications like phpnuke suck.
We should define a minimal policy to which applications should be
compliant to be packaged in Debian. Having a nice multi-site packaged
app which can be a problem for sec-upgrading is not a great idea...

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Peter Eisentraut

2004-08-22, 6:11 pm

Am Donnerstag, 19. August 2004 15:41 schrieb Pierre Habouzit:
> * php ought to have a php.d directory

You can put php configuration into Apache configuration files, so I think this
is a low-priority issue. In fact, as a user I would probably prefer to have
both in one place.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ola Lundqvist

2004-08-22, 6:11 pm

I wrote a webapp policy proposal a few years ago.

You can take a look at it here:

http://www.opal.dhs.org/involved/de...pache/index.oml

It is just a start and I have probably changed my mind since then.

Regards,

// Ola

On Thu, Aug 19, 2004 at 07:30:07AM -0400, sean finney wrote:
> hey guys,
>
> i totally agree, and have had an inkling to bring this up for some time.
> web apps are totally un-standardized in how they install themselves,
> bad enough in some cases to actually do damage (to themselves, at
> least).
>
> in my eyes, the following should be dictated by a "web apps policy",
> or at least "reference".
>
> - whether/how to prompt for database usernames/passwords via debconf
> (if necessary), and how not to store the root password.
> - whether/how to prompt for whether to leave the database after purge
> - default settings, disallowing default username/passwords for
> web-accessible services.
> - how to get a list of different installed web servers, and how to
> select which ones to target for installation.
> - whether/how to include one's configuration with apache. ideally there'd be
> a conf.d style directory, though if the apache folks could settle
> on a name for their config script calling that in postinst would work
> too

> - php ought to have a php.d directory
> - whether/how to restart the web server
> - fhs-compliant layout for sites, examples of how to seperate the config
> from the rest of the site. what constitutes something that ought to
> be in /var/cache, /var/lib, et c.
> - debhelper macros for as much as possible
>
>
> there's probably more.... anyway, i'd be very interested in discussing
> this further, as i think it's an area that could use a lot of work
> (post-sarge, of course

>
>
> sean

--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Francesco P. Lovergine

2004-08-22, 6:11 pm

On Fri, Aug 20, 2004 at 04:45:14PM +1000, Matthew Palmer wrote:
> On Thu, Aug 19, 2004 at 03:48:02PM +0300, Kai Hendry wrote:
>
> Aah. I've given up trying to support every variant of apache out there,
> it's just not worth the hassle. If the Apache people come up with something
> to manage all their variant web servers, wonderful.
>

Well basically admin can install all of them and use just one or all (setting
ports for instance). Asking admin is mandatory, I think. And sure, having
a single script to configure all variants could be nice.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Pierre Habouzit

2004-08-22, 6:11 pm

sean finney

2004-08-22, 8:48 pm

hey ola,

On Fri, Aug 20, 2004 at 11:53:43PM +0200, Ola Lundqvist wrote:
> I wrote a webapp policy proposal a few years ago.
>
> You can take a look at it here:
>
> http://www.opal.dhs.org/involved/de...pache/index.oml

cool, nice to know this really isn't the first time folks have been
thinking of this

> It is just a start and I have probably changed my mind since then.

i've taken much of what was in that document, along with what's been
discussed in this thread, and formed a (very) rough outline on my
p.d.o site:

http://people.debian.org/~seanius/p...app-outline.txt

in its current state, it doesn't say a lot about what the policies
should actually *be*, but does state the specific topics that they
ought to eventually clarify.

input of any sort is welcome.

sean

--

Hilko Bengen

2004-08-22, 8:48 pm

Peter Eisentraut <peter_e@gmx.net> writes:

> Am Donnerstag, 19. August 2004 15:41 schrieb Pierre Habouzit:
>
> You can put php configuration into Apache configuration files, so I
> think this is a low-priority issue.

Only in the case where mod_php is used.

> In fact, as a user I would probably prefer to have both in one
> place.

IMO, it's most important to be flexible in what different kinds of
setups are supported. Normally, telling php4-cgi to use a different
php.ini is a major pain, so a php.d/ directory is a Good Idea.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hilko Bengen

2004-08-22, 8:48 pm

Matthew Palmer <mpalmer@debian.org> writes:

>
> I don't think it's worth it at all. I'd say the majority of webapps
> / other database-liking things don't work with multiple DBMS'
> anyway.

Since you're putting effort into abstracting locel / remote databases
already, giving users the opportunity to work with other systems than
just mysql isn't that much extra work.

I am maintaining a package of drupal, a CMS written in php that offers
support for mysql and PostgreSQL (it used to support MSSQL, too) and
it wouldn't help my package if the web application policy strictly
depended on LAMP.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hilko Bengen

2004-08-22, 8:48 pm

"Francesco P. Lovergine" <frankie@debian.org> writes:

>
> Well basically admin can install all of them and use just one or all
> (setting ports for instance). Asking admin is mandatory, I think.
> And sure, having a single script to configure all variants could be
> nice.

With wwwconfig-common and the /etc/$APACHE/conf.d/ directory into
which you can just drop a link to your /etc/$PACKAGE/apache.conf
snippet, this is trivial. The only thing we need here is documentation
about how it should be done.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Palmer

2004-08-23, 2:51 am

On Mon, Aug 23, 2004 at 02:44:40AM +0200, Hilko Bengen wrote:
> Matthew Palmer <mpalmer@debian.org> writes:
>
> Since you're putting effort into abstracting locel / remote databases
> already, giving users the opportunity to work with other systems than
> just mysql isn't that much extra work.
>
> I am maintaining a package of drupal, a CMS written in php that offers
> support for mysql and PostgreSQL (it used to support MSSQL, too) and
> it wouldn't help my package if the web application policy strictly
> depended on LAMP.

Then you can code your package to use either of a PgSQL or a mysql database.
But the abstraction system still needs to know what sort of database it is,
because there are plenty of webapps that will only work with one, and
presenting a list of PgSQL databases to a webapp that will only work with a
MySQL DB is unpleasant, to say the least.

- Matt

Pierre Habouzit

2004-08-23, 2:51 am

Pierre Habouzit

2004-08-23, 2:51 am

Hilko Bengen

2004-08-23, 8:02 am

Matthew Palmer <mpalmer@debian.org> writes:

>
> Then you can code your package to use either of a PgSQL or a MySQL
> database.

I have already gone through great pains to provide just that
functionality. My point is that an abstraction system would not help
at all in my case: A system that is deliberately limited to assume a
specific database engine would not be much of an improvement over the
way we currently do things.

> But the abstraction system still needs to know what sort of database
> it is, because there are plenty of webapps that will only work with
> one, and presenting a list of PgSQL databases to a webapp that will
> only work with a mysql DB is unpleasant, to say the least.

Then the package's maintainer script should tell the system what
database engines it can talk to.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marcela Tiznado

2004-08-24, 3:19 am

Hi!

Ive been following this thread for a few days, Im packaging a web
application and I got many of this questions before, Ive looked for
answers at the Debian Policy without luck.

I think its a good idea to start getting all the ideas together, thats
why Ive opened a wiki at http://wiki.debian.net/index.cgi?webapppolicy
and Im copying the problems and the posible solutions.

Then we can find a reasonable solution to each problem, and finally get
a web applications policy proposal.

Im just starting moving the ideas to the wiki, but Ill have it finished
soon..

Regards,
- ASCIIGirl

> that sounds like a great plan. we should also try and solicit more
> input from the maintainers of these various packages (web servers,
> database engines, and web apps) before solidifying on anything.