Changelog für Syncwerk Debian Pakete.

Der Stable-Kanal enthält eine aktualisierte Webapp für verwaltete Ordnerfreigaben.

Der Freigabedialog erhält aus der Admin-Ordnerliste jetzt den vollständigen Repository-Root-Kontext.

Vorhandene Download- und Uploadlinks bleiben dadurch beim erneuten Öffnen gemeinsam sichtbar, sofern beide Links existieren.

Der Stable-Kanal enthält eine ergänzte Webapp für den Freigabedialog.

Bestehende Download- und Uploadlinks bleiben auch dann sichtbar, wenn Root-Pfade, leere Pfade oder Slash-Varianten vom aufrufenden Kontext unterschiedlich geliefert werden.

Die Änderung wurde aus demselben öffentlich geprüften Testing-Artefakt nach Stable übernommen; es wurde kein abweichendes Stable-Paket erstellt.

Der Stable-Kanal enthält eine aktualisierte Webapp für den Freigabedialog.

Beim erneuten Öffnen bestehender Ordnerfreigaben aus der Administration bleiben vorhandene Download- und Uploadlinks sichtbar.

Die Änderung wurde aus demselben öffentlich geprüften Testing-Artefakt nach Stable übernommen; es wurde kein abweichendes Stable-Paket erstellt.

Dieser Stable-Stand übernimmt die im öffentlichen Testing-Kanal geprüften Korrekturen für Freigabelinks, Admin-/Setup-Abgleich und Paketkonfiguration.

Download- und Uploadlinks bleiben beim erneuten Öffnen des Freigabedialogs sichtbar und der Link-Lifecycle wurde gegen den öffentlichen Paketstand geprüft.

Neuinstallation und Upgradepfad für Debian 13 wurden ausschließlich aus dem öffentlichen Testing-Repository validiert. Die Stable-Veröffentlichung erfolgt ohne Rebuild durch Promotion derselben geprüften Artefakte.

Dieser Stable-Stand bündelt die Debian-13-Paketbasis mit korrigierter Neuinstallation, Wiederanlauf nach unvollständigem Bootstrap und normalem APT-Upgradepfad.

Der Bootstrap-Admin wird zuverlässig finalisiert, RESTAPI-Login- und Bootstrap-Anfragen liefern kontrollierte Antworten, und die Freeware-Grenze liegt konsistent bei 20 aktiven Benutzern.

ONLYOFFICE-Integration und ClamAV-basierter Virenschutz werden beim Setup und Upgrade konsistenter geprüft; fehlerhafte Zustände brechen kontrolliert ab, statt scheinbar erfolgreich weiterzulaufen.

Der Stable-Kanal enthält aktualisierte Admin-Werkzeuge für Legacy-Rollen und Lizenzprüfung.

RESTAPI-Upgrades laden geänderten Code über einen Debian- und systemd-konformen Neustartpfad.

Die Weboberfläche reduziert helle Kontraste im Darkmode.

Legacy-Desktop-Client-Endpunkte liefern wieder konsistente JSON-Antworten für Server-Info, Aktivitäten, Favoriten, Events und Suche.

Browser-Login und Upload-Statusfenster wurden für produktive Nutzung verbessert.

Desktop-Client-Aktivitäten liefern zusätzliche kompatible Felder.

Admin-Listen für Benutzer, Gruppen und Ordner unterstützen serverseitige Suche und Pagination.

Der Stable-Kanal ist im öffentlichen Installer freigeschaltet und für produktive Neuinstallationen dokumentiert.

Weboberfläche, PDF-Vorschau und deutschsprachige Bezeichnungen wurden für den Stable-Stand nachgeschärft.

Die erste produktiv nutzbare Trixie-Stable-Paketfamilie für Syncwerk Server wurde veröffentlicht.

Server-, Daemon-, Python-, WebDAV- und Setup-Komponenten sind auf Debian 13 Trixie ausgerichtet.

Die RESTAPI meldet Dateilöschungen erst dann als erfolgreich, wenn der betroffene Eintrag anschließend nicht mehr im Ordner sichtbar ist.

