Autorenarchiv: Jörg Kastning

RHEL System Roles: firewall

In Teil 5 meiner losen Reihe über die RHEL System Roles stelle ich die Rolle firewall vor. Diese dient der Konfiguration des Regelwerks für firewalld. Möchte man bestimmte Regelsätze für alle bzw. eine Gruppe von Servern konfigurieren, erleichtert der Einsatz dieser Rolle die Arbeit und reduziert den administrativen Aufwand.

Im Folgenden stelle ich meinen Anwendungsfall vor. Anschließend beschreibe ich, wie ich diesen mithilfe der RHEL System Role löse.

Während mir dieser Artikel zur Dokumentation dient, soll er euch den Einsatz von RHEL Roles verdeutlichen.

Warnung: Die Firewall-Konfiguration eines Hosts über das Netzwerk birgt die Gefahr, sich selbst auszusperren. Wenn dies passiert, benötigt man höchstwahrscheinlich physischen Zugriff auf den verkonfigurierten Host.

Anwendungsfall

Ich möchte sicherstellen, dass auf allen RHEL-Systemen in meiner Labor-Umgebung das Paket firewalld installiert ist, der Service aktiviert ist und läuft. Darüber hinaus möchte ich sicherstellen, dass ausschließlich der SSH-Zugriff in der lokalen Hostfirewall freigegeben ist und alle übrigen Regeln entfernt werden.

Die Rolle

Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.firewall/ und die Dokumentation in /usr/share/doc/rhel-system-roles/firewall/README.md. Aus letzterer stammt auch folgendes Beispiel:

---
- name: Erase existing config and enable ssh service
  hosts: myhost

  vars:
    firewall:
      - previous: replaced
      - service: 'ssh'
        state: 'enabled'
  roles:
    - rhel-system-roles.firewall

Dieses Beispiel kann ich direkt in das folgende Playbook übernehmen.

Das Playbook

Das Playbook ist kompakt und übersichtlich:

---
- name: Ensure firewalld is started with SSH-acess only
  hosts: all

  vars:
    firewall:
      - previous: replaced
      - service: 'ssh'
        state: 'enabled'
  roles:
    - rhel-system-roles.firewall

Der folgende Playbook-Lauf in meiner Labor-Umgebung zeigt, dass sich die RHEL System Role auch um die Installation, Aktivierung und den Start des Dienstes firewalld kümmert, wenn dies erforderlich ist.

[root@ansible-ctrl ansible]# ansible-playbook firewall_config.yml 

PLAY [Ensure firewalld is started with SSH-acess only] ************************************

TASK [Gathering Facts] ********************************************************************
ok: [rhel7]
ok: [ansible-pctrl]
ok: [rhel9]
ok: [rhel8]

TASK [rhel-system-roles.firewall : include_tasks] *****************************************
included: /usr/share/ansible/roles/rhel-system-roles.firewall/tasks/firewalld.yml for ansible-pctrl, rhel7, rhel8, rhel9

TASK [rhel-system-roles.firewall : Ensure ansible_facts used by role] *********************
ok: [rhel7]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel8]

TASK [rhel-system-roles.firewall : Install firewalld] *************************************
ok: [ansible-pctrl]
changed: [rhel9]
changed: [rhel8]
changed: [rhel7]

TASK [rhel-system-roles.firewall : Install python-firewall] *******************************
skipping: [ansible-pctrl]
skipping: [rhel8]
skipping: [rhel9]
ok: [rhel7]

TASK [rhel-system-roles.firewall : Install python3-firewall] ******************************
skipping: [rhel7]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel8]

TASK [rhel-system-roles.firewall : Enable and start firewalld service] ********************
ok: [ansible-pctrl]
changed: [rhel7]
changed: [rhel9]
changed: [rhel8]

TASK [rhel-system-roles.firewall : Check if previous replaced is defined] *****************
ok: [rhel7]
ok: [ansible-pctrl]
ok: [rhel9]
ok: [rhel8]

TASK [rhel-system-roles.firewall : Get config files, checksums before and remove] *********
ok: [rhel9]
ok: [rhel7]
ok: [rhel8]
ok: [ansible-pctrl]

TASK [rhel-system-roles.firewall : Configure firewall] ************************************
ok: [rhel7] => (item={'service': 'ssh', 'state': 'enabled'})
ok: [rhel9] => (item={'service': 'ssh', 'state': 'enabled'})
ok: [rhel8] => (item={'service': 'ssh', 'state': 'enabled'})
ok: [ansible-pctrl] => (item={'service': 'ssh', 'state': 'enabled'})

TASK [rhel-system-roles.firewall : gather firewall config information] ********************
skipping: [ansible-pctrl] => (item={'service': 'ssh', 'state': 'enabled'}) 
skipping: [rhel9] => (item={'service': 'ssh', 'state': 'enabled'}) 
skipping: [rhel7] => (item={'service': 'ssh', 'state': 'enabled'}) 
skipping: [rhel8] => (item={'service': 'ssh', 'state': 'enabled'}) 

TASK [rhel-system-roles.firewall : update firewalld_config fact] **************************
skipping: [rhel7]
skipping: [ansible-pctrl]
skipping: [rhel9]
skipping: [rhel8]

TASK [rhel-system-roles.firewall : gather firewall config if no arguments] ****************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel9]
skipping: [rhel8]

