pixel
Seite wählen

NETWAYS Blog

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: „Welches Linux ist das Beste?“. Also für mich ganz persönlich. Nicht für die weite Welt. Zur Auswahl stehen die rpm Fraktion wie centos, fedora oder rhel; debianoide wie ubuntu, mint, debian und arch Derivate wie Manjaro oder Endeavour.

Entscheidungsmatrix

  • Suse ist raus, fedora ist mir zu unstable, centos/rhel zu altbacken.
  • ubuntu ist mir zu kommerziell, debian zu rock-stable, mint vereinigt irgendwas dazwischen
  • Manjaro finde ich ganz gut, Endeavour ist ein reines Arch mit beigelegtem installer.

Ergebnis

Ich nehme nichts von alledem, sondern Arch-Linux ohne Verpackung, aus folgenden Gründen.

Ein sehr neuer Laptop hat manchmal aktuelle Chipsätze oder ähnliches, die einen aktuellen Kernel oder andere Tools erfordern. Bei Arch Linux bekommt man immer aktuelle Software und muss nicht auf einen neuen Major-Release der Distro warten, da es sich um einen Rolling-Release handelt.
Für die Installation des OS brauche Endeavour oder Manjaro mehr. Das reine Arch Linux bringt mittlerweile einen terminal basierten Installer mit. Bis vor ein paar Jahren musste man die im Arch-Wiki beschriebene Schritt für Schritt Installation durchführen. Jetzt hat sich das mit archinstall aber sehr vereinfacht. Hier hat man nach circa 5 Minuten ein lauffähiges System. In meinem Fall: Eine LUKS verschlüsselte Basis Partition, darauf ein Gnome mit Wayland. Eine Besonderheit ist mir dabei aufgefallen. Per Default wird nicht mehr grub sondern systemd-boot genutzt. Ein letzter Fallstrick: Man sollte bei „Netzwerk“ angeben, dass der NetworkManager die Verbindungen verwaltet, sonst hat man nach dem Neustart der Installation kein Netzwerk mehr. Damit dann nicht zu langweilig wird ist dann natürlich kein NetworkManager installiert und ohne Internet ist das auhch nicht möglich. Da ifconfig(depricated) auch nicht installiert ist landet man dann schnell an dem Punkt, wo man mit dem *ip* command weiterhelfen muss.
Generell ist das Arch-Wiki eine gute Anlaufstation für Hilfe. Obwohl Arch eine viel kleinere Nutzerbasis hat als Ubnutu oder fedora, ist das Wiki mittlerweile so ausführlich, dass ich darin auch Lösungen für Probleme finde die ich mit anderen Distros habe.
Updates: funktionieren einfach. Ich benutze seit circa sieben Jahren Arch Linux und konnte in der Zeit immer problemlos updaten. Ab und zu muss man mal den keyring aktualisieren wenn die Updates lange ignoriert wurden aber die Updates – an und für sich – funktionieren einfach.
Bei Ubuntu oder Fedora kann man das Glück haben das ein Softwarehersteller direkt Pakete baut und anbietet. Bei Arch nicht. Bei Arch gibt es allerdings das Arch User Repository (AUR). Hier werden an zentraler Stelle Pakete von einer großen Community gepflegt. Ein AUR Paket besteht dabei im Prinzip aus einem Pacman-Install-Skript(PKGBUILD), dass entweder vorkompilierte binaries von *irgendwo* laden oder auch mit Quelltext Binaries on-demand kompilieren kann. Allerdings muss man sich bewusst sein, dass die PKGBUILD zwar im AUR von der Community geprüft werden *können*, aber nicht in jedem Fall sicher sind. Ich finde aber das PKGBUILD-Format ist sehr einfach lesbar und man kann genau nachlesen was genau von wo heruntergeladen und wie installiert wird. Wenn man z.B. spotify aus dem AUR installiert kann man nachlesen, dass das debian Paket hierfür genutzt wird und von repository.spotify.com geladen wird. Außerdem kann man hier sehen, wie gpg genutzt wird um den Inhalt zu verifizieren.

