Waarom mag je digit 1 tot 3 van je bankkaartcode wel corrigeren wanneer je mis bent bij het invoeren in een bankterminal, maar nooit de 4de? Na het indrukken van de 4de digit wordt de code meteen gecontroleerd. Wanneer een toets wat blijft hangen (laat ons zeggen, de toets die uw derde cijfer bevat), kan dat wel nefaste gevolgen hebben.
Sinds enige tijd was onze mailscanner setup ietwat slecht in het onderzoeken van mail op spam en niet-spam. We gebruiken daarvoor, net als elke andere hoster, een bayesian engine. Door de tijd heen was die wat vervuild geraakt, en uiteindelijk deed hij zijn werk niet meer 100% goed (teveel spam ongemarkeerd laten).
We hebben dus enkele dagen spam verzameld in onze mailboxen (na enkele dagen zaten we aan ongeveer 5000 spam-mails, dus spam is wel degelijk een probleem). Daarnaast hebben we ook onze algemene mailboxen samengegooid, om genoeg “ham” te hebben.
Eens we genoeg van alles hadden (ongeveer dubbel zoveel ham als spam), heb ik de bayesian databases herbouwd. Omdat ik niet meteen vond op het internet hoe je nu proper de boel leegmaakt, hier even een miniem overzicht (zo heb ik het gedaan, en het werkt zo, voor een gemeenschappelijke DB!):
# /etc/init.d/uwmailscanner stop
# cd /waar/je/dbs/staan/
# mkdir old
# mv bayes_* old
# touch bayes_toks
# touch bayes_seen
# sa-learn --rebuild -C /pad/naar/je/cofiguratie
Dat zou je lege databases moeten geven, dit kan je controleren met ‘sa-learn –dbpath /waar/staan/je/dbs –dump magic’. Het resultaat zou allemaal 0 moeten zijn.
We gaan ervan uit dat je een directory met spam hebt (gewoon, 1 message per file, maildir-achtig dus, maar zonder de cur/new/tmp brol).
# sa-learn --spam --no-rebuild -C /config/pad --showdots ~/training/spam/
...... etc etc
# sa-learn --ham --no-rebuild -C /config/pad --showdots ~/training/ham/
....... etc etc
# sa-learn --rebuild -C /config/pad
Opnieuw de dump van de magic doen, en je “nspam” en “nham” waarden zouden het aantal spam en ham moeten weergeven, en je tokens zouden een bepaalde zinnige waarde moeten hebben.
Dan de boel goed chown/chmodden (je kon dit noteren in stap 1, voor je de mv deed 
), en je mailsysteem een duw geven… Klaar.
Eurid is al meermaals in de fout gegaan, maar nu gaan ze toch een stapje te ver:
Eerst en vooral is er het voorval van gisteren, door Frank gemeld, en die door Eurid opgelost werd met de fijne mededeling dat ze er niets aan gaan doen, de namen zijn “correct” geregistreerd, en iedereen kon het doen, en iedereen dus gelijk was. Dit maakt me razend, maar soit, daar kan ik even nog mee leven…
Dan was er nog iets anders. Kijk wat er onlangs door een bepaald persoon gestuurd werd naar een mailinglijst:
> > A week ago I discover how Ovidio and other people were able to
> > register so many domains that other had applied for*. EURid have a bug
> > that makes it possible to download the whole database with all 2000
> > 000 domains names.* It was a terrifying thing to discover that EURid
> > have so less security and how simple this was to do so. I called tech
> > number and they said that they will correct the bug right away. Now I
> > week later the system is still leaking domain names to everyone that
> > wants the information.
Zeer intressante materie, maar onbewezen, dus met een korreltje zout te nemen. Ik moet wel zeggen dat ik de persoon geloofde. Zelf hebben we nooit het systeem onderzocht hoe het ineen steekt, en hebben we dus niet gevonden hoe het mogelijk is.
Het antwoord van Eurid bevestigt de correctheid van deze claim, maar het is vooral de inhoud van het antwoord dat me ietswat vreemd overkomt:
The feature did in no way affect the registration system
as such and did not jeopardize the fairness of the system since
all accredited registrars had the same possibilities.
Akkoord, als je het van heel ver bekijkt, heeft iedereen dezelfde kansen gehad, en moest iedereen maar elk hoekje van het systeem afzoeken, en de bug vinden, exploiten en de lijst afhalen. Nu de bug gepatched is, zijn de registrars wel niet langer gelijk. Er zijn er met lijsten, en er zijn er zonder lijsten.
Waarom zijn die lijsten zo belangrijk? Eenvoudigweg, elke naam op die lijst was reeds aangevraagd of geregistreerd. De laatste categorie is niet intressant, de eerste wel. De filtering kan vrij snel gebeuren, en dan heb je een lijst van namen die door mensen in sunrise 1 of 2 voor vrij veel geld aangevraagd zijn. Wanneer je dan verder filtert, en je neemt de namen die afgewezen zijn, dan heb je een lijst van namen, waar gegadigden voor zijn, maar de gegadigden hebben deze niet verkregen (verkeerde documentatie, verkeerde aanvraag…). Als je dergelijke naam kan registreren, weet je zeker dat er een afzetmarkt voor is. Ideaal voor domeinsquatters, en EXACT de reden waarom Eurid deze lijst uiteindelijk toch niet vrijgaf aan iedereen.
En Eurid doet natuurlijk alsof hun neus bloedt.
Vandaag bij een controle een bijna-foutje opgemerkt:
Checking MyISAM file: Foo.MYI
Data records: 37735284 Deleted blocks: 0
myisamchk: warning: Table is marked as crashed
- check file-size
myisamchk: warning: Datafile is almost full, 4084938976 of 4294967294 used
- check record delete-chain
- check key delete-chain
- check index reference
...
“Datafile is almost full”. Intressant. Moest ik niet beter weten, men zou zeggen dat er limieten op MySQL tables staan… De oplossing is eenvoudig, bij de creatie moet je opgeven hoeveel data je vermoed weg te proppen in je tabel. Als je het achteraf pas beseft, geen paniek.
Even kijken naar de huidige limieten:
mysql> show table status like 'Foo' \G
*************************** 1. row ***************************
Name: Foo
Engine: MyISAM
Version: 7
Row_format: Dynamic
Rows: 37735150
Avg_row_length: 98
Data_length: 3702075068
Max_data_length: 4294967295
Index_length: 1241720832
Data_free: 0
Auto_increment: 98045406
Create_time: 2006-02-28 09:06:42
Update_time: 2006-07-03 16:03:25
Check_time: 2006-07-03 16:15:45
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
Even wat bijsturen:
mysql> alter table Foo max_rows = 380000000 avg_row_length = 100;
Dit duurt even… Merk op dat ik hier avg_row_length 100 neem, gebasseerd op mijn average dat ik al heb, van 98.
En opnieuw de huidige limieten bekijken:
mysql> show table status like 'Foo' \G
*************************** 1. row ***************************
Name: Foo
Engine: MyISAM
Version: 9
Row_format: Dynamic
Rows: 37735150
Avg_row_length: 98
Data_length: 3702075068
Max_data_length: 1099511627775
Index_length: 1409983488
Data_free: 0
Auto_increment: 98045406
Create_time: 2006-07-03 16:18:54
Update_time: 2006-07-03 16:26:27
Check_time: 2006-07-03 16:32:57
Collation: latin1_swedish_ci
Checksum: NULL
Create_options: max_rows=380000000 avg_row_length=100
Comment:
1 row in set (0.02 sec)
Tadaa! En dat heb ik allemaal niet zelf uitgevonden, maar google gaf me een link naar hier.
Vrijdag is Baas A erin geslaagd -bij het debuggen van een probleempje op een nogal duchtig verneukte testmachine (het was ‘modprobe unix’ die de redding bracht, het probleem was ‘socket protocol error’ of zo bij een ssh)- een glas 100% natuurlijk veenbessensap in mijn extern toetsenbord te kieperen.
No problem, het is maar een keyboard van enkele eurootjes, maar ik ben het eigenlijk wel gewoon, en het werk gaat toch een stuk sneller op dit keyboard dan dat van mijn laptop (dat ik nog altijd niet 100% gewoon ben). De restanten er wat uitgegoten, wat gedept met een schotelvod, en dan nog eens proberen. Het keyboard werd foobar verklaard, en is in mijn papierbak terecht gekomen. Deze morgen toch nog eens geprobeerd, en de tijd had blijkbaar een goede invloed, het ding werkt terug.
Er is echter één probleem. Sticky keys. En dan bedoel ik niet de bovenkant, maar het “duw-omhoog” mechanisme. Af en toe blijft een toets zitten, en dan moet die er even uit, even wat water en zo, en dan werkt het weer. Geen probleem als het een spatie is (deze morgen, net als de linkse Alt), of een letter (de ‘n’, daarnet), maar het komt problematischer als je in je CMS aan de site zit te typen, en je opeens merkt dat je backspace al een kleine 30 seconden ingedrukt is. Weg toegevoegde tekst, welkom frustratie.
Ah, als het dat maar is. Regelmatig op save duwen dus…