Kategorie: Adminstories (Seite 1 von 4)

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

Wir sind umgezogen. Wir hatten es ja bereits gesagt. Und es ist immer wieder interessant zu sehen, wie flott man sich im anfallenden Aufwand verschaetzt. Bei unseren zwei Servern denkt man vielleicht:

Ok, schnell mal eben Mail, Webserver und Datenbanken auf den neuen Serven eingerichtet. Daten kopieren, ein bisschen scp und rsync und DNS umstellen.

Aber da steckt doch einiges mehr dahinter. Hier mal eine fast komplette Liste der bei uns genutzten Dienste:

• Amavis als Spamfilter
• Apache als Webserver
• Dovecot als IMAP Server
• ejabberd als Messaging Server (XMPP)
• git fuer Versionierung
• Horde Groupware Webmail Edition als Webmailanwendung
• Icinga fuer das Monitoring
• MySQL als Datenbank
• OpenVPN als VPN-Loesung
• phpMyAdmin zur Datenbankadministration
• Piwik zur Webanalyse
• Postfix als Mailserver
• RoundCube als Webmailanwendung
• Smokeping als Ergaenzung zum Monitoring
• Tiny Tiny RSS als RSS-Reader fuer den Browser
• Trac als Dokumentationsplattform
• vsftp als sicheren SFTP Server
• Munin fue Monitoring mit bunten Bildern

Wer sich mit der ein oder anderen Anwendung auskennt wird bereits ahnen, dass es da in der Regel nicht mit einem aptitude install $SOFTWARE getan ist. Natuerlich gibt es Anwendungen, die man, wie phpMyAdmin oder auch MySQL, oft „mal eben“ installiert hat. Aber das komplette Mail- und Webserver-Umfeld kann schon viel Zeit in Anspruch nehmen. Dabei meine ich nicht unbedingt die Momente, wo man Neuland betritt und sich informieren muss. Im Grunde haben wir alles schon mal gemacht. Aber wir installieren die Dinge eben nicht woechentlich neu, sondern vielleicht einmal im Jahr. Da gehen einem natuerlich immer wieder Detailinformationen verloren. Und auch wenn man alles parat hat, so dauert die Einrichtung auch ohne moegliche Probleme seine Zeit. Und mit Problemen muss man immer rechnen. Ergaenzend macht es natuerlich auch Sinn alle Dienste vor dem Abschalten der alten Server auf der neuen Umgebung zu testen.

Als zusaetzliche „Huerde“ haben wir noch die Benutzer. Wir verwenden die beiden Server nicht nur fuer uns sondern bieten ein paar wenigen Leuten auch verschiedene Dienste, wie etwa Mail oder Webhosting, ab. Das bedeute aber auch, dass wir die Benutzer zeitig informieren muessen. Wir haben allerdings das Glueck, dass unsere Anwender sehr pflegeleicht sind. Sprich, eine kurze Mail als Benachrichtigung an die Betroffenen reicht im Regelfall aus.

Was auch gerne vergessen wird ist, dass der Umzug auch Chance zum aufraeumen und Neuanfang sein kann. Denn letzlich muessen alle Dienste und Konfigurationen in irgendeiner Art angefasst werden. Da sollte man sich gleich von den Teilen trennen, die nicht mehr benoetigt werden. Bei uns waren das zum Beispiel ein Teil meiner Webseiten sowie ein paar Datenbanken. Und fehlt vielleicht die Dokumentation zur Anwendung ABC? Dann ist jetzt die Gelegenheit gekommen die auf einen aktuellen Stand zu bringen, bzw. zu erstellen! 🙂

Alles in allem vergehen, reine Arbeitszeit, mal problemlos ein paar Tage bis alles fertig ist. Denn zu den genannten Punkten kommt natuerlich noch hinzu, dass die Server erst mal grundkonfiguriert werden muessen. Also, nachdem man die Server erst mal bestellt hat. Wenn nachdem man sich erst mal fuer einen Anbieter entschieden hat 😉

Man sollte also ausreichend Zeit fuer eine Migration einplanen. Alleine schon um nicht in Versuchung zu kommen, einen Dienst oder eine Anwendung, die bei der Einrichtung Probleme macht, irgendwie anders ans laufen zu bekommen. Denn „Loesungen“, die im Business gerne Uebergangsloesung genannt werden, sind in der Produktion bestaendig. Sprich, Uebergangsloesungen bekommt man spaeter oft nicht mehr in Ordnung, ohne groessere Ausfaelle oder Aufwaende in Kauf zu nehmen.

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. 😉

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