TASK [rhel-system-roles.firewall : update firewalld_config fact] **************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel9]
skipping: [rhel8]

TASK [rhel-system-roles.firewall : Get config files, checksums after] *********************
ok: [rhel7]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel8]

TASK [rhel-system-roles.firewall : Calculate what has changed] ****************************
changed: [ansible-pctrl]
changed: [rhel7]
changed: [rhel9]
changed: [rhel8]

TASK [rhel-system-roles.firewall : Show diffs] ********************************************
skipping: [ansible-pctrl]
skipping: [rhel8]
skipping: [rhel7]
skipping: [rhel9]

PLAY RECAP ********************************************************************************
ansible-pctrl              : ok=11   changed=1    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0   
rhel7                      : ok=11   changed=3    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0   
rhel8                      : ok=11   changed=3    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0   
rhel9                      : ok=11   changed=3    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

Fazit

Ich beginne, mich an dieser Stelle zu wiederholen. Auch diesmal war es möglich, mithilfe einer RHEL System Role einen einfachen Anwendungsfall schnell und unkompliziert zu lösen, ohne selbst eine Ansible-Rolle schreiben zu müssen. Ein einfaches Copy-Past-and-Modify genügte.

In meinen Augen ist es Red Hat gelungen, den System-Administratoren mit den RHEL System Roles etwas Arbeit abzunehmen und sie beim Einsatz von Ansible zu unterstützen.

Lasst euch überraschen, welche Rolle ich mir als nächstes herauspicke.

Quellen und weiterführende Links

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: sshd

Ansible: Seafile Professional Edition in Rootless-Podman-Umgebung bereitstellen

Wer diesen Blog regelmäßig liest, kann den Eindruck gewinnen, es sei mein Hobby, Ansible-Rollen zu schreiben, mit denen von mir genutzte Web-Anwendungen auf Servern bereitgestellt werden können. Dieses Mal habe ich es mit Seafile getan und möchte in diesem Beitrag darüber berichten.

Was ist Seafile?

Seafile ist eine Sync&Share- bzw. Private-Cloud-Lösung ähnlich wie Nextcloud, ownCloud oder TeamDrive. Auf mich erweckt Seafile den Eindruck, als wenn der Schwerpunkt jedoch auf der Synchronisation und dem Teilen von Dateien liegt und damit genau meinem Suchmuster entspricht.

Seafile gibt es in einer Community und einer Professional Edition. Die Professional Edition darf mit bis zu drei Benutzern kostenlos verwendet werden.

Für weiterführende Informationen wird auf die Seiten des Herstellers und den Wikipedia-Artikel verwiesen.

Was ist das Ziel?

Nun, es gibt nicht das eine Ziel. Ich habe mit diesem kleinen Wochenendprojekt folgende Ziele verfolgt:

  • Beschäftige dich mit Ansible.
  • Beschäftige dich mit der Collection Containers.Podman.
  • Beschäftige dich mit rootless Podman.
  • Deploye Seafile Professional Edition in einer rootless-Podman-Umgebung, um es als Sync&Share-Lösung nutzen zu können.

Die Vorgehensweise

Zuerst habe ich mich informiert, ob es Container-Images für Seafile gibt und ob entsprechende Installationswege in der Dokumentation beschrieben sind. Meine Recherche förderte folgende Treffer zutage:

Ansible-Rollen haben eine einheitliche Struktur. Mit dem Befehl ansible-galaxy role init ansible_role_deploy_seafile_with_rootless_podman habe ich das Grundgerüst für meine Rolle erstellt. Anschließend habe ich die notwendigen Dateien {defaults,meta,tasks,vars}/main.yml mit Inhalt gefüllt und nicht benötigte Verzeichnisse wie handlers gelöscht. Mir ist dabei wichtig, dass alle notwendigen Parameter über Variablen definiert werden, die in defaults/main.yml zu finden sind. In vars/main.yml befinden sich hingegen nur Variablen, welche intern von der Rolle verwendet werden und vom Benutzer nicht explizit gesetzt werden sollen. So lässt sich die Rolle leicht wiederverwenden, um verschiedene Seafile-Instanzen auf dem gleichen Host oder in unterschiedlichen Umgebungen zu deployen.

Bevor ich die Rolle zum ersten Mal auf meinen Server angewendet habe, habe ich sie mit yamllint und ansible-lint geprüft und vorhandene Warnungen und Fehler behoben. Allerdings lassen sich mit den Lint-Werkzeugen und der Option --syntax-check nicht alle Fehler im Vorfeld finden. Da mir ein zweites Augenpaar fehlte, habe ich die letzten Tippfehler erst durch die Verwendung des Ansible Playbook Debugger gefunden.

Das Ergebnis

Das Ergebnis findet ihr auf:

Unter allen drei URLs könnt ihr meine Rolle herunterladen. Es ist damit möglich, eine lauffähige Seafile Pro Instanz bereitzustellen. Ein Test auf Idempotenz und ob diese Rolle auch zur Aktualisierung einer bestehenden Umgebung genutzt werden kann, steht noch aus.

Ihr seid herzlich eingeladen, die Rolle bei Interesse zu testen. Ich freue mich über Rückmeldungen zur Rolle und Dokumentation (Readme.md).

