Linux-Systemadministration

1. Kurzfassung

In Modul M01 wurden die zwei Startsysteme des Linux-Kurses gemäß Kursmitschrift aufgebaut und validiert:

• debian13 als schlanke Debian-CLI-/Server-VM ohne grafische Oberfläche.
• rocky9 als Rocky-Linux-9.7-VM mit GUI und RHEL-naher Administrationslogik.

Beide Systeme wurden in Hyper-V bereitgestellt, mit Hostnamen versehen, mit Benutzerkontext geprüft, per Netzwerk validiert und über SSH erreichbar gemacht. Zusätzlich wurden SSH-Verbindungen vom Windows-/RemoteLab-Host zu beiden Systemen sowie von Debian13 zu Rocky9 getestet.

2. Ziel des Moduls

M01 schafft die technische Ausgangsbasis für die folgenden Linux-Module. Dokumentiert sind:

• Installation und Rollenbildung zweier Linux-VMs.
• Unterschied zwischen Debian- und Rocky-/RHEL-nahem Systemkontext.
• Grundvalidierung über Hostname, Distribution, Kernel, Netzwerk, Speicher und Benutzer.
• SSH-Bereitschaft auf beiden Systemen.
• kontrollierte Verbindungstests als Grundlage für spätere Remote-Administration.

3. Kursbasis / Materialbezug

Führende Arbeitsgrundlage für den Einstieg ist die Kursmitschrift mitschrift_kurs.txt. Daraus ergeben sich am Kursanfang zwei relevante VMs:

cl01 wird in M01 nicht verwendet und ist kein Bestandteil des dokumentierten Debian-/Rocky-Basiszustands.

4. Umgebung und Ausgangszustand

5. Durchführung

5.1 Debian13

Die Debian-VM wurde als Generation-2-VM mit Kursnetzwerk, 16-GB-VHDX und Debian-Netinst-ISO vorbereitet. Im Installer wurde bewusst keine Desktopumgebung ausgewählt. Aktiviert wurden nur SSH-Server und Standard-Systemwerkzeuge.

Nach der Installation wurde der Hostname auf debian13 gesetzt. Die Baseline wurde über Standardbefehle geprüft. Der SSH-Dienst wurde über systemctl validiert und Port 22 über ss geprüft.

5.2 Rocky9

Rocky9 wurde als zweite Kurs-VM installiert. Abweichend von Debian wurde hier eine GUI-basierte Installation gewählt, passend zur Kursmitschrift und zur RHEL-/Rocky-Vergleichsrolle. Der Hostname wurde im Installer auf rocky9 gesetzt. Der Benutzer student wurde als administrativer Benutzer angelegt und später über die Gruppe wheel validiert.

Der SSH-Dienst heißt unter Rocky sshd. Er wurde als aktiv und enabled geprüft; Port 22 lauscht auf IPv4 und IPv6.

5.3 SSH-Verbindungstests

Zusätzlich zur Dienstprüfung wurden SSH-Verbindungen getestet:

• Windows-/PowerShell-Client → Debian13
• Windows-/PowerShell-Client → Rocky9
• Debian13 → Rocky9

Die Verbindung Debian13 → Rocky9 wurde mit hostname und whoami auf dem Zielsystem validiert. Zusätzlich zeigten who und w -i auf Rocky9 aktive Remote-Sitzungen und Pseudoterminals.

6. Relevante Befehle / Konfigurationen

hostnamectl
cat /etc/os-release
uname -r
ip -brief a
ip route
df -h /
free -h
lsblk
id
groups

Debian SSH:

systemctl status ssh --no-pager
ss -tulpn | grep :22

Rocky SSH:

systemctl status sshd --no-pager
ss -tulpn | grep :22

Verbindungstest:

ssh student@<debian-ip>
ssh student@<rocky-ip>

Linux-zu-Linux-Test:

ssh student@<rocky-ip>
hostname
whoami
who
w -i

M01 verbindet die folgenden Arbeitsschritte zu einer gemeinsamen Systembasis:

• Systeme werden nicht nur installiert, sondern mit Rollen versehen.
• Hostnamen, Benutzerkontext und Netzwerkstatus werden geprüft.
• Dienste werden mit systemctl validiert.
• Netzwerkdienste werden nicht nur als Dienststatus, sondern auch über Ports geprüft.
• SSH wird als zentrale Remote-Administrationsschnittstelle vorbereitet.
• Unterschiede zwischen Debian und Rocky werden früh sichtbar: ssh vs. sshd, sudo-/wheel-Kontext, CLI- vs. GUI-Installation.

8. Fehler, Abweichungen oder Entscheidungen

Hostname Debian

Nach der Debian-Installation war der interne Hostname zunächst nicht konsistent mit dem VM-Namen. Der Hostname wurde auf debian13 gesetzt, damit Kursmitschrift, Prompt und Dokumentation sauber zusammenpassen.

grep-Tippfehler

Bei der Prüfung von Port 22 wurde zunächst grep:22 statt grep :22 eingegeben. Der Fehler wurde direkt erkannt und korrigiert. Das ist ein kleiner, aber dokumentierbarer Praxispunkt: Shell-Befehle interpretieren fehlende Leerzeichen als anderen Befehl.

SSH-Validierung mit erneutem Login

Nach einem Verbindungstest wurde die SSH-Sitzung mit exit beendet. Anschließend wurde erneut zu Rocky9 verbunden, um hostname und whoami auf dem Zielsystem auszuführen.

Checkpoint-Logik

Es wurden keine unnötigen Checkpoints erstellt. Ein Checkpoint wurde nur dann gesetzt, wenn ein echter persistenter VM-Zustand erreicht war.

9. Validierung / Ergebnisprüfung

11. Erkenntnisse

• VM-Name und Linux-Hostname sind unterschiedliche Ebenen und müssen getrennt geprüft werden.
• Debian und Rocky unterscheiden sich bei Dienstnamen und Administrationsgruppen: ssh vs. sshd, sudo vs. wheel.
• Dienstzustand und Portprüfung mit ss werden gemeinsam ausgewertet.
• Verbindungstests sind Nachweise, aber keine Checkpoint-Gründe.

12. Ergebnis und fachliche Grenze

Die dokumentierten Arbeitsschritte zeigen die VM-Basis sowie die damalige SSH-Erreichbarkeit von Debian und Rocky. Ein aktueller Live-Zustand der Systeme wird daraus nicht abgeleitet.

Architektur und Rollen

Nachweis 1M01

Arbeitsschritte und Nachweise

Nachweis 2M01

Nachweise

Nachweis 3M01

Nachweis 4M01

Nachweis 5M01

Nachweis 6M01

Nachweis 7M01

Nachweis 8M01

Nachweis 9M01

Nachweis 10M01

Nachweis 11M01

Nachweis 12M01

Nachweis 13M01

Nachweis 14M01

Nachweis 15M01

Nachweis 16M01

Nachweis 17M01

Nachweis 18M01

Modul: M02 – Shell, Hilfe, Editor, Dateisystem, Pfade, Links, Dateisuche und Bash-/Terminal-Konfiguration
System: debian13
Benutzer: student

Kurzfassung

M02 dokumentiert die grundlegende Arbeit im Linux-Terminal auf debian13. Im Mittelpunkt standen Benutzerkontext, Navigation im Dateisystem, strukturierte Dateiablage, Dateioperationen, relative und absolute Pfade, symbolische Links, Hilfesysteme, Editorarbeit mit nano und Validierung über cat. Ergänzend wurde die persönliche Bash-Umgebung kontrolliert angepasst: ein persistenter Alias ll='ls -lha' wurde eingerichtet und der Prompt zur besseren Lesbarkeit der Nachweise konfiguriert. Kleine Fehler wie ein falscher absoluter Pfad oder ein fehlendes Leerzeichen bei mkdir -p wurden fachlich als Lernpunkte eingeordnet.

1. Modulkontext und Ausgangslage nach M01

M02 baut auf M01 auf. In M01 wurden die Linux-VMs erstellt und debian13 als CLI-/Server-System per SSH erreichbar gemacht. M02 nutzt diese Basis, erweitert aber keine systemweiten Dienste und benötigt keine Root-Rechte. Der Fokus liegt auf sicherer Terminalarbeit im normalen Benutzerkontext.

Abgrenzung: Paketverwaltung, Rechteverwaltung, Archivierung, SSH-Key-Verwaltung, systemd, Logs und Shell-Scripting gehören bewusst nicht in M02, sondern in spätere Module.

2. Zielsetzung

M02 behandelt die Linux-Grundbedienung in den folgenden Arbeitsschritten:

• Arbeiten als normaler Benutzer auf debian13
• Orientierung im Dateisystem
• strukturierte Ablage im Home-Verzeichnis
• Dateien erstellen, kopieren und verschieben
• relative und absolute Pfade unterscheiden
• symbolische Links erstellen und validieren
• Hilfesysteme und Befehlstypen verwenden
• Dateien mit nano bearbeiten und mit cat validieren
• Bash-Arbeitsumgebung benutzerspezifisch und nachvollziehbar anpassen

Arbeitsschritte und Nachweise

Kontext prüfen → Arbeitsstruktur erstellen → Dateien/Pfade bearbeiten → Symlink validieren → Editorarbeit prüfen → Hilfesysteme nutzen → Bash-Alias und Prompt konfigurieren

Nachweis 19M02

4. System- und Arbeitsumgebung

5. Benutzer- und Arbeitskontext

Ziel

Vor Beginn der Dateisystemübungen musste nachgewiesen werden, dass auf dem richtigen System und im richtigen Benutzerkontext gearbeitet wird.

Für M02 ist der normale Benutzerkontext ausreichend. Das vermeidet unnötige Systemänderungen und zeigt sauberes Arbeiten im Home-Verzeichnis.

Arbeitsschritte und Nachweise:

hostname
whoami
id
pwd

Nachweis

Nachweis 20M02

Nachweis: Der Nachweis zeigt debian13, den Benutzer student, die Gruppeninformationen und das Arbeitsverzeichnis /home/student. Damit ist die Ausgangsbasis von M02 belegt.

Ergebnis

Die Übungen wurden auf dem richtigen Zielsystem und ohne Root-Kontext durchgeführt.

6. Strukturierte Arbeitsumgebung im Home-Verzeichnis

Ziel:

Für M02 wurde eine eigene Arbeitsstruktur unter ~/linux_m02 angelegt.

Eine getrennte Übungsstruktur verhindert ungewollte Änderungen im Home-Verzeichnis und macht die Arbeit reproduzierbar. Die Nutzung von mkdir -p und Brace Expansion zeigt zugleich grundlegende Bash-Funktionalität.

Arbeitsschritte und Nachweise:

mkdir -p ~/linux_m02/{docs,configs,logs,archiv,links}
cd ~/linux_m02
pwd
find ~/linux_m02 -maxdepth 2 -type d

Nachweis:

Nachweis 21M02

Nachweis: Der Screenshot zeigt den Modulordner mit den Unterordnern docs, configs, logs, archiv und links.

Ergebnis:

Die strukturierte Arbeitsumgebung für M02 wurde erfolgreich erstellt und mit find validiert.

7. Dateioperationen und Pfadverständnis

Ziel:

Grundlegende Dateioperationen sollten praktisch nachgewiesen werden: Dateien erstellen, kopieren, verschieben und über Pfade adressieren.

Dateioperationen sind Grundlage fast aller späteren Linux-Administrationsaufgaben: Konfigurationsdateien bearbeiten, Logs prüfen, Dateien sichern oder Inhalte in Arbeitsverzeichnissen organisieren.

Arbeitsschritte und Nachweise:

touch docs/notizen.txt configs/beispiel.conf logs/m02_test.log
cp docs/notizen.txt archiv/notizen_backup.txt
mv logs/m02_test.log logs/m02_shell_dateisystem.log
find ~/linux_m02 -maxdepth 3 -type f

Nachweis:

Nachweis 22M02

Nachweis: Der Nachweis zeigt cp, mv und die abschließende Dateiliste. Damit sind Erstellen, Kopieren und Umbenennen/Verschieben belegt.

Ergebnis:

Die Dateien wurden kontrolliert im Modulordner erzeugt und organisiert. Die erzeugte Dateiliste zeigt den erwarteten Zustand.

Erkenntnisse und Hinweise

Ein fehlerhafter Zwischenstand mit find /linux_m02 wurde erkannt und korrigiert. Der Unterschied ist fachlich wichtig: /linux_m02 meint ein Verzeichnis direkt unter /; korrekt war ~/linux_m02 im Home-Verzeichnis.

8. Relative und absolute Pfade sowie symbolische Links

Ziel:

