Meeting agenda robot

[Joerg Jaspert]

>> > > 5. we failed to add a new user to plone, then corrupted the database
>> > > by trying to download a copy of the page content from its webdav, then
>> > > discovered that a special "copy-the-plone-db-in-a-consistent-state"
>> > > command should have been run at backup time.  It's mainly by the
>> > > persistence of Ganneff and kind help from some (unknown to me) Plone
>> > > experts that most of the current site was recovered.
>> > Wow. I wonder how you managed to do that! That sounds like extremely
>> > unlikely breakage.
>> Actually, "corrupted the database by trying to download" is my
>> mistake.  I don't know that for sure.  I just think it's the most
>> probable explanation, but it could have been the attempts to add a new
>> user to plone which broke it, or simply the phase of the moon.

>> As far as I know, the download attempt was simply a davfs mount, then
>> tar czvf content.tar.gz mountpoint.  It seemed an extremely unlikely
>> breakage to me too, but that didn't make anyone any happier with us
>> after www.spi-inc.org was replaced by some error messages!

> I can see that producing errors if you had some magic filenames in there
> that conflicted with some ids plone uses internally. But that is
> something different than a corrupted database, and generally easy to fix.

What we had was a corruption of Data.fs in a way that the server did not
start anymore. It simply wouldn't come anywhere near its normal status,
floogin the log with "exiting, error 1\n starting, exiting\n...."
messages until it had enough of them and stopped entirely.

I don't know how exactly we got there. My tries to add a user all failed
with weird error messages (how about a ! as a response to "Add user"?)
and at the same time Jimmy was using the webdav foo. Thats all we had as
action at that time.

No known tool (to me or the Debian Zope People) was able to convince it
of getting back up. Nor fixing it. Yet most of them did their work. Like
fspack actually packing it for example. Without giving even the
slightest hint of a problem.

In the end we found a "space.py" somewhere in the zope tree. Which broke
on the file, denying to work. But did output some text for an old
backup. Modifying its code to not just die at a broken entry, we found
13 non-working OIDs (transactions?).
*Somehow* we then have been able to fix that damn filestorage to a point
a new zope instance was able to read it. Then we could do an export.
Which we have been able to import. Not that it worked then, I then
needed to go and export all the various subpages on their own, then
using an old Data.fs backup. Removing the subpages there and reimporting
those I just exported.
Voila, the page is back.


Somehow I doub't ikiwiki with git as backend or movabletypeopensource
with *sql or *anything* with a sane backend (read: not a
single-large-file storage) would have made it that complicated.

-- 
bye, Joerg
If the autobuilder tells me that my package failed to build from source,
it's probably doing that on some obscure architecture I don't have
access to.