NETWAYS Blog

NETWAYS wird Puppet Authorized Reseller

von Christian Stein | Jun 1, 2022 | Puppet

Seit vielen Jahren unterstützt NETWAYS bereits erfolgreich Kunden bei der Konzeptionierung, dem Aufbau, der Erweiterung sowie der Migration von Puppet Umgebungen. Dabei lag der Schwerpunkt bislang auf der Open Source Variante, obwohl es im Puppet ENTERPRISE Segment viele interessante und hilfreiche Erweiterungen gibt, die wir im Rahmen der Dienstleistung nicht direkt anbieten konnten.

Diesen Zustand wollten wir ändern! Wir freuen wir uns, dass wir seit Kurzem offizieller Authorized Reseller von Puppet sind. Für unsere Kunden ändert sich an unseren bestehenden Leistungen dadurch nichts. Wir bieten weiterhin die professionellen Dienstleistungen im Open Source Bereich an, die sie von uns gewohnt sind. Der Vorteil dieser Partnerschaft ist eine Erweiterung unseres Portfolios. Anforderungen unserer Kunden können wir jetzt noch besser umsetzen, da wir nun in der Lage sind, ENTERPRISE Lizenzen selbst anzubieten und sämtliche Leistungen damit direkt von uns beziehbar sind.

Puppet als starker Partner

Für unsere Kunden ergibt sich aus dieser Partnerschaft zudem ein zusätzlicher deutlicher Vorteil: Neben den Open Source Themen können wir nun nicht nur die ENTERPRISE Lösungen anbieten, sondern auch mit Puppet und unseren Kunden gemeinsam in den Dialog treten können, um das Configuration Management passgenau beim Kunden zu installieren und zu konfigurieren.

Durch das breite Partner Netzwerk von Puppet können wir auf bisherige Erfahrungen von Puppet in ähnlichen Umgebungen zurückgreifen und mögliche Herausforderungen sowie Anforderungen frühzeitig identifizieren.

Nächster Halt: Solution Provider

Als nächster Schritt steht bei uns jetzt noch aus, dass wir Puppet Solution Provider werden. Damit ergibt sich für unsere Kunden noch eine Vielzahl an weiteren Vorteilen, da unsere Kollegen in diesem Fall offiziell von Puppet zertifiziert werden und somit auch ein Nachweis darüber vorhanden ist. Hierdurch können wir dann auch unser langjähriges Engagement und Know-How, das wir mit Puppet gesammelt haben, schriftlich unter Beweis stellen.

Habt Ihr Interesse an unseren Puppet Dienstleistungen oder Puppet ENTERPRISE? Dann nutzt doch einfach unser Kontaktformular und nehmt Kontakt mit uns auf! Wir freuen uns auf eure Anfragen!

Christian Stein

Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Lies mehr von Christian und triff unser Team

Ansible – How to create reusable tasks

von Thilo Wening | Mrz 24, 2022 | DevOps, Python, Ansible

Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. Often tasks could be used in multiple playbooks to combine update routines, setting downtimes at an API or update data at the central asset management.

To use external tasks in Ansible we use the include_task module. This module dynamically includes the tasks from the given file. When used in a specific plays we would assign play specific variables to avoid confusion. For example:


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ myplay_ad_bind_pw }}"
    bind_dn: "{{ myplay_ad_bind_dn }}"
    server_uri: "{{ myplay_ad_server }}"
    dn: "{{ myplay_ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ myplay_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

If this task should be used in another playbook to reduce the amount of code or is used again with other conditions or values. Therefore the variables need to be overwritten or if it is another playbook the variables are named wrong.

The solve this problem change the variables to unused generic variables. And assign your own variables in the include_task statement.


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ _ad_bind_pw }}"
    bind_dn: "{{ _ad_bind_dn }}"
    server_uri: "{{ _ad_server }}"
    dn: "{{ _ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ _ad_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

The include_task vars parameter provides own variables to the tasks.


vim plays/user_management.yml
[...]
- name: check if user exists in ldap
  include_tasks:
    file: tasks/get_ldap_user.yml
  vars: 
    _ad_bind_pw: "{{ play_ad_pw }}"
    _ad_bind_dn: "{{ play_ad_user }}"
    _ad_server: "{{ play_ad_server }}"
    _ad_user_dn: "OU=users,DC=example,DC=de"
    _ad_usermail: "{{ play_usermail }}"

