Azubi-Projekt: Java Applikationsserver

Ein Dienst, der laufen soll – aber nicht läuft. Ein Logfile, das alles weiß.
Deine Aufgabe: herausfinden, was das Logfile dir sagen will.

Ausgangslage

Auf dem Server läuft eine kleine Java-Statusanwendung: der azubi-statusapp-Dienst. Er ist als systemd-Unit eingerichtet, soll unter Port 8080 antworten und bei Aufruf eine JSON-Antwort liefern. Tut er aber nicht.

Dein Auftrag: Den Dienst zum Laufen bringen – nachhaltig, sauber, dokumentiert.

Das Ziel ist erreicht, wenn dieser Aufruf funktioniert: 

curl -s http://localhost:8080/status

…und eine JSON-Antwort mit „status“:„ok“ zurückkommt – lokal auf dem Server und von einem zweiten Rechner aus über die IP-Adresse des Servers.

Was dich erwartet

Es gibt mindestens einen Fehler – möglicherweise mehrere. Ein behobener Fehler kann den nächsten erst sichtbar machen. Das ist kein Versehen, sondern die Realität: In der Produktion steht auch nicht dabei, wie viele Probleme auf dich warten.

Arbeite dich Schritt für Schritt durch. Teste nach jeder Änderung erneut, bevor du weitersuchst.

Dieses Projekt richtet sich an das 2. Lehrjahr. Du kennst systemd, Dateirechte und Firewall bereits. Neu ist der Java-Kontext: JAR-Datei, Konfigurationsdatei, Java-Exceptions im Log. Diese Unterschiede lernst du hier kennen.

Lernziele

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

  • Den Unterschied zwischen einem Fehler, den systemd meldet, und einem Fehler, den die Java-Anwendung selbst wirft – und wie du beides im Log erkennst
  • Eine systemd-Unit-Datei auf Syntaxfehler prüfen, bevor du sie startest
  • Warum systemctl daemon-reload nach jeder Änderung an einer Unit-Datei zwingend nötig ist – und was passiert, wenn du es vergisst
  • Benutzer, Dateiberechtigungen und Eigentümerschaft im Kontext eines laufenden Dienstes prüfen
  • Einen Port auf Belegung prüfen und Firewall-Regeln gezielt setzen
  • Den Unterschied zwischen lokalem Test (localhost) und externem Test erklären und beide durchführen

Die Spielregeln

⚠ Keine Holzhammer-Lösungen

Folgende Maßnahmen gelten nicht als Lösung – auch wenn der Fehler danach verschwindet:

  • systemctl stop firewalld – die Firewall abschalten
  • Den Dienst als root statt als vorgesehenen Service-User laufen lassen
  • Berechtigungen pauschal auf 777 setzen

Finde die eigentliche Ursache und behebe genau die. Alles andere ist Symptombehandlung.

⚠ Pflicht nach jeder Änderung an der Unit-Datei

Wer die Datei /etc/systemd/system/azubi-statusapp.service ändert, muss danach zwingend ausführen: 

systemctl daemon-reload

Ohne diesen Schritt sieht systemd weiterhin die alte Version – ein klassischer Stolperstein, der viel Zeit kostet.

Systematisch vorgehen – von außen nach innen

Ein guter Administrator springt nicht direkt in die Konfiguration. Er liest zuerst die Situation – von außen nach innen:

Schritt Frage Womit
1. Erreichbarkeit Kommt überhaupt eine Antwort? Welcher Fehler genau? curl, Browser
2. Dienststatus Läuft der Dienst? Ist er aktiviert? Startet er in einer Schleife? systemctl status
3. Unit-Datei Hat die Konfigurationsdatei Syntaxfehler? systemd-eigenes Prüfwerkzeug (Manpage)
4. Logs Was meldet systemd? Was meldet die Java-Anwendung selbst? journalctl -xeu azubi-statusapp
5. Dateisystem Existieren JAR-Datei und Konfiguration? Wer darf sie lesen? Existiert der Service-User? ls -l, id, getent passwd
6. Netzwerk Lauscht der Dienst auf dem richtigen Port? Ist der Port von außen erreichbar? ss -tlnp, firewall-cmd

Halte diese Reihenfolge ein. Ein Fehler in Schritt 2 kann Fehler in Schritt 4 verbergen. Wer mit Schritt 6 beginnt, repariert möglicherweise das Falsche.

Werkzeugkasten

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

Bereich Werkzeuge und Ansatzpunkte
HTTP-Antwort testen curl, Browser
Dienststatus systemctl status, systemctl is-active, systemctl is-enabled
Unit-Datei prüfen Ein systemd-eigenes Analysewerkzeug (Hinweis: Manpage zu systemd-analyze)
Logs lesen journalctl -u azubi-statusapp, journalctl -xeu azubi-statusapp --no-pager
Unit-Konfiguration /etc/systemd/system/azubi-statusapp.service
Anwendungskonfiguration /etc/azubi-statusapp/app.properties
Dateien und Rechte ls -l, ls -la, chmod, chown
Benutzer prüfen id <benutzername>, getent passwd <benutzername>
Netzwerk und Ports ss -tlnp, firewall-cmd --list-ports
Java-Prozess ps aux | grep java

Lokaler Test reicht nicht

curl http://localhost:8080/status testet nur die lokale Sicht des Servers. Manche Fehler – insbesondere Firewall-Regeln – werden dabei nicht sichtbar, weil lokaler Datenverkehr anders behandelt wird als Datenverkehr von außen.

Teste am Ende immer auch von einem zweiten Rechner über die IP-Adresse des Servers. Erst dann ist das Ziel wirklich erreicht.

Dokumentationspflicht

Halte für jeden gefundenen Fehler fest:

  1. Wie hast du ihn entdeckt – welcher Befehl, welche Auffälligkeit im Log?
  2. Was war die Ursache?
  3. Wie hast du ihn behoben?

Diese Dokumentation ist Teil der Bewertung – nicht nur das Endergebnis.

Abgabe

Kurze mündliche oder schriftliche Zusammenfassung anhand deiner Dokumentation, plus Live-Demo: curl lokal und extern liefert eine JSON-Antwort mit „status“:„ok“.

Das Projektdokument

Vollständige Aufgabenstellung – als LaTeX oder PDF

Das Dokument enthält alle Anforderungen, Spielregeln und den Werkzeugkasten in druckbarer Form.
Lösungshinweise für Ausbilder sind ausschließlich im Ausbilder-Dokument enthalten.

Overleaf (Quelldatei + Live-Vorschau):
→ Overleaf: Azubi-Projekt Java Applikationsserver

⬇ Aufgabenstellung herunterladen (PDF)

↑ Übersicht – Der Weg zur Macht
← Projekt: Webserver
→ Projekt: Freigabeserver

„Das Logfile lügt nicht. Es redet nur manchmal in Rätseln.“

[azubi02@rhel9-kurs ~]$ _