Seite wählen

NETWAYS Blog

Go – Automatische Package Updates

Durch die Einführung des GO-Module, welches ein eigenes Dependency Management für das GO-Ökosystem ist, erleichtert es dem Programmierer, die importieren Go-Packages im Projekt aktuell zu halten. Dabei muss der Programmierer diese Updates immer manuell auslösen, was über folgende Befehle gemacht werden kann:

go get -u ./...
go mod tidy

Dabei wird der aktuelle Stand aller importierten Packages heruntergeladen. Das Problem hierbei ist – wie oben erwähnt – dass der Programmierer dies manuell auslösen muss. Bei einem Projekt ist das kein Problem – sind es aber mehrere Projekte, können womöglich manche Updates vergessen werden oder es ist dem Programmierer nicht bewusst, dass Updates anstehen. Aus diesem Grund bietet sich eine Automatisierung an, genauer gesagt handelt es sich hierbei um den Dependabot.

Was kann der Dependabot?

Der Dependabot selbst ist auch ein Dependency Management Tool, welches in GitHub integriert werden kann. Dependabot sucht automatisch nach Manifestdateien und prüft dort die eingetragenen Versionen der Package-Abhängigkeiten. Wurde ein Update gefunden, erstellt Dependabot automatisch einen Pull Request, um die Packages zu aktualisieren.

Um eine Integration in GitHub zu erhalten, muss lediglich eine dependabot.yml im Ordner .github des Repositories angelegt werden:

.github/dependabot.yml

In dieser Datei kann nun das Verhalten des Bots konfiguriert werden:

version: 2
  updates:
  - package-ecosystem: gomod
    directory: "/"
  schedule:
    interval: weekly
    time: '10:00'
  open-pull-requests-limit: 10
  • package-ecosystem: In diesem Fall gomod. Kann je nach Programmiersprache angepasst werden
  • directory: Der Ort der Manifestdatei. In diesem Fall die go.mod
  • schedule.interval: Der Zyklus, wie oft auf Updates geprüft werden soll
  • open-pull-requests-limit: Limitiert die Anzahl der Pull Requests, die Dependabot für das jeweilige Repository erstellt

Die komplette Liste an Konfigurationseinstellungen kann auf der Projektseite von Dependabot gefunden werden.

Anschließend überprüft Dependabot alle Abhängigkeiten und erstellt selbstständig Pull Request mit den aktuellen Packages:

Der Pull Request kann im Anschluss gemerged werden und der aktuelle Stand der Packages ist gesichert.

Du möchtest mehr dazu wissen?

Wenn ich mit diesem Blog das Interesse an Versionsverwaltungssoftware geweckt habe, kann ich nur die NETWAYS-Trainings empfehlen. Dort werden die Grundlagen einer Versionskontrolle für Softwareprojekte auf Basis von Git beigebracht.

 

Bildquelle: Dependabot-Core

Icinga for Windows: Tools, Wrapper, Management

Immer wieder Mal lasse ich hier ein paar Worte zum Thema PowerShell und Icinga for Windows fallen und so ist es auch dieses Mal wieder. In meinem letzten Blogpost Plugins, Provider, PowerShell habe ich schon ein bisschen ein Blick in die einzelnen Repositories im Zusammenhang mit Icinga for Windows gegeben.

Dieses Mal betrachten wir das Framework, beziehungsweise dessen Komponenten und Tools, welche wichtig oder praktisch für Plugin-Entwicklung und Troubleshooting sind.

Tools

Mit den Tools des Frameworks lässt sich einiges an Arbeit sparen, diese befinden sich im icinga-powershell-framework repository unter /lib/core/tools. Natürlich können diese Tools auch außerhalb des Icinga-Kosmoses Anwendung finden.

Unter den Tools finden sich die verschiedenste Module, wie zum Beispiel Convert-Bytes, dessen Aufgabe es ist die Einheit entsprechender Byte Werte umzurechnen. Während der Anwendungsfall von Convert-Bytes sehr offensichtlich ist, gibt es ebenso Tools, welche Nischen bedienen, wie zum Beispiel ConvertTo-IcingaIPBinaryString, welches in der Bestimmung des Network-Interfaces mittels Get-IcingaNetworkInterface eine Rolle spielt.