Ich habe das Deployment bisher nur auf Debian Buster getestet. Daher freue ich mich besonders über Rückmeldungen, wenn ihr die Rolle erfolgreich auf anderen Plattformen angewendet habt. Dann kann ich die entsprechenden Angaben für Ansible Galaxy ergänzen.

Eure Rückmeldungen nehme ich in den Kommentaren zu diesem Beitrag, per E-Mail oder in meinem neuen Matrix-Kanal #my-it-brain:matrix.org entgegen.

Fragen an meine Leser*innen

Ich interessiere mich für Themen rund um Ansible und Podman und frage mich, wie dies bei euch aussieht. Daher freue ich mich, wenn ihr in den Kommentaren oder gern auch per E-Mail und Chat folgende Fragen beantworten mögt:

  • Verwendet ihr Ansible für Software-Deployments?
  • Kennt ihr Podman und nutzt ihr es im privaten und/oder beruflichen Umfeld?
  • Findet ihr die Nutzung von Ansible zur Bereitstellung von Software auf (rootless) Podman sinnvoll? Oder bevorzugt ihr andere Bereitstellungsverfahren?

Ich freue mich auf eure Antworten.

Erfahrungsbericht zu den Chemnitzer Linux-Tagen 2023

Endlich sind wieder Chemnitzer Linux-Tage vor Ort in der Karl-Marx-Stadt. Für mich beginnen diese schon Wochen vorher, wenn die Vorfreude auf dieses Ereignis einsetzt.

Wenn dieser Erlebnisbericht veröffentlicht wird, ist die Konferenz leider schon wieder vorbei. Wie es war, erfahrt ihr im nun folgenden Text.

Anreise

Nach der Vorfreude kommt die Anreise. Bisher bin ich immer mit dem Auto nach Chemnitz gefahren. Von meinem Wohnort aus war ich regelmäßig nach 3,5-4,5 Std. im Hotel, inkl. Pause, Tanken, Essen und Erleichtern.

Ich mag Autofahrten. Ich kann während der Fahrt entspannen, meine Musik so laut hören, wie ich mag und muss keine anderen Menschen neben mir dulden. Es ist für mich eine komfortable Art zu reisen. Einziger Nachteil, ich kann während der Fahrt nicht arbeiten, bloggen, etc.

Da mich diesmal mein Umweltgewissen plagte und ich die Zeit besser nutzen wollte, habe ich meine Reise mit der Bahn geplant. Um nicht ganz so unkomfortabel zu reisen, habe ich 1. Klasse gebucht. Kann man frühzeitig planen und Sparpreisangebote nutzen, ist der Preis gegenüber der 2. Klasse durchaus gerechtfertigt, zumal die Sitzplatzreservierung schon mit inbegriffen ist.

Ganz ohne Auto geht es dennoch nicht. Da ich den ersten Fernverkehrsbahnhof mit dem ÖPNV erst nach 1-1,5 Std. erreicht hätte, bin ich in 40 Min. mit dem Auto zum nächsten kostenlosen Park&Ride-Parkplatz gefahren und von dort mit der Stadtbahn weiter zum Hauptbahnhof. Hier ging meine Reise mit 7 Minuten Zugverspätung weiter. Bei einer geplanten Umstiegszeit von 8 Minuten sah ich meinen Anschlusszug schon ohne mich fahren. Doch auf unsere Bahn ist Verlass. Auch der Anschlusszug hatte Verspätung, sodass ich wie geplant mit diesem weiterreisen konnte.

In Leipzig wurde es dann auch nochmal kurz hektisch, da für den Umstieg nur 4 Minuten verblieben. Für derartige Sprints bin ich definitiv zu unsportlich. Doch auch hier habe ich den Anschluss noch erreicht und traf in einem sehr vollen RE auf die ersten CLT-Teilnehmerinnen und Teilnehmer. So verging auch die letzte Stunde der Anreise wie im Flug.

Insgesamt war die Anreise sehr entspannt, bequem und angenehm. WLAN funktionierte im ICE und IC durchgängig und ich konnte so mobil arbeiten.

Die Chemnitzer Linux-Tage 2023

Nun habe ich der Anreise soviel Raum gewidmet und weiß gar nicht, was ich groß über die Veranstaltung selbst schreiben soll. Dies ist vielleicht noch dem tollen Gefühl geschuldet, die Community endlich mal wieder vor Ort getroffen zu haben.

Laut Resümee der Veranstalter kamen rund 3000 Besucherinnen und Besucher zur Veranstaltung. Somit gab es reichlich Gelegenheit zum Fachsimpeln, Netzwerken und es einfach mal zu genießen, unter normalen Menschen zu sein.

Am Samstag habe ich zwei Vorträge besucht:

Mehr war nicht drin. Denn es war einfach zu schön, alte Bekannte wiederzutreffen und neue Nerds kennenzulernen. Nach drei Jahren Pause war mir dies ein Fest.

Das Bild zeigt Mitglieder der Red Hat Accelerators und Ubuntuusers Community vor dem Ubuntu Stand auf den Chemnitzer LInux-Tagen 2023.
Gruppenfoto mit Mitgliedern der Red Hat Accelerators und Ubuntuusers Community vor dem Ubuntu-Stand auf den Chemnitzer Linux-Tagen 2023.

Im Laufe des Tages haben Dirk, Sujeevan und ich noch unseren Gemeinschaftsvortrag geprobt. Wir konnten während des Tages bereits auffällig oft vernehmen, dass etliche Personen diesen unbedingt hören wollten. Bloß keinen Druck aufkommen lassen. ;-)

