Wiki movement

Zarggg · Post by **Zarggg** » Sat Aug 04, 2007 8:24 pm

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.

Post by **randi** » Fri Aug 24, 2007 8:21 pm

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

/var/log/mail.log wrote:(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 · Post by **Hirogen2** » Sun Aug 26, 2007 2:58 am

randy wrote: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.

Post by **randi** » Mon Aug 27, 2007 8:57 pm

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.)

Post by **randi** » Tue Aug 28, 2007 11:09 pm

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

Grubber · Post by **Grubber** » Wed Aug 29, 2007 1:44 am

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

phpbb.com wrote: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 · Post by **Karate Chris** » Wed Aug 29, 2007 2:36 am

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

Grubber · Post by **Grubber** » Wed Aug 29, 2007 6:40 am

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

Post by **randi** » Wed Aug 29, 2007 8:58 am

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 · Post by **stevenaaus** » Sun Sep 09, 2007 6:04 pm

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).

Post by **Gez** » Mon Sep 10, 2007 3:15 am

stevenaaus wrote: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.)

Post by **randi** » Tue Sep 11, 2007 3:49 pm

stevenaaus wrote: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.