Fully packed to reduce heating – OSMC 2016 – Tag 2

OSMC LogoDer gestrige Tag endete in lockerer Atmosphäre in der Indabahn, die wir nach ein paar Jahren am Flughafen wieder zur Abendlokation erkoren hatten, und für die Ausdauernden in Checkpoint Jenny, unserer üblichen Late-Lounge. Aufgrund unserer Rekordteilnehmerzahl gab es auf der Abendveranstaltung ein Running Buffet, so dass man einfach entspannt sitzen bleiben und sich unterhalten konnte und trotzdem gut mit Essen und Getränken versorgt wurde. Für weitere Unterhaltung war mit mehreren Roulette-Tischen gesorgt, an denen natürlich nicht um echtes Geld sondern um die Platzierung und damit den Preis für den ersten Platz gespielt wurde.

Trotz allem hatte Mario Mann volles Haus für den ersten Vortrag “Application Performance Management with Open-Source-Tooling” des Tages. Primär ging es um InspectIt welches Mario sowohl kommerziellen Tools gegenüberstellte als es auch in die Landschaft der “Open Source”-Monitoring-Tools einordnete. Auch hier drehte sich alles um Metriken, diesmal zur Erkennung von Anomalien in der Anwendungsperformance, und um die weiteren Daten um diese Anomalien richtig einzuordnen. Ein weiteres nettes Werkzeug, das ich aus dem Vortrag mitnehme ist WebPagetest.org.

Der “Engineer’s guide to Data Analysis” von Avishai Ish-Shalom spannte die Teilnehmer direkt ein um Problemanalyse auf Basis von Metriken zu betreiben. Ein paar der erlernten Lektionen: Durchschnittswerte sind nicht gut, die schlechtesten 5% (oder 1%) und möglichst nicht aggregierte Daten zeigen das Problem deutlicher. Aggregation ist nötig um die Daten speichern zu können, allerdings muss man im Vorfeld wissen wie man die Daten nutzen will um sie richtig zu aggregieren. Dies gilt auch für die graphischen Tools, die automatisch Daten zur Anzeige aggregieren.

“What’s Happening with OpenNMS” war der Update-Vortrag zu OpenNMS von David Hustace. Auch OpenNMS hat eine stetig wachsende Community und Feature-Liste, mit den üblichen Verdächtigen wie API und Grafana-/Elasticsearch-Integration. Die Integration von Backshift und R zur Darstellung von Graphen erlaubt eine richtige schöne Interaktion mit den Daten wie beispielsweise Live-Analyse und Vorhersage für Trends. Das neue BusinessProcess-Tool sieht auch sehr interessant aus, in der Icinga-Welt würde ich es als Mischung aus dem BusinessProcess Modul und NagVis bezeichnen. Allgemein kann man sagen viel Modernisierung hat in den letzten Monaten stattgefunden und wird es in den nächsten noch weiter tun.

Frisch gestärkt ging es nach dem Mittagessen weiter mit Thomas Niedermeier und “Hello Redfish, goodbye IPMI – The Future of Hardware Monitoring”. Nach einem Abriss warum man Remotemanagement einsetzen sollte und warum IPMI nicht mehr zeitgemäß ist, ging es um Redfish welches seit 2014 versucht eine moderne Lösung für diese Aufgabe darzustellen. Die Lösung basiert auf einer REST-API mit entsprechender Authentifizierung. Wer will kann also schon mit einem einfachen Browser-Plugin oder etwas python-Code arbeiten, die DMTF liefert allerdings sogar schon entsprechende einfache Tools. Es sieht also aus als könnte in naher Zukunft das IPMI-Protokoll zu Gunsten von Redfish abgeschaltet werden.

Nach seinem Vortrag fand dann auch gleich die übliche Hardware-Verlosung statt bei der Thomas-Krenn sich als Sponsor wie üblich nicht Lumpen gelassen hat und so durften drei Teilnehmer mit einer neuen Laptop-Tasche, SSD oder gar Mini-Computer nach Hause gehen. Ebenfalls wurde der Roulette-Gewinner der Abendveranstaltung mit einer smarten Waage beehrt, die man nach einer OSMC sicherlich gebrauchen kann.

