Details über einzelne Logstash Filter rausfinden

Dass Logstash sehr performant ist, wissen hoffentlich alle, die ihn schon mal ausprobiert haben. Dennoch gibt es einige Kniffe, die man anwenden kann, um die Konfiguration so zu schreiben, dass Events noch schneller verarbeitet werden. Bisher war dabei nur das Problem, herauszufinden, ob das Tuning gefruchtet oder alles nur verschlimmert hat. Seit Version 5 hat Logstash nun eine eigene API bekommen, die es ermöglicht, etliche Informationen über den Logstash Dienst einzuholen. Diese ist per Default auf Port 9600 des Logstash Hosts erreichbar. (Eventuell, je nach Version, muss sie in /etc/logstash/logstash.yml aktiviert werden.)

# curl localhost:9600/_node/stats?pretty
...
  "process" : {
    "open_file_descriptors" : 79,
    "peak_open_file_descriptors" : 80,
    "max_file_descriptors" : 16384,
    "mem" : {
      "total_virtual_in_bytes" : 3390824448
    },
    "cpu" : {
      "total_in_millis" : 176030000000,
      "percent" : 3,
      "load_average" : {
        "1m" : 0.0,
        "5m" : 0.02,
        "15m" : 0.11
      }
    }
...

Neuer Versionen von Logstash 5 liefern sogar Details über einzelne Filter. Das Problem beim Anzeigen der Performancedetails ist nur, dass Logstash jedem Filter eine zufällige ID verpasst und ein Zuordnen nicht möglich ist. Wer jedoch die Logstash Issues auf Github verfolgt, erkennt, dass es sehr wohl eine Möglichkeit gibt, diese ID zu setzen – sie wurde nur noch nicht dokumentiert.
Folgende Konfiguration verpasst also dem angegebenen Filter eine ID, die nicht in Elasticsearch gespeichert und damit auch nicht in Kibana ersichtlich ist. Sehr wohl sichtbar ist sie jedoch über die Logstash API.

filter {
  if [program] == "kibana" {
    json {
      id => "kibana-json"
      source => "message"
      target => "kibana"
    }
  }
}

Die API liefert dann entsprechenden Output.

     {
        "id" : "kibana-json",
        "events" : {
          "duration_in_millis" : 908,
          "in" : 394,
          "out" : 394
        },
        "name" : "json"
      }

Wer keinen exec Input verwenden möchte, damit Logstash regelmässig seine eigene API abfragt, kann auch check_logstash verwenden, das es bereits als Checkcommand in die ITL von Icinga 2 geschafft hat. Über Feedback sowohl zum Plugin als auch zur Integration würde ich mich freuen. Und auch an dieser Stelle nochmal Danke an die, die bereits etwas beigetragen haben. Allen voran Jordan Sissel.
Vagrant Boxen, die die gezeigte Konfiguration bereits enthalten, gibt’s auch auf Github. Die sind zwar noch nicht so weit gediehen, wie ich das gern möchte, aber als Grundlage für eigene Experimente können sie durchaus dienen. Auch hier freue ich mich über Feedback.
Wer überhaupt gern mehr zu Logstash und dem Elastic Stack erfahren möchte, sollte sich für eine unserer Schulungen zu dem Thema anmelden. Wer jedoch noch nicht von Vagrant gehört hat, wird in einer anderen, unserer Schulungen fündig.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Schnellere Neustarts für Elasticsearch

Dass Elasticsearch das “Elastic” in seinem Namen richtig ernst meint, hat jeder, der mal mit mehr als einem Knoten experimentiert hat, feststellen können. Anders als viele andere geclusterte Dienste können Knoten fast nach Belieben zu einem bestehenden Cluster hinzugefügt und wieder entfernt werden.
Wie ernst es Elastic mit der Elastizität ist, sieht man unter anderem an den folgenden Eigenschaften. (Wer sich intensiver mit Elasticsearch auseinandergesetzt hat, wird wissen, dass es sich hier um Defaulteinstellungen handelt und man in komplexeren Setups doch das eine oder andere einstellt und nicht dem Automatismus überlässt. Also bitte keine Kommentare wie “In meinem Cluster steht aber, dass gateway.expected_nodes den Wert 23 hat.”)

  • Elasticsearch Cluster haben üblicherweise nirgends vermerkt, wie viele Knoten der Cluster beinhaltet. Lastverteilung, Wahl des Masters, etc. rechnet immer mit der aktuell vorhandenen Anzahl an Knoten.
  • Es gibt keinen Weg, einen Knoten aus einem Cluster “sauber” zu entfernen oder ihn hinzuzufügen. Entfernen bedeutet Beenden des Dienstes und Hinzufügen bedeutet Starten des Dienstes mit gleicher Konfiguration wie der Rest.
  • Backups bzw. Snapshots werden von allen beteiligten Knoten auf einen Share geschrieben und von dort gelesen. Egal, wie viele Knoten zum jeweiligen Zeitpunkt aktiv sind. Ein zwei Knoten Cluster kann ohne weiteres einen Snapshot restoren, der von einem 12 Knoten Cluster gemacht wurde, solange die Ressourcen dazu ausreichen. Konfiguration braucht man dafür nicht.
  • Kommunikation mit dem Cluster geschieht üblicherweise über die REST-API eines einzelnen Knotens, der die Anfrage im Cluster weiter verteilt. Egal, ob es sich dabei um ein Query oder eine dynamische Konfigurationsänderung handelt.

Der Nachteil dieser Elastizität ist, dass der Cluster nicht wissen kann, ob ein Knoten entfernt wurde oder nur mal kurz neu gestartet wird. Das hat zur Folge dass üblicherweise sofort nach Wegummiringerlgfall eines Knotens der restliche Cluster beginnt, Shards und ihre Repliken (Daten in Elasticsearch werden in Indices aufgeteilt, die wiederum in Shards unterteilt werden, die ihrerseits in Repliken kopiert werden – so erreicht Elasticsearch mit beliebigen Daten Lastverteilung und Redundanz) umzuverteilen, um den “Verlust” des Knotens auszugleichen. Dazu werden die Daten, die auf diesem Knoten waren, sofort auf andere Knoten kopiert – das ist möglich weil Elasticsearch per default jeden Datensatz mindest zweimal vorhält. Nachdem die Redundanz wieder hergestellt ist, werden die Shards und Repliken nochmal verschoben, jedoch langsamer, um die Last im Cluster gleichmässig zu verteilen.
Was aber nun, wenn der Knoten sofort wieder dem Cluster beitritt, weil er nur, z.B. wegen eines Kernel Updates, rebooted wurde? Die Daten, die sich noch auf dem Knoten befinden, werden validiert, ob sie noch brauchbar sind oder in der Zwischenzeit verändert wurden und eventuell verschobene Daten werden vielleicht wieder zurückverschoben. Wird Elasticsearch als Teil des Elastic Stack mit Logstash und Kibana verwendet (und das wollen wir doch alle), dann werden üblicherweise nur in den Index des aktuellen Tages Daten geschrieben und die anderen bleiben unverändert. Da Elasticsearch das jedoch nicht weiss, wird der gesamte Datenbestand überprüft. Abhängig von verschiedenen Faktoren kann dieses Überprüfen wenige Minuten bis etliche Stunden dauern. Während dieses Prüfens sind üblicherweise die Daten nicht so verteilt, wie es sein soll und der Cluster bleibt im Status “Yellow”, was einige Arbeiten daran verhindert und auch bedeutet, dass kein weiterer Knoten ausfallen sollte, um Datensicherheit zu gewährleisten. Das macht den Neustart eines gesamten Clusters Knoten für Knoten im laufenden Betrieb zum Geduldsspiel.
Zum Glück gibt es einen einfachen, wenn auch nicht weithin bekannten, Weg, Elasticsearch vom Rebalancing des Clusters abzuhalten und auch die Daten bereits im Vorfeld als unveränderlich zu markieren.


curl -XPUT http://elasticsearch001:9200/_cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "none"
    }
}
curl -XPOST http://elasticsearch001:9200/_flush/synced

