hi, On Tue, May 03, 2005 at 01:38:57PM +0200, Pierre Habouzit wrote: > > * 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 i do, i wrote it :) > 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. i think the simplest solution for how the webapp policy could handle the topic of databases is to defer to the previously mentioned db app policy, which already has a lot of work done on it. there's more than enough other stuff for us to focus on here. > > Providing a VirtualHosting facility > > ----------------------------------------------------------------- > > 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. could you provide an example of that? i don't know of any webapps off the top of my head that fall into this category. > IMHO, there is sth to do, maybe some srvconfig-common that would take > advantage of the under-used /srv tree. i really disagree here. i think we should remain completely /srv agnostic, or at least do nothing other than symlink into /srv. there already exist mechanisms to alias a website directory to something under /usr/share/foo, so i think it's kind of moot. > 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. that's not true, most applications (at least ones that don't require daemons) do work on a per-vhost level, though the local admin has to do some work to get them to work. > 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. yeah, this kind of sucks... istr someone declaring that they were going to do some work on this, but can't seem to dig up a reference. however, this is not as serious of an issue (unless you're packaging a PEAR library) because you can always work around it by changing include_path with ini_set (either in the code, config file, or apache config). > 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. is there a limitation of the number of paths in the include_path? > I'm the author of a small draft of a PEAR packaging policy (that is > really not final and is not perfect) [1] aha, cool. On Tue, May 03, 2005 at 02:06:07PM +0200, Pierre Habouzit wrote: > the fact is if you change some templates, you don't want the upgrade to > simply override them. well, i'd argue that they weren't templates in the first place. > and AFAIK, rt is not that good, since it has no less than 3 packages in > debian, and I recall some guy explaining that it was really hard to > upgrade from one version to the next, and that was why there is 3 > packages (v3, 3.2 and 3.4). IMHO, that is not a success story at all. > if every single webapp means a new package for each new minor > release ... we are driving into the wall. the problem with upgrades is definitely a problem, but is somewhat tangential to what i was discussing. rt uses an "overlay" system, where you can put a copy of a page in /usr/local/somewhere and modify it, and then when you access a page in rt, if a modified version of the page exists there it will use that instead of the default. the upgrade problems have more to do with rt changing the location of files or their api, not with the overlay concept itself. that said, it illustratees exactly why providing such a feature can be a problem. > srv-instanciate [webapp] [directory] > > that would work like that : > > srv-instanciate myApp /srv/myvhost.mydomain.org/myapp let's not talk about the tools before we finish figuring out what exactly we're trying to do :) > > - is cgi-bin obsoleted? > I don't think so, for PHP, I've been told fastcgi is more efficient than > apache module e.g. But that is sth the webapp should not have to be > aware of. most of (even if it's not 100% true) the web apps (in php at > least) work in php-mod as well as in cgi mode. so that should be sth > that only the webserver has to be aware of. sorry, i should have been more clear. i meant is the *location* /usr/lib/cgi-bin obsoleted. also, there's the whole arch-independant cgi issue. On Tue, May 03, 2005 at 01:50:04PM +0200, Pierre Habouzit wrote: > another thing, that is related to what I said, is providing some > "quality" criteriums to allow a php package to be in debian. that's a great idea, that i haven't heard before. having a "web applications must meet the following standards" criteria could save us a lot of trouble. a problem i see with that is it could exclude an otherwise dfsg application from debian, which i don't think would make it very attractive to the debian community at large. how about "must meet the following standards if they are to work out-of-the-box, otherwise the packager must do no automatic stuff"? > [1] : here the point is for *libs* not for apps. I think we may be more > tolerant wrt apps, but libraries *have* to behave well in any > common PHP configuration. agreed. On Tue, May 03, 2005 at 02:20:01PM +0200, Thijs Kinkhorst wrote: > so we have an overview of all that could be done, and then split off into > separate threads, eg about the (db,www)config-common packages, or a > policy, security etc. i think alexis was right to first talk about the current problems and issues. while we're doing that (and continuing afterwards), we can discuss how we think they *should* be done, and generate a policy. *after* that should we really start talking about the packaging "interface" that developers would use. > This is nicely solved in the phpbb2 package, which contains instructions > on how to set it up for multiple boards on one host. It amounts in short > to the following: create separate db, create new copy of config file under > etc, change apache config snippet to point to this new config file. While > not perfect or automatic, it is reasonably well doable. yeah, this is what i was getting at. i think it should eventually be possible to support such a thing via packaging tools, but that will be a little complicated. > I think it's important to require PHP apps to run with register_globals > off, since this prevents a lot of potential security holes. If upstream in an ideal world, yeah i agree. unfortunately far too many upstream apps don't practice this :) > doesn't support this at all this is not feasible (they should be pushed to > change that). In that case one should include a means / instruction of > turning r_g on for this specific application only so people won't turn it > on globally. this is pretty easy to do, you can do it in the apache config for the web app, or you can do it via a small patch to use ini_set somewhere in the code (or config file). > Also, if reasonably possible it should be made compatible with PHP's > safe_mode. agreed. i think what's surfacing here is that there we're finding some "must" features and some "would be nice" requirements. sean --
Attachment:
signature.asc
Description: Digital signature