Jan Doberstein mit “Take Care of your Logs” machte deutlich warum Logging wichtig ist und warum man Log-Events zentral sammeln sollte. Vom einfachen zentralen Syslog-Server über den Platzhirsch Elastic Stack ging es zu Graylog, welches einem gesamtheitlichen Ansatz folgt um Logs zu normalisieren und anzureichern um sie möglichst hilfreich zu präsentieren. Klarer Vorteil bei Graylog ist und bleibt die schöne Zugriffsteuerung auf die gesammelten Daten. Für Neugierige sei gesagt, dass die Open Beta der nächsten Version kurz vor der Veröffentlichung steht, die es noch flexibler machen wird.

“Software Development seen from a #yolo^Wdevop” von Jan Wagner aus dem Monitoring-Plugins-Projekt zeigte wie sich die Entwicklerwerkzeuge vom Texteditor zu heutigen Toolchains weiterentwickelt haben (inklusive YoloOps Bingo). Ich kann nur sagen ein schöner Einblick in das Projekt und eine nette Auswahl an Tools.

Ich fand es mal wieder eine sehr schöne und interessante Konferenz. Meinen Dank dafür an alle Speaker und Teilnehmer. Ich wünsche allen, die nicht zum Hackathon bleiben können, eine gute Heimfahrt und wir sehen nächstes Jahr am 21. bis 24. November wieder.

Bilder folgen!

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Fully packed to reduce heating – OSMC 2016 – Tag 1

OSMC 2016Auch dieses Jahr begann für mich wieder mit Tag 0, dem Workshop-Tag. Ich durfte Thilo bei einem voll ausgebuchten “Advanced Graphing”-Workshop assistieren, während nebenan Lennart und Thomas einen sehr praktischen “Icinga 2”-Workshop auf Basis der Beispiele aus ihrem Buch hielten. Für den Elastic-Stack waren David und Simon vor ebenfalls vollem Haus tätig, während Michi in entspannter Kleingruppe seine Teilnehmer in das Arbeiten mit Git eingewiesen hat. Und wie immer ging es nach den Workshops nahtlos weiter mit Fachsimpelei beim Abendessen und der anschließender Feuerzangen-Bowle auf dem Nürnberger Christkindles-Markt.

So richtig los ging Tag 1 dann wie immer mit Bernds Begrüßung, bei der sich schon zeigte, dass wir dieses Jahr mit über 300 Teilnehmern einen neuen Besucherrekord vorweisen konnten. Aus seiner Begrüßung stammt auch das Zitat, das ich als Titel für den diesjährigen Konferenzbericht gewählt habe. Zusätzlich zur eigentlichen Begrüßung stellte Bernd auch ganz stolz Netways Web Services vor, unsere neue Software-as-a-Service-Plattform vor. Aktuell zum freien Ausprobieren kann ich jedem empfehlen zumindest mal einen Blick darauf zu werfen, wer noch einen externen Satelliten für seine “Icinga 2”-Umgebung sucht. Und natürlich haben wir es uns nicht nehmen lassen James Fryman zum Geburtstag zu gratulieren.

Dieses Jahr fiel es mir wirklich durchgängig schwer mich für einen Talk zu entscheiden, daher empfehle ich jedem gleich vorweg gespannt auf das Konferenz-Archiv zu warten, um nicht nur das Wichtigste aus Vorträgen, die ich mir angeschaut habe mitzubekommen, sondern aus allen. Für den ersten Vortrag fiel meine Wahl auf Monica Sarbu mit “Monitor your Infrastructure with Elastic Beats” um mich über die aktuelle Entwicklung der Beats zu informieren. Interessant war auch wie die verschiedenen Beats genutzt werden können um relativ einfach Monitoring-Informationen aus Containern rauszubekommen. Eine Aufgabe, die ich doch als herausfordernd betrachte. Zusätzlich gab es nebenbei viele weitere nützliche Informationen, so kann beispielsweise Elasticsearch nun effektiver auch als “Timeseries Database” genutzt werden.