Genauso wie im Developer-Guide beschrieben, sollten Custom-Plugins, sowie Tools, die von euch selbst geschrieben werden in ein separates Modul gespeichert werden. Falls der bisherige Funktionsumfang eines Tools nicht ausreichend ist für ein Custom Plugin oder Provider, dann sollte wenn möglich auf der Basis des Tools weiterentwickelt werden, wenn das möglich ist – aber natürlich innerhalb eines separaten Moduls.

Wie immer sind Pull-Request und Feature-Anfragen auch für Tools des Frameworks mehr als willkommen.

Wrapper

Um nicht willkürlich unterschiedliche Funktionen zu nutzen und eine grundsätzliche Einheitlichkeit in der Entwicklung von Plugins und Modulen im Framework zu habe werden Wrapper genutzt. Es ist also zielführender, wenn man sich im Voraus erkundigt, ob bestehende PowerShell-Kommandos in einem Wrapper mit gegebenenfalls erweiterter Logik bereits genutzt werden. Um ein paar Beispiele hierfür zu nennen, Restart-IcingaService ist im eigentlichen ein Wrapper für das PowerShell-Kommando Restart-Service. Dabei nutzt Restart-IcingaService aber Module, wie zum Beispiel Write-IcingaConsoleNotice oder Write-IcingaConsoleWarning, die dann entsprechend dafür sorgen, dass via Write-IcingaConsoleOutput entsprechende Informationen in einheitlicher Formatierung ausgegeben werden.

Ein ähnliches Szenario liegt auch vor für Start-IcingaService, Stop-IcingaService für Start-Service und Stop-Service. Im Falle dieser drei Wrapper wurde das Error-Handling im Icinga-Kontext verbessert im Vergleich zu den einzelnen zugrunde liegenden Kommandos.

Prominentestes Beispiel für die Plugin-Entwicklung jedoch ist wahrscheinlich Get-IcingaWindowsInformation, mehr oder weniger ein Wrapper für Get-WmiObject und Get-CimInstance. Get-IcingaWindowsinformation hilft hierbei nur WmiObjects aufzurufen, welche vom Framework unterstützt werden, beziehungsweise weißt es auf fehlende Berechtigungen hin und beschreibt eventuelle Fehler genauer bei der Plugin-Entwicklung. Sollten also in einem Provider CimObjects oder WimObjects benötigt werden, dann sollten diese mittels Get-IcingaWindowsInformation aufgerufen werden.

Selbiges wie bei den Tools gilt natürlich auch hier. Wenn Kommandos mit logischen Strukturen für das icinga-powershell-framework verbessert werden können, zum Beispiel in Form eines Wrappers, dann sind Vorschläge stets erwünscht.

Management

Hier ein kleiner Einblick in ein bisher noch experimentelles Feature und zwar die Management-Konsole. Die Funktion Invoke-IcingaCommand oder gemeinhin eher icinga, sollte bekannt sein, aber nichts desto trotz hier noch einmal. Der icinga Befehl ist grundsätzlich dafür da um Framework-Befehle in einer neuen PowerShell-Instanz auszuführen, was das Testen von neuen Plugins schnell und angenehm gestaltet.

Als Beispiel kann somit direkt durch geschweifte Klammern ein Skriptblock übergeben werden:
PS> icinga { Get-IcingaCPUs }               
Name             Value                      
----             -----                      
0                {specs, errors, metadata}  

Alternativ kann ohne Parameter, beziehungsweise Klammern, eine Icinga-Konsole aufgerufen werden, die wie beim gebrauch von Use-Icinga die Framework-Funktionalitäten lädt:
PS> icinga                                  
********************************************
**       Icinga for Windows v1.5.0        **
**  Copyright (c) 2021 Icinga GmbH | MIT  **
**       User environment Test\Test       **
********************************************
icinga> Get-IcingaCPUs                      
Name             Value                      
----             -----                      
0                {specs, errors, metadata} 

