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.

Freitag, 17. Februar 2012

Wechsel der Software

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

Montag, 13. Februar 2012

KW 2012/06 - Fundstuecke

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

Freitag, 10. Februar 2012

Screen

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.

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


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


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


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



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.


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.

Montag, 6. Februar 2012

KW 2012/05 - Fundstuecke

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?

Freitag, 3. Februar 2012

mailman

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.


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


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


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


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.


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.


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


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.


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

Montag, 30. Januar 2012

KW 2012/04 - Fundstuecke

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

Freitag, 27. Januar 2012

Das Backup

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.

Montag, 23. Januar 2012

KW 2012/03 - Fundstuecke

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

Freitag, 20. Januar 2012

Zentrale .bashrc (3)

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.