Autor: ports (Seite 8 von 82)

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Hatten wir das noch nicht? Wir hatten vor ein paar Tagen was zum menschlichen Backup erzaehlt, aber ich sehe, wir haben noch nichts dazu gesagt, wie wir auf unseren Servern das Backup machen. Verrueckt 🙂

Wir haben ja zwei Server und verteilen dort die Dienste etwas. Auf Server foo haben wir in erster Linie Mail und Dokumentation. Auf dem Server bar haben wir dann primaer Web, bzw. die Webseiten von uns und einigen Bekannten. Wir sind bekennende Weicheier und erstellen daher taeglich auch immer ein komplettes Backup der fuer uns wichtigen Daten. Ein grosser Teil des Artikels wird aus den beiden Scripts bestehen, die wir zur Sicherung nutzen.

Wie wir die Daten zwischen den Servern synchronisieren hatte wir ja vor einiger Zeit schon mal beschrieben. Und auch der log4bash-Teil wurde schon mal beschrieben. Daher gehe ich nachfolgend nicht weiter drauf ein.

Fangen wir also mal mit einer Sicherung der wichtigen Dinge an:

#!/bin/bash

logger -t hotcopy.bash -i „Starting backup“

TIMESTAMP=$(date „+%Y%m%d-%H%M“)
TARGET_DIRECTORY=“/srv/bak/backup-md1″
DB_PREFIX=“db.“
DIR_PREFIX=“dir“
TRC_PREFIX=“trc.“

DIRECTORIES_TO_COPY=“/root /etc /var/log /var/mail /var/vmail /var/spool /var/www /home/∗ /srv/pwd /srv/www/∗ /usr/local/src/scripts /usr/share/munin/plugins /var/run/munin /var/spool/cron/crontabs/∗ /srv/trc/∗/attachments“

DATABASE_USERNAME=“deruser“
DATABASE_PASSWORD=“daspasswort“
DATABASE_TO_COPY=$(mysqlshow -u $DATABASE_USERNAME -p$DATABASE_PASSWORD | awk ‚!/Databases|–/ {print $2}‘ | grep -v information_schema)

cd /srv/trc
TRAC_WIKIS=$(ls)
cd ->/dev/null

logger -t hotcopy.bash -i „save a list of installed packets“
if [ -x /usr/bin/dpkg ]
then
dpkg –get-selections | bzip2 -9 > $TARGET_DIRECTORY/dpkg-selections-$TIMESTAMP.bz2
fi
if [ -x /bin/rpm ]
then
rpm -qa | bzip2 -9 > $TARGET_DIRECTORY/rpm-selections-$TIMESTAMP.bz2
fi

