Bitkom Forum Open Source 2018

Auch dieses Jahr veranstaltet die BITKOM, genauer der Arbeitskreis Open Source, wieder das jährliche Forum Open Source. Die Veranstaltung findet am 18. September 2018 im Kaisersaal Erfurt unter dem Motto

Automatisierung von Open Source Compliance: Es geht nicht mehr per Hand!

statt. Themen wie Open Source Compliance und Governance sind nichts Neues, waren jedoch in Vergangenheit eher in größeren Unternehmen von Bedeutung. Dabei geht es sehr verkürzt um die rechtliche und fachliche Bewertung von verwendeten Open Source Produkten. Wird dies nicht oder nur hemdsärmelig gemacht, setzt sich das Unternehmen durchaus rechtlichen aber auch sicherheitstechnischen Problemen aus, welche vorsorglich hätten vermieden werden können. Wenngleich vermutlich nur ein kleiner Prozentsatz  unserer Leserschaft an dem Thema Interesse hat, empfehle ich diesen interessanten Blog-Artikel. Er erklärt aus meiner Sicht sehr ausführlich und anschaulich für wen und warum die die Bereiche Compliance und Governance von Bedeutung sind.

Da dies auch innerhalb des Arbeitskreises, bei dem wir uns seit Jahren engagieren, ein zentrales Thema ist, möchte ich hiermit auf die Veranstaltung aufmerksam machen. Im Vergleich zu vielen anderen BITKOM Veranstaltungen ist die Teilnahme, dank der Sponsoren, für alle Firmen kostenfrei möglich. Bitte sendet Eure Anmeldung an Dr. Frank Termer (f.termer@bitkom.org).

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

NETWAYS Webinare – Aus der Asche

Wer am letzten Webinar zur Icinga 2 Anbindung von Graphite und Grafana teilgenommen hat, wurde Live Zeuge wie sich ein System verhält wenn es faktisch zu heiß ist und einfach seinen Dienst quittiert. Zugegeben, so etwas passiert in der Regel relativ selten. Während eines Webinars ist der Zeitpunkt aber relativ ungünstig.

Wie angekündigt werden wir das Webinar nachholen und zwar am 23. August 2018 um 10:30 Uhr. Die kostenfreie Anmeldung ist direkt hier möglich.

Damit natürlich nicht das selbe Szenario wie beim letzten mal Auftritt, haben wir unser Equipment ein klein wenig aktualisiert.

Somit ist zumindest das Hitze- und Performance Problem kein Hindernis mehr und können entspannt in die Zukunft blicken und die nächsten geplanten Webinare mit Bravur meistern:

Ich freue mich wie immer auf eine rege Teilnahme!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

This entry is part 4 of 4 in the series SSL leicht gemacht

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.

Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.

Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort “clientbasierte Zertifikats-Authentifizierung” kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).

Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.

Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL

1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr

5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.

Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register “Ihre Zertifikate” nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.

Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!

Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir 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.

Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.

 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier

openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'

In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Gitlab | self-hosted vs. Gitlab as a Service

Egal ob GitLab-CE oder GitLab-EE, es stellt sich die Frage, ob self-hosted oder vielleicht sogar als GitLab as a Service (im Folgenden GaaS genannt). Unterschiede gibt es bei diesen beiden Varianten genug. Doch wo sind die gravierendsten Unterschiede in diesen beiden Varianten, was ist das richtige für wen? Diese Fragen möchte in dem folgenden Blogpost beantworten.

 

 

Zeitaufwand

Fangen wir mit dem zeitlichen Aufwand an. Eine GitLab Instanz zu installieren, kann schon einmal etwas Zeit in Anspruch nehmen. Installation, Konfiguration, Wartung, etc, aber auch das Bereitstellen eines Systems (Hardware Server oder VM und eventuell sogar Storage), kann hier mehrere Stunden dauern. Im direkten Vergleich hierzu steht GaaS gehostet in unserem NWS Portal. Nach bestellen einer Gitlab-CE oder GitLab-EE App, dauert es ca 10 Minuten bis alle Funktionen installiert und konfiguriert sind und GitLab einsatzbereit ist.

Umfang

Bei der self-hosted Variante hat man natürlich alle Freiheiten, die ein Administrator der Anwendung haben sollte. Die Instanz kann mit allen gewünschten Features erweitert und somit sehr stark individualisiert werden. Man hat die Auswahl ob man gerne AutoDevOps mit Kubernetes oder GitLab Runner für das Ausführen von Build Jobs haben möchte.

