DailyStuff

Al geruime tijd gebruik ik een Bayesian-filter om e-mail te beoordelen of het ham of spam is, maar wat is de stand nu na enkele maanden? Gelukkig loopt rrdtool mee te bepalen wat de vullingsgraad van de database is. Op de maandgrafiek lijkt niet echt mis en dat terwijl het langzaam lijkt af te nemen.
Als we naar de jaargrafiek kijken dan ziet het er iets heftiger uit, maar na de eerste dip in mei is de database aangepast om nog maar 500.000 tokens te bewaren maximaal. Dit omdat het verschil tussen de top en de bodem te groot was. Deze nieuwe top is dan ook zeker te zien bij de twee pieken erna, maar hierna lijkt de database zoveel spreiding in tokens van verschillende data te hebben dat er eens stabiele vullingsgraad komt.
Als we naar de huidige afname kijken dan zou die nooit onder de 375.000 moeten komen, want dat is de magische grens van 75 procent van 500.000 die in de database zou moeten blijven zitten bij een opschoning. Mocht dat wel gebeuren dan komen er niet snel genoeg verse tokens bij, maar dat zal duidelijk moeten worden in de komende maanden. Voorlopig lijkt de stroom van spam en ham berichten stabiel genoeg om dit voor elkaar te krijgen, maar het is even afwachten.

Gisteravond werd DNSSEC ingevoerd voor de root-zone, maar vlak voor de invoering kwam nog een foutje in BIND 9.7.1 naar boven. Dit mocht helaas de pret niet drukken en wat sommige voorspelden met het einde van de wereld is ook niet uitgekomen en zijn de eerste ccTLD en non-ccTLD opgenomen met een DS resource record.

De tijd is dus gekomen om te kijken om van DLV af te gaan stappen en kijken of de resolving correct blijft werken. De tijd is dus ook gekomen dat SIDN binnenkort DNSSEC gaat ondersteunen, want de belofte was om dit een maand na de root-zone te gaan ondersteunen.

Helaas werken sommige oplossingen niet correct zoals de resolver in de Fritz!Box. Bij het opvragen van de nameservers van de root-zone met het verzoek om DNSSEC te gebruiken besluit de firmware om op slot te gaan voor een paar minuten. Er is een bugreport naar AVM gegaan en hopelijk komt er binnenkort een update.

De vraag die ook al bij IPv6 kwam is hoe lang het nog gaat duren voordat het mainstream gebruikt kan worden. Want veel verouderde oplossingen worden nog steeds verkocht en zolang is het nog niet geleden dat oa SpeedTouch-modems alleen maar A en CNAME records konden verwerken.

Als een eerstejaars ben ik sinds jaren weer in de autocommit grap van database getrapt. Om een of andere reden bleven de tupels netjes in de tabel zitten. Dit terwijl de query direct met psql uitgevoerd wel netjes zijn werk deed. Dus maar eens in de documentatie van psycopg2 gedoken om te zien wat er mis was met de volgende Python-code.

1
2
3
4
5

curr = conn.cursor()
try:
    curr.execute("""delete from tabel where x > 2""")
except Exception, e:
    exit(1)

Het antwoord was helaas snel gevonden en deed me terug denken aan de eerste stappen op Oracle. Een dikke 15 jaar geleden, dat wel. De bijgewerkte code hieronder vertelt eigenlijk wel het verhaal.

1
2
3
4
5
6
7

curr = conn.cursor()
try:
    curr.execute("""delete from tabel where x > 2""")
    conn.commit()
except Exception, e:
    conn.rollback()
    exit(1)

Ik heb me laten misleiden door de autocommit bij andere modules binnen PHP en Perl als een eerstejaars. Want daar stopt autocommit op het moment dat je een transactie start, maar hier moet alles worden gecommit. Dit doet met denken of er dirty read/write bugs zijn te vinden in sommige applicaties die autocommit doen.