for i in $DIRECTORIES_TO_COPY
do
# vim backups entfernen
find $i -iname ‚*~‘ | xargs -r rm
FILENAME=$TARGET_DIRECTORY/$(echo $DIR_PREFIX$i-$TIMESTAMP.tar.bz2 | sed „s/^\///g ; s/\//./g“)
find $i -type s > /usr/local/src/scripts/sockets.lst
cat /usr/local/src/scripts/sockets.lst /usr/local/src/scripts/exclude.lst > /usr/local/src/scripts/excludesum.lst
tar -Pcjf ${FILENAME} ${i} -X /usr/local/src/scripts/excludesum.lst
logger -t hotcopy.bash -i „save $FILENAME“
done

for i in $DATABASE_TO_COPY
do
FILENAME=$TARGET_DIRECTORY/$DB_PREFIX$i-$TIMESTAMP.sql.bz2
mysqldump -c –databases –add-drop-database -u $DATABASE_USERNAME -p$DATABASE_PASSWORD $i | bzip2 -9 > $FILENAME
logger -t hotcopy.bash -i „save $FILENAME“
done

for i in $TRAC_WIKIS
do
/usr/local/bin/trac-admin /srv/trc/${i} hotcopy $TARGET_DIRECTORY/$TRC_PREFIX${i}-$TIMESTAMP
tar -Pcjf $TARGET_DIRECTORY/$TRC_PREFIX${i}-$TIMESTAMP.tar.bz2 $TARGET_DIRECTORY/$TRC_PREFIX${i}-$TIMESTAMP
logger -t hotcopy.bash -i „save $i“
rm -r $TARGET_DIRECTORY/$TRC_PREFIX${i}-$TIMESTAMP 1>/dev/null
done

find $TARGET_DIRECTORY -mtime +6 | xargs rm -f

logger -t hotcopy.bash -i „ending backup“

/usr/local/src/scripts/ftpbackup.bash 2>&1

Sieht vielleicht wild aus, ist es aber nicht. Zu Anfang definieren wir ein paar Dinge wie Benutzername und Kennwort fuer den Datenbankzugriff, zu sichernde Vezeichnisse und so weiter. Wichtig fuer uns ist TIMESTAMP. Diesen nutzen wir sowohl fuer die Logeintraege, als auch als Teil des Dateinamens fuer die Sicherungsdateien.

Zu Beginn erstellen wir erst mal eine Liste aller installierten Pakete. Das hilft ungemein wenn der Server, warum auch immer, neu aufgesetzt werden muss. Oder man moechte einen Server identisch installieren. Dann holt man sich die Liste, setzt ein sudo dpkg –set-selections < Liste gefolgt von einem sudo apt-get -u dselect-upgrade ab und hat kurze Zeit spaeter alle benoetigten/gewuenschten Pakete installiert.

Mit einer einfachen Schleife erstellen wir anschliessend Sicherungsdateien von den fuer uns wichtigen Verzeichnissen. Vorab generieren wir die Datei excludesum.lst. Dies ist eine Liste aller zu ignorierenden Dateitypen/Verzeichnisse (*.mp3, etc.) und den zur Laufzeit in dem zu sichernden Verzeichnis zu findenden Sockets.

Die Datenbanken und die Tracdaten holen wir uns auch ueber eine einfache Schleife und erstellen auch hier eine Sicherungsdatei. Wobei bei Trac trac-admin als Bestandteil der Trac-Installation zum Einsatz kommt.

Damit haben wir nun ein Haufen Dateien (es sind etwas ueber 90 Dateien mit insgesamt etwa 18 GB) die wir nun sinnvollerweise von der Maschine weg sichern. Vorab loeschen wir auf dem Server mit find $TARGET_DIRECTORY -mtime +6 | xargs rm -f alle Sicherungsdateien, die aelter als die angegebenen Tage sind. Ja, es gibt -exec fuer find 🙂

Jetzt aber erst mal alles weggesichert. Rufen wir also /usr/local/src/scripts/ftpbackup.bash 2>&1 auf. Damit die aufgerufene Sicherung auch laueft und wir keine Credentials in dem Script eintragen muessen, nutzen wir die Datei /root/.netrc.

machine zielserver
login ulopa
password vollkomplex

Diese Datei wird beim Aufruf von ftp gezogen und genutzt.

#!/bin/bash
logger -t ftpbackup.bash -i „Starting ftpbackup“

BACKUPDIR=/srv/bak/backup-md1
BACKUPDIRFTP=/
KEYFROMUSER=root
HOST=zielserver

########################################################################
# declare -a L4B_LABEL=(DEBUG INFO WARN ERROR CRITICAL FATAL ENDOFWORLD)

source /usr/local/src/scripts/log4bash.sh

# L4B_DEBUGLVL=1
# L4B_DELIM=“/“
# L4B_DATE=“date“
# L4B_DATEFORMAT=“+%Y%m%d-%H%M%S.%N“
# L4B_VERBOSE=true
# L4B_LOGFILE=“skript.log“
########################################################################

cd $BACKUPDIR

for FILENAME in *$(date +%Y%m%d)*
do
logger -t ftpbackup.bash -i „encrypt $FILENAME“
gpg -e -o $FILENAME.gpg -r $KEYFROMUSER $FILENAME
done

logger -t ftpbackup.bash -i „copy files“

ftp -i << EOF open $HOST bin lcd $BACKUPDIR cd $BACKUPDIRFTP mput *.gpg quit EOF logger -t ftpbackup.bash -i „delete enrcypted files in $BACKUPDIR“ rm *.gpg logger -t ftpbackup.bash -i „delete files older 7 days in $BACKUPDIRFTP“ ftp -i <

Wie im oberen Job definieren wir auch hier erst mal ein paar Dinge. Da wir die Daten via FTP uebertragen muessen (gibt nichts anderes) verschluesseln wir diese vorab noch mit PGP. Nach der Verschluesselung werden dann alle Dateien auf den Backupserver uebertragen. Anschliessend werden alle lokal liegenden verschluesselten Dateien geloescht und auch auf dem FTP-Server werden alle Dateien, die aelter als sieben Tage sind, entfernt.

Das Backup starten wir um 01:05 Uhr am Morgen und es dauert, mit dem Uebertragen der Daten, knapp ueber 2 Stunden. Das ist fuer uns wichtig zu wissen, da wir anschliessend ja noch den Synchronisationsjob laufen haben. Wenn der zu frueh startet koennen Dateien vielleicht nicht abgeholt werden, da diese im Rahmen des Backups noch nicht erstellt wurden.

Wir werden im Zusammenhang mit dem Umzug auf die neuen Server vermutlich etwas am Backup aendern. Aber dazu dann spaeter mehr.

Vielleicht ist fuer den ein oder anderen noch unser Vortrag interessant, den wir auf der Ubucon 2010 zum Thema „Restore“ gehalten hatten. Hintergrund war, dass uns Anfang 2010 unser damals noch singulaer ausgelegter Server abgeraucht ist. Das hatte hohen Unterhaltungswert! 🙂

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Hier, heute mal Leichenfledderei 🙂 Sprich, es gibt einen Beitrag, der auf unserer internen Dokumentation basiert, aber etwas erweitert wird. In Das Backup hatten wir schon angemerkt, dass wir fuer uns intern eine Mailingliste nutzen. Da wir ja beinahe alles selber machen moechten, haben wir dafuer mailman bei uns im Einsatz. Mailman ist eine Software fuer die Erstellung und Verwaltung von Mailinglisten. Gibt es eigentlich Alternativen?

Sowohl die Einrichtung, als auch die Wartung und Pflege von mailman ist erfreulich uebeschaubar. Wenn man es halt mal gemacht hat. Vor der Installation legen wir in unserem DNS noch einen A- und MX-Record fest, da wir gerne eine eigene Subdomain fuer die Listen nutzen moechten. Wir nehmen dafuer „lists“. Anschliessend installieren wir mailman via root@server:~# aptitude install mailman. Im Rahmen der Installation koennen wir ein paar „Sprachpackete“ auswaehlen und werden darauf hingewiesen, dass wir, nach der Installation, noch newlist mailman laufen lassen sollen.

Erst einmal wollen wir aber schauen, dass wir mailman spaeter auch via Brower erreichen koennen.

root@server:~# ln -s /etc/mailman/apache.conf /etc/apache2/sites-enabled/mailman
root@server:~# apache2ctl configtest
root@server:~# apache2ctl graceful

Das Apache-Modul cgi braucht es auch noch. Wenn das also nicht aktiv ist, dran denken. Nun wollen wir Postfix noch anpassen. Dafuer nehme ich folgende Anpassungen in der /etc/postfix/main.cf vor.

relay_domains = lists.ptlx.de
transport_maps = hash:/etc/postfix/transport
mailman_destination_recipient_limit = 1
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases

Bei bestehender Postfix-Konfiguration mag das natuerlich etwas anders aussehen, bzw. es koennte schon der ein oder andere Eintrag bei euch vorhanden sein. Damit wir spaeter keine „loops back to myself“-Meldungen erhalten, passen wir in der /etc/postfix/main.cf noch das my destination an und fuegen die Domain, die wir auch bei relay_domains angegeben haben (siehe oben), hinzu.

In der /etc/postfix/master.cf sollten wir nun folgender Eintrag zu finden sein.

mailman unix – n n – – pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}

Nun erstellen wir noch die Datei /etc/postfix/transport, tragen dort list.ptlx.de mailman: ein und erstellen/aktualisieren anschliessend via postmap -v /etc/postfix/transport (-v fuer verbose) die sogenannte „Postfix lookup table“. Soweit, so Postfix.