[...]
source=('spotify.protocol'
'LICENSE'
"${pkgname}-${pkgver}-x86_64.deb::http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_${pkgver}.${_commit}_amd64.deb"
[...]

Um mit AUR Paketen einfach installieren zu können favorisiere ich YAY, dass als pacman replacement fungiert. Eine Installation von eben genanntem Spotify würde man z.B. mit *yay spotify* anstoßen. Und bevor ich es vergesse: die schicken Icons aus dem Screenshot kommen aus dem buuf icon-set und können auch mit yay installiert werden.

To the moon

Für mich ist Arch aktuell das optimale Betriebssystem und wenn alle Anderen ihren Fehler endlich eingesehen haben könnte 2023 das Jahr des Linux-Desktops werden.

Christoph Niemann
Christoph Niemann
Senior Consultant

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.

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist:
Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten Daten von einem System sammelt und als ZIP verpackt. Das ZIP kann in Support Fällen an uns geschickt werden, damit wir uns einen Überblick über das System machen können.

Letzte Woche konnte mit Verzögerungen die Version 0.7.0 veröffentlich werden, welche nun auch Daten über die IcingaDB und Redis sammelt. Von Versionen bis hin zur Konfiguration und Service Status wird alles mit gesammelt.

Im Rahmen dieses Blogposts möchte ich euch einen kleinen Ausblick geben, welche möglichen Erweiterungen wir mit dem Support Collector noch abbilden möchten.

Systemweiter Datensammler

Zum aktuellen Stand sammelt der Support Collector Daten ein, speichert sie in eine Datei und verpackt dass alles zu einem großem ZIP. Das ganze passiert aber nur auf dem System auf welchen das Tool ausgeführt wird. Jetzt stehen wir natürlich vor dem „Problem“ dass Icinga 2 Umgebungen über mehrere Systeme verteilt sein können. So kann es sein dass einfach nur die Datenbank auf einem anderen Host läuft oder dass sich irgendwo noch ein zweiter Master bzw. Satelliten befindet. Aus Sicht des Supports wäre es natürlich schön auch diese Daten mit abzufragen.
Die Umsetzung des eben beschriebenen Vorhabens ist noch nicht ganz klar, da es hier neben vielen Kleinigkeiten vor allem die Security zu beachten gilt. Da wir uns auch vorstellen können, dass nicht ein jeder es gut findet, wenn wir komplette Systeme scannen, wird diese Funktion auch nur optional. Unser Augenmerk liegt darauf, dass der Benutzer frei entscheiden kann, was er gesammelt haben möchte.

Statistiken

Mit den gesammelten Daten lassen Sich natürlich auch aussagekräftige Statistiken erstellen. Anhand von diesen Daten könnten wir von den einfachsten Statistiken wie „Welche Versionen werden wie oft genutzt“, bis hin zu komplexen Themen wie „Durchschnittliche Größe eines Systems“ oder „Welche Hardware Specs für welche Icinga 2 Größe“ erstellen. Allerdings ist auch hier noch nicht zu eindeutig wie die Umsetzung aussehen soll, da hier ebenfalls die Security und Anonymität eine große und wichtige Rolle spielen.

Mit den zwei Punkten welche ich hier angesprochen habe, konnte ich euch nur einen kleinen Einblick gegeben, was an Feature Ideen noch in Planung sind. Sollte euch etwas einfallen, was aus eurer Sicht sinnvoll wäre umzusetzen, könnt ihr gerne ein Feature Request im Git Repository eröffnen.

Tobias Bauriedel
Tobias Bauriedel
Systems Engineer

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

Icinga for Windows Preview: Visualisiert eure Metriken!

Icinga hat in seinem Blogpost mitgeteilt, dass es mit Icinga for Windows v1.10.0 einige Änderungen an den Performance Metriken geben wird. Hier wollen wir einmal grob zusammenfassen, worum es geht und welche Auswirkungen diese Änderungen haben. Für alle Details ist der Original-Post aber sehr zu empfehlen!

Das Label-Problem

Ein grundlegendes Problem in aktuellen Icinga for Windows Versionen ist die Tatsache, dass die Labels für Performance Metriken zwar automatisch vom Icinga PowerShell Framework generiert werden, jedoch eine Filterung auf diese Werte innerhalb von Grafana nicht so einfach möglich ist. Nimmt man sich einmal das Partition-Space Plugin zur Hand, sehen die Metriken wie folgt aus:

‚free_space_partition_c’=10328260000B;;;0;491811100000

‚used_space_partition_c’=481483000000B;;;0;491811100000

Das Label ändert sich dabei, je nachdem ob das Plugin den Free- oder Used-Space der Partitionen überwacht. An sich wäre das nicht schlimm, da Grafana ja das Filtern über mehrere Metriken hinweg erlaubt. Jedoch ergeben sich Probleme bei komplexen Plugins oder wenn verschiedene Plugins eine ähnliche Struktur der Performance Metriken liefern – dann ist nicht mehr abzugrenzen, woher eine Metrik kommt.

Check_Multi Label

Um diesem Problem entgegenzuwirken, gibt es mit Icinga for Windows v1.10.0 im August einen Breaking Change: Alle Performance Metriken werden künftig im check_multi Format geschrieben. Dadurch ergeben sich eine Vielzahl von Vorteilen, da im Vorfeld schon während der Label Generierung ein Index, ein Template sowie ein Metrik Name definiert werden kann. Im Beispiel der oberen Performance Werte, sieht das Ergebnis dann wie folgt aus:

‚c::ifw_partitionspace::used’=480627800000B;;;0;491811100000

‚c::ifw_partitionspace::free’=11178000000B;;;0;491811100000

In diesem Beispiel wäre der Index unsere Partition c, das Template für die Visualisierung ifw_partitionspace und der Name der Metrik used oder free. Sowohl der Index als auch der Metrik Name müssen innerhalb der Plugins mittels der Funktion New-IcingaCheck gesetzt werden. Hierfür gibt es dann neue Argument, -MetricIndex und -MetricName. Das Template, in unserem Beispiel ifw_partitionspace, wird dabei automatisch je nach Name des Check-Plugins gesetzt.

Natürlich ergibt sich hierdurch ein kleiner Mehraufwand für Entwickler während des Bauens der Plugins, jedoch sind die Daten in der Regel sowieso vorhanden und werden in bisherige Labels eingearbeitet, weshalb dieser überschaubar ist.

Metriken Visualisieren

Da es sich hierbei um einen Breaking Change handelt und deshalb vorhandene Grafana Dashboards nicht mehr funktionieren, gibt es eine gute Nachricht: Icinga liefert ab Tag 1 der Icinga for Windows v1.10.0 für alle Plugins Grafana Dashboards aus!

Aufgrund technischer Gründe ist ein Parallelbetrieb von alten und neuen Performance Metriken nicht möglich, daher wurde dies zum Anlass genommen, standardisierte und von Icinga gepflegte Dashboards bereitzustellen. Hierfür wird lediglich InfluxDB 2 sowie Grafana benötigt. Wer bereits eigene Dashboards erstellt hat, kann sich die vorgefertigten Dashboards als Basis hernehmen und seine Ansichten anpassen, während neue User sich direkt aus dem Portfolio bedienen können.

Icinga Web 2 CPU Metriken

Icinga Web 2 Disk Metriken

Grafana Basis-Dashboard für Icinga for Windows

 

Wir freuen uns bereits sehr auf den Release von Icinga for Windows v1.10.0 im August und helfen gerne beim Update, der Implementierung oder Erweiterung. Hierzu könnt Ihr gerne mit uns Kontakt aufnehmen!

Christian Stein
Christian Stein
Lead Account Manager

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".

Icinga for Windows – Performance Boost mittels REST-Api

Seit dem ersten Release von Icinga for Windows hat sich eine Menge getan, um sowohl die Funktionalitäten, die Usability als auch die Sicherheit der Lösung zu erhöhen. Ein großer Fokus lag parallel jedoch auch immer auf der Performance, was sowohl auf den Aufbau des Icinga Agenten als auch der PowerShell oder generell der Plugins zurückzuführen ist.

Warum ist die Performance „schlecht“?

Der große flexible Ansatz von Icinga erlaubt es, beliebige Plugins in einer Vielzahl von Programmier- oder Skriptsprachen auszuführen – unter anderem auch PowerShell. Das bedeutet jedoch, dass Icinga sich keine Libraries, Inhalte oder sonstigen Informationen merkt. Stattdessen ist – im Beispiel von PowerShell – für jeden einzelnen Aufruf eine PowerShell zu starten. Hierfür müssten dann zuerst die notwendigen Bibliotheken geladen werden und gegebenenfalls umgebungsspezifische Informationen.

Zu guter letzt muss dann noch Icinga for Windows geladen werden, also das Framework und die Plugins, welche wir ausführen wollen. Das kostet nicht nur Zeit, sondern auch CPU-Ressourcen. Bis zu diesem Punkt haben wir aber auch das Plugin noch nicht ausgeführt – je nach Plugin, kommen dann noch WMI Handler und sonstige Themen hinzu, welche das Plugin abfragen und laden muss, bis man schließlich sein Ergebnis erhält.

Gibt es Lösungsansätze für dieses Problem?

Über paar Jahre in welchen Icinga for Windows entwickelt wurde, gab es mehrschichtige Ansätze, um die Performance zu verbessern. Zum einen wird von Icinga for Windows ein Cache-File für alle Komponenten des Frameworks angelegt und als „ein großes Modul“ geladen. Dadurch entfallen Lade- und CPU-Zeiten für das Einbinden von Sub-Modulen oder Skripten.

Der größte und wichtigste Ansatz ist jedoch die Nutzung des Icinga for Windows Service. Dieses kleine Service Binary erlaubt es, eine PowerShell im Hintergrund über die Windows Dienste zu starten und zu verwalten. Dadurch können über das Icinga PowerShell Framework dann sogenannte Background Daemons registriert werden, welche im Hintergrund Ihren Dienst verrichten.

Einer dieser Background Daemons, welche normalerweise als separate Komponenten installiert werden, ist in den letzten Versionen direkt in das Icinga PowerShell Framework eingezogen: Die REST-Api

Eine REST-Api für Plugin Ausführung

Mittels der REST-Api und einer entsprechenden Funktion im Icinga PowerShell Framework können Plugin-Ausführungen über die REST-Api innerhalb des Icinga for Windows Dienstes ausgeführt werden. Das hat mehrere Vorteile, da man zum einen andere Wege finden könnte, seine Plugins auszuführen, zum anderen aber die Last von Icinga for Windows komplett anders verteilt wird.

Zwar startet der Icinga Agent im Standardverhalten zwar weiterhin eine PowerShell, diese führt aber den eigentlichen Plugin Code nicht mehr aus, sondern prüft, ob die REST-Api sowie das entsprechende Feature aktiviert sind. Falls ja, wird ein Versuch gestartet, den Plugin Aufruf über die REST-Api einzustellen. Das bedeutet, dass innerhalb der Daemons und der REST-Api zwar auch Bibliotheken geladen werden müssen, diese aber persistent verfügbar und beim erneuten Aufruf des Plugins bereits vorhanden sind. Das bringt nicht nur einen Performance-Boost für die Ausführungszeit, sondern reduziert auch die CPU last deutlich.

Am Ende wird nur das Ergebnis zurückgegeben, von unserem Plugin-Handler ausgewertet und an den Icinga Agent weitergereicht. Sollte in diesem Prozess etwas schief gehen, gibt es immer noch den Fallback auf die automatische lokale Ausführung. Im EventLog von Icinga for Windows sind dann einige Details zu finden: Ob es ein Fehler bei der Ausführung des Plugins war oder ob die Ausführung zu lange gedauert hat und deshalb auf lokale Ausführung zurückgegriffen wurde.

Kann man dieses Feature einfach aktivieren?

Ja! Die einzigen Voraussetzungen für dieses Feature sind das Icinga for Windows Service Binary und der installierte Icinga Agent mit einem Zertifikat, das von der Icinga CA signiert wurde. Anschließend kann man das Feature über die IMC einfach aktivieren. Da wir nur einen HTTPS Socket anbieten, der per Default auf localhost läuft, ist weder eine externe Kommunikation möglich noch eine Nutzung der REST-Api ohne TLS.

Zuerst müssten wir den Icinga for Windows Service installieren, sofern nicht vorhanden:

Install-IcingaComponent -Name ’service‘ -Confirm;

Anschließend öffnen wir die Icinga Management Console mittels dem Befehl icinga in einer administrativen PowerShell und navigieren zu folgenden Punkten:

* [2] Settings
* [6] Icinga for Windows Features
* [0] Api-Check Forwarder

Mittels der IMC kann das Api-Check Forwarder Feature dann einfach aktiviert oder deaktiviert werden. Der jeweilige Status ist direkt neben dem Eintrag zu finden. Wenn alles aktiviert ist, starten wir zur Sicherheit noch den Icinga Agent sowie Icinga for Windows Dienst neu und alles sollte funktionieren!

Restart-Service -Name ‚icinga2‘;
Restart-IcingaWindowsService;

Und jetzt?

Wenn die Ausführungszeit der Plugins von Icinga Seite schneller und die Last auf dem System reduziert ist, sollte alles funktionieren. Natürlich kann man jetzt noch das EventLog parallel beobachten, während man Checks ausführt, ob im Icinga for Windows EventLog Probleme auftreten:

Read-IcingaForWindowsLog;

Sofern Fragen hierzu sind, es Probleme gibt oder wir bei der Einrichtung helfen können, freuen wir uns natürlich über eure Kontaktaufnahme!

Viel Spaß mit Icinga for Windows und der neu gewonnenen Performance!

Christian Stein
Christian Stein
Lead Account Manager

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".