James Fryman hatte mit “Metrics are for chumps – Understanding and overcoming the roadblocks to implementing instrumentation” nicht nur wieder sein Talent für die Namensgebung eines Vortrags bewiesen, sondern hat es mit seiner humorvollen Art geschafft klar aufzuzeigen warum Metriken ein grundlegendes Feature sein sollten. Denn ohne Metriken lässt sich keine Aussage über Kapazität, Verbesserung oder Verschlechterung treffen und man muss sich auf Intuition oder Glück verlassen. Seine Präsentation enthielt nebenbei noch Tipps wo man Metriken abgreifen sollte, wie man Dev und Ops dazu bekommt die Wichtigkeit von Metriken zu verstehen und vieles mehr, wie immer sehr sehens- und hörenswert.

Tom hatte zu seinem Vortrag “Ein Jahr mit dem Icinga Director” volles Haus woran sich das Interesse an der graphischen Konfiguration ablesen lies. Von der einfachen Installation über manuelle Nutzung, Automatisierung, Agent-Deployment bis zum Ausblick auf geplante Features war alles in einer Stunde geboten. Ich denke mal nach dem Vortrag war nicht nur ich vom Director begeistert. Wenn man dann noch weiß wie viel Differenz zwischen offizieller und tatsächlicher Entwicklungszeit liegt, möchte man Tom doch glatt mit einem Gläschen oder auch Fläschchen Wein für weitere Features in Nachtarbeit motivieren! 😉

Nach der wie jedes Jahr üppigen Stärkung ging es für mich weiter mit Gerhard Laußer und “Open Monitoring Distribution 2016+”. Ein kurzer historischer Abriss und schon ging es zur OMD Labs Edition in die Consol die ganzen modernen Tools wie InfluxDB, Grafana und Icinga 2 integriert, so dass auch diese einfach als Teil von OMD zu installieren sind. Die Edition 2016 bringt dann noch zusätzlich Ansible für Neuinstallation, Update, Plugin-Verteilung und Inter-Site-Connections und den “Livestatus Multi Daemon” der Cache, Aggregierung, Sortierung und Formatierung für verschiedene Livestatus-Installationen bietet sowie Prometheus für Cloud-Monitoring.

Michael Medin gab uns in “Automated monitoring with Icinga and NSClient++” zusätzlich zum eigentlichen Thema Pro-Tipps zum Thema Präsentation. Allein die Neuerungen der letzten und nächsten Versionen aufzuzählen würde wohl den Rahmen sprengen. Interessant ist der von Michael angestrebte Paradigmen-Wechsel von aktiven Abfragen zu passivem Real-Time-Monitoring inklusive Metriken und automatischer Konfiguration.

Dieses Jahr mal was neues für mich, denn statt dem Vortrag des Icinga-Projekts wollte ich Shlomi Zadok zu “Security & Compliance automation and reports with Foreman” sehen, schließlich hat man nicht immer die Chance den Entwickler (in diesem Fall des Foreman-OpenSCAP-Plugins) persönlich zu hören. Neben der allgemeinen Erklärung was Foreman so ist, ging es natürlich primär um Compliancereports, welche ich bereits vor einer Weile in einem Blogpost behandelt habe. Die geplanten Erweiterungen klingen genau wie meine Wunschliste: Mehr Informationen und Anpassen der Profile in der Oberfläche sowie Ausführen der Remediation-Skripte via Remore Execution.

Natürlich will ich dem geneigten Leser auch die Neuigkeiten rund um Icinga nicht verschweigen. Fangen wir klein an mit dem überarbeiteten Dashboard, Performance-Verbesserungen in “Icinga 2″s Datenbankschnittstelle, Support für die “Icinga 2”-API als Kommandotransport in Icinga Web 2 sowie Verschönerungen wie die Möglichkeit Ankündigungsbanner zu schalten. Und machen groß weiter mit dem Cube, der Datawarehouse-Funktionalitäten für Icinga Web 2 bringt, sowie dem aktualisierten Businessprocess Module.

Nach dem Konferenztag geht es nun zur Abendveranstaltung in die Indabahn um gemeinsam der Völlerei zu frönen und sich weiter zum Thema Monitoring auszutauschen. Es werden sicher wieder die verschiedensten Personen und Projekte zusammenfinden und ich werde versuchen morgen zu berichten.

