Graphite vs. IOPS – experience exchange

Last year, Blerim told us how to benchmark a Graphite and now we want to share some experience on how to handle the emerging IOPS with its pro and contra. It is important to know that Graphite can store its metrics in 3 different ways (CACHE_WRITE_STRATEGY). Each one of them influences another system resource like CPU, RAM or IO. Let us start with an overview about each option and its function.

max

The cache will keep almost all the metrics in memory and only writes the one with the most datapoints. Sounds nice and helps a lot to reduce the general and random io. But this option should never be used without the WHISPER_AUTOFLUSH flag, because most of your metrics are only available in memory. Otherwise you have a high risk of losing your metrics in cases of unclean shutdown or system breaks.

The disadvantage here is that you need a strong CPU, because the cache must sort all the metrics. The required CPU usage increases with the amount of cached metrics and it is important to keep an eye on enough free capacity. Otherwise it will slow down the processing time for new metrics and dramatically reduce the rendering performance of the graphite-web app.

naive

This is the counterpart to the max option and writes the metrics randomly to the disk. It can be used if you need to save CPU power or have fast storage like solid state disk, but be aware that it generates a large amount of IOPS !

sorted

With this option the cache will sort all metrics according to the number of datapoints and write the list to the disk. It works similar to max, but writes all metrics, so the cache will not get to big. This helps to keep the CPU usage low while getting the benefit of caching the metrics in RAM.

All the mentioned options can be controlled with the MAX_UPDATES_PER_SECOND, but each one will be affected in its own way.

Summary

At the end, we made use of the sorted option and spread the workload to multiple cache instances. With this we reduced the amount of different metrics each cache has to process (consistent-hashing relay) and find the best solution in the mix of MAX_UPDATES_PER_SECOND per instance to the related IOPS and CPU/RAM usage. It may sound really low, but currently we are running 15 updates per second for each instance and could increase the in-memory-cache with a low CPU impact. So we have enough resources for fast rendering within graphite-web.

I hope this post can help you in understanding how the cache works and generates the IOPS and system requirements.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

SSL leicht gemacht – forcierte Weiterleitung von HTTP auf HTTPS einrichten

In den vorherigen Teilen der Serie wurde bereits die Erstellung und Einbindung der Zertifikate beschrieben. Eines Tages wünscht sich der Admin jedoch die sichere Verbindung aller Seitenbesucher, ohne dass diese manuell ein https voranstellen müssen. Gerade bei einer Migration einer bestehenden Seite wird der

Parallelbetrieb erst nach eingehenden Tests eingestellt und das SSL jeweils forciert, um Seitenbesucher nicht mit ungültigen Zertifikaten oder Mixed Content zu verunsichern.

Die eigentliche Umsetzung ist dann relativ einfach und wird in unserem Beispiel direkt in der Vhost-Definition des Apache vorgenommen. Übrigens, die verfügbaren Vhosts sind zu finden unter: /etc/apache2/sites-available. Hier wird nun der HTTP-Vhost (Port 80) um den unten aufgezeigten Block mit den Rewrites erweitert.

<VirtualHost *:80>
  ServerAdmin webmaster@netways.de
  ServerName www.netways.de
  DocumentRoot /var/www/html/netways.de/
  <Directory /var/www/html/netways.de/>
   Options FollowSymLinks
   AllowOverride All
  </Directory>
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
  CustomLog /var/log/apache2/access.log combined
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.netways.de [OR]
  RewriteCond %{SERVER_NAME} =netways.de
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
 </VirtualHost>

Damit das Ganze nun auch funktioniert, muss natürlich der SSL-Vhost unter Port 443 erreichbar sein. Wie dieser initial erstellt wird, ist im Artikel SSL-Zertifikat einbinden beschrieben.