Die Samstagabendveranstaltung fand in diesem Jahr in der Mensa statt, welche schräg gegenüber dem Hörsaalgebäude liegt. In meinen Augen war es eine gute Entscheidung, das Abendprogramm hierhin zu verlegen. Hier konnte man gemütlich zusammensitzen und ein wenig essen, trinken und plaudern. Das Essen war übrigens großartig!

Nur die Musik passte meiner Meinung nach nicht so recht zum Publikum. Statt Gesang mit musikalischer Begleitung auf dem Flügel hätte ich mir eher ein paar Arcade-Sounds aus 8-Bit-Midi-Prozessoren gewünscht.

Am Sonntag hatte ich die Ehre, um 10:00 Uhr einen der ersten Vorträge (Link zur Aufzeichnung) des Tages zu halten. Der Raum war voll, die Moderation spitze (Danke Henning) und auch die kleine Live-Demo hat geklappt. Im Anschluss konnte ich noch einige Fragen zu Ansible beantworten und durfte positives Feedback entgegennehmen. Lieben Dank an meine Hörerinnen und Hörer. Es war mir ein Fest, vor euch sprechen zu dürfen.

Viel Zeit zum Ausruhen gab es nicht, denn um 13:00 Uhr erläuterten Dirk, Sujeevan und ich, warum man nicht in der IT arbeiten sollte und warum wir es trotzdem tun (Link zur Aufzeichnung). Ich glaube, das Publikum im gut gefüllten Hörsaal V5 hatte Spaß mit uns. :-)

Auch nach diesem Vortrag durften wir einiges an positivem Feedback entgegennehmen und haben Fragen beantwortet. Ich wiederhole mich gern: „Es war mir auch diesmal ein Fest.“ :-)

Fazit

Danke an das Veranstaltungs-Team der Chemnitzer Linux-Tage für die Ausrichtung dieser großartigen Veranstaltung und auch allen Besucherinnen und Besuchern, dass sie diese Konferenz zu einem der schönsten Community-Treffen in Deutschland machen. Ich freue mich schon heute auf ein Wiedersehen im nächsten Jahr!

Dank der Deutschen Bahn habe ich die Rückreise nicht entspannt im Zug, sondern in einem Mietwagen zurückgelegt. Doch dieses Ärgernis soll das schöne Wochenende nicht trüben.

Wie hat euch die Veranstaltung insgesamt gefallen? Welche Vorträge oder Workshops habt ihr besucht und wie fandet ihr sie? Schreibt mir eure Erfahrungen gern in die Kommentare oder hinterlasst einen Link zu eurem Erfahrungsbericht. Dann freue ich mich. :-)

RHEL System Roles: sshd

In Teil 4 meiner losen Reihe über die RHEL System Roles stelle ich die Ansible-Rolle sshd vor. Diese dient der Konfiguration des OpenSSH-Servers, einem der wichtigsten Dienste in Linux- und UNIX-Systemen.

Wer die ersten Teile dieser Reihe gelesen hat, ist inzwischen mit der grundsätzlichen Anwendung dieser Ansible-Rollen vertraut. Die Rolle sshd bildet hier keine Ausnahme. Wendet man die Rolle ohne weitere Konfiguration auf Ziel-Systeme an, konfiguriert sie den OpenSSH-Server entsprechend der Standard-Konfiguration des jeweiligen Betriebssystems. Es werden alle Optionen der sshd_config(5) unterstützt.

Ein Wort der Warnung: Mit dieser Rolle konfiguriert ihr den SSH-Dienst der Zielsysteme. Wenn dabei ein Fehler passiert, könnt ihr euch und euren Ansible-Controller aussperren und verliert ggf. den Zugriff auf die Systeme. Behaltet dies bitte im Hinterkopf und sorgt ggf. für alternative Zugänge, wie z.B. über eine lokale Konsole.

Bei der Konfiguration meiner Server ist mir persönlich wichtig, dass

  • der Benutzer root sich nur mittels SSH-Public-Key-Verfahren anmelden kann,
  • die Public-Key-Authentifizierung aktiviert ist,
  • die Passwort-Authentifizierung deaktiviert ist und
  • in der Datei .ssh/authorized_keys des jeweiligen Benutzers nach dem SSH-Public-Key gesucht wird.

Darüber hinaus möchte ich alle Git-bezogenen Umgebungsvariablen (GIT_*) nutzen. Die übrigen Einstellungen möchte ich auf den Standard-Werten des jeweiligen Betriebssystems belassen.

Im Folgenden beschreibe ich, wie sich diese mit der RHEL System Role sshd umsetzen lässt.

Voraussetzungen

Wie bei allen RHEL System Roles müssen auch hier die Pakete ansible-core und rhel-system-roles inkl. ihrer Abhängigkeiten auf dem Ansible-Controller installiert sein. Der Ansible-Controller muss die Ziel-Hosts über SSH erreichen können und über einen Benutzer mit sudo-Berechtigungen verfügen.

Das Playbook

Es werden bereits zwei Beispiel-Playbooks mitgeliefert, die sich im Pfad /usr/share/doc/rhel-system-roles/sshd/ befinden. Diese heißen:

  • example-accept-env-playbook.yml und
  • example-root-login-playbook.yml.