This can be easily combined with loops, to enhance the reusability of your tasks even more! Checkout this blogpost about looping multiple tasks. Ansible – Loop over multiple tasks

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening

Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Lies mehr von Thilo und triff unser Team

Neues vom Icinga-Installer

von Lennart Betz | Dez 16, 2021 | IT Automation, Icinga

Mein letzter Blog Icinga Installation mit Director in 10 Minuten zeigte wie man mit dem Icinga-Installer und etwas Nacharbeit per Hand zu einem arbeitsfähigen Icinga-Server mit Director bekam.

Inzwischen ist eine neue Version 0.5.0 vom Icinga-Installer veröffentlicht, die einem auch komplett die Installation und Konfiguration des Directors inkl. Datenbank-Setup und erstem Kickstart-Lauf abnimmt.

Abschließend noch ein kleiner Tipp, wie unter zur Hilfenahme des Installers, die GUI des Icinga Webs ausschließlich per HTTPS ereichbar gemacht wird. Voraussetzung sind natürlich ein vorhandenes Zertifikat nebst privatem Schlüssel und das CA-zertifikat bzw. ein Chain-File. Diese müssen zuvor an den angegeben Orte im Dateisystem abgelegt werden. Die erforderlichen Einstellungen können nicht interaktiv vorgenommen werden, lassen sich aber in /etc/icinga-installer/custom-hiera.yaml (hier ein Beispiel für ein RedHat basiertes System) festlegen:

--- apache::default_vhost: false apache::default_ssl_vhost: true apache::default_ssl_cert: /etc/pki/tls/certs/apache.crt apache::default_ssl_key: /etc/pki/tls/private/apache.key apache::default_ssl_ca: /etc/pki/tls/certs/my-ca.crt

Möchte oder muss man eine CA-Chain angeben, lautet die Option apache::default_ssl_chain. Diese ersetzt die Zeile mit default_ssl_ca.

Lennart Betz

Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Lies mehr von Lennart und triff unser Team

Ansible – check your data

von Thilo Wening | Nov 3, 2021 | Ansible

The automation and deployment tool Ansible is able to configure applications in multiple environments. This is possible due to variables used in Roles.

Variables are key to make roles reusable, but without proper documentation or descriptions they can get complicated.
If you want to provide different scenarios which are defined by specific variables, you can provide a good documentation and hope it will be seen and understood, otherwise users will get failed runs.

But instead of failed runs with cryptic messages which show that the used variables are wrong, we can easily check beforehand if the variables are set correctly.

The Ansible module ansible.builtin.assert can provide the solution to this problem.

With Ansible when expressions you can define rules and check variables. If the conditions aren’t true the module will fail with a custom message or if true, reward the user with a custom „OK“ message.


- assert:
    that: role_enable_feature is true and role_feature_settings is defined 
    success_msg: The feature is configured correctly and will be managed. 
    fail_msg: To use the feature please configure the variable role_feature_settings, please look at the documentation section X.

With this module it’s easy to guide users when they forgot to use a specific variable or if they use multiple variables which shouldn’t be used together.

If you want to learn more about Ansible, checkout our Ansible Trainings or read more on our blog.

Thilo Wening

Manager Consulting

Lies mehr von Thilo und triff unser Team

Foreman 3.0 – Was bedeutet der neue Major-Release

von Dirk Götz | Sep 23, 2021 | Foreman

Wer erinnert sich noch an die letzte Versionsnummer bei Foreman mit einer 1 am Anfang? Es war eine 1.24, also 25 Minor-Releases und ein ganzer Haufen Bugfix-Releases, bis zur 2.0! Und nun nach nur 6 Releases mit einer 2.x, kommt schon die 3.0? Hat die Entwicklung hier so viel Fahrt aufgenommen? Um gleich alle Bedenken vorweg zu nehmen: Nein, Foreman nutzt die Major-Versionen um eine größere Änderung an der Infrastruktur hinzuweisen. Mit 2.0 war es die Fokussierung auf PostgreSQL als einzige Datenbank und mit 3.0 ist es das Herauslösen von Puppet in ein separates Plugin.

Puppet als separates Plugin

