Nextcloud-Kommentare und ihr Archiv: Was dauerhaft bleibt, was verschwindet

Es ist ein Satz, der in Projekten selten freundlich ankommt: „Können Sie belegen, wer wann welche Änderung an dieser Datei kommentiert hat?“ Dann wird gesucht, geklickt, gescrollt – und irgendwann fällt der Satz, den niemand hören will: „Das war mal da, ich finde es aber nicht mehr.“ Genau an dieser Stelle beginnt das Thema, das unter dem Schlagwort Nextcloud Comments Archive in Suchmasken und Ausschreibungen auftaucht. Gemeint ist selten ein einzelner Knopf. Gemeint ist die Frage, ob die Kommentare, die in der Seitenleiste einer Datei hängen, ein flüchtiges Arbeitsmittel sind oder eine nachvollziehbare Spur.

Nextcloud gibt darauf keine einfache Antwort. Die Plattform kann beides sein – Arbeitsmittel und Spur –, aber sie trennt die beiden Rollen nicht besonders deutlich voneinander. Wer das weiß, kann planen. Wer es nicht weiß, erlebt irgendwann eine unangenehme Überraschung, meistens während einer Prüfung, eines Audits oder einer Personalie, die plötzlich eine digitale Beweiskette braucht.

Ein Kommentar ist kein Chatverlauf

Zunächst einmal lohnt sich eine begriffliche Aufräumarbeit, weil in der Praxis ständig drei Dinge durcheinandergehen. Da ist erstens die Kommentarfunktion der Dateien-App. Sie sitzt in der rechten Seitenleiste, heißt intern schlicht comments, wird als System-App mit jeder Nextcloud-Installation ausgeliefert und arbeitet mit kurzen Textnachrichten, Erwähnungen über @-Zeichen und einem Lesestatus pro Nutzer. Zweitens gibt es Talk, den Chat, dessen Speicherlogik und Aufbewahrungseinstellungen ganz andere sind. Drittens existieren Kommentare in anderen Anwendungen – auf Deck-Karten, in Textdokumenten von Nextcloud Text, in Collectives oder in Announcements. Das ist eine Landschaft aus mehreren Inseln, und wer ein Archiv plant, sollte wissen, welche Insel er eigentlich trockenlegen will.

Der Klassiker ist die Dateikommentarfunktion. Sie ist unspektakulär: kurze Notizen am Rand, häufig nur wenige Wörter, manchmal Rückfragen, manchmal ein „erledigt, siehe Version 12“. Genau diese Unspektakulärität ist ihr Problem. Weil Kommentare so beiläufig wirken, behandelt sie kaum jemand als dokumentationspflichtigen Inhalt. In Projekten mit Freigabeprozessen, in der Qualitätssicherung, in Konstruktions- und Prüfungsabteilungen können sie aber die einzige Stelle sein, an der eine Begründung überhaupt schriftlich festgehalten wurde. Ein freigegebenes Dokument ohne den Kommentar „Freigabe nur für Mock-up, nicht für Serie“ ist bei genauer Betrachtung eine Falle.

Die Anatomie: Datei-ID statt Dateipfad

Um zu verstehen, warum Kommentare sich so verhalten, wie sie sich verhalten, muss man den einen Entwurfsentscheid kennen, der alles andere nach sich zieht. Kommentare hängen nicht am Pfad und nicht am Dateinamen, sondern an der fileid. Das ist der Primärschlüssel, den Nextcloud in der Tabelle oc_filecache für jedes bekannte Objekt vergibt. Ein Kommentar wird also nicht „an /Projekte/Anlagen/Spezifikation_v3.odt“ gehängt, sondern an die Zahl 94812.

Das hat sehr angenehme Folgen. Wer eine Datei umbenennt, in einen Unterordner verschiebt oder den Projektordner komplett umstrukturiert, verliert seine Kommentare nicht. Auch das Verschieben in einen Groupfolder bricht die Zuordnung nicht ab, weil dabei die Datei selbst samt ID erhalten bleibt. Wer allerdings eine Datei herunterlädt und unter neuem Namen wieder hochlädt, erzeugt eine neue ID – und damit eine Datei ohne Geschichte. Dasselbe gilt für den Klassiker „ich lade die alte Fassung nochmal hoch, weil etwas kaputt ist“: Die alte Fassung in der Versionshistorie hat die Kommentare, die neue Arbeitskopie nicht. Das ist logisch, wird aber regelmäßig als Fehler empfunden.

