Autorenarchiv: Jörg Kastning

Meine neue berufliche Herausforderung in 2023

6 Antworten

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

2 Antworten

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

1 Antwort

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

6 Antworten

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

3 Antworten

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

Meine privaten Arbeitsmittel 2023

1 Antwort

Dies ist ein Update des Artikels aus dem letzten Jahr.

Smartphone

Mein Sony Xperia XZ2 Compact musste aufgrund mehrerer Macken ersetzt werden. Mein neuer Begleiter ist nun ein Samsung Galaxy S22. Zwar habe ich mir auch ein Fairphone angesehen, doch ist mir dieses einfach viel zu groß. Nutzungsänderungen ergaben sich lediglich bei den Messenger-Diensten und den sozialen Netzwerken:

  • Für Chat und Kurznachrichten mit Matrix über Element (dienstlich)/neu: FluffyChat (privat), SMS und Threema (bevorzugt).
  • Nutzung diverser sozialer Netzwerkwerke wie Facebook, LinkedIn, Mastodon, Twitter und XING; meine Accounts in den gestrichenen Netzwerken habe ich gelöscht.

Tablet

Hier hat sich gegenüber dem Vorjahr nichts verändert.

Laptop

Hier gab es lediglich ein Upgrade auf Fedora 37 und Rambox ist hamsket gewichen.

Desktop-/Server-PC

Auch hier gibt es keine Änderungen gegenüber dem Vorjahr.

Sonstige Geräte im Netzwerk

Unverwüstlich verrichtet mein Brother DCP-540CN weiterhin zuverlässig seinen Dienst. Meine FHEM-Installation hingegen habe ich eingestampft und meinen Pi-Hole auf den Raspberry Pi 1 Rev. B migriert. Damit habe ich wieder einen Pi für neue Basteleien frei.

Zusammenfassung

Viel hat sich hier nicht verändert und ich bin mit dem aktuellen Setup zufrieden. Ob es im Jahr 2023 etwas mehr Veränderungen geben wird, wird sich zeigen.

IPFire oder nicht?

35 Antworten

Hallo liebe Leserinnen und Leser,

in diesem Beitrag möchte ich um eure Meinungen und Gedanken zur Distribution IPFire 2.x und einer dafür erhältlichen Hardware-Appliance bitten.

IST-Zustand

Vereinfachte Struktur des betrachteten Netzwerks

Es existiert ein einfaches Heimnetzwerk, welches über eine Vodafone ConnectBox mit dem Internet verbunden ist. Die Firewall der ConnectBox ist aktiviert und es sind aktuell keinerlei eingehende Verbindungen zugelassen.

Im LAN existieren eine Vielzahl unterschiedlicher Geräte, wie z.B. Access-Points, Pi-Hole, PCs, Laptops, PV-Anlage, Netzwerkdrucker, etc. pp.

SOLL-Zustand

Das bestehende Heimnetzwerk soll in verschiedene Netzwerkzonen unterteilt werden können, welche durch eine Firewall voneinander getrennt sind. Es soll eine Möglichkeit zur VPN-Einwahl geschaffen werden, um von außerhalb des Netzwerks auf Dienste im Heimnetzwerk zugreifen zu können. Der vorhandene Kabelrouter soll nicht ersetzt werden.

Vereinfachte Netzwerkstruktur mit IPFire

Bei der Internet-Recherche bin ich auf IPFire gestoßen, für welche ich als ehemaliger IPCop-Nutzer eine gewisse Sympathie hege. Zudem habe ich mit der IPFire Mini Appliance (EU) ein Gerät im Blick, welches am Aufstellungsort eine gute Figur machen sollte. Mir ist dabei wichtig, dass das Gerät möglichst sparsam bei der Energieaufnahme ist und passiv gekühlt wird, damit im Betrieb keine Geräusche verursacht werden.

Ich möchte die IPFire als Paketfilter, OpenVPN-Gateway und ggf. IPS nutzen.

Ihr seid gefragt

Bevor ich nun ca. 450 Euro investiere, möchte ich die Chance nutzen und nach euren Erfahrungen mit IPFire und den verfügbaren Appliances fragen.

Habt ihr IPFire genutzt oder nutzt sie noch? Seid ihr damit zufrieden, oder würdet ihr zu einer Alternative raten? Wenn Alternative, welche und warum?

Worauf betreibt ihr IPFire? Auf einer Appliance wie der oben verlinkten, einem Raspberry Pi, in einer VM oder auf etwas ganz anderem? Lasst es mich gerne wissen, warum ihr euch für welche Lösung entschieden habt.

Falls ihr jetzt die Hände über dem Kopf zusammenschlagt und ruft: „Nein alles, nur das nicht!“ Dann bin ich natürlich umso mehr an eurer Erfahrung interessiert.

Bitte nutzt die Kommentare oder schreibt mir an „ipfire (aett) my-it-brain (Punkt) de“, wenn ihr eure Gedanken mit mir teilen möchtet.

Quellen und weiterführende Links

Was ich 2022 für/mit FLOSS getan habe

Schreibe eine Antwort