Mehr dazu gibt in der Elasticsearch Doku. Der erste Befehl schaltet das Umverteilen von Shards komplett ab und der zweite führt einen sogenannten “Synced Flush” aus. Dabei werden ein paar Ressourcen freigegeben und Elasticsearch erstellt etwas ähnliches wie eine Checksum für jeden Index, der sich in den letzten 5 Minuten nicht verändert hat. Diese beiden Befehle haben zur Folge, dass auch bei Wegfall (in unserem Beispiel Neustart) eines Knotens weder die Redundanz im Cluster wieder hergestellt noch die Last gleichmässig verteilt wird. Das ist in diesem Fall gut, da der Knoten ja gleich wieder da sein wird. Wenn denn der neu gestartete Knoten wieder da ist, prüft Elasticsearch nur kurz, ob die Prüfsummen noch stimmen, wovon auszugehen ist, und bringt die Shards und Repliken auf diesem Knoten sofort wieder online. Das beschleunigt einen Neustart enorm.
Wenn alle geplanten Neustarts abgeschlossen sind, muss unbedingt der folgende Befehl abgesetzt werden, um die Umverteilung wieder zu aktivieren, da Elasticsearch sonst nicht auf den echten Ausfall eines Knotens reagieren kann.


curl -XPUT http://elasticsearch022:9200/_cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "all"
    }
}
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

yum Plugins

