NETWAYS Blog

Der Klassiker: syslog -> logstash

von Thomas Widhalm | Jan 30, 2014 | Elastic Stack, Technology

Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben. logstash_01
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:

Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)

Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.

input {
  syslog {
    type => "syslog"
    port => 514
  }
}

Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:

*.* @192.168.200.2

Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:

*.* @@192.168.200.2:514

Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.

Thomas Widhalm

Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Lies mehr von Thomas und triff unser Team

logstash – Der 15 Minuten Quickstart Guide

von Thomas Widhalm | Jan 23, 2014 | Elastic Stack, Technology

Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.

Und genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.

Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhindern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:

logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.

Jetzt aber wie versprochen die Kurzanleitung:

logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.

Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf angelegt:

input {
  stdin {
    type => "stdinput"
  }
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
}
output {
  stdout {
    codec => rubydebug
  }
  elasticsearch {
    embedded => true
  }
}

Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages hat. Wer das nicht für einen Test möchte, kann den file Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.

Gestartet wird logstash mit

java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web

Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type wurde ebenfalls über die Konfiguration gesetzt.

[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn}
hello world
{
       "message" => "hello world",
      "@version" => "1",
    "@timestamp" => "2014-01-23T12:06:27.895Z",
          "type" => "stdinput",
          "host" => "fenris.int.netways.de"
}

„hello world“ ist die eingetippte Testnachricht.

Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.

Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es „nur“ mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.

Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.

Thomas Widhalm

Manager Operations

Lies mehr von Thomas und triff unser Team

Backup Quick 'n Dirty

von Thomas Widhalm | Nov 8, 2013 | Linux, Technology