Interessant wird es bei externen Speichern. Kommentare liegen immer in der Datenbank der Nextcloud-Instanz, nie auf dem eingebundenen SMB- oder S3-Speicher. Das ist für den Betrieb bequem, hat aber eine unschöne Konsequenz: Wird ein externer Mount entfernt und später neu eingerichtet, entstehen neue IDs, und die alten Kommentare zeigen ins Leere. Sie verschwinden aus der Oberfläche, existieren aber unter Umständen noch wochenlang als verwaiste Datensätze in der Datenbank. Wer eine Instanz über Jahre umbaut, sammelt solche Waisen an, ohne es zu merken.

Was in der Datenbank tatsächlich steht

Technisch ist die Sache überschaubar. Die Kommentare liegen in oc_comments, die Lesemarkierungen in oc_comments_read_markers. In der Kommentartabelle finden sich unter anderem ein actor_type und eine actor_id – also wer geschrieben hat –, ein object_type und eine object_id – meist der Wert files zusammen mit der Datei-ID –, dazu die eigentliche Nachricht, ein Verb, Zeitstempel sowie ein Feld für Erwähnungen. Das Verb ist in der Regel schlicht comment; die Struktur stammt aus einer Zeit, in der die Comments-App aus der Activity-App herausgelöst wurde, und trägt diese Herkunft noch sichtbar mit sich.

Die Lesemarkierungen sind der Grund, warum ein Nutzer eine kleine rote Zahl in der Dateiliste sieht und ein anderer nicht. Wer die Datei lesen darf, sieht in aller Regel auch ihre Kommentare. Für das Schreiben braucht es Schreibzugriff – die Rechte folgen also der Freigabe, es gibt keine separate Berechtigung „darf kommentieren“. Über die WebDAV-Eigenschaften oc:comments-count und oc:comments-unread lässt sich der Zustand maschinell abfragen, was für Monitoring und für eigene Auswertungen nützlich ist. Der Kommentartext selbst kommt über die OCS-Schnittstelle der Comments-App.

Ein Hinweis an alle, die es eilig haben: Bitte niemals direkt in oc_comments schreiben. Lesen ja, mit Bedacht und möglichst auf einer Replik. Schreiben nein. Es gibt keinen Grund, dem Datenbankoptimierer im Kopf nachzugeben, und es gibt mehrere Reparaturläufe in occ maintenance:repair, die verwaiste Einträge später ohnehin wieder einsammeln. Wer händisch eingreift, produziert Datenmüll, den niemand mehr auseinanderhalten kann.

„Archiv“ – ein Wort mit drei Bedeutungen

Spätestens hier wird klar, warum die Diskussion um ein Kommentararchiv so häufig im Kreis läuft. Drei völlig unterschiedliche Anforderungen verstecken sich hinter demselben Begriff.

Die erste Anforderung ist Historisierung: Ich möchte zu einem beliebigen Zeitpunkt wissen, was zu einer Datei gesagt wurde, möglichst mit Zeitstempel und Urheber. Die zweite ist Aufbewahrung: Ich muss Inhalte über einen definierten Zeitraum vorhalten und danach löschen, aus steuerlichen, vertraglichen oder datenschutzrechtlichen Gründen. Die dritte ist die Überlebensfähigkeit: Ich möchte, dass die Information auch dann noch verfügbar ist, wenn die Datei selbst gelöscht, verschoben oder aus der Instanz ausgelagert wurde.

Nextcloud erfüllt die erste Anforderung gut, solange die Datei existiert und niemand den Kommentar löscht. Die zweite erfüllt es allenfalls teilweise. Die dritte erfüllt es überhaupt nicht. Es gibt keinen Archivierungsknopf für Kommentare, keine Einfrierfunktion, keine Möglichkeit, einen Kommentarstrang schreibgeschützt zu konservieren, während die Datei weiterlebt. Wer das braucht, baut es selbst – und sollte vorher genau wissen, welche der drei Fragen er eigentlich beantworten will. Sonst entsteht ein riesiges Schattenarchiv, das niemand pflegt und das im Zweifel mehr Risiko produziert als Nutzen.

Der Fall der gelöschten Datei

