Mittwoch, 21. März 2012

Wie geht es hier weiter?

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.

Montag, 19. März 2012

KW 2012/11 - Fundstuecke

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.

Freitag, 16. März 2012

Planaenderung

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!

Montag, 12. März 2012

KW 2012/10 - Fundstuecke

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

Freitag, 9. März 2012

Skripte

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:

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


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


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

Montag, 5. März 2012

KW 2012/09 - Fundstuecke

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.

Freitag, 2. März 2012

Aufwaende bei einer Migration

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.

Montag, 27. Februar 2012

KW 2012/08 - Fundstuecke

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

Freitag, 24. Februar 2012

Das Backup, technisch

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:


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.


Diese Datei wird beim Aufruf von ftp gezogen und genutzt.


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

Montag, 20. Februar 2012

KW 2012/07 - Fundstuecke

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.