Auch wenn viele ihn regelmäßig verwenden, so haben sich doch nur wenige mit seinen Möglichkeiten auseinander gesetzt: yum, der Paketmanager von RHEL, CentOS, Fedora (bis vor kurzem) und einigen anderen Distributionen aus dem RedHat Dunstkreis.
Zwar wird er in absehbarer Zeit durch dnf ersetzt werden, aber bis dahin zahlt es sich durchaus aus, nochmal ein wenig Energie in yum zu investieren.Yum
Eine meiner liebsten Funktionalitäten ist die Verwendung von Delta RPMs. Dabei werden Updates nicht mehr als ganzes Paket heruntergeladen, sondern nur der Unterschied zwischen der installierten und geplanten Version. Lokal am System wird aus dem installierten Paket und dem Delta RPM dann das neue RPM zusammengebaut und installiert. Je nachdem, welches Paket aktualisiert wird, kann sowas schon einiges an zu übertragenden Daten sparen. Ja, heutzutage sind Netzwerkleitungen oft dick genug, dass es ziemlich wurscht ist, ob man LibreOffice nochmal komplett herunterlädt, oder nur die paar kleinen Änderungen, aber in einigen Situationen fällt es sogar heute noch ins Gewicht. Nicht jeder hat eine überall eine Leitung, die dick genug ist. Z.B. in Schulungssituationen oder auf Konferenzen, kann es schon mal eng werden mit der Bandbreite. Ausserdem entlastet es natürlich die Server, die die Updates zur Verfügung stellen. Hauptsächlich finde ich es aber einfach eine gute Idee und ich hab’ Spass, wenn sich jemand bei einer Lösung was gedacht hat und ich sie einsetzen kann.
Musste man früher noch ein eigenes yum Plugin installieren, reicht seit CentOS 7 die Installation des deltarpm Pakets, um diese Funktionlität zu aktivieren, wenn die verwendeten Repos das anbieten.
Zwei Plugins befassen sich mit dem Entfernen von Paketen, die als Abhängigkeit installiert wurden, aber nun nicht mehr benötigt werden: yum-plugin-remove-with-leaves und yum-plugin-show-leaves. Damit lässt sich beispielsweise durch yum autoremove jedes Paket anzeigen und deinstallieren, das einmal als Abhängigkeit installiert wurde, dessen Grund, weshalb es installiert wurde, inzwischen schon wieder entfernt wurde. Ja ich weiß, Debian kann das auch so.
Mit yum-plugin-protectbase und yum-plugin-versionlock lassen sich einfach ungewollte Updates von bestimmten Paketen, insbesondere über Repository Grenzen hinweg verhindern.
Die Erweiterung yum-plugin-local erstellt aus heruntergeladenen und installierten Paketen ein lokales Repository. Gerade im Zusammenhang mit Containern oder virtuellen Maschinen kann ich es mir praktisch vorstellen, etwas zu bauen, mit dem sich einmal heruntergeladene Pakete leichter weiter verteilen lassen.
Ein besonders praktisches Plugin finde ich search-disabled-repos . Das gibt es unter CentOS 7 nicht als eigenes Paket, sondern nur als Teil des Subscription Managers, der eigentlich für die Verwaltung von RedHat Subscriptions auf RedHat Systemen gedacht ist, aber auch auf CentOS im Paket subscription-manager verfügbar ist. Damit laufen Installationen zukünftig folgendermassen ab: Versucht man ein Paket zu installieren, dessen Abhängigkeiten nicht aufgelöst werden können, bietet yum an, auch alle aktuell deaktivierten Repositories vorübergehend zu aktivieren und dort nach den fehlenden Abhängigkeiten zu suchen. Werden sie dort gefunden, bietet yum an, die nötigen Repos einmalig für die Installation zu aktivieren oder dauerhaft. Die Default Konfiguration verhindert dabei, dass ein -y beim yum Aufruf automatisch alle nötigen Repos aktiviert.
Ein recht hilfreiches Plugin für eine defensive Versionsstrategie ist yum-plugin-security. Dafür müssen aber alle verwendeten Repositories mitspielen. Ist es installiert, können mit yum update --security nur Security-relevante Updates installiert werden und alle anderen werden außen vor gelassen. Aber nicht alle Repos stellen diese Information zur Verfügung.
Was alle Plugins gemeinsam haben ist, dass ihre Konfigurationsdateien unter /etc/yum/pluginconf.d/ liegen. Da bei einigen nur enabled=1 drin steht, ist es wahrscheinlich einfacher, das Plugin einfach wieder zu deinstallieren, als es extra zu deaktivieren. Ansonsten lohnt sich oft durchaus ein Blick in die Dateien dort, um weitere Möglichkeiten zu entdecken.
Das waren nur ein paar der verfügbaren Plugins und auch nur als Anregung gedacht, sich mal näher damit auseinander zu setzen. Die meisten Plugins sind relativ eingägig in der Verwendung und fügen sich nahtlos in die übrigen yum Kommandos (z.B. auch in help) ein.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Logstash 1.5 (bald) released

Während Version 1.5 von Logstash kurz vor dem Release steht, nehme ich mir kurz Zeit, schonmal einen Vorgeschmack darauf zu geben. Eine umfassende Liste der Änderungen findet man wie gewohnt im Changelog.
Besonders freue ich mich dabei auf folgende Neuerungen und Verbesserungen:

  • Plugin Manager: Man wird jetzt aus einer grösseren Menge an Plugins wählen und diese auch über Logstash nachinstallieren können. Ich hab’ zwar noch kein konkretes Plugin, das mir abgehen würde, aber das eröffnet doch ganz neue Möglichkeiten.
  • Konfigurationsdateien können jetzt nicht nur aus dem lokalen Dateisystem, sondern auch über http angezogen werden. Vielleicht eine etwas abenteuerliche Methode, aber sicher ein Weg, Konfig auf mehrere Hosts zu verteilen. Andererseits setzt hoffentlich eh jeder Puppet ein, oder?
  • Filter, die neue Events generieren (split, multiline, etc) reichen diese jetzt korrekt an folgende Filter weiter.
  • Man kann jetzt ein Standardverzeichnis für eigene Patterns angeben. Damit spart man sich unter Umständen einiges an Tipparbeit.
  • Syslog Inputs, die mit Nachrichten in einem falschen Format gefüttert werden, schreiben jetzt eigene Tags, damit man sie leichter debuggen kann.logstash_01
  • Der Elasticsearch Output unterstützt jetzt https mit Anmeldung!
  • Mehrere Hosts im Elasticsearch Output für mehr Hochverfügbarkeit.
  • Heartbeat Information von Logstash, damit man ihn leichter monitoren kann.

Ausserdem wurden einige Teile anscheinend enorm in ihrer Performance verbessert, was sowieso nie schlecht ist und Kibana 3 verschwindet mit Logstash 1.5 auch aus dem Logstash Paket.
 

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Elasticsearch Tribe Node