Kommen wir zum praktisch relevantesten Teil. Was passiert mit Kommentaren, wenn eine Datei in den Papierkorb wandert? Solange die Datei im Papierkorb liegt, bleibt die ID erhalten und damit in vielen Fassungen auch der Kommentar. Wird die Datei endgültig gelöscht – durch den Nutzer, durch das Ablaufdatum des Papierkorbs oder durch occ trashbin:cleanup –, räumt Nextcloud die zugehörigen Kommentare mit ab. Das ist konsistent, aber es bedeutet: der Papierkorb ist das inoffizielle Kommentararchiv der Plattform. Wer die Papierkorb-Aufbewahrung aus Platzgründen auf drei Tage setzt, verkürzt damit automatisch die Lebensdauer der Kommentare auf drei Tage.

Ein weiterer Aspekt, der gern übersehen wird: Kommentare werden nicht mitgeteilt. Bei einer internen Freigabe sieht der Empfänger die Kommentare, sofern er Lesezugriff auf die zugrunde liegende Datei hat. Bei einer föderierten Freigabe an eine andere Instanz ist das nicht der Fall; dort wandert die Datei, nicht die Konversation. Für abteilungsübergreifende Zusammenarbeit über Instanzgrenzen hinweg ist das eine relevante Einschränkung, gerade in Konzernumgebungen mit mehreren Nextcloud-Installationen. Und in Umgebungen mit Ende-zu-Ende-Verschlüsselung verschwindet die Kommentarfunktion gleich ganz, weil der Server den Inhalt nicht lesen kann – dazu weiter unten mehr.

Verschlüsselung: der blinde Fleck

Wer über Archivierung spricht, muss über Verschlüsselung sprechen. Bei serverseitiger Verschlüsselung ist die Lage entspannt: Dateien liegen verschlüsselt im Speicher, Kommentare liegen im Klartext in der Datenbank, die sich wiederum über datenbankseitige Verschlüsselung oder verschlüsselte Volumes schützen lässt. Bei der Ende-zu-Ende-Verschlüsselung sieht es anders aus. In verschlüsselten Ordnern sind Vorschaubilder, Volltextsuche und eben auch Kommentare deaktiviert, weil sie eine serverseitige Verarbeitung voraussetzen würden. Das ist konsequent, macht aber die Kombination „E2E für sensible Projekte plus Kommentararchiv für die Nachvollziehbarkeit“ unmöglich. Man muss sich entscheiden, und diese Entscheidung gehört in ein Dokument, nicht in ein Meetinggedächtnis.

Ein Archiv selbst bauen: drei Reifegrade

Wenn klar ist, dass die Bordmittel nicht reichen, beginnt die Eigenarbeit. Drei Ansätze haben sich in der Praxis bewährt, und sie unterscheiden sich vor allem im Aufwand und in der Belastbarkeit.

Variante A: Export über die API, per Cron

Der pragmatischste Weg führt über die OCS-Schnittstelle der Comments-App. Mit einem eigenen Konto, einem App-Passwort und einem nächtlichen Cron-Job lassen sich Kommentare strukturiert abziehen und als JSON oder CSV ablegen. Zwei Kopfzeilen sind dabei Pflicht: die Authentifizierung per Basic Auth mit App-Passwort und der Header OCS-APIRequest: true, sonst antwortet die Schnittstelle nicht wie erwartet.

curl -s -u "archiv-bot:<app-passwort>" \
  -H "OCS-APIRequest: true" \
  -H "Accept: application/json" \
  "https://cloud.example.org/ocs/v2.php/apps/comments/api/v1/comments/94812" \
  | jq '.ocs.data[] | {id, actorId, message, creationDateTime}'

Das Ergebnis ist eine Liste mit Kommentaren einer Datei-ID. Wichtig ist, dass man beim Export den Pfad mit protokolliert, denn der Pfad kann sich später ändern. Dafür gibt es ein unterschätztes Werkzeug: occ info:file 94812 liefert den aktuellen Pfad, die Größe und den Zeitstempel zu einer Datei-ID. Idempotenz bekommt man über die Kommentar-ID und einen Zeitstempel des letzten Exports hinzu. Wer es sauber mag, schreibt pro Lauf eine neue Datei und löscht nichts – dann ist auch nachvollziehbar, wann welcher Kommentar erstmals aufgetaucht ist und ob er später bearbeitet wurde. Bearbeitungen sind übrigens möglich; ein Kommentar, der heute anders lautet als gestern, ist kein Datenfehler, sondern ein Feature, das die Historisierung erschwert.