Jetzt aber zur Management-Konsole, die wird aufgerufen durch das Benutzen von icinga -Manage. Es ist notwendig den Befehl auf einer Administrator-Shell auszuführen, ansonsten stehen nicht alle Funktionalitäten zur Verfügung. Durch das Ausführen des Befehls landet man in einem Interaktiven Menü, mit den folgenden Punkten und Aktionsmöglichkeiten:
[0] Installation                       
[1] Update environment                 
[2] Manage environment                 
[3] Remove components                  
[x] Exit [c] Continue [h] Help [m] Main
Input (Default 0 and c):               

Abhängig von der Installation der Umgebung sind Punkte abgeschaltet und aus gegraut. Die Hilfe gibt zu jeden einzelnen Punkt und Schritt in den jeweiligen Untermenüs Informationen. Dadurch dass die vielen Untermenüs und Schritte zahlreich sind, sollte sich das jeder selbst genauer anschauen, beispielsweise ähnelt der erste Punkt, der der Installation sehr dem Interaktiven-Menü des Kickstarts-Skripts. Während die anderen Punkte, wie Update, und Manage environment es einen Nutzer erlauben auch mit geringen Kenntnisstand über Framework-Funktionen, die Funktionalitäten auszukosten. Wer also kein Freund von Befehlen wie Invoke-IcingaFrameworkUpdate oder Install-IcingaFrameworkComponent ist, kann die Sache hiermit unter einem Hut einfach zusammenfassen. Genau das Gleiche gilt auch für Befehle wie Uninstall-IcingaFrameworkComponent mit Punkt 3.

Wir würden uns wirklich sehr darüber freuen, wenn ihr das experimentelle Feature ausprobieren könntet und uns dazu Feedback zu kommen lassen würdet.

Icinga PowerShell Management Console

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Kommende Icinga Web-Funktion: Rememberme

Wir freuen uns immer über Feedback von euch, um Icinga noch besser zu machen. Viele Icinga-Benutzer haben die Meinung geäußert, dass sie gerne eine Rememberme-Checkbox auf der Login-Seite von Icinga Web hätten, damit sie sich nicht jedes Mal anmelden müssen, wenn sie Icinga Web besuchen.
Wir haben an diesem neuen Feature speziell während des Home-Office gearbeitet und planen, es in der nächsten Version von Icinga Web zu veröffentlichen.

Hier sind einige Schritte, wie dies funktioniert:

  • Wir führen ein neues „remember me” Cookie und ein „Stay logged in” checkbox auf der Login Seite ein.
  • Alle sensiblen Benutzerinformationen werden mit einem RSA-Schlüsselpaar verschlüsselt.
  • Das Cookie läuft nach 30 Tagen ab.
  • Die Erneuerung erfolgt automatisch nach einer erfolgreichen „remember me” Authentifizierung und beinhaltet die Neuerstellung des RSA-Schlüsselpaares und des Cookies mit 30 Tagen Ablaufdatum.
  • Die Authentifizierung über das „remember me” Cookie löst unseren normalen Authentifizierungsprozess aus, d. h. die Anmeldung mit dem Benutzernamen und dem Kennwort und die Erstellung eines neuen Sitzungs-Cookies bei erfolgreicher Authentifizierung.
  • Das Cookie wird gelöscht, wenn die Authentifizierung fehlschlägt oder ein Logout ausgelöst wird.

Um die Geheimnisse des Benutzers sicher zu speichern, erzeugen wir auf der Serverseite ein RSA-Schlüsselpaar bei der Erstellung des „remember me” Cookies. Das Schlüsselpaar wird in unserer Web-Datenbank gespeichert. Der Inhalt des Cookies sieht wie folgt aus:

  • Öffentlicher Schlüssel
  • Benutzername und Kennwort, verschlüsselt mit dem öffentlichen Schlüssel

Damit ist der öffentliche Schlüssel unser gemeinsames Geheimnis. Bei der Authentifizierung über das „remember me” Cookie suchen wir den öffentlichen Schlüssel in unserer Datenbank, entschlüsseln die Geheimnisse mit dem privaten Schlüssel und lösen unsere normale Authentifizierung mit dem entschlüsselten Benutzernamen und Passwort aus.

Warum lösen wir die normale Authentifizierung aus?

