Kategorie-Archiv: linux

btrfs auf LUKS mit systemd

Veröffentlicht am von — Keine Kommentare ↓

Systemd scheitert momentan noch am Erkennen der Abhängigkeiten von multi-volume btrfs Dateisystemen auf LUKS-Basis.

Mein aus vier LUKS-Volumes (btrfs-RAID1) bestehendes Archiv wird in der /etc/fstab so eingebunden:

/dev/mapper/archive1	/mnt/archive	btrfs	device=/dev/mapper/archive1,device=/dev/mapper/archive2,device=/dev/mapper/archive3,device=/dev/mapper/archive4,defaults,noatime,nodiratime	0 0

systemd erkennt dabei allerdings nur die Abhängigkeit zu /dev/mapper/archive1, und versucht es folgerichtig schon nach dessen Auftauchen einzubinden, was oft fehlschlägt weil die restlichen Volumes noch nicht angelegt sind.

Bis zu einem Upstream-Fix hilft ein manuelles .mount-File für den entsprechenden fstab-Eintrag, also in meinem Fall /etc/systemd/system/mnt-archive.mount:

[Unit]
Description=/mnt/archive
Wants=cryptsetup.target
After=cryptsetup.target
 
[Mount]
What=/dev/mapper/archive1
Where=/mnt/archive
Type=btrfs
Options=defaults,noatime,nodiratime

(Der Dateiname ist hier wichtig, da er das automatisch aus der fstab generierte .mount-File überlagern muss!)

EDIT: Ab munin-node-2.0.4-1 ändert sich u.A. der Pfad zum Binary, daher muss das .service-File angepasst werden:

[Unit]
Description=Munin Node Service
After=syslog.target network.target
 
[Service]
Type=forking
PIDFile=/run/munin/munin-node.pid
ExecStart=/usr/bin/munin-node
 
[Install]
WantedBy=multi-user.target

munin-node mit systemd

Veröffentlicht am von — Keine Kommentare ↓

Für den Betrieb von munin-node unter systemd sind die folgende Service-Unit und ein Eintrag in /etc/tmpfiles.d nötig:

/etc/systemd/system/munin-node.service:

[Unit]
Description=Munin Node Service
After=syslog.target network.target
 
[Service]
Type=forking
PIDFile=/var/run/munin/munin-node.pid
ExecStart=/usr/sbin/munin-node
 
[Install]
WantedBy=multi-user.target

/etc/tmpfiles.d/munin-node.conf:

D /var/run/munin 0755 munin munin -

Linux-Moderne: systemd, journald und kein syslog-ng

Veröffentlicht am von — Keine Kommentare ↓

Lange Zeit (zwei Jahre, 5 Monate und 6 Tage laut /var/log/pacman.log) war ich mit meinem klassischen Setup zufrieden: SysVinit als init-System, syslog-ng als Logger, soweit es geht kein PolicyKit, ConsoleKit, Avahi und all dieses moderne Zeug – alles Schnickschnack! ;)

Aber so ganz will ich mich der Neuerungen dann doch nicht verschließen und so begann ich kürzlich damit, mich über systemd zu informieren (angeregt nicht zuletzt durch den Talk auf der GPN12).
Weil ich mit den Bootzeiten meiner Box trotz SSD nicht zufrieden war (und schon länger mal plymouth ausprobieren wollte) wagte ich dann den Vorstoß und confte mein System auf systemd um (hauptsächlich nach Arch-Wiki).

Tja was soll ich sagen, ~11 Sekunden Bootzeit statt ~35 – das liegt deutlich im spürbaren Bereich (zumindest für Nerds wie mich ;) ). Auch aus technischer Sicht macht es absolut keinen Sinn, auf Parallelisierung zu verzichten: warum sollen sich drei von vier CPU-Kernen langweilen, wenn durch die SSD mehr als genug I/O-Bandbreite für ein parallelisiertes Startprozedere zur Verfügung stünde? Die Verwendung von cgroups und (x)inetd-ähnliches Verhalten bilden dann das Sahnehäubchen bei der Verwendung von systemd gegenüber traditionellen init-Systemen.