Variante B: Lesende Replik und eigene Auswertung

Der zweite Weg ist schwerer, aber belastbarer. Eine lesende Datenbankreplik bekommt eine eigene, schlanke Sicht auf oc_comments, verknüpft mit oc_filecache und den Nutzertabellen. Damit lassen sich Auswertungen fahren, ohne die Produktion zu belasten. Zwei Warnungen gehören dazu. Erstens ist der Pfad in oc_filecache nicht identisch mit dem, was ein Nutzer in seiner Oberfläche sieht, sobald Freigaben, externe Speicher oder Groupfolder im Spiel sind. Zweitens sollte man das Replikat nie für Schreibzugriffe verwenden, auch nicht „nur kurz“, weil sonst die Replikation auseinanderläuft und der Supportfall vorprogrammiert ist.

Für Kennzahlen ist der Ansatz trotzdem wertvoll. Wie viele Kommentare entstehen pro Monat? In welchen Ordnern? Welche Nutzer kommentieren viel, welche nie? Wie viele Kommentare hängen an Dateien, die seit zwei Jahren nicht geöffnet wurden? Solche Fragen lassen sich mit SQL beantworten und liefern die Grundlage für jede vernünftige Aufbewahrungsrichtlinie. Ohne diese Zahlen wird jede Retention-Regel zum Ratespiel.

Variante C: Ereignisgetriebene Pipeline

Der dritte Weg ist der aufwendigste und für regulierte Umgebungen oft der einzig haltbare. Statt in festen Intervallen zu exportieren, reagiert ein Dienst auf Ereignisse und schreibt sie in ein externes System – eine Log-Plattform, ein Objektspeicher mit WORM-Eigenschaften, ein SIEM. Die Comments-App ist über den öffentlichen Kommentarmanager OCP\Comments\ICommentsManager ansprechbar, und Nextcloud selbst stellt für Erweiterungen Event-Klassen bereit, deren Stabilität man vor dem Produktiveinsatz für die eigene Version prüfen sollte. Wer diesen Weg geht, muss außerdem wissen: Das Audit-Log der Nextcloud protokolliert Dateizugriffe, Freigaben, Anmeldungen und administrative Eingriffe. Kommentarinhalte stehen dort nach hiesiger Kenntnis nicht als eigenes Ereignis. Wer also eine revisionssichere Spur von Kommentaren braucht, kommt um einen eigenen Listener oder einen regelmäßigen Export nicht herum.

Aufbewahrung: Aktivität läuft ab, Kommentare nicht

Ein Missverständnis begegnet einem in Administratorenrunden immer wieder: die Annahme, mit dem Ablauf der Aktivitäten sei auch der Rest der Historie verschwunden. Das ist nicht so. Die Aktivitäts-App kennt eine Einstellung activity_expire_days, mit der sich alte Einträge automatisch entfernen lassen – ein sinnvoller Schritt gegen eine ausufernde Datenbank. Die Kommentare in oc_comments bleiben davon unberührt. Das gilt auch in die andere Richtung: Wer Kommentare löscht, löscht nicht die zugehörigen Aktivitätseinträge. Zwei Systeme, zwei Lebenszyklen, keine gemeinsame Klammer.

Ähnlich verhält es sich mit Talk. Dort existieren Aufbewahrungsfristen für Chats, die sich konfigurieren lassen. Für die Dateikommentare gibt es kein Gegenstück. Es gibt keinen Schalter, der Kommentare nach 90 Tagen entfernt, und keinen, der sie für zehn Jahre aufbewahrt. Wer Aufbewahrung braucht, muss sie über einen Export und eine eigene Löschroutine abbilden – und diese Routine dann auch tatsächlich betreiben. Eine Richtlinie, die nur im Wiki steht, ist keine Richtlinie.

Rechtlich wird es ungemütlich – und zwar zu Recht

