Ergebnisse für " Linux "

End of Life von CentOS Linux 7 – Was bedeutet das für mich?

von Dirk Götz | Mrz 25, 2024 | Linux

Der ein oder andere Admin wird sich vermutlich schon lange den 30. Juni 2024 im Kalender vorgemerkt haben, denn dann ist für CentOS Linux 7 das „End of Life“ erreicht. Aber auch Benutzer von Red Hat Enterprise Linux 7 sollten sich Gedanken machen, denn auch dieses verlässt an dem Tag die „Maintenance Support 2 Phase“ und geht in den „Extended life cycle“ über.

Was bedeutet das nun?

„End of Life“ ist relativ einfach erklärt, ab diesem Termin wird die Unterstützung für das Produkt eingestellt und somit gibt es hier keine Updates mehr. Insbesondere das Fehlen von Sicherheitsupdates spricht dann ganz klar gegen einen Weiterbetrieb.

„Extended life cycle“ ist dagegen etwas komplizierter. Auf der einen Seite stellt auch Red Hat hiermit das Updaten ein, supported bestehende Systeme aber weiter und bietet auch Migrationsunterstützung. Auf der anderen Seite ermöglicht es bei Red Hat hier ein Support-Addon hinzu zu kaufen, welches dann Zugriff auf kritische und schwerwiegende Sicherheitsupdates und ausgewählte Bugfixes sowie andere Supportbedingungen gibt. Wer also aus irgendwelchen Gründen darauf angewiesen ist, kann für einen nicht gerade kleinen Betrag einen sicheren Weiterbetrieb sicherstellen und damit die Migration weiter hinauszögern. Für die meisten Nutzer dürfte es aber gleichbedeutend mit dem „End of Life“ sein.

Was soll ich nun tun?

Der übliche Weg bei Software ist der Weg nach vorne, also ein Upgrade auf die nächste Version des Betriebssystems. Hier wird es allerdings in diesem Fall deutlich komplizierter denn mit der Einstellung von CentOS Linux gibt es den klaren Weg nach vorne nicht mehr, sondern einen echt verzwickte Weggabelung!

Wer weiterhin dem CentOS-Projekt sein Vertrauen schenkt, hat als direkten Nachfolger CentOS Stream 8. Dieses ist aber nicht länger ein Downstream von Red Hat Enterprise Linux und auch nicht mehr den kompletten Support-Lifecycle unterstützt, sondern EoL bereits am Ende des „Full support“ was dem Release der Minorversion 10 und somit 5 Jahren statt 10 entspricht! Damit ist das EoL für CentOS Stream 8 allerdings bereits am 31. Mai 2024, also vor dem von CentOS Linux 7. Somit sollte der Weg schnell beschritten werden und dann direkt weiter zu CentOS Stream 9.

Der ein oder andere sollte auch überlegen ob die eigenen Anforderungen nicht den Wechsel zum Enterprise-Support rechtfertigen. Red Hat supportet den Wechsel hier nicht nur, sondern stellt auch entsprechende Werkzeuge zur Verfügung. Damit lässt sich auch das Upgrade bei Bedarf raus zögern, auch wenn ich nach dem Wechsel eigentlich direkt den Schritt zu RHEL 8 empfehlen würde bzw. man auch hier direkt mit Version 9 überlegen kann.

Eine andere Alternative mit direktem Enterprise-Support aber auch unbegrenzter freier Verfügbarkeit ist Oracle Linux. Hierbei lässt sich quasi das gleiche bezüglich Migration sagen. Aber bei diesem Wechsel empfehle ich sich mit den Besonderheiten von Oracle Linux ausführlich auseinander zu setzen. Ich habe da in der Vergangenheit durchwachsene Erfahrungen gesammelt. Zum einen haben wir Kunden, die mit teils recht großen Umgebungen komplett auf Oracle Linux sehr gut fahren. Zum anderen hatte ich mit zusätzlichen Repositories und dort enthaltener Software teils Probleme, da Oracle teilweise andere Kompiler-Flags setzt und auch EPEL (Extra Packages for Enterprise Linux) nachbaut, aber dies nicht im vollen Umfang.