Etwas schwierig gestaltete sich dabei das Einbinden meines Ramdisk-Scripts und das korrekte Mounten einer multi-Volume btrfs-Partition auf LUKS-Basis – zu beidem folgen separate Beiträge.

Wo ich schon am Über-Bord-werfen von alten Standardkomponenten war kam mir das Konzept vom systemd-Journal gerade recht: warum eine SSD mit unzähligen Schreiboperationen für persistente Logs belasten? Ich kam ins Grübeln, zu welchen Zwecken ich meine Syslogs verwende: eigentlich nämlich nur zum Erkennen von Laufzeitproblemen (Kernel, Dienste) durch Parsen über logcheck, und abundzu mal zum Recherchieren von Aktionen der Paketverwaltung (/var/log/pacman.log). Mir fiel kein einziger Fall ein, in dem ich die Logs vergangener Tage zu Rate gezogen hätte.
Das Pacman-Log wird nicht über den System-Logdienst geschrieben und ist damit unabhängig, also wagte ich mit dem Wechsel zum systemd-eigenen Journal (journald) mit nicht-persistenten Logs (ich weiß, die kann man auch persistent machen) einen weiteren Versuch.

Die Zeit wird zeigen, welche langfristigen Änderungen sich dadurch ergeben – ich werde berichten. Eine schon jetzt geborene Projektidee ist der Ersatz von logcheck durch ein mit journald kompatibles Tool auf Bash-Basis, mal schauen wann ich dafür Zeit finde :)

S100 Revival

Veröffentlicht am von — Keine Kommentare ↓

Kürzlich ergab sich der Bedarf nach einer möglichst günstigen Printserver-Lösung. Nach dem Durchschauen mehrerer USB-Ethernet-Adapter, die meist nur “mit ausgewählten Druckern voll kompatibel” sind, viel mir die gute alte S100 wieder ein, die in einer Hardware-Kiste im Keller eingemottet ihr Dasein fristete.

Da ich sowieso noch auf der Suche nach einem Backup-Target für zwei Server war habe ich das Teil also herausgekramt, mit einer Transcent IDE-SSD versehen (32GB, mittlerweile bezahlbar) und neu aufgesetzt – diesmal auf Debian-Basis.

Sie werkelt nun seit ein paar Wochen brav vor sich hin und ist mittlerweile Printserver, Munin-Node und -Master, Backup-Relay, SSH-Gateway und Mailserver für die lokale Domäne. Möglich wird das trotz des sehr knapp bemessenen Speichers des Geräts (128 MB, von denen noch Grafikspeicher entfällt) durch exzessiven Gebrauch von xinetd:

micro-httpd:

service http
{
	port            = 80
	socket_type     = stream
	wait            = no
	user            = root
	cps		= 100 5
	server		= /usr/sbin/micro-httpd
	server_args	= /var/cache/munin/www
	disable		= no
}

vsftpd:

service ftp
{
         socket_type    = stream
         wait           = no
         user           = root
         server         = /usr/sbin/vsftpd
         nice           = 10
         disable        = no
}

dovecot IMAPS:

service imaps
{
       disable         = no
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user            = root
       server          = /usr/lib/dovecot/imap-login
       flags           = IPv4
       server_args     = --ssl
}

Außerdem helfen die üblichen Maßnahmen: nicht genutzte Dienste des Standard-Setups deaktivieren (portmap, dbus, etc.), statisches Networking verwenden (spart einen DHCP-Client – jeder Prozess zählt! ;) ), nicht benötigte Kernelmodule blacklisten.

Die Kiste swapt zwar trotzdem regelmäßig und bei den meisten Druckaufträgen wird nach jeder Seite eine Gedenkpause von gut 10 Sekunden fällig, aber eine Embedded-Lösung mit Rums von der Stange macht doch nur halb so viel Spaß ;)

Einen neuen Anstrich bekam das Gehäuse dann auch noch – passt so besser ins HiFi-Rack.

Update: Die xinetd-config für munin-node scheint nur bei einer gepatchten Version für OpenWRT funktioniert zu haben, daher entfallen.

Update 2: Mailserver hinzugefügt.