Weil es in meinem Umfeld die Tage wieder so eine Situation gab geht es heute um das Thema „Verhalten im Ernstfall“. Ein Ernstfall kann mehr oder weniger ausgepraegt sein. Auf unserem gemeinsamen Server hatten wir Anfang 2010 einen Ernstfall, denn ich mal als Notfall kategorisieren wuerde, der uns (Dirk, Hampa, mich) einige Stunden fuer die Wiederherstellung gekostet hat.

Die gemachten Erfahrungen haben Dirk und ich spaeter in einem gemeinsamen Talk auf der Ubucon 2010 verarbeiten „muessen“.

Eine Definition einer Stoerung oder Groesserem kann beispielsweise dem BSI entnommen werden. Letzlich laesst sich ein Problem nicht immer eindeutig kategorisieren. Aber halten wir uns nicht mit Definitionsdetails auf.

Was mache ich nun, wenn es zu einer Stoerung kommt? Ich versuche erst einmal einzuschaetzen wie gross der Einfluss der Stoerung ist. Ist „nur“ ein Testserver ausgefallen, der hier und da von Entwicklern genutzt wird oder ist ein Firewallcuster ausgefallen, so dass 4.000 Menschen kein Internet und damit auch keine Partneranwendungen mehr nutzen koennen? Oft zeigt das Telefon einem schon an, ob es ein wichtiges System getroffen hat oder nicht 🙂

Wir gehen mal von einem harten Fall aus, wo viele Anwender nicht mehr arbeiten koennen. Welche Moeglichkeiten habe ich als Administrator, dessen Server gerade abgestuerzt ist oder einfach nicht mehr reagiert? Da gibt es natuerlich den Klassiker frei nach den Simpsons. Ein Hinweis auf „Schau mal da hinten der Hund! Der wedelt mit dem Schwanz!“ und dem anschliessenden Geraeusch eines startenden Flugzeuges. Da viele von uns aber Familie haben gehen wir den harten und ehrlichen Weg. Wir stellen uns dem Problem.

Hier gibt es einige Punkte, die einem helfen koennen die Situation ohne Herzklappenabriss zu bestehen. Das wichtigste ist immer die Ruhe zu bewahren! Das sagt sich oft so locker und ist sicher nicht leicht, wenn um einen herum die Anwender/Vorgesetzten stehen und einen mit panischen und (in dem Moment) stoerenden Fragen immer wieder aus der Arbeit reissen. Was uns zu einem weiteren Punkt bringt, der hilft die Ruhe zu bewahren.

Sorgt dafuer, dass ihr euch auf das Problem konzentrieren koennt indem ihr alle Leute raus werft, die nicht zur Loesung des Problems beitragen koennen. Das kann man freundlich aber bestimmt machen. Ich habe bei einem Problem auch schon mal einen Vorgesetzten mit den Worten „Wenn Sie mich nicht alle fuenf Minuten unterbrechen wuerden, waere ich schon ein Stueck weiter“ dazu gebracht mich alleine zu lassen. Natuerlich habe ich meinem Vorgesetzten spaeter auch noch mal erklaert, um was es mir ging und dass es eben niemandem hilft, wenn ich alle fuenf Minuten den Stand der Situation erklaeren muss. Er hat es dann auch verstanden, auch wenn er nach meinen Rauswurf doch einen leicht roten Kopf hatte. Damit kann man natuerlich auch mal auf die Nase fallen. Aber auch der Kollege hier, der Dirk, hatte sich mal bei einer groesseren Stoerung gegenueber einem weiter ueber ihm stehenden Vorgesetzten entsprechend geaeussert.

Nicht vergessen sollte man in dem Zusammenhang so Dinge wie das Telefon. Wenn moeglich leitet nach Absprache euren Apparat auf einen Kollegen, den Chef oder, wenn es das gibt, das Service Center um. Der Kollege kann auch als Ergaenzung die Kommunikation in Richtung Anwender uebernehmen.

Kommen wir zum dritten Punkt, der wiederum prima am vorherigen Punkt anschliesst. Die Kommunikation! Vielen Leuten ist nicht klar, wie wichtig Kommunikation ist. Man selber merkt das aber oft selber, wenn man auf etwas wartet und es wird nichts kommuniziert. Sei es, dass man auf einem Amt wartet der Naechste zu sein. Oder sei es am Rechner, wo einem, wie beispielsweise bei dem Linux cp kein Balken anzeigt, wie weit er mit dem Kopieren der 10.000 Dateien ist. Das ist der Grund, weshalb man rsync -P statt cp benutzt.

