Im siebten Teil meiner losen Reihe über die RHEL System Roles stelle ich die Rolle rhc vor, mit welcher sich RHEL-Systeme (Version >= 8.6) in der Hybrid Cloud Console, Insights und dem RHSM registrieren lassen.
Möchte man ein oder mehrere RHEL-Systeme in der Hybrid Cloud Console registrieren, kann man dazu die RHEL System Role rhc verwenden.
Die Rolle
Durch die Installation des Pakets rhel-system-roles existiert die Rolle rhc bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.rhc/ und die Dokumentation in /usr/share/doc/rhel-system-roles/rhc/README.md.
Das Playbook
- name: Register systems
hosts: all
vars:
rhc_auth:
activation_keys:
keys: ["key-1", ...]
rhc_organization: "your-organization"
roles:
- rhel-system-roles.rhc
key-1 ist durch den eigenen Activation Key zu ersetzen
your-organization ist durch die eigene Org-ID zu ersetzen
Mit diesem Playbook werden die Hosts im RHSM und der Hybrid Cloud Console registriert
Die Systeme werden bei Insights registriert und laden regelmäßig aktuelle Daten hoch
Die Systeme werden für die Ausführung von Remediation Playbooks konfiguriert
Fazit
Mit dieser System Role ist es einfach möglich, eine große Anzahl Systeme in die Hybrid Cloud Console aufzunehmen. Dabei lässt sich konfigurieren, ob Funktionen wie Insights und Remediation Playbooks genutzt werden können.
Eine weitere tolle Rolle aus dem Paket rhel-system-roles, die sich einfach zur Anwendung bringen lässt.
Im folgenden Text gebe ich eine Einführung in Red Hat Remote Host Configuration (rhc). Dabei handelt es sich um ein Werkzeug, um Red Hat Enterprise Linux (RHEL) System mit der Hybrid Cloud Console zu verbinden und aus dieser heraus verwalten zu können.
Der Artikel soll interessierten RHEL-Nutzern zur Information und Wissensvermittlung dienen. Dazu wird rhc auch im Kontext subscription-manager und insights-client eingeordnet.
Aus Gründen der Transparenz weise ich hiermit darauf hin, dass ich Angestellter der Firma Red Hat bin.
Hintergrund
Als ich persönlich angefangen habe, mich für RHEL zu interessieren, war die Version 7 aktuell und von Simple Content Access (SCA) noch keine Rede. Um RHEL-Systeme betreiben zu können, waren diese beim Red Hat Subscription Management (RHSM), einem Satellite-Server oder offline zu registrieren, um Subscription Entitlements zuweisen zu können. Hierfür gab und gibt es das Kommando subscription-manager.
Im Laufe der Zeit kam der Dienst Red Hat Insights hinzu, zu welchem es hier im Blog bereits eine Einführung gab. Um Systeme hierfür zu registrieren, gibt es das Kommando insights-client. Die Console, die einst nur Red Hat Insights beheimatete, hat sich zur Hybrid Cloud Console entwickelt, welche heute Heimat für viele weitere Dienste rund um RHEL, OpenShift und die Ansible Automation Platform (AAP) ist.
Es hat sich viel getan. Dank SCA [1] entfällt die Notwendigkeit, Entitlements zuweisen zu müssen und das Subscription Management befindet sich im Übergang zur Hybrid Cloud Console. Übergang bedeutet hier insbesondere, dass viele Teile in Bewegung sind und sich in Zukunft noch ändern werden. Der Artikel unter [6] gibt einen Überblick dazu.
Hybrid Cloud Console mit Insights und Ansible Remediation Playbooks
Die folgenden vier Absätze wurden der Dokumentation entnommen und mit www.DeepL.com/Translator (kostenlose Version) übersetzt.
Die Red Hat Hybrid Cloud Console ist eine webbasierte, einheitliche Verwaltungsoberfläche für Red Hat-Lösungen. Mit der Hybrid Cloud Console können Sie eine Verbindung zu Ihren verschiedenen Plattformen herstellen und dann Ihre Hybrid Cloud und die darin enthaltenen Systeme zentral verwalten und automatisieren.
Verwenden Sie die Hybrid Cloud Console, um Ihre RHEL-Infrastruktur, Red Hat OpenShift-Cluster, AAP-Infrastruktur und Anwendungsdienste zu verwalten.
Die Red Hat Hybrid Cloud Console bietet einen zentralen Einblick in Betrieb, Sicherheit und Subscriptions für Red Hat Enterprise Linux (RHEL).
Mithilfe von Tools, regelbasierten Analysemodellen und der Unterstützung von Red Hat können Sie die Konsole nutzen, um viele der Aufgaben und Analysen zu optimieren, die für den Aufbau und die Bereitstellung einer stabilen und sicheren Umgebung für Anwendungen auf RHEL erforderlich sind.
Dem Marketing-Text der vorstehenden Absätze möchte ich einen Hinweis hinterherschicken. Mit der Hybrid Cloud Console verhält es sich wie mit allen extern gehosteten Cloud-Diensten. Hat der Anbieter ein Problem oder ist die Cloud bzw. das Internet nicht verfügbar, ist auch der Cloud-Dienst nicht verfügbar. Bei der Fähigkeit, meine Infrastruktur zu administrieren, möchte ich mich persönlich daher nicht allein auf einen externen Dienst verlassen und empfehle dies auch niemanden. In meinen Augen ist die Hybrid Cloud Console ein zusätzliches Werkzeug, welches mit Red Hat Insights einen hohen Mehrwert bietet.
In den nun folgenden Abschnitten beschreibe ich, wie in der Hybrid Cloud Console ein Activation Key erstellt wird und wie man diesen nutzt, um Systeme mittels rhc in der Console zu registrieren. Anschließend zeige ich, wie dank rhcAnsible Remediation Playbooks direkt aus der Console heraus auf verbundenen RHEL-Systemen ausgeführt werden können.
Ob man einem extern durch Dritte gehosteten Dienst das Recht einräumen möchte, Änderungen an den eigenen Server-Systemen durchführen zu können, muss jeder für sich selbst und seine Umgebung bewerten. Ich möchte hier lediglich die Funktionalität in meiner Lab-Umgebung demonstrieren.
Activation Key erstellen
Um einen Activation Key zu erstellen [10], meldet man sich an der Hybrid Cloud Console (https://console.redhat.com) an und tippt in das Suchfeld im oberen Bereich „create activation key“ ein.
Ausgefüllte Suchmaske in der Hybrid Cloud Console
Der erste Treffer führt uns zu folgender Maske, in der ein Activation Key erstellt werden kann:
Menü zur Erstellung von Activation KeysDialog zur Erstellung des Activation Keys
Nach einem Klick auf die Schaltfläche Create activation key erscheint der oben dargestellte Dialog. Die Optionen, die unter Role, Service Level Agreement (SLA) und Usage zur Auswahl stehen, hängen von den im Account vorhandenen Subscriptions ab. Mit ihnen wird der sogenannte System Purpose bestimmt. Der Name kann frei gewählt werden. Er erscheint anschließend in der Übersicht.
Übersicht der existierenden Activation Keys
Hinweis: Die Organization ID und der Name des Activation Key sind vertraulich zu behandeln, da mit diesen Informationen Systeme für die Hybrid Cloud Console registriert werden können.
System mit rhc registrieren
Mit dem Befehl rhc -h erhält man eine Beschreibung, wie Organization ID und Activation Key genutzt werden, um das System bei Red Hat zu registrieren:
DESCRIPTION:
The rhc command controls the system's connection to Red Hat.
To connect the system using an activation key:
rhc connect --organization ID --activation-key KEY
Führt man den Befehl wie angegeben aus und ist die Registrierung erfolgreich, erhält man folgende Ausgabe:
Connecting host.example.com to Red Hat.
This might take a few seconds.
● Connected to Red Hat Subscription Management
● Connected to Red Hat Insights
● Activated the Remote Host Configuration daemon
● Enabled console.redhat.com services: remote configuration, insights, remediations, compliance
Successfully connected to Red Hat!
Manage your connected systems: https://red.ht/connector
Unter der URL https://red.ht/connector ist der Remote Host Configuration Manager erreichbar. Hier werden die aktuellen Einstellungen angezeigt und können bei Bedarf geändert werden.
Darstellung der Seite Remote Host Configuration Manager
Der rhc Client konfiguriert auf dem RHEL host den rhcd service, welcher die Verbindung zur Hybrid Cloud Console initiiert und über eine MQTT-Verbindung auf Instruktionen lauscht [14].
Möchte man mehrere Systeme registrieren, empfehle ich die Verwendung der RHEL System Role rhc. Auf diese werde ich in einem folgenden Beitrag noch genauer eingehen.
Die Registrierung und Einbindung in die Hybrid Cloud Console ist damit abgeschlossen.
Ansible Remediation Playbook erstellen und ausführen
Die offizielle Dokumentation für die folgenden Schritte befindet sich unter [12]. Ich habe ein System gewählt, welches noch nicht aktualisiert wurde und daher einige Schwachstellen aufweist.
Übersicht der vorhandenen CVE. Zwei Einträge wurden für die Remediation mit Ansible ausgewählt.
In der Übersicht können CVE ausgewählt werden, welche mit Hilfe eines Ansible Remediation Playbook geschlossen werden sollen. Mit einem Klick auf die Schaltfläche Remediate gelangt man in den Assistenten zur Erstellung des Playbooks.
Der Name des Playbooks kann frei gewählt werden.In Schritt zwei können verwundbare Systeme ausgewählt werden.Review der Einstellungen mit dem Hinweis, dass das Zielsystem durch das Playbook automatisch neugestartet wird.Bis hierher wurde nur ein Playbook erstellt. Es wurde noch keine Remediation durchgeführt.
Die erstellten Playbooks findet man im Menü unter Red Hat Insights –> Automation Toolkit –> Remediations. Bisher kann das Playbook hier allerdings nur heruntergeladen werden, um es auf einem Ansible Controller in der eigenen Infrastruktur auszuführen. Um diese Playbooks direkt aus der Hybrid Cloud Console heraus ausführen zu können, muss der verwendete User Mitglied einer Gruppe mit der Rolle Remediations administrator sein.
Ein Exkurs in die Rollen- und Rechteverwaltung der Hybrid Cloud Console würde an dieser Stelle zu weit führen. Nachdem die Voraussetzungen für die Ausführung von Remediation Playbooks geschafften wurden, stehen folgende Schritte zur Verfügung.
In der Ansicht des Remediation Jobs kann das Playbook nun direkt ausgeführt werden.
Eine letzte Bestätigung, dann geht es los.
Im Hintergrund passiert nun folgendes:
Das Playbook wird auf den oder die Hosts übertragen
Auf den Hosts wird es durch die dort lokal installierte Ansible Engine (Paket ansible-core) ausgeführt
Der Host wird anschließend automatisch neugestartet
In der Console wird anschließend sichbar, dass die Remediation abgeschlossen wurde
Ob man einem SaaS-Dienst, der von einem US-Unternehmen in den USA gehostet wird, Zugriff auf die eigenen Server gewähren möchte bzw. darf, muss individuell bewertet werden.
Ich gestehe dem Service allerdings zu, dass er die Verwaltung und Remediation von Sicherheitslücken, fehlenden Advisories und Konfigurationsanpassungen durch den Advisor denkbar einfach gestaltet.
Ein Werkzeug für alles?
Für die in diesem Text aufgeführten Anwendungsfälle
Registrieren eines RHEL-Hosts an der Hybrid Cloud Console
Ausführen von Ansible Remediation Playbooks
ist die Verwendung des rhc-Clients ausreichend; ein Ersatz für den insights-client ist er allerdings nicht. Letzterer wird im Hintergrund weiterhin verwendet, um Insights-Reports an die Hybrid Cloud Console zu senden.
Auch die vielfältigen Optionen des subscription-manager werden nicht abgebildet. Der rhc-Client ist daher mehr eine Ergänzung als ein Ersatz für die bekannten Kommandos.
Fazit
Der rhc-Client ist in meinen Augen das Mittel der Wahl, möchte man RHEL-Systeme für die Verwaltung durch Insights und die Ausführung von Ansible Remediation Playbooks an die Hybrid Cloud Console anbinden.
Ich hoffe euch interessierten Lesern, die bishierhin ausgehalten haben, hat diese Einführung gefallen. In der folgenden Liste findet ihr einige Links, hinter denen ihr euer Wissen noch vertiefen könnt.
Es waren einmal Alice und Bob. Diese lebten in unterschiedlichen Ländern auf unterschiedlichen Kontinenten unserer schönen Erde. Beide wollten sich zu einer Videokonferenz verabreden, am Samstag, dem 1.4.2023 um 11:00 Uhr (IST). Wobei (IST) die Abkürzung für die verwendete Zeitzone ist (siehe [2]).
Leider verharrten Alice und Bob jeweils allein im Videokonferenzraum und fanden nicht zueinander. Denn während Alice (IST) als Irish Standard Time (UTC+01) interpretierte, richtete sich Bob nach (IST) wie in Indian Standard Time (UTC+05:30). Schade, so haben sich die zwei um 4,5 Stunden verpasst.
Das Problem
Die Angabe der Zeitzone erfolgt überwiegend als Drei-Buchstaben-Akronym. Ungünstigerweise sind diese Akronyme häufig nicht eindeutig.
So findet das Akronym IST z.B. für folgende Zeitzonen Verwendung:
Indian Standard Time (UTC+05:30)
Irish Standard Time (UTC+01)
Israel Standard Time (UTC+02)
Und es lassen sich weitere schöne Beispiele finden. Hier nur eine kleine Auswahl:
AMT für:
Amazon Time (Brazil) (UTC-04)
Armenia Time (UTC+04)
AST für:
Arabia Standard Time (UTC+03)
Atlantic Standard Time (UTC-04)
CST für:
Central Standard Time (UTC-06)
China Standard Time (UTC+08)
Cuba Standard Time (UTC-05)
Hach, was habe ich es gut. Ich lebe im Winter in den Zeitzonen CET und MET. Bzw. im Sommer dementsprechend in CEST und MEST. Da ist es dann auch genauso spät
wie in IST. Ach Moment, welches IST ist das denn jetzt schon wieder?
Von der zusätzlichen Komplexität, welche durch die Zeitumstellung zum Winter bzw. Sommer entsteht, möchte ich gar nicht erst anfangen.
Doch verzagt nicht, es besteht Hoffnung, dass Alice und Bob doch noch zueinander finden.
Die koordinierte Weltzeit (UTC)
Wie bei allen anderen Zeitzonen auch wird bei der UTC [1] die Welt in Zonen eingeteilt. Der Vorteil in der Verwendung besteht darin, dass Alice und Bob sich nicht mehr darum kümmern müssen, in welcher Zeitzone der jeweils andere lebt und wie viel Uhr 10:00 (EDT) wohl in IST oder GMT+8 sein mag. Sie müssen sich nur merken, wie viele Stunden sie selbst der UTC-Zeit voraus bzw. hinterher sind.
Beispiel: Meine lokale Zeit entspricht im Winter der Zone UTC+01 und im Sommer, wenn wir die Uhr eine Stunde vorstellen, der Zone UTC+02. Das kann ich mir einfach merken. Wenn sich jemand mit mir um 15:00 (UTC) treffen möchte, weiß ich abhängig von der Jahreszeit, dass ich entweder um 16:00 Uhr oder um 17:00 Uhr meiner lokalen Zeit am vereinbarten Treffpunkt sein muss.
Möchte ich mich selbst verabreden und meinem Besuch ersparen, meine Zeitzone zu raten oder die Zeit umrechnen zu müssen, rechne ich meine lokale Zeit einfach in UTC um. So entspricht in diesem Monat 15:00 Uhr (UTC+02) ganz einfach 13:00 Uhr (UTC). Lebt mein Besuch in UTC-03, so kann er leicht bestimmen, dass ich ihn um 10:00 Uhr seiner lokalen Zeit erwarte.
Das Happy End
Alice und Bob haben sich darauf geeinigt, zukünftig die koordinierte Weltzeit zu verwenden. Alice lebt in Irland und möchte sich mit Bob verabreden, wenn es bei ihr 10:00 Uhr ist. Die Zeitzone von Alice entspricht UTC+01. Sie verabredet sich mit Bob um 09:00 Uhr (UTC).
Bob weiß, dass er 5,5 Stunden zur UTC-Zeit hinzuaddieren muss, um seine lokale Zeit zu bestimmen. Er wählt sich also um 14:30 Uhr (UTC+05:30) in die Videokonferenz ein.
Und wenn sie nicht gestorben sind, so zoomen sie noch heute.
Zusammenfassung
Ich hoffe, diese kleine Geschichte hat euch ein wenig unterhalten und die Vorteile, die sich aus der Verwendung der koordinierten Weltzeit ergeben, deutlich gemacht.
In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.
Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.
Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.
Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.
Voraussetzungen
Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.
Das Playbook
Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.
Um zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.
Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.
Zusammenfassung
Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.
Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.
Diese Frage habe ich mir selbst schon mehrmals gestellt. Und mindestens genauso oft wurde sie mir schon von anderen gestellt. Als Antwort kommen hier meist zuerst telnet oder netcat (nc) in den Sinn. Doch in einer RHEL-Minimal-Installation sind diese beiden Programme nicht enthalten und müssen erst nachinstalliert werden. Was tut man in diesem Fall (ohne den Paketmanager zu starten)?
Ich möchte in diesem Artikel mehrere Antworten auf die Eingangsfrage festhalten. Dabei beginne ich mit denen, die ich auf stackoverflow gefunden habe.
Bash und timeout
Von RHEL 6 aufwärts sollte das Programm timeout in der Minimal-Installation enthalten sein. In Fedora 35 und Debian 11 ist es ebenfalls enthalten. Es stammt aus dem Paket coreutils, in dem es meines Wissens spätestens seit Version 8.22 enthalten ist.
Mit timeout und nc habe ich meine beiden Favoriten festgehalten. Mit beiden lässt sich die Erreichbarkeit von entfernten TCP-Ports testen (die von lokalen TCP-Ports übrigens auch).
Falls ihr noch weitere Möglichkeiten kennt, mit Bordmitteln, die in der Minimal-Installation einer Distribution enthalten sind, um einen Verbindungstest durchzuführen, schreibt sie mir gern in die Kommentare. Ich nehme sie dann gern mit in den Artikel auf.
Anmelden