Aus diesen beiden Beispieldateien habe ich das folgende Playbook für meine Labor-Umgebung erstellt:

---
- hosts: all
  tasks:
  - name: Configure sshd to accept some useful environment variables
    include_role:
      name: rhel-system-roles.sshd
    vars:
      sshd:
        PermitRootLogin: without-password
        PasswordAuthentication: no
        PubkeyAuthentication: yes
        AuthorizedKeysFile: .ssh/authorized_keys
        # there are some handy environment variables to accept
        AcceptEnv:
          LANG
          LS_COLORS
          EDITOR
          GIT_*

Wie zu sehen ist, habe ich mich entschieden, noch ein paar weitere Umgebungsvariablen zu konfigurieren. Diese habe ich aus dem Beispiel example-accept-env-playbook.yml übernommen.

Testlauf in Labor-Umgebung

Auch dieses Playbook habe ich in meiner Labor-Umgebung, bestehend aus einem RHEL8-Ansible-Controller und jeweils einem rhel{7..9}-Client laufen lassen. Mit den Optionen -C -D ist die Ausgabe 707 Zeilen lang, weswegen der folgende Code-Block nur den Aufruf und das Ergebnis zeigt.

[root@ansible-ctrl ansible]# ansible-playbook sshd_config.yml -C -D

PLAY [all] ************************************************************************************************************
[...]
PLAY RECAP *******************************************************************************************************************************
ansible-pctrl              : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel7                      : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel8                      : ok=20   changed=2    unreachable=0    failed=0    skipped=13   rescued=0    ignored=0   
rhel9                      : ok=21   changed=2    unreachable=0    failed=0    skipped=12   rescued=0    ignored=0

Zusammenfassung

Die RHEL System Role sshd wurde kurz vorgestellt und genutzt, um meine bevorzugten Einstellungen für den OpenSSH-Dienst in meiner Labor-Umgebung zu konfigurieren. Alle Optionen in der sshd_config(5), welche ich nicht explizit über die Ansible-Rolle konfiguriert habe, werden auf die Standardwerte des Betriebssystems eingestellt. Es ist also ggf. Vorsicht geboten, wenn Systeme mit bestehender Konfiguration bearbeitet werden.

Selbstverständlich schützt ein einmaliger Playbook-Lauf nicht davor, dass ein Benutzer mit root-Berechtigungen lokale Änderungen an der Datei /etc/ssh/sshd_config vornimmt. Dies mag vorübergehend für Tests auch so gewollt sein. Damit die Konfiguration nicht dauerhaft vom SOLL-Zustand abweicht, kann man das Playbook regelmäßig durch cron(8) ausführen lassen, um evtl. Abweichungen zu korrigieren.

Quellen und weiterführende Links

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: firewall

Meine neue berufliche Herausforderung in 2023

Wenn dieser Artikel erscheint, habe ich das Bielefelder IT-Service-Zentrum (BITS) der Universität Bielefeld und damit den öffentlichen Dienst nach acht Jahren verlassen. Seit dem 1. März arbeite ich als Senior Technical Account Manager – Platforms für die Red Hat GmbH in München. Ja, ich bin jetzt tatsächlich auf dem besten Weg, ein echter Red Hatter zu werden.

Warum?

Seit 2016 arbeite ich beruflich mit Red Hat Enterprise Linux (RHEL). Und seit 2019 bin ich stolz, zu den Red Hat Accelerators zu gehören. Beruflich habe ich mich jedoch nicht nur um Linux gekümmert.

Es fielen noch etliche weitere Themen in meinen Aufgabenbereich. In mir wuchs jedoch der Wunsch, meinen beruflichen Schwerpunkt in Richtung Linux und Open Source zu verlagern. So ist meine Motivation zum Jobwechsel, dass ich nun in einem Unternehmen arbeite, wo ich von Linux- und Open-Source-Experten umgeben bin. Hier kann ich jeden Tag mit und an Technologien arbeiten, die mich interessieren und meinen Kunden dabei helfen, diese in ihrem Umfeld optimal einzusetzen. Darüber hinaus habe ich hier die besten Chancen, mein Wissen zu erweitern und zu vertiefen. Dies freut mich sehr.

Hey, ich tue Dinge für und mit Open Source und werde dafür bezahlt. Was kann sich ein Linux-Nerd denn mehr wünschen?

Was ändert sich für das BITS?

Na hoffentlich nichts. :-)

Ich hoffe, dass ich euch in guter Erinnerung bleibe und euch von Zeit zu Zeit besuchen darf. Ich beobachte übrigens den Mensaplan. Wenn mal wieder der Burrito mit Wedges auf dem Speiseplan steht, begleite ich die Post-Pandemische-Peer-Group-01 gern zum Essen. ;-)

Was ändert sich für Red Hat?

Ich hoffe, dass durch meine Anstellung nicht gleich ein Ruck durch das ganze Unternehmen geht. Mein Team hat mit mir jetzt ein Mitglied mehr, welches neugierig ist, jeden Tag dazulernen möchte und bereit ist, euch mit Fragen zu löchern.

Habt vielen Dank für den tollen Empfang und die Aufnahme in den ersten Tagen. Ich freue mich auf die weitere Zusammenarbeit mit euch und darauf noch viele weitere Kolleg*innen kennenzulernen.

