I finally played with libcrm114, a C library that implements several text classification algorithms. It is a potential replacement for the mailreaver.crm tool, which is the basis for my SpamAssassin plugin.

Having a C library removes the need to fork a crm interpreter process (and in most cases also the need to read the learned feature data) for every single classification; it also enables the inclusion into other languages (so far I know modules for PHP and Python – now my module seems to be the first one for Perl).

A first and unprofessional benchmark against my mailbox confirms the expected performance improvement. I use Text::AI for the old fork-interpret-model (source) and Text::AI::CRM114 for the new library in-memory model (source).

~> time perl test_ai_crm114.pl
classified 9111 texts in 100.86 seconds (11.070 millisec per text)
Spam Texts: 68
 Ham Texts: 9043
30.717u 64.212s 1:41.50 93.5%   200+8161k 9361+0io 0pf+0w

~> time perl test_text_ai_crm114.pl
classified 9111 texts in 7.89 seconds (0.866 millisec per text)
Spam Texts: 68
 Ham Texts: 9043
6.719u 0.485s 0:08.41 85.4%     9+2691k 0+0io 0pf+0w

Die Verzeichnisstruktur hat dann üblicherweise ein /trunk für die Arbeitsversion und /vendor mit Unterverzeichnissen für die Upstream-Releases (die sich nicht ändern und deshalb nicht unter /trunk, /tags oder /branch liegen sollten). Ziel ist dann bei einem neuen Release alle Änderungen (also der diff zweier Verzeichnisse) auf die eigene Arbeitsversion (im dritten Verzeichnis) anzuwenden. Das Kommando dafür hat dann die Form: svn merge --accept mine-full --ignore-ancestry https://server.../vendor/snort-2.9.1 https://server.../vendor/snort-2.9.2 ./trunk/snort

Das entsprechende Kapitel im SVN-Book fand ich als Anleitung wenig hilfreich, aber Schritt-für-Schritt-Anleitungen findet sich in diesen Artikeln.

Interessanterweise ist dies ein Feature bzw. ein Workflow der sich nicht so einfach mit git nachbilden lässt (habe es auch noch nicht gebraucht, aber dieser Nachbau scheint zu funktionieren).

Ein paar Beobachtungen dabei:

• Dovecot als IMAP-Server ist toll. Seine große Flexibilität führt zum typischen Problem dass man zu Beginn auch viel Konfigurationseinstellungen sichten muss. Wenn man weiß wo man hinwill merkt man aber dass nur wenige der Optionen auch benötigt werden.
• Ein IPv6-Subnetz erlaubt schöne Setups mit eigener IP pro Dienst und IP-basierten VHosts auf dem Webserver. Leider ist’s nur bedingt praxistauglich wenn man nur eine vintage IP Adresse hat und auch darüber erreichbar sein möchte.
• Mangels sinnvoller x.509-Infrastruktur benutze ich jetzt einfach weiter quasi-selbstsignierte Zertifikate. Wer’s über einen zweiten Kanal haben möchte findet das Zertifikat auch auf dem Studi-Server (SHA1 Fingerprint=­91:1B:DF:13:­F7:EF:E6:68:­E5:ED:27:39:­74:D2:46:B7:­8B:66:A8:44).
• Weder nginx noch lighttpd scheinen Authentifizierung mittels x509-Zertifikaten zu können (Zertifikat überprüfen geht anscheinend noch, aber das testen einzelner Einträge dann schon nicht mehr). Um schnell einen Webserver aufzusetzen würde ich weiterhin den Apache nehmen.
• Es ist garnicht so einfach SpamAssassin in Betrieb zu nehmen… es dauert echt lange bis die 200 Spam-Mails zusammenkommen, die man so als Grundlage für den Bayes-Filter braucht.

Today both memory and disks are cheap enough to make this question insignificant in many cases. One can usually buy enough memory to prevent swapping, and with terrabyte disks it makes no real difference whether the swap partition is 1 Gb or 4 Gb in size.

I still use the old rule of thumb and allocate twice the size of RAM for a swap partition. But the intention is not so much to swap memory pages but rather to always have enough space for kernel core dumps. My basic reasoning is:

1. In case of kernel errors I want to get a core dump.
2. A later RAM upgrade is relatively cheap and easy, thus probable over a system’s lifetime.
3. A later disk re-partitioning is more difficult, thus to avoid.
4. Disk space is cheap, allocating ≤ 5% for a mostly unused swap partition has no significant cost.

2011-11-19T01:31:21 frodo kernel: pid 47812 (try), uid 0: exited on signal 10 (core dumped)

Source of the program is Perl’s Configure script, which compiles its C library test cases into programs named try. And apparently amd64 systems need to use the function va_copy() because the test case without this function leads to a segfault.

Für brauchbare Statistiken müsste man noch einen Arbeitstag rein­stecken (Ein- und Ausgang trennen, PC/Server-Traffic unterscheiden, IPv6-Bias durch Neighbor Discovery rausfiltern, die verlorenen Messpunkte am 8.6. wiederherzaubern ;). Aber bunte gnuplot-Graphen sind ja auch für sich immer schön.

Ich würde ich die Verteilung auch gerne kontinuierlich erfassen, aber der benutzte Switch möchte mir per SNMP leider nicht mitteilen welche Protokolle er so weiterleitet. “Wenn mal Zeit ist” muss ich nochmal den MIB durchsuchen…

Noch was zur Datenerfassung: Die Anleitung “Using Wireshark to Create Network-Usage Baselines” zu tcpdump und tshark ist hilfreich. Leider schreibt tshark keine Unix-Zeitstempel in seine Ausgabe — die müssen noch per Skript ergänzt werden.

[Update:] Die Daten „großer“ Anbieter sind natürlich auch interessant. Igor Gashinsky von Yahoo berichtete auf der NANOG52 vom IPv6-Tag und stellt fest: “That was a lot of work for 0.229%!”

Mit der Kombination musste ich letztens feststellen dass sich das benutzte Hash-Verfahren für X.509-Zertifikate änderte:

> /usr/bin/openssl version ; 
/usr/local/bin/openssl version
OpenSSL 0.9.8q 2 Dec 2010
OpenSSL 1.0.0d 8 Feb 2011
> /usr/bin/openssl x509 -noout -hash -in astaca.pem ; 
/usr/local/bin/openssl x509 -noout -hash -in astaca.pem
a3a544f7
aff0606f

Das führte dann dazu dass eine Anwendung meine (im CApath-format hinterlegte) CA nicht benutzen wollte, obwohl beim ausführlichsten Test mit openssl {verify,s_client|s_server} alles bestens funktionierte. :-/

Als eigentliches Problem entpuppte sich letztlich ein falscher $PATH:

> which openssl
/usr/bin/openssl

Der insofern ‘falsch’ ist als dass die Anwendung halt gegen die nachinstallierte v1.0 in /usr/local gelinkt ist. Aber darauf muss man erstmal kommen… ein Test mit /usr/local/bin/openssl verify hätte echt viel Zeit gespart.