adminstories

Wie geht es hier weiter?

nospam@example.com (Dirk Deimeke) — Wed, 21 Mar 2012 09:57:00 +0100

Mich hat der Weggang von Ramon auch hart getroffen und ich hatte jetzt die Gelegenheit, ein paar Gedanken in den Fortbestand dieses Blogs zu investieren.

Vorab: Die Domain ist bis zum 22.11.2012 bezahlt und so lange lasse ich das Blog wenigstens Online.

Adminstories ist (war) ein Projekt von Ramon und mir und ist (war) mit beiden von uns eng verbunden. Administration, auch als "Meta-Thema" liegt mir am Herzen und ist mein Steckenpferd, ich werde es aber neben anderen Verpflichtungen nicht schaffen, einmal in der Woche einen Artikel zu schreiben.

Ein Blog lebt aber von Kontinuitaet und von regelmaessigen Eintraegen. Momentan sehe ich nicht, auch nicht mit "Fremd"-Autoren, dass diese Kontinuitaet gewaehrleistet wird.

Mit anderen Worten: Das Blog wird sterben.

Aber ich kann Euch beruhigen, die Inhalte bleiben im Netz. Ich denke gerade darueber nach, die Artikel in ein Wiki einzubauen und so online zu behalten. Dazu kommt, dass ein neues Format im Entstehen ist. Nur so viel dazu, es wird um Open-Source-Software gehen und das unabhaengig vom zu Grunde liegenden Betriebssystem.

Das Thema Administration werde ich in meinem eigenen Blog weiter verfolgen.

Eure Gedanken dazu interessieren mich.

KW 2012/11 - Fundstuecke

nospam@example.com (Ramon Kukla) — Mon, 19 Mar 2012 00:00:00 +0100

Kalenderwoche 10, 12.-18.03.2012

Fuer alle, die gerne etwas mehr als nur an der Oberflaeche kratzen moechten ist sicher "Collecting and analyzing Linux kernel crashes" sowie der auf dem ersten Artikel aufbauende Beitrag "Analyzing Linux kernel crash dumps with crash" interessant.

Planaenderung

nospam@example.com (Ramon Kukla) — Fri, 16 Mar 2012 09:00:00 +0100

Hallo liebe Leser. Heute gibt es mal keinen klassischen Beitrag, sondern mehr eine Information aus dem "Maschinenraum".

Ich, also Ramon, werde mich (erst mal?) aus allen Dingen, die das Internet betreffen (exklusive Mail und mal nach Informationen suchen) zurueck ziehen. Damit einhergehend werde ich auch meine Mitarbeit an verschiedenen Projekten beenden. Damit ist dann auch sowas wie Adminstories gemeint.

Das ist insofern schade, als dass Dirk und ich noch tolle Ideen hatten und ich Dirk nun im Grunde alleine lasse. Das ist doof fuer Dirk und schade fuer mich. Aber fuer mich gibt es (in erster Linie) familiaere Gruende, die mich zu dem Schritt bewogen haben. Im Detail ist das ganze natuerlich ungleich komplexer, aber hat auf Adminstories auch nichts zu suchen ;)

Ich danke allen, die uns immer gelesen haben und mit tollen Kommentaren belohnt haben. Ich danke vor allem aber auch Dirk, der fuer mich persoenlich ein fantastischer Projektpartner war. Das Ende kommt auch fuer ihn sehr ueberraschend, aber er hat Verstaendnis fuer meine Gruende. Leider war mein Ende nicht nur sehr ueberraschend. Meine "interne" Ankuendigung war auch sehr ungluecklich. Aber leider ist es so, dass man eben auch Fehler macht, die nicht "mal eben" wieder gut zu machen sind. Lernen kann man also immer etwas. Nicht nur im technischen, sondern auch im sozialen Umfeld.

Danke und bleibt Dirk treu!

KW 2012/10 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 12 Mar 2012 00:00:00 +0100

Kalenderwoche 10, 05.-11.03.2012

Der sehr desillusionierende Artikel Filenames and Pathnames in Shell: How to do it correctly listet auf, was man alles unternehmen muesste, um moeglichst alle erlaubten Dateinamen in Suchen und Schleifen zu treffen. Ich zitiere mal Paul, von dem ich den Link habe: "This makes me cry.".

Mal anschauen, vielleicht ist das ja etwas: Nmon - a nice monitoring tool for Linux

Skripte

nospam@example.com (Dirk Deimeke) — Fri, 09 Mar 2012 09:00:00 +0100

Warum ist eigentlich das Verstaendnis (wenigstens einer) Skriptsprache in der Systemadministration so wichtig?

Die Antwort ist sehr einfach: Weil sich damit Aufgaben automatisieren lassen. Automatisierung fuehrt als Nebennutzen dazu, dass Arbeitsablaeufe reproduzierbar werden.

Anders als bei in Maschinensprache uebersetzten Programmen bestehen Skripte aus ASCII-Code, der auf dem System lesbar ist. Das sollte man nicht mit Dokumentation verwechseln, aber es hilft einem selber und eventuell den Kollegen nachzuvollziehen, was ein Skript tut und warum es bestimmte Resultate oder Fehler zeigt.

Dabei ist es enorm hilfreich, einen Programmierstil zu verwenden, der die Lesbarkeit eines Skriptes auch foerdert und das ist unabhaengig von der gewaehlten Sprache. Ja, auch in Perl kann man lesbaren Code schreiben und das ist gar nicht einmal so schwer. Ich habe einige Administratoren kennen gelernt, die es als Schutz ihres Arbeitsplatzes verstanden haben, Code zu schreiben, den niemand ausser ihnen versteht. Das grosse Problem dabei ist, dass sie selber ihren eigenen Code sechs Monate nach dem sie ihn geschrieben haben nicht mehr verstehen.

Nur ein Gedanke: Wenn die Arbeit eh doppelt gemacht werden muss, kann der Chef sich auch einen neuen dafuer suchen. Jeder ist ersetzbar, aber wenn jemand (sehr) gute Arbeit leistet, ist die Huerde fuer eine Kuendigung hoeher. Die eigene Arbeitsqualitaet und die Professionalitaet ist der beste Schutz vor Kuendigung.

Ja, auch klassische Administratoren sind Programmierer, wenn sie ihren Job gut machen, da kann Admin auch mal ein Programmierbuch zur Hand nehmen, um sich fortzubilden. Bei O'Reilly ist The Art of Readable Code erschienen, was sich bei Paperc gratis nach kostenfreier Anmeldung lesen laesst.

Den Jeningen, denen das mit dem Buch zu viel ist, moechte ich drei einfache Tipps mit auf den Weg geben:

Nutzt sprechende Funktions- und Variablennamen.
Ja, es ist mehr Arbeitsaufwand, aber der macht sich bezahlt. Ich bekomme gerade noch zugerufen, dass man sich die Ungarische Notation mal anschauen sollte. Dem schliesse ich mich an, die sieht gar nicht schlecht aus.

Nutzt Einrueckungen, wenn die Programmiersprache es zulaesst.
Einrueckungen strukturieren Code und machen ihn leichter ueberschaubar. Tipp am Rande: Ein Befehl pro Zeile reicht, Zeilen nach Moeglichkeit nur so lang machen, dass sie auf dem Bildschirm auch in einer Zeile darstellbar sind.

Keine Angst vor Leerzeichen und Leerzeilen.
Sinnvoll eingesetzt helfen auch sie, die Struktur leichter zu erfassen.

Selbstverstaendlich darf man auch Kommentare verwenden und wenn man im Hinterkopf behaelt, dass bei Codebloecken, deren Laenge eine Bildschirmseite uebersteigt, die Fehlerquote exponentiell ansteigt, ist alles im gruenen Bereich.

Die Wahl der geeigneten Skriptsprache ist auch haeufig ein Thema. Es schadet nichts, wenn man viele Konzepte kennt, um die richtige Sprache fuer den richtigen Zweck auszuwaehlen. Meistens aber sind die Sachzwaenge so, dass man eine zu benutzende Skriptsprache vorgesetzt bekommt, in diesem Fall kann man nicht waehlen, das macht es einfach, oder dass man mit vielen Systemen zu tun hat, da wuerde ich die Sprache waehlen, die in der eigenen Infrastruktur am weitesten verbreitet ist.

Fuer den Bereich, in dem ich taetig bin, wuerde die Wahl immer wieder auf Perl fallen und das gleich aus zwei Gruenden: Ich mag Perl ;-) und es ist auf jedem System (inklusive Windows) vorinstalliert. Bei Shell-Skripten faellt die Wahl auf die Korn Shell, weil die auf allen Truemmern installiert ist.

KW 2012/09 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 05 Mar 2012 00:00:00 +0100

Kalenderwoche 09, 27.02.-04.03.2012

Eine gute Uebersicht von vim-Befehlen gibt Best of Vim Tips. Gibt es eigentlich noch Bekloppte so wie mich, die vim tippen, wenn sie vim meinen und vi tippen, wenn sie vi meinen?

Lesenswert ist die Richtigstellung How I can be wrong about the death of sysadmin jobs, der noch einmal richtigstellt, dass DevOps eher das Ende der stupiden Arbeiten als das Ende der Systemadministration sind.

Ein guter Einstieg in den Job als Linux-Admin sind die 10 Tipps für den Start als Linux-Admin, hier das englische Original Ten Things I Wish I Knew When Becoming A Linux Admin.

Huch, "neues" ueber die BaSH zeigt Unknown Bash Tips and Tricks For Linux.

Aufwaende bei einer Migration

nospam@example.com (Ramon Kukla) — Fri, 02 Mar 2012 09:00:00 +0100

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.

KW 2012/08 - Fundstuecke

nospam@example.com (Ramon Kukla) — Mon, 27 Feb 2012 00:00:00 +0100

Kalenderwoche 08, 20.-26.02.2012

Vieles hatten wir schon zu Git. Eine zweiteilige Einleitung, die mir auf viele ungestellte Fragen Antworten gegeben hat, habe ich bei Marco Schmidt gefunden. Teil 1 und Teil 2

Das Backup, technisch