Was ändert sich für My-IT-Brain?

Hier ändert sich auch nichts. Dies ist und bleibt mein persönlicher Blog, in dem ich meine Meinung zu allen Themen schreibe, die mich interessieren. Die Artikel spiegeln dabei meine persönlichen Ansichten wider. Diese können mit denen meines Arbeitgebers übereinstimmen, müssen dies aber nicht.

Evtl. wird es hier in der nächsten Zeit ruhiger, während ich mich voll und ganz auf das Onboarding bei Red Hat konzentriere. In Zukunft dürft ihr aber wieder mit Artikeln, Anleitungen und Wochenend-Projekten rund um Linux und Open Source rechnen.

Wenn sich die Artikel zukünftig thematisch stärker mit RHEL und Fedora beschäftigen, liegt dies schlicht daran, dass ich mich mit diesen Distributionen stärker beschäftige als mit anderen. Berufliches und privates Interesse liegen bei mir schon immer eng beieinander.

Jetzt stürze ich mich ins Onboarding und versuche, so viel wie möglich von dieser neuen Welt im ersten Anlauf aufzunehmen. Bis neulich. :-)

RHEL System Roles: timesync

In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.

Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.

Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.

Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.

Voraussetzungen

Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.

Das Playbook

Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.

[root@ansible-ctrl ]# cp /usr/share/doc/rhel-system-roles/timesync/example-multiple-ntp-servers-playbook.yml ansible/use_de_ntp_servers.yml

Das Playbook sieht nach der Anpassung wie folgt aus:

- hosts: all
  vars:
    timesync_ntp_servers:
      - hostname: 0.de.pool.ntp.org
        iburst: yes
      - hostname: 1.de.pool.ntp.org
        iburst: yes
      - hostname: 2.de.pool.ntp.org
        iburst: yes
      - hostname: 3.de.pool.ntp.org
        iburst: yes
  roles:
    - rhel-system-roles.timesync

Testlauf in Labor-Umgebung

Um zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.

Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.

Zusammenfassung

Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.

Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: sshd
  7. RHEL System Roles: firewall

Vorfreude auf die Chemnitzer Linux-Tage 2023

Im März ist es endlich wieder soweit. Die Chemnitzer Linux-Tage laden am 11. und 12. März in das Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz ein.

Nach den Online-Konferenzen der letzten Jahre, mit denen ich nicht wirklich warm geworden bin, freue ich mich sehr darauf, Open Source begeisterte Menschen wieder vor Ort treffen zu können.

Das Programm bietet dieses Jahr 90 Vorträge in sechs parallelen Tracks, neun Workshops und ein spezielles Junior-Programm.

Ich selbst bin dieses Jahr mit zwei Vorträgen am Sonntag vertreten. Dirk, Sujeevan und ich werden euch gemeinsam bewusst machen „Warum man nicht in der IT arbeiten sollte und warum wir es trotzdem tun.“ In meinem Vortrag „Einstieg in die Automatisierung mit Ansible“ geht es darum, dass Konzepte wie Automatisierung und Konfigurationsmanagement nicht nur in die Werkzeugkästen für Hyperscaler gehören, sondern wie sie jedem Sysadmin die tägliche Arbeit erleichtern und der gesamten Organisation von Nutzen sein können.

Als passionierter Autofahrer setze ich dieses Jahr mein Vertrauen in die Bahn, welche mich am Freitag nach Chemnitz und am Sonntag wieder heim bringen soll. Ihr werdet in meinem Konferenzbericht lesen, wie mir diese Erfahrung gefallen haben wird.

So alles klappt, sehen wir uns in Karl-Marx-Stadt.

RHEL System Roles: selinux

Dies ist Teil 2 meiner kleinen Serie zu den RHEL System Roles. Ich beschreibe hierin, wie die Ansible-Rolle selinux genutzt werden kann, um Einstellungen für SELinux auf mehreren/allen Hosts in der eigenen Infrastruktur zu konfigurieren.

Die Anforderung dies zu tun, lässt sich bspw. aus den IT-Grundschutzbausteinen SYS.1.3.A10, SYS.1.3.A16, SYS.2.3.A8 und SYS.2.3.A17 des BSI [2] ableiten.

Falls euch SELinux noch nichts sagt, schaut zuerst in meine Einführung in das grundlegende Konzept von SELinux [1].

In dem folgenden und zugegeben sehr einfachen Beispiel nutze ich ein Playbook, welches sicherstellt, dass SELinux auf allen Ziel-Hosts im Modus Enforcing läuft. Dieses Playbook kann ich dann bspw. durch cron(8) in regelmäßigen Abständen laufen lassen, um sicherzustellen, dass sich SELinux im gewünschten Modus befindet bzw. in diesen zurückversetzt wird.

Voraussetzungen

Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.

Das Playbook

Die Dokumentation zu dieser Ansible-Rolle befindet sich in /usr/share/doc/rhel-system-roles/selinux/README.md. Darin enthalten ist auch ein Code-Beispiel, aus dem ich das folgende Playbook erstellt habe:

---
- name: Enforce SELinux Policy
  hosts: all
  vars:
    selinux_policy: targeted
    selinux_state: enforcing
  roles:
    - role: rhel-system-roles.selinux
      become: true

Testlauf in der Laborumgebung