Hier mal ein paar erste Eindrücke:

 

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Orchestration mit Foreman

Foreman Logo

Ich möchte heute mal wieder ein Plugin vorstellen, das Foreman um eine neue Funktionalität erweitert. Diesmal handelt es sich um das Plugin “Remote Execution” and die Funktionalität möchte ich mal “Orchestration” nennen.

Nachdem sich unter dem Begriff Orchestration jeder was anderes vorstellt und es mindestens zwei verschiedene Ansätze in der IT gibt, möchte ich mit einer kleine Definition und Abgrenzung anfangen. In diesem Fall verstehe ich unter Orchestration die zentrale Steuerung von Jobs, sowohl zum direkten als auch zeitgesteuerten Ausführung auf den angebundenen Systemen. Der zweite Aspekt zentrale Steuerung von Jobs auf verschiedenen Systemen mit Abhängigkeiten zu einander wird hier leider nicht bedient. Das Plugin unterstützt einen Administrator somit darin beispielsweise allen Systemen ein Update-Kommando zu schicken, um die Logik das jeweils nur ein Knoten im Cluster gleichzeitig gemacht werden soll muss er sich also weiterhin kümmern.

Aber fangen wir doch einfach von vorne mit der Installation an. Diese erfolgt am einfachsten mit dem Foreman-Installer, welcher die Puppet-Module des Projekts verwendet. Wenn man diesen Installationsweg nimmt und auch gleich den Provider “SSH” dazu nimmt, bekommt man gleich alles fertig eingerichtet. Dies heißt es gibt dann einen SSH-Key auf dem Smart-Proxy, der per Snippet direkt auf neuen Systemen als “Authorized Key” für “root” deployed wird. Um bestehende Systeme muss sich noch gekümmert werden, aber dies übernimmt das Konfigurationsmanagement gerne. Wer hier nicht mit “root” arbeiten will oder darf, kann dem Plugin auch einen anderen Anmeldebenutzer, effektiven Benutzer zur Ausführung und die Methode zum Wechseln zwischen diesen konfigurieren. Wem “SSH” als Provider nicht gefällt, kann sich bereits den Entwicklungsstand des “Ansible“-Providers anschauen, für die Zukunft sind noch weitere Provider wie “Salt” oder “MCollective” geplant.

Im Webinterface von Foreman erhält man nun die Option Jobs auszuführen. Ich empfehle den Weg über die Hostliste, um mehrere Host auszuwählen und dann für alle eine “Run Job”-Action auszulösen. Für den Power-User funktioniert auch der direkte Einstieg über die Job-Maske und mit eine Suchbedingung wie alle Systeme mit einer bestimmten Betriebssystemversion oder alle Produktivsysteme.

Job Invocation

Nachdem ein Job eingeplant wurde, wird dieser im Hintergrund über das Foreman-Task-Plugin ausgeführt und man kann für jeden Job die Ausführung sehen, so dass man weiß auf wie vielen System der Job noch ausgeführt werden muss, schon erfolgreich oder mit Fehlern gelaufen ist.

Job Result

Auch der Output jedes einzelnen Systems kann nachgeschaut werden, so dass man sieht warum ein Job fehlgeschlagen ist oder auch bei erfolgreicher Ausführung natürlich was genau passiert ist.

Job Output

Die ausführbaren Kommandos basieren auf Job-Templates ähnlich den Provisioning-Templates. Neben dem generischen Kommandos sind bereits Templates zum Softwaremanagement, Powermanagement, Steuerung von Diensten und der Interaktion mit Puppet vorbereitet. Zusätzlichen können natürlich eigene Templates erstellt werden, inklusive den Eingabemasken mit Validierung.

Neben der sofortigen Ausführung lassen sich Jobs auch zeitgesteuert einplanen. Hierbei wird angegeben wann frühestens aber auch wann spätestens der Job ausgeführt wird. Außerdem können auch wiederkehrende Jobs im gleichen Stil wie Cronjobs eingeplant werden.