Dann gibt noch die Forks, die aufgrund der Einstellung von CentOS Linux entstanden sind. Hier müssen für mich alle noch beweisen wie ihnen der veränderte Umgang von Red Hat mit den Quellen gelingt und wie das ganze nach dem EoL von CentOS Stream aussieht. Da sehe ich aktuell bei AlmaLinux, dass das Projekt sehr vieles richtig macht, sowohl technisch als auch in anderen Bereichen. Rocky Linux wirkt hier auch sehr solide. Alle anderen habe ich quasi aus den Augen verloren, da sie weder bei uns im Kundenstamm relevant geworden sind noch mein persönliches Interesse durch etwas geweckt wurde. Das Schöne hier ist, dass sowohl Werkzeuge zur Migration in Version 7, als auch direkt von 7 zu 8 existieren.

Den kompletten Distributionswechsel lasse ich in der Betrachtung mal außen vor, da hier dann deutlich mehr Planung notwendig ist. Auch dieser Aufwand ist zu stemmen, aber dann doch eher keine Lösung für einen Zeitraum von etwa 3 Monaten.

Wie gehe ich nun vor?

Nachdem die Entscheidung für das Ziel gefallen ist, stellt sich als nächste Frage üblicherweise ob man das System überhaupt upgraden oder lieber direkt neu erstellen will. Hier habe ich mich mittlerweile tatsächlich zu einem Befürworter von In-Place-Upgrades entwickelt, was auch an dem Tool Leapp bzw. ELevate liegt. Mit diesem und den Möglichkeiten wie ich es auch in größeren Umgebungen sinnvoll nutze, habe ich mich schon vor einer Weile in meinem Artikel „Leap(p) to Red Hat Enterprise Linux 9“ beschäftigt.

Worauf ich damals nur am Beispiel von Foreman eingegangen bin, sind hier der Umgang mit zusätzlicher Software. Foreman war für den Artikel ein gutes Beispiel, da hier extra Migrationen für Leapp gebaut wurden. Bei anderer Software ist dies nicht der Fall. Also müssen wir hier von zwei Szenarios ausgehen. Zum einen von Software, die aus einem zusätzlichen Repository in Form von Paketen installiert wurde, und zum anderen solcher die manuell installiert wurde. Software in Containern oder ähnlichem können außen vor lassen, da diese unabhängig vom Betriebssystem sind.

Software aus zusätzlichen Repositories sollte mit Leapp/ELevate kein Problem darstellen, solang ein Repository für die neuere Version verfügbar ist. In diesen Fällen muss nur das zusätzliche Repository während des Upgrades verfügbar gemacht werden. Dass es auch hier Stolpersteine gibt ist klar, ein Beispiel wäre hier Icinga wo ab EL8 nur noch Subscription-pflichtige Repositories zur Verfügung stehen. Also auch hier sollte etwas Zeit in Planung und Tests investiert werden bevor es an produktive Systeme geht.

Bei manuell installierter Software ist nach dem Betriebssystem-Upgrade sehr wahrscheinlich einmal neu kompilieren angesagt, damit die Software mit neueren Version der Systembibliotheken läuft. In manchen Fällen wird auch ein Update der Software notwendig sein, wenn die Kompatibilität sonst nicht mehr gegeben ist. Das gilt auch in vielen Fällen für nicht zu kompilierende Software, da sich auch Perl-, Python-, Ruby- oder ähnliche Laufzeitumgebungen ändern. Da hier ein Vorteil des In-Place-Upgrades weg fällt und eh ein manueller Schritt übrig bleibt, ist hier ein paralleler Neuaufbau schon eher verlockend. Was am Ende sinnvoller ist, entscheidet sich meist je nach Menge der Laufzeitdaten.

Ist damit alles getan?

In vielen Umgebungen wird hier gerne noch vergessen wo das Betriebssystem noch so eine Rolle spielt und auch hier ist die Migration wichtig. Zum einen ist es sinnvoll sich bei Containern oder Images wie beispielsweise bei Vagrant die Basis anzuschauen und hier auf neuere Versionen zu wechseln. Und dann haben wir zum anderen CI/CD-Pipelines, hier kann im Vorfeld über eine Erweiterung der Matrix schon oft eine Kompatibilität sichergestellt werden und nach abgeschlossenem Upgrade können dann die alten Systeme entfernt und damit verbundene Restriktionen gelockert werden, was sicher einige Entwickler freut.

Fazit