Das verbessert den Umgang mit älteren Unicode-Dateinamen und verhindert irreführende Erfolgsmeldungen bei nicht entfernten Einträgen.

Produktive Stable-Installationen sind nicht betroffen.

Der Testing-Kanal enthält aktualisierte Kernlaufzeit-, Runtime-, RESTAPI- und Admin-Pakete für die weitere Debian-13-Qualifikation.

Das Paketset enthält die zusammengehörigen Versionen von ccnet, libevent, librpc und Daemon, damit Neuinstallationen und Aktualisierungen nicht an inkonsistenten Runtime-Abhängigkeiten scheitern; die RESTAPI liefert für nicht lizenzierte Admin-Meeting-Endpunkte eine kontrollierte Berechtigungsantwort statt eines internen Serverfehlers.

Die Kernlaufzeit enthält vorbereitete Korrekturen für Unicode-normalisierte Dateinamen; produktive Stable-Installationen sind noch nicht betroffen.

Der Testing-Kanal enthält eine aktualisierte Webapp für verwaltete Ordnerfreigaben.

Der Freigabedialog erhält aus der Admin-Ordnerliste jetzt den vollständigen Repository-Root-Kontext.

Vorhandene Download- und Uploadlinks bleiben dadurch beim erneuten Öffnen gemeinsam sichtbar, sofern beide Links existieren.

Der Testing-Kanal enthält aktualisierte RESTAPI- und Webapp-Pakete für den Freigabedialog.

Beim erneuten Öffnen vorhandener Freigaben wird der fachliche Besitzerkontext beim Link-Readback berücksichtigt.

Vorhandene Download- und Uploadlinks bleiben dadurch auch in verwalteten Ansichten gemeinsam sichtbar, sofern beide Links existieren.

Der Testing-Kanal enthält eine ergänzte Webapp für den Freigabedialog.

Bestehende Download- und Uploadlinks bleiben auch dann sichtbar, wenn Root-Pfade, leere Pfade oder Slash-Varianten vom aufrufenden Kontext unterschiedlich geliefert werden.

Diese Änderung erweitert den Link-Lifecycle-Fix um robuste Pfadnormalisierung; bestehende Links bleiben unverändert nutzbar.

Der Testing-Kanal enthält eine aktualisierte Webapp für den Freigabedialog.

Beim erneuten Öffnen bestehender Ordnerfreigaben aus der Administration bleiben vorhandene Download- und Uploadlinks sichtbar.

Die Änderung verwendet eine eigene Paketversion, damit bereits veröffentlichte Testing-Pakete nicht mit anderem Inhalt ersetzt werden.

Der Testing-Kanal enthält eine aktualisierte Webapp für den Freigabedialog.

Bereits vorhandene Upload- und Downloadlinks bleiben beim erneuten Öffnen des Dialogs sichtbar und werden dem aktuellen Ordner eindeutig zugeordnet.

Bestehende Links bleiben unverändert nutzbar.

Der Testing-Kanal enthält aktualisierte Admin- und Setup-Pakete für die Debian-13-Paketkonfiguration.

Der Setup-Lauf wartet vor dem Superadmin-Abgleich auf die Server-Laufzeit und führt vorhandene Bootstrap-Konfigurationsdateien kontrolliert auf die aktuelle Zielkonfiguration zurück.

Bei frischen Installationen wird eine vorhandene nginx-Konfiguration weiterhin geprüft; ein noch nicht laufender nginx-Dienst führt dabei nicht zu einem unnötigen Paketkonfigurationsfehler.

Der Testing-Kanal enthält aktualisierte RESTAPI- und Admin-Pakete für den Superadmin-Abgleich während der Paketkonfiguration.

Damit steht der vom Setup-Paket verwendete Abgleichsbefehl im Admin-Paket wieder vollständig zur Verfügung und die RESTAPI liefert den zugehörigen Management-Command.

Der Abgleich bleibt kontrolliert: nicht auflösbare Rollen- oder Konfigurationsabweichungen führen weiterhin zu einem Paketkonfigurationsfehler statt zu einem stillschweigenden Erfolg.

