[Sat Apr 21 21:38:26 2012] [warn] [client 88.65.186.160] mod_fcgid: can't apply process slot for /home/webX/trac/htdocs/favicon.ico
[Sat Apr 21 21:42:01 2012] [warn] [client 66.249.66.247] mod_fcgid: read data timeout in 40 seconds
[Sat Apr 21 21:42:01 2012] [error] [client 66.249.66.247] Premature end of script headers: trac.fcgi

The cause I finally discovered was that I had mixed up several ways of running Trac (mod_python, mod_fastcgi, mod_fcgid) while testing performance, so the lines in my Trac vhost looked like this (including the disabled lines):

<VirtualHost x.y.z.w:80>
	ServerName domain.org
	ServerAlias www.domain.org
 
	DocumentRoot /home/webX/trac/htdocs
	Alias /chrom/common /usr/share/pyshared/trac/htdocs
	Alias /chrome/site /home/webX/trac/htdocs
	Alias /favicon.ico /home/webX/trac/htdocs/favicon.ico
 
	<Directory "/usr/share/pyshared/trac/htdocs">
		Order allow,deny
		Allow from all
	</Directory>
	<Directory /home/webX/trac/htdocs>
		Order allow,deny
		Allow from all
	</Directory>
 
	ScriptAlias / /home/webX/trac/fcgi/trac.fcgi/
#	<Location />
#		SetHandler fcgid-script
#		Options ExecCGI
#		Allow from all
#	</Location>
 
	<Location "/login">
		AuthType Basic
		AuthName "Trac"
		AuthUserFile "/home/webX/trac/passwd.htaccess"
		Require valid-user
	</Location>
 
	CustomLog /var/log/apache2/domain.org.access.log combined
	ErrorLog /var/log/apache2/domain.org.error.log
</VirtualHost>

Removed the superfluous <Location /> - Block and trouble was gone

Ohne manche der mit [Fix] markierten Schritte hätten einige Dienste übrigens garnicht oder mit unschönen Nebeneffekten funktioniert, weshalb ich vom Installations-Image meines Providers auch ziemlich enttäuscht war - da hätte ich es besser selbst aufgesetzt  Als Distribution kam bei mir Debian 6.0.4 Squeeze zum Einsatz.

Hinweis: Irren ist menschlich, alle hier vorgestellten Schritte erfolgen auf eigene Gefahr! Backups sind Gold wert!

Upgrade

Bei mir war ein Upgrade auf die aktuelle Version 3.3.9 erforderlich, wer einen Guide sucht kann hier fündig werden.

[Security] MySQL-Accounts ändern

Das Wichtigste zuerst: unbedingt alle mit Confixx in Verbindung stehenden Passwörter überprüfen. Bei meinem Setup war doch tatsächlich als Passwort für den MySQL-root 'T' (ja, der Buchstabe 'T') gesetzt! Und das bei einem standardmäßig über PHPMyAdmin von außen erreichbaren Dienst!

Ich habe einen separaten MySQL-Benutzer für Confixx erstellt und ihm entsprechende Rechte gegeben. Anzufassen sind folgende Configs:

• <confixx-install-dir>/confixx_main.conf: ab Zeile 547
• /var/www/confixx/settings.inc.php: Werte aus der confixx_main.conf übertragen
• /etc/spamassassin/local.cf (wird aber sowieso neu generiert)

[Fix] Mail-Aliase behalten

Diverse Pakete legen eigene Benutzer an und tragen diese in die /etc/aliases ein, z.B. logcheck. Dumm nur, dass Confixx die /etc/aliases periodisch (bzw. bei jeder Änderung an Postfächern) neu schreibt, und zwar "dumm" nach einem eigenen Template, was die neuen Benutzer nicht reflektiert.

Hier ist also dauerhaft Handarbeit angesagt: neue System-Aliase oder eigens angelegte müssen in die <confixx-install-dir>/safe/aliases_header aufgenommen werden, um nicht verloren zu gehen.

[Fix] Spamassassin

Ohne Nachbessern war bei mir Spamassassin nicht funktionstüchtig. Ich habe einen separaten Benutzer für den spamd angelegt:

$ groupadd -g 5001 spamd
$ useradd -u 5001 -g spamd -s /usr/sbin/nologin -d /var/lib/spamassassin spamd
$ mkdir /var/lib/spamassassin
$ chown spamd:spamd /var/lib/spamassassin