Wie hoffentlich jeder sieht, hier steht uns allen Arbeit bevor und zwar nicht nur beim eigentlichen Doing. Aber es kann auch als Chance für Innovation gesehen werden. Beispielsweise hat beim Foreman-Projekt ein regelrechter Frühjahrsputz eingesetzt nachdem mit dem Wegfall des Supports für EL7 und damit dem Bedarf an Support für EL9 der ganze Technologie-Stack modernisiert werden kann. Wenn ich nun jemand aufgeschreckt habe oder allgemein jemand bei dem Thema Hilfe benötigt gerne unterstützen unsere Consultants bei der Planung egal ob es um das richtige Vorgehen oder den Einsatz der Tools geht. Über ein Outsourcing-Kontingent unterstützen die Kollegen auch gerne beim eigentlich Upgrade. Und auch wegen einer Icinga-Subcription darf sich bei Bedarf an unser Vertriebsteam gewendet werden.

Dirk Götz

Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Lies mehr von Dirk und triff unser Team

Linux Monitoring mit Icinga – so löst du bekannte Probleme

von Lorenz Kästle | Jun 5, 2023 | Monitoring & Observability, NETWAYS

This entry is part 5 of 5 in the series Icinga. Einfach. Erklärt.

Beim Betrieb von Computerinfrastrukturen treten früher oder später Probleme auf. Typischerweise schon bei der Einrichtung und später bei Änderungen, aber auch im “Normalbetrieb”. Die Ursachen dafür sind entweder extern, intern oder eine Mischung aus beidem. Zu regelmäßig auftretenden externen Ursachen zählen zum Beispiel eine Änderung des Kontextes der Maschinen, wie etwa ein Strom- und/oder Netzwerkausfall oder Updates, die etwas am äußeren Verhalten eines Programmes ändern.
Aber auch schlicht der Fortlauf der Zeit muss hier erwähnt werden. Eine tragische und unaufhaltsame Gewissheit, die durchaus technische Bedeutung hat, etwa in der Gültigkeit von Zertifikaten oder Problemen mit der Zeitsynchronisation.

Intern können Probleme durch eine bestehende Fehlkonfiguration entstehen. Dieser Begriff ist jedoch etwas Vorsicht zu genießen, da es durchaus Szenarien gibt, in denen eine bestimmte Konfiguration zum Zeitpunkt der Entstehung durchaus richtig und angemessen war. Oftmals zeigt sich erst im Verlauf von Monaten oder Jahren oder durch Änderung des Kontextes, dass die damals „richtigen“ Einstellungen problematisch sind.

An dieser Stelle tritt Monitoring auf den Plan und nimmt seinen Platz in einer gut geplanten IT-Infrastruktur ein. Enterprise-Monitoringlösungen wie Icinga versuchen bei der Voraussage, Entdeckung und Behebung von Problemen zu helfen. Um dir einen guten und vielfältigen Eindruck von den Möglichkeiten eines gut eingerichteten Monitoringtools zu geben, gehe ich in diesem Blogpost auf einige klassische und häufige Probleme, speziell im Kontext von Linux (und damit häufig auch anderen unixoiden Betriebssystemen) ein.

Im Laufe meines Beitrags werde ich regelmäßig auf die Monitoring Plugins eingehen, da diese beim Erkennen von Problemen eine wichtige Rolle spielen. Diese Zusammenstellung an Plugins ist neben Icinga auch für den Einsatz mit anderen Monitoring-Systemen geeignet, solange diese die Monitoring Plugins unterstützen.

Gängige Probleme auf Linux-Maschinen und Monitoringlösungen mit Icinga

Dateisysteme erreichen die Kapazitätsgrenzen

Ein nicht sehr häufiges (bezogen auf die Auftretenswahrscheinlichkeit), aber fatales Problem ist ganz klassisch, dass im Betrieb ein Dateisystem bis an die Kapazitätsgrenzen vollläuft. Dies führt üblicherweise dazu, dass das System seinen Betrieb ganz oder teilweise einstellt, jedoch ist das Fehlerbild potenziell auf den ersten Blick nicht offensichtlich. Beispielsweise können Programme keine großen Dateien mehr anlegen, beziehungsweise wird das Schreiben derselben abgebrochen, aber kleine, temporäre Dateien sind vielleicht (für den Moment) noch möglich.
Das führt je nach betrachteter Software und deren Fehlerbehandlung dazu, dass erst mal noch alles in Ordnung erscheint. Ein Webdienst wird weiterhin ansprechbar sein und kleine Abfragen durchaus beantworten, dann aber bei anderen (bei denen dann versucht wird größere Dateien zu schreiben) die Bearbeitung abbrechen und nur noch Fehler ausgeben, aber nicht vollständig abstürzen.