DPF als Display an Fritz!Box 7270

Veröffentlicht am von — Keine Kommentare ↓

Mal wieder was zum Basteln gefunden :)

Ein gehackter LinkDelight 2.4″ DPF (Digital Picture Frame) dient jetzt als Status-Display meiner zirpenden und manchmal leider etwas empfindlichen Fritz!Box 7270.

Auf der Fritz!Box läuft bei mir Freetz, theoretisch sollte es aber genügen, das LCD4Linux-Binary nebst Config auf die Box zu kopieren und irgendwie zu starten – hat man keine alternative Firmware mit SSH-Zugang kann man dafür auch den ab Werk installierten (aber deaktivierten) Telnetd nutzen.

Hier noch meine LCD4Linux-Config:

Display dpf {
	Driver     'DPF'
	Port       'usb0'
	Font       '9x12'
	Foreground 'ffffff'
	Background '000000'
	Basecolor  '000000'
}
 
Display 'dpf'
 
 
Widget w_heading {
	class		'Text'
	expression	'=== FRITZ!BOX STATUS ==='
	align		'C'
	width		35
	update		0
}
 
Widget w_load {
	class		'Text'
	expression	loadavg(1)
	prefix		'Load'
	width		16
	precision	1
	align		'R'
	update		2000
}
 
Widget w_uptime {
	class		'Text'
	expression	uptime('%dd %H:%Mh')
	prefix		'Uptime'
	width		17
	align		'R'
	update		60000
}
 
Widget w_temp {
	class		'Text'
	expression	exec('ctlmgr_ctl r power status/act_temperature', 60000)
	prefix		'Temp'
	align		'R'
	width		16
	postfix		' C'
	update		10000
}
 
widget w_ram_txt {
	class		'Text'
	expression	'Mem'
	width		3
	update		0
}
 
Widget w_ram_bar {
	class		'Bar'
	expression	(meminfo('MemTotal')-(meminfo('MemFree')+meminfo('Buffers')+meminfo('Cached')))/meminfo('MemTotal')*100
	min		0
	max		100
	length		10
	direction	'E'
	background	'444444'
	update		5000
}
 
Widget w_sync_down {
	class		'Text'
	expression	exec('ctlmgr_ctl r sar status/dsl_ds_rate', 600000)
	prefix		'DSL'
	align		'R'
	width		16
	postfix		' kb/s'
	update		10000
}
 
Widget w_sync_up {
	class		'Text'
	expression	exec('ctlmgr_ctl r sar status/dsl_us_rate', 600000)
#	prefix		'DSL u'
	align		'R'
	width		16
	postfix		' kb/s'
	update		10000
}
 
Widget w_ontime {
	class		'Text'
	expression	'00:00'
	prefix		'Online'
	align		'R'
	width		17
	postfix		' h'
	update		10000
}
 
Widget w_ip {
	class		'Text'
	expression	exec('get_ip', 600000)
	prefix		'IP'
	width		16
	align		'R'
	update		10000
}
 
Widget w_rate_down {
	class		'Text'
	expression	netdev::fast('adsl', 'Rx_bytes', 500)/1024
	prefix		'WAN d'
	postfix		' kB/s'
	align		'R'
	precision	0
	width		16
	update		1000
}
 
Widget w_rate_up {
	class		'Text'
	expression	netdev::fast('adsl', 'Tx_bytes', 500)/1024
	prefix		'WAN u'
	align		'R'
	precision	0
	width		16
	postfix		' kB/s'
	update		1000
}
 
Widget w_traffic_down {
	class		'Text'
	expression	netdev::fast('adsl', 'Rx_bytes', 0)/1048576
	prefix		'Vol d'
	align		'R'
	precision	0
	width		16
	postfix		' MB'
	update		10000
}
 
