In der Einführung in Red Hat Insights habe ich kurz umrissen, worum es sich bei dieser SaaS-Anwendung handelt und wie man RHEL-Systeme einrichtet, um den Dienst nutzen zu können. Dieser Artikel widmet sich dem Menüpunkt „Advisor“ im Insights-Dashboard.
Das Insights-Dashboard ist erreichbar unter der URL: https://cloud.redhat.com/insights/dashboard
Das Dashboard gibt einen Überblick darüber, wie viele Systeme aktuell in Insights eingebunden sind, ob es Probleme mit bekannten Systemen gibt, den Patch-Status, Schwachstellen, Compliance-Status, durchgeführte Remediations und Advisor recommendations. Letztere sind Gegenstand dieses Artikels und werden im Folgenden einer genauen Betrachtung unterzogen.
Advisor recommendations bedeutet auf Deutsch soviel wie „Empfehlungen eines Ratgebers“. Der Ratgeber (Advisor) ist in diesem Fall die Firma Red Hat, welche mit Machine Learning Algorithmen, ihrer Erfahrung und dem aus Kunden-Support-Fällen gesammelten Wissen, Ratschläge zur Systemkonfiguration und Hinweise auf Konfigurationsfehler unterbreitet.
Das Dashboard in Bild 1 zeigt, dass Insights für die 13 verbundenen Systeme insgesamt 5 Empfehlungen bereithält, mit denen die Systemkonfiguration verbessert werden kann.
Über das Menü am linken Rand oder den Link im Feld der Advisor recommendations gelangt man auf die Unterseite des Ratgebers, welcher die Empfehlungen in einer Übersicht mit Bewertung darstellt (siehe Bild 2).
Die tabellarische Übersicht in Bild 2 zeigt die Empfehlungen mit einer kurzen Beschreibung, seit wann diese Empfehlung im Insights existiert, eine Risikobewertung, wie viele Systeme davon betroffen sind und ob ein Ansible-Playbook existiert, mit dem das beschriebene Problem in der eigenen Infrastruktur behoben werden kann.
Auf die einzelnen Funktionen der Seite aus Bild 2 werde ich im Folgenden näher eingehen, während ich eine Bewertung der angezeigten Empfehlungen vornehme.
Als erstes sticht mir der zweite Punkt ins Auge. Mit einem Klick auf den Pfeil vor der Beschreibung werden weitere Details eingeblendet (siehe Bild 3). Hier erfährt man, dass es vermutlich kein Problem darstellt, wenn man zum jetzigen Zeitpunkt kein In-Place-Upgrade auf RHEL 8 durchführt und dass ein Upgrade vermutlich ein Wartungsfenster mit Downtime benötigt. Weitere Informationen bietet der verlinkte Knowledge-Base-Artikel.
Ich persönlich bewerte die in Bild 3 ausgewählte Empfehlung als unnütz. RHEL 7 ist immer noch ein Release unter Wartung, welches Sicherheits-Aktualisierungen erhält. Dass RHEL 8 inzwischen in Version 8.2 erschienen ist und mit neuen Funktionen und Verbesserungen aufwartet, ist bekannt, aber kein Grund für übereilte Upgrades. Darüber hinaus führen wir im BITS in der Regel keine In-Place-Upgrades durch. Stattdessen installieren wir eine neue virtuelle Maschine (VM), migrieren Daten und Dienste und schalten anschließend den alten Host ab.
Zum Glück muss man sich von unbedeutenden Meldungen nicht ewig nerven lassen. Wie in Bild 3 zu sehen, bietet Insights die Möglichkeit, Meldungen einfach zu deaktivieren. Sehr schön empfinde ich dabei, dass man einen Grund angeben kann (siehe Bild 4). So wird man auch nach Wochen oder gar Monaten daran erinnert, warum man einen Eintrag deaktiviert hat.
Anschließend wird der Eintrag in der Übersicht nicht mehr angezeigt (vgl. Bild 5).
Nach dem Deaktivieren eines Eintrags kam mir sofort die Frage in den Sinn, wo ich diese denn wohl wiederfinden kann. Dies ist über die Filtereinstellungen im oberen Bereich der Seite möglich (siehe Bild 6).
An dieser Stelle möchte ich erwähnen, dass das Insights-Team die entsprechende Empfehlung nach meiner Rückmeldung komplett aus Insights entfernt hat. Schön, dass man als Kunde hier Gehör findet.
Bewertung der weiteren Empfehlungen
Es bleiben noch vier weitere Empfehlungen, die ich im Folgenden für meine konkrete Umgebung bewerten will. Alle vier haben gemein, dass ich vermutlich nie bewusst nach diesen Konfigurationseinstellungen gesucht hätte. Und zumindest zwei sind dabei, bei denen ein genauerer Blick lohnt. Und mit diesen fange ich an.
OS boot failure occurs due to uncertain disk discovery order when /dev/sdN format device names are used in /etc/fstab
Hier wird auf eine Konfiguration hingewiesen, die im ungünstigsten Fall den Bootvorgang eines Hosts verhindert. Eine Einstufung als „Important“ ist daher nachvollziehbar. Lässt ein System, das nicht startet, doch regelmäßig den Puls und Adrenalinspiegel eines Sysadmin steigen.
Um mir das (mögliche) Problem näher erläutern zu lassen, rufe ich aus der Detailansicht den dort verlinkten Knowledge-Base-Artikel auf. Dabei fällt mir auf, dass, obwohl ich ausschließlich RHEL 7 Systeme verwende, auf einen Artikel verlinkt wird, der nur für RHEL 6 gilt. Immerhin findet sich in diesem eine Referenz zum entsprechenden Artikel für RHEL 7. Hier hätte man gleich passend verlinken können.
- How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 6?
- How are persistent names assigned for SCSI devices using udev in Red Hat Enterprise Linux 7?
Wie ist dieser Eintrag nun für uns zu bewerten?
Die beiden betroffenen Systeme sind schon einige Zeit in Betrieb und haben bereits mehrere Neustarts ohne Probleme überstanden. Das potenzielle Problem scheint sich zumindest in unserer Umgebung nicht negativ auszuwirken.
Insights bietet für diesen Fall die Erstellung eines Ansible-Remediation-Playbooks an, mit welchem das Konfigurationsproblem behoben werden kann. Da ich in diesem Fall nicht der System-Betreiber für die beiden aufgeführten Systeme bin, kann ich dies jedoch nicht ohne Rücksprache mit dem entsprechenden Kollegen zur Ausführung bringen.
Ich habe den entsprechenden System-Betreiber über dieses Ereignis benachrichtigt, ihm die mögliche Lösung weitergeleitet und ihm die Entscheidung überlassen, wie er weiter damit verfahren möchte. Dieser hat sich für den Hinweis bedankt und das Problem sofort behoben.
In einem späteren Artikel werde ich mich noch damit beschäftigen, wie ich Kollegen Zugriff auf das Insights-Dashboard gewähren kann, so dass diese ihre Systeme darin selbst verwalten und untersuchen können.
Traffic occurs or services are allowed unexpectedly when firewall zone drifting is enabled
Dies ist aus meiner Sicht wirklich ein interessanter Fund. Denn er weist darauf hin, dass womöglich Kommunikation durch die lokale Host-Firewall erlaubt wird, obwohl dies nicht beabsichtigt ist (vgl. Bild 7).
Auch hier liefert der verlinkte Knowledge-Base-Artikel ausführliche Informationen.
Ich werde diesen Punkt auf jeden Fall mit dem betroffenen Kollegen thematisieren. Ich denke, dass hier ein kleiner Wissenstransfer angebracht ist, da nach meiner Einschätzung auch weitere Kollegen sich des konkreten Verhaltens nicht bewusst sind. Von daher bewerte ich diesen Ratschlag als gut und sinnvoll.
Ein Punkt übrigens, der mir am Insights-Dashboard allgemein gut gefällt, ist, dass ich jederzeit anzeigen lassen kann, wie viele Systeme betroffen sind und noch wichtiger, welche dies sind (siehe Bild 8).
Decreased security: httpd serving unencrypted (HTTP) traffic
Dies ist eine Meldung mit niedriger Risiko-Einstufung und so werden wir sie auch behandeln. Bei den betroffenen Systemen handelt es sich um Test-Systeme. Der System-Betreiber hat hier bewusst auf die Implementierung von TLS/SSL verzichtet.
Decreased security: Yum GPG verification disabled (third-party repos)
Dieser Punkt stellt sich wider Erwarten als interessant heraus. Wir betreiben eigene Repositories, welche nur innerhalb unserer Einrichtung verwendet werden. Um den Aufwand zu minimieren, verzichten wir bei diesen auf die Signierung der Pakete.
Überraschend ist jedoch der Umstand, dass bei einigen Hosts auch die GPG-Signatur-Überprüfung für ein gespiegeltes RHEL-Repo deaktiviert ist. Um dies herauszufinden, muss man sich nicht erst zu einem betroffenen System verbinden und dies untersuchen. Es genügt ein Klick auf den Hostnamen in der Liste der betroffenen Systeme (vgl. Bild 8), um zu einer Ansicht zu gelangen, die neben einer ausführlichen Beschreibung auch einen Lösungsweg anbietet.
Insights bietet nicht nur Unterstützung dabei herauszufinden, was falsch ist, sondern auch wie man das Problem abstellt. Ich werde im Laufe des Tests fortlaufend überprüfen, wie häufig Insights hier mit sinnvollen Lösungen aufwarten kann.
Slow system boot when storage devices do not support WRITE SAME command
Neu hinzugekommen und daher in obigen Bildern noch nicht enthalten ist dieser Hinweis auf ein Problem, welches die Leistung des Systems beim Bootvorgang reduzieren kann.
Insights hat diesen Incident erkannt, nachdem das betroffene System neugestartet wurde, der insights-client erneut gelaufen ist und Insights eine entsprechende Meldung in /var/log/messages gefunden hat.
Das Problem selbst ist uns seit langem bekannt. Es fällt allerdings in die Kategorie: „Gucken wir uns an, wenn wir mal Zeit haben.“ Also vermutlich nie. Zum Glück booten unsere VMs innerhalb weniger Sekunden und es wird hier kein Problem wahrgenommen.
Zwischenfazit
Ich stehe noch am Anfang unseres Tests. Die bisherigen Erkenntnisse lassen daher noch keine abschließende Bewertung zu, ob ein dauerhafter und ausgedehnter Einsatz von Insights gerechtfertigt ist.
Als erster Eindruck bleibt eine benutzerfreundliche Oberfläche, welche eine intuitive Bedienung gestattet. Der Advisor enthält bis jetzt neben einigen belanglosen Empfehlungen auch interessante Hinweise.