Nun noch etwas fuer mailman konfigurieren (warum wir uns heute ja auch getroffen haben). Wir haben fuer uns folgendes in der /etc/mailman/mm_cfg.py eingestellt:

DEFAULT_URL_PATTERN = ‚https://%s/cgi-bin/mailman/‘
DEFAULT_EMAIL_HOST = ‚lists.ptlx.de‘
DEFAULT_URL_HOST = ‚www.ptlx.de‘
MTA=’Postfix‘

Dann noch via newlist mailman die, nennen wir es mal, „initiale“ Liste anlegen und anschliessend die Aliases in /etc/aliases einstellen.

mailman: „|/var/lib/mailman/mail/mailman post mailman“
mailman-admin: „|/var/lib/mailman/mail/mailman admin mailman“
mailman-bounces: „|/var/lib/mailman/mail/mailman bounces mailman“
mailman-confirm: „|/var/lib/mailman/mail/mailman confirm mailman“
mailman-join: „|/var/lib/mailman/mail/mailman join mailman“
mailman-leave: „|/var/lib/mailman/mail/mailman leave mailman“
mailman-owner: „|/var/lib/mailman/mail/mailman owner mailman“
mailman-request: „|/var/lib/mailman/mail/mailman request mailman“
mailman-subscribe: „|/var/lib/mailman/mail/mailman subscribe mailman“
mailman-unsubscribe: „|/var/lib/mailman/mail/mailman unsubscribe mailman“

Was zu unserem Glueck nun noch fehlt ist die Initialisierung der sogenannten „alias-datenbank“ und der Neustart von Postfix (sicher ist sicher).

root@server:~# newaliases
root@server:~# /etc/init.d/postfix restart

Statt newaliases kann im Uebrigen auch sendmail -bi verwendet werden.

Im Rahmen der Erstellung der ersten Liste sollte es nun auch eine Mail an die Adresse gehen, die hier fuer „Enter the email of the person running the list:“ eingetragen habt. Dort findet sich dann unter anderem dem Link, ueber den mailman nun via http(s) konfiguriert werden kann. So, fertig 🙂

Migration?
Wenn mailman laeuft ist die Migration einer Liste recht einfach. Dafuer werden erst einmal alle Listendaten auf dem alten Server eingesammelt…

root@server:/var/lib/mailman# tar cfz /root/archiv.tar.gz archives/
root@server:/var/lib/mailman# tar cfz /root/data.tar.gz data/
root@server:/var/lib/mailman# tar cfz /root/lists.tar.gz lists/

…und nach dem Uebetragen auf den neuen Server koennen die Daten dort entpackt und an die richtige Stelle gebracht werden.

root@foo ~ # tar xzf archiv.tar.gz
root@foo ~ # tar xzf data.tar.gz
root@foo ~ # tar xzf lists.tar.gz
root@foo ~ # mv archives/ /var/lib/mailman/archives/
root@foo ~ # mv data/ /var/lib/mailman/data/
root@foo ~ # mv lists/* /var/lib/mailman/lists/

Nachfolgend sollte noch ein check_perms ausgefuehrt werden, der die Berechtigungen auf fuer mailman wichtige Verzeichnisse prueft. Die Option -f besagt, dass falsch gesetzte Berechtigungen auch gleich in Ordnung gebracht werden.

root@foo ~ # check_perms -f
root@foo ~ # /etc/init.d/mailman start

Probleme?
Was kann passieren oder ist vielleicht noch interessant zu wissen? Mir ist schon passiert, dass ich mailman nicht gaengig bekommen habe und in der /etc/mail.log die Meldung postfix/smtpd[25778]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory zu sehen war. Dann muss die Datei aliases.db noch angelegt werden.

root@server /srv/dav # touch /var/lib/mailman/data/aliases.db
root@server /srv/dav # postalias /var/lib/mailman/data/aliases.db
root@server /srv/dav # /etc/init.d/postfix restart
* Stopping Postfix Mail Transport Agent postfix [ OK ]
* Starting Postfix Mail Transport Agent postfix [ OK ]

Wenn nach der Migration in der Mailingliste der konfigurierte Hostname nicht mehr stimmt, kann das wie folgt in Ordnung gebracht werden.

root@server /var/lib/mailman/bin $ ./withlist -l -r fix_url LISTNAME -u foo.ptlx.de -v
Importing fix_url…
Running fix_url.fix_url()…
Loading list hosting (locked)
Setting web_page_url to: http://foo.ptlx.de/cgi-bin/mailman/
Setting host_name to: lists.ptlx.de
Saving list
Finalizing

Und um eine Mailingliste von http auf https, oder umgekehrt, zu bringen kann man wie folgt vorgehen. Erst einmal den DEFAULT_URL_PATTERN in der /etc/mailman/mm_cfg.py anpassen. Damit werden alle neuen Listen schon mal wie gewuenscht erstellt. Fuer alte Listen muss man noch dann nur noch fix_url aufrufen.

root@server /var/lib/mailman/bin $ withlist -l -a -r fix_url

Wobei die Optionen -l, -a und -r fuer lock list, all lists und run module stehen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Da gibt es uns schon so lange und wir haben nicht einmal ueber das Thema „Backup“ gesprochen. Wobei in dem nun folgenden Zusammenhang wohl eher „Der Backup(kollege)“ korrekt waere. Oder eben „Die Backup(kollegin)“.

Wir alle haben unsere Aufgaben und erledigen die gut bis besser (hoffentlich der Regelfall) oder schlechter. Das Ergebnis unserer Arbeit ist natuerlich immer von vielen Umgebungsvariablen abhaengig. Aber was passiert wenn wir nicht verfuegbar sind? Im optimalen Fall spreche ich hier von der Urlaubszeit. Aber man kann ja auch mal krank werden, vom Auto angefahren werden… Oder es passiert, was niemandem zu wuenschen ist, noch schlimmeres. Koennen die von mir administrierten Systeme noch am Laufen gehalten werden. Oder, was eher passiert, kann im Fehlerfall jemand helfen, wenn ich nicht da bin?

