DailyStuff

Bayesian database na enkele maanden

Hans — Tue, 27 Jul 2010 21:34:47 +0000

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.

DNSSEC, de dag erna

Hans — Fri, 16 Jul 2010 16:26:04 +0000

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 met psycopg2

Hans — Sat, 10 Jul 2010 18:45:09 +0000

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.

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.

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.

RFC 5006 ondersteuning

Hans — Fri, 09 Jul 2010 06:00:26 +0000

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?

Debian mirrors volgens het CDN-model

Hans — Tue, 29 Jun 2010 21:27:35 +0000

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.

HTTPS forceren

Hans — Fri, 11 Jun 2010 18:04:15 +0000

Er is veel te doen over HTTP versus HTTPS en met de “gratis” SSL-offloaders in de systemen van Sun Microsystems met de UltraSPARC T1, T2 en T2+ processor wordt het interessant om af te stappen van HTTP. Gelukkig hebben oa Intel-processoren optimalisatie voor oa AES en is met de juiste aanpassing aan het besturingssysteem en middleware zoals Apache mogelijk om SSL-verkeer sneller te laten afhandelen.

Nu kan je in de webapplicatie inbouwen dat dit moet gebeuren, maar als je massaal HTTP-verkeer naar HTTPS wilt migreren is het verstandiger om dit af te dwingen in de webserver. Zo ook voor een webmail-applicatie in dit geval waarbij de configuratie fouten kan opleveren en programmeurs snel fouten kunnen maken.

Door de volgende regels in de .htaccess-file te zetten in de documentroot van de website zal Apache tegen de webbrowser vertellen dat dit moet worden aangeleverd via HTTPS. Elke webbrowser die de HTTP statuscodes begrijpt zal dit vlekkeloos uitvoeren.
RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Aan deze oplossing zit wel een performance penalty verbonden. De initiale opbouw naar de website kan iets langer duren door de redirect naar de HTTPS-site, maar de grootste penalty zal zitten in de .htaccess-file. Bij productie websites is het dan ook verstandig om dit op te nemen in de virtual host configuratie binnen Apache zelf en de ondersteuning voor .htaccess-files uit te zetten. Hierdoor hoeft we webserver minder de documentroot voor de website af te zoeken naar oa de .htaccess-file.

MD en een nieuwe disk

Hans — Sun, 06 Jun 2010 06:59:58 +0000

Op Sun Solaris was en is het nog steeds met SVM redelijk makkelijk om een RAID1 opstelling van de boot-disken te herstellen. Je kopieert het disklabel over van de ene disk naar de andere, maakt de metadevices aan en koppelt deze weer. En met ZFS is het zelfs nog minder werk, maar hoe op Linux?

Op Linux is het gelukkig niet veel anders en met sfdisk kan snel de partitietabel worden overgezet.
$ sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
De tweede stap is om de partities weer in het array te hangen en een flinke tijd te wachten.
$ sudo mdadm --add /dev/md0 /dev/sdb1 $ sudo mdadm --add /dev/md1 /dev/sdb2
De derde stap voor boot-disken is om de code voor de boot-loader te installeren. Zoals GRUB in dit voorbeeld.
$ sudo grub-install /dev/sdb Installation finished. No error reported.
Vanaf dit moment is de RAID1 configuratie voor de boot-disken weer operationeel.

FeedBurner sites misleiden

Hans — Tue, 27 Apr 2010 06:37:21 +0000

Op verzoek van Antoon een vervroegde posting over hoe je RSS-feeds kan misleiden om toch de content binnen te krijgen zonder te worden gemeten bij FeedBurner. De makkelijkste oplossing is om proxy te gebruiken en dit voorbeeld ga uit van Privoxy om de juiste headers te herschrijven.