Dann die Startoptionen für den Daemon korrigieren:

# /etc/default/spamassassin
(...)
OPTIONS="--create-prefs --nouser-config --max-children 5 -H /var/lib/spamassassin -u spamd -q"
(...)

[Fix] AWStats

AWStats muss scheinbar das 10-Minuten-Update als root durchführen, daher unter /etc/cron.d/awstats beim oberen Eintrag den Benutzer auf root ändern. Das habe ich allerdings nicht näher untersucht, also besser selbst nochmal checken.

[Fix] Apache "other vhosts" log

Da Confixx für jeden Vhost nur ein Custom-Log über eine Pipe setzt (/etc/apache2/confixx_vhost.conf), bewirkt die Direktive in /etc/apache2/conf.d/other-vhosts-access-log, dass jeder (!!) Zugriff auf irgendeinen Vhost unter /var/log/apache2/other_vhosts_access.log vermerkt wird. Das lässt das File je nach Auslastung des Servers extrem schnell wachsen, man sollte die Option also der Performance und des Plattenplatzes zuliebe besser auskommentieren.

[Fix] Postfix SASL authentication

Abgesehen von einer komplett überarbeiteten main.cf musste ich für Postfix noch die SASL-Authentifizierung fixen, was praktischerweise in der /etc/default/saslauthd schon vorgesehen ist:

# Example for postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"

Details siehe /usr/share/doc/sasl2-bin/README.Debian.gz.

Das wars erstmal mit den wichtigsten Nachbesserungen. Confixx in eine eigene Subdomain zu sperren und das Vhost-Schema dauerhaft zu ändern war nochmal eine ganz eigene Angelegenheit - vielleicht dazu demnächst ein HowTo.

• create a random-filled file, sync it to disk
• determine the LBAs the file resides in using hdparm --fibmap [file]
• pick one sector, raw-read it with hdparm --read-sector [sector] [device]
• delete the random file, sync again
• verify TRIM was issued by reading the same block again, should return only zeroes

The problem with all these guides is that they don't say anything about the influence partitioning and other layers like LVM can have on the right LBA to use with hdparm --read-sector.
You must add any offsets resulting from either other partitions or payload-offsets from LVM, LUKS and thelike to the address you got from hdparm --fibmap!

I'll explain the concrete steps using my setup:

[alex@thor ~]$ fdisk -l /dev/sdd
 
Disk /dev/sdd: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xddfc7af4
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *        2048     1050623      524288   83  Linux
/dev/sdd2         1050624   250069679   124509528   8e  Linux LVM

The PV our target LV resides on starts at sector 1050624, which is our first offset.

[alex@thor ~]$ dmsetup table
root-plain: 0 56619008 crypt aes-xts-plain [keyslot] 0 254:0 4096 1 allow_discards
m4vg0-root: 0 55050240 linear 8:50 2048
(...)

Here we can see that LVM has a payload offset of 2084 bytes and LUKS (dm-crypt) one of 4096 bytes (fits well for an SSD).

[alex@thor usr]$ hdparm --fibmap testfile
 
testfile:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     272600     272607          8

So finally we calculate the "real" address of our chosen sector (the first one) by 272600 + 1050624 + 2048 + 4096 = 1329368.

Happy TRIM-testing, and keep in mind the implications for crypto-recurity!

Mit folgenden Zeilen schaffe ich es im Idle auf 42°C und einen gelegentlich inaktiven Lüfter:

# /etc/rc.local
# set governor
cpufreq-set -g ondemand -c 0
cpufreq-set -g ondemand -c 1
 
# disable bluetooth
echo disable > /proc/acpi/ibm/bluetooth
 
# set brightness level
echo 6 > /sys/class/backlight/acpi_video0/brightness
 
# set vm laptop-mode
echo 5 > /proc/sys/vm/laptop_mode
 
# increase vm dirty writeback time
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
 
# set SATA link power management
for D in /sys/class/scsi_host/host*/link_power_management_policy; do
	echo min_power > $D
done
 
# disable kernel nmi watchdog
echo 0 > /proc/sys/kernel/nmi_watchdog
 