Aus meiner Sicht ist es wichtig hier alles zu tun, damit die Systeme weiter betrieben werden koennen, auch wenn ich mal vier Wochen Urlaub habe. Natuerlich fuehlt man sich erst mal gebauchpinselt, wenn man angerufen wird, weil es ein ganz dringendes Problem gibt und man der Einzige ist, der nun den Erhalt des Unternehmens sicherstellen kann. Aber die Zeit, in der ich diese „Bestaetigung“ brauchte ist lange vorbei. Heute arbeite ich um zu leben. Ich habe viel Spass an meiner Arbeit. Aber wenn ich nach Hause gehe, dann will ich Ruhe haben. Dann moechte ich mich auf mich, meine Familie und meine Hobbies konzentrieren koennen. Und mal unter uns. Fuehlt man sich noch immer so gebauchpinselt, wenn das private Handy im Kroatienurlaub zum dritten mal klingelt, nur weil man irgendeinen simplen Prozess nicht dokumentiert hat?

Womit wir schon beim Punkt waere. Wichtig, um Kollegen oder dem Ersatzmann die Arbeit zu ermoeglichen, ist die Dokumentation. Damit sind Dinge wie „Was war meine taegliche Aufgabe“ bis hin zu „Was mache ich im Fehlerfall ABC“. Dirk und ich betreuen ja gemeinsam einige Server und daher kann man uns ja auch als Beispiel nehmen. Wobei wir das bei Weitem nicht perfekt machen, da es unser privater Spass ist und vom Betrieb der Server keine Arbeitsplaetze abhaengen. Wichtig zu wissen ist sicher noch, dass eine Dokumentation nicht bis ins letzte Details ausformuliert sein muss. Es ist aber wichtig, dass da etwas im Dokumentationsmedium zu finden ist.

Was machen wir also um eine solide Basis zu bekommen und zu erhalten?

Trac ist eine Software, die Python-basiert ein Wiki, ein Ticket-System und einen Repository-Browser beeinhaltet.

Wir…
…nutzen ein Trac in dem wir installierte Dienste und Anwendungen beschreiben.
…nutzen das Trac in dem wir, wenn noetig, dokumentieren wie Dienst ABC installiert/konfiguriert wurde.
…nutzen das Trac in dem wir unsere Systeme (Hardware) und wichtige Daten (Kontakadressen, etc.) dokumentieren.
…nutzen das Ticketsystem des Trac fuer das „Erinnern“ und Erledigen von Aufgaben.
…stellen sicher, dass wir beide immer identische Rechte auf wichtige Ressourcen haben.
…haben eine eigene Mailingliste (ja, nur wir zwei) in der wir beinahe alle unsere Systeme betreffenden Punkte besprechen.

Der Vorteil einer Mailingliste ist, neben der zentralen Archivierung auf dem Server, dass wir auch alternative Mailadressen eintragen koennen, damit wir z.B. auch im Buero erreichbar sind.

Wir planen seit einiger Zeit auch die Verwendung sogenannter OpsDocs. Leider sind wir da in den letzten Wochen nicht zu gekommen, da uns andere Projekte Zeit geklaut haben. Diese Dokumente wuerden uns in einzelnen Punkten auf jeden Fall helfen uns zu verbessern. Aber…! Wir sind mit all den genannten Dingen bereits so weit, dass sowohl Dirk, als auch ich, mal vier Wochen im Urlaub verschwinden kann, ohne dass es bei Problemen zu Anrufen kommt, weil der eine nicht weiss, was der andere gemacht hat. Ausnahmen bestaetigen natuerlich die Regel. Wenn der Server wegen eines Crashes komplett neu aufgesetzt werden muss, machen wir das beide. Nicht in erster Linie wegen fehlendem Wissen. Hier hat sich einfach bewaehrt, mit vier Augen eine unter Zeitdruck zu erledigende Installation durch zu fuehren.

Dokumentation ist es aber, was wichtig ist. Es muss eine Dokumentations- und Berechtigungsbasis geschaffen werden die es dem „Ersatz“ erlaubt die Arbeit zu uebernehmen und Fehler zu beheben, wenn es drauf ankommt.

Klar ist, dass nicht immer alles dokumentiert werden kann. Eine oft ignorierte Voraussetzung fuer ein erfolgreiches Backup ist, dass der Backuppartner eben auch ueber vergleichbares Wissen verfuegt. Zu glauben, mann muss einfach nur alle moeglichen Fehler eines Domino-Servers inklusive der Loesungen dokumentieren und dann kann da auch ein Netzwerker helfen, ist verrueckt. Um Probleme zu loesen ist in der Regel auch ausreichend Hintergrundwissen wichtig um auch Zusammenhaenge zu erkennen und zu verstehen. Ansonsten koennte, bei ausreichender Dokumentation, ja jeder jeden Job machen.

Vereinzelt gibt es ja noch den Irrglaube, dass der eigene Job sicher ist, wenn man Wissen nicht weiter gibt. Kopfmonopol wird sowas genannt. Das stimmt heute aber eher selten bis gar nicht mehr. Jeder Mitarbeiter ist ersetzbar. Und wenn man nicht als Einzelperson betroffen ist, kann es auch schon mal passieren, dass man im Rahmen des Outsourcen einer IT-Abteilung mitgehen muss. Es ist auch einfach so, dass wir unsere Arbeit professionell erledigen wollen. Zum Einen weil es Spass macht, zum Anderen hat das natuerlich auch ganz handfesten Nutzen. Die eigene Arbeit wird besser wahrgenommen und das hilft bei Befoerderungen, Jobwechseln oder anderem, was einem dann auch wieder helfen kann interessantere Aufgaben zu bekommen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Der letzte Freitagsartikel, Richtig mailen, hat doch ueberraschend viel Feedback generiert. Dafuer moechten wir uns schon einmal bedanken. In dem Zusammenhang sind noch einige Punkte angesprochen worden, die wir gerne ergaenzen moechten.

Vorab vielleicht mal… Aus meiner Sicht ist der Grund, dass viele der „alten“ Regeln fuer richtiges Mailen nicht mehr bekannt sind, das Aufkommen der damaligen Mailclients wie Outlook Express und Co. Die Hersteller der Mailclients wollten den Benutzern die Verwendung von Mail so leicht wie moeglich machen. Die Benutzer waren auch gewohnt, dass sie in ihrem Office Text fett drucken konnten, warum also nicht auch in einer Mail?

