Web applications specific issues
Hello.
To start with, we have to list the main common issues a webapp
maintainer can face.
I suggest that we discuss on this list every issue, the idea is to
gather points of view and solutions on each of them.
Don't give importance to the order I chose to write this list down, it's
pure random.
Handling param files which are editable through a web interface
-----------------------------------------------------------------
Most of the time, webapps come with a couple of configuration files
which are handled through a web admin area.
* Those files should be considered conffiles and thus be located under
/etc/$package. Note that the file must be writable by www-data.
Handling template files
-----------------------------------------------------------------
Webapps can provide a set of template files which give the global design
of the website.
How should we provide such files? This question is hard to answer[1].
In a way, some users would like to see them as conffiles in order to
keep their local changes when upgrading.
But on the other way, when upgrading major upstream releases, the
templates are very likely to change a lot, the merge would be really
hard to do by hand and can break the application.
* One solution I like is to provide a default template directory,
notifying the user in README.Debian (or in a debconf note) that he must
not touch it and provide a way to use template from an alternate point.
This solution seems to be used in some packages.
1: http://lists.debian.org/debian-mentors/2005/04/msg00393.html
Configuring the package when the database server is not running
-----------------------------------------------------------------
It has been underlined that a common design issue is present in every
webapp package that uses a database. Indeed, the postinst script tries
to play with the DB (creating a databse, creating tables or whatever).
What happens if the database is down?
Well you see the tricky thing to do...
* This is a complex issue, a decent but complex solution would be to
write a package that could run database related actions asynchronously.
We might also think at the upcoming dbconfig-common[1] package
1: http://packages.debian.org/experimental/admin/dbconfig-common
Creating/updating a database account for the web application
-----------------------------------------------------------------
Handling the database in the postinst can become quickly a pain, you
have to create the databse, grant privileges on a specified user, create
tables...)
There are many postinst for solving this issue, each of them different.
We definitely have to coordinate the way we handle databases.
* dbconfig-common really sounds to be right solution[1]. It also comes
with some policy about DB handling[2].
1:
http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbconfig-common-using.html
2:
http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbapp-policy.html
Providing a VirtualHosting facility
-----------------------------------------------------------------
On some occasions, system adminstrations need to run different versions
of a webapp package, as they are used across different virtualhosts.
It's usually quite hard to do that currently. Most packages can only
have one version installed at a time.
You will probably need to fetch the packages' source and do a lot of
modifications
* The standard approach is to install stuff from source.
* Another way to do that is to bump the package name but that seems to
be a solution that's not well liked by some DDs
Managing PHP libraries, security policy about include()
-----------------------------------------------------------------
When you provide some php scrips in your package, you are likely to find
some include() statements in some scripts. There must be a discussion
around the secrity issues about that, as it can sometimes lead to
security holes[1].
1: http://lists.debian.org/debian-security/2005/04/msg00103.html
--
Alexis Sukrieh <sukria@sukria.net>
Reply to: