hi andrew, penny, et al, On Thu, Jul 28, 2005 at 09:49:40PM +1200, Andrew McMillan wrote: > Having now been forcibly reminded, I include a document which is a > consolidation of the notes I took, and the notes taken by Dmitri > Borodaenko before he had to leave. > > And I'm even subscribed to the list now too, so no need to CC me on > replies (although that's fine if you want too). thanks for joining up. seeing as most of your names aren't too familiar, i'm wondering how much you are aware of what the current state of things are wrt our work in web/db policy, as well as the "implementation" packages. i'll inline some comments to give you and idea where things actually stand right now. > Meta Things > =========== > Initially these are going to be guidelines. Later the ones that are > successful will likely become recommendations, and further down the > track they should become policy. > > We need recommendations, not rules at this stage. Or at least not too > many rules. > > We need to write policy, but we need to write code to implement it > before we can expect people to do the approach we've been using so far is to draft what we consider best practices, and pretend that they are policy in every respect except our abstract, in which we state that this is a draft pending approval. in my database policy i go one step further and clearly state that it's a best practices document that one day hopes to be part of a policy. there's still a fair amount of work to be done here, please take a look at the contents of the doc directory from the webapps-common and dbconfig-common packages to get an idea. a few days ago we also had a discussion about the next steps, and who we should go to for feedback once we get the last couple things smoothed out. > Database > ======== > create database > create account > generate database > DB app policy this is all pretty much taken care of via dbconfig-common. of course comments, questions, and improvements are all welcome, but at this point our focus has really shifted away from db related stuff and more towards web-server, web-application, and web-programming-language related topics. > Templates > ========= > merging changes is pain > conffiles or not at all we had a pretty detailed discussion about how to handle various template related situations, and had more or less the same resolution. dig back in the archives about 2 months if you'd like to se the whole discussion. in fact, i'd say if you're interested in helping out with this effort that starting from the beginning of the list archive and reading forward to this email practically required reading. > Virtual hosts, FHS > ================== > > vhost->server-flavour this will be one of the trickier things to accomplish, but is within reason that we can do so. we've discussed a few ways of implementing this. > /srv tree imo we should stay away from /srv as much as we can. > cgi-bin location i think /usr/lib/cgi-bin is almost obsoleted, though i don't think we say anything specific about this opinion (which may not be globally shared) in our document yet. > Web-editable configuration > ========================== > Don't ever use /var/www > Recommend to remove first setup page and have a Debian way of dealing > With such setup (due to security considerations); Debian way here is: > Have sane defaults and debconf for the sane options i think the important thing is that after installation it's not left in a wide-open state. if that can't be done then it shouldn't be automatically configured, or there should a be an activate/deactivate toggle switch. > No web-app writable files in /etc yeah, we've currently made allowances for this, but perhaps a better approach would be to write them under /var/lib and include them from the main config. > Remote Database Packages > ======================== > We want the database package maintainers to create ???remote-??? packages > allowing specification of remote database, user and host information so > that we can also attempt automatic upgrades of databases that are > remote, as well as for local ones. i'm not sure i'm following exactly what the 'remote-' packages do. > Web Applications should depend on dbconfig-common as well as depending > on (local-database-version | remote-database-version). yes, dbconfig-common has no dependencies on the db servers in question, to keep it as lightweight as possible and not force someone using a mysql app to have pgsql libs installed and vice versa. i believe the documentation states this. > Databases we need to consider > ============================= > PostgreSQL > > LDAP > > Firebird > > MySQL well, i have 2/4, and adding the other two shouldn't be too hard for any interested party. i have enough experience with ldap that i could cobble that together in a day's hacking if i had a reference package to use as an example. > "Magical" Upstream Upgrade programs > =================================== > How do we handle applications that have magical web interface upgrades? > The general recommendation is that the upgrade should be done outside of > the web application. In as many cases as possible we from personal experience, this is a pretty tricky topic. for example, cacti very frequently needs to touch the database during upgrades. dbconfig-common is flexible enough that it can run sql code or scripts during specific version upgrades, but what cacti does is so complex that i'd rather leave it to the author's code (which is much more well tested). however, when the package is updated, it does temporarily place the web application in a 'vulnerable' state, where the next person to visit the application temporarily has limited administrative control. addressing this is important and i don't believe we've done so yet. > Restricting Application During Upgrade > ====================================== > Several approaches may be possible, e.g. dropping in a .htaccess file > during the upgrade, stopping the web server during the upgrade, and so > forth. We all agreed that the decision is up to the web application. this is probably true, depending on the nature of the upgrade. i think it's reasonable that we could try and generalize the different types of situations and built support for handling them in the "implementation" package though. > Depending on a Webserver > ======================== > Is an application-specific thing. yes. it might be nice to draft a reference for developers to know how to determine whether or not their package will be compatible with foo httpd-providing package, though. > Bundling is Bad > =============== > When upstream wants to bundle (e.g.) PEAR then we should endeavour to > rip it out and depend on a package of it. agreed. however, how will we handle situations where the local admin has installed a pear package via pear and not the debian-provided pear package? for example, say they want a newer version of the pear DB stuff. we could probably address this by placing locally installed pear packages in a directory ahead of the debian package pear directory in the include_path. > It is possible that the different library versions might need versioned > package names and locations. as in the version of the pear package, php, or ? hwoooh. anyway, lemme know what you think :) sean --
Attachment:
signature.asc
Description: Digital signature