Ein paar vim tricks

Ich benutze in meiner täglichen Arbeit vim als Editor. Im Laufe der Zeit habe ich dabei ein paar Dinge gelernt, die mir das Leben einfacher machen. Ein paar dieser “Tricks” möchte ich euch heute einmal zeigen.

Autovervollständigung

Mit vim kann man seine Texte und Scripte autovervollständigen lassen. Das funktoniert mit normalen Wörtern, die schon einmal im Text vorgekommen sind STRG + n, mit ganzen Zeilen STRG + x + l oder mit Dateien und Ordnern im Filesystem.

Einfügen auf mehreren Zeilen

Es ist zwar nicht intuitiv, aber man kann relativ einfach viel Text auf einmal einfügen. Man kann entweder vor der Curserposition, z.B. am Anfang der Zeile, oder am Ende der Zeile Zusätzliche Zeichen hinzufügen.

In jedem Fall muss man erstmal mit STRG + v die Zeilen markieren, die bearbeitet werden sollen.
Das # am Anfang der Zeilen fügt man jetzt mit SHIFT + i (instert mode), gefolgt von #, gefolgt von ESC ein.
Der . am Ende der Zeilen funktioniert ähnlich. Aber statt SHIFT + i kommt $A zum Einsatz. Wieder gefolgt von dem Zeichen . und einem ESC.

History im vim

Lange zeit dachte ich, wenn ich zweimal dd benutze ist dar erste Inhalt weg. Genauso wie bei Word’s “auschneiden/einfügen”. Das ist allerdings nicht wahr. mit :reg kommt man in die History vom vim. Möchte man z.B. den dritten eintrag einfügen, geht das mit “3p.

json, jq und vim

In vergangen Blogposts wurde ja schon über die Macht von API, json und jq geschrieben. Das lässt sich wunderbar auch im vim kombinieren. Wenn ich mir Beispielsweise die Services einer icinga2 API ausgeben lasse, schaut das erstmal im vim recht unleserlich aus.

curl -k -u root:icinga 'https://127.0.0.1:5665/v1/objects/services' |vim -

Erst durch ein :%!jq ‘.results[].attrs | select(.active==true) | {__name, display_name, enable_perfdata}’ wird daraus etwas schönes.
Jetzt wird nur noch Name, display_name und enable_perfdata angezeigt. Und das nur von Services, die “active” sind.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

DevOpsDays Berlin 2018 Recap

The sixth iteration of DevOpsDays Berlin is almost over and we would like to give you a little recap of what was offered.

This years conference was divided into two parts. The first half of both days focused on the single track talks and the second half was dedicated to Open Spaces and workshops.

We’ll only go over the 8 main talks that where presented on the single track stage, because we could not visit all the Open Spaces and workshops.

Day 1

Peter Chestna – Full Spectrum Engineering – The new Full Stack for 
Developers need to adapt – was the core idea of Peters talk. He explained how the typical software dev of the past has to evolve into a specialist in full spectrum development. Now a developer must become fluent in software testing, deployment, telemetry and even security. We have to adapt both in mind- and skillset in order to improve in our ever changing IT world.

Jessica Ulyate – Platform: How to Product?
The keyword in this talk was: product management (in DevOps).
She described in which ways to structure the communication flow between the developers and the stakeholders to efficiently get to a successful product.

Philip Smyth – Shifting ownership of code quality to developers
In short he talked about how developers should do more QA; and QA should get more into development and how his company basically merged those two departments. He described how this practice improves the workflows and makes working towards a product more efficient and focused.

Subhas Dandapani – DevOps as a Contract
Subhas talked about different areas in infrastructure and how they tried to remodelled everything into contracts. He showed us some approaches his company tried out, how they improved and where they are still struggling.

Ignite talks:

Day 2

Dirk Lehmann – Trust as foundation of DevOps
The one of the most important things when it comes to working together is – trust, according to Dirk Lehmann. In his talk he explained the principles you should strive for when working together in an organisation, be it big or small – in one location or spread over the globe.

Yuwei Ren – Mentorship: From the receiving end
In her talk she elaborated how to improve mentorship – both from the sides of the mentor and the mentee. She took us on her journey from starting university, over several internships to becoming a professional developer. The focus was on what she did, could have done better and what her advice would be for the mentors.

Ken Mugrage – Want to successfully adopt DevOps? Change Everything.
It’s usually not enough to rename a team, you should also think about restructuring the organisation itself. He stressed the different definitions of DevOps and the variety of approaches – in order to make us, the audience, think about how we could improve our systems.

Tiago Pascoal – Don’t make the same mistakes we made in our Devops journey
Tiago gave us brief overview over the past developments in DevOps culture at Microsoft Azure. He highlighted the pros and cons of the approaches Microsoft tried out, including: team structure, balance of alignment and automation, CI/CD, development cycles and many more.

