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.

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.]

Depending on the number of events the step has to be adjusted. The arguments to cut determine the used time intervals; the above aussumes a traditional BSD Syslog timestamp and will yield daily counts. For hourly counts one can use cut -d : -f 1 (then the print command has to be changed as well to printf $2, $3, $4, bar;) — for Syslog-Protocol timestamps one can use cut -d T -f 1 or cut -d : -f 1. Note that only intervals with matches are shown, there is no easy way to add empty lines.

Example:

[mschuett@mail] /var/log> fgrep -h 'idle for too long, closing connection' cyruslog | cut -d T -f 1 | uniq -c | awk '{step=10; bar = ""; for(i = $1; i>=1; i = i-step) bar = bar "#"; print $2, bar; }'
2010-03-01 ########################
2010-03-02 ################################
2010-03-03 #####################
2010-03-04 ##############################
2010-03-05 #################################
2010-03-06 ######################
2010-03-07 ###########################
2010-03-08 #####################
2010-03-09 ###################
2010-03-10 #####################
2010-03-11 ##################

Plakat der Chemnitzer Catering-Tage (Photo: Roman Hanhart)

Gerade wieder zurück von den Chemnitzer Linux-Tagen 2010.

As a demonstration you can now access this site with https. The only drawback: Internet Explorer on WindowsXP and KDE’s Konqueror do not support the TLS extension but show a certificate error.

Another small but nice feature is the new piped log syntax to launch a process without invoking the shell. On a shared server with about twenty VHosts and all of them logging slightly differently to pipes and syslog this saves a few unnecessary processes.
Update to give an example: My httpd.conf now contains these lines for logging

CustomLog "||/usr/bin/logger -p local2.info -t apache" complete
ErrorLog "||/usr/bin/logger -p local3.info -t apache"

Just one note about updating: OpenSSL (and its FreeBSD port) does not use the TLS extension by default. — One has to configure it with option enable-tlsext (for the port: change the Makefile so it contains the line “EXTRACONFIGURE+= enable-camellia enable-tlsext”).

Die Installation lief problemlos und nach zwei Anläufen waren auch beide Monitore richtig eingestellt. Meine Probleme begannen dann aber am zweiten Tag als ich diverse eigene Programme aus den Ports installierte. Wichtigstes (und umstrittenstes) Merkmal von PC-BSD ist nämlich das PBI-Paketsystem, bei dem Programme mit allen Abhängigkeiten zusammen gebündelt werden (ist dann in der Installation/Benutzung so ähnlich einfach wie unter OSX). Hätte ich vorher in die Doku geschaut, dann hätte ich gesehen dass die PBI-Programme in den default-Pfaden liegen und für die Installation und Benutzung der Ports erst der Modus gewechselt werden muss. Hab ich aber nicht gelesen; und daher war nach zwei Tagen alles schon so vermischt, dass ich keine Ports mehr installieren konnte (weil falsche Pfade und Abhängigkeiten benutzt wurden). Einen Tag später hab ich mir dann halt das FreeBSD-7.2-Release genommen und neuinstalliert.

An sich gefällt mir PC-BSD (und auch das PBI) gut; ich würde es vielleicht für administrierte Büro-PCs einsetzen, bei denen klar ist welche Programme benötigt werden und dann nur PBIs installiert werden müssen. Auf meinem eigenen Rechner entwickle/teste/spiele ich aber zu viel mit zu vielen verschiedenen Programmen (zur Zeit habe ich fast 700 Ports installiert). — Dabei sind die PBIs und die extra-Verzeichnisse dann nicht nur überflüssig sondern sogar störend.

BSD Stand@Linuxtag 2009 (Bild des LinuxTag e.V.)

Die letz­te Woche habe ich auf dem Linux­Tag ver­bracht, spe­ziell am BSD-Stand dort.

Eine kurze Nach­lese in Stich­worten; ich habe:

• viel nettes Spielzeug gesehen (z.Bsp. ein MIPS-Netbook und ARM-Boards),
• nicht live bloggen können weil’s am Stand kein WLan gab,
• mal wieder das Keysigning verpasst,
• mir eine Erkältung eingefangen,
• die Verpflegung etwas dürftig gefunden,
• immerhin einen Vortrag komplett gehört,
• vier Tage als zu lang empfunden — zwei würden auch reichen.