Open Source Camp Issue #1 – Foreman & Graylog

Right after OSDC we help to organize the Open Source Camp, a brand new serie of events which will give Open Source projects a platform for presenting to the Community. So the event started with a small introduction of the projects covered in the first issue, Foreman and Graylog. For the Foreman part it was Sebastian Gräßl a long term developer who did gave a short overview of Foreman and the community so also people attending for Graylog just know what the other talks are about. Lennart Koopmann who founded Graylog did the same for the other half including upcoming version 3 and all new features.
Tanya Tereshchenko one of the Pulp developers started the sessions with „Manage Your Packages & Create Reproducible Environments using Pulp“ giving an update about Pulp 3. To illustrate the workflows covered by Pulp she used the Ansible plugin which will allow to mirror Ansible Galaxy locally and stage the content. Of course Pulp also allows to add your own content to your local version of the Galaxy and serve it to your systems. The other plugins a beta version is already available for Pulp 3 are python to mirror pypi and file for content of any kind, but more are in different development stages.
„An Introduction to Graylog for Security Use Cases“ by Lennart Koopmann was about taking the idea of Threadhunting to Graylog by having a plugin providing lookup tables and processing pipeline. In his demo he showed all of this based on eventlogs collected by their honey pot domain controller and I can really recommend the insides you can get with it. I still remember how much work it was getting such things up and running 10 years ago at my former employer with tools like rsyslog and I am very happy about having tools like Graylog nowadays which provide this out of box.
From Sweden came Alexander Olofsson and Magnus Svensson to talk about „Orchestrating Windows deployment with Foreman and WDS“. They being Linux Administrators wanted to give their Windows colleagues a similar experience on a shared infrastructure and shared their journey to reach this goal. They have created a small Foreman Plugin for WDS integration into the provisioning process which got released in its first version. Also being a rather short presentation it started a very interesting discussion as audience were also mostly Linux Administrators but nearly everyone had at least to deal in one way with Windows, too.
My colleague Daniel Neuberger was introducing into Graylog with „Catch your information right! Three ways of filling your Graylog with life.“ His talk covered topics from Graylogs architecture, what types of logs exists and how you can get at least the common ones into Graylog. Some very helpful tips from practical experience spiced up the talk like never ever run Graylog as root for being able to get syslog traffic on port 514, if the client can not change the port, your iptables rules can do so. Another one showed fallback configuration for Rsyslog using execOnlyWhenPreviousIsSuspended action. And like me Daniel prefers to not only talk about things but also show them live in a demo, one thing I recommend to people giving a talk as audience will always honor, but keep in mind to always have a fallback.
Timo Goebel started the afternoon sessions with „Foreman: Unboxing“ and like in a traditional unboxing he showed all the plugins Filiadata has added to their highly customized Foreman installation. This covered integration of omaha (the update management of coreos), rescue mode for systems, VMware status checking, distributed lock management to help with automatic updates in cluster setups, Spacewalk integration they use for SUSE Manager managed systems, host expiration which helps to keep your environment tidy, monitoring integration and the one he is currently working on which provides cloud-init templates during cloning virtual machines in VMware from templates.
Jan Doberstein did exactly what you can expect from a talk called „Graylog Processing Pipelines Deep Dive“. Being Support engineer at Graylog for several years now his advice is coming from experience in many different customer environments and while statements like „keep it simple and stupid“ are made often they stay true but also unheard by many. Those pipelines are really powerful especially when done in a good way, even more when they can be included and shared via content packs with Version 3.
Matthias Dellweg one of those guys from AITX who brought Debian support to Pulp and Katello talked about errata support for it in his talk „Errare Humanum Est“. He started by explaining the state of errata in RPM and differences in the DEB world. Afterwards he showed the state of their proof of concept which looks like a big improvement bringing DEB support in Katello to the same level like RPM.
„How to manage Windows Eventlogs“ was brought to the audience by Rico Spiesberger with support by Daniel. The diversity of the environment brought some challenges to them which they wanted to solve with monitoring the logs for events that history proved to be problematic. Collecting the events from over 120 Active Directory Servers in over 40 countries generates now over 46 billion documents in Graylog a day and good idea about what is going on. No such big numbers but even more detailed dashboards were created for the Certificate Authority. Expect all their work to be available as content pack when it is able to export them with Graylog 3.
Last but not least Ewoud Kohl van Wijngaarden told us the story about software going the way „From git repo to package“ in the Foreman Project. Seeing all the work for covering different operating systems and software versions for Foreman and the big amount of plugins or even more for Katello and all the dependencies is great and explains why sometimes things take longer, but always show a high quality.
I think it was a really great event which not only I enjoyed from the feedback I got. I really like about the format that talks are diving deeper into the projects than most other events can do and looking forward for the next issue. Thanks to all the speakers and attendees, safe travels home to everyone.

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

Softwaremanagement – Katello