In diesem Artikel führe ich auf, was ich 2022 für bzw. mit FLOSS getan habe. FLOSS steht dabei für Free/Libre Open Source Software. Es geht dabei nicht um weltbewegende Projekte oder große Beiträge. Es ist mehr eine Sammlung von Kleinigkeiten. Dennoch möchte ich diese öffentlich machen, um zu zeigen, was man mit FLOSS tun und wie man sich beteiligen kann.

Ansible-Rolle zum Deployment von Nextcloud und MariaDB in einem Podman Pod

Dieses kleine Projekt ist etwas verrückt und für den Einsatz in Produktion vermutlich nicht geeignet. Doch konnte ich mich gleich mit zwei Themen intensiv beschäftigen, die mich interessieren, Ansible und Podman. Mein Ziel war es, die Anwendungen Nextcloud und MariaDB zur Bereitstellung einer privaten Cloud in einem rootless Podman Pod zu provisionieren. Die ganze Geschichte kann in der kleinen Serie Nextcloud im Container nachgelesen werden.

Die Quellen der Ansible-Rolle gibt es auf:

RHEL-Patchmanagement

Seit 2016 entwickle und pflege ich ein Patch-Management für Red Hat Enterprise Linux Systeme. Dieses Jahr habe ich Release 3.3.0 und 3.3.1 veröffentlicht.

Mit diesem Projekt habe ich ein Patch-Management gebaut, welches sehr gut die Anforderungen meines Arbeitgebers abdeckt und sich ohne Zusatz-Subskriptionen wie das Smart-Management-Addon für RHEL-Subskriptionen realisieren lässt. Seit 2018 läuft es vollautomatisch und stellt sicher, dass verfügbare Sicherheits-Updates mindestens einmal pro Monat installiert werden.

Es erfreut sich auch außerhalb unserer Organisation einiger Beliebtheit:

Drei Ansible-Rollen dank Open Source

Häufig haben Unternehmen/Organisationen sehr individuelle Anforderungen, für die keine fertigen Lösungen von der Stange existieren. Open Source schafft die Möglichkeit, sich selbst helfen zu können. So habe ich ohne großen Aufwand Ansible-Rollen geschrieben, um Proxy-Einstellungen für den subscription-manager und YUM bzw. DNF zu konfigurieren sowie um Red Hat Enterprise Linux registrieren und den System Purpose konfigurieren zu können.

Quellen:

Meine erste Linux System Role

Die Linux System Roles sind eine Sammlung von Ansible-Rollen zur Konfiguration diverser Betriebssystem-Komponenten von Linux. Ziel der Sammlung ist es, Ansible-Rollen zur einfachen Nutzung durch Systemadministratoren bereitzustellen.

Ich habe viel über den Entwicklungsprozess von Ansible-Rollen gelernt, bis meine erste Rolle pam_pwd aufgenommen wurde. Mit dieser Rolle kann PAM konfiguriert werden, um eine Passwort-Richtlinie zu etablieren.

Sie befindet sich noch in einem sehr frühen Stadium. Nutzt sie auf eigene Gefahr. Der Lerneffekt für mich war jedoch sehr groß, so dass sich die Arbeit in meinen Augen gelohnt hat.

Quelle:

Mit Ansible Labor-Umgebungen in KVM und vSphere provisionieren

Ich benötige immer mal wieder Labor-Umgebungen mit frischen Betriebssystem-Installationen für verschiedene Versuche und Tests. Um die Provisionierung dieser Laborumgebung zu vereinfachen und zu beschleunigen, habe ich zwei Ansible-Rollen erstellt, mit denen sich diese Labor-Umgebungen auf KVM- und vSphere-Hypervisoren provisionieren lassen:

Blogs, Issue-Reports Pull-Requests

Man kann FLOSS auch dadurch unterstützen, indem man darüber spricht bzw. schreibt. Letzteres tue ich in diesem Blog. Der My-IT-Brain Jahresrückblick 2022 gibt einen Überblick darüber.

Hinzu kommen kleine Beiträge in Form von Issue-Reports und Pull-Requests. Details kann man meiner Contribution Activity auf Github entnehmen.

Spenden

Viele FLOSS-Projekte werden ohne funktionierendes Geschäftsmodell von Menschen in deren Freizeit entwickelt und gewartet. Diese Projekte sind auf Spenden angewiesen.

Ich setze mir jedes Jahr ein persönliches Budget, aus dem ich an die Projekte spende, deren Anwendungen ich häufig benutze oder die mir besonders sympathisch sind. Das ist nicht immer ganz einfach. Ich persönlich bevorzuge eine Banküberweisung oder eine Einmalzahlung per Kreditkarte. Mich erst bei einem Zahlungsdienstleister anzumelden stellt für mich meist eine zu hohe Hürde dar.

Fazit

Es muss nicht das eine große Projekt sein. Auch mit der Summe kleiner Teile kann man eine Menge erreichen.

FLOSS hat mir geholfen, viele meiner Anforderungen zu erfüllen. Für mich ist es selbstverständlich, die Ergebnisse dieser Arbeit ebenfalls wieder unter einer freien Lizenz zu veröffentlichen, um auf diesem Weg etwas an die FLOSS-Gemeinschaft zurückzugeben. Doch denkt immer daran: „Nutzung auf eigene Gefahr.“