Das Modul sollte zeigen, dass eine Datei sowohl relativ als auch absolut adressiert werden kann und dass symbolische Links korrekt verstanden werden.

Pfade und symbolische Links sind im Linux-Dateisystem zentral. Gerade Systemverzeichnisse wie /bin, /sbin oder /lib sind in modernen Distributionen häufig selbst symbolische Links.

Arbeitsschritte und Nachweise:

ls -l docs/notizen.txt
ls -l /home/student/linux_m02/docs/notizen.txt
ln -s ../docs/notizen.txt links/notizen_link.txt
ls -l links/

Nachweis:

Nachweis 23M02

Nachweis: Der Screenshot zeigt die Datei notizen.txt über relativen und absoluten Pfad sowie den korrigierten symbolischen Link notizen_link.txt -> ../docs/notizen.txt.

Ergebnis:

Der symbolische Link zeigt korrekt auf die Datei im Ordner docs. Das Linkziel wurde relativ zum Speicherort des Links interpretiert.

Erkenntnisse und Hinweise:

Beim Erzeugen symbolischer Links ist der Bezugspunkt entscheidend. Da der Link im Ordner links liegt, ist ../docs/notizen.txt das korrekte Ziel.

9. Editorarbeit und Validierung

Ziel:

Eine Textdatei sollte mit nano bearbeitet und anschließend über Originalpfad und symbolischen Link validiert werden.

Editorarbeit im Terminal ist Vorbereitung für spätere Module, in denen Konfigurationsdateien angepasst werden. Der reine Editor-Screenshot reicht nicht; die Änderung muss anschließend geprüft werden.

Arbeitsschritte und Nachweise:

nano docs/notizen.txt
cat docs/notizen.txt
cat links/notizen_link.txt

Nachweis:

Nachweis 24M02

Nachweis: Der Nachweis zeigt denselben Inhalt über docs/notizen.txt und über links/notizen_link.txt. Damit sind Editorarbeit, Speicherung und Symlink-Funktion validiert.

Ergebnis:

Die Datei wurde erfolgreich bearbeitet. Der symbolische Link zeigt funktional auf dieselbe Datei.

10. Hilfequellen und Befehlstypen

Ziel:

Das Modul sollte zeigen, dass Hilfesysteme und Befehlstypen zur eigenständigen Orientierung genutzt werden können.

In der Linux-Praxis ist es nicht realistisch, alle Optionen auswendig zu kennen. Entscheidend ist, Hilfen wie --help, Manpages und Bash-Builtin-Hilfen gezielt zu verwenden.

Arbeitsschritte und Nachweise:

ls --help | head
type cd
which ls
man ls

Nachweis:

Nachweis 25M02

Nachweis: Der Nachweis zeigt die Kurz-Hilfe von ls, identifiziert cd als Shell-Builtin und zeigt /usr/bin/ls als externes Programm.

Ergebnis:

Es wurde nachvollzogen, dass nicht jeder Befehl ein externes Programm ist. cd ist in die Bash integriert, während ls als Binärprogramm im Dateisystem liegt.

11. Bash-/Terminal-Konfiguration

Ziel:

Die persönliche Bash-Arbeitsumgebung sollte kontrolliert angepasst werden, ohne globale Systemdateien zu verändern.

Die Kursmitschrift behandelt Bash, Prompt, History, .bashrc, .bashrc.d und persistente Konfigurationen. Die Umsetzung in M02 orientierte sich daran, wurde aber bewusst begrenzt: Es wurden ein sinnvoller Alias und ein besser lesbarer Prompt eingerichtet. Eine dauerhafte PATH-Änderung oder umfangreiche History-Optimierung wurde nicht durchgeführt.

11.1 Alias ll='ls -lha'

nano ~/.bash_aliases
source ~/.bash_aliases
cat ~/.bash_aliases
type ll
ll ~/linux_m02

Nachweis 26M02

Nachweis: Der Nachweis zeigt die Alias-Datei ~/.bash_aliases, die Alias-Definition und die erfolgreiche Ausführung von ll ~/linux_m02.

11.2 Persistenztest des Alias

bash
type ll
ll ~/linux_m02
exit

Nachweis 27M02

Nachweis: Der Nachweis zeigt, dass der Alias auch in einer neu gestarteten Bash-Sitzung verfügbar ist.

11.3 Modulare Prompt-Konfiguration über .bashrc.d

Vor der Änderung wurde .bashrc gesichert. Danach wurde ~/.bashrc.d als modularer Konfigurationsordner eingebunden und eine eigene Prompt-Datei erstellt.

cp ~/.bashrc ~/.bashrc.bak_m02
mkdir -p ~/.bashrc.d
nano ~/.bashrc
nano ~/.bashrc.d/bash_prompt
source ~/.bashrc

Nachweis 28M02