Übrigens: wer Let’s Encrypt verwendet, wird im Wizard gleich gefragt, ob SSL forciert werden soll. Der Wizard übernimmt dann die oben gezeigten Schritte. Wie man Let’s Encrypt einsetzt, haben wir natürlich auch schon einmal beschrieben. Damit später keine Seitenbesucher verloren gehen, sollte der HTTP-Vhost, der auf Port 80 läuft, nicht abgeschaltet werden. Die Verbindung ist mit dieser Maßnahme sicher und alle Besucher werden auf https umgeleitet.

Wer damit gar nichts zu tun haben will, und trotzdem stets auf der sicheren Seite sein will, der kann natürlich seine Seite auch bei NETWAYS im Managed Hosting betreuen lassen. Hier kümmern wir uns darum.

In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Generationswechsel bei GnuPG/PGP Schlüsseln

Die für digitale Signaturen und zum Verschlüsseln von Daten verwendeten GnuPG bzw. PGP Schlüssel sind keine reinen Schlüssel im eigentlichen Sinne. Stattdessen enthalten sie den eigentlichen Schlüssel und diverse zusätzliche Informationen wie, für welche “IDs” (also Kombinationen aus Name und E-Mailadresse) sie gültig sind, wie lange sie gültig sind und einige Informationen über Hash- und Verschlüsselungsalgorithmen, die der Besitzer des Schlüssels vorzieht oder überhaupt zulässt.

Da sich das Wissen über die verwendeten Algorithmen weiterentwickelt und immer mehr Rechenleistung immer günstiger zu haben ist kann man leider nicht davon ausgehen, dass man einen Schlüssel für immer verwenden kann. Irgendwann ist er schlichtweg überholt und kann nicht mehr als sicher gelten. Dafür sind vor allem drei Komponenten ausschlaggebend: Die Länge des eigentlichen Schlüssels, der bevorzugte Verschlüsselungsalgorithmus und der für Signaturen verwendete Hash-Algorithmus.

Bei der Länge wird man beim Erstellen des Schlüssels mit einer Auswahl konfrontiert, die eine minimale und eine maximale Länge angibt. Manchmal kann man diese Auswahl auch übersteuern, läuft dann aber Gefahr, einen Schlüssel zu haben, mit dem viele Kommunikationspartner gar nichts anfangen können oder der so lange für jede Aktion braucht, dass er alleine schon deshalb unbrauchbar ist. Unter einigen Umständen bringt ein extralanger Schlüssel überhaupt nichts, da z.B. damit nur eine weitere, einmalige, Passphrase gesichert wird, die eine fixe Länge hat. (Asymmetrische Verfahren für lange Texte zu verwenden ist auch heute noch zu rechenintensiv, weshalb meist ein symmetrisches Verfahren mit einer einmaligen Passphrase eingesetzt wird und nur die wird asymmetrisch verschlüsselt). Etwas mehr dazu findet man in einem älteren Post zu dem Thema.

Die für die Kommunikation bevorzugten Algorithmen kann man in den “Preferences” des Schlüssels setzen. Mehr dazu im zuvor genannten Blogpost.

Signaturen jedoch werden einmalig erstellt und sollen dann gelten. Wer schon länger mit GnuPG arbeitet wird also noch einige Signaturen mit SHA1, so auch die Selbstsignatur, mit der der Schlüssel ursprünglich ausgestattet wurde. SHA1 gilt aber schon lange nicht mehr als sicher, weshalb man ihn auch nicht mehr benutzen sollte. (Ebenso MD5, mit dem auch früher Signaturen erstellt wurden). Wer einen DSA Schlüssel mit 1024bit Länge hat, sollte sich jetzt angesprochen fühlen.

Es gibt also mittlerweile mehrere Gründe, manche alte Schlüssel zu überdenken. Die Liste der bevorzugten Algorithmen lässt sich auch bei einem bestehenden Schlüssel einfach austauschen. Die Schlüssellänge liesse sich durch einen neuen Subkey realisieren, der aber auch einige extra Schritte beim Handling braucht. Signaturen auszutauschen wird aber ein aufwändiger Prozess, weil man mit allen, die den alten Schlüssel signiert haben, nochmal in Kontakt treten und sie um neue Signaturen auf dem neuen Schlüssel bitten muss. Und da wir ja hoffentlich alle sehr viele Signaturen auf unseren Schlüsseln haben, kann das schon recht aufwändig werden.