Als je verschillende plugins bekijkt dan zie je dat de plugins een redirect doen voor elk verzoek om de feed te downloaden. De redirect gaat naar de juiste URL bij FeedBurner, maar de plugins controleren eerste de User-Agent string. Als bij deze controle een match wordt gemaakt met de string “feedburner”, dan wordt er geen redirect gedaan en wordt de daadwerkelijk content geserveerd.

Dit laat dus de mogelijkheid open om ons voor te doen als FeedBurner. Gelukkig kan Privoxy naast inkomende content ook uitgaande HTTP-headers herschrijven. Door de volgende regels toe te voegen aan het bestand user.action van Privoxy zal in veel gevallen een aanpaste HTTP-header worden gezonden naar website ipv de HTTP-header van de RSS-reader.
{+crunch-incoming-cookies \ +hide-user-agent{FeedBurner/1.0 (http://www.FeedBurner.com)} } /.*feed /.*atom /.*rss
Wat sommige mensen zal opvallen is de optie om cookies te vernietigen, maar helaas blijken ook veel feeds oa cookies mee te sturen om te kijken hoeveel mensen hun feed lezen. Ook gelijk de waarschuwing dat ik nog niet voldoende tijd heb gehad om dit alle goed en lang te testen, maar voorlopig lijkt het correct te werken bij het bekijken van netwerktraces.

FeedBurner buitensluiten

Hans — Mon, 26 Apr 2010 06:58:51 +0000

Na Google Analytics gaat nu ook FeedBurner in de ban. Want monitoren is leuk, maar er zijn grenzen en zeker als alle data wordt geëxporteerd naar de United States of America. Een kleine uitbreiding aan de hosts-file lost dit snel op.
127.0.0.2 feeds.feedburner.com 127.0.0.2 www.google-analytics.com
Helaas stopte hiermee een redelijk aantal RSS-feeds met werken, maar daar is snel afscheid van genomen. Binnenkort eens kijken of we de juiste filter regels kunnen maken voor Privoxy.

Pod- en vodcasting veranderen mediaconsumptie

Hans — Sun, 18 Apr 2010 10:23:02 +0000

XML verdeelde de wereld in tweeën bij de introductie met voor- en tegenstanders, maar nu z’n 14 jaar later worden de voordelen duidelijk. Zelfs zo erg dat EBI de overstap heeft gewaagd naar ebXML en geeft misschien ook wel de kracht aan van XML. Want iedereen die kan programmeren in bijvoorbeeld C#, Java of Python kan van alles doen met XML-bestanden en de data die is ingesloten in XML.

Want iedereen kent wel het RSS-icon op websites waardoor je op de hoogte kan worden als er aanpassingen zijn aan een website. En gezien de actie van Google met hun Google Reader badge is RSS tegenwoordig een geaccepteerde standaard geworden om data te consumeren. Applicaties zoals iTunes, Songbird en Banshee doen nu hetzelfde voor meer conventionele media.

Deze conventionele media hebben een beperkte ruimte op de radiozender bijvoorbeeld, maar mensen hebben ook niet altijd tijd op het moment dat het wordt uitgezonden. Kleine broadcasters zijn hier al vrij vroeg ingesprongen en sinds enige tijd zie je ook partijen zoals BBC en NOS hetzelfde doen. Vele uitzendingen worden omgezet naar audiobestanden en aangeboden met behulp van een RSS-feed voor luisteraars nieuwe afleveringen te downloaden. Gelukkig is de NOS ook al begonnen om sommige televisie-uitzendingen via dezelfde manier aan te bieden.

Hoewel het beeldformaat voor de normale televisie veel te klein lijkt is het ideaal voor smartphones. Je favoriete podcast luisteren in de trein of je favoriete televisieserie kijken als je op het station staat te wachten. Hoe we Internet gebruiken en content consumeren is flink aan het veranderen en de vraag is of de overstap naar HD daar iets aan kan doen. Voorlopig geef ik de voorkeur aan pod- en vodcasts voor sommige programma’s, want het geeft me gewoon meer tijd dan zinloos voor een televisie zitten oa.