Es steht ausser Frage, dass die Prozentangaben (Dirk hatte da auch eben noch was in seinem Blog) im Grunde Stuss sind. Aber sie geben einem erst einmal ein gutes Gefuehl. Und das braucht auch der Anwender und der Vorgesetzte. Die Betroffenen muessen das Gefuehl bekommen, dass sich da jemand kuemmert. Daher schreibe ich gerne mal eine Statusmail. Da verzichte ich auf die Angabe von Zeiten, so ich diese nicht vernuenftig einschaetzen kann. Aber ich gebe durch, was ich gemacht habe und was noch fuer Schritte fehlen. Das mache ich uebrigens auch bei Projekten, die sich ueber einen laengeren Zeitraum hinziehen. Jede Woche eine kleine Statusmail an den Auftraggeber. Das dauert fuenf Minuten, gibt dem Auftraggeber aber das Gefuehl, dass sein Thema/Auftrag noch in der Bearbeitung ist.

Was haben wir noch?

Aus meiner Sicht fehlen hier noch drei Punkte. Zum einen die Systemdokumentation. Ab einer bestimmten Anzahl von betreuten Systemen kann ich nicht alles im Kopf behalten. Da ist eine Dokumentation erforderlich. Wichtig ist also zu wissen, wo ich die diese finde und… wo ich die Replik der Informationen finde. Denn es kann ja auch passieren, dass der Server weg ist, auf dem die benoetigten Dokumente liegen. Und bitte nicht auf die Dokumentation bestimmter Prozesse oder Punkte verzichten, weil es da einen prima Link im Internet gibt. Das Internet koennte am Arbeitsplatz auch mal nicht funktionieren.

Des Weiteren finde ich es immer hilfreich eine Liste der moeglichen Ansprechpartner zu haben. Das betrifft sowohl die internen Kollegen, als auch die Personen beim Dienstleister oder Hersteller. Bei den internen Kollegen handelt es sich durchaus nicht nur um Techniker. Gibt es auch ein IT-Stoerungsmanagement? Einen Ansprechpartner im Fachbereich, welche die Anwendung nutzt?

Abschliessend gibt es noch eine Uebersicht moeglicher Vertragsdetails. Aus denen kann ich dann alles entnehmen, was beispielsweise fuer den Austausch von defekter Hardware oder zur Ticketerstellung benoetigt wird.

Als Ergaenzung sei fuer die Zukunft auf jeden Fall noch ein Punkt empfohlen. Die Nacharbeit! Ich moechte wissen, was zum Ausfall eines Systems gefuehrt hat und es abstellen. Ich moechte auch pruefen, wo meine Vorgehensweise noch verbessert werden kann. Alleine schon um beim naechsten Problem besser vorbereitet zu sein und den Anwender schnell(er) wieder ans Arbeiten zu bekommen.

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

Moeglicherweise ist ja Interesse an dem was ich die Tage eingerichtet habe. Es ging darum, dass ein Server installiert werden sollte, der Syslog Meldungen sammelt. Ich, als jemand der es gerne auch etwas sicherer hat, habe da auch an verschiedenen Stellen einiges „optimiert“, um Zugriff durch Unbefugte zu erschweren. Da durchaus mit einer groesseren Menge von Logs zu rechnen ist (>20.000/h), wollte ich, dass alles gleich in eine Datenbank laueft.

Basisinstallation und SSH
Begonnen habe ich mit der Basisinstallation eines Ubuntu 10.04.3 LTS. Da SSH eines der Administrationszugaenge ist, lege ich da natuerlich Wert auf eine ordentliche Konfiguration. Also die /etc/sshd_config geoeffnet und dort folgendes angepasst (Erklaerungen fuege ich mal aus der man-Page hinzu).

# The server disconnects after this time if the user has not successfully logged in.
LoginGraceTime 60

# Specifies whether root can log in using ssh(1).
PermitRootLogin no

# Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon.
MaxStartups 3:50:10

# Wohl selbst erklaerend
AllowUsers ramon

Ergaenzend empfehle ich auch noch PasswordAuthentication no zu setzen. Voraussetzung dafuer ist allerdings, dass man fuer alle berechtigen Benutzer die Anmeldung via SSH-Keys eingerichtet hat.