Ein anderes Beispiel ist eine Datenbank, die zwar noch lesende Zugriffe durchführen kann, aber eben keine Schreibenden. In diesen Fällen wird ein einfacher Test auf die Funktionalität des Dienstes (das init-System des Systems bescheinigt, dass der Dienst läuft; entsprechende Anfragen auf bestimmten Ports werden noch angenommen) ein positives Ergebnis bescheinigen. Trotzdem ist die eigentliche Hauptfunktionalität nicht mehr gegeben.

In einem typischen Szenario, in dem die Checks für das System lokal (oder aus der Ferne über gängige Transportwege wie SSH) ausgeführt werden, ist die klassische und gängigste Wahl beim Monitoring mit Icinga check_disk ( aus den Monitoring Plugins (Debian- und Suse-artige Distributionen) bzw. nagios-plugins (RedHat-Familie)). Zwar ist die Benutzung teilweise etwas ungewöhnlich (Stichwort Gruppierung), aber für unkomplizierte Dateisystem-Setups (und damit die häufigsten) durchaus noch ausreichend.

Ein typischer Aufruf könnte etwa so aussehen:

# ./plugins/check_disk -w 2% -c 1% \
    -X none -X tmpfs -X fuse.portal -X fuse.gvfsd-fuse \
    -X sysfs -X proc -X squashfs -X devtmpfs
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154929MiB (34% inode=96%); /boot/efi 503MiB (98% inode=-);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314740572160B;492755872645;497783993794;0;502812114944 /boot/efi=7340032B;524078284;529426022;0;534773760

# ./plugins/check_disk -w 2% -c 1% -N ext2 -N ext4
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154935MiB (34% inode=96%);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314734280704B;492755872645;497783993794;0;502812114944

In diesem Beispiel werden die Grenzwerte für Dateisysteme so gesetzt, dass der Warnzustand bei weniger als zwei Prozent freiem Speicherplatz und der Kritische bei weniger als einem Prozent auftritt. Die Sammlung an -X-Parametern (beziehungsweise das komplementäre -N) schließt diverse Dateisystemtypen aus, die nicht geprüft werden sollen. Die von mir in diesem Beispiel ausgeschlossenen Dateisystemtypen fallen nicht unter die Kategorie, die man hier im Auge hat. Hierbei handelt es sich um Dateisysteme die meine Dateien persistent auf magnetische Platten oder Halbleiterspeicher fixieren.

Alternativ können check_disk gezielt ein oder mehrere Befestigungspunkte übergeben werden:

./plugins/check_disk -w 2% -c 1% -p /home -p /boot
DISK OK - free space: /home 154935MiB (34% inode=96%); /boot 257MiB (57% inode=99%);| /home=314733232128B;492755872645;497783993794;0;502812114944 /boot=197132288B;482974105;487902412;0;492830720

Zur Feinjustierung existieren noch mehr Optionen, ein check_disk --help kann sehr hilfreich sein. Das Setzen von Grenzwerten für die Benutzung von Inodes mittels -W und -K ist leider ein viel zu häufig vergessenes Problem. Ein Mangel an freien Inodes bietet ein sehr ähnliches Bild wie eine Mangel an freiem Platz, jedoch ist es weniger offensichtlich (und tritt auch deutlich seltener auf).

Alternativen zu check_disk sind diverse andere Monitoring Plugins, wie etwa disk_usage der Linuxfabrik. Damit wird zu großen Teilen dieselbe Problematik abgedeckt. Weiterhin gibt es Plugins, die Rand- oder Sonderfälle behandeln, die außerhalb des Funktionsumfangs der klassischen Plugins liegen.
Sonderfälle dieser Art wären etwa kompliziertere Setups mit Dateisystemen mit einer größeren Menge an Funktionen wie etwas btrfs, xfs oder zfs. Hier ist eine einfache Aussage, wie die von mir bereits betrachtete “Wie viel Platz ist frei/belegt?” nicht so einfach zu treffen. Als wäre das noch nicht genug, gibt es hierbei noch die Problematik von Netzwerk- und verteilten Dateisystemen, die auch etwas komplexer ist.

TLDR