Nachweis: Der Screenshot zeigt die Einbindung von ~/.bashrc.d/* in .bashrc.

Nachweis 29M02

Nachweis: Der Screenshot zeigt die Datei ~/.bashrc.d/bash_prompt mit der PS1-Definition.

Nachweis 30M02

Nachweis: Der Screenshot zeigt den neuen Prompt mit History-Nummer und weiterhin funktionierendem Alias ll.

Ergebnis:

Die Bash-Konfiguration wurde benutzerspezifisch, modular und nachvollziehbar angepasst. Der Prompt wurde lesbarer, ohne die Systemkonfiguration global zu verändern. Der Alias ll verbessert die praktische Arbeit mit Dateilisten und wurde persistent validiert.

Erkenntnisse und Hinweise:

• Vor Änderungen an .bashrc ist ein Backup sinnvoll.
• Prompt-Farben sind nicht nur optisch: In diesem Fall verbessern sie die Lesbarkeit der Screenshots.
• Konfigurationen im Benutzerprofil sind für M02 angemessen; globale Dateien wie /etc/profile wären unnötig riskant.

12. Fehler, Korrekturen und Entscheidungen

13. Zusammenfassung

Die dokumentierten Arbeitsschritte zeigen Terminalbedienung, Dateisystemorientierung, Hilfesystemnutzung, Editorarbeit und eine kontrollierte Bash-Konfiguration im Benutzerkontext.

14. Abgrenzung

M02 enthält bewusst nicht:

• Paketverwaltung mit apt
• Archivierung/Restore mit tar/gzip
• Rechteverwaltung mit chmod, chown, umask
• SSH-Key-Verwaltung, scp, sftp, rsync
• Prozesse, systemd, Dienste oder Logs
• Shell-Scripting und Scheduling
• produktive Sicherheits- oder Härtungsmaßnahmen

Diese Themen sind nicht Bestandteil von M02. Alias und Prompt wurden als eigene dokumentierte Umsetzung erstellt; die Trainerdateien bash_prompt und bash_variables wurden nicht 1:1 übernommen.

Modul: M03 – Textströme, Pipes, Filter, Redirects, Reports, Archivierung und Restore

1. Kurzfassung

In M03 wurde eine strukturierte Linux-Arbeitsumgebung aufgebaut, um kontrollierte Logdaten und echte Systeminformationen mit Shell-Werkzeugen auszuwerten. Die Auswertung nutzte grep, reguläre Ausdrücke, cut, sort, uniq, wc, Pipes, tee sowie stdout-/stderr-Redirects. Anschließend wurden die Ergebnisse in einem Modulreport zusammengeführt, mit tar.gz archiviert, wiederhergestellt und per diff_exit_code=0 validiert.

Die Arbeitsschritte bauen nachvollziehbar aufeinander auf: Arbeitsstruktur → Datenbasis → Filteranalyse → Pipelines → Report-Erstellung → Archivierung → Restore → Integritätsprüfung. Verwendet wurden kontrollierte Übungsdaten und ergänzende Systeminformationen der Debian-VM; eine Analyse produktiver Logdaten wird daraus nicht abgeleitet.

2. Rolle von M03 im Linuxkurs

M03 verbindet mehrere Linux-Werkzeuge zu einer gemeinsamen Admin-Auswertung: Textausgaben, Logausgaben und Dienststatus werden kombiniert gefiltert, gespeichert und ausgewertet.

Für den weiteren Kurs bildet M03 die Grundlage für spätere Module zu Benutzerverwaltung, Paketmanagement, systemd, Logs, Netzwerk/SSH, Troubleshooting und Automatisierung. Pipes, Redirects, Variablen und Reports sind Basistechniken, die dort wiederverwendet werden.

Arbeitsablauf

Arbeitsstruktur
→ kontrollierte Logdaten und echte Baseline-Daten
→ Filteranalyse mit grep/cut/sort/uniq/wc
→ Pipelines und tee-Reports
→ stdout/stderr-Redirects
→ Variablen, Globbing und Modulreport
→ tar.gz-Archivierung
→ Restore in separates Verzeichnis
→ diff-Integritätsprüfung

Die Ergebnisse wurden erzeugt, gespeichert, geprüft und interpretiert.

4. Arbeitsstruktur und Datenbasis

Ziel

Für M03 wurde unter ~/linux_m03 eine saubere Arbeitsstruktur mit getrennten Bereichen für Rohdaten, Reports, Archive, Restore-Tests und Notizen erstellt.

Die Trennung von daten, reports, archive, restore und notes ist keine reine Ordnungssache. Sie verhindert, dass Eingabedaten, erzeugte Ergebnisse und Restore-Daten vermischt werden. Gerade bei Dokumentations- und Troubleshooting-Aufgaben ist diese Trennung wichtig, weil später nachvollziehbar bleiben muss, welche Datei Ausgangsmaterial, Zwischenergebnis oder Validierungsnachweis ist.

Die Datei system_events.log wurde bewusst als kontrollierte Übungslogdatei erstellt. Das ist pädagogisch sinnvoll: Kontrollierte Eingaben führen zu erwartbaren Ausgaben. Dadurch lässt sich prüfen, ob Filter, reguläre Ausdrücke, Zählungen und Pipelines tatsächlich korrekt arbeiten. Gleichzeitig wurden echte Systemdaten der Debian-VM erfasst, damit M03 nicht nur aus synthetischen Daten besteht.

Arbeitsschritte und Nachweise

• Verzeichnisstruktur unter ~/linux_m03 erstellt.
• Kontrollierte Logdatei daten/system_events.log erzeugt.
• System-Baseline mit hostnamectl, getent passwd und ip -brief addr erstellt.
• hostnamectl-Warnungen getrennt nach stderr gespeichert.

Ergebnis

Die Arbeitsgrundlage war vorhanden. Die hostnamectl-Warnungen wurden als Berechtigungseffekt innerhalb der VM erkannt und separat gespeichert; stdout und stderr werden in einem späteren Arbeitsschritt getrennt ausgewertet.

Nachweise

5. Textfilter und Logauswertung

Ziel:

Aus den Logdaten sollten relevante Ereignisse, Benutzer und Quelladressen extrahiert und gezählt werden.

Linux-Administration findet häufig im Terminal und mit Textausgaben statt. Logdateien, Dienststatus, Prozesslisten und Konfigurationsfragmente sind typischerweise textbasiert. Werkzeuge wie grep, cut, sort, uniq und wc sind deshalb nicht nur Grundlagenbefehle, sondern Bausteine für Diagnose, Reporting und Fehlersuche.

Die kontrollierte Logdatei macht sichtbar, ob die Filterlogik stimmt. Beispiel: grep "sshd" findet nur Einträge, die exakt die Zeichenkette sshd enthalten. Ein Eintrag mit service=ssh hat zwar fachlich SSH-Bezug, wird aber von dieser exakten Suche nicht erfasst. Dieser Unterschied ist wichtig, weil Textsuche keine fachliche Interpretation ersetzt.

Arbeitsschritte und Nachweise:

• WARN-, ERROR- und kombinierte WARN|ERROR-Filterung.
• SSH-bezogene Suche über grep "sshd".
• Zeilenzählung mit wc -l.
• Benutzerextraktion mit grep -oE, cut, sort, uniq -c.
• Quell-IP-Auswertung mit demselben Muster.

Ergebnis:

Die Logdatei enthielt 10 Einträge. Davon waren 5 als WARN oder ERROR klassifiziert. 4 Einträge enthielten direkt sshd. Die Benutzer root und student sowie die Quelladressen 192.168.1.50 und 192.168.1.77 wurden jeweils gezählt.

Nachweise:

6. Pipes als Admin-Auswertung

Ziel:

Einzelne Shell-Werkzeuge sollten zu zusammenhängenden Auswertungsketten kombiniert werden.

Pipes sind eines der zentralen Unix-/Linux-Prinzipien. Statt ein großes Spezialprogramm zu verwenden, werden kleine Werkzeuge kombiniert: ein Befehl liefert Daten, der nächste filtert, der nächste formatiert oder zählt. Diese Arbeitsweise ist sehr effizient und gut dokumentierbar, weil jeder Schritt im Datenfluss sichtbar bleibt.

tee hält die Ausgabe im Terminal sichtbar und schreibt sie gleichzeitig in eine Datei. So werden Diagnoseausgabe und persistiertes Ergebnis in einem Schritt erfasst.

Arbeitsschritte und Nachweise:

• Sortierte WARN/ERROR-Auswertung.
• Verschachtelte Filterung für sshd + WARN/ERROR.
• Speicherung sicherheitsrelevanter Ereignisse mit tee.
• Benutzer- und IP-Zählungen mit Pipeline grep → cut → sort → uniq → tee.
• Ergänzende Systemauswertung mit ps aux und systemctl.

Ergebnis:

Die Pipelines erzeugten direkt nutzbare Report-Dateien wie security_relevant_events.txt, user_event_count.txt und source_ip_count.txt. Zusätzlich wurde der laufende SSH-Dienst mit systemctl sichtbar gemacht. Damit verbindet M03 kontrollierte Übungsdaten mit echtem Systemzustand.

Nachweise:

7. Redirects, stdout/stderr und Reports

Ziel:

Normale Ausgaben und Fehlerausgaben sollten bewusst getrennt, zusammengeführt und in Reportdateien gespeichert werden.

Für Administration und Troubleshooting reicht es nicht, nur eine Ausgabe zu sehen. Es muss klar sein, ob sie aus stdout oder stderr stammt. stdout enthält normalerweise reguläre Ergebnisse, stderr enthält Fehler- oder Warnmeldungen. Ohne diese Trennung können Fehler übersehen oder fälschlich als normale Ausgabe interpretiert werden.

Der absichtlich fehlerhafte Pfad does_not_exist war deshalb kein Fehler im Modul, sondern ein kontrollierter Testfall. Er erzeugte eine erwartete stderr-Ausgabe und machte sichtbar, wie 2> und 2>&1 funktionieren.

Arbeitsschritte und Nachweise:

• > zum Neuschreiben einer Report-Datei.
• >> zum Anhängen weiterer Ergebnisse.
• 2> zum getrennten Speichern von stderr.
• 2>&1 zum Zusammenführen von stdout und stderr.
• Vergleich der erzeugten Reportdateien und Zeilenzahlen.

Ergebnis:

Die erzeugten Dateien zeigen kontrollierte Ausgabeumleitung. Das ist ein praktischer Nachweis für reproduzierbare Diagnosearbeit, weil sowohl erfolgreiche Ausgaben als auch Fehlerausgaben dauerhaft nachvollziehbar gespeichert wurden.

Nachweis

8. Variablen, Globbing und Modulreport

Ziel:

Die bisherigen Ergebnisse sollten über Variablen und Dateimuster reproduzierbar zusammengeführt werden.

Variablen wie BASIS, LOG und REPORT reduzieren Tippfehler und machen Befehle wartbarer. Globbing wie *.log ermöglicht es, Dateimuster gezielt zu verarbeiten. Der Modulreport ist der Übergang von Einzelbefehlen zu einer zusammenhängenden Ergebnisdatei.

Die nicht gesetzte $REPORT-Variable führte zu einer fehlerhaften Ausgabeumleitung. Der Korrekturlauf definiert die Variable explizit und prüft die Zieldatei.

Arbeitsschritte und Nachweise:

• Variablen MODUL, BASIS, LOG und REPORT definiert.
• Existenz von Logdatei und reports-Verzeichnis geprüft.
• Logdatei per Globbing gefunden und kopiert.
• Modulreport m03_summary.txt erzeugt.
• Reportinhalt mit Host, Benutzer, Kennzahlen, Benutzer-/IP-Auswertung und Reportdateien angezeigt.

Ergebnis:

Der Modulreport bündelt die wichtigsten Ergebnisse aus M03 in einer zusammenhängenden Ergebnisdatei.

Nachweise:

9. Archivierung mit tar/gzip

Ziel:

Daten, Reports und Notizen sollten in einem komprimierten Archiv gesichert und der Archivinhalt geprüft werden.

tar.gz ist ein klassisches Linux-Format zur Bündelung und Kompression von Dateien. Für Administration und Dokumentation ist entscheidend, dass nicht nur ein Archiv erstellt wird, sondern auch der Inhalt geprüft wird. Die Prüfung mit tar -tzf verhindert, dass man sich auf eine Datei verlässt, deren Inhalt nicht kontrolliert wurde.

Für den Restore wurde linux_m03_20260531_0649.tar.gz gewählt, weil dieses Archiv die vollständige Datenbasis enthält. Das 45-Byte-Zwischenarchiv enthält diese Datenbasis nicht und wurde deshalb nicht für die Wiederherstellung verwendet.

Arbeitsschritte und Nachweise:

• Archivvariable gesetzt.
• Archiv mit tar -czf erstellt.
• Archivdatei mit ls -lh geprüft.
• Archivinhalt mit tar -tzf angezeigt.
• Archivliste als archive_content.txt gespeichert.

Ergebnis:

Für den Restore wurde das größere Archiv von 06:49 verwendet; das kleinere Archiv blieb als unvollständiger Zwischenstand unberücksichtigt.

Nachweise:

10. Restore-Test und Integritätsprüfung

Ziel:

Das Archiv sollte in ein separates Restore-Verzeichnis wiederhergestellt und mit den Originaldateien verglichen werden.

Die Wiederherstellbarkeit wurde durch den Restore-Test geprüft. diff -q und diff_exit_code=0 zeigen, dass Modulreport und Logdatei nach dem Restore mit den Originaldateien übereinstimmen.

Arbeitsschritte und Nachweise:

• Aktuelles Hauptarchiv automatisch ausgewählt.
• Restore-Verzeichnis bereinigt und neu erstellt.
• Archiv nach restore/test_restore entpackt.
• Wiederhergestellte Dateien angezeigt.
• Modulreport und Logdatei mit diff -q verglichen.
• diff_exit_code=0 dokumentiert.

Ergebnis:

Modulreport und Logdatei waren nach dem Restore identisch mit den Originaldateien. Damit sind Wiederherstellbarkeit und Integrität für diese Dateien geprüft.

Nachweise:

11. Zusammenfassung

Ziel:

Die relevanten Arbeitsergebnisse wurden in einer kompakten technischen Übersicht zusammengeführt.

Die Ergebnisübersicht führt vorhandene Ergebnisdateien, Archive und Restore-Prüfungen zusammen.

Arbeitsschritte und Nachweise:

• Arbeitsverzeichnis geprüft.
• Hauptbereiche angezeigt.
• Wichtige Ergebnisdateien und Archive gelistet.
• Restore-Nachweise mit test -f geprüft.
• Modulreport als Kurzansicht ausgegeben.

Ergebnis:

Die Arbeitsschritte umfassen Arbeitsstruktur, Datenbasis, Filteranalyse, Pipes, Redirects, Modulreport, Archiv, Restore und Integritätsprüfung.

Nachweise:

12. Troubleshooting, Abweichungen und Erkenntnisse

hostnamectl-Warnung

hostnamectl konnte als normaler Benutzer einzelne VM-Hardwareinformationen wie Product UUID und Hardware Serial nicht auslesen. Die eigentliche System-Baseline wurde trotzdem erzeugt. Die Warnung wurde separat als stderr gespeichert und fachlich eingeordnet.

Nicht gesetzte $REPORT-Variable

Beim ersten Modulreport-Versuch war die Zielvariable nicht gesetzt. Dadurch konnte Bash die Ausgabeumleitung nicht korrekt durchführen. Der Korrekturlauf definierte die Variablen explizit und prüfte Logdatei sowie Zielverzeichnis vor der Report-Erstellung.

Kontrollierte Logdaten

Die Logdaten wurden kontrolliert erzeugt, sodass Eingaben und erwartete Ausgaben nachvollziehbar bleiben. Eine Analyse produktiver Logdaten wurde nicht durchgeführt.

Kleines Zwischenarchiv

Das 45-Byte-Zwischenarchiv wurde nicht für den Restore verwendet. Die Wiederherstellung erfolgte mit dem größeren Archiv von 06:49, das die vollständigen Inhalte enthält.

13. Fachliche Abgrenzungen

Nachweis 31M03

Nachweis 32M03

Nachweis 33M03

Nachweis 34M03

Nachweis 35M03

Nachweis 36M03

Nachweis 37M03

Nachweis 38M03

Nachweis 39M03

Nachweis 40M03

Nachweis 41M03

Nachweis 42M03

Nachweis 43M03

Nachweis 44M03

Nachweis 45M03

Nachweis 46M03

Nachweis 47M03

Kurzfassung

In M04 wurde Paketverwaltung als administrativer Prozess dokumentiert. Auf Debian wurde das Paket jq recherchiert, installiert, validiert, über Paketlogs nachvollzogen und anschließend wieder entfernt. Auf Rocky Linux wurde die DNF/RPM-Welt als Vergleichssystem genutzt; dabei entstand ein realistischer Transaktionsfall, weil dnf remove -y jq mehr Pakete entfernte als erwartet. Die Nebenwirkung wurde über dnf history analysiert, ein automatischer Undo-Versuch geprüft und der Zustand anschließend kontrolliert manuell wiederhergestellt.

Arbeitsablauf

Paketstatus prüfen
→ Paketmetadaten auswerten
→ Installation durchführen
→ Installation validieren
→ Logs/History prüfen
→ Paket entfernen
→ Nebenwirkung erkennen
→ Wiederherstellung vorbereiten
→ Wiederherstellung validieren
→ Debian/Rocky vergleichen

Ausgangslage

M04 ist ein Lern-/Kursmodul mit Sysadmin-Bezug. Debian bleibt die Hauptlinie, Rocky dient als Vergleichssystem für die RHEL-/RPM-Welt. Auf Debian war jq vor M04 nicht installiert. Außerdem war sudo auf dem Debian-Minimalsystem nicht vorhanden, weshalb administrative Paketoperationen über su -c ausgeführt wurden.

Debian: Paketlebenszyklus mit APT/dpkg

Ziel war ein vollständiger Paketlebenszyklus. apt wurde für Repository-basierte Paketoperationen genutzt, dpkg zur lokalen Paketstatus- und Dateiprüfung. Die Installation wurde über jq --version, which jq, dpkg -l und dpkg -L jq validiert. Dadurch wurde nicht nur die Installation, sondern auch Programmverfügbarkeit, PATH-Eintrag, Paketstatus und Dateiliste belegt.

Debian: Paketlogs und Audit-Spur

Die Paketoperation wurde über /var/log/dpkg.log, /var/log/apt/history.log und /var/log/apt/term.log nachvollzogen. Der Zugriff auf apt/term.log erforderte Root-Kontext. Das wurde als Berechtigungsthema dokumentiert, nicht als Paketverwaltungsfehler.

Debian: Entfernung

jq wurde wieder entfernt. Danach war das Paket nicht mehr als installiert sichtbar und das Binary war nicht mehr im PATH. Die APT-History belegte die Install- und Remove-Transaktion. Die automatisch installierten Abhängigkeiten libjq1 und libonig5 blieben als automatisch entfernbar sichtbar. apt autoremove wurde bewusst nicht ausgeführt, um die Änderung auf das Zielpaket zu begrenzen.

Rocky: DNF/RPM-Vergleich

Rocky wurde als Vergleichssystem genutzt. dnf übernahm die Rolle des höheren Paketwerkzeugs, rpm die Rolle der lokalen Paketdatenbank. Auf Rocky war jq bereits vorhanden. Der DNF-Vorgang aktualisierte das Paket und wurde über jq --version, which jq, rpm -q, rpm -qi, rpm -ql und dnf history validiert.

Rocky: DNF-Remove, Undo-Grenze und manuelle Wiederherstellung

Beim Entfernen von jq über dnf remove -y jq wurden mehrere weitere Pakete entfernt. Die DNF-History machte die Nebenwirkung nachvollziehbar. Ein automatischer Rollback über dnf history undo scheiterte, weil exakte RPM-/NEVRA-Versionen nicht gefunden wurden. Die Wiederherstellung wurde deshalb zuerst mit --assumeno als Vorschau geprüft und anschließend manuell über Paketnamen durchgeführt. Danach wurden die wiederhergestellten Pakete und jq validiert. Die Abbildungen zeigen diese Rocky-Troubleshooting-Schritte in derselben fachlichen Reihenfolge.

Korrigierte Nachweislogik des Rocky-Troubleshooting-Blocks

Vergleich APT/dpkg vs. DNF/rpm

Erkenntnisse

• Paketverwaltung ist ein Lebenszyklus, nicht nur Installation.
• sudo ist nicht auf jedem Debian-Minimalsystem vorhanden.
• apt/dpkg und dnf/rpm erfüllen vergleichbare Rollen auf unterschiedlichen Distributionsfamilien.
• Logs und History sind zentrale Admin-Werkzeuge.
• dnf remove -y kann unerwartet mehrere Pakete entfernen.
• dnf history undo ist nützlich, aber nicht garantiert erfolgreich.
• Eine manuelle Wiederherstellung über Paketnamen kann im Lab ein kontrollierter Korrekturweg sein.

Abgrenzung

M04 ist keine produktive Paketstrategie. Nicht behandelt wurden Repository-Deep-Dives, GPG-Key-Management, Backports, Testing/Unstable, Mischrepositories oder produktive Rollback-Strategien.

Nachweis 48M04

Nachweis 49M04

Nachweis 50M04

Nachweis 51M04

Nachweis 52M04

Nachweis 53M04

Nachweis 54M04

Ziel

Nachweis 55M04

Nachweis 56M04

Nachweis 57M04

Nachweis 58M04

Nachweis 59M04

Nachweis 60M04

Nachweis 61M04

Nachweis 62M04

Nachweis 63M04

Nachweis 64M04

Nachweis 65M04

Nachweis 66M04

Nachweis 67M04

Nachweis 68M04

Ergebnis und Erkenntnisse

Nachweis 69M04

Ergebnis

Nachweis 70M04

Nachweis 71M04

Modul: M05 – Benutzer, Gruppen, Rechte, su, sudo, umask und visudo
Hauptsystem: Debian debian13

Kurzfassung

In M05 wurde auf Debian ein lokales Benutzer- und Rechtekonzept aufgebaut. Die Benutzer m05alice und m05bob wurden erstellt, der Gruppe m05team zugeordnet und über das Projektverzeichnis /srv/m05-projekt mit root:m05team und Modus 2770 praktisch eingesetzt. Zugriffstests zeigten, dass Gruppenmitglieder Dateien erstellen konnten, während student außerhalb der Projektgruppe keinen direkten Zugriff erhielt. Zusätzlich wurden chmod, chown, umask, su, sudo und visudo -c behandelt, inklusive realer Lernpunkte zum /usr/sbin-PATH und zur Aktivierung von Gruppenmitgliedschaften erst nach neuer Login-Sitzung.

Arbeitsablauf

Ausgangslage → Benutzer/Gruppe → Projektverzeichnis → Zugriffstest → chmod/chown → umask → su/sudo/visudo → Ergebnis

1. Ausgangslage und Admin-Kontext

Ziel

Der Ausgangszustand sollte nachvollziehbar erfasst werden, bevor Benutzer, Gruppen oder Rechte verändert werden.

Lokale Benutzer- und Rechteverwaltung verändert sicherheitsrelevante Systemzustände. Deshalb ist der Startzustand wichtig: Wer arbeitet auf welchem System, welche Admin-Werkzeuge sind vorhanden und welche Testobjekte existieren bereits?

Umsetzung und Ergebnis

Auf debian13 wurde im Arbeitsverzeichnis ~/linux_m05 gearbeitet. su war vorhanden, sudo zunächst nicht installiert. Die Testobjekte m05alice, m05bob, m05gast, m05team und /srv/m05-projekt waren zu Beginn nicht vorhanden.

Nachweise:

2. Benutzer und Gruppen

Ziel:

Zwei lokale Testbenutzer sollten erstellt und einer gemeinsamen Projektgruppe zugeordnet werden.

Benutzer und Gruppen bilden die Grundlage klassischer Unix-Dateirechte. Wichtig ist nicht nur das Erstellen, sondern auch die Validierung über getent und id.

Umsetzung und Ergebnis:

Die Gruppe m05team sowie die Benutzer m05alice und m05bob wurden angelegt. Beide Benutzer wurden mit usermod -aG ergänzend zur Gruppe m05team hinzugefügt. -aG ist bewusst relevant, weil -G ohne -a bestehende Zusatzgruppen ersetzen kann.

Während der Umsetzung zeigte sich ein PATH-Thema: groupadd, useradd und usermod lagen unter /usr/sbin und wurden über absolute Pfade ausgeführt.

Nachweise:

3. Projektverzeichnis mit Gruppenrechten und setgid

Ziel:

Ein gemeinsames Projektverzeichnis sollte so eingerichtet werden, dass nur root und Mitglieder der Gruppe m05team Zugriff erhalten.

Ein sauberer Gruppenbereich ist besser als pauschal offene Rechte. Der Modus 2770 kombiniert Gruppenberechtigungen mit setgid. Dadurch erben neue Dateien im Verzeichnis die Gruppe des Verzeichnisses.

Umsetzung und Ergebnis:

/srv/m05-projekt wurde mit Besitz root:m05team und Modus 2770 erstellt. ls und stat zeigten drwxrws--- und bestätigten das setgid-Bit.

Nachweis:

4. Zugriffstests aus Benutzersicht

Ziel:

Die gesetzten Rechte sollten aus Sicht der Benutzer geprüft werden.

Die konfigurierten Rechte wurden mit praktischen Zugriffstests geprüft; ls -l zeigt ergänzend Eigentümer, Gruppe und Modus.

Umsetzung und Ergebnis:

m05alice und m05bob erstellten Dateien im Projektverzeichnis. Beide Dateien erhielten durch setgid die Gruppe m05team. Der direkte Zugriff von student auf das Projektverzeichnis wurde verweigert. Das war erwartetes Verhalten, weil student nicht Mitglied von m05team war.

Nachweise:

5. chmod und chown

Ziel:

Rechte und Besitz sollten gezielt an einer Datei verändert und validiert werden.

chown und chmod steuern unterschiedliche Aspekte: Besitzverhältnisse einerseits, Modusbits andererseits. Beide Ebenen müssen für Dateizugriff zusammengedacht werden.

Umsetzung und Ergebnis:

alice.txt wurde von 664 auf 640 gesetzt und explizit auf m05alice:m05team geprüft. Damit darf der Eigentümer lesen und schreiben, die Gruppe lesen, und andere Benutzer erhalten keinen Zugriff.

Nachweis:

6. umask

Ziel:

Der Einfluss verschiedener umask-Werte auf neu erstellte Dateien und Verzeichnisse sollte sichtbar gemacht werden.

Rechte entstehen nicht erst durch chmod. Bereits beim Erstellen beeinflusst die aktuelle umask, welche Rechte neue Dateien und Verzeichnisse erhalten.

Umsetzung und Ergebnis:

Die Werte 022, 027 und 002 wurden getestet. Die Ergebnisse zeigten typische Rechte wie 644/755, 640/750 und 664/775. Die aktuelle Shell hatte zuvor 0002, was als gruppenfreundliche Voreinstellung eingeordnet wurde.

Nachweis:

7. su, sudo und visudo

Ziel:

Der Admin-Kontext sollte sauber eingeordnet und sudo kontrolliert eingeführt werden.

su und sudo sind unterschiedliche Modelle. su nutzt den Ziel- bzw. Root-Kontext direkt. sudo delegiert Rechte über die sudoers-Policy. visudo ist der sichere Weg, sudoers-Konfigurationen zu prüfen oder zu bearbeiten.

Umsetzung und Ergebnis:

Zu Beginn war sudo nicht installiert. Es wurde über su -c installiert. Danach wurde student der Gruppe sudo hinzugefügt. Nach einer neuen SSH-Sitzung war die Gruppenmitgliedschaft aktiv. sudo id zeigte Root-Kontext, und sudo visudo -c meldete eine erfolgreiche Syntaxprüfung. Die sudoers-Datei wurde nicht direkt mit einem Editor verändert.

Nachweise:

8. Troubleshooting und Abweichungen

PATH bei su -c

Mehrere Admin-Befehle wurden über su -c zunächst nicht gefunden, obwohl Root-Kontext genutzt wurde. Ursache war nicht fehlende Berechtigung, sondern die Suchpfad-Umgebung. Die Korrektur erfolgte über absolute Pfade wie /usr/sbin/groupadd und /usr/sbin/runuser.

Teilweise fehlgeschlagene Benutzeranlage

m05alice wurde zunächst erstellt, während m05bob fehlte. Der Zustand wurde erkannt und gezielt korrigiert.

Zugriffsbeschränkung für student

student konnte /srv/m05-projekt nicht direkt lesen. Dies war kein Fehler, sondern bestätigte das Rechtekonzept: Zugriff war nur für root und m05team vorgesehen.

Ergebnis

Die Arbeitsschritte zeigen ein lokales Rechtekonzept mit Benutzern, Gruppen, Projektverzeichnis, setgid, Zugriffstest, chmod, chown, umask, su, sudo und visudo. Die Grenze zur produktiven Härtung bleibt bestehen: ACLs, PAM-Konfigurationen und riskante sudoers-Regeln wurden nicht umgesetzt.

10. Fachliche Abgrenzung

• Kein Cleanup der Testbenutzer wurde dokumentiert; die Testobjekte bleiben für eventuelle Nachprüfungen bestehen.
• Keine ACLs wurden behandelt.
• Keine PAM- oder sudoers-Deep-Dives wurden durchgeführt.
• Produktive Sicherheitshärtung wurde nicht umgesetzt.

Nachweis 72M05

Nachweis 73M05

Nachweis 74M05

Nachweis 75M05

Nachweis 76M05

Projektverzeichnis mit Gruppenrechten

Nachweis 77M05

Zugriffstests

Nachweis 78M05

Nachweis 79M05

Nachweis 80M05

Nachweis 81M05

Nachweis 82M05

Nachweis 83M05

Nachweis 84M05

Nachweis 85M05

Nachweis 86M05

Nachweis 87M05

Kurzfassung

In M06 wurde der laufende Systemzustand einer Debian-VM mit klassischen Linux-Werkzeugen untersucht. Prozesse wurden mit ps und top -b -n 1 ausgewertet, aktive Sitzungen und Laufzeit mit who, w und uptime geprüft sowie Speicher-, Swap-, Dateisystem- und Inode-Nutzung mit free und df erfasst. Anschließend wurde ein kontrollierter sleep-Hintergrundprozess gestartet, über PID, jobs, ps und pgrep nachvollzogen und mit kill -TERM beendet. Ein Systemstatusreport bündelt die Ergebnisse als wiederverwendbares Admin-Artefakt.

Arbeitsablauf

Toolcheck → ps-Snapshot → top-Batch → Sessions/Load → Ressourcen → Hintergrundjob → kill -TERM → Systemstatusreport

Rolle im Kurs

M06 folgt auf die bisherigen Module zu Shell, Paketverwaltung und Rechten. Der Schwerpunkt liegt nun auf dem laufenden System: Prozesse, Jobs, Sessions, Laufzeit, Load Average, Speicher, Swap, Dateisysteme und Inodes. Es wurde bewusst kein Performance-Tuning, keine Serviceverwaltung und keine journalctl-Analyse durchgeführt; diese Themen gehören in spätere Module.

Wichtige Abschnitte

1. Ausgangszustand und Toolcheck

Arbeitsstruktur und Werkzeugverfügbarkeit wurden in ~/linux_m06 geprüft. Die aktuelle Bash-Shell wurde zusätzlich über ps -p $$ als Prozess sichtbar gemacht.

2. Prozess-Snapshot mit ps

ps wurde zur Momentaufnahme genutzt. Sortiert wurde nach CPU- und RAM-Nutzung. Zusätzlich wurden SSH- und Bash-Prozesse gefiltert. Ein Quoting-/Pattern-Fehler bei grep -E wurde korrigiert; die Abbildung zeigt Fehler, Korrektur und erfolgreiche Filterung.

3. top im Batch-Modus

top -b -n 1 wurde genutzt, weil die Ausgabe für Dokumentation und Screenshots stabiler ist als interaktives top.

4. Sessions, Uptime und Ressourcen

who, w, uptime, free -h, df -h, df -ih und df -hT zeigen aktive Sitzung, Laufzeit, Load, Speicher, Swap, Dateisysteme, Inodes und Dateisystemtypen.

5. Hintergrundjob und Prozesssteuerung

Ein Testprozess sleep 300 & wurde gestartet, seine PID über $! gesichert, mit jobs, ps und pgrep geprüft und anschließend mit kill -TERM beendet. Die Beendigung wurde mit ps, pgrep und jobs validiert.

6. Systemstatusreport

Die Einzelprüfungen wurden in reports/m06_systemstatus_report.txt zusammengeführt. Dadurch entsteht ein kleines Admin-Artefakt und nicht nur eine Screenshotfolge.

Ergebnis

M06 umfasst Systemzustand, Prozessauswertung, Ressourcenprüfung, die kontrollierte Steuerung eines Testprozesses und einen zusammenfassenden Report. Optimierung und Lasttests waren nicht Bestandteil.

Abgrenzung

Nicht durchgeführt wurden:

• Performance-Tuning,
• Lasttest,
• Serviceverwaltung,
• journalctl-Analyse,
• kill -9 als Standardlösung,
• Paketinstallation für zusätzliche Monitoring-Tools.

Erkenntnisse

Siehe 50_Lessons_Learned/lessons_learned_m06.md.

Nachweise

Nachweis 88M06

Nachweis 89M06

Nachweis 90M06

Nachweis 91M06

Nachweis 92M06

Nachweis 93M06

Nachweis 94M06

Nachweis 95M06

Nachweis 96M06

Nachweis 97M06

Nachweis 98M06

Nachweis 99M06

Nachweis 100M06

Modul: M07
Hauptsystem: Debian debian13

Kurzfassung

In M07 wurde auf Debian ein eigener systemd-oneshot-Dienst erstellt, erfolgreich ausgeführt und über systemctl sowie journalctl validiert. Anschließend wurde ein kontrollierter Fehlzustand erzeugt, indem ExecStart absichtlich auf ein nicht vorhandenes Skript gesetzt wurde. Der Fehler wurde über systemctl status, systemctl --failed, journalctl -u und journalctl -xeu analysiert; die Ursache war ein fehlender ausführbarer Pfad mit status=203/EXEC. Danach wurde die funktionierende Unit aus dem Backup wiederhergestellt, systemd neu eingelesen, der failed-State bereinigt und der erfolgreiche Dienstlauf erneut validiert.

Technische Übersicht

Strukturelle Übersicht

m07-demo.sh
   │
   ▼
m07-demo.service (Type=oneshot)
   │
   ├── erfolgreicher Lauf → journalctl → finished successfully
   │
   ├── geänderter ExecStart → missing script → failed 203/EXEC
   │
   └── Backup restore → daemon-reload → reset-failed → successful validation

1. Ausgangslage und systemd-Toolcheck

Ziel

Der systemd-Startzustand sollte vor allen Änderungen geprüft werden, damit spätere Fehler eindeutig dem M07-Demo-Dienst zugeordnet werden können.

Vor einer Service-Triage ist der Ausgangszustand entscheidend. Wenn bereits vorher fehlgeschlagene Units vorhanden wären, dürften sie später nicht fälschlich M07 zugeschrieben werden.

Arbeitsschritte und Nachweise

Es wurden Arbeitsordner erstellt, Host und Benutzer geprüft, systemctl und journalctl validiert, die systemd-Version angezeigt und systemctl --failed vor dem Fehlerfall ausgeführt.

Nachweise

Ergebnis

Das System war running; vor M07 waren keine failed Units vorhanden. Ein kleiner dateecho-Tippfehler wurde direkt korrigiert und hat keine fachliche Relevanz.

2. SSH-Dienst als reales Leseobjekt

Ziel:

Ein bestehender systemd-Dienst sollte realistisch betrachtet werden, ohne eine aktive SSH-Sitzung zu gefährden.

SSH ist ein kritischer Verbindungsdienst. Daher wurde er ausdrücklich nur gelesen und nicht gestoppt, neu gestartet oder verändert.

Arbeitsschritte und Nachweise:

ssh.service wurde mit systemctl status, is-active, is-enabled, systemctl cat und sudo journalctl -u ssh analysiert.

Nachweise:

Ergebnis:

ssh.service war aktiv und enabled. Die Journal-Ausgabe bestätigte Dienststart und SSH-Sitzungen.

3. Demo-Skript und eigene systemd-Unit

Ziel:

Ein ungefährliches Übungsobjekt sollte erstellt werden, um Start, Logs, Fehlzustand und Korrektur risikofrei zu demonstrieren.

Ein eigener Demo-Dienst ist für Lab-Dokumentation sicherer als das absichtliche Beschädigen produktiver Dienste. Das Skript schreibt einfache Ausgaben, die systemd im Journal erfasst.

Arbeitsschritte und Nachweise:

Es wurde m07-demo.sh erstellt, ausführbar gemacht und anschließend als m07-demo.service mit Type=oneshot eingebunden. Nach daemon-reload war die Unit systemd bekannt.

Nachweise:

Ergebnis:

Die Unit war initial inactive (dead), was vor dem ersten Start erwartbar ist. daemon-reload wurde korrekt eingesetzt, um systemd die neue Unit-Datei bekannt zu machen.

4. Erfolgreicher oneshot-Dienstlauf

Ziel:

Der eigene Dienst sollte gestartet und über Status sowie Journal validiert werden.

Bei einem Type=oneshot-Dienst ist inactive (dead) nach erfolgreicher Ausführung normal. Der Erfolg wird über Status, Exit-Status und Journal-Ausgabe interpretiert, nicht allein über dauerhaftes active.

Arbeitsschritte und Nachweise:

Der Dienst wurde mit sudo systemctl start m07-demo.service gestartet. Danach wurden systemctl status und sudo journalctl -u m07-demo.service geprüft.

Nachweis

Ergebnis:

Das Journal zeigt started, Host: debian13, User: root, finished successfully, Deactivated successfully und Finished. Die Ausführung erfolgte als Root, weil keine abweichende User=-Direktive gesetzt wurde.

5. Restart, Enable, Disable und is-enabled

Ziel:

Der Unterschied zwischen aktuellem Dienstlauf und Autostart sollte praktisch gezeigt werden.

start und restart betreffen den aktuellen Lauf. enable und disable steuern systemd-Install-Links für den Autostart und starten den Dienst nicht zwingend sofort.

Arbeitsschritte und Nachweise:

Der Dienst wurde neu gestartet, der Journal-Verlauf geprüft, der Autostart aktiviert, mit is-enabled validiert und anschließend wieder deaktiviert.

Nachweise:

Ergebnis:

Der Restart erzeugte einen weiteren erfolgreichen Lauf. enable erstellte einen Symlink unter multi-user.target.wants; disable entfernte ihn wieder. Der Endzustand war disabled.

6. Kontrollierter Fehlzustand

Ziel:

Ein reversibler Fehlerfall sollte erzeugt werden, um Service-Triage realistisch zu üben.

Der Fehler wurde bewusst nur am eigenen Demo-Dienst erzeugt. Ein falscher ExecStart-Pfad ist ein typischer, klar analysierbarer systemd-Fehler.

Arbeitsschritte und Nachweise:

Die funktionierende Unit wurde gesichert. Danach wurde ExecStart per sed auf /home/student/linux_m07/units/m07-demo_missing.sh geändert. Nach daemon-reload schlug der Start erwartungsgemäß fehl.

Nachweis:

Ergebnis:

systemctl status zeigte failed, Result: exit-code und status=203/EXEC. Die Unit war geladen, aber der Prozess konnte nicht ausgeführt werden.

7. Fehleranalyse mit systemctl und journalctl

Ziel:

Die Ursache sollte über systemd-Werkzeuge nachvollziehbar eingegrenzt werden.

Zur Service-Triage wurden die Liste fehlgeschlagener Units und das Unit-spezifische Journal gemeinsam ausgewertet.

Arbeitsschritte und Nachweise:

systemctl --failed zeigte m07-demo.service als failed. journalctl -u und journalctl -xeu zeigten Unable to locate executable, No such file or directory und Failed at step EXEC.

Nachweis:

Ergebnis:

Die Ursache war der absichtlich falsche ExecStart-Pfad. Die Fehlermeldung war eindeutig und konnte direkt auf die Unit-Datei zurückgeführt werden.

8. Korrektur, reset-failed und Validierung

Ziel:

Der Dienst sollte wieder in einen funktionierenden Zustand gebracht und der Endzustand sauber validiert werden.

reset-failed behebt nicht die Ursache. Die Ursache wird durch Korrektur der Unit-Datei behoben; reset-failed bereinigt anschließend den systemd-Fehlerstatus.

Arbeitsschritte und Nachweise:

Die funktionierende Unit wurde aus dem Backup wiederhergestellt, systemd neu eingelesen, der failed-State bereinigt und der Dienst erneut gestartet. Anschließend wurden failed Units, kompakter Unit-Zustand und ein gefiltertes Journal nach Korrektur geprüft.

Nachweise:

Ergebnis:

systemctl --failed zeigte wieder 0 loaded units listed, Result=success, ExecMainStatus=0, ActiveState=inactive, SubState=dead. Das gefilterte Journal zeigte nur den erfolgreichen Lauf nach der Korrektur.

9. Service-Triage-Report

Ziel:

Die Fehleranalyse sollte als reproduzierbares Admin-Artefakt dokumentiert werden.

Der Report bündelt die einzelnen Terminalausgaben zu einer Triage-Kette aus Status, Fehler, Ursache, Maßnahme und erneuter Prüfung.

Arbeitsschritte und Nachweise:

Der Report m07_service_triage_report.md dokumentiert Dienst, Zweck, Ausgangszustand, Fehlerfall, Triage-Kette, Maßnahme, Validierung und Erkenntnisse.

Nachweis:

Ergebnis:

Die Triage-Kette umfasst Status, fehlgeschlagene Units, Logs, Ursache, Maßnahme, daemon-reload, reset-failed und die anschließende Prüfung.

10. Ergebnis:

Ziel:

Der korrigierte Dienstzustand sollte anschließend geprüft werden.

Nach einer Fehlersimulation darf kein unerklärter Failed-State zurückbleiben. Der Demo-Dienst soll vorhanden, aber nicht dauerhaft aktiv oder enabled sein.

Arbeitsschritte und Nachweise:

Die Ergebnisübersicht zeigt Systemkontext, vorhandene M07-Dateien, Demo-Service-Status, Autostartstatus, failed Units und Report-Kurzansicht.

Nachweise:

Ergebnis:

Der Demo-Dienst ist inactive (dead) und disabled; systemctl --failed zeigt keine fehlgeschlagenen Units. Dies ist der erwartete Ergebniszustand.

Zusammenfassung

M07 dokumentiert die Kette aus Dienstlauf, kontrolliertem Fehler, Analyse, Korrektur und erneuter Prüfung.

Troubleshooting und Abweichungen

Abgrenzung

Nicht umgesetzt:

• SSH wurde nicht gestoppt, verändert oder repariert.
• Es wurde kein Produktivdienst absichtlich beschädigt.
• Es wurde kein Timer erstellt; Timer gehören später zu M11.
• Es wurden keine komplexen systemd-Optionen oder Härtungsmaßnahmen umgesetzt.
• inactive (dead) bei Type=oneshot wurde nicht als Fehler interpretiert.

Ausgangszustand und systemd-Toolcheck

Nachweis 101M07

Nachweis 102M07

SSH-Dienst nur lesend analysieren

Nachweis 103M07

Nachweis 104M07

Nachweis 105M07

Nachweis 106M07

Erfolgreicher oneshot-Lauf

Nachweis 107M07

Restart, Enable und Disable

Nachweis 108M07

Nachweis 109M07

Kontrollierter Fehlzustand und Analyse

Nachweis 110M07

Nachweis 111M07

Korrektur und Prüfung

Nachweis 112M07

Nachweis 113M07

Triage-Report und Ergebnis

Nachweis 114M07

Nachweis 115M07

Nachweis 116M07

Modul: M08
Systeme: Debian debian13 als Quelle, Rocky rocky9 als Ziel, Windows/RemoteLab als Client-Kontext

Kurzfassung

In M08 wurde eine zusammenhängende Remote-Admin-Kette aufgebaut: Zuerst wurden Netzwerkbasis, Routing, Erreichbarkeit, Namensauflösung und SSH-Sockets geprüft. Danach wurde ein ED25519-SSH-Key erzeugt, der Public Key auf Rocky in authorized_keys eingebunden und ein SSH-Aufruf mit expliziter Schlüsseldatei sowie deaktivierter Passwortauthentifizierung erfolgreich ausgeführt. Der Nachweis bestimmt die tatsächlich akzeptierte Authentifizierungsmethode nicht eindeutig. Anschließend wurden eine Datei per scp übertragen und eine rsync-Synchronisation zuerst mit --dry-run, danach real durchgeführt und remote validiert. rsync war auf Debian zunächst nicht vorhanden und wurde kontrolliert per apt nachinstalliert.

Arbeitsablauf

Netzwerkbasis prüfen
→ Erreichbarkeit testen
→ Namensauflösung einordnen
→ SSH-Port und aktive Verbindung prüfen
→ SSH-Key erzeugen
→ Public Key auf Rocky einrichten
→ SSH-Aufruf mit deaktivierter Passwortauthentifizierung prüfen
→ Datei per scp übertragen
→ rsync-Verfügbarkeit prüfen und Debian nachrüsten
→ rsync Dry-Run
→ echter rsync
→ Remote-Validierung
→ Technischer Report

Abgrenzung

Nicht umgesetzt wurden DNS-Server-Aufbau, SSH-Härtung, Firewall-Konfiguration, ein produktives Backup-Konzept und rsync --delete. Dokumentiert sind Netzwerkdiagnose, der SSH-Aufruf sowie kontrollierte Dateiübertragung und Synchronisation im Labor.

1. Ausgangszustand und Toolcheck

Ziel und Einordnung. Ziel war, Quelle/Ziel-Kontext und verfügbare Werkzeuge vor den Netzwerk- und SSH-Tests festzuhalten. Dabei wurde sichtbar, dass rsync auf Debian zunächst nicht installiert war. Das wurde nicht als Fehler gewertet, sondern als sauberer Ausgangszustand für die spätere kontrollierte Nachinstallation.

Nachweis 117M08

Nachweis 118M08

2. IP-Adresse, Interface und Routing

Ziel und Einordnung. Debian nutzte eth0 mit 10.100.20.43/24; die Default Route führte über 10.100.20.254. In diesem Abschnitt wurde ausschließlich ausgelesen, nicht konfiguriert.

Nachweis 119M08

3. Erreichbarkeit und Namensauflösung

Ziel und Einordnung. Rocky war per IP erreichbar, Debian über die eigene IP ebenfalls. Der Windows-/RemoteLab-Client antwortete nicht auf ICMP; das wurde nicht als Linux-Fehler bewertet. rocky9 war über getent hosts nicht auflösbar, weil kein entsprechender Eintrag über die systemweite Namensauflösung sichtbar war; daher wurde im weiteren Verlauf die IP-Adresse 10.100.20.36 genutzt.

Nachweis 120M08

Nachweis 121M08

4. SSH-Port, Socketebene und Dienststatus

Ziel und Einordnung. ss zeigte SSH auf Port 22 und eine aktive Verbindung zwischen Windows/RemoteLab und Debian. Ergänzend bestätigte systemctl, dass der SSH-Dienst aktiv und aktiviert ist. Socketebene und Dienstebene wurden damit getrennt betrachtet.

Nachweis 122M08

5. SSH-Key-Erzeugung

Ziel und Einordnung. Ein ED25519-Key wurde für M08 erzeugt. Die Rechte zeigen den privaten Schlüssel restriktiv und den Public Key lesbar. Der Inhalt des privaten Schlüssels wurde nicht angezeigt und ist nicht Bestandteil der Dokumentation.

Nachweis 123M08

6. Public-Key-Verteilung und Rechte auf Rocky

Ziel und Einordnung. Der Public Key wurde manuell auf Rocky in authorized_keys eingetragen. Die Rechte 700 für .ssh und 600 für authorized_keys wurden geprüft.

Nachweis 124M08

7. SSH-Aufruf mit deaktivierter Passwortauthentifizierung

Ziel und Einordnung. Der SSH-Aufruf mit expliziter Schlüsseldatei und PasswordAuthentication=no war erfolgreich. Damit war Passwortauthentifizierung für diesen Aufruf deaktiviert. Der Nachweis identifiziert jedoch weder den tatsächlich akzeptierten Schlüssel noch die konkrete alternative Authentifizierungsmethode eindeutig; ein gebundener SSH-Debug- oder Serverlogbeleg liegt nicht vor.

Nachweis 125M08

8. Dateiübertragung mit scp

Ziel und Einordnung. Eine lokale Testdatei wurde von Debian per scp nach Rocky übertragen und anschließend remote mit ls und cat validiert. Das belegt eine einfache SSH-basierte Dateiübertragung, aber kein vollständiges Backup-Konzept.

Nachweis 126M08

9. rsync-Verfügbarkeit, Dry-Run und echter Sync

Ziel und Einordnung. Rocky hatte rsync, Debian zunächst nicht. Debian wurde kontrolliert per apt ergänzt. Danach wurden zwei Testdateien zuerst per rsync --dry-run geprüft und anschließend real synchronisiert. Die Zielinhalte wurden auf Rocky validiert.

Nachweis 127M08

Nachweis 128M08

Nachweis 129M08

10. Netzwerk- und Transferreport

Ziel und Einordnung. Der Report bündelt die Diagnosekette und Ergebnisse. Er ersetzt nicht die Screenshots, macht den Ablauf aber nachvollziehbar und wiederverwendbar.

Nachweis 130M08

Nachweis 131M08

11. Ergebnisübersicht

Ziel und Einordnung. Die Ergebnisübersicht zeigt lokale Artefakte, SSH-Key-Dateien als Dateinamen, Remote-Dateien auf Rocky und die lokale rsync-Version. Der private Key-Inhalt wurde nicht angezeigt.

Nachweis 132M08

Nachweis 133M08

Ergebnis

M08 verbindet Netzwerkdiagnose, Socket- und Dienstprüfung, einen erfolgreichen SSH-Aufruf mit expliziter Schlüsseldatei und deaktivierter Passwortauthentifizierung, Dateiübertragung sowie kontrollierte Synchronisation. Die tatsächlich akzeptierte Authentifizierungsmethode und der konkret akzeptierte Schlüssel sind aus dem vorhandenen Nachweis nicht bestimmbar.

SSH-Authentifizierung und Schlüsselgrenze

Die Passwortauthentifizierung war für den SSH-Aufruf deaktiviert, und der Aufruf war erfolgreich. Die tatsächlich akzeptierte Authentifizierungsmethode und der konkret akzeptierte Schlüssel sind aus dem vorhandenen Nachweis nicht eindeutig bestimmbar. Die private Key-Datei ist nicht enthalten.

Nicht dokumentierter Endzustand

Ein Cleanup der Testdateien und SSH-Key-Artefakte ist nicht dokumentiert. Ihr späterer Zustand ist daher nicht bestimmt.

Nachweis 134M08

Modul: M09
Hauptsystem: Debian debian13
Arbeitsverzeichnis: /home/student/linux_m09

Kurzfassung

In M09 wurde ein kleines Bash-Skript m09_basic_check.sh erstellt, das ein Zielverzeichnis als Argument erwartet, Fehlerfälle sauber über Exit-Codes behandelt, Statuswerte ausgibt und eine Logdatei schreibt. Das Skript wurde ausführbar gemacht, mit Fehler- und Erfolgsfällen getestet, über bash -n syntaktisch geprüft und mit einer einfachen Schleife mehrfach ausgeführt. Zusätzlich wurde cron gegenüber systemd.timer eingeordnet, ohne bereits M11 vorwegzunehmen.

Technische Übersicht

Ablaufübersicht

Nachweis 135M09

1. Ausgangszustand und Toolcheck

Ziel: System-, Shell- und Werkzeugkontext dokumentieren.
Skripte sind nur bewertbar, wenn Shell, Arbeitsverzeichnis und verfügbare Werkzeuge bekannt sind.

Nachweis 136M09

Nachweis: Belegt den reproduzierbaren Startzustand für M09.

Ergebnis: Debian debian13, Benutzer student, Bash und relevante Werkzeuge waren verfügbar.

2. Skriptstruktur

Ziel: Wiederverwendbares Bash-Skript als Artefakt erstellen.
M09 zeigt Grundlagen für spätere Automatisierung: Shebang, Variablen, Argumente, if, Logausgabe, Schleife und Exit-Codes.

Nachweis 137M09

Nachweis: Belegt Shebang, Variablen, Argument $1, if-Prüfung, Logausgabe, Schleife und Exit-Codes im Skript.

Ergebnis: Das Skript bildet einen kleinen, kontrollierten Bash-Grundlagen-Nachweis.

3. Fehlerfälle und Exit-Codes

Ziel: Fehlerarten unterscheidbar behandeln.
Fehlende Argumente und ungültige Zielverzeichnisse sind unterschiedliche Fehler und sollten differenzierte Exit-Codes liefern.

Nachweis 138M09

Nachweis: Belegt Eingabeprüfung und differenzierten Exit-Code für fehlende Parameter.

Nachweis 139M09

Nachweis: Belegt Vorbedingungsprüfung über Verzeichnisexistenz.

Ergebnis: Fehlendes Argument führt zu Exit-Code=2; nicht vorhandenes Zielverzeichnis führt zu Exit-Code=1.

4. Erfolgsfall, Logdatei und Schleife

Ziel: Regulären Lauf und Wiederholungslogik belegen.
Ein erfolgreicher Skriptlauf wird durch zusammenpassende Ausgabe, Logdatei und Exit-Code bestätigt.

Nachweis 140M09

Nachweis: Belegt funktionierenden Erfolgsfall und Nachvollziehbarkeit über Logs.

Nachweis 141M09

Nachweis: Belegt einfache Wiederholungslogik und sichere Mehrfachprüfung.

Ergebnis: Der Erfolgsfall endet mit Exit-Code=0; Schleifenläufe für alpha und beta sind sichtbar.

5. Syntax- und Ausführungsprüfung

Ziel: Syntax und Ausführbarkeit prüfen. bash -n prüft Syntax, aber nicht fachliche Logik; daher ergänzt es die Testfälle.

Nachweis 142M09

Nachweis: Belegt technische Mindestprüfung und Ausführbarkeit des Skripts.

Ergebnis: Syntax und Ausführbarkeit sind nachgewiesen.

6. Scheduling-Einordnung

Ziel: cron und systemd.timer fachlich einordnen, ohne M11 vorwegzunehmen.
Cron ist verbreitet und einfach; systemd.timer ist enger in systemctl und journalctl integriert.

Nachweis 143M09

Nachweis: Belegt, dass M09 Scheduling einordnet, aber die praktische Timer-Umsetzung auf M11 verschiebt.

Ergebnis: Scheduling wurde eingeordnet, aber kein Cronjob und kein systemd.timer aktiviert.

7. Report und Ergebnis

Ziel: Ergebnis und Artefaktbasis zusammenführen.

Nachweis 144M09

Nachweis: Belegt die fachliche Zusammenfassung des Moduls.

Nachweis 145M09

Nachweis: Belegt, dass M09 mit funktionsfähigem Skript abgeschlossen wurde.

Nachweis 146M09

Nachweis: Belegt Reports, Notizen und Logdateien des Moduls.

Ergebnis: Skript, Logdatei, Scheduling-Notiz und Report sind vorhanden und durch die beschriebenen Testfälle eingeordnet.

Ergebnis

Es wurde ein Bash-Skript mit Eingabeprüfung, Fehlerbehandlung, Logausgabe, Schleife und Exit-Codes erstellt und validiert. M11 führt diese Grundlagen mit einem systemd-Service und einem systemd-Timer fort.

Troubleshooting und Abweichungen

Abgrenzung

Nicht umgesetzt:

• kein produktiver Healthcheck,
• kein aktivierter Cronjob,
• kein praktisch umgesetzter systemd.timer,
• keine ShellCheck-/Unit-Test-Suite,
• keine Root-/sudo-Automatisierung.

Nicht umgesetzte Erweiterungen

• In M09 wurden weder ein systemd-Service noch ein systemd-Timer umgesetzt.
• ShellCheck wurde nicht eingesetzt.

Kurzfassung

In M10 wurde Mosquitto auf Debian installiert und als lokaler MQTT-Broker untersucht. Paketstatus, systemd-Dienststatus, Listener, Baseline-Konfiguration und Logs wurden geprüft. Der erste manuelle Pub/Sub-Test endete mit timeout/Exit-Code 124 und zeigte keinen Nachrichtenempfang. Ein gekoppelter Pub/Sub-Test und ein zusätzlicher Retained-Message-Test zeigten anschließend den lokalen Nachrichtenempfang. Der Broker wurde nicht extern geöffnet; ein falscher Client-Port wurde als Client-/Zielportfehler eingeordnet.

Technische Übersicht

Strukturelle Übersicht

Mosquitto auf debian13
  ├─ systemd-Dienst: mosquitto.service
  ├─ Listener: 127.0.0.1:1883 / ::1:1883
  ├─ Pub/Sub-Test
  │   ├─ Erstversuch: kein Empfang, timeout 124
  │   ├─ gekoppelter Versuch: Publish + Subscribe erfolgreich
  │   └─ Retained-Test: Nachricht vor Subscriber-Start publiziert, später empfangen
  └─ kontrollierter Clientfehler: Port 1884 → Connection refused

Ausgangszustand und Toolcheck

Vor Beginn wurde geprüft, dass Mosquitto und die Clients noch nicht installiert waren. Dadurch ist der spätere Installationsnachweis eindeutig und nicht nur eine Bestätigung eines bereits vorhandenen Zustands.

Nachweise

• Vor M10 sind mosquitto, mosquitto_pub und mosquitto_sub nicht vorhanden; systemctl, journalctl und ss sind verfügbar.

Installation, Dienststatus und Listener

Die Installation stellt Broker und CLI-Clients bereit. Direkt danach wurden Paketstatus, systemd-Status, Autostart und Listener geprüft, weil eine reine Paketinstallation noch keine funktionsfähige MQTT-Validierung beweist.

Nachweise:

• Mosquitto und mosquitto-clients werden installiert; mosquitto.service wird eingerichtet.
• Paketstatus, mosquitto active/enabled und lokale Listener 127.0.0.1:1883 sowie ::1:1883.

Baseline-Konfiguration und Logs

Vor weiteren Tests wurden Mosquitto-Konfigurationspfade, Hauptkonfiguration, Logs und Baseline-Kopien geprüft. Das entspricht einer sauberen Admin-Reihenfolge: erst Ist-Zustand sichern, dann interpretieren oder ändern.

Nachweise:

• Mosquitto-Konfigurationspfade, conf.d und mosquitto.conf mit include_dir.
• journalctl zeigt Dienststart; mosquitto.conf und conf.d werden als Baseline gesichert.

Pub/Sub-Erstversuch: Timing ohne Empfangsnachweis

Der erste manuelle Pub/Sub-Test lieferte keinen Nachrichtenempfang. Der Subscriber wurde durch timeout mit Exit-Code 124 beendet; die Ausgabedatei blieb leer. Daraus folgt kein Mosquitto-Broker-Ausfall: Bei Standard-QoS 0 und nicht-retained Nachrichten zeigt ein erfolgreicher Publish allein nicht, dass ein konkreter Subscriber die Nachricht erhalten hat.

Nachweise:

• Manueller Pub/Sub-Test: Subscriber endet mit timeout 124, Publish selbst ist erfolgreich, aber keine Nachricht wurde empfangen.

Erfolgreicher gekoppelter Pub/Sub-Test

Der Test wurde anschließend automatisch gekoppelt: Subscriber starten, kurz warten, Publisher senden, Subscriber abwarten. Dadurch wurden Publish-Exit-Code=0, Subscribe-Exit-Code=0 und die empfangene Nachricht nachgewiesen. Der Test zeigt die lokale Brokerfunktion; manuelle Timing-Tests bleiben dennoch anfällig.

Nachweise:

• Automatisch gekoppelter Pub/Sub-Test: Publish/Subscribe Exit-Code 0 und empfangene Nachricht.

Robuste MQTT-Validierung mit retained Message

Für einen vom manuellen Startzeitpunkt unabhängigen Test wurde zusätzlich eine Retained Message verwendet. Sie wurde vor dem Subscriber-Start auf ein Testtopic veröffentlicht und anschließend erfolgreich empfangen.

Nachweise:

• Retained Message wird veröffentlicht, späterer Subscriber empfängt m10/retained-clean M10 retained clean validation message, Exit-Codes 0, Fehlerausgabe leer.

Labor- und Sicherheitsentscheidung

Da der lokale Listener funktionierte, wurde Mosquitto nicht auf externe Interfaces geöffnet. Es wurde keine zusätzliche allow_anonymous true-Konfiguration geschrieben. Präzise einzuordnen ist: Der erfolgreiche lokale Test lief ohne produktive Authentifizierung; die Schutzwirkung im Lab besteht in der Loopback-Bindung, nicht in einer Authentifizierungslösung.

Nachweise:

• Dokumentierte Entscheidung: keine externe Öffnung, keine zusätzliche allow_anonymous-Konfiguration, Sicherheitsabgrenzung.
• Listener bleibt localhost; conf.d enthält nur README.

Kontrollierter Fehlerfall: falscher Port

Port 1884 wurde absichtlich als falscher Client-Zielport verwendet. Connection refused und Exit-Code 1 wurden gegen den aktiven Listener auf Port 1883 geprüft. Damit ist klar: Fehlerursache ist der Zielport, nicht der Broker.

Nachweise:

• Port 1883 aktiv, Port 1884 nicht; mosquitto_pub/sub melden Connection refused und Exit-Code 1.

Triage-Report

Der Report fasst Ausgangszustand, Tests, Fehleranalyse, Laborentscheidung, Sicherheitsabgrenzung und Erkenntnisse zusammen. Er ist ein eigenes Admin-Artefakt und keine bloße Screenshot-Galerie.

Nachweise:

• Report mit Ziel, Ausgangszustand, Schritten, Ergebnis und Fehleranalyse.
• Report mit Fehleranalyse, Sicherheitsabgrenzung und Erkenntnisse.

Ergebnis

Ein zusätzlicher Check zeigt ActiveState=active, SubState=running, Result=success, MainPID, Listener und Pub/Sub-Ergebnis.

Nachweise:

• M10-Dateien, Pub/Sub-Nachweis und Laborentscheidung sichtbar.
• ActiveState=active, SubState=running, Result=success, MainPID, Listener und Pub/Sub-Ergebnis sind gemeinsam sichtbar.

Zusammenfassung

Abgrenzungen

Nicht umgesetzt: externe Brokerbereitstellung, produktive MQTT-Härtung, TLS, ACLs, Authentifizierung, Firewall-Freigaben oder ein Rocky-/Remote-Client-Test gegen Mosquitto.

Erkenntnisse

Erkenntnisse M10

• Vor einer Konfigurationsänderung sollte der tatsächliche Ausgangszustand geprüft werden: Paketstatus, Dienststatus, Listener und Baseline-Konfiguration.
• systemctl beantwortet die Frage, ob der Dienst läuft; ss beantwortet, auf welchen Interfaces und Ports der Dienst lauscht.
• Ein MQTT-Pub/Sub-Test ist nur aussagekräftig, wenn der Empfang wirklich nachgewiesen wird.
• Ein Exit-Code 124 stammt vom timeout-Kommando und zeigt, dass das Zeitfenster abgelaufen ist.
• Standard-Pub/Sub mit QoS 0 und nicht-retained Nachricht ist als manueller Timing-Nachweis anfällig.
• Eine retained Message ist für einen robusteren Lab-Nachweis geeignet, weil ein später gestarteter Subscriber die zuletzt gespeicherte Nachricht erhalten kann.
• Das Nicht-Setzen von allow_anonymous true ist keine Authentifizierungsmaßnahme. Die eigentliche Begrenzung im M10-Lab ist die Loopback-Bindung.
• Ein Fehler auf Port 1884 bei aktivem Listener auf Port 1883 ist ein Client-/Zielportfehler, kein Broker-Ausfall.
• Authentifizierung, ACLs, TLS, Netzfreigabe und Firewall wurden nicht umgesetzt; der Broker blieb auf die Loopback-Schnittstelle begrenzt.

Nachweis 147M10

Nachweis 148M10

Nachweis 149M10

Nachweis 150M10

Nachweis 151M10

Pub/Sub-Erstversuch: Timingfehler

Nachweis 152M10

Nachweis 153M10

MQTT-Validierung mit Retained Message

Nachweis 154M10

Nachweis 155M10

Nachweis 156M10

Nachweis 157M10

Nachweis 158M10

Nachweis 159M10

Nachweis 160M10

Nachweis 161M10

System: Debian debian13
Benutzerkontext: student
Arbeitsordner: /home/student/linux_m11

Kurzfassung

In M11 wurde ein Bash-basiertes Healthcheck-Skript erstellt, das Dateisystembelegung, Speicherstatus, Load/Uptime und fehlgeschlagene systemd-Units protokolliert. Das Skript wurde manuell geprüft, als systemd-oneshot-Service eingebunden, über einen systemd.timer automatisiert ausgeführt und über list-timers, Journal sowie Logdatei validiert. Eine fehlerhafte Documentation=-Freitextzeile in der Service-Unit wurde erkannt und korrigiert. Nach dem Lab-Test wurde der Timer kontrolliert deaktiviert. M11 ist kein produktives Monitoring-System, sondern ein nachvollziehbarer systemd-basierter Automatisierungsnachweis.

Strukturelle Übersicht

Nachweis 162M11

Technische Übersicht

1. Ausgangszustand und Toolcheck

Ziel: Reproduzierbaren Startzustand für die Automatisierung erfassen.

Ein systemd-Timer ist nur sinnvoll dokumentierbar, wenn vorher klar ist, auf welchem System, mit welchen Werkzeugen und mit welchem Ausgangszustand gearbeitet wurde.

Arbeitsschritte und Nachweise: Im Arbeitsordner /home/student/linux_m11 wurden Host, Benutzer, Pfad, Datum, Toolverfügbarkeit und fehlgeschlagene Units geprüft.

Nachweise:

• Startzustand von M11: Toolbasis vorhanden und keine failed Units.

Ergebnis: Die Werkzeugbasis war vollständig vorhanden; systemctl --failed zeigte keine fehlgeschlagenen Units.

Erkenntnisse / Hinweise: Vor einer Automatisierung erst den Systemzustand prüfen, damit spätere Timer-/Service-Fehler nicht mit Altproblemen verwechselt werden.

Nachweis 163M11

2. Healthcheck-Skript mit festem Projektpfad

Ziel: Ein wiederverwendbares Bash-Skript erstellen, das relevante Systemwerte protokolliert.

Das Skript ist die fachliche Nutzlast des Moduls. Die systemd-Units automatisieren nur dessen Ausführung. Der Logpfad wurde bewusst fest auf /home/student/linux_m11 gesetzt, weil $HOME im systemd-Kontext je nach Benutzerkontext uneindeutig sein kann.

Arbeitsschritte und Nachweise: Das korrigierte Skript nutzt df -h /, free -h, uptime und systemctl --failed --no-pager. Die Ausgabe wird mit tee -a parallel im Terminal und in der Projektlogdatei gespeichert.

Nachweise:

• Korrigiertes Healthcheck-Skript mit festem Projektpfad und relevanten Systemprüfungen.

Ergebnis: Das Skript ist ausführbar, enthält die relevanten Healthcheck-Bausteine und schreibt konsistent in die Projektlogdatei.

Erkenntnisse / Hinweise: Feste Pfade sind bei systemd-Services robuster als implizite Umgebungsvariablen.

Nachweis 164M11

#!/bin/bash

PROJECT_DIR="/home/student/linux_m11"
LOG_FILE="$PROJECT_DIR/logs/m11_healthcheck.log"

mkdir -p "$(dirname "$LOG_FILE")"

{
  echo "===== M11 Healthcheck ====="
  echo "Zeitpunkt: $(date)"
  echo "Host: $(hostname)"
  echo "Ausgeführt als: $(whoami)"
  echo

  echo "=== Dateisystem / ==="
  df -h /
  echo

  echo "=== Speicherstatus ==="
  free -h
  echo

  echo "=== Load Average / Uptime ==="
  uptime
  echo

  echo "=== Fehlgeschlagene systemd-Units ==="
  systemctl --failed --no-pager || true
  echo

  echo "=== Ende Healthcheck ==="
  echo
} | tee -a "$LOG_FILE"

exit 0

3. Manuelle Validierung vor systemd

Ziel: Skriptfehler vor der Integration in systemd ausschließen.

Wenn ein Skript bereits manuell fehlschlägt, ist systemd nicht die Ursache. Die manuelle Prüfung trennt Skriptlogik von Unit- und Timerlogik.

Arbeitsschritte und Nachweise: Das Skript wurde mit bash -n geprüft, anschließend manuell ausgeführt und die erzeugte Logdatei kontrolliert.

Nachweise:

• Manueller Healthcheck-Lauf vor systemd-Einbindung erfolgreich.
• Logdatei wurde erzeugt und enthält den manuellen Healthcheck-Lauf.

Ergebnis: bash -n bestätigte die Syntax. Der manuelle Wrapperlauf endete mit Exit-Code 0; die sichtbaren Ausgaben und die Logdatei zeigen Dateisystem, Speicher, Load/Uptime und failed Units. Wegen des abschließenden exit 0 ist der Exit-Code allein kein Beleg für jeden Teilcheck.

Erkenntnisse / Hinweise: Automatisierung erst nach erfolgreichem manuellen Test aktivieren.

Nachweis 165M11

Nachweis 166M11

4. systemd-Service als oneshot

Ziel: Das Healthcheck-Skript als systemd-Service ausführbar machen.

Type=oneshot passt für kurz laufende Admin-Aufgaben. Der Dienst startet das Skript, wartet auf dessen Ende und ist danach wieder inactive (dead). Dieser Zustand ist nach erfolgreichem Lauf kein Fehler.

Arbeitsschritte und Nachweise: Die Service-Datei wurde unter /etc/systemd/system/m11-healthcheck.service erstellt, per daemon-reload eingelesen und nach der Korrektur erfolgreich gestartet.

Nachweise:

• Korrigierte Service-Datei wurde neu geladen und erfolgreich gestartet.
• Service lief nach Bereinigung erfolgreich; Journal enthält Healthcheck-Ausgaben.
• Service-Ausführung ist in der Projektlogdatei nachvollziehbar.

Ergebnis: Der Service-Wrapper endete mit Result=success und ExecMainStatus=0; Journal und Logdatei enthalten Healthcheck-Ausgaben. Wegen der Skriptlogik beschreiben diese Statuswerte nur das Ende der Wrapper-Ausführung, nicht den Erfolg jedes einzelnen Systemchecks.

Erkenntnisse / Hinweise: Bei einem oneshot-Service ist inactive (dead) nach dem Lauf normal. Result und ExecMainStatus müssen zusammen mit Skriptlogik, Journal und Loginhalt gelesen werden; hier maskieren || true, die Pipeline ohne pipefail und das abschließende exit 0 mögliche Teilfehler.

Nachweis 167M11

Nachweis 168M11

[Unit]
Description=M11 Healthcheck Service

[Service]
Type=oneshot
User=student
WorkingDirectory=/home/student/linux_m11
ExecStart=/home/student/linux_m11/scripts/m11_healthcheck.sh

5. Korrektur der Documentation-Zeile

Ziel: Unit-Warnungen erkennen und bereinigen.

Die ursprüngliche Documentation=-Zeile enthielt Freitext, obwohl systemd dort gültige Dokumentations-URIs erwartet. systemd meldete deshalb eine Warnung; der Healthcheck selbst lief weiter.

Arbeitsschritte und Nachweise: Die Freitextzeile wurde entfernt, die Unit neu geschrieben, per daemon-reload eingelesen und der Service erneut gestartet.

Nachweise:

• Korrigierte Service-Datei wurde neu geladen und erfolgreich gestartet.

Ergebnis: Die korrigierte Service-Datei enthält keine fehlerhafte Documentation=-Direktive mehr.

Erkenntnisse / Hinweise: Journal-Ausgaben sollten nicht nur auf harte Fehler, sondern auch auf Warnungen geprüft werden.

Ergänzende Einordnung zum bereits gezeigten Bildnachweis.

6. systemd-Timer erstellen

Ziel: Die Ausführung des Healthchecks über einen Timer planen.

Ein systemd-Timer ist für wiederkehrende Aufgaben direkt in systemctl und journalctl eingebunden. Für den Lab-Nachweis wurden kurze Intervalle verwendet, damit der automatische Lauf sichtbar geprüft werden konnte.

Arbeitsschritte und Nachweise: Die Timer-Unit definiert OnBootSec=1min, OnUnitActiveSec=2min und triggert m11-healthcheck.service.

Nachweise:

• systemd-Timer ist definiert und aktiviert später den Healthcheck-Service.
• Timer-Definition ist vorhanden; Aktivierung erfolgt erst im nächsten Schritt.

Ergebnis: Der Timer war korrekt geladen, aber vor der Aktivierung noch disabled/inactive.

Erkenntnisse / Hinweise: Timer-Erstellung und Timer-Aktivierung sind getrennte Schritte.

Nachweis 169M11

Nachweis 170M11

7. Timer aktivieren und geplante Ausführung prüfen

Ziel: Timer aktivieren und dessen geplante Ausführung sichtbar machen.

Erst enable --now macht aus der definierten Timer-Datei eine aktive Automatisierung. list-timers zeigt, welche Unit aktiviert wird und wann die nächste oder letzte Ausführung liegt.

Arbeitsschritte und Nachweise: Der Timer wurde mit systemctl enable --now aktiviert, danach mit status, is-enabled, list-timers und einem kompakten Service-Status geprüft.

Nachweise:

• Timer wurde aktiviert und wartet auf geplante Ausführung.
• Service bleibt als oneshot nach Lauf erfolgreich inactive/dead.

Ergebnis: Der Timer war active (waiting), enabled und als Trigger für m11-healthcheck.service sichtbar.

Erkenntnisse / Hinweise: enable --now ist ein präziser Lab-Befehl, weil Aktivierung und Start im selben Schritt nachweisbar sind.

Nachweis 171M11

Nachweis 172M11

8. Timerlauf über list-timers, Journal und Log einordnen

Ziel: Belegen, dass der Timer den Healthcheck tatsächlich automatisiert ausgelöst hat.

Eine Timer-Datei allein beweist keine Automatisierung. Den eigentlichen Timer-Trigger belegt hier systemctl list-timers mit LAST, NEXT und der aktivierten Service-Unit. Journal und Logdatei belegen ergänzend, dass der Service erfolgreich ausgeführt wurde und Healthcheck-Ausgaben erzeugt hat; sie zeigen für sich allein jedoch nicht eindeutig den Auslöser eines einzelnen Service-Starts.

Arbeitsschritte und Nachweise: Nach Wartezeit wurden list-timers, systemctl show, journalctl -u m11-healthcheck.service und die Logdatei geprüft.

Nachweise:

• Timer hat den Healthcheck-Service tatsächlich ausgelöst.
• Journal belegt mehrere erfolgreiche Healthcheck-Service-Läufe; die Timer-Auslösung selbst ist in S08a über list-timers belegt.
• Logdatei bestätigt Healthcheck-Ausgaben aus Service-Läufen; der konkrete Timer-Trigger wird über S08a belegt.
• Mehrere Healthcheck-Läufe wurden in der Logdatei protokolliert; spätere Einträge passen zur Timer-Validierung aus S08a.

Ergebnis: Mehrere Healthcheck-Läufe sind im Journal und in der Logdatei sichtbar. Result=success und ExecMainStatus=0 zeigen eine beendete Wrapper-Ausführung; welche Teilchecks verwertbare Ergebnisse lieferten, ergibt sich aus den protokollierten Ausgaben.

Erkenntnisse / Hinweise: Automatisierung muss mit Ausführungsnachweisen validiert werden, nicht nur mit Konfigurationsdateien.

Nachweis 173M11

Nachweis 174M11

9. Timer kontrolliert deaktivieren

Ziel: Den Lab-Endzustand sauber herstellen.

Ein Test-Timer sollte im Lernsystem nicht unkontrolliert weiterlaufen. Das Deaktivieren ist Teil verantwortlicher Administration.

Arbeitsschritte und Nachweise: Der Timer wurde mit disable --now deaktiviert. Danach wurden Enabled-Status, Active-Status und list-timers geprüft.

Nachweise:

• Lab-Timer wurde kontrolliert beendet.

Ergebnis: Der Timer steht auf disabled und inactive; in list-timers erscheint kein aktiver M11-Timer mehr.

Erkenntnisse / Hinweise: Automatisierung sauber zurücknehmen ist ein eigener Betriebsnachweis.

Nachweis 175M11

10. Technischer Report und Endzustand

Ziel: Umsetzung, Ergebnis und Abgrenzung in einem Admin-Report zusammenfassen.

Ein Report bündelt Durchführung, beobachtete Ergebnisse und Grenzen. M11 bleibt ein systemd-basierter Automatisierungsnachweis und kein produktives Monitoring.

Arbeitsschritte und Nachweise: Der Report dokumentiert Komponenten, Healthcheck-Inhalte, Umsetzung, Ergebnis, Abgrenzung und Erkenntnisse. Die Ergebnisübersicht zeigt Dateien, Skriptstatus, Units, Timer-Endzustand, Journal und Log.

Nachweise:

• Technischer Report fasst Komponenten und Umsetzung nachvollziehbar zusammen.
• Report grenzt M11 klar von produktivem Monitoring ab.
• Die Übersicht zeigt lokale Artefakte und die korrigierte Service-Datei.
• Timerzustand, Journal und letzte Service-Ausgaben sind gemeinsam sichtbar.
• Logausgabe belegt wiederholte Healthcheck-Ausgaben.

Ergebnis: M11 dokumentiert die Kette aus Skript, Service, Timer, Journal- und Logbeobachtung sowie kontrollierter Deaktivierung. Der technische Beleg bleibt auf diese Laborabläufe und die jeweils sichtbaren Ausgaben begrenzt.

Erkenntnisse und Hinweise: Aktivierung, Timerlauf und kontrollierte Deaktivierung werden getrennt gezeigt.

Nachweis 176M11

Nachweis 177M11

Abgrenzung

Nicht umgesetzt wurden produktives Monitoring, Alerting, E-Mail-Benachrichtigung, Schwellwertlogik, Prometheus/Grafana und ein vollständiger Monitoring-Stack.

Erkenntnisse und Hinweise

Nachweis 178M11

Nachweis 179M11

Nachweis 180M11

Timerlauf: Journal (Teil 2)

Nachweis 181M11

Timerlauf: Logausgaben (Teil 3)

Nachweis 182M11

Timer- und Journalzustand

Nachweis 183M11

Logausgaben

Nachweis 184M11

Überblick

M01 bis M11 dokumentieren einen aufeinander aufbauenden Arbeitsweg von Lab-Grundlagen über Shell, Paketverwaltung, Rechte, Monitoring, systemd, Remote-Administration und Scripting bis zu lokaler MQTT-Funktionsprüfung und systemd-basierter Healthcheck-Automatisierung.

M01 bis M03 behandeln Systembasis, Shell und Textauswertung; M04 bis M06 Paketverwaltung, Rechte und Systemzustand; M07 und M08 Dienste sowie Remote-Administration; M09 bis M11 Scripting, MQTT und systemd-Automatisierung.

3. Entwicklungslinie des Kurses

M01 Lab-Basis und SSH-Erstkontakt
→ M02 Shell, Dateisystem und Hilfesysteme
→ M03 Textströme, Filter, Reports, Archiv/Restore
→ M04 Paketverwaltung Debian/Rocky
→ M05 Benutzer, Gruppen und Rechte
→ M06 Prozesse, Jobs und Basismonitoring
→ M07 systemd-Service-Triage
→ M08 Netzwerkdiagnose, SSH-Key, scp und rsync
→ M09 Bash-Scripting-Grundlagen
→ M10 lokale Mosquitto/MQTT-Funktionsvalidierung
→ M11 Healthcheck mit systemd-Service und systemd-Timer
→ M12 Kursüberblick, Arbeitsfelder und fachliche Grenzen

Die Module bauen fachlich aufeinander auf und verbinden die einzelnen Werkzeuge zu zusammenhängenden Arbeitsabläufen.

Arbeitsfelder und technische Inhalte

5. Zusammenhängende Arbeitsabläufe

6. Fachliche Grenzen

Nicht Bestandteil der dokumentierten Arbeiten sind:

Security-Hardening-Maßnahmen
Monitoring mit Alerting
Prometheus/Grafana oder ein Monitoring-Stack
komplexe Netzwerkarchitekturen
Cloud-, Container- oder DevOps-Umsetzungen
vollständige LPIC-1-Prüfungsvorbereitung
Aufgaben außerhalb der dokumentierten Laborabläufe

Die dokumentierten Arbeiten umfassen Linux-Grundlagen, Remote-Administration, Paket- und Rechteverwaltung, systemd, Troubleshooting, Bash-Scripting und eine einfache systemd-basierte Automatisierung in einer Lern- und Laborumgebung.

7. Erkenntnisse über den gesamten Kurs

1. Ausgangszustand, Durchführung und Ergebnis wurden getrennt erfasst. Dadurch bleiben Änderungen und Prüfungen nachvollziehbar.
2. Analysierte Fehlerfälle zeigen Ursache, Maßnahme und Ergebnis. Beispiele stehen in M04, M07, M10 und M11.
3. Werkzeuge werden entsprechend ihrer Funktion eingesetzt. ps liefert eine Momentaufnahme, top eine Live-/Batch-Ansicht, systemctl den Dienstzustand, journalctl Logs und ss die Socketebene.
4. SSH, MQTT, sudo, systemd und Monitoring bleiben auf die tatsächlich umgesetzten Laborfunktionen begrenzt.
5. Die Automatisierung zeigt Aktivierung, Timerlauf und kontrollierte Deaktivierung.

8. Zusammenfassung

M01 bis M11 bilden zusammen den Arbeitsweg von der Linux-Systembasis über Administration und Fehleranalyse bis zu Scripting und systemd-Automatisierung ab.