Wiki movement

[Zarggg]

That's actually a very common error people make when installing MediaWiki (and I have made it myself). Make sure that /images/ is CMODed to 777.

[randi]

I looked through my mail logs yesterday and discovered that mail sent by the wiki was being caught as spam:

(host xxx refused to talk to me: 550 5.7.1 (xxx): Client host rejected: Are you spamer?
host xxx said: 450 <xxx>: Sender address rejected: Domain not found (in reply to RCPT TO command)

So I decided to spend the time to set up postfix properly. For some reason, out-of-the-box, it was able to send e-mails from cron jobs to me just fine, but mail I sent myself got filed away as spam. I was able to fix that, so I can now mail myself from my server without my primary e-mail treating it as spam, yet mail sent by the wiki is still filed as spam. Meh. Maybe once I have zdoom.org pointing there instead of my old host, I can fix that...

[Hirogen2]

No fair cheating! You and your "tools."

"Fair cheating"? (Pretty much an oxymoron.) Anyway, it's just a whois away. Then again, it's not like the world would be jumping off that hoster.

[randi]

Here's another update: I've decided to switch the database from MySQL to PostgreSQL and ran into a bit of a snag. MySQL does not enforce foreign key constraints; PostgreSQL does. This is a problem because over the wiki's lifetime, I deleted several spambot accounts without deleting all references to those accounts. MySQL let me do that when it shouldn't have, so now I need to edit the database dump by hand to remove all these references so that I can successfully import the database into PostgreSQL. In the end, the wiki is probably going to be closed for modification for a day or two while I fix it, rather than the hour I had expected. (Don't worry, the MySQL version of the database that has been used all along still works, so the wiki is still available; you just can't make any changes to it.)

[randi]

Wiki editing is enabled once again with the database now stored using PostgreSQL. Now to finish setting up phpBB 3...

[Grubber]

I've said it before and I'll say it again:

We encourage only those running the release candidates wanting to test out the new version, it is still recommended to wait for the full release; after all this is a release candidate.

Am I paranoiac? Probably yes .

[Karate Chris]

I think phpBB3 is stable enough. That reminds me. I need to update to the latest version.

[Grubber]

It might be stable, but there still can be security problems.

[randi]

I see one security change from RC4 to RC5 relating to the use of custom BBCodes. RC4 had none, RC3 had one, and RC2 had three. Seems pretty good to me, considering there are sure to still be things found after they go final. I'd rather get the forum upgrade out of the way now than wait until later.

[stevenaaus]

Randy wrote -

> MySQL does not enforce foreign key constraints;
> PostgreSQL does. This is a problem because over the wiki's
> lifetime, I deleted several spambot accounts without
> deleting all references to those accounts. MySQL let me do
> that when it shouldn't have, so now I need to edit the
> database dump by hand to remove all these references

Do you mean editting the database with a text editor ??
Can't you just (in mysql):

For entire database
delete entry where entry.account not in accounts

Or is this what you meant ? (Sorry for my shitty quasi-sql. I ~used~
to now it).

[Gez]

Do you mean editting the database with a text editor ?

Technically, you can't. A database is not text. (Only way you can do that is export the whole database to SQL requests, delete it, edit the SQL requests, and then run them. Kinda cumbersome. On the plus side, with a real text editor, you can make regexp-based search & replace.)

[randi]

Do you mean editting the database with a text editor ??

Yes, that's exactly what I mean. MediaWiki has a script that connects to a MySQL database, dumps it, and massages it into something that PostgreSQL will take. Some of the columns that store user-ids are null on delete, some are cascade on delete, and some are block on delete. I figured the safest way to proceed would be to run the dump, fix the error it flags up, and repeat until there were no errors.