[gentoo-dev] Web application data
It seems that many web applications have a need to store data, logs, etc. I have been using a directory scheme I thought others on this mailing list may be interested in. Because of my need to keep things neat, clean and separate I do not like having this dynamic data in the same web directory that serves the application. For instance, my PyBlosxom ebuild has serveral CGI files that get installed when you use webapp-config to create a new instance of the application. I did not want the data and log files to reside in that same path. So what I did was create a hook script that webapp-config runs whenever it installs or removes and instance of the PyBlosxom application. The hook script creates a directory specific to that instance that is being installed. Given an instance of PyBlosxom served from the /blog directory you get this: /srv/fqdn/www/htdocs/blog /srv/fqdn/www/webapps/blog/data /srv/fqdn/www/webapps/blog/logs The structure allows the data to be separate from the application. This does not force the /srv heirarchy on anyone, the hook script uses the webapp-cofig environment variables so that things get installed where the user would expect them. To keep things separate I take this one step further. I also push the directory of the web application down a level. This separates content I generate from content that was installed for me. So my directory structure actually looks more like: /srv/fqdn/www/blog # PyBlosxom /srv/fqdn/www/mail # Squirrel Mail /srv/fqdn/www/htdocs# my content /srv/fqdn/www/webapps # web application data Does this seem reasonable? I was thinking about writing a GLEP or proposing an addendum to GLEP 11 or 20 to address this. My driving force behind this is a desire to have the application and the application data separate. As a side effect it is easier to do backups and my data between machines. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpjRBaQMR1NQ.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 03:32:40PM -0700, Donnie Berkholz wrote: > > Krzysiek Pawlik wrote: > > Use `quickpkg` before dangerous updates/merges. If something brakes - > > untar the package. > > Doesn't work too well when tar's broken too. =) How about statically linking a version of tar with portage. This way tar cannot be broken. Add an option to emerge, --backup or something similar, that will automatically run quickpkg. Then make a erescue executable that can parse the command line to figure out which package the user wants to be rescued from, and execute the new tar command. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpQUoBThCuhI.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: > On Sunday 15 May 2005 16:41, david stanek wrote: > > Add an option to emerge, --backup or something > > similar, that will automatically run quickpkg. > > If you set FEATURES="buildpkg", portage automatically makes binary packages > for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpXNiuhdlWu3.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 09:56:54PM -0400, David Stanek wrote: > On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: > > On Sunday 15 May 2005 16:41, david stanek wrote: > > > Add an option to emerge, --backup or something > > > similar, that will automatically run quickpkg. > > > > If you set FEATURES="buildpkg", portage automatically makes binary packages > > for you. No need to add new support. > > That would build a binary package for the potentially broken > package. What it would need to do is build a binary package of the > existing merged package. So a user can recover from a botched > upgrade. Actually a very simple safe-emerge script can be easily written. It could first do an 'emerge --buildpkg' on the existing merged package, if that package was already merged. The other part would be to create a statically linked version of tar that can be used in a recovery situation. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpvGsYgziGCW.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 09:07:15PM -0700, Sami Samhuri wrote: > * On Sun May-15-2005 at 05:18:06 PM -0400, Mike Frysinger said: > [...] > > my proposal is to implement a new utility (called 'erescue' for lack of a > > better name) that is written in C and designed to be statically linked ... > > then next time you break a core system package which cannot be recovered by > > simply running `emerge` a few times, you run `erescue ` > > Everyone who is saying that Portage can already sort of handle this > seems to be missing one important point. If Python is broken then emerge > won't work. The proposed erescue would still work in that case. If erescue is a statically built binary that basically untars a backed up copy of a package, why would it depend on Python? -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpxBL8wrNK4r.pgp Description: PGP signature
Re: [gentoo-dev] Pinboard of outdated ports
On Tue, May 24, 2005 at 07:26:49AM +0200, Johannes Weiner wrote: > > What it seems like you're doing here is saying more work for the > > developers is fine, if it makes things easier for the users. (Developers > > will just cvs up, which is likely faster than dealing with a web interface.) > > I dunno if it's really big work to have a look at one site to see if > there are ebuilds you missed when they were updated. > It was not my intention to make really more work. It was just to find a faster > way for outdated ebuilds getting updated. If it is difficult for the users, maybe it needs to be documented better. Might be as simple as a "Report old ebuild" links on the Bugzilla homepage. Somehow I don't think it is all that difficult though. To make a clean separation for other Bugzilla content a new Component may be added. This should ease an searching issues as long as the users searching are aware of the new component. But then we'd probably still see a bunch of confused, headless chickens running around squaking "ebuilds, old ebuilds". -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgp1w7iYtHEec.pgp Description: PGP signature
