Auf der Arbeit komme ich in den Genuss eines Unix-Mailservers und eines SSH-Zugangs auf ebendiesen (der mittlerweile etwas veraltete „Big Iron“-Ansatz hat wohl nicht mehr lange Bestand und ich fürchte um meine liebevoll eingepflegten procmail-Filter). Damit sind alle Voraussetzungen erfüllt, um eintreffende E-Mails serverseitig zu filtern.

Der Vorteil gegenüber einer clientseitigen Filterung (mit Apple Mail übrigens ein Kinderspiel) liegt auf der Hand: Greife ich zum Beispiel mit einem Mobiltelefon auf den IMAP-Server zu, liegen weniger Nachrichten in der INBOX, was sich in einer schnelleren Übertragung wiederspiegelt.

Syntax

Ein kleiner Ausschnitt aus meiner .procmailrc:

:0
* ^Subject.*new station eth0.
IMAP/arpwatch-n

:0
* ^From.*arpwatch
IMAP/arpwatch

Der Aufbau ist recht simpel:

• :0 Der Ursprung dieser Zeichenfolge entzieht sich meiner Kenntnis; die Bedeutung lautet „Es folgt eine Regel“
• * Signalisiert einen Filter. Nachfolgend werden reguläre Ausdrücke („regular expressions“) angefügt. ^ bedeutet beispielsweise „am Anfang einer Zeile“; das Gegenteil wäre $, was „am Ende einer Zeile“ bedeutet. Ein . (Punkt) ist ein Platzhalter für genau ein Zeichen, ein .* (Punkt mit nachfolgendem Stern) bedeutet „eine beliebig lange Zeichenkette“ usw. usf.
• IMAP/arpwatch bedeutet den Zielordner; eine grosse Datei im .mbx-Format

Bestimmte E-Mails weiterleiten

Vor einigen Tagen kam der Wunsch auf, bestimmte automatisch generierte Mails an gewisse Leute auf der Arbeit weiterzuleiten. Von Hand wäre das sehr mühsam gewesen, ein Eingriff in den Programmcode (Drupal) stand ebenfalls ausser Diskussion.

Doch wieso in die Ferne schweifen? .procmailrc bringt alles mit, um auch so etwas auf drei Zeilen zu bewerkstelligen:

:0 c
* ^Subject.*Kontodetails f
! user@server.tld

• :0 c „c“ weist procmail an, eine Kopie der Nachricht zu erstellen (damit ich die Nachricht weiterhin in meine INBOX geliefert erhalte)
• * Signalisiert (immer noch) einen Filter (siehe oben)
• ! user@server.tld Die Nachricht wird an die Mail-Adresse user@server.tld weitergeleitet

Weiterführendes

5. Mails lokal zustellen

Seit einiger Zeit sichere ich die Datenbanktabellen auf meinem Entwicklungsserver (Debian) jeden Abend mit dem Perl-Script mysqlhotcopy. Einerseits beuge ich so einem Datenverlust vor, wenn ich für ein neues Projekt die Nacht durchgecodet habe und am nächsten Tag dummerweise DROP database ausführe, andererseits wenn Partyguide wieder einmal versuchen sollte, die Datenbank vollzuspammen.

Seit dem letzten

apt-get upgrade

spinnt die Routine leider und produziert folgende Fehlermeldungen:

Invalid db.table name 'mysql.mysql`.`columns_priv' at
usr/local/mysql/current/bin/mysqlhotcopy line 855.

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Das Problem taucht mit dem Upgrad auf DBD::mysql 4.003 auf. Da ich in der Eile nicht herausfinden konnte, wie ich dieses Package downgrade, habe ich mysqlhotcopy folgendermassen gepatcht:

...
my @dbh_tables = eval { $dbh->tables() };
map { s/^.*?\.//o } @dbh_tables;

## Remove quotes around table names
...

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Nun läuft das Backup wieder sorgenfrei.

APC Smart-UPS SUA750I
Originally uploaded by emeidi.

Gestern ist sie eingetroffen, meine neue, übergrosse Batterie (APC Smart-UPS SUA750I), die meinen Server sowie die sich am gleichen Ort befindlichen Breitband-Geräte in Zukunft vor kurzen Stromausfällen oder Sicherungen beschützen soll.

Vor diesem Neugerät hatte ich einige Monate lang eine APC Smart-UPS 1400 in Betrieb, doch bei mehreren Ernstfällen verweigerte die Batterie ihren Dienst. Entweder hätte ich für mindestens 200 Stutz die Batterie wechseln oder aber für etwas mehr Geld ein Neugerät mit allem Drum und Dran, inklusive Garantie, anschaffen können. Ich entschied mich für letzteres.

Erste Tests liefen völlig zufriedenstellend – das Stromkabel ausziehen: Der Server surrt weiter vor sich hin, die LEDs des Router und des Kabelmodems blinken weiter unablässig. Ziel erreicht. In den letzten Wochen war das nicht mehr so gewiss – wurde die USV vom Stromnetz getrennt, verstummten alle Geräte blitzartig.

Kontrolle muss sein

Damit auch das Herz des Kontrollfreaks höher schlägt, werden zwei – aus meiner Sicht – wichtige Parameter der USV von meinem Linux-Server aufgezeichnet: Temperatur sowie die „Load Percentage“. Dank apcupsd, einem OSS-Ersatz für die offizielle PowerChute-Software, und dem darin enthaltenen Tool apcaccess ist das alles kein Problem.

Folgendes Script liefert die zwei Zahlen zur einfachen Integration in cacti:

#!/bin/sh

ITEMP=`apcaccess | grep ITEMP | cut -d ":" -f 2 | cut -d " " -f 2`
LOADPCT=`apcaccess | grep LOADPCT | cut -d ":" -f 2 | cut -d " " -f 3`
LINEV=`apcaccess | grep "^LINEV" | cut -d ":" -f 2 | cut -d " " -f 2`

echo ITEMP:$ITEMP LOADPCT:$LOADPCT LINEV:$LINEV >> /var/log/apcupsd.temp

exit 0