Da Linux in einer WSL2 Umgebung recht autark und abgekapselt dasteht, scheint eine zentrale Administration auf dem ersten Blick nicht direkt möglich zu sein.
In dem nachfolgendem Beitrag möchte ich trotz aller Hürden klären, ob dennoch eine Möglichkeit hierfür besteht.
In einem meiner vorherigen Beiträge zum Thema Ansible, ging ich auf die Installation von Foreman ein, mit der es möglich ist, Ansible grafisch zu verwalten. Als weitere Option, Ansible eine GUI zu spendieren, steht AWX zur Verfügung. AWX ist im Prinzip die Open Source Variante des kostenpflichtigen Ansible-Tower. Wie die Installation und die erste Einrichtung aussieht, verrät der folgende Beitrag.
In meiner bisherigen Reihe zum Thema Ansible, bin ich stets auf die Installation, Konfiguration und Erweiterung auf einem Ubuntu-Server eingegangen. Um nun auch eine Anleitung für CentOS zu bieten, soll dieser Beitrag ein Leitfaden sein. Genauer gesagt, beziehe ich mich auf die CentOS Version 8 Stram (rolling release), sodass eine entsprechende Vorinstallation des Betriebssystems vorausgesetzt ist.
Pop-Up Meldungen auf dem Desktop können gerade in der Administration ein wichtiges Mittel sein, um z.B. den User auf bevorstehende Wartungsarbeiten hinzuweisen. Leider gibt es in Linux (wie so häufig) nicht immer DIE standardisierte Lösung dafür parat. Um eine Möglichkeit (von womöglich vielen aufzuzeigen) aufzuzeigen, soll dieser Beitrag ein Leitfaden sein.
Ansible lässt sich nicht nur in der Kommandozeile administrieren. Wie dies auch über die GUI Foreman funktioniert, behandelt dieser Beitrag.
Immer mal wieder schwirren in IT-Landschaften Versionen von Paketen herum, die so in ihrer abgehangenen Akutalität besser nicht mehr installiert sein sollten. log4j und Polkit sind nur 2 dieser (in Zungenbrechersich) “vulnerabiliy” aus der jüngsten Vergangenheit. Schnell möchten wir nun diese Sicherheitslücken schließen. Doch neben dem eigentlichen Update, müssen wir erstmal herausfinden, welche Systeme überhaupt betroffen sind und welche eine nicht konforme Version installiert haben.
Um letztere Information zu beschaffen, möchte ich in folgendem eine Möglichkeit vorstellen, wie dies über Ansible erledigt werden kann.
Aufbauend auf meinen letzten Ansible Beiträgen möchte ich an dieser Stelle noch eine Möglichkeit ergänzen, wie man sich die sogenannten ‚Facts‘ zunutze machen kann. Wie zuvor erwähnt, verfügen sowohl Ansible als auch Puppet über einen Mechanismus, um Host-spezifische Informationen von seinen Zielsystemen zu sammeln: IP-Adressen, Sofware-Ausstatung, Hardware-Informationen und vieles mehr. Neben den vordefinierten Facts lassen sich auch eigene setzen.
Es folgt der zweite Teil zur Linux Orchestrierung mit Ansible, in dem es sowohl um die Installation einer grafischen Übersicht geht als auch eine Möglichkeit darstellt, sich die Inventarisierung automatisch generieren zu lassen.
In einem früheren Beitrag bin ich auf die Möglichkeit eingegangen, Linux Maschinen von zentraler Stelle aus zu verwalten. Der Beitrag behandelte das Tool Puppet. Wie dort bereits erwähnt, gibt es neben Puppet noch weitere Möglichkeiten. Eine davon ist Ansible, worum es in diesem Beitrag gehen soll.
Im letzten Beitrag haben wir den Boden für unsere Puppet-Infrastruktur mit Server-/ und Client -Installation bereitet. Nun soll der zweite Teil des Artikels eine erste Funktionsanweisung (das sogenannte “Manifest”) samt Inventarisierung der Puppet-Clients behandeln.