Der Testing-Kanal enthält aktualisierte Admin- und Setup-Pakete für den aktuellen Debian-13-Paketstand.

Die Pakete verwenden nun dieselben öffentlichen Repository- und Build-Informationen wie RESTAPI und Webapp und lassen sich dadurch konsistenter per APT prüfen.

Der Setup-Lauf verwendet den aktuellen Admin-Abgleich für bestehende Installationen. Produktive Stable-Installationen sind nicht betroffen und bleiben auf dem bisherigen freigegebenen Paketstand.

Der Testing-Kanal enthält aktualisierte RESTAPI- und Webapp-Paketstände mit vollständigerer Build-Information im Paket.

Damit lassen sich Paketversion, Repository-Kanal und zugrunde liegender Quellstand bei der technischen Prüfung eindeutiger nachvollziehen.

Diese Änderung betrifft nur den Testing-Kanal. Produktive Stable-Installationen sind nicht betroffen und bleiben auf dem bisherigen freigegebenen Paketstand.

Der Testing-Kanal enthält einen aktualisierten Kandidatenstand für RESTAPI und Webapp, der nicht zur Laufzeit verwendete historische Build-Metadaten nicht mehr in den Runtime-Paketen ausliefert.

Dadurch werden Paketinhalt, CVE-Scan und öffentliche Repository-Prüfung enger auf tatsächlich ausgelieferte Laufzeitbestandteile begrenzt.

Diese Pakete sind noch nicht für produktive Stable-Systeme freigegeben. Die Installation aus dem öffentlichen Testing-Repository und die vollständigen Freigabeprüfungen müssen vor einer Stable-Übernahme erfolgreich abgeschlossen sein.

Der Testing-Kanal enthält zusätzliche Härtungen für bestehende Installationen und Upgrades auf Debian 13.

Setup, Admin, RESTAPI und Webapp werden in einem zusammengehörigen Kandidatenstand geprüft; der normale APT-Pfad soll Superadmin-Rechte, Legacy-Konfigurationen und Laufzeitvalidierung zuverlässiger abgleichen.

Diese Pakete sind noch nicht für produktive Stable-Systeme freigegeben. Neuinstallation, Upgrade, ONLYOFFICE-Integration und Virenschutz müssen vor einer Stable-Übernahme erfolgreich geprüft sein.

Der Testing-Kanal vereinheitlicht weitere API3-Endpunkte mit und ohne abschließenden Schrägstrich.

Auth-Status, Profil, Account-Informationen, Logout und Passwort-Reset-Antworten liefern damit konsistenter kontrollierte Antworten.

Bestehende Integrationen sollten weiterhin die dokumentierten Pfade verwenden; die zusätzliche Toleranz verbessert die Kompatibilität während der Trixie-Qualifikation.

Der Testing-Kanal kann den öffentlichen Syncwerk-HTTPS-Endpunkt beim Setup jetzt explizit in der Serverkonfiguration abgleichen.

Damit verwenden Syncwerk und angebundene Dienste wie ONLYOFFICE denselben öffentlichen Basisnamen, wenn der technische Hostname vom Browser-Endpunkt abweicht.

Die Änderung betrifft den Testing-Kanal. Produktive Stable-Installationen bleiben unverändert, bis die vollständige Stable-Qualifikation abgeschlossen ist.

Der Testing-Kanal übernimmt bei vorhandenen gültigen Let’s-Encrypt-Zertifikaten den öffentlichen HTTPS-Endpunkt wieder in die Syncwerk-nginx-Konfiguration, wenn dort noch das lokale selbstsignierte Syncwerk-Zertifikat eingetragen ist.

Dadurch kann ONLYOFFICE den öffentlichen Syncwerk-Endpunkt weiterhin mit normaler Zertifikatsprüfung erreichen, ohne die Zertifikatsprüfung zu schwächen.

Eigene oder abweichende Zertifikatspfade werden nicht automatisch ersetzt.

