Betrieb¶

Unter Administration > Betrieb (/v2/admin/operations) wird die laufende Anlage verwaltet: geplante Aufgaben, Cache, Datenbanksicherungen, TLS-Zertifikate und Ablagepfade. In calServer V1 war das der Tab „Administration" der Grundeinstellungen.

Drei Berechtigungen auf einer Seite

Die Tabs hängen an verschiedenen Operationen, weil die Endpunkte dahinter es tun. Ein Tab, dessen Operation der Benutzer nicht hält, wird ausgeblendet — die Seite läuft nicht in einen Fehler.

Tab	Operation
Geplante Aufgaben (inkl. Cache)	`administration_management`
Sicherungen	`database_management_admin`
Zertifikate	`basic_setting_admin`
Dateispeicher	`basic_setting_admin`

Datenbankstand¶

Die erste Karte im Tab Geplante Aufgaben. Sie ist im Normalfall zugeklappt und meldet sich nur, wenn etwas nicht stimmt — dann aber als Erstes, weil sie die Ursache nennt, deren Folgen darunter stehen.

Meldung	Bedeutung
Das Schema ist auf dem Stand des Programms	Alle mitgelieferten Migrationen sind gelaufen. Der Normalfall.
n Migrationen stehen aus	Der Migrationslauf beim Start des Containers ist abgebrochen. Alles nach der gescheiterten Migration blieb liegen — und bleibt es, denn der nächste Start scheitert an derselben Stelle.
Diese Datenbank wurde nie migriert	Es gibt keine Tabelle `migrations`. Das Schema ist nicht eingerichtet.
Der Datenbankstand lässt sich nicht ermitteln	Die Datenbank hat auf die Frage nicht geantwortet. Der Grund steht daneben.

Warum das an ganz anderer Stelle auffällt

Ein abgebrochener Migrationslauf hält den Container nicht auf — die Anlage startet, die Oberfläche kommt hoch. Was die ausgelassenen Migrationen angelegt hätten, fehlt aber: Ein Verwaltungsbildschirm bleibt leer, ein anderer antwortet mit HTTP 500. Wer nur die Symptome sieht, sucht den Fehler in der Seite, die nichts anzeigt. Diese Karte nennt stattdessen die Ursache.

Was zu tun ist: Der Grund des Abbruchs steht im Startprotokoll des Containers (docker logs calserver-api-v2, Zeilen ab ERROR:). Ist er behoben, holt der Lauf den Rest nach:

docker exec calserver-api-v2 php artisan migrate --force

Ausgeführt wird über die Oberfläche bewusst nichts. Ein Migrationslauf auf gewachsenen Kundendaten ist nichts, was hinter einen Knopf gehört.

Geplante Aufgaben¶

Was calServer regelmäßig von selbst tut: Mailversand, Terminerinnerungen, zeitbasierte Statusregeln, MET/TEAM-Abgleich, Aufräumarbeiten.

Welche Aufgaben es gibt, liefert calServer mit

Hier wird eingestellt, ob und wann eine Aufgabe läuft — nicht, welche es gibt. Der Katalog kommt mit dem Programmstand, deshalb ist die Liste auf einer frischen Installation vollständig, und eine in einem Update ergänzte Aufgabe erscheint von selbst.

Ein eigener Befehl lässt sich bewusst nicht eintragen: Ein Feld, dessen Inhalt der Server ausführt, wäre ein Weg, sich über die Oberfläche mehr Rechte zu verschaffen, als die Rolle hergibt.

Dies ersetzt die Cron Jobs früherer Stände. Jene Tabelle gehörte calServer V1; calServer V2 hat sie nie ausgeführt. Sie bleibt unangetastet, solange beide Stände nebeneinander laufen.

Der Balken ganz oben¶

Er beantwortet die Frage, die bei einer Störung zuerst kommt: Arbeitet der Zeitplan überhaupt?