TOFU
Das kritisierte TOFU kann in Firmen gewuenscht sein, damit spaeter hinzu kommende Mitleser leichter einsteigen koennen. Die gesammte Mailhistorie ist ja in einem Dokument zu finden. Allerdings hat man dann mit Effekten zu kaempfen, dass man im Laufe der Diskussion mehr und mehr Signaturen am Ende einsammelt. Das resultiert dann oft darin, dass nach zehn Runden ewig viele Zeilen „Signaturmuell“ am Ende der Mail zu finden ist.

Bilder
Eine Unart, die eher von Firmen zu Webezwecken, als zur internen Kommunikation genutzt wird. Text in Grafiken verpacken. Das sieht genau einmal toll aus. Und zwar dann, wenn man Absender ist und sich das ganze noch mal im Ordner „Gesendet“ anschaut. Fuer alle anderen ist diese Art der Kommunikation ein Horror. Man kann auf solche Mails nicht ordentlich antworten, da es keinen zitierfaehigen Text gibt. Und so Dinge wie Text markieren, Kopieren und Einfuegen geht mit Grafik auch eher nicht.

Verbieten von…
Mit Lotus Notes, auch Outlook (nicht ohne Grund sind die beiden Programme auf Platz 4 und Platz 6 bei dreckstool.de)?, gibt es die Moeglichkeit beim Versenden von Mails die Option das Kopieren oder Weiterleiten von Mails zu verbieten. Das ist, aus meiner Sicht, ganz schlechter Stil. Mir ist kein Szenario bekannt, in dem diese Option wirklich sinnvoll einzusetzen waere. Des Weiteren ist es so, dass damit ja ohnehin nur ein Flag gesetzt wird ($KeepPrivate), dass der Empfaenger im Zweifel einfach anpasst. Und nach aussen hin funktioniert der Unsinn ohnehin nicht.

Abschliessend noch zwei URLs, die im Zusammenhang mit korrektem Zitieren und der Freundlichkeit beim Mailverkehr zu empfehlen sind.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute mal ein Thema, dass nicht ausschliesslich fuer Administratoren interessant ist. Es geht um Mails. Also nicht um technische Details, sondern wie man Mails „richtig“ schreibt. Ein ganzer Haufen interessanter Punkte, die man beachten sollte, will mal aufgelistet werden.

• Betreff
Der Betreff ist dann korrekt, wenn Anhand dessen schon erkennbar ist, um was es in der nachfolgenden Mail geht. Also bei der Frage zu einer Rechnung vielleicht „Rechnungsanfrage“ oder „Frage zu Rechnung“. Der Betreff ist der falsche Ort fuer die eigentliche Mail. Auch wenn der folgende Mailtext nur eine kurze Zeile wie „Starte die Server dev-01 bis dev-09 neu“ beinhaltet, sollte er auch in der Mail zu finden sein. In diesem Beispiel mache ich es beispielsweise auch mal so, dass ich den Text sowohl in den Betreff, als auch in den Mailbody packe. Tatsaechlich weiche ich manchmal aber auch von der Regel ab. Das aber nur bei Leuten die mich kennen uns wissen, dass eine Mail mit dem Betreff „Schreibrechtsfehler“ keinen wichtigen, bzw. lebenswichtigen Inhalt hat.

Auch sollte man schauen, ob sich nach laengerem Mailverkehr nicht bereits eine „Re: AW: Re: AW:“-Kette im Betreff aufgebaut hat. Die kann man ruhig bereingen. Das „Re:“, bzw. „AW:“ bedeutet Antwort. Das muss da nicht mehrfach drin stehen.

Das kommt eher selten vor, aber auch da sollte man dran denken. Wenn man beispielsweise eine Mail aus einer Mailingliste weiterleitet und sich in dem Zusammenhang etwas am Inhalt aendert, sollte man den Betreff anpassen. Beispielsweise „Noch mal Detailfrage zum Ablauf (was: Offene Punkte fuer Projekt)“.

• An, Kopie, Blindkopie
Moegliche Empfaenger einer Mail koennen in eines von drei Feldern eingetragen werden. Das „An“-, „Kopie“- und „Blindkopie“-Feld. In das „An“-Feld kommt die Person, oder der Personenkreis, der mit der Mail explizit angesprochen wird. In das Feld „Kopie“ kommen die Adressaten, die die Mail in Kopie und somit nur zur Information mitbekommen. Moechte ich also meinen Kollegen fragen, ob er den Tagesdienst fuer mich am Montag uebernehmen kann, packe ich ihn in das „An“-Feld und mein Teamleiter bekommt die Kopie der Mail, da er unsere Einsatzplaene erstellt. Das Feld „Blindkopie“ ist ein sehr interessantes Feld. In dieses trage ich Adressaten ein, die bei den Empfaengern, die im „An“- und „Kopie“-Feld stehen, nicht angezeigt werden. Es sieht also niemand, dass ich den Kollege XY in Blindkopie hatte. Als wir unser ersten Kind bekommen hatten habe ich alle Empfaenger, die sich zum Teil auch untereinander nicht kennen, in Blindkopie genommen und die eigentliche Mail dann an meine Frau geschickt.

Bitte aber auch drauf achten, dass es schlechter Stil ist Leute waehrend einer laufenden Diksussion auf Blindkopie zu setzen.

• Verteiler
Bitte immer nur die Leute mit in die Empfaengerliste mit aufnehmen, die die Mail auch sinnvollerweise erhalten sollten. Ein zu grosser Verteiler kann schnell zu einem Eigentor werden. Mir ist da beispielsweise ein Fall bekannt, in dem die Weihnachtsmail eines Werksleiters von einem Mitarbeiter mit etwas wie „Ebenso. Sowie Guten Rutsch und Penisbruch“ beantwortet wurde. Dabei hat der Mitarbeiter den Verteiler auf quasi „alle“ belassen. Das war natuerlich ungeschickt, da der Werksleiter irgendwie reagieren musste.