Ignites of the day:

As always, DevOpsDays Berlin was an awesome event with very informative talks and a meet-up of wonderful people with the same mindset.

We hope everyone who was here with us enjoyed it as much as we did and would be happy to see the community again next year.
If you want to be part of this community, feel free to join us in 2019!

For more information on the event visit the DevOpsDays Berlin homepage.

 

Written in collaboration with Noah Hilverling 🙂

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer (von eigentlich jedem nur "Feu" genannt) verbrachte ihre Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt sie nun im Rahmen ihrer Ausbildung zum Fachinformatiker die Development Abteilung bei Netways und widmet sich dort dem Web Development. Ihre Freizeit verbringt sie hauptsächlich in den virtuellen Welten von 'Dota 2' und diversen anderen Games, an der Kletterwand in der Boulderhalle oder damit ihren Freunden und Kollegen auf die Nerven zu gehen.

SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

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 Gebert

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 unter anderen um den Support und die Entwicklung unserer NWS Produkte. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack, über die Porgrammiersprache Ruby bis hin zu Puppet. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu haben.

Linux Netzwerkschnittstellen mit check_nwc_health überwachen

Quelle: 9gag.com

Olá!

Heute möchte ich euch zeigen wie ihr lokale Netzwerk Schnittstellen unter Linux ganz einfach mit dem Plugin check_nwc_health überwachen könnt. Für die Demonstration verwende ich eine VirtualBox Maschine mit CentOS Linux 7.5.1804 (Core) und Icinga 2.9.1.

Anmerkung: Zusätzliche Icinga 2 Plugins werden im besten Fall unter /usr/lib64/nagios/plugins/contrib installiert. Hierfür muss die Konstante PluginContribDir (/etc/icinga2/constants.conf) angepasst werden da diese per se auf /usr/lib64/nagios/plugins zeigt.

 

[root@centos7 ~]# mkdir -pv /var/lib64/nagios/plugins/contrib
[root@centos7 ~]# vi /etc/icinga2/constants.conf
- const PluginContribDir = "/usr/lib64/nagios/plugins"
+ const PluginContribDir = "/usr/lib64/nagios/plugins/contrib"

Dann kann es auch schon los gehen! Zunächst müssen fehlende Pakete installieren sowie das Plugin heruntergeladen und kompilieren werden:

[root@centos7 ~]# yum install -y perl-Net-SNMP perl-Data-Dumper perl-Module-Load
[root@centos7 ~]# cd /tmp
[root@centos7 tmp]# wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# tar -xvzf check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# cd check_nwc_health-7.2
[root@centos7 check_nwc_health-7.2]# ./configure \
  --libexecdir=/usr/lib64/nagios/plugins/contrib \ 
  --with-statesfiles-dir=/var/cache/icinga2 \ 
  --with-nagios-user=icinga \
  --with-nagios-group=icinga
[root@centos7 check_nwc_health-7.2]# make
[root@centos7 check_nwc_health-7.2]# make install

Nun sollte man das Plugin im Verzeichnis /usr/lib64/nagios/plugins/contrib vorfinden. Im Endeffekt waren das jetzt auch schon alle Schritte. Nun können wir folgende Befehle einfach ausführen:

[root@centos7 check_nwc_health-7.2]# cd /usr/lib64/nagios/plugins/contrib
[root@centos7 contrib]# sudo -u icinga ./check_nwc_health --hostname localhost --servertype linuxlocal --mode interface-health

Ausgabe

Schnittstelle eth0

OK - eth0 is up/up, interface eth0 usage is in:0.00% (0.06bit/s) out:0.00% (0.00bit/s), interface eth0 errors in:0.00/s out:0.00/s , interface eth0 discards in:0.00/s out:0.00/s , interface eth0 broadcast in:0.00% out:0.00%

Schnittstelle eth1

eth1 is up/up, interface eth1 usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface eth1 errors in:0.00/s out:0.00/s , interface eth1 discards in:0.00/s out:0.00/s , interface eth1 broadcast in:0.00% out:0.00%

Schnittstelle lo

lo is up/up, interface lo usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface lo errors in:0.00/s out:0.00/s , interface lo discards in:0.00/s out:0.00/s , interface lo broadcast in:0.00% out:0.00%

Performancedaten

