Posted on

Met MediaWiki 1.14 naar PostgreSQL

PostgreSQL ondersteuning kwam pas met versie 1.12 echt van de grond en met 1.15 voor de deur werd het tijd om verschillende 1.13 installaties te gaan upgraden naar 1.14. Bij een eerste poging om van 1.13 naar 1.14 te gaan gingen de wiki’s blank wat helaas geen mooi gezicht was. Bij het niet kunnen herleiden van het probleem bleef alleen de upgrades naar 1.13.3 en 1.13.4 over. Bij het uitzoeken wat er mis was besloot Oracle om Sun Microsystems over te nemen waarbij de toekomst van MySQL nog onzekerder is geworden. Dit ook omdat MySQL 5.1 onder leiding van Sun ook al niet geheel een positieve ervaring was en MySQL 6 heeft DukeNukem Forever trekjes.

Het werd tijd om in een testomgeving MediaWiki 1.14 op te bouwen met PostgreSQL als achterliggende database-engine. Het overstappen van database-prefixes naar schema’s maakt de DBA in mij ook weer blij nu het wat overzichtelijker is geworden. Zeker omdat PostgreSQL dumps op schema-niveau ondersteunt en met veel verschillende wiki’s is dat wel een fijne feature, want bij MySQL is dit helaas niet mogelijk.

Helaas zijn er ook nadelen met de overstap naar PostgreSQL zoals dat voor MediaWiki 1.15 een nieuwe versie van PostgreSQL vereist is. Ik gebruik nu 8.1 en dan zal 8.3 nodig zijn volgens de specificaties. Een tweede punt en dat hangt samen met deze aanpassing is het laden van tsearch2-ondersteuning, maar deze ondersteuning zou bij PostgreSQL 8.3 standaard is de database moeten zitten. Voorlopig voldoet Mediawiki 1.14 en kan de upgrade nog even wachten tot het moment dat de databaseserver overgaat van Debian 4.0 naar Debian 5.0 deze zomer.

Nu deze migratie van MySQL naar PostgreSQL gedaan is gaat wordt het tijd om de volgende migratie te gaan voorbereiden. Dit zullen hoogstwaarschijnlijk Dovecot en Postfix gaan worden, maar eerst even kijken of er nog issues uit de migratie van MediaWiki komen.

Posted on

PostgreSQL voor Bayesian-filtering in SpamAssassin

SpamAssassin beschikt over veel regels om e-mail te doorzoeken en te beoordelen op basis van een score of het spambericht is of een mailbericht. Er bestaat ook een optie om SpamAssassin uit te breiden met extra regels en bestaande te updaten, maar deze wedloop kan nooit worden gewonnen. Gelukkig zijn er meer opties om e-mail te beoordelen, zoals met een Bayesian-filter waarbij de kans wordt berekent of een bericht spam is of niet. Een methode waarbij niet wordt gekeken naar de frequentie dat iets voorkomt en daarmee alleen kan zeggen of een stelling waar is of niet waar is. Er is de mogelijkheid om te zeggen dat een bericht de kans heeft van 20% dat het een spambericht is en daarmee is de kans dus redelijk laag, maar er kan ook uitkomen dat de kans 80% is waarmee het veel aannemelijker is dat het een spambericht is.

De voorwaarde voor een goede werking is om goede statistieken te hebben om zo een kansberekening te maken. En hoewel er discussie bestaat over hoe deze statistieken moeten worden gemaakt lijkt de methode nu te werken om het filter op een regelmatige basis zowel spam- als hamberichten te voeden. Hoe je aan deze berichten komt laat ik nu even buiten beschouwing. De eerste stap op Bayesian-filtering aan te zetten in SpamAssassin is door de volgende aanpassingen te maken in /etc/spamassassin/local.cf:

use_bayes 1
bayes_auto_learn 0

Na deze aanpassing moet een database worden aangemaakt in PostgreSQL en moet worden voorzien van de tabellen die in /usr/share/doc/spamassassin/sql/bayes_pg.sql staan. Hierna moet /etc/spamassassin/local.cf worden uitgebreid met de onderstaande regels om SpamAssassin de database te laten gebruiken.

bayes_store_module Mail::SpamAssassin::BayesStore::PgSQL
bayes_sql_dsn dbi:Pg:dbname=database;host=localhost;port=5432
bayes_sql_username gebruiker
bayes_sql_password wachtwoord

Vanaf dit moment kan SpamAssassin gebruik maken van PostgreSQL om te beoordelen en met spamassassin –lint kan worden gecontroleerd of alles correct werkt.

Posted on

PostgreSQL wordt geaccepteerd?

MySQL was altijd de database in het open source landschap, maar de laatste tijd lijkt daar steeds meer verandering in te komen. Projecten richten zich meer om applicaties op meerdere databases te laten draaien en zo ook MediaWiki wat de software achter WikiPedia is.

Maar het was al even mogelijk om PostgreSQL als database voor MediaWiki te gebruiken, maar er waren nog voldoende onvolkomenheden. Gelukkig komt daar met versie 1.10.1 verandering is en worden zoekfuncties betrouwbaar naast de al goede performance van MediaWiki op PostgreSQL die zeker te vergelijken is met de MySQL implementatie.

Hopelijk maken meer projecten zich sterk om PostgreSQL als database backend te gaan gebruiken, want concurrentie cq competitie is goed in de open source wereld om een gezonde omgeving voor iedereen te maken en te houden.