Mindestens das root-Dateisystemen sollte mit check_disk oder etwas Ähnlichem überwacht werden, als Checkintervall reichen fünf Minuten locker aus. Zusätzliche Dateisysteme für das Persistieren von Daten sollten äquivalent überwacht werden. Auch sollte überwacht werden, ob noch genügend Inodes frei sind.

Swapping

Swap-Speicher ist ein Bereich im Langzeitspeicher, der zur Auslagerung von Arbeitsspeicherinhalten dienen kann (Stichwort “Auslagerungsdatei” unter Windows). In Zeiten von sehr limitierter Arbeitsspeicherkapazität eine nützliche Funktion, um kurzfristige Kapazitätsengpässe handhaben zu können, ohne Nutzerprogrammen den angeforderten Speicher zu verweigern. Zusätzlich dient der Swap-Bereich heutzutage oft als Speicherort für Arbeitsspeicherinhalte, wenn eine Maschine in einen Ruhezustand versetzt und der (physikalische) Arbeitsspeicher ebenfalls außer Betrieb geht (Stichwort: “Hibernation”).

Diese Möglichkeiten kommen natürlich mit einem Preis. Festspeicher (“long term storage”) ist immer noch um Größenordnungen langsamer als Arbeitsspeicher (der wiederum deutlich langsamer als die
Speicher (“L*-Caches”) in der CPU ist). Die Auslagerung von aktiv genutzten Arbeitsspeicherinhalten kann dazu führen, dass ein System langsam bis an die Grenze der Benutzbarkeit gebracht wird. Das ist bei einem PC störend und frustrierend, kann jedoch bei Produktivmaschinen teilweise noch schlimmere Konsequenzen haben.
Eine Maschine, die ohnehin gerade unter Last steht, weil sie zum Beispiel sehr viele Abfragen erhält, wird, wenn das Swapping beginnt, sehr viel langsamer werden, was dann die Belastung typischerweise nicht senkt. Es sollte deshalb sichergestellt sein, dass die Nutzung von Swapspeicher (im Normalbetrieb) sowohl in Hinsicht der Quantität (Prozent an freiem/benutzten Speicher) als auch im zeitlichen Rahmen begrenzt ist.

Klassisch bietet sich hier check_swap (wiederum Monitoring Plugins|nagios-plugins) an, beispielsweise:

# ./plugins/check_swap -w 60% -c 20%
SWAP OK - 100% free (36863MB out of 36863MB) |swap=38653657088B;23192194200;7730731400;0;38653657088

In diesem Beispiel wird getestet, ob weniger als 60 Prozent des Swapspeichers frei ist (Grenzwert für WARNING) bzw. 20 Prozent (Grenzwert für CRITICAL). Eine temporär hohe Nutzung mag (je nach Szenario) durchaus erlaubt sein, aber längerfristig dürfte dies ein Problem darstellen.
Als groben Richtwert könnte man vielleicht fünfzehn Minuten anlegen, nach denen jemand alarmiert werden sollte. Das Checkintervall dürfte mit ein, zwei oder drei Minuten ausreichend bedient sein.

Wie hoch ist die Systemlast?

Ganz generell sind Systemressourcen limitiert, seien es CPU-Zeit, Speicher, andere Prozessoren und natürlich die ganzen Schnittstellen dazwischen. Manchmal lässt sich nicht oder nur schlecht an einzelnen kleinen Metriken ablesen, wenn ein Engpass besteht, zumindest wenn die Werte nur eine Teilmenge aller Werte darstellen und die wichtigen Metriken nicht enthalten sind. In unixoiden Systemen gibt es aus diesen und anderen Gründen die load-Metrik, die zwar die Details vermissen lässt, aber zuverlässig einen Indikator für ein Problem liefert.

Händisch kann die load mit dem Programm uptime (beispielsweise) abgerufen werden:

# uptime
 12:21:58 up  1:25,  1 user,  load average: 0.40, 0.38, 0.23

Die load besteht hier aus den drei Zahlenwerten 0.40,0.38 und 0.23, mit einem Aggregatswert über eine Minute, fünf Minuten und fünfzehn Minuten.

Alternativ direkt aus dem Proc-Dateisystem:

# cat /proc/loadavg
0.00 0.06 0.12 1/1316 27272

Und in “proc (5)” findet sich dann auch eine Erklärung der Zahlen.