Widget w_traffic_up {
	class		'Text'
	expression      netdev::fast('adsl', 'Tx_bytes', 0)/1048576
	prefix          'Vol u'
	align           'R'
	precision       0
	width           16
	postfix         ' MB'
	update          10000
}
 
 
Layout mylayout {
	Row2 {
		Col1	'w_heading'
	}
	Row5 {
		Col1	'w_load'
		Col19	'w_ram_txt'
		Col25	'w_ram_bar'
	}
	Row7 {
		Col1	'w_temp'
		Col19	'w_uptime'
	}
	Row10 {
		Col1	'w_sync_down'
		Col19	'w_ontime'
	}
	Row12 {
		Col1	'w_sync_up'
		Col19	'w_ip'
	}
	Row15 {
		Col1	'w_rate_down'
		Col19	'w_rate_up'
	}
	Row17 {
		Col1	'w_traffic_down'
		Col19	'w_traffic_up'
	}
}

Alle Anzeigen bis auf die Online-Zeit sind funktionsfähig und erfordern keine Cron-Jobs o.Ä. wie die in den unten Artikeln genannten.

Warnung: Alle Modifikationen des DPF oder der Fritz!Box erfolgen auf eigene Gefahr!

Folgende Quellen fand ich hilfreich:

SPAM mit SPF und DKIM

Veröffentlicht am von — Keine Kommentare ↓

Kurz nach Aufsetzen von DKIM- und SPF-Filter auf meinem Mailserver nun ein enttäuschendes Novum: mich erreicht die erste SPAM-Mail mit SPF-legitimiertem Absender und valider Signatur:

Return-Path: <bounce@live-kameras.in>
X-Original-To: mail@alexanderkoch.net
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=46.167.40.90; helo=mail89.sysmessage.net; envelope-from=bounce@live-kameras.in; receiver=mail@alexanderkoch.net 
Authentication-Results: vserver3082.vserver-on.de; dkim=pass
	(1024-bit key; insecure key) header.i=@live-kameras.in;
	dkim-adsp=pass
Received: from mail89.sysmessage.net (mail89.sysmessage.net [46.167.40.90])
	by vserver3082.vserver-on.de (Postfix) with ESMTP id 8215A1A21DC
	for <mail@alexanderkoch.net>; Wed, 20 Jun 2012 22:06:01 +0200 (CEST)
Received: from localhost (mail89.sysmessage.net [46.167.40.90])
	by mail89.sysmessage.net (Postfix) with ESMTP id 7B80CED333A6
	for <mail@alexanderkoch.net>; Wed, 20 Jun 2012 21:46:36 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
From: Carola Gerber <carola@live-kameras.in>
To: mail@alexanderkoch.net
Subject: Kontaktanfrage
Message-ID: <1340221596.312.61884107@live-kameras.in>
Date: Wed, 20 Jun 2012 21:46:36 +0200
DKIM-Signature: v=1; a=rsa-sha1; s=c; d=live-kameras.in; l=180;
	t=1340221596; c=relaxed/relaxed;
	h=mime-version:content-type:content-transfer-encoding:from:to:subject:message-id:date;
	bh=PHke5WSAMx7YYOAPDF0i9PGyalA=;
	b=Scw49u8DJmqQ3FfNmqoukpaAvtg7+nif45MlE1Kqs8LSoMM8K96W5zJYg5TbLOpYBFRtYor8n6i/
	iJvPpU7sY1hwtBIpyeteus44NjV5HMZivINxQjs57hfhouN58zs5n5uN424Mid6qmbhK3cnxvXXL
	YFzc6ciq7OGm5iqipHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=live-kameras.in; s=c;
	h=mime-version:content-type:content-transfer-encoding:from:to:subject:message-id:date;
	b=CNcWdpqE/rnJRUra4YbpLf3lh8JsLQ2OcB4h/lc4JvHOrQiDcut8lYwxOpAqLvPcAlmmKPIMLLrv
	3kqHqbcGkO31n77gIhum1j9UQiJdwrKp5X7m5gmm0P8buFIs3Oju1ZzFYEy8rsC+Fv5pJ6eV9+Ui
	jnBNeS5bN44sO7BT9Mg=
 
Hallo,
 
m=F6chtest Du deutschen M=E4dchen live vor der Kamera zuschauen?
Das kannst Du hier: http://www.live-kameras.in/
 
Viel Spa=DF!
 
Liebe Gr=FC=DFe,
Carola / Cam-Team

Tja, auch Spammer rüsten auf ;)