Elasticsearch hat sich einen Namen damit gemacht, in ungeahnte Grössen zu skalieren, aber manchmal ist ein Cluster einfach nicht genug. Für diese Fälle wurde der Elasticsearch Tribe Node eingeführt, eine spezielle Elasticsearch Instanz, die selber keine Daten hält, sondern mehrere Cluster miteinander verbindet und so den Zugriff auf die Daten der einzelnen Cluster erlaubt, als wären alle Daten in einem einzigen grossen Cluster vorhanden.
Allerdings wird der Tribe Node nicht verwendet, um Grössenbeschränkungen von Elasticsearch Clustern zu umgehen, da die Anzahl von Knoten innerhalb eines Clusters nur durch die zur Verfügung stehenden Ressourcen beschränkt ist. Dabei ist der Bedarf eines einzelnen Knoten so wenig, dass hunderte bis tausende Knoten innerhalb eines Clusters möglich sind.
Übliche Anwendungen des Tribe Node sind:

  • Organisatorische Einschränkungen: Verschiedene Teams sollen Zugriff auf ihren jeweils eigenen Cluster aber nicht auf die Cluster anderer Teams haben. Dennoch soll eine übergeordnete Instanz Zugriff auf alle Daten über eine gemeinsame Schnittstelle haben.
  • Rechtliche Einschränkungen: Wenn Daten in einer bestimmten geographischen Position (z.B. ein bestimmtes Land) gespeichert werden müssen, die Daten jedoch zentral abgefragt werden sollen. (Achtung, ich bin kein Jurist. Ob dieses Konstrukt wirklich solche Einschränkungen erfüllt, ist in den einzelnen Fällen extra zu ermitteln!)
  • Einschränken von Traffic: Besonders bei der Verwendung von Elasticsearch als Teil des ELK Stacks (also mit Logstash) werden oft sehr grosse Datenmengen in die Cluster geschrieben. Wird ein einzelner Cluster verwendet, um alle Daten aus Remote Offices oder verschiedenen Firewallzonen zu sammeln müssen entweder Daten vorgefiltert werden, wodurch auf Events verzichtet werden muss oder die grossen Datenmengen über Firewalls oder WAN Leitungen geschickt werden. Mit dem Tribe Node können die Daten lokal in eigenen Clustern gesammelt und zentral abgefragt werden, wobei nur die Anfrage und die aufbereitete Antwort übertragen werden müssen.

Die Konfiguration des Tribe Node ist denkbar einfach. Man gibt die Namen des Clusters in den folgenden Optionen in der /etc/elasticsearch/elasticsearch.yml an und startet den Dienst. Dabei sollte der Tribe node selbst jedoch keine Daten enthalten.

tribe:
  es1:
    cluster.name: cluster1
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.23.228:9300
  es2:
    cluster.name: cluster2
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.69.229:9300

Da sich die Cluster oft in verschiedenen Subnetzen befinden, wurde hier auch gleich multicast discovery deaktiviert und die Verbindungen zu Knoten aus den einzelnen Clustern per unicast htribe-nodeergestellt.
Wichtig ist, dass man am Tribe Node zwar lesen und schreiben, jedoch keine Indices anlegen kann. Will man also Kibana auf so einem Tribe Node nutzen, muss man den von Kibana zu nutzenden Index für eigene Daten (Dashboards, etc.) in einem der im Tribe Node zusammengefassten Cluster selbst anlegen bzw. Kibana erst mit einem der Cluster verbinden und den Index anlegen lassen, bevor man es auf den Tribe Node umleitet.
 
Mehr Info zum Tribe Node gibt’s in der Elasticsearch Dokumentation.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

OSDC 2015 – Enterprise integration with open source, day 2

Attending conferences of a certain size always brings the pain of deciding what talks to listen to. I really wished I could listen to all of them live but at least there are the OSDC archives, so I will be able to watch what I’ve missed when the videos will be edited and uploaded. Following are my personal impressions of the talks I chose from the tracks.
Despite being at least a bit tired from attending the OSDC evening event at the Paulaner Bavarian restaurant in Berlin yesterday talks were interesting enough that from the first talk on day 2 of the Open Source Datacenter Conference on the two rooms where talks were given were full of attendees again.
As first talk of day 2 Timo Derstappen used the Pixar movie plot schema “Once upon a time…” to give an introduction into microservices and how orchestrate them using the “ambassador pattern”. He showed with his demo that systemd and fleet on CoreOS can be a real alternative when running multiple containers depending on each other.
After the first coffee break of the day Ingo Friepoertner gave a short overview over the history of databases and why NoSQL databases will not replace relational databases but are the better alternative for many applications. Using the concept of “Polyglot Persistence” you will want to use the right store for the right job, so split data into different databases: Financial data in an RDBMS, user sessions in a KeyValue store and recommendations into a graph database and so on. To avoid getting stuck in a swamp of many different databases from many different vendors you can use multi-model databases to consolidate several of the beforementioned technologies into one product.


In the next talk Matthias Klein showed us how to keep development close to production by creating your own package repositories and copy only selected packages into them. Then use vagrant or Xen and puppet to create test hosts that resemble the production hosts as close as possible to roll out new packages, run tests from Jenkins and, if all went well, deploy the same packages on production systems. One of the most important factors will be to convince everyone that only packages in your repositories are allowed and that every configuration change has to be implemented in puppet so it can be reviewed more easily and tested on test hosts before the same configuration (with just some parameters replaced) goes on production hosts.
After the great lunch John Spray showed us what CephFS is, how it developed lately and what the current state is. Being not so familiar with Ceph like I wished I was, I was glad hearing that CephFS, a distributed filesystem on the Ceph backend, is available now (even if it’s not supported for enterprise use) and CephFS volumes can be mounted simultanousely on different hosts just like a network share. A great “new” feature (which is available for about a year now, which is almost no age for enterprise grade software) is the combination of Cache Tiering and Erasure Coding which basically means having a fast but small pool of disks (preferably SSDs) that handles all of your I/O and a second pool of big, slow disks where data is not replicated like in standard Ceph pools but split like on RAID 5 / 6 / Z systems where automatically “cold” data, which is rarely used, is moved to.


Next was a talk I anticipated a lot, personally. Pere Urbon talked about one of my most favourite toolsets, the ELK stack. He gave a quick explanation about what Elasticsearch, Logstash and Kibana are and what they are used for. Then he dug a bit into some real life examples about scaling the stack, especially by using a broker like Redis or RabbitMQ. In fact, RabbitMQ might be a real alternative to Redis and I will definitely see into the different possibilities, the various brokers have to offer. Not only Redis and RabbitMQ but Apache Kafka and some others. During the talk we learned a bit about the new features of the to-be-released-today Logstash 1.5 and the coming-someday Logstash 2.0. After the talk there was only one question unanswered: How is the Green Lantern Corps logo out of the slides related to the Marvel comic multiverse, Elastic normally gets most of its names out? 😉