# set pci/i2c bus power management
for I in /sys/bus/{pci,i2c}/devices/*/power/control; do
    echo auto > $I
done
 
# enable scheduler power saving
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings

In der Kernel-Line im Bootloader noch folgende Parameter:

pcie_aspm=force i915.i915_enable_fbc=1 i915.i915_enable_rc6=1

Ein Bash-Script, das Platten bei Inaktivität nach definierbarem Timeout per hdparm -y in Standby schickt. Für mich sehr nützlich bei SATA-Platten, die sich nicht per hdparm -S konfigurieren lassen.

Gehostet wie immer auf github, oder direkt hier:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#!/bin/bash
 
#
# Automatic disk standby using kernel diskstats and hdparm
#
# Version 1.1, 2011 by Alexander Koch <lynix47@gmail.com>
#
 
 
# DEVICES syntax: DEVICE:TIMEOUT_SEC
DEVICES=( "sda:120" "sdb:120" )
 
function device_worker() {
	test -e "/dev/$1" || return 1
	logger -t hdd-spindown.sh "spawned monitor thread for $1"
	COUNT_R=0
	COUNT_W=0
	while true; do
		NEW_R=$(awk '{print $1}' /sys/block/$1/stat)
		NEW_W=$(awk '{print $5}' /sys/block/$1/stat)
		if [ $COUNT_R -eq $NEW_R ] && [ $COUNT_W -eq $NEW_W ]; then
			if hdparm -C /dev/$1 | grep active &>/dev/null; then
				logger -t hdd-spindown.sh "suspending $1"
				hdparm -qy /dev/$1
				if [ $? -gt 0 ]; then
					logger "failed to suspend $1"
					return 1
				fi
			fi
		else
			COUNT_R=$NEW_R
			COUNT_W=$NEW_W
		fi
		sleep $2
	done
}
 
for D in ${DEVICES[@]}; do
	device_worker $(echo "$D" | cut -d ':' -f 1) $(echo "$D" | cut -d ':' -f 2) &
done
 
exit 0

Auf Performance-Optimierungen habe ich bewusst verzichtet und alles möglichst simpel gehalten.

Funktionsbedingt ist der einstellbare Wert für den Timeout (T) übrigens nicht hart; die reale Zeit an Inaktivität t_i genügt der Bedingung T ≤ t_i < 2T.

In diversen Wikis werden die unterschiedlichsten Methoden beschrieben, das von Lenovo bereitgestellte CD-Image ohne optisches Laufwerk und mit Linux-Bordmitteln gebootet zu bekommen. Mit der gängigsten Methode (syslinux) bekam ich jedoch nur einen kompletten Freeze (nebst verbundenem Schreck).

Funktioniert hat mit meinem X220 die Variante Using grub4dos. An den Temperaturen hat das soweit ich sagen kann aber nichts geändert.

Die Wahl viel nicht auf eine aktuell recht günstig zu habende OCZ Vertex 2, da der SandForce Controller seine spezifizierten Transferraten nur durch hardwareseitige Kompression erreicht, und bei verschlüsselten oder bereits komprimierten Daten stark einbricht. Die Crucial-SSDs (M4 ebenso wie ihr Vorgänger C300) nutzen Marvel Controller und "tricksen" nicht durch Kompression.

Verschlüsselung und TRIM-Support

Bei Verwendung von SSDs ist der TRIM-Support entscheidend für Lebensdauer und Performance. Auf meinen HDDs verwende ich überall FDE mit LUKS (dm-crypt), was allerdings leider erst ab Kernel 3.1 TRIM unterstützen wird. Das neue Kernel-Release wird wohl erst im Oktober erscheinen; außerdem fehlt noch Userspace-Support für TRIM in cryptsetup.

Da für mich die Verschlüsselung der Daten unverzichtbar war, ein Unlocking per Login aber ungünstig finde (cron-jobs...), habe ich nun eine Hybridlösung im Einsatz: die Rootpartition (~1,2GB) bleibt weiterhin LUKS-verschlüsselt, während ich für /home auf Verschlüsselung auf Dateiebene zurückgreife. Wegen der vielen Berichte über miese Performance von EncFS (irgendwie einleuchtend wegen der vielen user<->kernel switches) habe ich mich für das in-kernel implementierte eCryptfs entschieden.

eCryptfs für /home

Wer LUKS gewöhnt ist, der hat mit eCryptfs am Anfang einige Umgewöhnung vor sich, denn eCryptfs arbeitet deutlich anders. Zum groben Setup habe ich mich an einem HowTo orientiert, allerdings lasse ich mein eCryptfs-Volume nicht beim Login über PAM mounten, sondern automatisch über /etc/rc.local (ist wegen blockverschlüsseltem root kein Problem).

Dazu habe ich die Passphrase in eine Datei unter /etc gepackt und nutze diese Zeile in der fstab:

# /etc/fstab
 
(...)
 
/home.crypt /home ecryptfs rw,verbosity=0,ecryptfs_sig=XYZ,ecryptfs_passthrough=n,key=passphrase,passphrase_passwd_file=/etc/vol.key,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_fnek_sig=XYZ,ecryptfs_unlink_sigs  0 0

Benchmarks

Nun zum titelgebenden Inhalt: Benchmarks
Natürlich wollte ich wissen, wie viel Performance ich durch die SSD gewinne, bzw. welcher Anteil davon durch die Verschlüsselung wieder flöten geht.

Gemessen habe ich die Transferraten beim Lesen bzw. Schreiben einer 1GB-Datei per dd:

[alex@thor bench]$ LC_ALL=C dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 10.7813 s, 99.6 MB/s
[alex@thor bench]$ sudo su -c "echo 3 > /proc/sys/vm/drop_caches"
[alex@thor bench]$ LC_ALL=C dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.583 s, 79.1 MB/s

Als Dateisystem kam überall ein korrekt align'tes EXT4 zum Einsatz, mit aktivierter discard-Option wo möglich. Darunter lag über dem physischen Layer noch ein ebenfalls sorgfältig eingerichtetes LVM. Zum Vergleich habe ich auch noch mein Software-RAID1 (Blogpost folgt) auf zwei herkömmlichen HDDs (WD Caviar Green WD20EARS) getestet, wo ebenfalls EXT4 auf LUKS auf LVM zum Einsatz kommt.

Wie man sehen kann erreicht die SSD zwar nicht ganz ihre Datenblatt-Werte, aber da diese sowieso immer recht utopisch sind und ich die Platte nur an einem SATAII-Port hängen habe, bin ich mit den Transferraten für unverschlüsselte Dateisysteme zufrieden.

Alle Werte für verschlüsselte Dateisysteme zeigen einen Performanceverlust, der beim Lesen deutlich größer ist als beim Schreiben - darüber muss ich noch nachdenken
Hier geht es mir aber um den Vergleich LUKS-eCryptfs, der deutlich zu Gunsten von LUKS ausfällt.

UPDATE: LUKS+TRIM, Mehr Benchmark

Hier noch ein überaus interessanter Artikel zu Folgen von TRIM auf dm-crypt Volumes aus kryptographischer Sicht.

Außerdem noch ein Screenshot des Disk-Benchmarks palimpsest (ehemals Teil des gnome-disk-utilitiy), der die Transferraten auf der unformatierten M4 (nach Firmware-Update) zeigt:

Entgegen einiger Forenbeiträge ließ er sich jedoch mit etwas Basteleinsatz (Kabel trennen und neu verbinden, Klemme irgendwo unterbringen) durch einen alten Papst-Lüfter ersetzen, der hier noch rumlag.

Ergebnis: himmlische Ruhe...

Mir hat das gerade eine Brücke zwischen xbindkeys und Exaile geliefert, um per Multimediatasten den Player zu steuern:

# ~/.xbindkeysrc
 
"dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.PlayPause"
  XF86AudioPlay
 
"dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.Next"
  XF86AudioNext
 
"dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.Prev"
  XF86AudioPrev

Das Problem verursachte das aktivierte Power Saving feature des verwendeten Moduls snd_hda_intel. Hier sind zwei Parameter relevant:

• power_save: setzt den Timeout für den Power Saving Modus
  (in Sekunden, 0=deaktiviert)
• power_save_controller: Schaltet im Power Save auch den Controller ab
  (Y=aktiviert, N=deaktiviert)

Der zweite Parameter wird unter Arch standardmäßig auf Y gesetzt, was einen tieferen Schlaf für den Soundchip, aber auch eine dementsprechend längere Aufwachphase bewirkt. Durch Deaktivieren dieses Features konnte ich mein Problem mit den Benachrichtigungen lösen.

Übrigens: in der /etc/conf.d/alsa wird leider nicht ganz deutlich, dass über POWERSAVE direkt der Timeout-Wert gesetzt wird, d.h. es sind auch Werte >1 zulässig:

# Enables powersaving mode for AC97 and hda_intel audio chips.
# Set to 1 to enable powersaving.
# Set to 0 to disable powersaving (default).
POWERSAVE=10