Munin Plugin für postfix-policyd-spf-python

Veröffentlicht am von — Keine Kommentare ↓

Nachdem ich nach DKIM auch SPF auf meinem Mailserver aufgesetzt hatte (Paket postfix-policyd-spf-python) wollte ich natürlich auch sehen, welchen Effekt dieser zusätzliche Filter auf den Mailverkehr hat.

Wieder ein Grund zur Bash-Scripterei! :)  Folgendes kleine Plugin habe ich heute Morgen runtergehackt:

#!/bin/bash
#
#   Munin plugin to count postfix-policyd-spf-python results
#           2012 Alexander Koch <lynix47@gmail.com> 
# 
# Parameters understood:
#	config		(required)
#	autoconf 	(optional - used by munin-config)
# 
# Config variables:
#       logfile      - Where to find the postfix log (mail.log)
#
# Add the following line to a file in /etc/munin/plugin-conf.d:
# 	env.logfile /var/log/your/mail.log
#
# Magic markers (optional - used by munin-config and installation scripts):
#
#%# family=auto
#%# capabilities=autoconf
 
 
#
# Configuration
#
 
STAT_FILE=${STAT_FILE:-/var/lib/munin/plugin-state/plugin-plcyd-spf-python.state}
LOGFILE=${logfile:-/var/log/mail.log}
 
if [ "$1" = "autoconf" ]; then
	echo yes
	exit 0
fi
 
if [ "$1" = "config" ]; then
	echo 'graph_title SPF Check Results'
	echo 'graph_category postfix'
	echo 'graph_args --base 1000 -l 0'
	echo 'graph_vlabel Count/s'
 
	echo 'count_pass.label Pass'
	echo 'count_pass.type DERIVE'
	echo 'count_pass.min 0'
	echo 'count_pass.colour 00cc00'
	echo 'count_fail.label Fail'
	echo 'count_fail.type DERIVE'
	echo 'count_fail.min 0'
	echo 'count_fail.colour cc0000'
	echo 'count_none.label None'
	echo 'count_none.type DERIVE'
	echo 'count_none.min 0'
	echo 'count_none.colour 0066b3'
	echo 'count_temperror.label Temperror'
	echo 'count_temperror.type DERIVE'
	echo 'count_temperror.min 0'
	echo 'count_temperror.colour ff8000'
	echo 'count_neutral.label Neutral'
	echo 'count_neutral.type DERIVE'
	echo 'count_neutral.min 0'
	echo 'count_neutral.colour ffcc00'
 
	exit 0
fi
 
 
#
# Log parsing
#
 
function get_log_count() {
	egrep "policyd-spf\[[0-9]+\]: $1;" "$LOGFILE" | grep "$(date '+%b %e')" | wc -l
}
 
PASS=$(get_log_count "Pass")
FAIL=$(get_log_count "Fail")
NONE=$(get_log_count "None")
TEMPERR=$(get_log_count "Temperror")
NEUTRAL=$(get_log_count "Neutral")
 
echo "count_pass.value $PASS"
echo "count_fail.value $FAIL"
echo "count_none.value $NONE"
echo "count_temperror.value $TEMPERR"
echo "count_neutral.value $NEUTRAL"
 
 
exit 0

Wie immer gibts den Code auch in meinem GitHub-Repo.

Ein Screenshot des produzierten Graphen folgt, sobald ich genug Daten für eine vollständige Periode (24h) gesammelt habe. Edit: hier der Screeny, anscheinend habe ich zu wenig Traffic auf dem Mailserver ;)

DKIM mit Postfix für mehrere Domains

Veröffentlicht am von — Keine Kommentare ↓

Gerade noch schnell DKIM für Nerd-grade Kommunikation auf meinen Domains aufgesetzt :)

Dabei war dieses Tutorial als Basis hilfreich, ich habe nur die Pfade der Keyfiles anders strukturiert.

Außerdem würde ich noch folgenden DNS-Record setzten:

_adsp._domainkey.DOMAIN     IN    TXT    "dkim=all"

Damit funktioniert dann auch ADSP.

trac on apache2 with mod_fcgid: can’t apply process slot

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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.