Der erste Code-Block gibt die Ausgabe des Playbook-Laufs wieder. Der zweite Code-Block zeigt ein Ansible-Ad-Hoc-Kommando, mit dem ich kontrolliere, ob Ansible auf allen Ziel-Hosts im Enforcing-Modus läuft.

[root@ansible-ctrl ansible]# pwd
/root/ansible
[root@ansible-ctrl ansible]# ansible-playbook enfoce_selinux.yml 

PLAY [Enforce SELinux Policy] **************************************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [rhel7]
ok: [rhel8]
ok: [rhel9]
ok: [ansible-pctrl]

TASK [rhel-system-roles.selinux : Set ansible_facts required by role and install packages] *************
included: /usr/share/ansible/roles/rhel-system-roles.selinux/tasks/set_facts_packages.yml for ansible-pctrl, rhel7, rhel8, rhel9

TASK [rhel-system-roles.selinux : Ensure ansible_facts used by role] ***********************************
skipping: [rhel7]
skipping: [ansible-pctrl]
skipping: [rhel9]
skipping: [rhel8]

TASK [rhel-system-roles.selinux : Install SELinux python2 tools] ***************************************
skipping: [ansible-pctrl]
skipping: [rhel8]
skipping: [rhel9]
ok: [rhel7]

TASK [rhel-system-roles.selinux : Install SELinux python3 tools] ***************************************
skipping: [rhel7]
ok: [ansible-pctrl]
ok: [rhel9]
ok: [rhel8]

TASK [rhel-system-roles.selinux : refresh facts] *******************************************************
ok: [rhel7]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel8]

TASK [rhel-system-roles.selinux : Install SELinux tool semanage] ***************************************
skipping: [rhel7]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel8]

TASK [rhel-system-roles.selinux : Set permanent SELinux state if enabled] ******************************
ok: [rhel7]
ok: [rhel9]
ok: [rhel8]
ok: [ansible-pctrl]

TASK [rhel-system-roles.selinux : Set permanent SELinux state if disabled] *****************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Set selinux_reboot_required] *****************************************
ok: [ansible-pctrl]
ok: [rhel9]
ok: [rhel7]
ok: [rhel8]

TASK [rhel-system-roles.selinux : Fail if reboot is required] ******************************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Warn if SELinux is disabled] *****************************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Drop all local modifications] ****************************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Purge all SELinux boolean local modifications] ***********************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Purge all SELinux file context local modifications] ******************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Purge all SELinux port local modifications] **************************
skipping: [rhel7]
skipping: [ansible-pctrl]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Purge all SELinux login local modifications] *************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

TASK [rhel-system-roles.selinux : Set SELinux booleans] ************************************************

TASK [rhel-system-roles.selinux : Set SELinux file contexts] *******************************************

TASK [rhel-system-roles.selinux : Restore SELinux labels on filesystem tree] ***************************

TASK [rhel-system-roles.selinux : Restore SELinux labels on filesystem tree in check mode] *************

TASK [rhel-system-roles.selinux : Set an SELinux label on a port] **************************************

TASK [rhel-system-roles.selinux : Set linux user to SELinux user mapping] ******************************

TASK [rhel-system-roles.selinux : Get SELinux modules facts] *******************************************
ok: [rhel8]
ok: [rhel9]
ok: [ansible-pctrl]
ok: [rhel7]

TASK [rhel-system-roles.selinux : include_tasks] *******************************************************
skipping: [ansible-pctrl]
skipping: [rhel7]
skipping: [rhel8]
skipping: [rhel9]

PLAY RECAP *********************************************************************************************
ansible-pctrl              : ok=8    changed=0    unreachable=0    failed=0    skipped=17   rescued=0    ignored=0   
rhel7                      : ok=7    changed=0    unreachable=0    failed=0    skipped=18   rescued=0    ignored=0   
rhel8                      : ok=8    changed=0    unreachable=0    failed=0    skipped=17   rescued=0    ignored=0   
rhel9                      : ok=8    changed=0    unreachable=0    failed=0    skipped=17   rescued=0    ignored=0   

[root@ansible-ctrl ansible]#
[root@ansible-ctrl ansible]# ansible -m command -a'getenforce' all
rhel7 | CHANGED | rc=0 >>
Enforcing
rhel8 | CHANGED | rc=0 >>
Enforcing
ansible-pctrl | CHANGED | rc=0 >>
Enforcing
rhel9 | CHANGED | rc=0 >>
Enforcing

Zusammenfassung

Mit einem sehr einfachen Beispiel habe ich gezeigt, wie die RHEL System Role SELinux genutzt werden kann, um sicherzustellen, dass SELinux auf allen Ziel-Hosts im Enforcing-Modus läuft.

Dazu habe ich keine Zeile Ansible-Code selbst geschrieben. Den Quelltext für mein Playbook habe ich per Copy-Paste-and-Modify aus der mitgelieferten Dokumentation übernommen. Anschließend habe ich die notwendige Variable definiert und das Playbook ausgeführt. Fertig.

  1. BSI IT-Grundschutz-Kompendium 2022
  2. Einführung in das grundlegende Konzept von SELinux
  3. Quelltext im Upstream-Projekt {en}
  4. Red Hat Enterprise Linux (RHEL) System Roles {en}
  5. Ansible Documentation: Role Directory Structure {en}
  6. Red Hat Software and Download Center {en}
  7. Die Vorteile einer Red Hat Subskription
  8. RHEL System Roles: timesync
  9. RHEL System Roles: sshd
  10. RHEL System Roles: firewall