Kommentare enthalten häufig personenbezogene Daten. Nicht immer offensichtlich, aber oft: Namen in Erwähnungen, Bewertungen von Arbeitsleistungen, Hinweise auf Krankheiten, Informationen über Kunden. Daraus folgen die üblichen Pflichten. Ein Löschanspruch kann sich auch auf Kommentare erstrecken, und dann stellt sich die unangenehme Frage, ob man sie überhaupt finden kann. Hier zahlt sich aus, was viele als überflüssig abtun: eine ausgebaute Suche oder ein Export, in dem nach Nutzernamen und Zeiträumen gefiltert werden kann.

Ein zweiter Punkt betrifft die Beweisbarkeit. Wer aus Kommentaren ein Archiv baut, sollte sich bewusst sein, dass dieses Archiv selbst eine Datenverarbeitung ist. Es braucht einen Zweck, eine Rechtsgrundlage, eine Löschfrist und eine Zugriffsbeschränkung. Ein ungeordneter Ordner mit JSON-Dumps, den irgendwann drei Personen aus dem Betrieb gesehen haben, ist das Gegenteil einer guten Lösung. In regulierten Branchen ist es deshalb üblich, das Kommentararchiv an dieselben Prozesse zu hängen wie das Dateiarchiv – also an eine ausdrückliche, dokumentierte Aufbewahrungsmatrix statt an ein Skript, das irgendein Administrator vor zwei Jahren geschrieben hat.

Betrieb, Skalierung und die kleinen Ärgernisse

Über die Jahre ist die Kommentartabelle in den meisten Instanzen erstaunlich klein geblieben. Das liegt daran, dass Kommentare im Vergleich zu Aktivitätseinträgen, Versionen und Papierkorbinhalten wenig Volumen erzeugen. Anders sieht es aus, wenn eine Organisation Kommentare als Arbeitsprotokoll zweckentfremdet und jede Statusänderung als Kommentar dokumentiert. Dann wächst die Tabelle schnell, und weil Abfragen über object_type und object_id laufen, sollten entsprechende Indizes vorhanden sein – was bei Standardinstallationen der Fall ist, bei gewachsenen Umgebungen mit manuellen Eingriffen aber nicht garantiert.

Ein unterschätzter Punkt ist die Belastung durch das Öffnen der Seitenleiste. Jedes Aufklappen des Kommentarbereichs löst Abfragen aus, und bei langen Diskussionen mit vielen Beteiligten kann das spürbar werden. Die Schnittstelle arbeitet mit Limit und Offset, was eigene Clients nutzen sollten. Die Weboberfläche lädt zunächst eine begrenzte Anzahl und lädt beim Scrollen nach. Wer eine Datei mit mehreren tausend Kommentaren hat, sollte prüfen, ob das noch sinnvoll ist – irgendwann ist eine Diskussion in einem Kommentarbereich kein Zeichen für Zusammenarbeit, sondern für ein fehlendes Werkzeug.

Nicht zuletzt die Benachrichtigungen. Kommentare mit Erwähnungen lösen Mitteilungen aus, und die Einstellungen dafür verteilen sich über mehrere Stellen: persönliche Benachrichtigungseinstellungen, Aktivitätsabonnements, Mail-Benachrichtigungen. In Umgebungen mit vielen Kommentaren entsteht dadurch erheblicher Mail- und Push-Verkehr, der irgendwann dazu führt, dass Nutzer die Benachrichtigungen komplett abschalten – und dann auch die wichtigen nicht mehr sehen. Ein Grund mehr, sich vor der Einführung klarer Kommentarregeln Gedanken über die Benachrichtigungskultur zu machen.

Die Nachbarinseln: Deck, Talk, Text, Announcements

Wer ein umfassendes Kommentararchiv plant, sollte den Blick weiten. In Deck hängen Kommentare an Karten und sind Teil des Aufgabenkontexts; sie verhalten sich logisch anders als Dateikommentare, weil Karten ein eigenes Lebensmodell haben. In Talk gibt es Chats mit Aufbewahrungsfristen, die man auch exportieren kann, wobei hier die rechtliche Bewertung deutlich heikler ist, weil Chats oft beiläufig Persönliches enthalten. Nextcloud Text und Collectives speichern Kommentare und Anmerkungen teilweise innerhalb der Dokumentstruktur, was die Extraktion zusätzlich erschwert. Und Announcements sind ihrer Natur nach bereits Mitteilungen und weniger Diskussionen.