The last talk of the day I attended was Bernds talk about why to use Icinga instead of Nagios. Whoever reads this blog should already know that Icinga (2) is way cooler than Nagios so I will not go into detail about his talk. But you should definitely look at the video in the archive when it’s online even if you’re already convinced because Bernd’s talks are always worth the while.


Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Login Logs? Gern, aber bitte anonymisiert

Wir werden bei unseren Terminen zu Logstash und ELK Stack, zum Glück, oft nach Möglichkeiten zur Anonymsierung von Informationen gefragt. Logstash bietet da schon out of the box Filter an, um sensible Daten zu schützen.
Die folgende Beispielkonfiguration zeigt gleich zwei Wege, automatisiert zu anonymisieren.

input {
  exec {
    command => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten"
    interval => 30
  }
}
filter {
  kv {
    field_split => ","
    trim => "\n"
  }
  noop {
    remove_field => [ "password", "message" ]
  }
  anonymize {
    fields => "user"
    algorithm => "SHA1"
    key => "TheSnake"
  }
  noop {
    add_field => { "message" => "message was anonymized" }
  }
}
output {
  stdout {
    codec => "rubydebug"
  }
}

Dieses Beispiel lässt sich einfach in eine Textdatei kopieren und mit Logstash auf der Commandline ausführen, ohne, dass Elasticsearch oder Kibana bemüht werden müssten.
/opt/logstash/bin/logstash -f ./blogartikel.conf
Dabei sendet diese Konfiguration alle 30 Sekunden eine Beispielnachricht, die zerlegt und anonymisiert wird und gibt sie auf stdout aus.
Der kv Filter zerlegt die Nachricht in einzelne Key-Value Paare und macht daraus Felder mit dem Namen des Key und dem Wert des Value. Liesse man die weiteren Filter weg, sähe die Nachricht wie folgt aus:

{
       "message" => "host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten\n",
      "@version" => "1",
    "@timestamp" => "2015-03-12T00:05:25.628Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "SamuelReynolds",
      "password" => "6oben1unten"
}

Da das Passwort Feld eigentlich gar nicht in nachfolgenden Tools wie Elasticsearch auftauchen soll, wird es durch die remove_field Option des ersten noop Filters komplett entfernt. Ebenso wie das message Feld, das die zu anonymisierenden Daten ja ebenfalls enthält.
Der anonymize Filter erstellt aus dem Usernamen einen Hash, damit auch dieser nicht im Klartext vorliegt. Das hat den Vorteil, dass man weitere Abfragen und Kibana Dashboards verwenden kann, um festzustellen, ob z.B. ein bestimmter User versucht, sich auf verschiedenen Hosts mit falschem Passwort anzumelden oder an einem Host viele gleiche Logmeldungen produziert. Aber man sieht in Kibana eben nicht den Usernamen des Users. Sollte es nötig sein, kann mit dieser Information ein Admin, der Zugriff auf die Originallogs am sendenden Host hat, nachsehen, wie der User tatsächlich heisst, aber nicht jeder, der Zugriff auf Kibana hat, hat auch gleich alle echten Usernamen.logstash_logo
Achtung – SHA1 gilt nicht mehr als sicher und sollte nicht mehr für sensible Daten verwendet werden. Hier wird er verwendet, um den resultierenden Hash kurz zu halten und den Blogartikel nicht mit einem zu langen Hash zu füllen. Sollte es sich um Daten handeln, die “nicht einfach zugänglich” gemacht werden sollen, aber nicht sicherheitsrelevant sind, kann durchaus auch SHA1 in Betracht gezogen werden, um nicht übermässig lange Lognachrichten zu produzieren und keine Ressourcen zur Berechnung unnötig langer Hashes zu verbrauchen. Diese Einschätzung muss aber von Fall zu Fall getroffen werden.
Der nachfolgende noop Filter fügt ein neues message Feld hinzu, um überhaupt ein solches Feld zu haben, da normalerweise jedes Event ein solches Feld hat und Filter und Dashboards sich üblicherweise darauf verlassen.
Mit den gezeigten Filtern sieht die Nachricht folgendermassen aus:

{
      "@version" => "1",
    "@timestamp" => "2015-03-11T23:22:35.293Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "ee8a9e70ee30f82b7d169b4e259b052d3e6ef2db",
       "message" => "message was anonymized"
}

Da echte Daten nicht einfach vom exec Filter erzeugt werden, wird das command Feld für das Beispiel ignoriert, das hier ja auch wieder die sensiblen Daten enthält.
Um Anonymisierung bei Bedarf umkehrbar zu machen, kann der crypt Filter verwendet werden. Damit sind damit bearbeitete Felder für Kibana noch immer unlesbar, aber bei Bedarf und nach Freigabe können Admins mit Zugang zur Logstash Konfiguration die Felder wieder entschlüsseln.
P.S. Uns ist nicht entgangen, dass Kibana 4 released wurde. Da aber aktuell noch keine Pakete zur Verfügung stehen werden wir mit dem nächsten Artikel dazu noch etwas warten.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Get up and meet those pretty tags, tags, tags