Da ich regelmäßig auf die Wichtigkeit von Softwaremanagement im Zusammenhang mit Konfigurationsmanagement verweise, mich zumindest mit Packaging in Form von RPMs häufig auseinandersetze und auch schon der Softwarelösung Spacewalk bzw. Red Hat Network Satellite 5 befasst habe, liegt es nahe mich auch mit Katello zu befassen. Insbesondere da dies ein Foreman-Plugin ist und auch das Upstream-Projekt zum Red Hat Network Satellite 6 ist.
Katello bündelt hierbei mehrere Anwendungen und integriert diese in die Foreman-Oberfläche. Namentlich sind dies Pulp für das eigentliche Softwaremanagment und Candlepin für das Subskriptionmanagement, welche dann wiederum ihre eigenen Abhängigkeiten wie etwa Gutterball für das Zertifikatsmanagement mitbringen. Schaut man sich die Abhängigkeiten an, ist man ganz froh, dass der Katello-Installer die komplette Konfiguration für einen übernimmt und man nicht jede Komponente einzeln installieren muss. Der Installer ist hierbei stark parametrierbar, da im Hintergrund Puppet-Code verwendet wird und die in diesem verwendeten Parameter über den Installer gesetzt werden können.
Nach der Installation erhalte ich also einen vollwertigen Foreman mit zusätzlichen Snippets für die Anbindung an das Softwaremanagement. Dieses kann aus zwei Richtungen betrachtet werden. Zum einen den Hosts welche als sogenannte Content-Hosts auftauchen, was es ermöglicht Software-Repositories zuzuweisen, installierte Software abzufragen und wenn der entsprechende Agent auf dem System installiert ist sogar Softwareinstallationen und -updates aus der Weboberfläche heraus zu steuern.

Natürlich geht dies nicht nur für einzelne Hosts sondern es lassen sich auch mehrere auswählen oder vordefinierte Sets in Form von Host Collections bilden.
Zum anderen gibt es den weit größeren Teil zum Management von Software. Hierbei hat man die Möglichkeit verschiedene Produkte zu definieren, welche dann auch wiederum aus verschiedenen Repositories bestehen. Somit ist es kein Problem sich beispielsweise die Icinga-Repositories in all ihrer Pracht lokal zu spiegeln. Einen eigenen Bereich bilden die Red Hat Repositories, wobei sich hier Subskription- und Softwaremanagement mischen, aber auch diese lassen sich mit dem Manifest aus dem Red Hat Network mit wenigen Mausklicks spiegeln. Die Synchronisation lässt sich hierbei über Pläne steuern, die auch direkt in der Oberfläche erstellt werden. Wirklich mächtig wird das ganze dann durch Content Views, die es erlauben feste Zusammenstellungen von Paketen zu erstellen und sich auch einfach in einander verschachteln lassen, und Livecycle-Environements, welche dann Content Views über die verschiedenen Stages wie Entwicklung, Test und Produktion hindurch bekannt macht. Somit ist es ein leichtes in Produktion nur getestete Updates einzuspielen!
Die Benennung Content View kommt übrigens daher, dass der gleiche Mechanismus auch für Puppet-Code und Docker-Container funktioniert. Letztere habe ich allerdings bisher nicht getestet, für Puppet-Code ist dieses Feature ganz nett, aber nur wenn man hier keine hohe Dynamik braucht. Wenn dies eine Anforderung ist, insbesondere auch für den Einstieg in Puppet, empfehle ich daher zumindest für Puppet die Content-Views zu ignorieren und normale Enviroments zu nutzen. Die Content-Views sind aber flexibel genug um auch mal ein Sicherheitsupdate schnell in alle Stage zu promoten.
Vom Host aus betrachtet sehen Content-View und Lifecycle-Environment dann folgendermaßen aus:

Das Subskription-Management wird die meiste Zeit wohl nur genutzt werden um sich gegen Red Hat entsprechend rechtlich sauber aufzustellen. Diese bieten hierbei dann auch eine Lösung virt-who für ihre virtuellen Subskriptions bei denen der Host subskripiert wird und damit die Nutzung beliebig vieler virtueller Installationen erlaubt. Aber auch die interne Nutzung eröffnet viele Möglichkeiten. Für Katello ist standardmäßig das Organisation/Location-Feature von Foreman aktiv, so dass die Subskriptions auf die einzelnen internen Bereiche aufgeteilt werden können. Außerdem können auch selbst erstellte Produkte entsprechend limitiert werden, will man verhindern das beispielsweise kostenpflichtige Software überall installiert wird oder dass ein Wildwuchs an zum Beispiel Icinga-Installationen entsteht.
Klingt alles gut? Find ich auch! Allerdings möchte ich nicht ein paar Nachteile verschweigen. Zum einen ist das Produkt noch relativ jung und es finden sich immer noch Kinderkrankheiten, zum anderen treibt so eine Lösung die Komplexität nach oben. Außerdem lassen sich aktuell nur RPM-basierte Systeme verwalten, zumindest bis die Entwicklung bei Pulp-Debian weiter vorangeschritten ist. Hier hat Spacewalk noch die Nase vorn, allerdings gefällt mir Content-View und Lifecycle-Environment sehr gut, was beim Spacewalk alles noch individuell geskriptet werden muss. Auch kann Spacewalk nicht nur das Softwaremanagement fernsteuern, sondern beliebige Befehle absetzen, aber auch hieran arbeitet das Foreman-Team.
Wer also noch eine Lösung dieser Art sucht, sollte sich Katello oder auch den Satellite 6 definitiv mal ansehen. Wer schon eine Lösung hat und mit dieser zufrieden ist, sollte die Entwicklung zumindest verfolgen bis Kinderkrankheiten beseitigt und letzte Features implementiert wurden. Und falls wer zwar schon Softwaremanagement, aber noch kein Provisioning und Konfigurationsmanagement hat, sollte sich Foreman anschauen.