• HTML
Da gibt es ja verschiedene Meinungen zu. Aus meiner Sicht hat HTML in Mail nichts verloren. Plain-Text in Mail ist der kleinste gemeinsamer Nennen. Den „sprechen“ alle Mailclients. HTML zu verwenden ist, als wuerde man aus allen Autobahnen Offroad-Strecken fuer schwere Jeeps machen. Ja, die Strasse kann ich zur Not auch mit meinem Familien-Van befahren. Aber toll ist es nicht. Und wenn ich das falsche Fahrzeug habe, dann habe ich gleich verloren. Sprich, HTML-Mails werden nicht immer ueberall korrekt oder ueberhaupt angezeigt. Unabhaengig davon blaeht HTML die Mail unnoetig auf. Aktuelles Beispiel ist bei mir eine Rechnung. Da faengt der eigentliche Text der Mail in Zeile 236(!) an und die Mail hat 1077 Zeilen. Dabei hat die Mail eine Groesse von knapp ueber 40 KB. Der eigentlich Mailtext, was man mit also mitteilen moechte, umfasst dabei laecherliche 79 Woerter.

• Rechtschreibung
Ich bin nicht perfekt wenn es um die Rechtschreibung geht. Egal ob Deutsch oder Englisch. Aber eine Mail, in der alle Naselang ein falsch geschriebenes Wort zu finden ist, in der Kommazeichen und Punkte fehlen und vielleicht ergaenzend noch auf Gross- Kleinschreibung verzichtet wird, ist eine Zumutung. Hinzu kommt, dass mir eine solche Mail signalisiert, dass der Absender sich keine Muehe geben wollte und mir nun die Aufgabe zukommen laesst, mir aus dem Wortschrott die korrekte Bedeutung zu suchen.

Obwohl Mail elektronische Kommunikation ist, heisst es nicht, dass man da alle kommunikativen Gepflogenheiten, die man (hoffentlich) aus dem „wirklichen“ Leben kennt, sausen lassen kann.

• Richtig zitieren
Das ist ein recht umfangreiches Thema. Das komplett zu beschreiben wuerde den Artikel sprengen. Daher vielleicht das wichtigste. Es wird nur zitiert was wichtig ist, bzw. der Teil, auf den man sich in seiner Antwort bezieht. Das macht es vor allem bei laengerem Mailverkehr das lesen leichter und die Mails auch uebersichtlicher.

• TOFU
In obigen Zusammenhang passt auch ein wenig TOFU. Damit ist Text Oben, Full-Quote Unten gemeint. Also im Grunde das, was wir alle aus dem „Business“ kennen, weil die Leute es oft auch nicht besser wissen. Leider wird das aber oft auch durch fehlerhaft eingestelle Mailclients „vorgelebt“. Somit passiert es dann schon mal, dass eine umfangreiche Erklaerung zu einer moeglichen Entscheidung spaeter komplett zurueck kommt. Nur mit dem Unterschied, dass der „Entscheider“ oben dann seine Entscheidung (Ja/Nein) eingetragen hat.

• Signatur
Auch beliebt… Die Signatur und deren Laenge. Im beruflichen Umfeld ist es manchmal was mehr als die damals im Usenet oft genannten vier Zeilen. Wenn ich aber eine Mail bekomme, in der die Signatur 17 Zeilen lang ist (schon erlebt), dann ist das doch zu viel. Im privaten Umfeld kann man sich auf Dinge wie die Adresse des eigenen Blog oder was anderes beschraenken. Die Mailadresse macht in der Regel kein Sinn. Die steht ja schon im Absender. Im geschaeftlichen Umfeld ist, aus meiner Sicht, eine Signatur mit mindestens der Rufnummer des Absenders Pflicht. Ich habe schon mehrfach Mails erhalten, wo immer nur mit „Gruss, Hein“ unterschrieben wurde. Und wenn man da beispielsweise mal eben wegen eines Angebotes mal nachfragen moechte, dann sind fehlende Angaben bloed.

Was ich vergessen hatte und wo Seraphyn in den Kommentare drauf hinweis. Eine Signatur faengt mit „– “ (Minux, Minux, Leerzeichen) an, damit diese beim Beantworten der Mail gleich automatisch entfernt wird.

• Anhaenge
Bei der Verwendung von Anhaengen sollte man sich drei Fragen stellen. Muss der Anhang sein? Ist der Anhang in der Groesse angemessen und kann der Empfaenger den Anhang oeffnen? Bei Grafiken kann man sich beispielsweise fuer das schicke alte Format IFF entscheiden, weil man es nostalgisch mag. Aber oeffnen wird die Grafik heute kaum noch jemand koennen. Auch der Versand von Office-Dokumenten ist nicht immer optimal. Mal unabhaengig davon, dass in dem Dokument, neben dem was ich geschrieben habe, noch andere interessante Informationen zu finden sein koennen. Wenn man nicht sicher ist, auf der Gegenseite einfach mal nachfrage. Es ist schon frustrierend, wenn man ein Dokument erhaelt, dass mit Word 2010 erstellt wurde um man kann es mit seinem Office XP nicht oeffnen.

Als Ergaenzung vielleicht noch. Es ist generell kein guter Stil private Mails, ohne die Erlaubnis des urspruenglichen Absenders, an einen Dritten weiter zu leiten. Des Weiteren sollte man immer dran denken, dass auf der „anderen Seite“ in der Regel auch nur ein Mensch sitzt. Man sollte sich also entsprechend verhalten. Dem unbeliebten Kollegen in der Kantine in der Schlange an der Kasse mal eben ein „Du Spinner“ an den Kopf zu werfen ist nicht nett, aber, wenn man es leise macht, oft nicht nachweisbar. Per Mail hat das alles gleich einen ganze anderen Character.

Hierzu noch eine kleine, wahre, abschliessende Geschichte. Es gab da den Mitarbeiter Schmitz. Wenn er Mails geschrieben hat, dann war das keine Freude die zu lesen, weil er immer recht pampig und unverschaemt wurde. Irgendwann hat sich Herr Schmitz gewundert, dass er von Herr Mayer nie eine Antwort auf seine Fragen bekommen hat. Also ist Herr Schmitz ins Buero von Herr Mayer und hat gefragt, wie das denn bitte sein kann! Da hat Herr Mayer Herr Schmitz gebeten doch mal naeher zu kommen. Er hat sein Regelwerk im Mailclient geoeffnet und Herr Schmitz seine erste Regel gezeigt. Die sah wie folgt aus: „Alle Mails von Herr Schmitz ungelesen in den Papierkorb“.