Des Weiteren kann man auch, bei Einsatz von mehreren Netzwerkkarten, den SSH-Daemon mit dem Schluesselwort ListenAddress an ein Interface binden. Leider hat das bei mir dazu gefuehrt, dass der Daemon nach dem Neustart des Servers nicht automatisch mit startete. Sehr seltsam.

Davon, den Port von 22 auf einen anderen Port zu legen, halte ich persoenlich nichts. Ich betreue einige Server im privaten und beruflichen Umfeld. Wenn da jeder seinen eigenen Port verwenden wuerde, wuerde ich ja verrueckt werden 🙂 Ausserdem sehe ich hier keinen wirklichen Gewinn an Sicherheit. Aber das ist natuerlich subjektiv.

Das Netzwerk
Um zumindest noch eine weitere Huerde einzubauen habe ich ueber /etc/hosts.deny und /etc/hosts.allow den Zugriff auf ssh etwas weiter reglementiert.

root@server:/etc# cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are not allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#

sshd: ALL

root@server:/etc# cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#

sshd: 192.168.150.0/255.255.255.0

Anmeldung an einem AD
Da die Maschine nicht nur von mir, sondern auch weiteren Anwendern genutzt werden soll, habe ich die Anbindung an ein AD konfiguriert. Das macht es, wenn man beispielsweise keinen Key hat, etwas leichter. Damit koennen sowohl bei der Anmeldung via SSH, aber auch beispielsweise beim sudo, einfach die Windows-Anmeldedaten verwendet werden. Die Einrichtung hierfuer geht relativ flockig von der Hand.

Im Rahmen der Installation der Pakete krb5-user, krb5-config und libpam-krb5 werden die wichtigsten Dinge soweit vorbereitet. Sollte, wie bei mir, die Abfrage wegen der Domaindaten nicht kommen kann man die Konfiguration via dpkg-reconfigure krb5-config nachholen oder die Datei /etc/krb5.conf von Hand anpassen. Die wichtigen Teile sind hier in libdefaults und realms zu finden.

[libdefaults]
default_realm = Domaene

[realms]
Domaincontroller = {
kdc = Domaincontroller
}

Als „Domaene“ habe ich den Namen der DNS-Domaene eingetragen und bei Domaincontroller den voll qualifizierten Namen eines Domaincontrollers. Damit nun die Anmeldung via SSH auch mit Windows-Anmeldedaten funktioniert muss in der /etc/ssh/sshd_config nur noch was angepasst werden.

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

Bitte nicht vergessen anschliessend dem SSH-Daemon die Konfigurationsaenderung mitzuteilen. Das kann sowohl via service ssh reload, als auch via service ssh restart erfolgen. Es funktioniert auch noch ein albekanntes /etc/init.d/ssh restart bei Ubuntu. Das wird allerdings mit einer entsprechenden Meldung, dass das Script zu einem Upstart Job konvertiert wurde, kommentiert.

So, ob die Anmeldung mit AD-Credentials klappt kann man uebrigens auch wie folgt testen.

root@server:~# kinit ramon@Domaene
Password for ramon@Domaene: ****
root@server:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ramon@Domaene

Valid starting Expires Service principal
11/10/11 10:28:51 11/10/11 20:27:43 krbtgt/Domaene@Domaene
renew until 11/10/11 20:28:51
root@server:~# kdestroy

Der Webserver
Da soweit alles fertig ist, kann mit der Installation der eigentlichen Dienste begonnen werden. Aus den Paketquellen habe ich den Apache-Server und MySQL installiert.

Bei der Installation der zwei Dienste gibt es nichts besonderes zu beachten. Also einfach ein aptitude install apache2 mysql-client libapache2-mod-php5 php5-mysql und warten. Die beiden letztgenannten Pakete werden spaeter fuer LogAnalyzer benoetigt. Die Installation ist tatsaechlich relativ unkompliziert. Aber vorab noch schnell den rsyslog konfiguriert.

rsyslog
Im Standard ist das Paket rsyslog bereits installiert, so dass wir nur noch, fuer die Nutzung von MySQL, das Paket rsyslog-mysql nachinstallieren muessen. Hier wird dann auch gleich eine Konfigurationsdatei in /etc/rsyslog.d/ erzeugt, die sich mysql.conf nennt. Im Rahmen der Paketinstallation kann die Konfiguration der Datenbank auch gleich erledigt werden. Nach Eingabe des Kennwortes fuer den Datenbankadministrator (root) kann ein Kennwort fuer den neuen Benutzer „rsyslog“, der dann Rechte auf der neuen Datenbank „Syslog“ haben wird, vergeben werden. Schaut man sich die mysql.conf anschliessend an, wird man etwas in der nachfolgenden Art finden.