In der GaaS Lösung ist es so, dass hier direkt ein GitLab Runner mit ausgeliefert wird, sodass ohne Verzögerung erste Jobs laufen können. Eine Umstellung auf AutoDevOps ist jedoch auch möglich. Ebenso bringt diese Variante alle standardmäßigen Features mit, die GitLab so haben sollte. Individuelle Features können leider nicht ohne weiteres hinzugefügt werden, da diese durch das NWS Team geprüft, getestet und für alle Kunden zur Verfügung gestellt werden müssen.

Backups

Wer GitLab nutzt möchte natürlich auch Backups seiner Daten und Arbeiten erstellen. GitLab selbst bietet hier die Möglichkeit Backups aller Daten zu erstellen und diese entsprechend auf dem Server zu speichern. Regelmäßiges Warten dieser Backups ist nötig, da diese Backups je nach Größe der Instanz entsprechend Speicherplatz verbrauchen.

NWS bietet hier etwas mehr Komfort, denn um Backups muss sich hier nicht gekümmert werden. Das System erstellt automatisch jede Nacht Snapshots der Apps und auf Wunsch können auch Tagsüber Snapshots erstellt werden, zum Beispiel wenn Änderungen vorgenommen werden sollen und ein zusätzliches Backup gewünscht ist.

Updates

Regelmäßig werden durch GitLab Updates veröffentlicht. Im normalen Zyklus geschieht dies jeden Monat am 22.ten, jedoch werden zwischendrin auch Security Updates oder Bug Fixes veröffentlicht. Als Administrator vertraut man Updates nicht immer und möchte diese vorher Testen, bevor sie in der Produktionsumgebung eingespielt werden. Hier ist ein Testsystem von Nutzen.

In der GaaS Lösung ist dies automatisch der Fall. Nach Veröffentlichung eines Updates wird in verschiedenen Phasen getestet:

  1. Lokales starten der neuen GitLab Instanz
  2. Starten in der Testing Umgebung
  3. Upgrade einer “veralteten” Instanz in der Testing Umgebung
  4. Starten in der Produktionsumgebung
  5. Upgrade einer “veralteten” Instanz in der Produktions Umgebung

Erst wenn diese 5 Phasen durchlaufen sind, werden Wartungsmails verschickt und die neue Version wird für alle Nutzer live genommen.

TLS

TLS ist aus der heutigen Zeit nicht mehr weg zu denken. Zertifikate sind jedoch unter Umständen etwas teurer. GitLab bietet hier jedoch die Möglichkeit, mittels Letsencrypt TLS Zertifikate für die jeweilige Instanz zu generieren. Sowohl in der Self-Hosted Variante als auch bei GaaS ist dies recht einfach. Der Unterschied besteht lediglich darin, dass in der NWS Plattform lediglich ein Haken gesetzt werden muss, um eben diese Verschlüsselung zu aktivieren.

Self-Hosted

sed -i "/letsencrypt\['enable'\] = true/d" /etc/gitlab/gitlab.rb
sed -i "s#^external_url 'https://.*#external_url 'https://$YOUR_DOMAIN'#g" /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure

GaaS

Monitoring

Monitoring ist ebenso ein essenzieller Bestandteil von Produktionsumgebungen. Bei der selbstständig gehosteten Lösung muss sich hier eigenständig darum gekümmert werden. Welches Tool hierzu verwendet wird, bleibt jedem selbst überlassen, wir empfehlen aber Icinga 2.
Mit der GaaS Lösung kommt ein Monitoring automatisch mit. Zwar ist dies für die Kunden nicht einsehbar, jedoch werden alle Funktionen der Instanz durch unser Support Team überwacht.

Fazit

Welche Variante für einen selbst nun die richtige muss jeder für sich entscheiden. Wenn man GitLab selbst hosted, hat man absolute Kontrolle über die Instanz. Backups, Updates, Ressourcen, es kann selbständig über die Dimensionen entschieden werden und man ist etwas flexibler als in der GaaS Lösung. Jedoch ist in eben dieser der Vorteil, dass Backups, Updates, sowie Konfiguration und Support von den Mitarbeitern von NWS übernommen werden. GitLab kann in NWS 30 Tage kostenlos getestet werden, probiert es also einfach mal aus – testen

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Monthly Snap July – Sommermeeting & Grillfeier | Icinga Releases | Neuerungen, Updates, #lifeatnetways