Wer heute eine Instanz ohne jede Kommentarstrategie betreibt, sollte sich nicht wundern, wenn die Prüfungsfrage kommt. Umgekehrt gilt: Wer alles exportiert, was irgendwie nach Kommentar aussieht, schafft sich ein Datenhaltungsproblem, das er später nicht mehr auflösen kann. Die vernünftige Mitte liegt darin, den Geltungsbereich ausdrücklich zu definieren: Dateikommentare ja, Talk-Chats nein, Deck nur für bestimmte Boards, Textanmerkungen nach Bedarf. Diese Festlegung sollte schriftlich erfolgen, und zwar bevor jemand sie braucht.

Ein schlankes Kommentararchiv in fünf Schritten

Für den Einstieg hat sich eine Reihenfolge bewährt, die ohne Werkzeugkasten auskommt und trotzdem belastbar ist.

1. Bestandsaufnahme: Wie viele Kommentare gibt es, wie alt sind sie, an welchen Dateien hängen sie? Die Zahlen lassen sich über eine lesende Replik oder über Auswertungen der API gewinnen – wichtig ist, sie überhaupt einmal zu erheben.
2. Geltungsbereich festlegen: Welche Ordner, welche Abteilungen, welche Zeiträume sind relevant? Nicht alles archivieren, was technisch archivierbar ist.
3. Export automatisieren: Ein nächtlicher Lauf mit eigener Servicekonto-Anmeldung und App-Passwort, der pro Datei-ID einen Datensatz mit Zeitstempel, Autor, Text und zum Exportzeitpunkt gültigem Pfad schreibt. Dateien mit komprimiertem Inhalt oder mit einem Hash versehen, damit Manipulation erkennbar bleibt.
4. Ablage und Zugriff regeln: Ein eigener Bereich, schreibgeschützt, mit klaren Berechtigungen, außerhalb der normalen Nutzerfreigaben. Wer Einsicht braucht, bekommt sie über einen dokumentierten Weg und nicht über eine weitergereichte Freigabe.
5. Löschkonzept hinterlegen: Wann wird der Export gelöscht oder aggregiert? Wer entscheidet? Ohne diese Antwort ist das Archiv eine Altlast mit Ablaufdatum.

Ergänzend lohnt ein Blick auf die Monitoringseite. Ein einfacher Check, ob der nächtliche Export gelaufen ist, und eine Warnung, wenn die Zahl der erfassten Kommentare von einem Tag auf den anderen auf null fällt, ersparen die peinlichste aller Situationen: die Feststellung im Audit, dass das Archiv seit acht Monaten nicht mehr aktualisiert wurde, weil ein Passwort abgelaufen ist.

Was fehlt – und was man erwarten darf

Ein natives Kommentararchiv wird es in absehbarer Zeit wohl nicht geben, jedenfalls nicht als einfachen Schalter. Die Anforderungen sind zu unterschiedlich, die rechtlichen Rahmenbedingungen zu verschieden, und die Nextcloud-Gemeinde ist traditionell skeptisch gegenüber Funktionen, die Daten länger aufbewahren als nötig. Realistischer ist, dass sich die Bausteine verbessern: bessere Ereignis-Schnittstellen, mehr Konfigurationsmöglichkeiten für Aufbewahrung, sauberere Exportformate. Bis dahin bleibt es bei der Eigenverantwortung.

Das ist unbefriedigend, aber es ist auch eine Chance. Denn wer sich einmal ernsthaft mit der Frage beschäftigt, was Kommentare in seinem System eigentlich sind – Arbeitsmittel, Protokoll oder beides –, gewinnt mehr als ein Archiv. Er gewinnt Klarheit darüber, wie in seinem Haus dokumentiert wird. Und das ist am Ende die eigentliche Erkenntnis: Ein Kommentararchiv löst kein technisches Problem, sondern ein organisatorisches. Nextcloud liefert die Rohdaten. Was daraus wird, entscheidet der Betrieb.

Wer heute anfängt, sollte mit einer einzigen Frage beginnen, die alle weiteren beantwortet: Wenn morgen jemand fragt, was zu dieser Datei gesagt wurde – in welchem System soll dann nachgesehen werden? Sobald diese Frage eine Antwort hat, ist der Rest eine Frage von Skripten, Rechten und Routinen. Und das ist bekanntlich das Handwerk, in dem die meisten Administratoren ohnehin zu Hause sind.