Um also möglichst alle Probleme, die ein alter Schlüssel mit sich bringt, auf einmal zu erschlagen, gehen viele User den Weg, einfach einen neuen Schlüssel anhand möglichst aktueller Best Practices (als Ausgangspunkt kann wieder der vorherige Blogpost dienen) zu erstellen und auf den umzusteigen.

Um einen neuen Schlüssel zu etablieren und einen alten dadurch zu ersetzen, kann man folgendermassen vorgehen:

  • Einen neuen Schlüssel anhand aktueller Best Practices erstellen
  • Den neuen Schlüssel mit dem alten Schlüssel signieren
  • Ob man auch den alten Schlüssel mit dem neuen signieren soll, da gehen die Meinungen auseinander. (Ich hab’s jedenfalls immer gemacht)
  • Den neuen Schlüssel (und ggf. den alten, aktualisierten) auf Schlüsselsever hochladen
  • Den neuen Schlüssel bekanntmachen. Am besten über möglichst viele Kanäle, die man sonst auch nutzt, um mit der Welt zu kommunizieren. E-Mail, Soziale Medien, Blog, Website,…
  • “Dinge”, die bestehen bleiben sollen, also Dokumente, Pakete, etc. die mit dem alten Schlüssel signiert wurden mit dem neuen Schlüssel signieren. Wenn mehrere Signaturen möglich sind, sollte die neue hinzukommen, sonst muss sie ersetzt werden. Vor diesem Schritt sollte man etwas warten, damit die Empfänger eine Chance haben, den neuen Schlüssel zu holen bzw. zu bemerken.
  • Die Leute, die den alten Schlüssel signiert haben, sollten informiert und gebeten werden, den neuen Schlüssel ebenfalls zu signieren.

Für den letzten Punkt gibt es einige Vorlagen, die man verwenden kann. Es bietet sich an, ein Klartextdokument aufzusetzen, in dem über den Tausch informiert wird und gleich die nötigen Befehle mitzuliefern, mit der der neue Schlüssel geholt und signiert werden kann. Ein entsprechendes Beispiel habe ich für meine persönlichen Schlüssel verfasst. Dieses Dokument wurde auch gleich sowohl mit dem alten als auch dem neuen Schlüssel unterschrieben, um den Empfängern die Echtheit zu bestätigen.

gpg --digest-algo SHA512 --clearsign -u 6265BAE6 -u A84CB603 key-transition-2018-01-05.txt

Dieses Dokument sollte man möglichst öffentlich machen und an die Leute schicken, die den alten Schlüssel signiert haben.

Verwendet man den Schlüssel auch zum Signieren von Paketen, ist der Umstieg etwas schwieriger. Man kann leider nicht erwarten, dass jeder User, der die Software einsetzt, auch regelmässig ein Blog oder andere Neuigkeiten liest, weshalb ein einfaches Ersetzen des Schlüssels dazu führen würde, dass die User neue Pakete nicht mehr installieren können. Um den Umstieg einfacher zu machen sollte bereits im Vorfeld ein “release”-Paket bereitgestellt werden, also eines das das eigene Repository in den Packagemanager der User konfiguriert und den entsprechenden Schlüssel ablegt. In diesem Paket kann man in einem neuen Release dann auch den neuen Schlüssel hinterlegen, sodass beide, der neue und der alte in den Packagemanager kommen. Stellt man später um, mit welchem Schlüssel man Pakete signiert, werden sie automatisch als valide signiert erkannt. (Da sich verschiedene Packagemanager unterschiedlich verhalten, sollte man das unbedingt vorher testen!)