Heute gibt es mal einen Tip direkt aus der Praxis. Wer sich schon länger mit logstash beschäftigt, wird bemerkt haben, dass sich das Format der Konfigurationsdateien mit der Version 1.3 etwas verändert hat, wobei die alte Form nach wie vor gültig ist. Geändert hat sich vor allem der Weg, wie tags und types zum Festlegen der Filter und Outputs verwendet werden, die ein Event durchläuft.
Dass es durchaus seine Tücken haben kann, dass das alte Format weiterhin seine Gültigkeit hat, habe ich kürzlich in einer Schulung am eigenen Leib erfahren müssen. Das hat allerdings auch sein Gutes. Erstens wird mir das ganz sicher nicht mehr passieren und zweitens habe ich so ein Thema, über das ich bloggen kann.
Auch wenn neuere User sicherlich inzwischen das neue Format verwenden, so stösst man doch immer wieder online auf Beispiele im alten Format und wenn man die per copy&paste übernimmt, passieren ganz leicht Dinge, die man so nicht vorhergesagt hätte.
logstash_01
Zum Vergleich erstmal, wie sich tags im alten Format verhalten. In input Blöcken bedeutet die Option tags, dass Tags zum Event hinzugefügt werden. In filter und output Blöcken, dass der Filter oder der Output nur auf Events angewendet wird, die dieses Tag bereits haben. Seit logstash 1.3 verwendet man stattdessen if Verzweigungen. Um tags in Filtern und Outputs hinzuzufügen, verwendet man übrigens add_tag
Mit Types verhält es sich ganz ähnlich, auch wenn man den nur im ersten logstash Input, den das Event durchläuft, setzen und nicht mehr verändern kann.
Also wird der erste noop Filter im folgenden Beispiel nur auf Events aus dem ersten Input angewendet, der zweite noop nur auf Events aus dem zweiten Input.