Alles in allem ist für mich das “Remote Execution”-Plugin eine echte Bereicherung für Foreman und der logisch nächste Schritt nach Provisioning und Konfigurationsmanagement, weshalb es auch Teil der Foreman-Schulung geworden ist. Von SSH als Provider bin ich allerdings noch nicht überzeugt und will mir mit dem Wissen aus unserer Ansible-Schulung auch mal diesen Provider im Detail anschauen.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Foreman wird 7 – Wie war die Party?

Foreman Logo

Wie sich einige vielleicht erinnern, hatte ich vor ein paar Wochen zur Feier zum 7. Geburtstag des Foreman-Projekt eingeladen. Nun möchte ich den in meinen Augen gelungenen Event Review passieren lassen.

Mehr oder weniger pünktlich hat sich ein Teilnehmer-Kreis von 20 Leuten (zu Spitzenzeiten) eingefunden, der auch einige Mitglieder des Foreman-Teams umfasst hat. Besonders erwähnenswert sind hier Greg Sutcliffe, der es sich nicht nehmen lies als Community Manager aus Schottland herunterzukommen, und Ewoud Kohl van Wijngaarden, der den weiten Weg aus den Niederlanden auf sich nahm.

Den Anfang durfte ich machen, hatte aber wirklich nur ein paar Folien vorbereitet um nochmal ans geplante Programm zu erinnern, die Räumlichkeiten vorzustellen und die für die Hands-On-Session vorbereiteten Demo-Systeme zu erläutern. 4 Stück hatte ich vorbereitet, von denen zwei Foreman 1.12 mit alle den Möglichkeiten zeigten die ich auch in der Schulung vorstelle, einmal auf Basis Puppet 3 und einmal Puppet 4. Eines zeigte Katello 3.0, das Foreman unter anderem mit seinen Lifecycle-Environments um Staging für Content erweitert. Als viertes Demo-Setup hatte ich mir vorgenommen was besonderes zu zeigen und da es aufgrund fehlender Zeit zum Testen mit Windowsdeployment nicht geklappt hat, habe ich mich dem Docker-Hype angepasst und das Docker-Plugin für Foreman installiert. Nachdem die Teilnehmer auf die Systeme losgelassen wurden, konnte sich wohl keiner der “Foreman-Wissenden” mehr vor Fragen retten. Ein hohes Interesse bestand an nach meiner Auffassung vor allem an der Funktionsweise der Compute Resources, welche es erlaubt virtuelle Maschinen aus Foreman heraus anzulegen und direkt zu provisionieren, und dem Remote Execution Plugin, welches Orchestration ermöglicht. Erfreut war ich aber auch einigen OpenSCAP zur Überwachung von Compliance-Policies und ABRT als zentrales Crash-Reporting näher bringen zu dürfen. Alle waren am Ende so in Systeme und Diskussionen vertieft, dass wir gar keine offizielle Pause machten und stattdessen nahtlos zu den Vorträgen übergingen.

Foreman Event

Für die Vorträge haben wir eine gute Mischung gefunden, was ich so dem Feedback entnehmen durfte. Michael Moll stellte die Neuerungen in Foreman 1.12 vor und wenn man von einem der beteiligten Entwickler hört wie viel unter der Haube nötig war um sowas wie den “Puppet 4”-Support hinzubekommen, merkt man erst nochmal wie sehr sich die Versionen unterscheiden und versteht warum dieses Feature gefühlt anderthalb Jahre gebraucht hat. Der Ausblick auf 1.13 mit vollständigem IPv6-Support erfreute auch sicher viele. Timo Goebel stellte vor wie Filiadata, die IT-Tochter von dm, in nur 3 Jahren von 0 auf 2000 Linux-Server kam, welche zentrale Rolle Foreman dabei spielte und wie gut es hierbei gelungen ist die Integration in die Umgebung durch die Erweiterungsmöglichkeiten von Foreman umzusetzen. Hierbei hat er auch immer wieder die Hilfsbereitschaft der Forman-Community betont und dies hat Timo auch vom reinen Foreman-Anwender zum Core Contributor geführt. Interessant war auch seine noch offene Wunschliste zum Abschluss, man kann also sicher noch mit weiteren interessanten Plugins in der Zukunft rechnen. Den Abschluss der Vortragsreihe bildete Achim Ledermüller mit einem Einblick in die Opennebula-Foreman-Integration, die er mit den Kollegen entwickelt hat. Alles inklusive einer Livedemo mit den aktuellsten Versionen!

