trac on apache2 with mod_fcgid: can’t apply process slot
Recently had some serious trouble running Trac on Apache2 with mod_fcgid. An included Doxygen-page spent hours loading and the Apache error log contained lines like this:
[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 
Confixx Setup nachbessern
An einem frisch per Virtualisierungs-Container installierten Confixx schraubt man üblicherweise an ein paar Stellen herum, um das Panel abzusichern. Bei einem kürzlich von mir durchgeführten Server-(Provider-)Wechsel war diesmal jedoch so viel Handarbeit nötig, dass ich diese hier mal kurz festhalten möchte.
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.
Testing TRIM with LUKS on LVM
One can find many guides on the net on how to test TRIM using dd and hdparm, which all describe the same procedure:
- 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 8So 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!
Thinkpad X220 Power Saving
Das Thinkpad X220 leidet wie alle Rechner mit SandyBridge-Grafik (Intel HD 3000) an den Auswirkungen der aktuellen Kernel Power Regressions (siehe hier und hier), was zu CPU-Temperaturen über 50°C (idle!) und permanent relativ hoch drehendem Lüfter führt.
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
hdd-spindown.sh
Mal wieder Zeit gefunden, einen schon leicht angestaubten Punkt auf meiner 2code-Liste abzuhaken:
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 ti genügt der Bedingung T ≤ ti < 2T.
Thinkpad X220: BIOS Update
Mein kürzlich erstandenes Thinkpad X220 leidet unter den mit aktuellen Kerneln (~2.6.38 - 3.0.4) auftretenden Hitzeproblemen (Post folgt). Mit einem BIOS-Update soll sich laut Lenovo das Lüfterverhalten verbessern - Grund genug 
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.
SSD Encryption Benchmark
Kürzlich konnte ich dem allgemeinen Hype um SSDs nicht mehr widerstehen und habe das lästige Brummen meiner Systemplatte durch die Stille einer Crucial M4 mit 128GB ersetzt.
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:
DBus durchsuchen
Wer den DBus durchsuchen möchte, um schnell herauszufinden, welche Calls eine bestimmte Anwendung anbietet, dem könnte DBusExplorer sehr nützliche Dienste tun.
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
ALSA Power Saving unter Arch
Nach dem Wechsel der Soundkarte zurück auf die Semi-Onboard-Lösung hatte ich ein kleines Soundproblem: kurze Sounds (Mail-Benachrichtigungen, Chat-Töne, etc.) wurden gar nicht oder nur teilweise abgespielt - es fehlten oft die ersten Millisekunden.
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
ALSA: Best Config is No Config
Nach einigen Problemen mit dem angelöteten Frontpanel-Ausgang an meiner guten, alten Audigy 2 musste ich nun doch zurück zur Semi-Onboard-Lösung greifen und habe die beim Board mitgelieferte Pseudo-X-Fi eingebaut. Da das Teil kein Hardware-Mixing unterstützt musste ich meine /etc/asound.conf bearbeiten, um korrektes Upmixing inkl. dmix zu bekommen.
Das Erstaunliche dabei: es funktioniert am besten gänzlich ohne /etc/asound.conf
Out-of-the box, inkl. korrektem Upmixing von Stereo auf 5.1. Hier also der Tip bei Problemen mit aktuellem ALSA und vorhandener Config: vielleicht einfach mal ohne probieren...