Vorstellung der Red Hat Enterprise Linux (RHEL) System Roles

In diesem Artikel möchte ich euch die RHEL System Roles vorstellen. Er bildet den Beginn einer losen Artikelserie, welche in die einzelnen Rollen einführt und deren Nutzung beispielhaft darstellt.

Dieser Artikel gibt Antworten auf die folgenden Fragen:

  1. Was sind RHEL System Roles?
  2. Für wen sind RHEL System Roles gedacht?
  3. Wie nutzt man RHEL System Roles?
  4. Wie geht es nach diesem Artikel weiter?

Was sind RHEL System Roles?

Die RHEL System Roles sind eine Sammlung von Ansible-Rollen [2]. Sie stellen eine stabile Konfigurations-Schnittstelle bereit, um mehrere RHEL-Releases verwalten und konfigurieren zu können.

Sie leiten sich aus dem Upstream-Projekt Linux System Roles ab, welches die Distributionen CentOS (6+), Fedora und RHEL (6+) unterstützt.

Für wen sind RHEL System Roles gedacht?

Die RHEL System Roles sollen Systemadministratoren bei weit verbreiteten Anwendungsfällen unterstützen. Dazu zählen z.B. die Konfiguration von Server-Diensten wie SSH, Postfix, Zeitsynchronisation und SELinux sowie Netzwerkschnittstellen, Firewallregeln, etc.

Möchte ein Admin z.B. seine Server dafür konfigurieren, dass sie sich alle mit den gleichen Zeitservern synchronisieren, kann er dafür die Rolle timesync nutzen. Dabei müssen sich Admins nicht mit Implementierungsdetails oder der Frage beschäftigen, ob die Zielsysteme ntp oder chrony als Dienst für die Synchronisierung verwenden. Sie definieren lediglich Werte für die Variablen der Ansible-Rolle und überlassen die Details dem Konfigurationsmanagement (Ansible).

Die Rollen können direkt genutzt werden. Der Aufwand zur Erstellung und Test der eigenen Rollen entfällt bzw. wird stark reduziert.

Wie nutzt man RHEL System Roles?

Besitzer einer RHEL-Subskription [4] können das Paket rhel-system-roles auf ihrem Ansible Controller installieren. Dies kann aus den Repositorien RHEL 7 Extras bzw. den Application Streams für RHEL 8 und RHEL 9 installiert werden (vgl [1]).

Beispiel für RHEL 8 und RHEL 9:

# dnf install rhel-system-roles

Anschließend findet man die Dokumentation zu den einzelnen Rollen im Pfad /usr/share/doc/rhel-system-roles/<ROLLENNAME>/README.md. Neben dem README findet man auch einige Beispiel-Playbooks.

Die Rollen selbst liegen nach der Installation im Verzeichnis /usr/share/ansible/roles/rhel-system-roles.<ROLLENNAME>. Da sich die RHEL System Roles an die Role Directory Structure halten, findet sich auch hier eine README.md-Datei mit der Dokumentation zur Rolle.

Beispiel für Fedora:

# dnf install linux-system-roles

Hier befindet sich die Dokumentation im Pfad /usr/share/doc/linux-system-roles/<ROLLENNAME> und die Rollen selbst in /usr/share/ansible/roles/linux-system-roles.<ROLLENNAME>.

Darüber hinaus kann man sich die Rollen auch von Ansible Galaxy herunterladen.

Damit sind die Vorbereitungen abgeschlossen und man kann mit der Nutzung beginnen. Der folgende Codeblock zeigt dazu das Beispiel eines Playbooks zur Konfiguration von NTP auf einer Gruppe von Hosts (Inhalt der Variable targets):

- hosts: "{{ targets }}"
  vars:
    timesync_ntp_servers:
      - hostname: 2.pool.ntp.org
        pool: yes
        iburst: yes
  roles:
    - rhel-system-roles.timesync

Wie geht es nach diesem Artikel weiter?

Um mich selbst mit den RHEL System Roles vertraut zu machen, werde ich mir nach und nach eine Rolle herauspicken, diese in einem separaten Artikel kurz vorstellen und in meiner Labor-Umgebung einsetzen.

Die Labor-Umgebung besteht aus einem Ansible-Controller basierend auf RHEL 8 mit den Paketen ansible-core in Version 2.13.3 und rhel-system-roles in Version 1.20.1. Die genutzten Versionen mögen sich im Laufe der Zeit und in Abhängigkeit zur Verfügbarkeit neuer Releases ändern. Als Remote-Nodes verwende ich jeweils eine virtuelle Maschine mit RHEL 7, 8 und 9. Die Labor-Umgebung selbst provisioniere ich ebenfalls mit Ansible und der Rolle kvm_provision_lab.

Die VMs basieren auf qcow2-Images, welche ich aus dem Red Hat Customer Portal heruntergeladen habe (siehe [3]).

Die weiteren Artikel werde ich nach deren Veröffentlichung im folgenden Abschnitt verlinken, so dass diese auch von hier aus erreichbar sind.

Ich hoffe, dass diese Serie auch für euch nützliche Informationen bereitstellt und freue mich natürlich jederzeit über eure Rückmeldungen dazu.

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: sshd
  8. RHEL System Roles: firewall