Foreman T-Shirt

Den gemütlichen Teil leitete dann unser Events-Team ein, welches uns dankenswerterweise mit Pizza versorgte. Netways-typisch konnte jeder Teilnehmer, der nicht mehr mit dem eigenen Auto fahren musste, noch bei Bier und Gin-Tonic weiter diskutieren und den Tag ausklingen lassen bis ich 2,5 Stunden später hinter den letzten das Licht aus machen durfte.

Mein vorläufiges Fazit ist es war ein gelungener Event und es wurde schon angeregt es zum 8. Geburtstag zu wiederholen. Ein paar Dinge habe ich auch schon dafür gelernt. Nächstes Mal gibt es die Einladung also hoffentlich früher und dann schon mit vollständigem Programm und Registrierungslink an allen Stellen. Für die Hands-On-Session, die auch gut ankam, werde ich nächstes Mal noch ein paar Slides einbauen, die nicht nur sagen was auf den Demo-Systemen installiert ist, sondern auch direkt ein paar Hinweise zur Nutzung geben. Und Greg hat schon mitgenommen die T-Shirt-Box muss größer sein! 😉

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Minimale Rechte und persönliche Accounts zur Administration

Icinga 2

Nachdem in unserer letzten “Icinga 2”-Schulung die Diskussion aufkam wie man Icinga 2 am besten mit minimalen Rechten konfiguriert und administriert, will ich mich dieser Thematik mal annehmen. Dies wird zwar anhand des Beispiels Icinga 2 auf CentOS 7 sein, aber lässt sich so auf jeden Dienst anwenden, der in Konfigurationsdateien verwaltet wird.

Ausgangsbasis

Die Ausgangsbasis stellen immer die Rechte dar, die durch das Package bei der Installation vorgegeben werden. Diese sollen unverändert bleiben, da sie sonst bei einem Update wieder auf den Standard des Packages zurückgesetzt werden. Als zweites gehen wir mal davon aus, dass eine Anmeldung als unpriviligierter Benutzer mit einem persönlichen Account möglich ist, wobei egal ist ob dieser lokal angelegt ist oder aus einem zentralen Verzeichnisdienst kommt, und dass dieser zur Administration genutzt werden soll.

Bei Icinga 2 sehen die Rechte nach der Installation folgendermaßen aus:

  • Auf dem Hauptverzeichnis /etc/icinga2 hat root alle Rechte, die Gruppe icinga darf lesen und browsen, alle anderen haben keine Rechte.
  • Auf die Dateien und Unterverzeichnisse hat der Benutzer icinga alle Rechte, die Gruppe icinga darf lesen und Verzeichnisse browsen, alle anderen haben keine Rechte.
  • Die Ausnahme bildet die Datei /etc/icinga2/init.conf, bei der die Benutzerrechte auf root liegen, aber auch nicht editiert werden sollte.

Zusätzlich zu den Dateirechten brauchen wir zur Administration Befehle wie systemctl reload icinga2.service um Icinga 2 neuzustarten oder auch icinga2 daemon -C zum Validieren der Konfiguration. Die Systemkommandos können nur als root ausgeführt werden, die Icinga-Kommandos als root oder icinga. Der Benutzer icinga ist allerdings als Benutzer gedacht unter dem der Dienst läuft und hat daher keine Benutzerumgebung, Kommandos können mit sudo aber trotzdem mit seinen Rechten ausgeführt werden.

Ein unpriviligierter Account kann nun noch nicht mal die Konfiguration lesen oder auch nur durch die Verzeichnisse navigieren, den Dienst nicht steuern oder Icinga-Kommandos absetzen. Dies können wir auf zwei Arten lösen. Methode 1 sind Gruppenrechte, Methode 2 ACLs, beides angereichert um eine Prise sudo um Kommandos unter anderen Rechten auszuführen.

(more…)

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.