Und warum? Weil Herr Schmitz sich nicht an eine wichtige Regel gehalten hat. Denk immer dran, dass dir gegenueber ein Mensch sitzt. Sei also erst einmal freundlich!

Nachtrag:
Robert Kraus weist auf Google+ zu Recht auf nachfolgendes hin: Zu dem Abschnitt ‚Signatur‘ lohnt vielleicht noch der Hinweis, dass es in Deutschland bei geschaeftlichen Emails Pflichtangaben gibt, die man nicht vergessen sollte. Andernfalls drohen, man ahnt es bereits, Abmahnungen. Heise hat da einen passenden Artikel dazu: http://www.heise.de/resale/artikel/Abmahnsichere-Geschaefts-E-Mail-274204.html

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Wir haben mehrere Server im Einsatz. Auf einigen Servern hosten wir auch Dienste fuer Bekannte, die allerdings keinen direkten Zugang (SSH) erhalten. Nun war die Frage, wie diese Benutzer Daten auf den Server kopieren koennen, um beispielsweise die eigene Webseite auf einen aktuellen Stand zu bringen. Da Dirk und ich gerne auf ungesicherte Datenuebertragungen verzichten moechten, haben wir uns hier fuer FTPS entschieden.

Anfaenglich hatten wir uns auf Serverseite fuer ProFTPd entschieden. Die Installation lief auch problemlos. Allerdings konnte spaeter keine Verbindung hergestellt werden. Grund ist ein bekannter Bug, den wir auch in unserer Umgebung nachstellen „konnten“. Also haben vsftpd als Mittel der Wahl ausgewaehlt.

Die Installation ansich kann gewohnt problemlos ueber die Paketquellen erfolgen. Flott ein sudo aptitude install vsftpd libpam-pwdfile und schon kann man an die Konfiguration gehen. Das Paket libpam-pwdfile wird spaeter benoetigt um Benutzer gegen eine Passwortdatei zu authentifizieren. Wir haben diesen Weg gewaehlt, damit wir die Benutzer nicht in die /etc/passwd eintragen muessen. Da wir FTPS nutzen moechten habe ich den Daemon erst mal gestoppt (service vsftpd stop) und ein Zertifikat erstellt.

ramon@server:/srv/www# cd /etc/ssl/private/
ramon@server:/etc/ssl/private# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout vsftpd.pem -out vsftpd.pem

Anschliessend muss die Datei /etc/vsftpd.conf angepasst werden. Hier mal die relevanten Teile inklusive deren Beschreibung aus unserer Konfiguration.

# Uncomment this to enable any form of FTP write command.
write_enable=YES

# You may restrict local users to their home directories. See the FAQ for
# the possible risks in this before using chroot_local_user or
# chroot_list_enable below.
chroot_local_user=YES

# If enabled, virtual users will use the same privileges as local users. By default, virtual
# users will use the same privileges as anonymous users, which tends to be more restrictive
# (especially in terms of write access).
virtual_use_local_privs=YES

# This option is useful is conjunction with virtual users. It is used to automatically
# generate a home directory for each virtual user, based on a template.
user_sub_token=$USER

# This option represents a directory which vsftpd will try to change into after a local
# (i.e. non-anonymous) login. Failure is silently ignored.
local_root=/srv/www/$USER

# If enabled, all user and group information in directory listings will be displayed as
# „ftp“.
hide_ids=YES

# Turn on SSL
ssl_enable=YES

# This option specifies the location of the RSA certificate to use for SSL
# encrypted connections.
rsa_cert_file=/etc/ssl/private/vsftpd.pem

# All non-anonymous logins are forced to use a secure SSL connection in order to
# send and receive data on data connections.
force_local_data_ssl=YES

# All non-anonymous logins are forced to use a secure SSL connection in order to send the password.
force_local_logins_ssl=YES

# Permit TLS v1 protocol connections. TLS v1 connections are preferred
ssl_tlsv1=YES

# Permit SSL v2 protocol connections. TLS v1 connections are preferred
ssl_sslv2=NO

# permit SSL v3 protocol connections. TLS v1 connections are preferred
ssl_sslv3=NO

# If set to yes, all SSL data connections are required to exhibit SSL session reuse (which proves
# that they know the same master secret as the control channel). Although this is a secure default,
# it may break many FTP clients, so you may want to disable it.
require_ssl_reuse=NO

Wie man sehen kann mappen wir die Benutzer auf den Ordner /srv/www/$USER. Das bedeutet natuerlich auch, dass der Ordner vorhanden sein sollte und die Rechte enstprechend gesetzt sind.

Wie oben beschrieben moechten wir die Benutzer nicht im System ansich anlegen sondern in einer eigenen Datei pflegen. Dafuer erstelle ich erst einmal die Datei /etc/vsftpd.passwd und trage auch gleich einen ersten Benutzer ein.

ramon@server:/etc# htpasswd -c /etc/vsftpd.passwd ramon

Soweit, so fast fertig. Nun muessen wir noch konfigurieren, dass eben diese Datei auch genutzt wird um Benutzer zu authentifizieren. Dafuer muss die Datei /etc/pam.d/vsftpd angepasst werden. Folgende Eintraege sind dabei zu machen.

auth required pam_pwdfile.so pwdfile /etc/vsftpd.passwd
account required pam_permit.so

Des Weiteren muss der Eintrag auth required pam_shells.so auskommentiert werden. Jetzt nur noch den Service wieder starten und schon sollte die Anmeldung moeglich sein.