Nicht abgedeckt sind jene User, die das Repository “von Hand” angelegt und den Schlüssel manuell importiert haben. Klar könnte man in eine Version der Software selbst den neuen Schlüssel-Import ins Paket verbauen, aber das würden einem die User (zu recht) um die Ohren hauen, da das Software Paket nur die Software installieren soll und nichts am Paketmanager verändern. Beim Release-Paket ist das was anderes, da das ja genau für solche Aufgaben gebaut wurde. Hier heisst es, im Vorfeld umso mehr über diverse Kanäle zu kommunizieren und es auch möglichst in alle fertigen Module, Cookbooks, Playbooks, etc. zu integrieren, dass für kurze Zeit zwei Schlüssel vorhanden sind und wann umgestiegen wird. Besonders geeignet ist natürlich der Release einer grösseren neuen Version, wo vielleicht sowieso ein neues Repository gebaut wird.

Einige Zeit, nachdem der Umstieg vollzogen wurde, sollte man den alten Schlüssel “revoken”, damit er nicht mehr benutzt wird. Auch könnte man das Release-Paket dazu bringen, den alten Schlüssel aus den Packagemanagern zu entfernen. Sollte tatsächlich jemand den alten Schlüssel knacken, ist man so auf der sicheren Seite und genau dafür hat man den Umstieg ja gemacht. Alte Informationen, die mit dem alten Schlüssel verschlüsselt wurden, kann man übrigens auch mit einem revoked key noch immer entschlüsseln. Jedenfalls kenne ich keine Software, die das nicht mehr erlauben würde. Nur verschlüsseln geht dann eben nicht nicht mehr.

Etwas mehr zum Nachlesen zum Thema gibt’s unter anderem auf den Debian Seiten.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

NETWAYS Review 2017 – Just Awesome

Ganz schön turbulent war’s 2017 bei NETWAYS. Nun beginnt endlich die besinnliche Zeit des Jahres.
Das nehmen wir als Anlass, das ganze Jahr nochmal Revue passieren zu lassen.
Zu allererst stand unsere Skifahrt auf dem Programm, diesmal sind wir alle mit einem riesigen Bus zur Hütte gefahren und hatten tolle, verschneite Tage, viel Sahne im Gesicht und einen Heidenspaß.

Weiter ging’s auch direkt mit dem Jahresmeeting mit vielen spannenden Neuigkeiten, leckerem Essen und der Info zu unserem Unternehmenssommerseminar auf Mallorca. Ein guter Start schonmal, fanden wir.
Schwupps stand auch schon das erste Event vor der Türe. Das Icinga Camp war wie immer herzerwärmend – Vielen Dank an die 140 Teilnehmer, die das Event immer wieder zu dem machen, was es ist!

Kurz danach kam sofort der nächste Schrei, unsere Software as a Service Plattform nws.netways.de ging online. Mittlerweile hat das NMS-Team bei NETWAYS neun super praktische Apps in die Plattform eingebaut, die darauf warten, euch euren Arbeitsalltag zu erleichtern. Das ganze Team hat einen super Job gemacht, wie wir finden.

Im Mai hatten wir neben einer weiteren wunderbaren OSDC in Berlin eine Schulungspremiere im Kesselhaus – wir freuen uns sehr, dass Graylog nun fester Bestandteil in unserem Schulungsportfolio ist.

Neben den Teamevents aller Abteilungen, dem Sommermeeting, der NETWAYS Grillfeier und der Azubiprojektwoche im Sommer, waren wir mit auf den Deutschen OpenStack Tagen in München und auch auf der OSBConf in Köln war NETWAYS natürlich am Start.

Auch unsere Developer waren sehr fleißig und es ist einiges passiert. Alle Projekte liegen nun beispielsweise auf Github, der Icinga Exchange wurde gestemmt, es gibt ein Puppet Modul und ein Dashing für Icinga 2. Auch in Elasticsearch und Graylog ging es voran. Noch dazu haben wir so viele Azubis wie nie zuvor im Development, weiter so! Besonders stolz sind wir in diesem Jahr darauf, dass wir 2017 deutlich mehr Request-Tracker Projekte und Consulting hatten, aber auch mehr Datenbanken!