Die normale Authentifizierung beinhaltet bereits die Überprüfung der Kombination aus Benutzernamen und Passwort. Auf diese Weise prüfen wir, ob der Benutzer existiert oder das Passwort geändert wurde.
Wenn das Cookie bereits existiert und der Benutzer die Seite besucht, entschlüsseln wir die Benutzergeheimnisse und versuchen, uns damit anzumelden. Das funktioniert genauso, als ob der Benutzer diese Informationen manuell eingegeben und auf Login geklickt hätte.

Du kannst die Entwicklung dieser Funktion auf Github verfolgen. Wenn Du einen anderen Vorschlag oder einen neuen Feature Vorschlag hast, den Du gerne sehen würdest, kannst Du gerne ein Issue auf Issue auf Github öffnen.

 

Sukhwinder Dhillon
Sukhwinder Dhillon
Developer

Sukhwinder hat 2021 seine Ausbildung als Fachinformatiker für Anwendungsentwicklung bei NETWAYS erfolgreich abgeschlossen. In seiner Freizeit fährt er gerne Fahrrad, trifft sich mit Freunden, geht Joggen oder sitzt vorm Computer und lernt etwas Neues.

Flexbox in der Praxis: ein paar einfach Beispiele

Inzwischen wird das Flexible Box Layout (kurz FlexBox) ja soweit von Browsern unterstützt, dass es in vielen Fällen auch ruhigen Gewissens für die Produktion verwendet werden kann.
Größtenteils vereint FlexBox viele Layout-Funktionen unter einem Featureset. In erster Linie macht es bestimmte Layout-Funktionen leichter und direkter zugänglich, ohne das Markup verändern zu müssen. Dadurch lassen sich nun relativ elegant und mit wenigen CSS-Angaben viele Layout-Probleme lösen, die man eigentlich schon lange für selbstverständlich hielt.
mehr lesen…

Florian Strohmaier
Florian Strohmaier
Senior UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Selbstentwickelte Anwendungen überwachen

Die Basis

Bei selbstentwickelten Anwendungen stellt sich häufig die Frage wie sich diese im Monitoringsystem überwachen lassen.
Häufig läuft es dann darauf hinaus das einzelne Komponenten der Anwendung überwacht werden. Der Webserver, die Datenbank, eventuell der Applicationserver oder die Messagequeue die von der Anwendung benötigt wird. Das alles ist ein Solides Grundgerüst auf dem sich aufbauen lässt.

Die Anwendung verrät Ihren Status

In einer agilen (Web-)Plattform ist es aber hilfreich wenn die Anwendung etwas über ihren Status verrät. Welches Softwarelease ist ausgerollt und passt die Version des Datenbank Schemas zu dieser Version? Erreicht der Server seine Failover Systeme und sind diese OK?
Die Software kann aber noch mehr über sich verraten. Wie ist der Gesamtstatus der Software? Dieser ist nur OK wenn alle einzelnen Prüfungen OK sind.
Wünschen sich Entwickler oder Admins bestimmte Infos auf einer Infoseite oder einer API, lassen sich diese häufig recht einfach implementieren.
Hier das Beispiel einer möglichen API Ausgabe:

{
  "health": {
    "status": "OK"
  },
  "checks": [
    {
      "version": "1.0.1"
    },
    {
      "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
    },
    {
      "nodeid": "node2"
    }
  ],
  "cluster": [
    {
      "node1": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    },
    {
      "node2": [
        {
          "status": "MAINTENANCE"
        },
        {
          "version": "1.0.1"
        },
        {
          "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
        }
      ]
    },
    {
      "node3": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    }
  ]
}

Die Informationen im Monitoring nutzen

Im Monitoring lassen sich einzelne Werte zum Beispiel mit check_http auswerten, indem man auf den zu erwartenden String prüft. Mit check_multi lassen sich diese Infos dann mit anderen Checks verknüpfen. Die Kollegen in der Rufbereitschaft freuen sich über weitere Anhaltspunkte, wo das Problem zu suchen ist.

Hilfe bei der Automatisierung

Diese Infos sind zum Beispiel bei Continuous Delivery Szenarien enorm hilfreich. Das CI System kann prüfen ob der Rollout der ersten Knotens erfolgreich war und diesen dann z.B. über einen API Call wieder als Live markieren, das Monitoring System beendet die Downtime und der Loadbalancer nimmt den Knoten wieder in die Verteilung.