nospam@example.com (Ramon Kukla) — Fri, 24 Feb 2012 09:00:00 +0100

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/&lowast; /srv/pwd /srv/www/&lowast; /usr/local/src/scripts /usr/share/munin/plugins /var/run/munin /var/spool/cron/crontabs/&lowast; /srv/trc/&lowast;/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 <<EOF
open $HOST
cd $BACKUPDIRFTP
mdelete *$(date -d "7 days ago" +%Y%m%d)*
quit
EOF

logger -t ftpbackup.bash -i "Finishing ftpbackup"

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! :)

KW 2012/07 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 20 Feb 2012 00:00:00 +0100

Kalenderwoche 07, 13.-19.02.2012

Linux command line basics for beginners: Part 3

FAQ: Mein mysqldump zerstoert meine Umlaute erklaert wunderbar, wie man Daten vernuenftig konvertieren kann, die eine UTF8-Anwendung ohne Beachtung des Encodings in eine latin1-Datenbank geschrieben hat.

Wechsel der Software

nospam@example.com (Dirk Deimeke) — Fri, 17 Feb 2012 09:00:00 +0100

Wer uns kennt der weiss, dass wir unter notorischer Langeweile leiden. Daher sind wir immer froh wenn es etwas zu gibt. Aktuell haben wir dann aber doch mehr als an Aufgaben, als gut fuer uns ist. Ramon und ich stecken gerade mitten in zwei Migrationen, die "eigentlich" (auf dem Papier) ganz einfach sind, aber - wie meistens - steckt die Tuecke im Details.

Mit RadioTux migrieren wir gerade auf neue, durch Sponsoren bereitgestellte Server, neben einem Wechseln von Debian Lenny auf Squeeze wechseln wir auch von Wordpress nach Serendipity. Das wurde schon gefuehlte 100 Mal von verschiedenen Leuten vor uns gemacht und sollte "eigentlich" (boeses Wort!) locker von der Hand gehen.

Das Problem ist, dass Wordpress auf der alten Infrastruktur Daten im UTF8-Format in mit latin1-kodierte Tabellen geschrieben hat. Passend zur Umstellung erschien dieser Artikel von Kristian Koehntopp, der uns naeher an die Loesung bringt, aber noch nicht alles bereinigt.

Es bleibt spannend.

Mit unseren root-Servern wechseln wir ebenfalls, von Hetzner zu Manitu und von Ubuntu 10.04 LTS auf Debian Squeeze, bis jetzt - drei Mal auf Holz klopfen - sieht alles sehr gut aus.

In dem Zusammenhang moechten wir noch mal anmerken, dass wir immer auf der Suche nach Gastbeitraegen sind. Gerade jetzt haette es zumindest gepasst. ;)

KW 2012/06 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 13 Feb 2012 00:00:00 +0100

Kalenderwoche 06, 06.-12.02.2012

Ich habe linuxcareer.com gefunden und aus den Artikeln haben es gleich drei in die Fundstuecke geschafft.

Ubuntu command line basics for beginners: Part 1

Writing manual pages on Linux

How to configure NFS on Linux

Von Fstransform (file-system transformation tool) habe ich noch nichts gehoert, kann mir aber vorstellen, es einzusetzen, wenn ich BTRFS verwenden moechte: Fstransform zur Umwandlung von Linux-Dateisystemen

Screen

nospam@example.com (Dirk Deimeke) — Fri, 10 Feb 2012 09:00:00 +0100

Ich nutze schon sehr lange GNU Screen und das obwohl ich weiss, dass tmux der neue "heisse Scheiss" ist. Das liegt schlicht daran, dass ich tmux in drei Versuchen nicht auf Solaris 8 (ja, das gibt es noch) kompiliert bekommen habe.

Die Definitionen fuer Screen variieren, manche nennen es einen "terminal multiplexer" andere einen "textual window manager".

Für mich gibt es vier sehr gute Gruende, Screen zu benutzen.

Kommandozeilen-Sessions in Screen laufen auch dann weiter, wenn ich mich vom Rechner abmelde oder getrennt werde. Das ist vor allem auch dann interessant, wenn man zwischendurch den Rechner wechselt.

Mit Screen ist es moeglich, mehrere Benutzer an der gleichen Sitzung teilhaben zu lassen. Das laesst sich fuer Schulungen oder das Vier-Augen-Prinzip bei wichtigen Arbeiten verwenden.

Ueber eine einzige ssh-Verbindung lassen sich mit einer Screen-Umgebung bis zu 40 parallele Kommandozeilen-Sitzungen betreiben.

Screen kann benutzt werden, Kommandozeilensitzungen zu gruppieren. So nutze ich ein Setting, dass ich "daily" genannt habe, was ssh-Verbindungen zu den Infrastruktur-Servern enthaelt. Weitere Sitzungen enthalten die fuer bestimmte Arbeiten thematisch sortierten Verbindungen. Bei Arbeiten an einem Cluster haelt eine Umgebung beispielsweise Verbindungen zu allen Cluster-Nodes, um schnell umschalten zu können.

Basis für meine Konfigurationsdatei ist die, die ich im Linuxwiki gefunden habe, dort gibt es auch eine sehr gute Erklaerung der Datei.

# Tabs
caption always "%{kw}%-w%{ky}%n %t%{-}%+w %=%{bw}@%H%{kw} %D %Y-%m-%d %c"
hardstatus string "[%H]"