Außerdem neu war der NETWAYS Monitor als erste eigens entwickelte Hardware in unserem NETWAYS Shop. Nebenbei wurden zusätzlich neun super interessante Webinare gestemmt, die Ihr alle im Archiv finden könnt. Außerdem waren wir auf der Cebit vertreten und konnten hier tolle Kontakte zu Braintower knüpfen. Ein besonderes Highlight war Christians erster OSMC-Talk, den er mit Bravour gemeistert hat.

Bei Twitter sehen wir hauptsächlich Essens- und Reisebilder unserer Consultants, aber was diese Herren das Jahr über alles leisten, ist schon beachtlich. Neben dem festen Bürotag, allerhand Schulungen (122 Trainingstage) und vielen, vielen Remote-Tagen waren unsere flotten Herren insgesamt 1126 Tage beim Kunden. Chapeau!

Im September hatten wir unser absolutes Highlight: #netwaysgoesmalle, dieser Hashtag sollte reichen.

Ehe man sich versah wurden die Tage dunkler und die Bräune der Haut wandelte sich wieder in gewohntes Gelbwurst-Weiß um – Also muss wohl die OSMC vor der Tür stehen. Unser absolutes Lieblings- Open Source Event. Dieses Jahr war die Konferenz von einer ganz besonders herzlichen und aufgeschlossenen Atmosphäre der Teilnehmer geprägt, wir sind immer noch ganz hin und weg und können’s kaum in Worte fassen. DAS WAR DER WAHNSINN!!! 

Das letzte Event nach den erstmals durchgeführten NETWAYS Startupdays war unsere eigene Weihnachtsfeier, auf der wir das Jahr gemütlich ausklingen lassen konnten und nochmal gemampft haben was das Zeug hält.

Nun bleibt uns nur, euch allen ein gesundes, erfolgreiches, neues Jahr 2018 zu wünschen.

 

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über's Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

Liebes Icinga 2, sag “Aaaaaah”

Die meisten, die schon mal ein Support Ticket aufgemacht haben, kennen das:

“Hallo, ich hab’ ein Problem, weil blah blubb.”
“Hi, das ist schade. Ich hab’ hier ein paar Seiten Doku über Euer Setup. Ist das noch aktuell?”

Und erst dann geht’s los mit der eigentlichen Fehlersuche. Das hat vor allem den Hintergrund, dass viele unserer Kunden sehr unterschiedliche Ansätze haben, wie sie ihr Setup betreuen und mit uns zusammenarbeiten. Manche kontaktieren uns nur im Notfall, andere nehmen nur grössere Umbauten mit uns gemeinsam vor und pflegen alles andere selbst und wieder andere lassen alles von uns machen. Deshalb kommt auch immer erst die Frage, ob sich nicht vielleicht was geändert hat, was natürlich völlig ok ist, nur wissen muss man es für den Support.

Oder man stellt eine Frage im Monitoringportal. Dann kommt da auch gern mal: “Sag erstmal, was für ein Setup Du hast.”

Und genau für diese Fälle gibt’s jetzt (oder eher demnächst) das “Icinga 2 Diagnostics Script”. Das Script soll zwei Anwendungsfälle haben:

  • Einen ersten Überblick über die Eckdaten einer Installation
  • Eine umfassende Datensammlung um alle Feinheiten abzuklopfen

Dabei liegt der Fokus klar auf der ersten Anwendung. Icinga und die damit verbundenen Tools haben eine unglaubliche Flexibilität und können auf so viele unterschiedliche Arten verwendet und konfiguriert werden, dass es oft ziemlich aufwändig sein kann, einen ersten Überblick zu erhalten. Deshalb soll das Script einen nicht gleich mit Unmengen an Information überwältigen, sondern sie sinnvoll und übersichtlich aufbereiten. Dazu probiert es meist verschiedene Befehle durch, die einem Betriebssystem Informationen entlocken können und listet die Ausgabe dann entsprechend aufbereitet auf.