Wer sich jetzt nicht jedes Mal die Arbeit machen will, diese Werte mit einem händisch eingegebenen Befehl aufzurufen und auszulesen, kann auf eine automatisierte Überwachung durch Check-Plugins, in diesem Fall check_load (Monitoring Plugins|nagios-plugins) setzen. Die Grenzwerte sind in diesem Fall etwas schwierig zu bestimmen, da die “zu hohe Last” stark vom Kontext abhängt.
Generell lässt sich sagen, dass eine load von eins fast der Idealwert ist, da sich damit (im Durchschnitt) immer ein Prozess in der Warteschlange befindet.

Für Werte größer als eins wird die Beurteilung schwieriger. Die Zahlenwerte aus meinem Beispiel stammen von einem Laptop ohne größere Aktivitäten (nur zwei Webbrowser). Für eine größere Maschine, etwa einen Datenbankserver mit 16 (oder mehr) CPU-Kernen, kann ein Wert von 40 auch normal sein und durchaus noch einen akzeptablen Betriebszustand darstellen. Die Option -r für check_load dividiert die load-Werte durch die Anzahl der CPU-Kerne, um eine gewisse “Normalisierung” der Werte zu erreichen, die meistens angemessen ist.

Ein angemessenes Monitoring wäre ein Checkintervall von einer bis drei Minuten mit Benachrichtigung nach fünfzehn Minuten. Als Grenzwerte wären 3,3,3 für WARNING und 5,5,5 für CRITICAL als einigermaßen konservative Einschätzung angemessen.

Ausfälle von Services (systemd) und Prozessen

In den meisten Fällen stellen Maschinen Dienste für Menschen oder andere Maschinen bereit und es ist normalerweise von gesteigertem Interesse, ob dieser Dienst auch läuft. In den meisten Linux-Distributionen ist systemd als Event- und Servicemanager im Einsatz und sollte dazu benutzt werden, durchgängig laufende Programme zu verwalten.

Mittels check_systemd lässt sich ermitteln, ob Dienste (bzw. generalisiert, systemd-units) in einem fehlerhaften Zustand sind oder nicht.

Dazu ein Beispiel mit dem SSH-Serverdienst (openssh):

# ./check_systemd.py -u ssh
SYSTEMD OK - ssh.service: active | count_units=490 data_source=cli startup_time=6.193;60;120 units_activating=8 units_active=332 units_failed=2 units_inactive=148

Im Hintergrund sind Dienste am Ende aber auch “nur” Prozesse und du möchtest potenziell diverse Eigenschaften von Prozessen überprüfen (etwa CPU-Nutzungszeit (in Prozent), oder die Größe des benutzten Speicherbereichs). Erste Anlaufstelle ist für mich check_procs.

Beispielsweise kannst du damit überprüfen, ob Zombieprozesse vorhanden sind:

# ./plugins/check_procs -s Z -w 1
PROCS OK: 0 processes with STATE = Z | procs=0;1;;0;

Ein weiterer Anwendungsfall ist die Überprüfung aller Prozesse, die mehr als zwei Prozent der CPU-Zeit verschlingen:

# ./plugins/check_procs --metric CPU -w 2
CPU WARNING: 1 warn out of 310 processes | procs=310;;;0; procs_warn=1;;;0; procs_crit=0;;;0;

Dateieigenschaften – warum Probleme auftreten können

An vielen Stellen muss überprüft werden, ob eine oder mehrere Dateien vorhanden sind und/oder bestimmte Eigenschaften aufweisen, beispielsweise ob sie älter oder jünger als ein gewisses (relatives) Datum sind, größer oder kleiner als ein Grenzwert sind oder bestimmte Berechtigungen haben. Die Ergebnisse einer solchen Überprüfung können als Indikator für ein Problem in einem Programm dienen, etwa, dass Dateien in einem Spooler-Verzeichnis nicht schnell genug abgeholt werden.

Glücklicherweise ist das ein Bereich, der sich relativ einfach durch selbstgeschriebene, auf den Nutzungsfall abgestimmte Skripte abdecken lässt. Wenn man den passenden find Befehl zusammengebaut hat, kann man nach den Monitoring Plugins Guidelines dann ein Monitoring Plugin bauen, dass den eigenen Spezialfall abdeckt.

Für etwas generellere Fälle gibt es mit check_file_age aber bereits eine Option, die zumindest das Überprüfen auf Alter und Größe erlaubt.