Der Testing-Kanal gleicht eine bereits vorhandene ONLYOFFICE-Installation nun auch während des normalen Syncwerk-Setup-Laufs ab.

Dabei werden Syncwerk und DocumentServer auf denselben JWT-Signaturschlüssel gebracht, ohne ONLYOFFICE neu zu installieren.

Das reduziert Fehler bei Dokumentbearbeitung und Rückspeicherung nach einem Paketupgrade, wenn der DocumentServer zuvor einen abweichenden lokalen Schlüssel verwendet hat.

Der Testing-Kanal akzeptiert den API3-Login-Endpunkt nun konsistent mit und ohne abschließenden Schrägstrich.

Der Endpunkt verarbeitet JSON- und Formularanfragen einheitlich und gibt den erzeugten Zugriffstoken zusätzlich im Antwortkörper zurück.

Fehlerhafte Remember-Flag-Werte führen nicht mehr zu Serverfehlern, sondern werden kontrolliert als deaktivierte Option behandelt.

Der Testing-Kanal prüft bei der ONLYOFFICE-Einrichtung nun zusätzlich den öffentlich erreichbaren Syncwerk-HTTPS-Endpunkt.

ONLYOFFICE wird erst als konfiguriert eingetragen, wenn der öffentliche Healthcheck über ein vom System als vertrauenswürdig bewertetes Zertifikat erreichbar ist.

Selbstsignierte oder anderweitig nicht vertrauenswürdige Zertifikate führen zu einem kontrollierten Abbruch der Einrichtung, damit Dokumentbearbeitung und Rückspeicherung nicht in einem scheinbar erfolgreichen, aber später fehlschlagenden Zustand landen.

Der Testing-Kanal synchronisiert den ONLYOFFICE-JWT-Secret nun explizit zwischen Syncwerk und dem lokal installierten DocumentServer.

Damit verwendet der DocumentServer denselben Signaturschlüssel wie die Syncwerk-RESTAPI, auch wenn das ONLYOFFICE-Paket beim Installationslauf bereits einen eigenen Standardwert erzeugt hat.

Die Änderung betrifft den Testing-Kanal. Produktive Stable-Installationen bleiben unverändert; eine Übernahme in Stable erfolgt erst nach abgeschlossener Installations-, Upgrade- und Integrationsprüfung.

Der Testing-Kanal verwendet für die ClamAV-Readiness nun den konkreten clamdscan-Ping, der auch in der Laufzeitkonfiguration geprüft wird.

Dadurch bricht die Virenschutz-Einrichtung kontrolliert ab, wenn der ClamAV-Daemon nicht erreichbar ist, statt einen scheinbar erfolgreichen Zustand zu melden.

Die Änderung betrifft die Vorabprüfung für den Testing-Kanal; produktive Stable-Installationen bleiben unverändert, bis die vollständige Stable-Qualifikation abgeschlossen ist.

Der Testing-Kanal korrigiert die Bootstrap-Admin-Recovery für ältere Installationszustände mit bereits vorhandenem Account-Dienst-Benutzer.

Die Recovery-Prüfung verwendet nun den kompatiblen Account-Dienst-Enumerator statt eines Django-Queryset-Aufrufs, der bei diesem Account-Modell nicht verfügbar ist.

Der Reparaturpfad bleibt auf den eng begrenzten Bootstrap-Zustand ohne vorhandenen Web/Auth-Benutzer beschränkt.

Der Testing-Kanal repariert zusätzliche ältere Bootstrap-Zustände, bei denen der Account-Dienst-Benutzer bereits existiert, aber der Web-Login noch fehlt.

Die Reparatur bleibt auf einen eng begrenzten Zustand ohne vorhandenen Web/Auth-Benutzer und ohne weitere aktive Staff-Administratoren beschränkt.

Normale finale Admin-Zugangsdaten bleiben der Operator-Vertrag und werden nicht still überschrieben.

Der Testing-Kanal erkennt ältere finale Admin-Dateien mit Doppelpunkt-Schreibweise wie Mail: und Pass: als gültige Bootstrap-Credential-Quelle.

