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.

M0n0wall: I have already used this as a NAT router and liked the web-based configuration (which I percieved as convenient but not limiting), so it was the first candidate. But I found it to be ‘too small’ for my plans. It allows neither the installation of additional software, nor does it allow ssh login for scriptable configuration changes. It also does not use pf, which I tend to prefer for its concise configuration and dynamic tables.

pfSense: M0n0wall’s big brother; bigger, more complete, and more customizable. But with one major problem: no IPv6 support. It is 2010, with only 1-2 years until the IPv4 address pool exhaustion… deploying network infrastructure without IPv6 support is ridiculous and not an option. – Another problem seems to be a limited support for bridge setups: There are always a number of standard pf rules, which are hard to circumvent in case of problems. I nearly settled to use the web-interface for IPv4, and insert my own IPv6 rules into the PHP scripts. But this would have made it even harder to maintain than a solution without any web-interface.

NanoBSD: So I finally took the chance to build my own small FreeBSD system for the task. NanoBSD is basically a script to do a FreeBSD ‘make world’, allow for some customization, and finally put everything into a CF-ready disk image. Of course the first attempt required several changes after installation (it’s really hard to think of all configuration steps beforehand), but everything went well without major problems.

Thus I chose NanoBSD. YMMV, and I would not recommend it for anyone not familiar with BSD. – But with four other BSD servers the additional maintenance effort is really small; possibly even easier than with any non-standard or web-based configuration.

[Update, 2011-02-24: If you use NanoBSD yourself then take a look at the useful scripts and patches from BSDRP.]

I like the new logo for Mailman.

To extract single DB dumps from a complete dump find the line numbers where the single DB dumps start. Then use sed to print only the lines from the start of the searched DB and the next one. mysqldump seems to use separate passes for data, stored routines, and triggers — so there may be multiple ranges of lines in a complete dump:

fgrep -n 'Current Database: ' dump_all.sql
sed -n -e '86226,93282p' -e '123249,123254p'
  dump_all.sql > db_test.sql

diff loads the files it works on into memory, thus it cannot be used for large files (>= 1Gb). To extract multiple DBs or to compare dumps it is useful to split the SQL dump at DB boundaries:

split -p 'Current Database: ' dump_all.sql

The resulting partial files can be renamed/concatenated to one file per DB (using tcsh syntax here):

foreach f ( x?? )
  set dbname=`head -1 $f
  | sed -e 's/^-- Current Database: .(.*).$/1/'
    -e 's/^-- MySQL dump.*$/dumpheader/'`
  test $dbname && cat $f >> part-${dbname} && rm $f
end

If we did this with two SQL dumps in $dir1 and $dir2, then we can compare them chunk by chunk (assuming every DB on itself is small enough to fit into memory for diff):

foreach f ($dir1/part-*)
  diff --ignore-case --ignore-space-change
    --ignore-blank-lines -u
    $dir1/$f $dir2/$f >> /tmp/diff.out
end