Azubi-Projekt: Freigabeserver

Drei Protokolle. Eine Partition. Zwei Server. Und irgendwo ein Fehler –
oder mehrere. Das hier ist kein Tutorial.

Worum geht es

Ein Unternehmen braucht einen zentralen Dateiserver. Keine Cloud, kein Fertigprodukt – ein echter RHEL-Server, den du von Grund auf aufbaust und anschließend unter realen Fehlerbedingungen reparierst.

Dieses Projekt hat zwei Phasen:

Phase	Was du tust	Wie
1 – Aufbau	Du baust den Freigabeserver vollständig selbst auf	Konstruktiv, Schritt für Schritt
2 – Fehlersuche	Du bekommst einen kaputten Server und reparierst ihn	Diagnostisch, systematisch

Beide Phasen sind Pflicht. Phase 2 setzt voraus, dass du Phase 1 verstanden hast – nicht nur durchgeführt.

Voraussetzungen

Dieses Projekt benötigt zwei separate RHEL-VMs im selben Netzwerk:

fs01 – der Freigabeserver, den du aufbaust oder reparierst
azubi-server – der Client, der von außen testet, ob die Freigaben erreichbar sind

Beide VMs müssen sich gegenseitig per DNS erreichen können. Dein Ausbilder richtet die Umgebung ein und gibt dir den Startschuss.

Außerdem solltest du mitbringen:

Sicherer Umgang mit der Kommandozeile, Dateisystem und Berechtigungen
Verständnis für Netzwerk: IP-Adressen, Ports, Firewall
Erfahrung mit systemd und journalctl aus dem 1. Lehrjahr

Lernziele

Was du nach diesem Projekt kannst – und erklären kannst:

LVM: Partitionierung, Volume Groups, Logical Volumes anlegen und einbinden
DNS: BIND-Zonedateien schreiben, Resolver konfigurieren, Namensauflösung testen und reparieren
NFS: exports-Datei, SELinux-Kontexte, Firewall-Regeln – und warum alle drei zusammenspielen müssen
Samba: smb.conf verstehen, Samba-User verwalten, Windows-Freigaben einrichten
SFTP mit Chroot: SSH-basierter Zugriff mit eingeschränktem Dateisystem
Automatisierung: rsync-Sync-Jobs mit Cron einrichten und deren Umgebung korrekt konfigurieren
Fehlerdiagnose: Drei Protokolle gleichzeitig betreiben, gegenseitige Abhängigkeiten erkennen, Fehler schichtweise aufdecken

Phase 1 – Aufbau

Du baust den Server Schritt für Schritt auf. Dein Ausbilder schaltet Phasen frei, sobald die vorherige abgenommen ist. Die Reihenfolge ist nicht zufällig – jeder Baustein hängt vom vorherigen ab:

Schritt	Baustein	Warum in dieser Reihenfolge
0	LVM & Partition	Alle Freigaben liegen auf einem eigenen Logical Volume
1	DNS	Ohne Namensauflösung sind alle weiteren Tests über Hostnamen wertlos
2	NFS	Netzwerkdateisystem für Linux-Clients
3	Samba	SMB-Freigabe für Windows-Clients
4	SFTP	SSH-basierter Zugriff mit Chroot
5	rsync / Cron	Automatisierte Sicherung auf den Client

Abnahme je Schritt: Der Ausbilder prüft, ob deine Konfiguration korrekt ist, bevor der nächste Schritt freigeschaltet wird. Tempo ist dabei kein Maßstab – Verständnis ist es.

Die vollständige Schritt-für-Schritt-Anleitung liegt im Aufbau-Dokument (siehe unten).

Phase 2 – Fehlersuche

Dein Ausbilder versetzt den Server, den du in Phase 1 aufgebaut hast, in einen fehlerhaften Zustand. Alle Bausteine funktionierten vorher – jetzt ist mindestens einer davon gestört.

Das Ziel ist erreicht, wenn:

Alle drei Freigabewege funktionieren: NFS, Samba und SFTP
DNS löst beide Hostnamen korrekt auf
Ein manuell angestoßener Sync-Lauf per rsync synchronisiert erfolgreich auf den Client

Der Test erfolgt sowohl lokal auf fs01 als auch vom azubi-server aus. Nur lokal funktioniert gilt nicht.

Du weißt vorher nicht, wie viele Fehler eingebaut sind. Es gibt drei Schwierigkeitsstufen – welche du bekommst, entscheidet dein Ausbilder:

Level	Charakter
Easy	Wenige, klar abgegrenzte Fehler in einem Bereich
Medium	Mehrere Fehler in verschiedenen Schichten, die sich gegenseitig verdecken können
Hard	Alle Komponenten betroffen – volle Komplexität

Spielregeln

⚠ Keine Holzhammer-Lösungen

Folgende Maßnahmen gelten in beiden Phasen nicht als Lösung:

setenforce 0 – SELinux deaktivieren
systemctl stop firewalld – die Firewall abschalten
chmod 777 auf Freigabeverzeichnisse

Finde die eigentliche Ursache. Behebe genau die. Alles andere ist Symptombehandlung – und fällt im Nachgespräch sofort auf.