# Ctrl-PageUp/Down or Alt-PageUp/Down or Alt-left/right
bindkey ^[[5;5~ prev
bindkey ^[[6;5~ next
bindkey ^[[5;3~ prev
bindkey ^[[6;3~ next
bindkey ^[[1;3D prev
bindkey ^[[1;3C next

# putty uses Ctrl-PageUp/Down by itself
# so only Alt-PageUp/Down and Alt-left/right
bindkey ^[^[[5~ prev
bindkey ^[^[[6~ next
bindkey ^[^[OD prev
bindkey ^[^[OC next

# Ctrl-Shift-T
bindkey ^T screen bash

# Scrollen im xterm
termcapinfo xterm|xterms|xs|rxvt ti@:te@

# Detach mit logout
bind d
bind d detach
bind ^d pow_detach

sessionname migration
screen -t mon bash
screen -t foo ssh foo.ptlx.de
screen -t bar ssh bar.ptlx.de
screen -t eml ssh eml.ptlx.de
screen -t web ssh web.ptlx.de

Die letzten Zeilen sind von mir, der sessioname wird bei screen -ls angezeigt und die Sitzung laesst sich (im Beispiel) mit screen -rx migration verbinden.

screen -t Titel Befehl oeffnet ein neues "Fenster" mit dem angegebenen Titel und fuehrt dort den genannten Befehl aus.

Ich habe mir zusaetzlich noch eine Funktion definiert und in meine .bashrc gesteckt, die eine neue ssh-Verbindung in einem neuen Fenster oeffnet.

function ses (){ # session ssh
screen -t $1 ssh $1
}

Screen ist relativ alt und wird leider nicht mehr aktiv weiterentwickelt. Eine gute Einfuehrung in Screen - GNU Screen: an introduction and beginner's tutorial - stammt aus dem Jahr 2004 und funktioniert heute noch.

KW 2012/05 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 06 Feb 2012 00:00:00 +0100

Kalenderwoche 05, 30.01.-05.02.2012

Eine relativ einfache Einführung in Git gibt git - the simple guide.

Projektleitung und Talent beschreibt, dass man Talent braucht, um in etwas - in diesem Fall Projektleitung - richtig gut zu werden. Das gilt nicht nur fuer die Projektleitung.

developerWorks stuerzt sich auf Perfomance-Analysen: The performance detective: Where does it hurt?

mailman

nospam@example.com (Ramon Kukla) — Fri, 03 Feb 2012 09:00:00 +0100

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

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.

KW 2012/04 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 30 Jan 2012 00:00:00 +0100

Kalenderwoche 04, 23.-29.01.2012

RFC for the 7XX Range of HTTP Status codes - Developer Errors

One Div Zero: A Brief, Incomplete, and Mostly Wrong History of Programming Languages

Ein lesenswerter Artikel mit einem sehr provokanten Titel: The death of system administration: I'm all for it, ich muss ihm Recht geben.

In die gleiche Richtung und ebenfalls gut geschrieben: DevOps and me

Das Backup

nospam@example.com (Ramon Kukla) — Fri, 27 Jan 2012 09:00:00 +0100

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.

KW 2012/03 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 23 Jan 2012 00:00:00 +0100

Kalenderwoche 03, 16.-22.01.2012

Sehr lohnenswerter Artikel: What you can find out about the memory usage of your Linux programs

Hier ist eine sehr gute Einführung in die Arbeit mit der Kommandozeile: LinuxCommand.org: Learn the Linux command line. Write shell scripts.

DeveloperWorks hat in der Reihe Scripting KVM with Python den zweiten Teil veröffentlicht: Add a GUI to manage KVM with libvirt and Python

git - der einfache einstieg - kein schnick-schnack!

Gute Gegenueberstellung der alten und der neuen Befehle: Deprecated Linux networking commands and their replacements

Zentrale .bashrc (3)

nospam@example.com (Dirk Deimeke) — Fri, 20 Jan 2012 09:00:00 +0100

Es ist Zeit für einen weiteren Schluck aus der zentralen .bashrc (Teil 1, Teil 2). In diesem Teil geht es um Aliases.

Da alles sowohl unter Solaris, wie auch unter Linux, jeweils in verschiedenen Versionen, laufen muss, sehen ein paar Konstrukte vielleicht seltsam aus, erfuellen aber ihren Zweck.

Die Funktion gehe ich mal von oben nach unten durch.

Das ll-Alias ist ein Relikt aus alten Tagen, dass ich gar nicht mehr verwende. ls -ltr sortiert nach Datum und zeigt die aktuellsten Dateien zum Schluss.

vi und vim benutze ich gerne mit Zeilennummern, letzteren auch mit eingeschaltetem Syntax-Highlighting.

Unter Linux und Solaris kommen bei mir unterschiedliche Versionen von grep zum Einsatz, das mache ich, damit grep -q bei den folgenden Eintraegen funktioniert.

Ich nutze kein PuTTY, sondern Cygwin, um unter Windows per SSH Verbindungen auf die Truemmer herzustellen. Wenn ich mich auf meiner Linux- oder Solaris-Adminmaschine befinde, nutze ich screen, um von dort auf andere Server zuzugreifen. Das echo-Kommando aendert den Fenstertitel und wenn noch keine Screen-Session namens daily, build, work oder chg existiert, wird eine mit der entsprechenden Konfiguration angelegt.

Das memory-Alias gibt eine Idee darueber, wo gerade der Speicher verbraten wird.

dfh und duh verweisen auf die entsprechenden Perl-Skripte.

Und zuletzt psg macht einen grep auf die laufenden Prozesse.

KW 2012/02 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 16 Jan 2012 00:00:00 +0100

Kalenderwoche 02, 09.-15.01.2012

Habe gerade gesehen, dass es sogar einen Planeten fuer Sysadmin-Ressourcen gibt: Planet Sysadmin

Damit es endlich mal jeder versteht: Help! Linux ate my RAM!

Logwatch

nospam@example.com (Dirk Deimeke) — Fri, 13 Jan 2012 09:00:00 +0100

Der Eine oder andere hat vielleicht meinen Blogartikel gelesen, in dem ich sehr kurzfristig eine Ausfallzeit unseres Mailservers bekannt geben musste. Das Problem, dass die Festplatte defekt war, lag direkt vor unserer Nase, wir haben es nur nicht gesehen.

Vorzusingen nach der Weise Blowing in the Wind:

The answer, my friend, is written in the logs, ...

Auf unseren Servern haben wir Logwatch eingerichtet, um taeglich einen "relevanten" Auszug aus den Logdateien via E-Mail zu bekommen. Enthaltene Informationen sollten so wichtig sein, dass sie nicht ignoriert werden duerfen. In diesen E-Mails waren auch Anzeichen fuer das Festplatten-Problem zu finden.

Es kam natuerlich wie es kommen musste, die E-Mails kamen tagtaeglich, aber niemand hat sich darum gekuemmert.

Was ist passiert? Die Nachrichten enthielten viel zu viel Zeug, das nicht interessant und nicht wichtig war. Und es zeigt, dass Administrationsaufgaben nicht nur Spass machen, manches ist nervtoetend und trotzdem noetig.

In diesem Artikel wollte ich "eigentlich" darauf hinweisen, wie ich das Loghandling in den Griff bekommen habe und wie ich schnell und effizient Logs durchsuche und pro-aktiv Fehler finde. Um es kurz zu machen, so ist es nicht. Wenn jemand eine Loesung dafuer hat nur her damit.

Bis dahin werden wir auf Fehler reagieren, die uns das Monitoring zeigt und Tag fuer Tag - wenn die Fehler weniger werden auch wieder weniger intensiv - uns durch die Logs wuehlen und (hoffentlich keine) Fehler finden.

Wir freuen uns immer auf Eure Kommentare und in diesem Fall sind wir besonders interessiert, von Euch zu hoeren, wie Ihr mit Logdateien umgeht.

Richtig mailen - Nachtrag

nospam@example.com (Ramon Kukla) — Tue, 10 Jan 2012 09:00:00 +0100

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.

KW 2012/01 - Fundstuecke

nospam@example.com (Ramon Kukla) — Mon, 09 Jan 2012 00:00:00 +0100

Kalenderwoche 01, 02.01.2012-08.01.2012

Die Links hatten wir noch nicht? Kann ich gar nicht glauben!

Etwas aelter, aber interessant zu lesen ist "How To Look Like A UNIX Guru".

Eine Uebersicht von Unterschieden (Befehle, Verzeichnisse, Konfigurationsorten, etc.) zwischen einzelnen Unixoiden Systemen gibt es sowohl hier, als auch hier. Beides sehr empfehlenswert!

Ich (Dirk) habe schon mehrfach gesagt (aber vermutlich noch nicht hier geschrieben), dass ich von Webmin als Loesung zur Administration eines Servers nichts halte, dementsprechend weiss ich nicht, was ich von Submin - Subversion Web Administration zu halten habe.

Richtig mailen

nospam@example.com (Ramon Kukla) — Fri, 06 Jan 2012 09:00:00 +0100

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

KW 2011/52 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 02 Jan 2012 00:00:00 +0100

Kalenderwoche 52, 26.12.2011-01.01.2012

Sehr guter Artikel ueber Zusammenarbeit in der Systemadministration, welche Stolpersteine gibt es und wie kann man damit umgehen? - Collaboration in System Administration

Auf ein neues Jahr

nospam@example.com (Ramon Kukla) — Sun, 01 Jan 2012 00:00:00 +0100

Da ist es herum das erste Jahr...

Angefangen haben wir am 01.01.2011 mit dem Artikel "Und noch ein Blog". Wir hatten uns das Ziel gesetzt, jede Woche mindestens einen Artikel zu publizieren, was uns auch gelungen ist. Dabei haben wir versucht einen bunten Themenmix zu praesentieren. Eine Mischung, wie sie auch im klassischen Arbeitsumfeld des Administrators zu finden ist. Also was ueber Netzwerk, Scripting, etwas Programmierung, Debugging, Management und "Business-Kram". Eine Uebersicht aller Artikel ist uebrigens immer ueber die Artikeluebersicht zu bekommen.

Ende April haben wir dann unsere Artikelserie um die Fundstuecke ergaenzt. Uns waren immer wieder kleinere Tipps, Ideen und Webseiten untergekommen, die fuer einen Artikel nicht genug Futter geboten hatten, aber einfach zu interessant waren, um sie unter den Tisch fallen zu lassen.

Ende August haben wir dann einen weiteren Schritt vollzogen. Wir haben das Blog von Dotclear nach Serenditpiy migriert. Wir waren nicht unzufrieden mit Dotclear. Aber wir beide haben einfach mehr Erfahrung mit Serendipity, so dass wir uns fuer diesen Schritt entschieden haben.

Alles in allem sind im Jahr 2011 etwas mehr als 100 Beitraege enstanden. Mit diesen haben wir etwas ueber 170 Kommentare ernten koennen. Im Moment haben wir in der Woche zwischen 200 bis 300 Besucher. Das ist schon solide, laesst aber vor allem aber auch noch Luft nach oben :-) Wobei uns klar ist, dass wir bei der doch relativ geringen Artikelfrequenz und der teilweise doch sehr technischen Beitraege kaum, sagen wir mal, Mainstreamkompatibel sein werden.

Unterm Strich sind wir mit der Entwicklung bis hierher zufrieden. Aber natuerlich moechten wir auch nicht still stehen. Wir moechten uns weiter entwickeln. Daher haben wir fuer das Jahr 2012 einige Plaene. Neben dem grossen Plan, die Weltherrschaft an uns zu reissen, haben wir noch ein paar kleinere Ideen in der Schublade.

So planen wir in naher Zukunft eine Artikelreihe, in der wir Personen aus dem IT-Umfeld vorstellen moechte, die in der Regel im "Hintergrund" zu finden sind. Des Weiteren liebaeugeln wir mit einem regelmaessigen Podcast und dem Publizieren von Gastbeitraegen. Natuerlich moechten wir dabei die bestehenden Artikelreihen weiter laufen lassen.

Wie Anfang 2011 moechten wir auch heute aufrufen sich zu beteiligen. Jeder ist eingeladen, uns Artikel oder auch Artikelideen zu schicken. Wir schauen dann, inwieweit das passt und eingebaut werden kann. Im Impressum findet ihr entsprechende Kontaktmoeglichkeiten.

Auf ein neues, schoenes und interessantes Jahr.

Sysstat

nospam@example.com (Dirk Deimeke) — Fri, 30 Dec 2011 09:00:00 +0100

Monitoring ist eine der Kernaufgaben in der Administration. Warum und wie viel man ueberwachen sollte, ist in dem - meiner Meinung nach - besten Artikel zum Thema beschrieben: The Philosophy of Monitoring. Wir werden das sicherlich hier auch noch einmal ausfuehrlich thematisieren.

Es gibt eine grosse Menge an Open Source Monitoring-Loesungen, die verschiedene Anwendungszwecke abdecken. Nur um einmal ein paar Namen zu nennen, fuehre ich hier Cacti, Munin, Nagios, Icinga, Zabbix, Smokeping, Centreon und viele andere mehr (die fett gedruckten setzen Ramon und ich fuer unsere Server ein).

In die gleiche Richtung, wenn auch nicht ganz, stossen die SYSSTAT-Utilities. Die Utilities gibt es für nahezu jedes Unix-artige Betriebssystem und sind vermutlich bei allen Linux-Systemen in den Standard-Paketquellen enthalten. Es gibt einen guten Übersichtsartikel zu Sysstat im Linux-Magazin.

Fuer mich besonders wichtig ist das "System Activity Reporting", bei Sysstat uebernimmt die Aufgabe das Programm sar. Es bereitet die Daten, die durch den "System Activity Data Collector" (sadc) gesammelten Daten für Menschen lesbar auf. Der Datensammler sadc liest eine "lange" Reihe von aktuellen Systemwerten aus dem virtuellen proc-Dateisystem und schreibt sie in eine Binaerdatei. Da das nur sehr wenig Last erzeugt (nahezu gar keine), gibt es keinen Grund, den Datensammler nicht auf jedem installierten Linux oder Unix mitlaufen zu lassen. Die gesammelten Werte sind bei der Fehleranalyse oder der nachtraeglichen Untersuchung von Performance-Problemen enorm hilfreich.

Doch jetzt einmal "Schritt fuer Schritt".

Installiert wird Sysstat ueber das Paketmanagement oder man uebersetzt es sich durch den "klassischen Dreisatz" - ./configure ; make ; make install - selber.

Unter Debian-Systemen (und Ubuntu) muss in der Datei /etc/default/sysstat der Parameter ENABLED auf true gesetzt werden, sonst werden die Daten nicht gesammelt.

Die Datensammlung selber passiert via cron. In der Datei /etc/cron.d/sysstat finden sich die folgenden Zeilen:

# The first element of the path is a directory where the debian-sa1
# script is located
PATH=/usr/lib/sysstat:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin

# Activity reports every 10 minutes everyday
5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

# Additional run at 23:59 to rotate the statistics file
59 23 * * * root command -v debian-sa1 > /dev/null && debian-sa1 60 2

Dass debian-sa1 benutzt wird, ist eine Besonderheit von Debian, ansonsten heisst das Programm einfach sa1.

Der erste Cron-Eintrag sorgt dafuer, dass alle 10 Minuten ein Satz von Werten aufgezeichet wird. Das reicht, um einen Ueberblick ueber das System zu haben. Wenn man eine hoehere Aufloesung moechte, ist das zu aendern.

Der zweite Eintrag rotiert die Logdateien, bei Debian liegen sie unter /var/log/sysstat.

Welche Werte alle aufgezeichnet werden, zeigt ein sar -A, fuer einen Ueberblick, empfehle ich aber das Java-Programm kSar, das die Daten grafisch aufbereitet. Das oben im Artikel angezeigte Bild ist damit entstanden. Den kompletten Report fuer den gestrigen Tag von unserem Webserver findet Ihr in der PDF-Datei bar.pdf (3.5 MB).

KW 2011/51 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 26 Dec 2011 00:00:00 +0100

Kalenderwoche 51, 19.-25.12.2011

Let it Snow On Your Desktop

Learn Linux, 302 (Mixed environments): Performance tuning

100 Vim commands every programmer should know

30 Best Sources For Linux / *BSD / Unix Documentation On the Web

The 10 Most Important Open Source Projects of 2011

A bunch of tips for improving your postfix setup

Verfuegbarkeit

nospam@example.com (Dirk Deimeke) — Fri, 23 Dec 2011 09:00:00 +0100

Was haben eigentlich die vielen Neunen ("9") zu bedeuten?

Die Neunen geben die Verfuebarkeit eines (definierten) Computer-Systems im Rahmen eines Service-Level-Agreements (SLA) in Prozent an. Den deutschen Begriff Dienstguetevereinbarung (DGV) habe ich im verlinkten Wikipedia-Artikel zum ersten Mal gelesen. Sagt man, dass ein System fuenf Neunen hat, ist damit gemeint, dass es zu 99.999% verfuegbar ist. Die Anzahl der Neunen bestimmt dabei die Verfuegbarkeitsklasse.

Allerdings gibt es bei der Berechnung der Verfuegbarkeit Stolpersteine, die beruecksichtigt werden muessen. Ich greife nur einige wenige heraus.

Geplante Wartungsfenster zaehlen im Normalfall nicht zur Verfuegbarkeit. Natuerlich kann man vertraglich anderes vereinbaren oder den Wartungsvertrag beliebig teuer machen. Wer nur minimale Ausfaelle auch bei Wartungsaufgaben haben moechte, muss entsprechend viel Hardware kaufen, um auch die geplante Nicht-Verfuegbarkeit einzelner Komponenten (wegen Upgrades beispielsweise) abzudecken.

Die Definition des Systems fuer die die Vereinbarung gilt, ist sehr wichtig. Man kann sich leicht vorstellen, dass "laeuft" eine schlechte Definition ist. Was waere ein Server ohne Netzwerkverbindung? Oder man nimmt die Verfuegbarkeit eines Arbeitsplatzes. Es ist denkbar, dass es relativ (!) leicht ist, eine hohe Verfuegbarkeit des Client-Betriebssystems werktags in der Zeit von 07:00-18:00 Uhr zu vereinbaren. Wenn ein Rechner ausfaellt, stellt man "einfach" einen Ersatzrechner auf, vorausgesetzt, dass die Einstellungen auf Servern liegen. Aber zu einem Arbeitsplatz gehoert viel mehr, wie beispielsweise das Mailprogramm, der Zugriff auf Datenbanken und auf andere Software, mit der die Arbeit erledigt wird. Vielleicht sogar die Verbindung zum Internet. Immer, wenn eine Komponente nicht zugreifbar ist, laeuft die Zeit und knabbert an den Neunen. Im schlimmsten Fall oder eher im Normalfall fallen Systeme selten gleichzeitig aus.

Im Normalfall gibt es Vereinbarungen für verschiedene Bereiche, die sich auch deutlich voneinander unterscheiden koennen. Eine "nahezu hundertprozentige" Verfuegbarkeit des Netzwerkes wird ja schon fast vorausgesetzt. Was aber, wenn die Bits nur einzeln durch das Netz purzeln? Dann muss auch noch die Dienstequalitaet vereinbart werden (das ist aber hier nicht Bestandteil).

Ein Jahr im gregorianischen Kalender hat 365,2425 Tage = 365 Tage, 5 Stunden, 49 Minuten, 12 Sekunden = 31.556.952 Sekunden - um die krumme Zahl auszugleichen, haben wir Schaltjahre. Ein "normales Jahr" hat 365 Tage und somit 31536000 Sekunden, gebraeuchlich ist auch, ein Jahr auf 360 Tage oder 31104000 Sekunden zu reduzieren.

Wenn man in einem "normalen Jahr" Verfuegbarkeiten definieren moechte und die Systeme sollen rund um die Uhr laufen, dann duerfen die Systeme maximal die folgenden Ausfallzeiten pro Jahr haben.

Verfuegbarkeit 90% ~ Maximaler Ausfall von 3153600 Sekunden ~ 36 Tage, 12 Stunden
Verfuegbarkeit 99% ~ Maximaler Ausfall von 315360 Sekunden ~ 3 Tage, 15 Stunden, 36 Minuten
Verfuegbarkeit 99.9% ~ Maximaler Ausfall von 31536 Sekunden ~ 8 Stunden, 45 Minuten, 36 Sekunden (hier beginnt Hochverfuegbarkeit)
Verfuegbarkeit 99.99% ~ Maximaler Ausfall von 3153.6 Sekunden ~ 52 Minuten, 33.6 Sekunden
Verfuegbarkeit 99.999% ~ Maximaler Ausfall von 315.36 Sekunden ~ 5 Minuten, 15.36 Sekunden
Verfuegbarkeit 99.9999% ~ Maximaler Ausfall von 31.536 Sekunden

Hach, drei Tage Ausfall im Jahr sind ja nicht so schlimm ... oder? Was ist denn, wenn die Ausfallzeit nicht über das Jahr verteilt auftritt, sondern direkt am Stück? Es gibt sehr viele Unternehmen, bei denen ein dreitaegiger Stillstand zum Ruin fuehrt, so dass die Firma dicht machen muss.

Ist Euch in dem Zusammenhang mal aufgefallen, wie selbstverstaendlich es fuer uns ist, dass das Telefonnetz "immer" verfuegbar ist und dass wir Ausfaelle von IT-Systemen als gegeben hinnehmen? Seit alles auf VoIP (Voice over IP) umgestellt wird, sind auch die Zeiten der immerwaehrenden Verfuegbarkeit vorbei.

Ein abschliessendes Wort. Je nach gewuenschtem Verfuegbarkeitsgrad muss die Architektur des Systems ausgewaehlt werden. Dabei reicht die Bandbreite von "Ersatzteile und -geraete verfuegbar halten" ueber "Hot- und Cold-Standby-Systeme" bis hin zu Lastverteilung, Ausweichrechenzentren und dergleichen mehr. Wir werden hier sicher noch Loesungen vorstellen.

KW 2011/50 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 19 Dec 2011 00:00:00 +0100

Kalenderwoche 50, 12.-18.12.2011

Bei Golem ist der Artikel Erweiterungen von Grep und Diff vorgestellt zu lesen. Diese Erweiterungen sollen nicht mehr zeilenbasiert arbeiten, sondern auf Ebene von Datenbloecken.

Bei nixCraft (sehr lesenswertes Blog), gibt es den neuen Artikel Linux: 20 Iptables Examples For New SysAdmins.

Running with Tripwire ist ein guter Einstiegspunkt, um Tripwire zu nutzen.

Im verlinkten Post gibt es Hinweise auf zwei gute Python-Tutorials.

Sehr guter Artikel zur Sicherheitsproblematik aktueller Systeme: 99% Sicherheit ist kein Problem

Installation und Konfiguration von vsftpd mit SSL

nospam@example.com (Ramon Kukla) — Fri, 16 Dec 2011 09:00:00 +0100

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.

KW 2011/49 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 12 Dec 2011 00:00:00 +0100

Kalenderwoche 49, 05.-11.12.2011

Ein bisschen spaet, aber noch nicht zu spaet: Sysadvent

Bei den IBM developerWorks habe ich Scripting KVM with Python, Part 1: libvirt gefunden.

Ebenfalls dort findet sich ein Artikel fuer LPIC 302: Learn Linux, 302 (Mixed environments): Linux file system and share/service permissions

Und ein dritter Artikel, ja diese Woche war sehr ertragreich, Evolution of shells in Linux (From Bourne to Bash and beyond).

Pro Linux hat PDF-Tools für die Konsole vorgestellt. Da sind zwei oder drei, mit denen ich auch gerne in Zukunft etwas machen moechte.

The Limoncelli Test: 32 Questions for Your Sysadmin Team ist ein etwas laengerer meta-Artikel, der interessante Punkte enthaelt, an der man seine Systemadministration messen kann.

Ein Syslog Server, das Backup

nospam@example.com (Ramon Kukla) — Fri, 09 Dec 2011 09:00:00 +0100

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. ;)

KW 2011/48 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 05 Dec 2011 00:00:00 +0100

Kalenderwoche 48, 28.11.-04.12.2011

In der Learn Linux von developperWorks rauschte gerade der Artikel Working with Windows clients rein.

Gesetzt den Fall, man ist in der Bash, sorgt cp datei{,.bak} für das schnelle Backup einer Datei.

countdown till 0x7FFFFFFF, dem Ende der (Unix-)Zeit.

Automount

nospam@example.com (Dirk Deimeke) — Fri, 02 Dec 2011 09:00:00 +0100

Wenn man Netzwerk-Shares benutzt, ist es selten sinnvoll, diese Shares staendig zu verbinden. Schlauer waere es doch, wenn man sie nur dann verbinden wuerde, wenn sie gebraucht werden. Und genau das leistet autofs. Die Einrichtung geht flott von der Hand, wenn man weiss wie.

Installieren von autofs mit dem Paketmanagement der eigenen Distribution.

So einrichten, dass es automatisch startet, beispielsweise mit rc-update add autofs, bei Debian und Ubuntu ist nichts zu tun.

Ein Verzeichnis erstellen, unter dem die Shares eingebunden werden sollen, bei mir mkdir /ext.

Danach die eigentliche Konfiguration:

In die /etc/autofs/auto.master (bei Debian und Ubuntu /etc/auto.master) folgende Zeile einfuegen:
/ext /etc/autofs/auto.misc --timeout=300 --ghost
Fuer Debian und Ubuntu /etc/auto.misc, es kann aber auch eine beliebige andere Datei sein. timeout=300 sorgt fuer einen umount nach 300 Sekunden Inaktivitaet und ghost sorgt dafür, dass die Verzeichnisse auch sichtbar sind, wenn sie nicht gemountet wurden.

In die /etc/autofs/auto.misc bzw. /etc/auto.misc kommen jetzt die ganzen Shares, die eingebunden werden sollen. In den Dateien finden sich bereits einige Beispiele, ich zeige das hier einmal exemplarisch für eine cifs-Share:
share -fstype=cifs,credentials=/root/credentials,nounix ://host/sharename

share ist der Name des Verzeichnisses unter /ext, wohin die Einbindung erfolgen soll. Nach einem Tab (oder ein paar Leerzeichen) folgt das Filesystem mit den Optionen, die gebraucht werden und wieder ein paar Leerzeichen (oder ein Tab) spaeter die Informationen des anbietenden Rechners.

/root/credentials erstellen mit folgendem Inhalt:

username=value

password=value

workgroup=value

Falls keine Workgroup bekannt ist einfach "workgroup" benutzen oder eventuell sogar den Parameter weglassen.

Nach einem Neustart von autofs gibt es einen virtuellen Ordner /ext/share und erst beim Wechsel in das Verzeichnis wird der Mount ausgeführt. 300 Sekunden nachdem kein Prozess mehr auf Dateien dort zugreift, wird das Verzeichnis wieder ausgehaengt.

So richtig interessant wird das in Verbindung mit FUSE (Filesystem in Userspace), da denke ich insbesondere an sshfs, davfs2 oder ftpfs. Es gibt eine sehr grosse Anzahl von Netzwerkdateisystemen, die von FUSE unterstuetzt werden.

Ich beschreibe hier das Vorgehen mit sshfs, da es das komplizierteste ist.

Zuerst muessen wir testen, ob der User root (!) in der Lage ist per ssh auf die Gegenseite zuzugreifen.

ssh ich@ziel.domain.tld

Sollte das nicht klappen, muss die ~/.ssh/config des root-Users angepasst werden. Meist reicht ein Eintrag, um den Key festzulegen, mit dem zugegriffen werden soll.

Host ziel

  HostName ziel.domain.tld

  User ich

  IdentityFile /home/ich/.ssh/id_rsa

Jetzt funktioniert ein ssh ziel.

Der Eintrag in die auto.misc muss erstellt und der Service autofs neu gestartet werden.

mntpoint -fstype=fuse,rw,uid=1000,gid=1000,allow_other :sshfs#ich@ziel.domain.tld\:/pfad/zum/verzeichnis

Im Wiki von ubuntu.com stehen noch einige weitere gute Erlaeuterungen.

Gerade, wenn man - beispielsweise als Webentwickler - auf vielen entfernten Systemen arbeitet, ist das eine echte Erleichterung. Beim Wechsel in das entsprechende Verzeichnis wird es eingebunden und, wenn man fertig mit der Arbeit ist, auch wieder ausgehaengt.

KW 2011/47 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 28 Nov 2011 00:00:00 +0100

Kalenderwoche 47, 21.-27.11.2011

Wer GNOME 3 nutzt (ich find es gar nicht mehr so unsexy), der sollte sich mal das GSettings configuration tool anschauen. Eine flotte Uebersicht der moeglichen Schluessel bekommt man mit for i in $(gsettings list-schemas); do gsettings list-recursively $i; done

Verhalten im Ernstfall

nospam@example.com (Ramon Kukla) — Fri, 25 Nov 2011 09:00:00 +0100

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.

KW 2011/46 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 21 Nov 2011 00:00:00 +0100

Kalenderwoche 46, 14.-20.11.2011

Charly Kuehnast hat mir auf der OpenRheinRuhr von Postfix Admin erzaehlt. Das muss ich mir fuer unsere root-Server mal naeher anschauen.

Migration von Subversion nach Git

nospam@example.com (Dirk Deimeke) — Fri, 18 Nov 2011 09:00:00 +0100

Aus verschiedenen Gruenden wollte ich unsere Subversion-Repositories nach Git migrieren. Die Entscheidung dafuer war unabhaengig davon, dass zwei Projekte, naemlich FAI und Serendipity, etwa zur gleichen Zeit migriert sind.

Git ist ein verteiltes Versionskontrollsystem (DVCS) - in der gleichen Liga spielen auch Bazaar und Mercurial, wobei das "verteilt" nicht der Grund fuer den Wechsel war. Neben der komprimierten Speicherung und bandbreitenschonenden Uebertragung, spielen die neuen Systeme ihre Staerken vor allem im intelligenten Zusammenfuehren (merging) von unterschiedlichen Versionen aus.

Weitere Vorteile sind (die Liste ist nicht komplett):
• Es gibt kaum ein System, was besser dokumentiert waere.
• Kleinerer Administrationsaufwand.
• Sparen eines Apache-Moduls
• Alle haben die komplette Historie lokal und koennen auch ohne Server arbeiten.
• Alle koennen beliebig oft lokal committen und alle Aenderungen erst dann uebertragen, wenn der eigene Teil fertig ist.

Einen sehr guten Einstieg in verteilte Versionskontrollsysteme und insbesondere Git bietet die Ausgabe 130 von Chaosradio Express.

Subversion wurde bei uns ueber dav_svn, ein Modul des Webservers, benutzt. Die Migration musste also in drei Schritten passieren, zuerst die Serverseite, um die Infrastruktur zur Verfügung zu stellen, danach die Migration der bestehenden Projekte und zum Schluss die Umstellung der Clients.

Da Taskwarrior Gitosis einsetzt und ich so immer jemanden habe, den ich fragen kann, habe ich mich fuer Gitosis auf der Serverseite entschieden. Dafuer gibt es bereits eine sehr gute Anleitung, die ich leider ziemlich unuebersichtlich finde, daher fuehre ich hier noch einmal die einzelnen Schritte auf. Unsere Server laufen auf Ubuntu 10.04 LTS und ich bin strikt nach Anleitung vorgegangen.

sudo aptitude install git-core gitosis

Erzeugt einen User "gitosis" und die nötigen Verzeichnisse unter /srv/gitosis

Danach muss ich den eigenen oeffentlichen SSH-Schluessel auf den Server kopieren und damit das Administrations-Repository initialisieren (darin wird die ganze Konfiguration gemacht).

dirk@client$ scp .ssh/id_rsa.pub server:/tmp/dirk@client.pub
dirk@server$ sudo -H -u gitosis gitosis-init < /tmp/dirk@client.pub

Damit ist die serverseitige Einrichtung bereits abgeschlossen. Unglaublich aber wahr.

Was nicht in der Anleitung steht, jetzt aber lokal erledigt werden sollte, da commits in Git immer Usernamen und E-Mail-Adresse enthalten:

git config --global user.name "John Doe"
git config --global user.email "john@doe.com"
git config --global color.ui always

Der letzte Befehl ist nicht wichtig, der macht es nur huebsch.

Jetzt kann das gerade angelegte Adminrepository ausgechecked werden:

git clone gitosis@server:gitosis-admin.git gitosis-admin-server.git

Das letzte in der Kommandozeile ist der Name, wie das Verzeichnis lokal heissen soll. Ich habe ein "-server.git" hinzugefügt, da das Verzeichnis sonst nur "gitosis-admin" geheissen haette.

Jetzt können der Admingruppe weitere User hinzugefügt werden.

In gitosis.conf stand am Anfang nur dirk@client:

[group gitosis-admin]

writable = gitosis-admin

members = dirk@client dirk@workstation

Im Verzeichnis keydir sind die ganzen Schluessel zu finden. dirk@client.pub war schon vorher enthalten.

ls -l keydir/

total 12

-rw-r--r-- 1 dirk dirk 393 Nov  4 10:50 dirk@client.pub

-rw-r--r-- 1 dirk dirk 395 Nov  4 10:54 dirk@workstation.pub

Die Aenderungen werden jetzt an den Server uebertragen.

git add keydir/dirk@workstation.pub
git commit -a -m "User dirk@workstation hinzugefuegt"
git push

Git verhaelt sich ein bisschen anders als Subversion.

• Bei einem "git commit" passiert gar nichts, auch wenn sich Dateien veraendert haben.
• git add datei ; git commit -m "nachricht" oder git commit -a -m "nachricht"
• letzterer nimmt alle Dateien in den Commit, die bereits unter Versionskontrolle stehen und sich veraendert haben
• Der Commit ist lokal, erst "git push" uebertraegt die Änderungen zum Server
• Analog dazu synchronisiert sich "git pull" mit dem Server

Ein neues Repository auf dem Server legt man wie folgt an. Zuerst traegt man es in die gitosis.conf ein.

[group playground]

writable = playground

members = dirk@client dirk@workstation

Danach uebertraegt man die neue Konfiguration auf den Server.

$ git commit -a -m "playground erzeugt"
[master 8a62406] playground erzeugt
1 files changed, 4 insertions(+), 0 deletions(-)
$ git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 375 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitosis@foo:gitosis-admin.git
4755284..8a62406 master -> master

Wir initialisieren das Repositories (ebenfalls lokal):

$ git clone gitosis@server:playground.git playground-server.git
Cloning into playground-server.git...
Initialized empty Git repository in /srv/gitosis/repositories/playground.git/
warning: You appear to have cloned an empty repository.

$ cd playground-foo.git/

$ touch foo

$ git add .

$ git commit -m "init"
[master (root-commit) 8b70e1d] init
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 server

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 197 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitosis@server:playground.git
* [new branch] master -> master

Nachdem das alles funktioniert, koennen die Subversion-Repositories migriert werden, Anleitung dazu im freien Buch Pro Git.

Subversion nutzt Usernamen um die Commits zu kennzeichnen, Git nutzt reale Namen und E-Mail-Adressen, damit ist der erste Schritt klar, wir brauchen eine Liste der User, die schon in unser Repository geschrieben haben und muessen diese mit Realnamen abgleichen.

$ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'

Mit dem obigen Befehl bekommt man alle Committer aus einem Subversion-Repository, damit laesst sich eine Datei users.txt aufbauen, in der die Usernamen und die Git-Namen zu finden sind. Ich habe das auch zur Konsolidierrung benutzt.

dirk = Dirk Deimeke <dirk@deimeke.net>

lux = Dirk Deimeke <dirk@deimeke.net>

user = Vorname Nachname <name@example.com>

Mit dieser Vorarbeit ist es bereits moeglich, das Subversion-Repository zu klonen und zu konvertieren (ACHTUNG: Unterschied zum Buch, bei mir hat die Option -s nicht funktioniert, da ich kein Standard-Layout verwendet habe und statt git-svn habe ich git svn benutzt).

$ git svn clone http://my-project.googlecode.com/svn/ \
--authors-file=users.txt --no-metadata my_project

Jetzt gilt es noch, Aufraeumarbeiten durchzufuehren. Zuerst machen wir aus den Tags von Subversion Git Tags.

$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
$ rm -Rf .git/refs/remotes/tags

Als naechstes machen wir aus den remote Referenzen lokale Branches:

$ cp -Rf .git/refs/remotes/* .git/refs/heads/
$ rm -Rf .git/refs/remotes

So, jetzt muessen wir das ganze noch hochladen.

$ git remote add origin git@my-git-server:myrepository.git

Und, weil wir alles uebertragen wollen, geht es mit dem folgenden Kommando los:

$ git push origin --all

Fertig!

Ich hatte bei der Migration mit einem groesseren Problem zu kaempfen. Mein privates Repository hat ueber 2000 commits und einige Gigabytes an Daten. Das hat meinen lokalen Rechner in die Knie gezwungen, da waren 4 GB Speicher zu knapp. Ich habe die Migration kurzerhand auf einem Server mit 8 GB RAM laufen lassen, das ging. Alternativ dazu kann man aber mit git-svn die Migration haeppchenweise durchfuehren. Mit git svn clone -r0:100 (und den anderen Optionen weiter oben) werden nur die ersten 100 Commits geklont, dann macht man mit -r100:200 weiter bis man letztendlich fertig ist.

Es gibt einen sehr guten Git - SVN Crash Course, daher fuehre ich hier nur die Unterschiede der haeufigsten Kommandos an.

• git clone ersetzt svn checkout
• git pull ersetzt svn update
• git add mach das gleiche wie svn add
• git commit -a (oder git commit -am) ersetzt svn commit bzw. svn commit -m
• UNTERSCHIED: git push uebertraegt die lokalen Commits erst auf den Server

KW 2011/45 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 14 Nov 2011 00:00:00 +0100

Kalenderwoche 45, 07.-13.11.2011

Schon ein paar Tage alt, konnte es aber die Tage brauchen. Der Wuerschtlmann hat mal eine kleine Anleitung geschrieben, wie man mit encfs Dateien verschluesselt. Das kann auch prima auf so Dinge wie Dropbox angewendet werden.

Einrichten eines Syslog Servers

nospam@example.com (Ramon Kukla) — Fri, 11 Nov 2011 09:00:00 +0100

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.

KW 2011/44 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 07 Nov 2011 00:00:00 +0100

Kalenderwoche 44, 31.10.-06.11.2011

Workflows with Bazaar ist eine interessante Uebersicht ueber Workflows von verteilten Versionskontrollsystemen. Ist fuer Bazaar geschrieben, laesst sich aber auch direkt auf Git oder Mercurial uebertragen.

Iperf ist ein simples Tool, um die Netzwerkbandbreite zu bestimmen. Gefunden bei Stefan.

Diesen Git - SVN Crash Course habe ich gerade gefunden, er stellt die Kommandos von Git und Subversion gegenüber.

Die Firewall

nospam@example.com (Ramon Kukla) — Fri, 04 Nov 2011 09:00:00 +0100

Eine Frage, die immer wieder mal gestellt wird und in "Fachzeitschriften" regelmaessig bejaht wird ist, brauche ich zu Hause eine Firewall? Das kann man meiner Meinung nach ganz klar mit "Ja/Nein/Kann sein" beantworten.

Vorab macht es, wie bei so vielen Dingen, Sinn sich zu fragen was man erreichen moechte. Moechte ich den Zugriff meines LANs reglementieren, so dass nur noch http(s) erlaubt ist? Oder moechte ich den Schutz meines Clients verbessern? Oder moechte ich einfach nur etwas ueber mein Netzwerk lernen? Dann ist ja auch noch die Frage, was ich unter Firewall verstehe und ob ich eine lokale oder zentrale Softwareloesung haben moechte? Oder soll es doch lieber gleich Hardware sein?

Wobei ich mit Firewall jetzt eine sogenannte Stateful Inspection-Firewall meine. Also eine Firewall, die den Netzwerkverkehr anhand einfacher Regeln (Erlaube Host A den Zugriff auf Netz A, Port 80) reglementiert. Eine detailiertere Erklaerung findet man, wie so oft, im entsprechenden Wiki-Artikel.

Wenn ich den Zugriff meines Netzwerkes auf externe Ressourcen reglementieren moechte, ist der Einsatz von Hardware vermutlich am unkompliziertesten. Es muss nicht auf jedem beteiligten Rechner eine Firewall eingerichtet und konfiguriert werden. Ich habe da, eher aus Spass an der Freude, zu Hause eine Netscreen 5GT im Einsatz. Hiermit kann ich reglementieren und protokollieren, nutze viele der Funktionen aber nicht. In der Regel bringen neuere Router auch schon ein Stueck weit Firewallfunktionalitaet mit. In diesem Szenario haelt sich der Aufwand und vor allem eine moegliche Fehlersuche etwas in Grenzen.

Um den Schutz meines Clients zu verbessern mache ich mir keine Gedanken ueber eine lokale Firewall. Da setze ich lieber an sinnvolleren Stellen an. Der Einsatz einer Personal Firewall war ja eine zeitlang extrem beliebt und wurde und wird in verschiedenen Publikationen auch immer wieder empfohlen. Das Problem ist hier nur, dass fuer einen moeglichen sinnvollen Einsatz auch ein sehr gesundes Wissen ueber Netzwerke und das eigene System mitgebracht werden sollten. Denn Meldungen wie "Der Prozess 'ssh:25738' versucht von Adresse 192.168.100.110, Port 54721 auf die Adresse 192.168.100.1, Port 22 zuzugreifen" muessen auch verstanden werden. Und dieses Beispiel war ja nun relativ leicht.

Vor allem am Anfang der Konfiguration solch einer Personal Firewall wird man im Zweifel mit so vielen Meldungen konfrontiert, dass bei vielen Benutzern die Gefahr besteht, im Verlauf einfach nur noch alles zu verbieten oder zu erlauben. Ersteres fuehrt dazu, dass damit bestimmte Dinge vielleicht nicht (mehr) funktionieren. Zweiteres fuehrt dazu, dass ich eventuell einen Regeleintrag habe, der nicht gewuenscht war. Hat man es dann doch geschafft ein, wie man meint, gutes Regelwerk zu erstellen, hat man den Schutz der eigenen Maschine im Zweifel aber nicht derart verbessert, dass sich der Aufwand gelohnt hat. In allen Personal Firewalls, die ich bisher so gesehen habe, gab es einen Weg nach draussen, obwohl dieser eigentlich nicht gestattet sein sollte. Ein Beispiel, welches schon was aelter ist, findet man in meinem Blog.

Interessant ist eine Personal Firewall, wenn ich schauen moechte was mein System eigentlich so macht. Da kommt man mit einer zentralen Firewall oft nicht weit, da hier der Zusammenhang zwischen den Sessions und dem Ausloeser (sprich, der Anwendung) nicht immer klar ist.

Um etwas ueber das eigene Netzwerk zu erfahren ist eine Firewall, egal ob lokal oder zentral, oft nicht der passende Ansatz. Grund ist, dass ich in der Regel nur Informationen ueber erlaubte/verbotene Sitzungen bekomme. Und sowas wie...

firewall-> get session

alloc 2/max 2064, alloc failed 0, mcast alloc 0, di alloc failed 0

total reserved 0, free sessions in shared pool 2062

id 1675/s**,vsys 0,flag 00000040/0080/0021,policy 320002,time 180, dip 0 module 0

 if 2(nspflag 800601):192.168.100.15/52285->192.168.100.1/22,6,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1,wsf 0

 if 3(nspflag 2002010):192.168.100.15/52285<-192.168.100.1/22,6,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0,wsf 0

id 1769/s**,vsys 0,flag 00000000/0000/0001,policy 1,time 6, dip 2 module 0

 if 2(nspflag 800801):192.168.100.15/57327->188.40.57.208/1194,17,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1

 if 1(nspflag 10800800):192.168.0.2/1711<-188.40.57.208/1194,17,00150c73228c,sess token 4,vlan 0,tun 0,vsd 0,route 5

Total 2 sessions shown

...ist mal nett, wenn es ein Problem gibt. Aber so richtig lernen tut man da nichts. Da wuerde ich eher mal den Einsatz von tcpdump oder Wireshark empfehlen. Ich kann dann wirklich etwas vom Netzwerk und darauf befindlichen Protokollen sehen.

So oder so sollte man sich im klaren sein, dass der Einsatz einer Firewall durchaus auch Aufwand und spaetere Pflege noetig macht. Im Normalfall sind Firewallsysteme erst mal keine "Fire-and-Forget"-Systeme. Wer, wie im obigen Beispiel, eine Firewall einrichtet, da http(s) freigibt und meint, das war's, wird schnell merken, dass Netzwerk/Internet mehr als nur Port 80 und 443 ist.

Fazit:
Mit einer Firewall alleine gewinnt man noch lange keinen Blumentopf. Vor allem in Geschaeftsumfeld sollte es meiner Meinung nach kaum noch ein Unternehmen geben, dass sensible Maschinen, die aus dem Internet erreichbar sein muessen, ausschliesslich durch eine Firewall schuetzt. Fuer jede Anwendung, bzw. Anwendungsgruppe, sollte es Vorgaben geben, wie diese abzusichern sind. Da zaehlt dann aber nicht nur alleine der Einsatz einer Firewall. Da kommen dann, je nach Auspraegung, auch so Dinge wie Patch-Management, Web Application Firewall, IDS, IPS oder auch die Beschreibung des Notfalls (Einbruch) hinzu.

Auch im privaten Umfeld ist die klassische Firewall nur eine moegliche Ergaenzung zu weiteren Punkten um den Schutz der eigenen Infrastruktur zu verbessern. Und eines muss klar sein. Es gibt nicht *die Sicherheit*. Man kann versuchen den Schutz zu verbessern, wird aber im Regelfall keine 100% Sicherheit erreichen.

Ergaenzung:
Wenn zwei Personen sich unterhalten passiert es schnell, dass beide etwas anderes bei der Begrifflichkeit "Firewall" meinen. Umgangssprachlich ist mit Firewall oft die Komponente gemeint, die den Schutz eines Systems oder einer Umgebung zum Ziel hat. Korrekter ist jedoch, dass Firewall auch mit ein Konzept meint, in dem nicht nur die Frage nach der Hardware geklaert wird.

KW 2011/43 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 31 Oct 2011 00:00:00 +0100

Kalenderwoche 43, 24.-30.10.2011

Im Linux-Teil der IBM developerWorks gibt es einige interessante Artikel, es lohnt sich, den Feed zu abonnieren.
• Learn Linux, 302 (Mixed environments): Authentication and authorization
• Learn Linux, 302 (Mixed environments): A roadmap for LPI-302
• Learn Linux, 302 (Mixed environments): Managing user accounts and groups
• Learn Linux, 302 (Mixed environments): CIFS integration

Zu Git gibt es die wirklich interessanten Buecher auch Online und gratis zu lesen:
• Versionskontrolle mit Git
• Pro Git

Auf Slideshare gibt es eine richtig gute Praesentation zum Thema Git vs SVN - Eine vergleichende Einfuehrung.

Selbstmanagement

nospam@example.com (Dirk Deimeke) — Fri, 28 Oct 2011 09:00:00 +0200

Als Systemadminstrator habe ich die taegliche Herausforderung, meinen eigenen Arbeitstag zu organisieren. Dabei muss ich staendig im Hinterkopf behalten, dass ich sehr haeufig durch Telefonanrufe, E-Mails, Tickets und technischen Fehlern auf Systemen, fuer die ich verantwortlich zeichne, unterbrochen werde.

Die meisten Administratoren, die ich kenne, versuchen so viel wie moeglich ueber Selbstmanagement, Projektmanagement (ja, wirklich!) und nicht zuletzt auch Zeitmanagement zu lernen. Wir evaluieren staendig neue Moeglichkeiten und Werkzeuge, um unser Leben leichter zu machen. Faul und darum bemueht zu sein, Dinge nicht zwei oder sogar drei Mal machen zu muessen, sind weitere Mosaiksteine.

Gutes Zeitmanagement, (ja, ich weiss, Zeit kann man nicht managen), das durch den dringenden Wunsch, wiederkehrende Aufgaben zu automatisieren, unterstuetzt wird, ist der Schluesselfaktor dafuer, unsere Arbeit gut zu machen und unsere Chefs zufrieden zu stellen.

Wenn man sich auf dem Buchmarkt umschaut oder im Internet sucht, ist das groesste Problem, dass die meisten Artikel, Buecher und Werkzeuge auf dem Markt fuer "Business people" (Geschaeftsleute) und nicht fuer Techies wie uns geschrieben wurden.

Empfehlungen:

Ich bin ein grosser Fan von Tom DeMarco und habe alle seine (uebersetzten) Buecher gelesen. Meine Favoriten sind: Der Termin - Ein Roman über Projektmanagement, man kann eine in vielen Punkten sehr aehnliche Geschichte online finden, The King's Dinner (englisch), und Wien wartet auf Dich! - Der Faktor Mensch im DV-Management. Beide Buecher sind schon etwas aelter aber in jedem Fall lesenswert.

Thomas A. Limoncelli schrieb das Buch Zeitmanagement fuer Systemadministratoren, aus dem ich eine Menge an Tipps uebernommen habe.The Practice of System and Network Administration (englisch) vom gleichen Autor ist ebenfalls lesenswert, hat aber nichts mit dem eigentlichen Thema zu tun.

Ueber "praktische Administration" und Zeitmanagement habe ich bereits einige Workshops gegeben, die Ihr hier und hier findet. Das Video des zweiten Workshops wird noch fertiggestellt. Da die Videokassetten einen Schlag hatten, ist die Restauration aufwendiger.

Wichtig: Pruefet alles und behaltet das Beste!

Der Weg, den Andere (oder ich) Euch zeigen, muss nicht der richtige fuer Euch sein. Er ist es sogar hoechstwahrscheinlich nicht. Informiert Euch regelmaessig ueber verschiedene Techniken und Methoden, dann benutzt das, was fuer Euch gut und richtig ist, was durchaus eine Mischung aus vielen verschiedenen Quellen sein kann.

Wenn Ihr denkt, dass Euch ein elektronisches Werkzeug helfen kann, denkt bitte daran, dass das nur ein Werkzeug ist und Euch die Philosophie des Programmautoren aufzwaengen sollte. Das ist uebrigens einer der Gruende, weshalb ich Taskwarrior verwende und in dem Projekt mitmache.

Neues Logo, danke!

nospam@example.com (Ramon Kukla) — Tue, 25 Oct 2011 14:21:00 +0200

Wir hatten Anfang des Monats ja geschrieben, dass wir auf der Suche nach einem schicken Logo sind. Christian Duerr war so leichtsinnig sich dem Thema und unseren Ideen, die wir nur schwer in Worte fassen konnten, anzunehmen. Letztendlich hat Christian es aber geschafft und uns ein prima Favicon, Logo und ein tolles Bild erstellt.

An dieser Stelle noch einmal einen herzlichen Dank an alle die sich gemeldet haben und an Christian fuer das tolle Ergebnis!

KW 2011/42 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 24 Oct 2011 00:00:00 +0200

Kalenderwoche 42, 17.-23.10.2011

Wenn die Anmeldung an den eigenen Server, der Kerberos verwendet, nicht klappt und ein kinit zeigt ein Clock skew too great while getting initial credentials an, einfach mal schauen ob die Systemzeit korrekt ist. Hat bei mir geholfen.

Weil es auf google+ eine Anfrage gab. Zeige mir jede Zeile einer Datei an, in der in der fuenften Spalte der Wert 12 enthalten ist: awk -F\; '$5~/12/ {print}' DATEI (Der Trenner war ein Semikolon, daher das -F\;).

Das ist vielleicht fuer den Einen oder Anderen interessant: How to keep a detailed audit trail of what’s being done on your Linux systems

An Tagestermine erinnern

nospam@example.com (Dirk Deimeke) — Fri, 21 Oct 2011 09:00:00 +0200

Vor hundert Jahren als ich das erste Mal in intensiveren Kontakt mit Perl kam, habe ich mir "als Fingeruebung" ein kleines Skript gebastelt, dass mich seit vier Jahren an meine Tagestermine erinnert. Ihr werdet sehr schnell merken, dass ich kein ueberragender Programmierer bin, wenn Ihr Euch das Skript anschaut. Aber, mir hilft es und damit vielleicht auch Euch.

daterem-0.0.1.tar.gz (3,4 kB - MIT-License)

In der Datei daterem.dat stehen die Termine drin.

Fixe Termine sind entweder mit oder ohne vierstellige Jahreszahl moeglich: tt.mm. oder tt.mm.jjjj Im ersten Fall tauchen sie in jedem Fall auf, im zweiten Fall nur in den speziellen Jahr. Variable Feiertage werde durch ihren Abstand zu Ostersonntag gekennzeichnet. "0" für Ostersonntag selber, "-2" für Karfreitag und "1" für Ostermontag als Beispiel.

Bei Zeitraeumen muss nur angegeben werden, was unterschiedlich ist, die Jahreszahl ist nicht noetig, dann wird der Zeitraum eben jedes Jahr wiederholt (wiederkehrende Zeitraeume nutze ich persoenlich nicht).

Im gleichen Monat: 05.-15.04.2011
Verschiedene Monate gleiches Jahr: 16.04.-13.05.2011
Verschiedene Jahre: 30.12.2011-02.01.2011

Nach den Daten muss immer eine Beschreibung kommen.

Die Datei muss von Hand gepflegt werden.

Ohne Parameter aufgerufen, werden alle Jahrestage des heutigen Tages angezeigt. Wenn der Parameter ein Datum ist, dann das entsprechende Datum, wenn der Parameter mm.jjjj ist, kommen alle Termine des Monats und mit jjjj alle Termine des Jahres.

Da sind schon ein paar Termine drin, um das Format zu verdeutlichen.

Das Skript laeuft bei mir allmorgentlich um 04:00 Uhr und schickt mir die aktuellen Tagestermine und Geburtstage.

KW 2011/41 - Fundstuecke

nospam@example.com (Dirk Deimeke) — Mon, 17 Oct 2011 00:00:00 +0200

Kalenderwoche 41, 10.-16.10.2011

Bei The Geek Stuff findet sich ein kleines aber feines MySQL Tutorial: Install, Create DB and Table, Insert and Select Records

Bei developerWorks sind zwei Artikel zur Nutzung von PHP mit identi.ca erschienen: Teil 1 und Teil 2.

Mailserver testen

nospam@example.com (Ramon Kukla) — Fri, 14 Oct 2011 09:00:00 +0200

Vor laengerer Zeit gab es hier ja mal einen Beitrag der sich um das rudimentaere Testen eines Webservers via telnet und openssl drehte. Da war es nur konsequent, dass dem auch mal ein Beitrag folgt, der sich um das Thema Mail dreht.

Fangen wir erst mal einfach an und schauen, ob wir uns via SMTP mit unserem Mailserver verbinden und testweise mal eine Mail verschicken koennen.

ramon@client:~$ telnet 192.168.100.25 25
Trying 192.168.100.25...
Connected to mailserver.
Escape character is '^]'.
ehlo client
220 mailserver NuNu 3.3(18) ipop3d (Amiga)
250-mailserver Hello client ([192.168.100.25]), pleased to meet you
250-HELP
250-SIZE 20971520
250 PIPELINING
MAIL FROM:ramon@kukla.info
250 ramon@kukla.info... Sender OK
RCPT TO:ramon@kukla.info
250 ramon@kukla.info... Recipient OK
DATA
354 Enter message, end with "." on a line by itself
SUBJECT:testmail
testmail
.
250 Message accepted for delivery
quit
221 mailserver SMTP Service closing transmission channel
Connection closed by foreign host.

Hat alles geklappt haben wir anschliessend eine Mail in unserem Zielpostkorb. Jetzt haben wir einen Server, der es erfordert sich vorab als berechtigter Benutzer zu authentifizieren. Da wir unsere Authentifizierung nicht unverschluesselt ueber das Netz schicken werden wir uns nun via SSL mit dem Mailserver verbinden.

Vorab noch ein Hinweis. Bei der Nutzung von openssl im folgenden Beispiel passiert es, dass bei Kommandos, wo das erste Zeichen ein R ist, ein Regonitiation initiiert wird. Das wuerde uns dann also spaetestens beim "RCPT TO:" zum Verhaengnis werden. Daher rufen wir openssl mit der Option -ign_eof auf.

ramon@client:~$ openssl s_client -connect mailserver:465 -ign_eof
CONNECTED(00000003)
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify return:1
---
Certificate chain
0 s:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
i:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDnDCCAwWgAwIBAgIJAJLLd/ciGa54MA0GCSqGSIb3DQEBBQUAMIGRMQswCQYD
VQQGEwJERTEQMA4GA1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4x
DTALBgNVBAoTBHB0bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQD
Ewtmb28ucHRseC5kZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTAeFw0x
MTAyMjAxMzMxMzVaFw0yMTAyMTcxMzMxMzVaMIGRMQswCQYDVQQGEwJERTEQMA4G
A1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4xDTALBgNVBAoTBHB0
bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQDEwtmb28ucHRseC5k
ZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA1VqGIqHj1sH8MAO8+kA2JPzb4dmEvRcnRMOvS0eCpmLsN+GX
Tz+RUZLu5/2tfB7ntggU/R0P/LozFbUsFDqckKrzTuzus21/EJGfN51p9pixpGBi
GyiXlUJ2hg3zwwckCwxEuoY+By/KlEH6sN7vGpycYj2rmaf0nBTuoL+DGoMCAwEA
AaOB+TCB9jAdBgNVHQ4EFgQUpSWQtdmGGGMs8yYIWQZbtRQbJCswgcYGA1UdIwSB
vjCBu4AUpSWQtdmGGGMs8yYIWQZbtRQbJCuhgZekgZQwgZExCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdTYXhvbmlhMRQwEgYDVQQHEwtGYWxrZW5zdGVpbjENMAsGA1UE
ChMEcHRseDEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFDASBgNVBAMTC2Zvby5w
dGx4LmRlMRwwGgYJKoZIhvcNAQkBFg1hZG1pbkBwdGx4LmRlggkAkst39yIZrngw
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCQAvHWM1QUAw447V/l+1X+
R8+ATWJJUsj1dCtSrkrCuS9hS1mxnnLlWa/Jpe+ipRcHLdvYQ7g+iaWupujeZv8B
PqpipLSPyuaSlIlCJe38fUKbXuPbSLkx6RA8PrY6O3y32T23Rmc13HV5gwbf+8zI
/A3WXwxoOTYz/GzIA2+VMg==
-----END CERTIFICATE-----
subject=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
issuer=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
---
No client certificate CA names sent
---
SSL handshake has read 1499 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 6CFEC94B29AEFC1099D87B785F58631DF6D328F135B2CA75D5368566C1D3C19D
Session-ID-ctx:
Master-Key: 330430753D0F29C93467334FA9D0C43700C0B5DE6F8AD2F9D606B0A4ACD565FC9012F49DD7EEE2F7BE04AF2E0FC9137F
Key-Arg : None
Start Time: 1318419830
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
220 mailserver NuNu 3.3(18) ipop3d (Amiga)
ehlo client
250-mailserver
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Jetzt kommt der interessantere Teil, die Authentifizierung. Diese erfolgt via AUTH LOGIN oder AUTH PLAIN. Der Unterschied zwischen den beiden Methoden ist, dass bei ersterer (AUTH LOGIN) Benutzername und Kennwort getrennt uebertragen werden, wohingegen bei AUTH PLAIN Benutzername und Kennwort "am Stueck" uebertragen werden. Allerdings werden Benutzername und Kennwort nicht im Klartext sondern Base64-kodiert uebermittelt. Um einen solchen kodierten String zu erhalten kann man entweder einen der diversen Online-Konverter nutzen, oder ein lokales Perl mit dem MIME::Base-Modul.

ramon@client:~$ perl -MMIME::Base64 -e 'print encode_base64("meinpasswort");'
bWVpbnBhc3N3b3J0
ramon@client:~$ perl -MMIME::Base64 -e 'print encode_base64("ramon@kukla.info");'
cmFtb25Aa3VrbGEuaW5mbw==

Mit Hilfe der generierten Werte koennen wir uns nun also Authentifizieren und unsere Mail senden.

AUTH LOGIN
334 VXNlcm5hbWU6
cmFtb25Aa3VrbGEuaW5mbw==
334 UGFzc3dvcmQ6
bWVpbnBhc3N3b3J0
235 2.7.0 Authentication successful
MAIL FROM:ramon@kukla.info
250 2.1.0 Ok
RCPT TO:ramon@kukla.info
250 2.1.5 Ok
DATA
SUBJECT:testmail
354 End data with <CR><LF>.<CR><LF>
testmail
.
250 2.0.0 Ok: queued as BAA9C19EFD6E
quit
221 2.0.0 Bye
read:errno=0

Soweit so prima. Jetzt moechten wir natuerlich noch mal schauen, wie es sich mit IMAP darstellt. Bei IMAP ist wichtig zu wissen, dass alle Kommandos von einem sogenannten Identifier angefuehrt werden muessen.

ramon@client:~$ openssl s_client -connect mailserver:993
CONNECTED(00000003)
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify return:1
---
Certificate chain
0 s:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
i:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDJTCCAo6gAwIBAgIJAO3v57G3iscCMA0GCSqGSIb3DQEBBQUAMGsxHDAaBgNV
BAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQw
EgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRs
eC5kZTAeFw0xMTAyMjAxMDQzNTBaFw0xMjAyMjAxMDQzNTBaMGsxHDAaBgNVBAoT
E0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQwEgYD
VQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRseC5k
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7CqNuyJwyDYfkhjOYsBdLouu
tLDx/QjVulAyisf+YMWwRr/ZMI5dZCoB2+VYVk+px4pP0asNjtiMD7/aKgPs3SJH
LmcaPIfXayBYVVpwi1jEFhSNowCcQjmoPHAM0PrNJNz9qVGpxJkk/kwpXd8kPdBk
Eq1b/41Xb7NDbTLZ/GUCAwEAAaOB0DCBzTAdBgNVHQ4EFgQU6q65YYtCAUMqLMDi
crAg+zYxfSIwgZ0GA1UdIwSBlTCBkoAU6q65YYtCAUMqLMDicrAg+zYxfSKhb6Rt
MGsxHDAaBgNVBAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5w
dGx4LmRlMRQwEgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9v
dEBmb28ucHRseC5kZYIJAO3v57G3iscCMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN
AQEFBQADgYEARNxqxB3K++zRyB1mdaSU/P52yXEb03tqqaV+58lf75hfsBUHnz/8
1GUM2I98HM6r7nsqxG9WjCuNgDfvuZZ4A+5T3O1TPdJViTBZG/zAi4lvIHfalF5f
3ZmLUye2qLFlBScxCGdsvZ3RAOg/tskbJDgeKr/HaWAxqRlmcAxO1h8=
-----END CERTIFICATE-----
subject=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
issuer=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
---
No client certificate CA names sent
---
SSL handshake has read 1380 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 7DA8529181D88B345F6DF5771AA502682D534C7816F9036265D69F22A958AA50
Session-ID-ctx:
Master-Key: 4112D1CB2EE9357F5DF0226395E1D007C1C6401FD8F8EDC4D0C4E1CE0A98A3AA91BEB23165974633A8E60EAC349D2981
Key-Arg : None
Start Time: 1318426371
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a0001 LOGIN ramon@kukla.info meinpasswort
a0001 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a0003 EXAMINE INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $label1 $label2 $label3 $label4 $label5 $Forwarded)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 23 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1249171322] UIDs valid
* OK [UIDNEXT 25979] Predicted next UID
* OK [HIGHESTMODSEQ 10887] Highest
a0003 OK [READ-ONLY] Select completed.
a0004 FETCH 14 BODY[]
* 14 FETCH (BODY[] {1467}
Return-Path: <ramon@kukla.info>
Delivered-To: ramon@kukla.info
Received: from localhost (localhost [127.0.0.1])
by mailserver NuNu 3.3(18) ipop3d (Amiga) with ESMTP id 21D0E141E0A4;
Tue, 11 Oct 2011 22:45:38 +0200 (CEST)
From: Ramon Kukla <ramon@kukla.info>
To: ramon@kukla.info
Subject: testmail
User-Agent: Yet Another Mailer (YAM) (2.6p1)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline

testmail
--
Blog: http://ramon.kukla.info - http://adminstories.de
Software failure! Press left mouse button to continue.
Guru Meditation #8100000A.000FEA00

)
a0004 OK Fetch completed.
a0005 LOGOUT
* BYE Logging out
a0005 OK Logout completed.
closed

Soweit, so fertig. Wer nicht nur einen, sondern mehrfach Tests mit (s)einem SMTP-Server durchfuehren muss, dem sei swaks (Swiss Army Knife SMTP) empfohlen. Das erleichtert einem ungemein die Arbeit mit dem ganzen getippe.