Dadurch kann ein unvollständiger älterer Installationszustand über den normalen APT-Upgradepfad repariert werden, ohne normale Operator-Zugangsdaten still zu überschreiben.

Neu finalisierte Admin-Dateien bleiben im kanonischen Mail = / Pass = Format.

Der Testing-Kanal erkennt zusätzliche unvollständige Bootstrap-Admin-Zustände, bei denen die finale Admin-Datei bereits existiert, die Web-Anmeldung aber noch nicht nutzbar ist.

Die Reparatur greift nur in einem eng begrenzten Bootstrap-Sonderfall ohne vorhandenen Web-Login und ohne weitere aktive Staff-Administratoren.

Normale finale Admin-Zugangsdaten bleiben der Operator-Vertrag und werden nicht still überschrieben.

Der Testing-Kanal kann unvollständig angelegte Bootstrap-Administratoren robuster reparieren.

Wenn nach einem abgebrochenen alten Setup bereits ein Account-Dienst-Benutzer existiert, aber die Web-Anmeldung noch fehlt, wird der Zustand beim Upgrade kontrolliert vervollständigt.

Finale Mail/Pass-Dateien bleiben der Operator-Vertrag und werden nicht still überschrieben.

Das Setup trennt den internen Bootstrap-Zwischenzustand künftig nach /etc/syncwerk/admin.json von der finalen Operator-Datei /etc/syncwerk/admin.txt.

Defekte Stable-Zwischenzustände mit JSON-Inhalt in /etc/syncwerk/admin.txt werden beim Upgrade auf Testing erkannt, validiert und in das finale Mail/Pass-Format migriert.

Finale Mail/Pass-Dateien bleiben der stabile Operator-Vertrag und werden nicht als Pending-State behandelt.

Im Testing-Kanal wurde die Freeware-Grenze für Installationen ohne Lizenzdatei vereinheitlicht.

Der Account-Dienst verwendet nun dieselbe 20-Benutzer-Grenze wie die zentrale Lizenzprüfung.

Die Einrichtung des Virenschutzes installiert nun das benötigte Paket clamdscan und wartet auf initiale ClamAV-Signaturdatenbanken.

Unvollständige Dienststarts durch noch fehlende Signaturen werden kontrolliert erkannt und vor der Funktionsprüfung bereinigt.

Die Einrichtung von ONLYOFFICE und ClamAV wurde robuster gemacht.

Hilfebefehle können ohne Systemänderung aufgerufen werden, und unvollständige Paketinstallationen werden kontrolliert erkannt.

Außerdem verarbeitet die RESTAPI fehlerhafte Login-Eingaben robuster.

Bei einer Neuinstallation im Testing-Kanal übernimmt das Setup ein vorhandenes gültiges Let's-Encrypt-Zertifikat, statt es durch ein selbstsigniertes Zertifikat zu ersetzen.

Die Setup-Ausgabe zeigt den gewählten TLS-Modus an.

Das Setup wartet vor der Bootstrap-Admin-Erzeugung auf die echte Account-Dienst-Bereitschaft.

Administratordaten werden nach erfolgreicher Anlage validiert und ohne Ausgabe sensibler Daten verarbeitet.

Die Admin-Hilfe zeigt Werkzeuge für Rollen- und Lizenzabgleich sichtbar an.

Das RESTAPI-Paket nutzt beim Upgrade einen Debian- und systemd-konformen Neustartpfad.

Grid- und Lightbox-Hoverflächen bleiben im Darkmode dunkel und erzeugen keine hellen Zeilenflächen mehr.

Das Setup kann Legacy-Adminrollen idempotent abgleichen.

Unvollständige Lizenz-Featurematrizen werden als Administrationshinweis erkannt, und die Weboberfläche reduziert zu helle Darkmode-Flächen.

Lokale RESTAPI-Konfigurationen bleiben beim Paketupgrade erhalten, während Paketdefaults weiterhin aktualisiert werden.

Fehlende Virenschutz-Bereitschaftswerkzeuge werden als kontrollierter Bereitschaftsfehler statt als Traceback behandelt.