'eth0_usage_in'=0%;80;90;0;100 'eth0_usage_out'=0%;80;90;0;100 'eth0_traffic_in'=0.06;0;0;0;0 'eth0_traffic_out'=0.00;0;0;0;0 'eth0_errors_in'=0;1;10;; 'eth0_errors_out'=0;1;10;; 'eth0_discards_in'=0;1;10;; 'eth0_discards_out'=0;1;10;; 'eth0_broadcast_in'=0%;10;20;0;100 'eth0_broadcast_out'=0%;10;20;0;100 'eth1_usage_in'=0%;80;90;0;100 'eth1_usage_out'=0%;80;90;0;100 'eth1_traffic_in'=0.00;0;0;0;0 'eth1_traffic_out'=0.00;0;0;0;0 'eth1_errors_in'=0;1;10;; 'eth1_errors_out'=0;1;10;; 'eth1_discards_in'=0;1;10;; 'eth1_discards_out'=0;1;10;; 'eth1_broadcast_in'=0%;10;20;0;100 'eth1_broadcast_out'=0%;10;20;0;100 'lo_usage_in'=0%;80;90;0;100 'lo_usage_out'=0%;80;90;0;100 'lo_traffic_in'=0.00;0;0;0;0 'lo_traffic_out'=0.00;0;0;0;0 'lo_errors_in'=0;1;10;; 'lo_errors_out'=0;1;10;; 'lo_discards_in'=0;1;10;; 'lo_discards_out'=0;1;10;; 'lo_broadcast_in'=0%;10;20;0;100 'lo_broadcast_out'=0%;10;20;0;100

Icinga Web 2

check_nwc_health hält noch viele andere Möglichkeiten bereit die vom Umfang her, aber den Rahmen dieses Blogposts sprengen würden. Daher würde ich euch gerne auf die Dokumentation verweisen. In diesen Sinne verabschiede ich mich auch schon wieder und wünsche euch viel Spaß beim implementieren und basteln 🙂

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

SSL geknackt! Naja, fast.

Wer kennt das nicht: Da sitzt man beim Kunden (oder auch remote) und debugt ein Programm wie bspw. Icinga 2. Alle Stricke reißen und man ist dazu genötigt, den Netzwerk-Verkehr zu inspizieren… Ach ja, das ist ja alles SSL-verschlüsselt. Und dies ist auch nicht abschaltbar, selbst wenn man es dürfte. Und jetzt?

Genau in dieser Zwickmühle befand sich neulich ein Kollege und wandte sich kurzerhand an einen der Sicherheitsfanatiker hier in der Firma – mich.

Als solcher kenne ich die Maschen der dunklen Seite der Macht. So auch bspw. diese hier:

  1. Wireshark, den Netzwerk-Verkehr und den privaten Schlüssel von Icinga 2 Du brauchst: /var/lib/icinga2/certs/HOST_FQDN.key
  2. Den Schlüssel in Wireshark Du hinterlegst: Preferences (Command + Komma) / Protocols / SSL / RSA key list / Edit
  3. Den Netzwerk-Verkehr automatisch Wireshark entschlüsselt

So jedenfalls die Theorie ist…

In der Theorie sind Theorie und Praxis gleich – in der Praxis nicht. So wurden auch wir davon überrascht, dass sich am mitgeschnittenen Kauderwelsch nichts geändert hat. “Stimmt…”, fiel mir wieder ein, “da war was…”

 

Das DH macht den Unterschied

Zu Beginn einer SSL-Verschlüsselten Verbindung handeln Client und Server u.a. den konkreten Verschlüsselungsalgorithmus aus. In diesem Fall waren die beiden besonders schlau und wählten einen “Diffie Hellman” Algo. Schön für den Sysadmin, doof für uns. Der Zweck von Diffie Hellman ist es nämlich, genau solche Machenschaften der dunklen Seite der Macht dumm aus der Wäsche schauen zu lassen.

Zum Glück hatte ich noch ein Ass im Ärmel. Icinga 2 gibt dem Admin nämlich die Möglichkeit, die zu verwendenden Algorithmen einzuschränken:

--- /etc/icinga2/features-available/api.conf
+++ /etc/icinga2/features-available/api.conf
@@ -7,4 +7,6 @@
   //accept_commands = false

   ticket_salt = TicketSalt
+
+  cipher_list = "AES256-SHA256"
 }

Im konkreten Fall habe ich mich der Einfachheit halber auf einen einzigen nicht-DH Algorithmus beschränkt:

openssl ciphers |tr : \\n |grep -vFe DH

Es aber gingen theoretisch auch alle:

openssl ciphers |tr : \\n |grep -vFe DH |paste -sd : -

Nach einem Neustart von Icinga 2 und einer Wiederholung der HTTP-Anfragen hatten wir dann endlich Transparenz à la DSGVO (die grün markierten Pakete):

 

Fazit

Viel Spaß beim debuggen (lasst euch nicht vom Datenschutzbeauftragten erwischen) und vergesst nicht, die Lücke hinterher abzudrehen.

Und wenn bei euch wirklich alle Stricke reißen, helfen wir euch gerne weiter.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.