> 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 I don't know how this is written, and what it does. but I guess we need here some support from the debian SGDB packages (e.g. that the mysql init.d script look at a place if it has some action to perform at startup). I know this won't solve the distant SGDB problem, but that would be some good solution for the local ones, that is the most common case. > 1: http://packages.debian.org/experimental/admin/dbconfig-common > 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 moreover, independently from the multiple instances problems, packages usually provide subdirectories auto-configuration, and never allow the user to let the web app live on a virtual host, or worse in a subdir of a particular vhost. IMHO, there is sth to do, maybe some srvconfig-common that would take advantage of the under-used /srv tree. I believe we can write a set of scripts that would know some vhosts and services because they follow some debian policy about internal /srv/ use, and that would enable automagic per vhost configuration, and not per server like it is the case for most of applications. Note that the 'per server' configuration is a nonsense IMHO, and is a current design problem, because there is no other option than asking what the box actually use. If we have per vhost configuration, then it's really easier, because it would be independant of the server that is run : apache(-(2|ssl|perl|...))? I know that a distro should not assume /srv exists, and that would be the user's choice to use debians mechanisms to configure his vhosts. thouth, I believe it's sensible to suggest/recommend some clever organisation, that allow some automatic treatments > 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 PHP lacks a policy in PEAR (or other non pear libs) packaging too. There is too many php libs that don't live in /usr/share/php/ and even if there is no "official" php policy about that, we should do sth about it. As a web apps writer, I often have to look at the source of the libs I use to understand more precisely what they do, and it's sometimes a pain to find those files. Moreover, if all is in /usr/share/php, then it's the only thing that has to be in the include_path, and that will also avoid some headaches to the programmers : some of the web apps I write *need* more than 4 absolute path to be in the include_path, because the libs are not well written, and need their files to be accessible from include path, and that is very dangerous IMHO. btw, I'm the maintainer of flyspray in debian, and a co-author of diogenes (especially the diogenes lib : libphp-diogenes). I plan to try to package dotclear in debian too, but I was waiting for some new features to exists (like real multi-blog). I'm the author of a small draft of a PEAR packaging policy (that is really not final and is not perfect) [1] Cheers, [1] http://www.madism.org/debian.pear.php -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Attachment:
pgp_tfmZQHXfO.pgp
Description: PGP signature