Alles in allem ist die Einrichtung eigentlich einfach. Wie so oft steckt der Teufel aber im Detail. Im Rahmen der Installation hatte ich einige Probleme, die mich etwas Zeit gekostet haben. So ist auf Clientseite die Meldung ssl_getc: SSL_read failed -1 = 0, bzw. **** gnutls_record_recv: A record Paket with illegal version was received kein zwingender Hinweis auf ein Problem mit SSL. Bei mir war es einfach der fehlende Benutzer, der Ausloeser der Meldung war. Nach dem Anlegen der /etc/vsftpd.passwd und der Anpassung der /etc/pam.d/vsftpd funktionierte die Anmeldung noch immer nicht. Dafuer habe ich dann in der /var/log/auth.log den Eintrag bar vsftpd: PAM unable to dlopen(/lib/security/pam_pwdfile.so): /lib/security/pam_pwdfile.so: cannot open shared object file: No such file or directory gefunden. Daher auch die oben angesprochene Installation des Pakets libpam-pwdfile. Bei einem weiteren Versuch hat die Anmeldung noch immer nicht funktioniert, da ich die Datei /etc/pam.d/vsftpd zwar erweitert, den oben angesprochenen auth-Eintrag aber nicht auskommentiert hatte. Man sieht also, da ist Luft fuer Fehler gewesen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute ein Folgebeitrag zum Artikel Einrichten eines Syslog Servers. In diesem wurden ja einige Schritte zur Einrichtung eines Syslogservers beschrieben, der eingehende Logs in eine MySQL-Datenbank schreibt. Das ist auch soweit toll, bis auf… Bis auf die Punkte Backup und Logrotation. Im dargestellten Artikel bin ich mit keinem Wort auf einen der beiden Punkte eingegangen. Das moechte ich nun nachholen.

Warum ueberhaupt Backup und Rotation?

Die Logs die ich einsammel enthalten Details, die mir im Fall eines Problems oder Vorfalls helfen koennen benoetigte Informationen auf die Schnelle zentral zu sichten. Wenn das Ereignis, ueber das ich mich informieren moechte, nun zwei Tage zurueck liegt, mir aber am Tag vorher die Daten verloren gegangen sind (Servercrash, etc.), waere das schon doof. Daher also Backup. Und die Rotation soll einfach helfen die anfallenden Datenmengen zu begrenzen. Denn Logs von vor zwei Tagen duerften mal helfen koennen. Aber ab einem bestimmten Alter sind Logs in der Regel nicht mehr interessant. Ich habe den Zeitraum fuer mich mal auf 90 Tage festgelegt.

Die Daten, um die es mir nachfolgend geht, liegen in der Datenbank Syslog in der Tabelle SystemEvents. Um ein „richtiges“ Backup zu haben uebernehme ich taeglich die Daten vom Vortag in eine neue Tabelle, exportiere diese und sicher die dann weg.

Also fangen wir an und erstellen eine Tabelle, die die anfallenden Daten aufnehmen kann.

mysql -u root -p -e „CREATE TABLE Syslog.SystemEventsBackup LIKE Syslog.SystemEvents“ Syslog

Hiermit wird in der Datenbank Syslog die neue Tabelle SystemEventsBackup erstellt, die die gleichen Eigenschaften wie die Tabelle SystemEvents hat. Moechte ich nun die Daten des Vortags sichern, fuege ich diese erst einmal in meine neue Tabelle ein, nachdem ich die vorher geleert habe.

mysql -u root -p -e „TRUNCATE Syslog.SystemEventsBackup“ Syslog
mysql -u root -p -e „INSERT INTO Syslog.SystemEventsBackup SELECT * FROM SystemEvents WHERE datediff( curdate() , ReceivedAt ) =1“ Syslog

Habe ich die Abfrage nun ausgefuehrt kann ich hergehen und die Tabelle via mysqldump exportieren.

root@server:~# mysqldump -u root -p Syslog SystemEventsBackup > test.sql
Enter password:

Prima, die Sicherung klappt schon mal. Nun noch schauen, dass die Eintraege, die aelter als 90 Tage sind, entfernt werden. Fuer einen ersten Versuch schauen wir erst mal, ob die Anfrage korrekt laueft und nehmen alles, was aelter als 10 Tage ist.

mysql -u root -p -e „SELECT * FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 10*24*60*60“ Syslog

Ist das Resultat wie wir es erwarten koennen wir aus dem SELECT ein DELETE machen. Fuer die mit den schnellen Finger. Hiernach sind die Daten erst mal weg.

mysql -u root -p -e „DELETE FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 10*24*60*60“ Syslog

Somit haben wir also alles zusammen um uns ein Script zu schreiben, dass uns taeglich eine Sicherung der gestrigen Daten macht und anschliessend alle Daten in der Datenbank loescht, die aelter als 90 Tage sind.

#!/bin/bash

logger -t backrotate.bash -i „Starting backrotate.bash“

TIMESTAMP=$(date „+%Y%m%d-%H%M“)
TARGET_DIRECTORY=“/var/tmp“
DB_PREFIX=“db.“

DB_USERNAME=“username“
DB_PASSWORD=“password“
DB_DATABASE=“Syslog“
DB_TABLE=“SystemEvents“
DB_BAKTABLE=“SystemEventsBackup“
DB_ENTRIES=“`mysql -u $DB_USERNAME -p$DB_PASSWORD -e „SELECT COUNT(*) FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 90*24*60*60“ Syslog | egrep „[0-9]{1,}“ -o`“ logger -t backrotate.bash -i „creating backupfile“ FILENAME=$TARGET_DIRECTORY/$DB_DATABASE-$TIMESTAMP.sql.bz2 mysql -u $DB_USERNAME -p$DB_PASSWORD -e „TRUNCATE $DB_BAKTABLE“ $DB_DATABASE mysql -u $DB_USERNAME -p$DB_PASSWORD -e „INSERT INTO $DB_DATABASE.$DB_BAKTABLE SELECT * FROM $DB_TABLE WHERE datediff( curdate() , ReceivedAt ) =1“ $DB_DATABASE mysqldump -u $DB_USERNAME -p$DB_PASSWORD $DB_DATABASE $DB_BAKTABLE | bzip2 -9 > $FILENAME

logger -t backrotate.bash -i „backupfile $FILENAME created“
logger -t backrotate.bash -i „deleting $DB_ENTRIES database-entries >90 days“

mysql -u $DB_USERNAME -p$DB_PASSWORD -e „SELECT * FROM $DB_TABLE WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 90*24*60*60“ $DB_DATABASE

Diejenigen von euch, die schon laenger mitlesen werden zu Recht anmerken, dass ich mich nicht an die eigenen Hinweis halte. Natuerlich mache ich das 🙂 Obiger Job soll ja nur das Geruest sein. In „meiner“ Produktion habe ich das natuerlich entsprechend erweitert. 😉