# ./plugins-scripts/check_file_age -f plugins-scripts/check_file_age -w 300:30000000 -c 1: -W 1:300
FILE_AGE WARNING: plugins-scripts/check_file_age is 516096 seconds old and 5193 bytes | age=516096s;300:30000000;1: size=5193B;1:300;0:;0

In diesem Beispiel sollte die Datei plugin-scripts/check_file_age älter als eine Sekunde sein (kritische Bedingung), zwischen 300 und 30000000 Sekunden alt (Bedingung für den WARNING-Zustand) und zwischen einem und 300 Bytes gross (zweite Bedingung für WARNING).

Für alle die es etwas vielfältiger mögen, wären die Monitoring Plugins der Linuxfabrik, die mit file beginnen, eine Option.

Schlusswort

Die angesprochenen Probleme sind natürlich nur ein kleiner Teil der möglichen Problemstellungen, mit denen man als Systemadministrator konfrontiert wird. Zudem habe ich mich für diesen Beitrag auch ausschließlich auf Themen innerhalb einer Maschine limitiert. Die Thematik der Netzwerkproblembehandlung hätte den Rahmen mehr als gesprengt, bietet aber ein gutes Thema für weitere Blogposts.

Ich hoffe, ich konnte anhand meiner gewählten Beispiele verdeutlichen, welche Möglichkeiten der Einsatz von Monitoringlösungen wie Icinga bietet, besonders dann, wenn du ein Unix-basiertes Rechner- oder Servernetz betreibst. Und auch wenn ich mich im Rahmen dieses Posts auf die Ausführung der Checks über die Konsole beschränkt habe, lass dich davon bitte nicht abschrecken. Natürlich können all diese Eingaben auch (bis zu einem gewissen Punkt) mit der grafischen Lösung Icinga Director und die Weboberfläche Icinga Web durchgeführt werden.

Falls du und dein Unternehmen jetzt noch Hilfe bei der Einrichtung und Konfiguration von Icinga benötigt, lass es uns einfach wissen!

In der Zwischenzeit, bleibt zu hoffen dass diese Lektüre jemandem geholfen hat und wenn (aber auch wenn nicht), dann würde sich der Autor über Kommentare freuen.

Lorenz Kästle

Systems Engineer

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Lies mehr von Lorenz und triff unser Team

Leap(p) to Red Hat Enterprise Linux 9

von Dirk Götz | Nov 3, 2022 | IT Automation, Foreman, Ansible

Ich muss mich direkt für das Wortspiel im Titel entschuldigen, aber es lag so nahe als ich mich für das Thema entschieden hatte, denn ich möchte einen neuen Blick auf Leapp werfen mit dem Upgrades von Red Hat Enterprise Linux (RHEL) durchgeführt werden können. Der Blick soll wie gewohnt etwas ausführlicher sein, daher wird Blog-Post als erstes die Frage „Replace or In-Place“ aufgreifen, die ähnlich alt ist wie „Henne oder Ei“. Als nächstes geht es um den Status des Projekts, bevor ich die Nutzung auf Kommando-Zeile erläutere. Dann ein kleiner Abstecher über Foreman-Upgrades bevor es mit dem Cockpit-Plugin graphisch wird und am Ende das Foreman-Plugin und die Ansible-Rolle das ganze Thema massentauglich machen.

Replace or In-Place?

Vermutlich stand bereits jeder Nutzer mal vor der Frage ob sich ein Upgrade lohnt oder nicht doch besser das System direkt mit der neusten Version des Betriebssystems neu zu installieren ist. Bei ersterem ist der Aufwand natürlich entsprechend geringer, denn man liest sich die Neuerungen durch, achtet dabei auf besondere Hinweise, macht nochmal ein aktuelles Backup (das tun doch hoffentlich alle?), startet das Upgrade, neustartet, lässt die Nacharbeiten laufen, neustartet und erfreut sich eines schönen glänzenden neuen Systems. Zumindest bis man merkt, dass manche Schraube immer noch locker, der Müll auf der Rückbank nicht verschwunden ist, der Motor weiter leckt und falsch eingestellt ist, um einen Autovergleich zu bemühen. Oder in unserem Fall bleibt vielleicht die oder andere Einstellung beibehalten, die sich negativ auswirkt, eine Software-Lösung wird vielleicht nicht durch eine modernere Lösung ersetzt und alles was wir mal ausprobiert haben und danach nie wieder genutzt haben nimmt weiterhin Plattenplatz weg.
Das ist dann auch meist das Argument für die Befürworter von Neuinstallationen statt Upgrades. Ein weiteres war zumindest früher oft das Thema es gibt kein einfaches, geeignetes Werkzeug und der Vorgang ist nicht supportet. So musste man früher für Updates von RHEL immer über die Installationsabbilder gehen, damit auch Änderungen an Einstellungen sowie Software möglich waren, wodurch der Aufwand quasi bis auf das Wiederherstellen von Daten der einer Neuinstallation gleicht. Der alternative Weg über den Packagemanager war oft mit manuellen Nacharbeiten verbunden und absolut nicht durch den Support abgedeckt. Hier setzt Leapp an um einen Mittelweg aus Einfachheit für den Benutzer und der Möglichkeit für Anpassungen durch die Distribution zu finden.