root@server:/etc/rsyslog.d# cat mysql.conf
### Configuration file for rsyslog-mysql
### Changes are preserved

$ModLoad ommysql
*.* :ommysql:localhost,Syslog,rsyslog,rsyslog

Damit nun noch Logs angenommen werden muss noch die Datei /etc/rsyslog.conf angepasst werden. Fuer den Anfang reicht es aus, dass man die Module imudp und imtcp aktiviert, indem man in der genannten Konfiguration die entsprechenden Bereiche anpasst.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Nach dem Uebernehmen der Konfiguration (service rsyslog restart) kann man auch sehen, dass nun auf dem Port 514 was lauscht.

root@server:/etc# netstat -tulpen | grep 514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 0 36860 9598/rsyslogd
tcp6 0 0 :::514 :::* LISTEN 0 36861 9598/rsyslogd
udp 0 0 0.0.0.0:514 0.0.0.0:* 0 36856 9598/rsyslogd
udp6 0 0 :::514 :::* 0 36857 9598/rsyslogd

Die Profis unter uns nutzen natuerlich lsof, was dann wie folgt ausschauen wuerde.

root@server:/etc# lsof -i tcp:514 -i udp:514
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 677 syslog 3u IPv4 3327 0t0 UDP *:syslog
rsyslogd 677 syslog 4u IPv6 3328 0t0 UDP *:syslog
rsyslogd 677 syslog 5u IPv4 3331 0t0 TCP *:shell (LISTEN)
rsyslogd 677 syslog 6u IPv6 3332 0t0 TCP *:shell (LISTEN)

LogAnalyzer
Da nun alles soweit konfiguriert ist kann der LogAnalyzer angegangen werden. Den gibt es nicht aus den Paketquellen, was aber nicht wild ist, da die Installation, wie oben schon angedeutet, nicht wirklich hart ist. Via wget wird sich das aktuelle Paket von der Herstellerseite herunter geladen und installiert.

root@server:/# mkdir /var/www/loganalyzer
root@server:~# wget http://download.adiscon.com/loganalyzer/loganalyzer-3.2.3.tar.gz
Saving to: loganalyzer-3.2.3.tar.gz

root@server:~# tar xzf loganalyzer-3.2.3.tar.gz
root@server:~# cd loganalyzer-3.2.3
root@server:~/loganalyzer-3.2.3# cp -R src/ /var/www/loganalyzer/
root@server:~/loganalyzer-3.2.3# cp contrib/ /var/www/loganalyzer/
root@server:~/loganalyzer-3.2.3# cd /var/www/loganalyzer
root@server:~/var/www/loganalyzer# chmod +x configure.sh secure.sh
root@server:~/var/www/loganalyzer# ./configure.sh
root@server:~/var/www/loganalyzer# cd ..
root@server:~/var/www# chown -R www-data:www-data loganalyzer

Soweit so… ja, fast fertig. Jetzt sollte man noch das php5-Module fuer Apache mit a2enmod php5 aktivieren. Ist das geschehen kann man den LogAnalyzer konfigurieren. Dafuer verbindet man sich einfach per Webbrowser auf http://server/loganalyzer und geht die Punkte durch.

Was habe ich noch gemacht? Ergaenzend hierzu habe ich fuer Apache SSL aktiviert und einen entsprechenden Redirect konfiguriert, so dass der Aufruf nur noch ueber https:// moeglich ist. Ergaenzend habe ich noch AuthType Basic konfiguriert, so dass tatsaechlich nur berechtigte Benutzer auf die Seite zugreifen duerfen.

Fuer eine „mal eben“-Installation ist das aus meiner Sicht schon mal recht solide. Es gibt noch ein paar Dinge, die ich verbessern kann. Fuer ssh PasswordAuthentication no setzen. Die Authentifizierung fuer Apache auch an das AD „koppeln“. RELP (Reliable Event Logging Protocol) aktivieren. Eigene Logs des Servers auf einem anderen Server ablegen, um im Falle eines Vorfalls keine modifizierten oder geloeschten Logs vorzufinden. Den Zugriff auf den Webserver ueber /etc/hosts.allow und /etc/hosts.deny weiter reglementieren.

Da ich den Beitrag quasi aus dem Kopf erstellt habe hoffe ich, dass ich keine wichtigen Dinge vergessen habe. Wenn es Fragen, Anmerkungen oder Ergaenzungen gibt, einfach die Kommentare nutzen.