Das Puppet bei Foreman eine Sonderstellung gegenüber den anderen Konfigurationsmanagementlösungen hat bzw. ab jetzt hatte, ist historisch leicht zu begründen, da Foreman als Managementoberfäche für Puppet entstanden ist. Schon lange sollten die anderen Lösungen aber möglichst gleiche Funktionalität bieten und als gleichwertig betrachtet werden können. Nachdem sowohl in der Community öfters die Frage aufkam, ob man Foreman auch ganz ohne Puppet nutzen kann, als auch sich für Red Hat die Strategie zu Ansible als einzige Konfigurationsmanagementlösung geändert hat, war es nur eine Frage der Zeit, dass Puppet mit den anderen Lösungen gleichgestellt und als ein Plugin heraus gelöst wurde. Das Red Hat hierfür verständlicherweise die Entwicklungszeit zurückfahren möchte, wurde auch bereits von Anfang an klar kommuniziert und somit hat Ondrej Ezr um Unterstützung aus der Community für die weitere Pflege gebeten. Hier geht der Dank ganz klar an die ATIX AG und dmTech, die sich hierzu bereit erklärt haben, sowie iRonin, die sie dabei unterstützen.

Bereits in den letzten Versionen war das Plugin verfügbar und konnte getestet werden. Mit 3.0 wird es immer noch standardmäßig installiert, kann aber falls Puppet nicht gewünscht ist einfach deinstalliert werden. Erst mit 3.1 ist es angedacht es nicht mehr direkt mit zu installieren.

Bis jetzt sind mir hier noch keine Probleme aufgefallen, aber wenn man bedenkt, dass hier dmTech mit wesentlich größerer Umgebung in Produktion testen kann, hätte mich das auch gewundert. Daher mein Aufruf an Foreman-Nutzer ohne Puppet-Umgebung, direkt mal das Plugin zu deinstallieren und zu testen, bzw. an die mit Puppet-Umgebung zu prüfen, ob nicht doch ein Fehler in ihrer Umgebung auftritt.

Neue Hostansicht als Preview

Natürlich bleibt die Entwicklung hier nicht stehen, der nächste große Schritt wird die Modernisierung der Hostansicht sein. Diese ist zwar immer noch funktional aber unbestreitbar in die Jahre gekommen. Wer möchte kann also die Chance nutzen, die neue Ansicht aktivieren und Feedback geben. Zwar sind bereits die ersten Detailverbesserungen für die 3.0.1 angekündigt, aber nur mit Feedback von Leuten die Foreman auch täglich nutzen, kann in meinen Augen auch das bestmögliche Ergebnis erzielt werden.

Wer also die neue Hostpage sehen möchte, muss unter „Administer -> Settings -> Generic“ die Option „Show Experimental Labs“ aktivieren. Nun taucht im Action-Menü der Hostübersicht eine neue Option „New Detail Page“ auf.

Diese sieht aktuell folgendermaßen aus:

Teil der neuen Hostansicht ist bereits jetzt eine neue Statusübersicht, weitere Tabs für die verschiedenen Plugins werden in den nächsten Minor-Releases folgen.

Über Lob, Kritik oder Anregungen freut sich der Feedback-Thread im Community-Forum.

Zukunftssicherheit

Die meisten anderen Änderungen möchte ich unter Zukunftssicherheit zusammenfassen. Zum einen setzt Foreman ab 3.0 auf mod_auth_gssapi für die Kerberos-Authentifizierung, damit steht dieser auch auf EL8 nichts mehr im Weg. Zum anderen wurde der Code zum Parsen der Systemdaten aus allen Quellen in Foreman selbst verschoben, was das angedachte Refactoring erleichtern sollte.

Dazu kommen noch kleine Änderungen an Permissions, Parametern und Defaults, die sich in der Upgrade-Warnings finden. Und zu guter Letzt wurde der Support für Ubuntu 18.04 und EL7 als Plattform abgekündigt, wobei für ersteres konkret mit 3.0 der Support ausläuft, bei EL7 gilt aktuell nur EL8 ab dieser Version als bevorzugte Plattform.

Zusätzlich listen die Release Notes noch eine große Menge an Detailverbesserungen und Bugfixes auf.

Ich wünsche allen ein erfolgreiches Update, Katello-Nutzer warten darum bitte noch auf den finalen Release der Version 4.2! Und wer sich fragt wovon ich hier überhaupt rede, kann sich ja mal unsere Produktseite anschauen, die wir vor kurzem aktualisiert und erweitert haben.

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