Backuptools sind komplex und aufwändig. Das ist so und das wird sich auch so schnell nicht ändern. Wer sich auf sein Backup verlassen will, muss einfach Zeit, Aufwand und/oder Geld investieren. Was aber tun, wenn man keine hohe Sicherheit braucht, aber unter Umständen auf alte Stände des Systems / der Konfiguration zugreifen will? Weil vielleicht ein ausgefeiltes Backuptool vorhanden ist, aber ein Restore sehr umständlich wäre und man einen Abkürzung braucht? Geht sie – super! Geht sie nicht, gibt’s immer noch das eigentliche Backup.
Eine Möglichkeit wären vcs Systeme wie Git, aber auch die sind selten trivial in ihrer Bedienung – ausserdem müssen sie normalerweise dazu gebracht werden, einen aktuellen Stand eines Systems / einer Konfiguration zu sichern und das vergisst man leicht bzw. kann man es evtl nicht allen Usern zumuten. Ganz zu schweigen davon, dass man ja auch mal etwas sichern möchte, ohne, dass man dabei „anwesend“ ist. Und nicht zuletzt sind vcs Systeme dafür gedacht, Textdateien wie Quellcode und Config zu sichern und nicht ganze Server.
Eine mögliche Lösung sind Tools wie Rsnapshot. Backup, das leicht zu bedienen ist, aber, oder weil es, auf viele Features verzichtet.
Rsnapshot ist sehr schnell eingerichtet und braucht beinahe keine Ressourcen.
Die Installation funktioniert in aller Regel über den Paketmanager der ausgewählten Distribution und die Konfiguration ist ziemlich selbst erklärend mit einigen Kommentaren in der Beispielkonfig, weshalb ich hier nicht weiter darauf eingehen möchte. Bedarf kann gern in den Kommentaren angemeldet werden, dann reiche ich gern einen Artikel dazu nach.
Kurz zusammengefasst erstellt das Tool eine Kopie des Dateisystems mit rsync und erstellt Kopien dieser Kopie mit Hilfe von Hardlinks. Dadurch benötigen nur die Dateien, die sich seit dem letzten Lauf geändert haben, tatsächlich Platz auf der Festplatte. Ein Restore funktioniert dann einfach via cp oder ähnlichen Bordmitteln. Aber bitte nicht mv, da dies die interne Struktur der Backups durcheinanderbringen kann.
Ein paar mehr Details sind für das weitere Verständnis allerdings noch hilfreich: rsnapshot kennt verschiedene Intervalle, die in der Konfiguration sortiert sind und immer vom Kürzesten zum Längsten genannt werden. Dabei ist es völlig unerheblich, wie die Intervalle benannt werden, wichtig ist, nur dass die Reihung kürzer -> länger immer eingehalten wird. Der Einfachheit halber hat es sich eingebürgert, sie nach Zeitspannen zu bennnen und sie ihrem Namen entsprechend auszuführen, also hourly stündlich, daily, täglich, etc. . Im Sinne einer einfacheren Lesbarkeit werde ich davon ausgehen, dass es genauso umgesetzt wird – ich bitte also um Verständnis, wenn ich „stündliches Backup“ und nicht „am häufigsten ausgeführte Backupkonfiguration“ schreibe. Ausserdem gehe ich davon aus, dass 24 hourly, 7 daily, 4 weekly, 12 monthly und 10 yearly aufgehoben werden sollen. Genauso gut könnte ich 6 hourly, 17 daily und 8 quonko aufheben, aber das wird jetzt schon klar sein.
rsnapshot wird nach der Konfiguration via cron aufgerufen und zwar immer in der Art rsnapshot [intervallname], wobei eben hourly stündlich, daily täglich, etc. ausgeführt wird. Anders ausgedrückt muss für jeden Intervall ein eigener Job eingerichtet werden.
Im internen Ablauf passiert bei jedem Dtündlichen ein rsync, das die zu sichernden Verzeichnisse nach hourly.0 unter dem angegbenen Zielpfad kopiert (hourly entspricht wieder dem frei wählbaren Intervallnamen). Ausserdem wird hourly.23 (wegen dem Beginn bei 0 gibt es natürlich kein hourly.24) gelöscht, hourly.22 via mv in hourly.23 umbenannt, hourly.21 in hourly.22, etc. Das passiert noch vor dem Ausführen des rsync, weshalb bereits davor kein hourly.1 mehr existiert. hourly.0 wird mithilfe von Hardlinks nach hourly.1 kopiert – erst dann findet der zuvor genannte rsync statt.
Bei einem Lauf mit rsnapshot daily wird daily.6 gelöscht, daily.5 in daily.6 umbenannt, etc. . hourly.23 wird in daily.0 umbenannt. Existiert zu diesem Zeitpunkt kein hourly.23, gibt’s auch kein neues daily. Das bedeuet auch, dass erst daily erstellt werden, wenn alle hourly existieren. Das gilt es zu bedenken, wenn man z.B. 96 hourly behalten will. Ausserdem ist somit jedes daily älter als jedes hourly, jedes weekly älter als jedes daily, etc. In der angenommenen Konfiguration könnten wir also alleine durch hourly und daily 8 Tage zurück.
Wirklich hilfreich werden tools wie rsnapshot aber erst, wenn man etwas länger daran herumspielt. Ein Problem ist zum Beispiel, dass bei jedem Lauf alle bereits erstellten Backups umbenannt werden. Sucht man ein bestimmtes Backup, so muss man ausrechnen, wie es aktuell heisst und hoffen, dass alle Sicherungen nur via cron angestossen wurden. Eine mögliche Abhilfe ist, sich einen Ordner anzulegen, in dem man Dateien hinterlegt, die nur für die Dauer eines Backuplaufs existieren und das Backup identifizeren. z.B /root/snap/mysql_coldbackup . Nach der Datei kann man dann den Zielordner durchsuchen (aber bitte nicht mit locate, sondern mit etwas, das den aktuellen Zustand des Filesystems überprüft 🙂 ). Man kann das auch automatisieren, in dem man durch cron unmittelbar vor jedem backup einen timestamp dort hinterlegen lässt. Es ist auch denkbar, gewisse Zustände so zu verewigen. z.B Softwareversionsstände im Laufe einer Migration (geht ebenfalls automatisiert, vor allem da die meisten tools beim Aufruf mit -V ihre aktuelle Versionsnummer ausgeben.) oder noch ausstehende Schritte. So habe ich mir angewohnt, vor grösseren Schritten, erst touch /root/snap/[namedesgroesserenschrittes] ; rsnapshot hourly && rm -f /root/snap/[namedesgroesserenschrittes] auszuführen. So kann ich, wenn was schief geht, leicht auf alte Konfig zugreifen, kann das aber durchaus öfter machen, da diese Backups durch die stündliche Rotation wieder rausfallen. Evtl. geht eines davon auf die Reise durch die weiteren Intervalle, aber das stört mich nicht weiter.
Dabei muss man natürlich bedenken, wie lange man die Backups aufheben möchte. Da rsnapshot die einzelnen Intervalle unabhängig voneinander rotiert, passiert es leicht, dass ein Zustand, der nur in einer einzigen Sicherung vorhanden ist, bei der stündlichen Rotation rausfällt. Möchte man, dass gewisse Dateien länger im Backup bleiben, gibt es leider keine Garantie dafür. Wenn alles glatt geht, sollte das Aufheben aber funktionieren, wenn man die Datei einen Intervall des Backupzyklus lang verfügbar macht, für das man es aufhält. Ist eine Datei also eine Woche lang auf dem Filesystem zu finden, hat man gute Chancen, sie in allen hourly, allen daily und mindestens einem weekly zu finden, bis die Rotation sie aus dem letzten weekly wirft. In unserem Beispiel also 5 Wochen und 1 Tag lang. Gefährdet wird diese Logik vor allem, wenn man ausgiebig Gebrauch von den oben erwähnten „händischen Backups“ macht. Damit erhöht sich die Zeit, die ein Status bestehen muss, um ins daily überzugehen natürlich entsprechend.
Die yearly backups scheinen in den meisten Fällen überzogen, aber das ist aus meiner Sicht der beste Weg, einen Zustand dauerhaft zu bewahren. Dazu ein Beispiel aus der Praxis. Bevor ich eine grössere Migration beginne, in deren Rahmen ich rsnapshot einführe, lege ich die Konfiguration an und lasse, dem obigen Beispiel folgend, 24+7+4+12+10 mal folgenden Befehl laufen: rsnapshot hourly ; rsnapshot daily ; rsnapshot weekly ; rsnapshot monthly ; rsnapshot yearly. Das dauert nicht sehr lange und braucht nur minimal mehr Platz als eine einzige Kopie des zu sichernden Filesystems. Ab da beginne ich die normalen cron Läufe mit hourly stündlich, daily täglich… . So kann ich davon ausgehen, dass für die ganze Dauer der Migration und auch jedes spätere Mal, wenn ich zu diesem Kunden komme, die ursprüngliche Ausgangssituation im letzten yearly noch vorhanden ist.
Noch ein paar Worte der Warnung. Als Ziel wird rsnapshot ein Verzeichnis angegeben. Wenn dort ein anderes Filesystem, z.B. von einer USB Festplatte, gemountet ist und man diese entfernt, legt rsnapshot einfach in dieses Verzeichnis neue Backups an, womit man sich ganz schnell Festplatten anfüllen kann. Dieses Verhalten ist allerdings konfigurierbar. Falls das reguläre Backuptool das rsnapshot Zielverzeichnis inkludiert und nicht mit Hardlinks umgehen kann, wird man bald einen Backupadmin mit einer roten Kletzn (österr. für „Kopf“) im Büro stehen haben, weil man bei der obigen Konfig 24+7+4+12+10+1 mal den gesamten Platz des zu sichernden Filesystems wegkopiert. Das selbe gilt bei Netzwerkshares, etc. auf die man hinschreibt, sofern die nicht mit Hardlinks umgehen können. Aus dem gleichen Grund kann man auch nicht einfach via ssh oder ähnliches auf einen entfernten Server sichern. Um das hinzubekommen, muss man via rsync auf den Zielhost sichern und dort dann rsnapshot laufen lassen. Wer auf andere Hosts sichern, selbst auf dem selben Host die Backupkonfiguration verwalten und Backups auch noch verschlüsseln will, sollte sich evtl. duplicity und die vielen kleinen Tools, die einem das Leben damit deutlich einfacher machen, wie duply oder deja-dup ansehen. Eine Stolperfalle, in die man immer wieder gerne tappt, ist das Konfigfile, das Optionsname und Wert immer mit Tabulator getrennt verlangt und bei Zeilen, die Leerzeilen statt Tabs enthalten, Fehler wirft. Daher bietet es sich immer an, einen rsnapshot hourly Lauf nach Konfigänderungen zu machen.
Nicht zuletzt sollte man immer daran denken, Restores nur mit Kopien zu machen, da man Daten tatsächlich aus den Backups rausnehmen kann und so unter Umständen alle Kopien vernichtet. Umgekehrt muss man Backupsets, die man aus der Rotation entfernt (Pfade, die nicht mehr gesichert werden oder wenn man z.B. von 48 hourly auf 24 hourly umstellt) selbst löschen. Das nimmt einem rsnapshot nicht ab.

Thomas Widhalm

Manager Operations

Lies mehr von Thomas und triff unser Team

Backporting – Quick and a bit dirty

von Marcus Hanisch | Jul 5, 2011 | Linux, Development

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen „testing“-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.
Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
durch die Maintainer an das Debian-System angepasst
einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht „zugemüllt“ wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System „zerschossen“ wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).
Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.

Nächste Einträge »