Während der Monat Juli zu Ende geht, klettern die Temperaturen auf ihren diesjährigen Höchststand: Dienstag, 31. Juli | 36 Grad! Jeder geht mit der Hitze ja anders um. In einem solchen Monat lernt man seine Kollegen nochmal ganz anders kennen – und schätzen! Mit Nicole und Markus etwa werden Stieleis-Kindheitsträume wahr 😉

Sommer, Sonne, Sommermeeting

Highlight des Monats ist der 20. Juli: Sommermeeting und Grillfeier! Vormittags versammelt sich die gesamte NETWAYS Familie im Kesselhaus, wo die Teamleads das Abteilungsgeschehen präsentieren und CEO Bernd eine motivierende Rede hält, wie sie nur Bernd halten kann und einen Ausblick auf große Veränderungen gibt: Wir werden umziehen – physisch in neue Räumlichkeiten, virtuell auf eine neue Webseite. Das muss natürlich gefeiert werden: Am späten Nachmittag ziehen immer mehr Kollegen auf die Dachterrasse zu BBQ, DJ Alexander und Gin&Tonic-Bar.

Gefeiert hat die NETWAYS Familie im Juli so einiges  – auch den #SysadminDay, zu dem es ein großes Frühstücksbuffet gab.

Neuerungen und Updates

Aber wir waren auch abseits der Tanzfläche fleißig! Eine ganze Reihe NWS | Neuerungen und Updates stellt Marius in seinem Blogpost vor. Alexander hat SSL geknackt! Naja, fast. Markus sieht sich ReaR mal anders an und Georg erklärt, wie man einen verschlüsselten File-Container mittels cryptsetup und LUKS erstellen kann. Consultant Markus verrät, wie wir dienstlich Reisen. Marius hat einen anderen Ansatz gefunden: Let’s Encrypt HTTP Proxy: Another approach und Webinar-Meister Christian präsentiert die NETWAYS Webinare: Icinga 2 Serie.

Überhaupt Icinga! Hier hagelts Releases

Mitte Juli präsentieren die Icinga Entwickler ihr Icinga 2.9.0 Release! 2.9.0 bringt Neuerungen wie Elasticsearch 6-Unterstützung, eine einfachere Client-Installation und Bugfixes in punkto Windows-Reload, Speicherprobleme, geplante Downtimes und Benachrichtigungsreihenfolge. Kurz darauf folgt das Release von Icinga Web 2 2.6.0 mit zusätzlichen Dashboard-Widgets, einer neuen Hostgruppen-Übersicht und erweitertem Audit-Logging. Dank aufmerksamer Community Mitglieder, die einen weiteren Bug melden, kann die Icinga Crew letzte Woche gleich noch eins drauf setzen: Icinga 2.9.1.

Auch unsere Buchautoren Lennart und Thomas setzen eins drauf: Icinga 2 Buch, 2nd Edition. Dank Gunnar gibt es in unserem Blog einen Überblick über den Icinga Config Compiler. (Und dank @noledge eine lustige Icinga-Integration. ;))

Let it grow!

Am 1. August wird der erste von 7 (!) neuen Azubis in diesem Jahr kommen. Ja, auch deswegen werden wir umziehen: Wir wachsen! Unsere derzeitigen Auszubildenden kennt ihr ja schon. Afeef hat sich im Juli aber noch einmal genauer vorgestellt (Serie: NETWAYS stellt sich vor). Und worüber zerbrechen sich die anderen so den Kopf? Philipp beschäftigt sich mit der i-doit API, Killian mit AI – Artificial Intelligence (Was ist das? Ist das Gefährlich?) und Nicole gibt einen Einblick in ihre Projektwoche in der Berufsschule.

Und sonst so?

Nach dem einen Event, ist vor dem anderen: Von der OSDC gibt es Fotos, Slides und Videos im Archiv, für die OSBConf steht das Programm. Check it out! Niemals zuvor hatten wir so vielen Anfragen von Menschen, die unser Kesselhaus mieten wollen. Nie zuvor so früh im Jahr so viele Anmeldungen für die OSMC und so viele neue Speaker. Freut euch auf den Herbst! Dann gibt’s auch wieder viele interessante und lehrreiche Schulungen. Guckt doch mal in unseren Kalender: Die Zeit ist reif!

In diesem Sinne: Schönen Sommer!

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.