Der andere Modus sammelt so viele Informationen wie er nur kann, inklusive Logfiles, Konfiguration, Datenbankdumps, etc. Weil diese Daten manchmal Informationen enthalten, die man nicht rausgeben darf oder will, ist das nicht der Default Modus.

Egal, welchen Modus man verwendet, das Script sammelt die Daten und legt sie auf dem Host ab, der sie eingesammelt hat. Es gibt also keinen versteckten “Phone-Home” Mechanismus oder eine “praktische” Verschlüsselung, die nur verschlüsselte Daten zurücklässt, sodass der User nicht sieht, was er da verschickt. Auch ein Ändern der Daten ist vor dem Versand natürlich möglich, um z.B. Passwörter zu entfernen.

Ein Wunschtraum für die Zukunft wäre, dass das Script im Überblicksmodus auch auf ungewöhnliche Dinge prüft und nur meldet, wenn es etwas Erwähnenswertes gefunden hat. Also z.B. wenn eine Datenbank nicht dem Schema entspricht, das mitgeliefert wird – entspricht es, gibt’s aber keinen “Ok” Eintrag, um die Übersicht nicht zu beeinträchtigen.

Das Script ist aktuell noch auf dem Stand eines schnellen Hacks, der nach einem Dokumentationstermin bei einem Kunden entstanden ist. Ich habe damals versucht, die relevantesten Eckdaten des Setups zu dokumentieren und mir notiert, welche Befehle ich benutzt habe. Das wurde noch etwas erweitert (Danke Dirk, für die vielen guten Ideen) und einige davon in ein Script gegossen. Wie wahrscheinlich die meisten, die selber Projekte laufen haben, bin ich noch höchst unzufrieden mit dem Funktionsumfang, dem Errorhandling, dem Scripting-Stil, usw. Da ich aber nicht wieder ewig warten will, bis ich doch mal Zeit finde, daran weiter zu schrauben, folge ich der Empfehlung meiner Kollegen und mache ein offizielles Icinga-Projekt daraus. Das motiviert mich erstens sicherlich dazu, eher weiter zu arbeiten und andererseits, wird so wohl eher auch mal jemand den ein oder anderen Pull-Request schicken. Bitte habt aber Verständnis dafür, dass der Fokus darauf bleibt, den Output übersichtlich zu halten.

Inzwischen befindet sich das Script schon in einem GitHub Repo im Icinga Bereich. Wer es testen möchte, Ideen dafür hat oder auch mitarbeiten möchte, findet dort alles Nötige.

Thomas Widhalm

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.

Trainings mit Style

Wer bereits die Gelegenheit hatte an einem unserer Trainings teilzunehmen, dürfte bereits festgestellt haben, dass unsere Trainer keine schnöden Powerpoint Präsentationen verwenden.

Nein, sie verwenden showoff!

Markus hat bereits schon einmal darüber berichtet und showoff kurz vorgestellt, daher hier nur noch einmal eine kleine Zusammenfassung: showoff erlaubt es den Teilnehmern die Präsentation direkt in deren Browser nachzuverfolgen und auf weitere Inhalte zuzugreifen.

Bisher waren unsere Trainingsunterlagen jedoch von der showoff Version 0.9.11.1 abhängig. Diese ist mittlerweile mehr als zwei Jahre alt und die neuere Version bietet einiges an neuen Funktionen und natürlich Lösungen für bisherige Probleme. Nachdem ich mich letzte Woche damit beschäftigte diese Versionsabhängigkeit zu neutralisieren bzw. zumindest auf die aktuelle (v0.19.3) anzuheben, sind mir ein paar neue Features aufgefallen von denen unsere Trainer und natürlich Teilnehmer profitieren.

Live Code Execution
Live Slide Anmerkungen

Wer von was profitiert, lass ich mal offen. 😀

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.