Sinds enige tijd doe ik mee aan de IPv6-pilot van XS4ALL om gebruik te kunnen maken van IPv6 zonder dit via een extra tunnel te doen. In een recente update, versie 54.04.81-17599, voor oa de Fritz!Box 7270 van AVM is de ondersteuning voor RFC 5006 goed aangepakt. Helaas staat deze optie standaard uit, maar wel begrijpelijk om potentiële problemen te voorkomen met minder goed werkende netwerk hardware. Gelukkig zijn zowel MacOS X als vele Linux distributies klaar voor RFC 5006.

De vraag alleen is wat heb je aan RFC 5006? Het ligt eigenlijk in de provisioning van de nameservers die kunnen worden gebruikt als resolver. Met de komst van IPv6 is een DHCP-server eigenlijk niet meer nodig en blijft de vraag over hoe je sommige configuratie-items gaat zetten. En hoewel RFC 5006 een smerige hack lijkt is het eigenlijk wel netjes, want er zijn voorzieningen om bepaalde uitgiften te laten ondertekenen in IPv6. Hiermee gebruikt de client alleen gegevens met het juiste signature en is het eigenlijk veiliger dan vele DHCP-oplossingen die nu binnen bedrijven staan, maar een daadwerkelijke bruikbare oplossing laat nog op zich wachten.

Het aan de praat krijgen op bv Debian of Ubuntu is vrij simpel met de volgende opdracht.

$ sudo apt-get install rdnssd resolvconf

Als je nu reboot en kijkt in /etc/resolv.conf krijg je bv het volgende te zien:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fd00::21f:3fff:fe30:4ff0
nameserver 192.168.178.1
search fritz.box

Wat nu nog overblijft is NTP wat met behulp van NTP-broadcasting gedaan zou kunnen worden, maar hier kleven wel nadelen aan. Want hoe kan je de broadcaster vertrouwen dat hij de juiste tijd geeft? Hoor ik hier een oplossing in DNSSEC?

Bij het lezen van idee #25103 op de Ubuntu Brainstorm-site kwam de vraag hoever Debian dit nu heeft opgelost. Zeker aangezien Debian de moederdistributie van Ubuntu is en ze enige tijd geleden al waren overgegaan op een GeoDNS oplossing voor sommige sites.

Een brand, een zware verstoring en een update van OpenOffice.org heeft ervoor gezorgd dat model van security.debian.org anders moest. Het moest van een enkele server naar een schaalbare oplossing gaan zonder daar de gebruikers mee op te zadelen. Dit is gelukt aangezien security.debian.org nu mbv GeoDNS en HTTP-polling voor iedereen bereikbaar is gemaakt door een bereikbare mirrorserver in de buurt van het gebruiker aan te bieden.

Voor de algemene repository is de urgentie wat minder groot, omdat de gebruiker zelf kan kiezen in welk land de mirrorservers moeten worden benaderd. De vraag blijft of deze manier blijft schalen, want er zal altijd wel ergens een server onbereikbaar zijn door werkzaamheden. De Nederlandse mirror is daar geen uitzondering van, maar voor gratis hosting moet je iets over hebben. En waarom zou een andere server dit werk niet “transparant” kunnen overnemen?

Een klein project loopt nu om te testen of te kijken wat de meest ideale manier is om dit ook voor de normale mirrors van de repository te doen. Gelijk komt hier het probleem naar voren dat niet alle mirrors alle architecturen aanbieden, maar iedereen met een i386 of amd64 installatie zou overal zijn packages moeten kunnen krijgen. De aanpassing aan sources.list zoals hieronder is vrij simpel.

deb http://cdn.debian.net/debian/ testing main
deb-src http://cdn.debian.net/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main


Nu al enige tijd staat cdn.debian.net in mijn configuratie voor APT en ik moet zeggen dat ik voorlopig tevreden ben. Hopelijk wordt dit project verder uitgewerkt en opgenomen in zeg Debian 7.0, maar dan moet 6.0 wel eerst uitkomen natuurlijk.