Verändere nur, was für die Fehlerbehebung nötig ist. Wenn du dir bei einer Änderung nicht sicher bist, dokumentiere die Überlegung – auch das zählt.

Systematisch vorgehen

Auch hier gilt: von außen nach innen – und bei diesem Projekt gibt es eine wichtige Reihenfolge innerhalb der Schichten:

Schritt	Frage	Warum zuerst
1. DNS	Löst `dig` beide Hostnamen korrekt auf?	Ohne DNS sind alle Folgetests über Hostnamen wertlos
2. Partition / Mount	Ist `/srv/freigabe` gemountet, mit korrekten Besitzrechten?	Alle Protokolle greifen auf denselben Mountpoint zu
3. NFS	Werden Exports angezeigt? Mountet der Client?	`showmount -e`, Testmount vom Client
4. Samba	Ist die Konfiguration syntaktisch korrekt? Erscheint die Freigabe?	`testparm`, `smbclient -L`
5. SFTP	Verbindet der Client? Kann er in den Upload-Ordner schreiben?	`sftp`, Chroot-Prüfung
6. Automatisierung	Läuft das Sync-Skript manuell? Funktioniert der Cron-Job?	Zuletzt – setzt alle anderen Komponenten voraus

Nach jeder Änderung neu testen. Ein behobener Fehler kann den nächsten erst sichtbar machen.

SELinux-Hinweis: Nicht vorschnell verdächtigen – und niemals abschalten. Erst getenforce und ausearch -m avc -ts recent prüfen. SELinux meldet genau, was es blockiert hat.

Werkzeugkasten

Du musst nicht alle Befehle auswendig kennen. Teil der Übung ist, sie bei Bedarf nachzuschlagen – man <befehl>, <befehl> --help, oder das Vorbereitungsdokument.

Bereich	Werkzeuge und Ansatzpunkte
DNS	`dig`, `named-checkconf`, `named-checkzone`
Storage / Mount	`df -h`, `mount`, `lsblk`, `ls -la`
NFS	`showmount -e`, `exportfs -v`, `journalctl -u nfs-server`
Samba	`testparm`, `smbclient -L`, `journalctl -u smb`
SFTP / SSH	`sshd -t`, `sftp`, `journalctl -u sshd`
SELinux	`getenforce`, `ls -Z`, `getsebool -a`, `ausearch -m avc -ts recent`
Firewall	`firewall-cmd --list-services`, `firewall-cmd --list-ports`
Automatisierung	`crontab -l`, `tail -f /var/log/sync-freigabe.log`

Dokumentationspflicht

Halte für jeden gefundenen Fehler fest:

Wie hast du ihn entdeckt – welcher Befehl, welche Ausgabe hat dich darauf gebracht?
Was war die Ursache?
Wie hast du ihn behoben?

Diese Dokumentation ist zu 20 % Teil der Bewertung. Nicht nur das Endergebnis zählt.

Bewertung

Kriterium	Anteil
Alle Fehler gefunden und dauerhaft behoben	40 %
Korrekte, nachhaltige Lösung (kein Quick Fix)	30 %
Klare, nachvollziehbare Dokumentation	20 %
Selbstständigkeit	10 %

Wenn du stecken bleibst

Das ist normal. Ein Freigabeserver hat viele Komponenten, die sich gegenseitig beeinflussen – das ist kein Fehler im Projekt, sondern sein Kern.

15 Minuten eigenständig weitersuchen – welchen Schritt im Schema hast du noch nicht gemacht?
Logs nochmal lesen – diesmal langsamer, auf Zeitstempel und Fehlercodes achten
Protokolle einzeln testen – nicht „es geht nicht“, sondern: welches der drei Protokolle genau?
Dann den Ausbilder fragen – es gibt gestufte Hinweise, keine direkten Lösungen

Abgabe und Nachbesprechung

Abgabe: Kurze Zusammenfassung anhand deiner Dokumentation, plus Live-Demo aller drei Freigabewege und eines erfolgreichen manuellen Sync-Laufs – vom Client aus getestet.

Nachbesprechung mit dem Ausbilder:

Welcher Fehler war am schwierigsten zu finden – und warum?
Warum haben manche Fehler andere verdeckt?
Wie würde man das in der Produktion überwachen?
Was hättest du beim nächsten Mal schneller gesehen?

Diese Reflexion ist genauso wichtig wie die technische Fertigstellung.

Projektdokumente

Alle Unterlagen – als LaTeX oder PDF

Lies das Vorbereitungsdokument, bevor du mit Phase 1 beginnst.
Lösungshinweise für Ausbilder sind ausschließlich in den Ausbilder-Dokumenten enthalten und hier nicht verlinkt.

Overleaf (Quelldateien + Live-Vorschau):
→ Overleaf: Azubi-Projekt Freigabeserver

↑ Übersicht – Der Weg zur Macht
← Projekt: Java Applikationsserver

„Drei Protokolle, eine Ursache – oder drei Ursachen. Das Logfile weiß es.
Du musst nur lernen, es zu fragen.“

[azubi02@rhel9-kurs ~]$ _