Das Projekt

Das Projekt Leapp hat Red Hat 2017 gestartet und es besteht aus einem Framework und den sogenannten Actors, die die eigentliche Arbeit ausführen. Das erste Mal zum Einsatz kam es dann als Upgrade von RHEL 7 auf 8. Weitere Bekanntheit bekam das Projekt unter dem Namen ELevate, was ein Fork der Actor durch die Distributoren von AlmaLinux ist. Der Fork enthält dann Actors um CentOS Linux 7 auf AlmaLinux OS 8, CentOS Stream 8, EuroLinux 8, Oracle Linux 8 oder Rocky Linux 8 zu aktualisieren. Auch wenn die Intention sicher ein einfacher Wechsel von CentOS zu AlmaLinux war, ist der Open-Source-Gedanke hier mit der zusätzlichen Unterstützung der anderen Distributionen sehr löblich umgesetzt, insbesondere nachdem CentOS selbst die Unterstützung von Leapp ausgeschlossen hatte. Für ein Upgrade von RHEL 8 auf 9 gibt es mittlerweile vom Leapp-Projekt selbst auch Actors, was der Grund für mich war mich erneut mit dem Projekt zu beschäftigen, da bei einem Kunden genau dieses Update ansteht.
mehr lesen…

Dirk Götz

Principal Consultant

Lies mehr von Dirk und triff unser Team

Kickstart your Laptop with Linux

von Christoph Niemann | Okt 20, 2022 | 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

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.

Lies mehr von Christoph und triff unser Team

Offizielle Icinga Pakete für RHEL, SuSe und Amazon Linux 2

von Martin Krodel | Feb 28, 2022 | Icinga

Icinga stellt für viele Betriebssysteme fertige Builds auf der Icinga Download Seite bereit. Darüber hinaus hat Icinga eine tolle Community, die Icinga für weitere Umgebungen baut.

Um auch für Enterprise Linux Distributionen weiterhin zuverlässige Icinga Installationen möglich zu machen, hat Icinga für Red Hat Enterprise Linux (RHEL), Amazon Linux 2 und SUSE Linux Enterprise Server (SLES) eigene Pakete veröffentlicht. Diese speziellen Builds werden über ein Subscription Modell angeboten, die Community Pakete und die Icinga Builds für die weiteren Linux Distributionen bleiben frei verfügbar.

Wie komme ich an die Subscription?

Ihr könnt euch hier direkt an uns wenden, wir als Icinga Partner bieten die Subscription gerne an. Diese enthält den Zugriff auf alle Enterprise Pakete, es reicht also eine Subscription für alle Pakete.

Tipp: Wer einen Icinga Supportvertrag hat, kann sich zurücklehnen, hier ist der Zugang bereits enthalten. Bitte meldet euch einfach bei uns, wir stellen die Zugangsdaten gerne zur Verfügung bzw. wir melden uns bei euch in den nächsten Tagen.

Was geschieht mit laufenden Installationen?

Alle bestehenden Umgebungen laufen natürlich weiter. Die Umstellung betrifft nur neue Installationen und zukünftige Updates bestehender Setups.

Kann ich die Subscription testen?

Wenn ihr noch keinen Supportvertrag habt, könnt ihr die Icinga Enterprise Linux Pakete 60 Tage kostenfrei testen. Kurze Nachricht an uns und wir machen den Zugang möglich.

Martin Krodel

Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Lies mehr von Martin und triff unser Team