Meldung	Bedeutung
Der Scheduler arbeitet	Es wurden Läufe protokolliert. Alles im Normalbetrieb.
Der Scheduler ist angehalten	Jemand hat ihn über Anhalten gestoppt. Fortsetzen hebt das auf, sofort und ohne Neustart. Der Zustand liegt in der Datenbank und überlebt einen Neustart der Anlage — angehalten bleibt angehalten.
Der Scheduler ist auf der Konsole pausiert	`php artisan schedule:pause` wurde ausgeführt. Eigener Zustand neben dem Schalter; Fortsetzen hebt auch ihn auf.
Der Scheduler läuft nicht	Seit 26 Stunden wurde kein Lauf protokolliert. Dann führt die Anlage keine der Aufgaben aus. Im Docker-Betrieb sollte das nicht vorkommen. Auf Kubernetes läuft er ebenfalls mit, wird aber nicht gestartet, wenn mehrere Prozesse auf einen containerlokalen Cache-Store träfen — siehe Scheduler.
Der Zustand lässt sich nicht beurteilen	Die Laufhistorie ist nicht lesbar. Zeitplan und Schalter stimmen weiterhin, aber ob etwas läuft, steht nirgends. Meist fehlt die Tabelle dazu, weil Migrationen ausstehen — siehe Datenbankstand oben.

Nach einem Update sind drei Aufgaben abgeschaltet

Auf einer Installation, die schon Daten enthält, sind E-Mail-Strecke, Terminerinnerungen und Zeitbasierte Statusregeln nach dem Update abgeschaltet. Grund: Bis dahin lief der Zeitplan überhaupt nicht, und diese drei würden den gesamten aufgelaufenen Rückstand auf einen Schlag abarbeiten — also etwa Erinnerungen zu Terminen verschicken, die Monate zurückliegen.

Sie liefen vorher ebenfalls nicht, es geht also nichts verloren. Beim Einschalten fragt calServer zurück und zeigt vorher, was der erste Lauf abarbeitet — wie viele E-Mails sofort rausgehen, wie viele Terminerinnerungen fällig sind und wie viele davon zu Terminen gehören, die länger als 90 Tage zurückliegen. Ohne Rückstand entfällt die Rückfrage.

Was die Vorschau nicht beantwortet: wie viele Statuswechsel die zeitbasierten Regeln auslösen. Das zeigt nur der Trockenlauf — eine Vorschau, die anders rechnet als das Kommando selbst, wäre schlimmer als gar keine.

Je Aufgabe: eine Zeile¶

Über der Liste steht, wie viele Aufgaben es gibt und wie viele davon eingeschaltet sind; ist eine fehlgeschlagen oder fehlt eine Voraussetzung, steht das als Marke am Abschnittskopf — auch dann noch, wenn der Abschnitt zugeklappt ist.

In der Zeile selbst steht, was der Überblick braucht:

Angabe	Bedeutung
Farbiger Punkt links	Zustand: grün Bereit, gelb Läuft, rot Fehler (letzter Lauf schlug fehl), grau Aus bzw. Voraussetzung fehlt. Was Aufmerksamkeit braucht — Fehler, Läuft, Voraussetzung fehlt — steht zusätzlich als Text daneben; „Bereit" und „Aus" sagt der Schalter rechts bereits.
Stiftsymbol	Diese Anlage hat Takt oder Schalter gegenüber der Vorgabe verändert („abweichend")
Takt in Klartext	„Alle 5 Minuten", „Täglich um 03:00" — ab mittlerer Fensterbreite
Letzter und nächster Lauf	„zuletzt vor 3 Min. · nächster in 2 Min." — ab großer Fensterbreite; die genauen Zeitpunkte stehen im Tooltip
Schalter rechts	Aufgabe ein- oder ausschalten. Wirkt sofort. Beim Einschalten einer stillgelegten Aufgabe mit Rückstand kommt vorher die Vorschau (siehe oben).

Drei Symbolknöpfe davor: Jetzt ausführen, Verlauf und — nur bei abweichend eingestellten Aufgaben — Auf Vorgabe zurücksetzen.

Jetzt ausführen stößt die Aufgabe außer der Reihe an; sie läuft im Hintergrund weiter, auch wenn die Seite geschlossen wird. Bei Aufgaben, die über den gesamten Datenbestand wirken, wird vorher nachgefragt.

Verlauf zeigt die letzten Läufe mit Ergebnis, Dauer, Auslöser und Ausgabe. Bei einem fehlgeschlagenen Lauf stehen Exit-Code und Fehlertext dabei; hat ein Lauf keinen Fehlertext hinterlassen, verweist der Eintrag auf das Server-Log samt Lauf-Id als Suchbegriff. Das ersetzt die Logdateien, die V1 je Cronjob schrieb — es müssen keine Pfade mehr gepflegt werden.

Auf Vorgabe zurücksetzen stellt Takt und Schalter des Programmstands wieder her.

Aufgeklappt¶

Ein Klick auf den Namen (oder auf den Pfeil davor) klappt die Zeile auf. Darin steht, was für den Überblick nicht gebraucht wird:

Angabe	Bedeutung
Beschreibung	Was die Aufgabe tut
Takt	Auswahl in Klartext. Für Sonderfälle Eigener Ausdruck … mit crontab-Syntax.
Wiederholung je Minute	Nur bei Aufgaben, die häufiger als minütlich laufen (MET/TEAM-Abgleich)
Letzter Lauf	Ergebnis, Dauer und Auslöser (Zeitplan oder von Hand); darunter der nächste Lauf mit Datum und Uhrzeit
Fehlerdetails	Nur wenn der letzte Lauf fehlschlug: eine rot markierte Box mit Exit-Code und dem Fehlertext des Laufs (Standard- und Fehlerausgabe bzw. die Exception), dazu die Lauf-Id als Suchbegriff fürs Server-Log
Kommando	Der Artisan-Befehl, den die Aufgabe ausführt

Mehrere Zeilen lassen sich gleichzeitig aufklappen — beim Vergleich zweier Aufgaben nimmt kein Aufklappen die andere wieder weg.

Vom Fehlschlag zum Logeintrag

Der Fehlertext eines fehlgeschlagenen Laufs steht direkt in der Zeile — der rote Punkt führt zum Aufklappen, das Aufklappen zur Fehlerbox. Zusätzlich schreibt calServer jeden Fehlschlag mit der Lauf-Id ins Server-Log; dort steht er neben dem Kontext, den das Kommando selbst geloggt hat:

docker exec calserver-api-v2 grep <lauf-id> storage/logs/laravel.log

Der Griff zum Log ist nur noch für Läufe nötig, die keinen Fehlertext hinterlassen haben — Altbestand aus der Zeit, als die Ausgabe geplanter Läufe verworfen wurde, oder ein hart abgestürzter Prozess.

Warum eine Zeile und keine Karte

Bis August 2026 war jede Aufgabe eine Karte mit Beschreibung, Kommando und drei Formularfeldern — rund 200 Pixel, siebzehnmal untereinander. Auf einen Bildschirm passten vier. Die Frage, die man auf dieser Seite fast immer hat („läuft alles, oder hakt eine?"), war damit nur durch Scrollen zu beantworten. Bedient wird trotzdem in der Zeile: Schalter und Jetzt ausführen sind der Grund, warum man die Seite öffnet, und liegen deshalb nicht hinter dem Aufklappen.

Was „Voraussetzung fehlt" heißt

Die Aufgabe ist nicht eingeplant, weil eine Einstellung außerhalb dieser Seite fehlt — beim Dokumenten-Posteingang etwa, dass er überhaupt aktiviert ist. Der zuständige Konfigurationsschlüssel steht in der aufgeklappten Zeile. Die Zeile bleibt bewusst stehen, statt zu verschwinden.

Benachrichtigungen per Mail¶

Hier steht die Vorgabe der Installation: ob Meldungen aus dem Glockenmenü zusätzlich als Mail zugestellt werden. Drei Werte — keine Mails, sofort je Ereignis, einmal täglich gesammelt.

Ausgeliefert steht das auf keine Mails. Ein Update, das den gesamten Meldungsverkehr in Postfächer schiebt, die nicht danach gefragt haben, wäre die falsche Überraschung.

Die Vorgabe gilt für alle, die im Profil nichts eigenes gewählt haben. Wer dort etwas gesetzt hat, behält es — auch beim Umstellen hier. Die persönliche Wahl steht unter Mein Profil → Benachrichtigungen per Mail (Handbuch).

Darunter lässt sich je Bereich (Aufträge, Nachrichten) etwas anderes vorgeben — etwa Aufträge sofort und Nachrichten gesammelt. Ohne Auswahl gilt für einen Bereich die Vorgabe darüber. Die Reihenfolge ist: erst was der Benutzer gewählt hat (Bereich, dann allgemein), dann was hier steht (Bereich, dann allgemein). Eine Bereichsvorgabe hier übersteuert also nicht jemanden, der die Zustellung für sich abgeschaltet hat.

„Sofort" heißt eine Mail je Ereignis

Auf einer Anlage mit viel Betrieb sind das entsprechend viele. „Einmal täglich gesammelt" listet stattdessen abends, was aufgelaufen und noch ungelesen ist — wer tagsüber ins Glockenmenü sieht, bekommt weniger, bei nichts Offenem gar nichts.

Die tägliche Zusammenfassung hängt an der geplanten Aufgabe Benachrichtigungs-Zusammenfassung. Steht der Zeitplan, bleibt sie aus; die sofortige Zustellung läuft über die Warteschlange und ist davon unabhängig.

Warteschlange¶

Der Zeitplan stößt an, die Warteschlange arbeitet ab. Das sind zwei Prozesse, und beide können einzeln ausfallen: Mailversand, Benachrichtigungen, Importe und Sicherungs-Testläufe laufen über die Warteschlange. Steht ihr Worker, meldet die Oberfläche weiterhin „angestoßen", und nichts davon passiert.

Meldung	Bedeutung
Nichts wartet	Es steht kein Auftrag an. Das heißt nicht, dass ein Worker läuft — das zeigt sich erst, wenn etwas liegen bleibt.
n Aufträge in Arbeit	Rückstau im Normalbereich. Ältester Eintrag wird mit Alter genannt.
Die Warteschlange steht	Der älteste Auftrag wartet länger als 15 Minuten. So lange nimmt ihn niemand: Der Worker läuft vermutlich nicht.
Aufträge laufen ohne Warteschlange	Der Treiber steht auf sofortige Ausführung (`sync`). Für den Betrieb nicht gedacht — ein Sicherungslauf hielte damit die Anfrage offen, die ihn ausgelöst hat.

Warum es kein „der Worker läuft" gibt

Ein Worker meldet sich nirgends an. Beweisbar ist deshalb nur der Rückstau: Wartet etwas zu lange, holt es niemand ab. Umgekehrt gilt das nicht — eine leere Warteschlange sagt nur, dass gerade nichts ansteht. Die Anzeige formuliert das entsprechend, statt Sicherheit vorzutäuschen.

Gescheiterte Aufträge¶

Ein Auftrag, der endgültig scheitert, landet in einer eigenen Liste und läuft nicht von selbst noch einmal an. Bis hierher war diese Liste nur auf der Konsole sichtbar (php artisan queue:failed) — ein still verlorener Mailversand fiel damit niemandem auf.

Je Eintrag stehen Auftragsart, Warteschlange, Zeitpunkt und die erste Zeile der Fehlermeldung. Zwei Aktionen, einzeln oder für alle:

Aktion	Wirkung
Erneut versuchen	Der Auftrag geht auf seine ursprüngliche Warteschlange zurück und läuft, sobald ein Worker ihn abholt.
Verwerfen	Der Auftrag wird endgültig gelöscht. Was er tun sollte, passiert dann nicht mehr.

Gezeigt werden die jüngsten 20. „Alle erneut" und „Alle verwerfen" gelten trotzdem für alle.

Wenn die Liste aus lauter demselben Fehler besteht

Broadcast-Aufträge (Live-Updates im Grid) laufen über dieselbe Warteschlange. Ist ein Broadcaster eingerichtet, der nicht arbeiten kann, scheitert je angelegtem Datensatz einer — die Liste besteht dann aus einem einzigen, endlos wiederholten Eintrag.

calServer wählt deshalb keinen Broadcaster, der nicht arbeiten kann: BROADCAST_CONNECTION=pusher wirkt nur mit vollständigen Zugangsdaten und installiertem Paket pusher/pusher-php-server. Ist beides nicht da, bleiben Live-Updates aus, und es entsteht gar kein Auftrag. Sind die Zugangsdaten gesetzt und nur das Paket fehlt, steht der Grund als Hinweis über dieser Liste. Siehe Konfiguration.

Cache¶

Cache leeren verwirft zwischengespeicherte Abfragen und Konfiguration. Sinnvoll, wenn die Oberfläche nach einer Änderung noch alte Werte zeigt. Die nächsten Aufrufe sind langsamer, bis der Cache sich wieder gefüllt hat; Daten gehen nicht verloren.

Darüber steht, welcher Store das ist — und das ist mehr als eine Randnotiz, weil der Zeitplan daran hängt:

Meldung	Bedeutung
Der Cache wird geteilt	Mehrere Prozesse erreichen denselben Store (`database`, `redis`, `memcached`, `dynamodb`). Der Zeitplan kann sich darüber abstimmen.
Der Cache gilt nur für diesen Container	Der Store liegt lokal (`file`, `array`). Auf einer einzelnen Instanz in Ordnung. Laufen mehrere, sieht jede ihre eigenen Sperren.
Der Cache antwortet nicht	Der Store ist nicht ansprechbar. Sperren schlagen fehl, und der Zeitplan koordiniert über etwas, das nicht da ist.

Warum der Cache über den Zeitplan entscheidet

Geplante Aufgaben laufen mit onOneServer(): Vor jedem Lauf wird eine Sperre im Cache gesetzt, damit bei mehreren Prozessen genau einer arbeitet. Ist der Store containerlokal, sieht jede Replik ihre eigene Sperre, jede hält sich für die einzige, und jede Aufgabe liefe mehrfach. Das Helm-Chart schaltet den Scheduler deshalb ab, statt ihn falsch laufen zu lassen — Details unter Scheduler.

Wer sich also fragt, warum auf einer mehrfach replizierten Installation keine Aufgabe läuft, findet die Antwort hier.

Anzahl und Größe stehen dabei, soweit der Treiber sie ohne teure Vollsuche hergibt: database und file beantworten das, Redis und Memcached bräuchten dafür eine blockierende Schlüsselsuche über den gesamten Bestand — dafür ist die Auskunft zu unwichtig.

Sicherungen¶

Zustand¶

Ganz oben steht die Frage, die vor jeder Konfiguration kommt: Gibt es überhaupt eine Sicherung? Eine sauber eingerichtete Aktion, die seit drei Wochen scheitert, sah in der Liste darunter genauso aus wie eine, die läuft.

Meldung	Bedeutung
Die Sicherungen laufen	Es liegt ein aktueller Snapshot im Repository, und eine aktive Aktion wiederholt ihn.
Es wird nicht gesichert	Eine Laufvoraussetzung fehlt — Repo-Schlüssel oder Speicherziel. Der genaue Grund steht dabei.
Das Sicherungsziel antwortet nicht	Eingerichtet, aber der Zugriff scheitert. Das ist eine Störung, keine offene Einrichtung.
Es gibt noch keine Sicherung	Im Repository liegt kein Snapshot. Ein Testlauf zeigt, ob es funktioniert.
Die letzte Sicherung ist veraltet	Der jüngste Snapshot ist älter als 48 Stunden.
Es wird nicht wiederholt gesichert	Es gibt eine Sicherung, aber keine aktive Aktion. Ohne Aktion bleibt es bei dieser einen.

Je Aktion stehen zwei Zeitangaben nebeneinander, und das ist Absicht:

Angabe	Woher
Letzte Sicherung	Aus dem restic-Repository. Ein Snapshot existiert oder nicht — das ist die Wahrheit über den Erfolg.
Letzter Lauf	Aus der Laufhistorie. Ein Lauf kann gescheitert sein; die Fehlermeldung steht dann darunter.

Fallen sie auseinander — ein Lauf von heute, ein Snapshot von letzter Woche — sieht man genau das Problem, um das es geht. Ein gescheiterter Lauf hinterlässt keinen Snapshot und wäre ohne die Laufhistorie unsichtbar.

Zeitgesteuerte Läufe stehen jetzt in der Historie

Vorher landete ein nächtlicher Sicherungslauf ausschließlich im Anwendungslog. Ob er seit Wochen scheitert, war ohne Container-Shell nicht zu beantworten. Handläufe (Testlauf-Knopf) und zeitgesteuerte Läufe schreiben jetzt in dieselbe Historie.

Aktionen¶

Zeitgesteuerte Datenbanksicherungen.

Feld	Bedeutung
Beschreibung	Bezeichnung der Sicherung
Beginn / Ende	Zeitfenster, in dem die Sicherung laufen darf
Wochentage / Monate / Tage des Monats	crontab-Felder für die Wiederholung
Max. Sicherungen	Wie viele Sicherungen aufbewahrt werden, bevor die älteste entfällt
Aktiv	Deaktivierte Einträge laufen nicht

Je Zeile gibt es zwei Zusatzaktionen: Kopieren legt eine Kopie der Konfiguration an (praktisch für eine zweite, abweichende Sicherung), Testlauf stößt einen Lauf außer der Reihe an.

Speicherziel¶

Die Sicherungs-Aktionen oben legen fest, wann gesichert wird. Wohin, steht darunter.

Eine Sicherung im Container ist im Ernstfall keine

Vorgabe ist ein lokales Verzeichnis. Das funktioniert ohne Einrichtung, aber geht das Volume oder die Maschine verloren, sind die Sicherungen mit weg — also genau dann, wenn man sie braucht. Für den Regelbetrieb gehört das Ziel nach draußen. Die Seite weist darauf hin, solange die Ablage lokal ist.

Ablageart	Wofür
Lokales Verzeichnis	Einstieg, oder ein von außen eingehängtes Volume. Ohne eigene Angabe `storage/app/backups`.
S3-kompatibler Objektspeicher	Amazon S3 und alles, was dessen Protokoll spricht: Objektspeicher beim Hoster, MinIO, Ceph, Garage im eigenen Haus.
SFTP-Server	Ein Sicherungsziel im eigenen Netz, per Passwort oder privatem Schlüssel.

Feld	Bedeutung
Unterordner	Trennt mehrere calServer-Installationen, die sich ein Ziel teilen. Optional.
Bucket / Region	S3: Zielbehälter und Region. Dienste ohne Regionen vertragen die Vorgabe.
Endpunkt	S3: nur für Dienste abseits von Amazon nötig, als vollständige URL.
Pfad-Stil verwenden	S3: nötig für die meisten selbst betriebenen Dienste, die keine Bucket-Subdomains anbieten.
Host / Port / Benutzer	SFTP-Zugang
Geheimer Schlüssel, Passwort, Privater Schlüssel	Zugangsdaten. Werden verschlüsselt gespeichert und nie im Klartext zurückgegeben; das Feld zeigt nur, ob etwas hinterlegt ist. Unverändert lassen behält den gespeicherten Wert.

Verbindung testen schreibt eine kleine Probedatei, liest sie zurück und löscht sie wieder. Das Zurücklesen gehört dazu: Ein Ziel, auf das man schreiben, aber nicht lesen darf, nimmt Sicherungen an und gibt sie nicht wieder her — das fiele sonst erst bei der Wiederherstellung auf.

Kein Fremddienst ohne Entscheidung

S3 und SFTP muss jemand aktiv eintragen. Ohne diese Angaben verlässt keine Sicherung den Server.

Zertifikate¶

Ob diese Anlage wirklich über HTTPS läuft. Der Balken oben sagt es in einem Satz, darunter steht je Domäne, welche Zertifikatsdatei der Reverse Proxy heranzöge und ob sie taugt.

Fehlt eine Datei, läuft die Domäne über HTTP — unauffällig

Ohne passendes Zertifikat baut der Reverse Proxy für diesen Namen gar keinen HTTPS-Block. Alle Container bleiben grün, kein Protokoll meldet etwas. Genau diesen Fall macht der Tab sichtbar.

calServer stellt keine Zertifikate aus. Das erledigt der ACME-Dienst neben dem Reverse Proxy; diese Seite liest, was er ausliefert. Zu jeder Lücke nennt sie die Umgebungsvariable (CALSERVER_HOST, ADMINER_HOST, MCP_HOST) und den Deploy-Befehl zum Kopieren — ausgeführt wird nichts. Es gilt dieselbe Regel wie bei den geplanten Aufgaben: ein Feld, dessen Inhalt der Server ausführt, wäre ein Weg, sich über die Oberfläche mehr Rechte zu verschaffen, als die Rolle hergibt.

Zwei Fallen benennt der Tab ausdrücklich:

LETSENCRYPT_TEST=false schaltet die Testumgebung ein. Der Schalter prüft nur, ob überhaupt etwas in der Variablen steht, nicht was.
Eine vorhandene Datei muss den Namen nicht führen. Der Reverse Proxy wählt allein nach dem Dateinamen; der Browser schaut auf den Geltungsbereich.

Vollständige Fassung mit allen Zuständen, dem Spiegel ssl_certificate und dem Kubernetes-Fall: TLS-Zertifikate.

Dateispeicher¶

Belegung¶

Ganz oben stehen die Verzeichnisse, die calServer V2 tatsächlich benutzt — aus der Container-Konfiguration gelesen, nicht aus den Feldern darunter. Steht DMS_PATH auf einem eingehängten Volume, steht hier dieses Volume.

Je Verzeichnis: Pfad, ob es existiert, ob es beschreibbar ist, Größe und Dateianzahl. Darunter der freie Platz des Dateisystems, auf dem storage/ liegt.

Kennzeichen der Zeile	Bedeutung
Bereit	Vorhanden und beschreibbar.
Nur lesend	Absicht, keine Störung — siehe Kasten unten.
Nicht angelegt	Gibt es (noch) nicht. Die Sicherungs-Zwischenablage entsteht beim ersten Lauf.
Nicht beschreibbar	Nur bei Verzeichnissen, in die V2 schreibt: Was dorthin soll, geht verloren.
Nicht lesbar	Die Anwendung kann das Verzeichnis nicht öffnen — sein Inhalt fehlt damit in der Sicherung.

Meldung im Balken	Bedeutung
Genug Platz	Unter 85 % belegt, alle Verzeichnisse in Ordnung.
Der Platz wird knapp	Ab 85 % belegt.
Die Ablage ist fast voll	Ab 95 % belegt. Uploads und Sicherungen scheitern demnächst.
Ein Verzeichnis ist nicht beschreibbar	Schlägt jede Füllstandsmeldung: Was dorthin soll, geht verloren.
Ein Verzeichnis ist nicht lesbar	Was dort liegt, fehlt in der Sicherung, ohne dass ein Lauf deswegen fehlschlägt.
Der freie Platz ist nicht ermittelbar	Die Umgebung gibt darüber keine Auskunft (gehärtete PHP-Konfiguration).

Wo die Dokumente liegen: zwei Betriebsarten¶

calServer V1 legt seine Dokumente im Dateimanager-Baum ab ({filemanager}/dms, Posteingang {filemanager}/inbox). calServer V2 kann beides, und welche Variante gilt, entscheidet DMS_STORAGE_MODE in der Container-Konfiguration:

Modus	Wofür	DMS-Ablage	Dateimanager-Zeile
`own` (Vorgabe)	Anlage, die neben einer bestehenden V1 neu aufgebaut wird	`storage/app/dms`	Nur lesend
`v1-tree`	Reines Update einer laufenden Installation	`{filemanager}/dms`	Bereit (V2 schreibt hinein)

own lässt den V1-Baum unangetastet. V2 liest ihn nur, um Belegung anzuzeigen und ihn mitzusichern, und der Container hängt ihn deshalb schreibgeschützt ein. Die vorhandenen Dokumente kommen einmalig herüber:

docker exec calserver-api-v2 php artisan dms:import-v1              # Bericht, schreibt nichts
docker exec calserver-api-v2 php artisan dms:import-v1 --apply --force

Das ist nötig, weil die Datenübernahme (v1:sync) die Dokumentdatensätze überträgt, nicht die Dateien. Ohne den Import stünden die Dokumente in den Listen, und jeder Download liefe ins Leere. Der Befehl überschreibt nichts und ist wiederholbar; was er in der Quelle nicht findet, meldet er, statt es zu verschweigen.

v1-tree übernimmt den bestehenden Baum. Nichts wird kopiert, die Dokumente bleiben, wo sie sind, und V2 schreibt dort weiter. Der Mount muss dann beschreibbar sein — deploy.sh leitet das aus DMS_STORAGE_MODE ab, es ist also nur dieser eine Schalter zu stellen.

Der Modus wird beim Aufsetzen entschieden, nicht später

Ein Wechsel nach dem ersten Upload lässt die schon abgelegten Dokumente an der alten Stelle zurück. Wer wirklich wechseln muss, kopiert die Ablage vorher von Hand an den neuen Ort.

Warum „Nur lesend" kein Befund ist

Im Modus own gehört der Dateimanager-Baum calServer V1: Dort wird er über die Dateiverwaltung und über WebDAV beschrieben, und V2 hat keinen Schreiber dafür. „Nur lesend" ist dann ein Zustand, keine Störung. Wer den Schreibschutz entfernt, ohne den Modus umzustellen, setzt einen zweiten Schreiber auf einen fremden Baum, ohne dass V2 davon Gebrauch macht.

Im Modus v1-tree ist es umgekehrt: Die Zeile heißt dann Bereit, und ein schreibgeschützter Mount wird als Nicht beschreibbar gemeldet — dort wäre er ein echter Fehler. Die Karte liest das aus den tatsächlichen Pfaden ab und nicht aus einem zweiten Schalter, kann also nicht das eine anzeigen, während das andere gilt.

Warum die Größe abbrechen kann

Ein rekursiver Durchlauf über ein DMS mit einer Million Dateien blockiert die Anfrage minutenlang. Deshalb wird nach 25.000 Einträgen je Verzeichnis abgebrochen, und die Zeile sagt das auch — eine ehrliche Teilaussage ist besser als eine Antwort, die nie kommt. Größen messen / Ohne Größen laden schaltet den Durchlauf ganz ab; Existenz, Schreibbarkeit und freier Platz kosten nichts und bleiben.

Die Sicherungs-Zwischenablage sollte zwischen zwei Läufen leer sein. Ist sie es nicht, ist ein Lauf abgebrochen, ohne aufzuräumen.

Übernahme aus V1 (Assistent)¶

Unter der Belegung sitzt die Karte Übernahme aus V1. Sie beantwortet die eine Frage des 1:1-Umstiegs, bei dem die Dokumente physisch stehen bleiben: Zeigt die konfigurierte Ablage auf die Dateien, die die Datenbank kennt? Dazu hält sie eine Stichprobe der jüngsten Dokumente gegen die Ablage und sieht nach, ob im Dateimanager-Baum ({filemanager}/dms) ein DMS liegt.

Befund	Bedeutung
Ablage vollständig	Stichprobe trifft, Ablage beschreibbar — nichts zu tun.
Dokumente liegen im V1-Baum	Die Ablage zeigt woanders hin. Die Karte generiert die Umstellungs-Befehle auf `v1-tree` für diese Anlage.
Ablage nur lesbar	Downloads gehen, Uploads scheitern — der Mount muss auf `rw`.
Dateien fehlen	Der V1-Baum erklärt es nicht: Pfade und Volumes prüfen, Details im Server-Log.
Keine Dokumente	Nichts zu übernehmen; nach `v1:sync` neu prüfen.

Die generierten Befehle gibt es je Zielplattform — Docker (.env-Zeilen plus deploy.sh, das den Mount-Modus aus der Betriebsart ableitet) und OpenShift (oc set env plus readOnly: false am Dateimanager-volumeMount; dort gibt es kein deploy.sh, der Mount-Modus muss ausdrücklich ins Deployment). Ein gemessenes DMS_PATH/DMS_INBOX_PATH aus der Umgebung nennen die Befehle ausdrücklich zum Entfernen — es würde die Betriebsart sonst weiter übersteuern.

Ausführen kann die Karte die Befehle nicht, und das ist Absicht: Ablageort und Mount-Modus kann nur die Container-Ebene ändern, keine Web-Anwendung sollte ihren eigenen Dokumentenspeicher zur Laufzeit umzeigen können. Nach dem Neustart heißt es hier Neu prüfen — alle Häkchen grün (Ablage vorhanden, beschreibbar, Stichprobe vollständig), dann ist die Übernahme durch. Den vollständigen Datei-Abgleich liefert weiterhin die Integritätsprüfung der Dokumentenverwaltung.

Pfade (V1)¶

Die Ablagepfade für Dokumente, Uploads, Berichte und Sicherungen.

Nur V1

calServer V2 liest diese Werte nicht. V2 leitet seine Pfade aus der Container-Konfiguration ab (DMS_PATH, FILE_MANAGER_PATH und die übrigen Umgebungsvariablen, siehe Konfiguration). Die Properties gelten für calServer V1 und bleiben pflegbar, solange beide Stände nebeneinander laufen — deshalb tragen alle Felder das Kennzeichen Nur V1.

Feld	Bedeutung in V1	In V2 stattdessen
Ablageart	Lokales Verzeichnis oder entfernter Speicher	Filesystem-Disk der Container-Konfiguration
DMS-Verzeichnis	Ablage der Dokumente des Dokumentenmanagements	`DMS_PATH` (Vorgabe `storage/app/dms`)
Posteingang-Verzeichnis	Überwachter Ordner, aus dem der DMS-Posteingang Dateien übernimmt	`DMS_INBOX_PATH` (Vorgabe `storage/app/inbox`)
Upload-Verzeichnis	Ziel hochgeladener Dateien	Konfigurierter Filesystem-Disk
Bericht-Verzeichnis	Ablage der erzeugten Berichte	Storage des Containers, gesteuert von der Berichts-Pipeline
Sicherungs-Verzeichnis	Ablage der Datenbanksicherungen	Serverumgebung; wann gesichert wird, legen die Sicherungs-Aktionen oben fest

Dieselben Sätze stehen als Hinweis am Kennzeichen Nur V1 im Formular — Handbuch und Oberfläche ziehen sie aus derselben Quelle (SettingsCatalog), es gibt also keine zweite Fassung, die veraltet.

Der Umschalter für das DMS-Ablage-Layout (flach ↔ geshardet) steht bewusst nicht hier. Er gehört zum Migrationsbefehl dms:migrate-storage, der die Dateien mit umzieht; als frei editierbares Feld wäre er ein Knopf, der jedes Dokument unauffindbar macht.

Nicht auf dieser Seite¶

SymmetricDS-Pfade (settings/symmetric) gehören zum eigenständigen Sync-Client calserver-sync und werden von calServer V2 nirgends gelesen. Sie stehen weiterhin nur in der property-Tabelle.
Session-Timeout ist in V2 Container-Konfiguration (SANCTUM_EXPIRATION), keine Mandanten-Einstellung.
Updates haben eine eigene Seite: Update.