input {
  stdin {
    tags => stdin
    type => debuglog
  }
  tcp {
    port => 5514
    tags => tcp
    type => syslog
  }
}
filter {
  noop {
    tags => stdin
    add_tag => noop1
  }
  noop {
    type => syslog
    add_tag => noop2
}

Also merke: tags ist nicht gleich tags
In der neueren und aktuellen Form würde man das Beispiel von oben übrigens folgendermassen schreiben.

input {
  stdin {
    tags => stdin
    type => debuglog
  }
  tcp {
    port => 5514
    tags => tcp
    type => syslog
  }
}
filter {
  if ¨stdin¨ in [tags] {
    noop {
      add_tag => noop1
    }
  }
  if [type] == ¨syslog¨ {
    noop {
      add_tag => noop2
    }
  }
}

Das Beispiel soll möglichst deutlich zeigen, was das Verwirrende an dem Unterschied der beiden Schreibweisen ist und ist deshalb selbst bewusst nicht verwirrend gehalten.
Was dadurch regelmässig passiert ist, dass jemand die Option tags in einem Filter oder Output sieht und davon ausgeht, dass dadurch ein weiterer Tag gesetzt wird, nicht, dass dies eine Einschränkung auf gewisse Events darstellt. Will ich fälschlicherweise ein bisher nicht vorhandenes Tag mit tags in einem Filter setzen, wird dieser Filter natürlich nie angewandt, da ja nie ein Event mit diesem Tag kommen wird, da ich ihn ja erst setzen möchte. Für Neulinge ist das ein Stolperstein, bis diese Möglichkeit aus dem Format entfernt wird, aber auch Leuten, die intensiv mit logstash arbeiten, kann sowas als Flüchtigkeitsfehler passieren, wie ich mir eben vor kurzem selbst bewiesen habe.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Eine aktuelle Fassung des logstash Quickstarts

Viele Open Source Projekte kommen so in Fahrt, dass man mit dem Verfolgen der Entwicklung kaum noch hinterherkommt. Auch wenn das zusätzliche Arbeit verursacht, so ist das dennoch ein Grund zur Freude. Dem entsprechend gibt es heute eine Aktualisierung des logstash Quickstart Tutorials, das ich vor einiger Zeit gepostet habe.logstash_01
Vieles hat sich beim Wechsel von Version 1.3 auf 1.4 geändert, dennoch sollten Migrationen (grossteils) reibungslos vonstatten gehen. Dieses Tutorial soll möglichst schlank und aufs Wesentliche beschränkt bleiben, weshalb ich hier nicht gross auf die Unterschiede eingehen möchte. Dennoch ist es etwas aufwändiger als die vorherige Version, dafür hat man danach eine Teststellung, die nicht nur zum Rumspielen taugt, sondern gleich der Grundstock einer Testumgebung werden kann. Genug der Vorrede, jetzt geht’s ans Eingemachte.
Inzwischen ist es auf jeden Fall empfehlenswert, logstash aus den zur Verfügung gestellten Paketen zu installieren, die praktischerweise auch noch in Repositories organisiert sind. Als Voraussetzung muss Java installiert sein. OpenJDK funktioniert für einfache Beispiele, auch wenn das Projekt inzwischen Sun, äh, Oracle Java empfiehlt.
Für die Installation werden die Repositories konfiguriert. Die nötigen Repofiles und eine Anleitung, wie man sie inkludiert, findet man hier für logstash und hier für elasticsearch.

yum install logstash elasticsearch

(Der aufmerksame Leser erkennt jetzt, dass dieses Tutorial für CentOS/RHEL/Fedora ausgelegt ist, es funktioniert aber ganz ähnlich mit Debian, SLES und diversen anderen Linuxdistributionen oder auch anderen Betriebssystemen) Etwas unüblich ist, dass sich logstash nach der Installation nicht sofort starten lässt, sondern erst eine Konfigurationsdatei angelegt werden muss. Ein Beispiel könnte folgendermassen aussehen:

input {
  file {
    path => "/var/log/messages"
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Die legt man nach /etc/logstash/conf.d/logstash.conf . Es ginge noch etwas einfacher mit einer embedded Variante von elasticsearch, aber so kann man den Testhost auch gleich für etwas grössere Tests verwenden und die zusätzliche Installation ist nicht wirklich aufwändig, wie man gesehen hat.
Da im Beispiel der logstash Prozess auf ein File zugreifen will, das eigentlich nur für root lesbar ist, sollte der Prozess nicht als User logstash, sondern als User root gestartet werden. Dazu in /etc/sysconfig/logstash (auf Debian /etc/default/logstash) folgenden Eintrag vornehmen: LS_USER=root. Für Tests schadet es übrigens auch nicht, erstmal SELinux auf permissive zu setzen.
Jetzt noch

service elasticsearch start
service logstash start
service logstash-web start

und mit dem Browser http://localhost:9292/index.html#/dashboard/file/logstash.json (oder statt localhost den Namen / die IP der Maschine mit logstash, falls man nicht lokal testet) aufrufen. Fertig. Ja, ehrlich, das wars. Logstash sammelt lokale Logfiles ein, speichert sie in Elasticsearch und dort kann man sie mit Kibana durchsuchen.
Wer jetzt ein wenig weiter experimentieren möchte, kann noch ein paar Filter mit einbauen, die die Lognachrichten weiter aufbereiten. Da auf jedem System andere Dienste in die Logs schreiben und oft auch andere Logformate eingesetzt werden, kann es sein, dass das folgende Beispiel nicht überall funktioniert.

input {
  file {
    path => "/var/log/messages"
  }
}
filter {
  grok {
    match => [ "message", "%{SYSLOGLINE}" ]
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Dieses Beispiel setzt den grok Filter ein, um Syslognachrichten mit einem mitgelieferten Muster in ihre Einzelteile zu zerlegen. Sieht man im Kibana (das vorhin aufgerufene Webinterface) nach, erscheinen am linken Rand plötzlich neue Felder, nach denen man Filtern kann. So wird beispielsweise das program Feld erkannt, das Teil des Syslog headers ist.
kibana_fields
Ein Beispiel, das auf allen Linux Systemen funktionieren sollte, ist das folgende.

input {
  file {
    path => "/var/log/messages"
    type => "syslog"
  }
  exec {
    type => "system-load-average"
    command => "cat /proc/loadavg | awk '{print $1,$2,$3}'"
    interval => 30
    tags => "sysstat"
  }
}
filter {
  if [type] == "syslog" {
    grok {
      match => [ "message", "%{SYSLOGLINE}" ]
    }
  }
  if [type] == "system-load-average" {
    grok {
      match => [ "message" , "%{NUMBER:load_avg_1m} %{NUMBER:load_avg_5m} %{NUMBER:load_avg_15m}" ]
      named_captures_only => true
      add_tag => "groked"
    }
  }
}
output {
  elasticsearch {
    cluster => "elasticsearch"
    protocol => "http"
  }
}

Hier wird in regelmässigen Abständen ein Shellcommand ausgeführt, das aus /proc die aktuelle Load ausliest und als Logevent verschickt. Die wird durch den grok Filter in Felder zerlegt, wo sie dann z.B. zum Zeichnen von Graphen in Kibana oder Graphite verwendet werden kann. Man könnte auch beim Überschreiten einer bestimmten Load ein passives Checkergebnis an Icinga schicken, um darüber zu alarmieren. Klar macht das letzte Beispiel in der Praxis wenig Sinn, wenn es die hervorragenden Monitoringplugins gibt, aber es zeigt, wie vielseitig logstash sein kann. Man könnte Icinga dabei sogar umgehen und beim Überschreiten einer Grenze der load gleich per Mail, IRC, oder Jabber einen Alarm an den zuständigen Admin schicken.
schulung_logstashIch kann nur jedem empfehlen, zumindest den Anfang des Quickstarts durchzuspielen. Das Experimentieren mit logstash und dem Rest vom ELK Stack macht einfach Spass. Wenn es dann daran geht, die Erkenntnisse so zu vertiefen, dass sie in einer Produktivumgebung eingesetzt werden sollen, geht’s hier zu Schulung und Consulting. Die beiden machen übrigens auch Spass.
Für Experimentierfreudige gibt’s als Dreingabe noch ein paar Stichworte zum Erweitern des Kibana Dashboards:

  • Rechts unten auf “Add row”, damit eine neue Zeile in hinzufügen.
  • In der neuen Zeile auf “Add panel to empty row”
  • Panel type: “terms”
  • Alle Felder so lassen, wie sie sind, nur die folgenden ändern: title: “Programme”, field: “program”, style: “pie”

 

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

OSBConf 2014 – Ein Rückblick

Trotz der gelungenen Abendveranstaltung fanden sich die Teilnehmer der Open Source Backup Conference in Köln früh am Morgen wieder ein, um an den Vorträgen teilzuhaben.
Nachdem am Vortag jeder die Gelegenheit hatte, sich durch den Bareos Introduction Workshop über Bareos informieren zu lassen oder (entsprechendes Vorwissen vorausgesetzt) im Hacking Bareos Workshop tiefer in die Marterie einzutauchen, startete Philipp Storz von der Bareos GmbH & Co KG die Vorträge mit einem Überblick über Bareos mit Details zur gerade eben veröffentlichten Version 14.2.1 Beta und deren neuen Features. Die reichen von so kleinen aber wichtigen Änderungen wie der Möglichkeit, Warnungen über das Tray Icon auf Windows Hosts anzuzeigen, über eine Reihe neuer unterstützter Betriebssystemversionen bis zu der Enthüllung, dass nun alle Bareos daemons auch auf Windows ausgeführt werden können. Des weiteren werden jetzt auch diverse Cloudstorages als Ziel für Backups unterstützt. Für bestehende und angehende User enthielt der Vortrag auch Informationen über den Einfluss von blocksize und filesize auf die Schreibgeschwindkeit beim Sichern auf Bänder.


Nach der obligatorischen Fragerunde wurde das Mikrofon an Dave Simons übergeben, der eine Einführung in Puppet gab und dabei besonders auf die Konfiguration von Bacula und Bareos Backup Clients einging. So können exported resources genutzt werden, um Informationen der zu sichernden Systeme in die zentrale Backup Konfiguration zu übernehmen. Die Slides zum Vortrag gibt es schon vorab auf Slideshare, mehr zu Puppet u.a. bei uns.
Nachdem sich Redner und Hörer in der Kaffeepause stärken konnten, gab es einen Doppelvortrag von Jan Behrend und Dr. Stefan Vollmar von zwei Max Planck Instituten über die Herausforderungen für ein Backup im wissenschaftlichen Umfeld. Als Herausforderungen wurden hier besonders die grossen Datenmengen, der besondere Wert der Daten und die durchaus ausgefallenen Anforderungen der User herausgehoben. Die grossen Datenmengen zwingen bei solchen Installationen dazu, mit virtual full backups zu arbeiten, einer Technologie, die aus einem full backup und den Sicherungen, die seit seiner Erstellung ein full backup zusammensetzen, das dem aktuellen Stand entspricht, aber völlig ohne Kontakt mit dem zu sichernden Client auskommt. Ausserdem wurde ein Weg vorgestellt, wie Hochverfügbarkeitscluster konsistent gesichert werden können. Dabei werden für 2 Knoten 3 Clients in Bareos angelegt, je einer pro Knoten und einer für den hochverfügbaren Teil, der über die virtuelle IP Adresse des Clusters gesichert wird. Wenn die Verwendung eines HFS wie Grau OpenArchive nicht dem entspricht, was sich die User erhoffen, die Datenmengen aber ein HFS verlangen, wurde in diesem Vortrag ein Weg vorgeschlagen, mit dem Backups im HFS abgelegt werden, anstatt alle Daten. Besonders ungewöhnlich war hier die Verwendung eines eigenen Netzwerkes, das nur für die Dauer eines Backups erstellt und nach Abschluss des Backups wieder deaktiviert wird.
Bevor die Mittagspause eingeläutet wurde, stellte Daniel Holtkamp noch seine Erfahrungen mit der Migration von Bacula zu Bareos vor, wobei er besonderen Wert darauf legte, dass die Bacula Backups weiterhin verfügbar sind. Gesondert hervorzuheben ist hier, dass für Wiederherstellung der Bacula Sicherungen kein Bacula mehr benötigt wird, sondern Bareos mit der bisherigen Bacula Konfiguration und Datenbank gestartet wird. Da die Migration auch für eine Bereinigung der Konfiguration benutzt wurde, finden sich in dem Vortrag einige schöne Beispiele, wie man die Bareos Konfiguration übersichtlicher und leichter handhabbar machen kann. Dabei wurde auch viel Gebrauch davon gemacht, dass Bareos statt Pfadangaben oft auch den Output von Scripts, SQL Queries oder Shellcommands verwenden kann, die Bareos selbst bei Bedarf ausführt.
Nach einem hervorragenden Mittagsbuffet gab Martin Loschwitz eine ausführliche Vorstellung von Ceph, das von Haus aus in sich redundant und mit Selbstheilungsfunktionen ausgestattet ist, weshalb in einigen Setups Snapshots als Backup ausreichend sein sollten. Dabei wurden neben weniger bekannten aber sehr vielversprechenden Features wie Qemu-rdp, mit dem KVM virtuelle Festplatten von Guests direkt in Ceph ausbringen kann, auch noch unbekanntere aber deshalb nicht unbedingt weniger vielversprechende Features wie php bindings, mit denen Webapplikationen Daten wie Bilder direkt in Ceph ablegen können, vorgestellt.
Thematisch passend handelte der nächste Vortrag vom Backup in und von einer Cloud, gehalten von Marco van Wieringen. Hier gab es einen Überblick über verschiedene verteilte Dateisysteme wie GlusterFS und eben Ceph. Dabei wurden besonders Unterschiede und die Wege, wie man als Applikation Daten in diese Services schreiben oder deren Inhalt sichern kann, hervorgehoben und jeweils eine kurze Übersicht über den Entwicklungsstand der Anbindung des jeweiligen Service an Bareos gegeben.

Da der nächste Vortrag leider ausfallen musste, sprangen dankenswerterweise Frank Bergkemper und Daniel Neuberger mit einer schnellen Vorschau auf das kommende Bareos Webinterface ein. Selbst Vorschaupakete sind in den contrib Repositories von Bareos verfügbar und müssen nur mehr getestet werden. Feedback sehr willkommen! Das Webinterface ist schon weit gediehen und wird nicht nur alle in der bconsole verfügbaren Daten anzeigen, sondern auch Daten ableiten, wie eine Übersicht, welche Medien in wie vielen Tagen auslaufen werden. Auch Graphen und andere Daten für einfaches Reporting sind verfügbar. Das auf dem Zend Framework basierende Interface soll Administratoren von spezialisierten Clients für einzelne Betriebssysteme loslösen und die Bedienung von Bareos mit jedem Gerät ermöglichen, das einen Webbrowser hat.
Zum Abschluss zeigte Ralf Dannert noch ReaR, mit dem Medien erstellt werden können, um in Kombination mit einem Backuptool wie Bareos, Bacula oder sogar rsnapshot ein bare metal disaster recovery von Linux Servern zu ermöglichen. Dabei müssen die Medien für jeden Host einzeln erstellt werden, müssen aber nicht ein ISO oder USB Stick sein, sondern können auch in eine PXE Boot Infrastruktur eingebunden werden. Für SuSE User ist dabei besonders interessant, dass es einige Erweiterungen gibt, mit denen insbesondere OpenSuSE und SLES Hosts so wieder hergestellt oder vom physischen zum virtuellen System umgebaut werden können.
Damit war es wieder eine abwechslungsreiche und interessante OSBConf, bei der sich wohl jeder, vom alten Hasen bis zum Frischling in Sachen Open Source Backup etwas Neues mitnehmen konnte. Zumindest war die Beteiligung an den Fragerunden geradezu ungewöhnlich groß. Wer sich schon auf die nächste OSBConf einstellen möchte, kann sich schon mal das Datum 29.&30. September 2015 vormerken und eine Suche nach dem Hashtag #OSBConf speichern. Die Mitschnitte und Folien der Vorträge werden online zur Verfügung gestellt, wir werden hier über das Blog Bescheid geben, wann und wo das der Fall sein wird.
OSBC_Facebook Header_DANKE
 

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...