Die YAML-Datei aus der Quelle startete BookLore auf ZimaOS erfolgreich und ist ein wertvoller Beleg dafür, dass ein BookLore- und MariaDB-Stack mit zwei Diensten auf der Plattform funktioniert. Sie sollte heute jedoch nicht unverändert kopiert werden. Die gepflegte BookLore-Bereitstellung verwendet inzwischen aktualisierte Image-Namen, ein klareres .env Modell, Gesundheitsprüfungen und explizites Speicherverhalten wie DISK_TYPE.
Die Quelle verwendete BookLore zusammen mit MariaDB
Die YAML-Datei erstellte zwei Dienste in einem privaten Docker-Netzwerk: BookLore auf Port 6060 und einen MariaDB-Container von LinuxServer. Außerdem ordnete sie Anwendungsdaten, Bücher, BookDrop und die MariaDB-Konfiguration dauerhaften Host-Ordnern zu.
Die Passwörter aus der Quelle nicht wiederverwenden
Die veröffentlichte YAML-Datei verwendete Passwort für das BookLore-Datenbankpasswort und das MariaDB-Root-Passwort. Diese Werte sind öffentliche Beispiele und keine sicheren Zugangsdaten.
Die aktuellen Upstream-Hinweise verschieben Geheimnisse in eine .env Datei auf und erwartet, dass Benutzer ihre eigenen Werte auswählen.
Aktuelles Upstream verwendet den Image-Namensraum booklore-app
Die aktuelle BookLore-Dokumentation führt ghcr.io/booklore-app/booklore:latest als Haupt-Image und verwendet weiterhin einen auf MariaDB 11.4 basierenden Dienst.
Verwende die aktuelle BookLore-Bereitstellungsanleitung, statt die Image-Tags vom Februar 2026 festzuschreiben.
Daten, Bücher, BookDrop und Datenbankspeicher getrennt halten
Aktuelles BookLore verwendet dauerhafte Zuordnungen für:
-
/app/data— Anwendungsdaten und Metadaten-Cache; -
/books— verwaltete Bibliothek; -
/bookdrop— automatischer Import-/Drop-Ordner; - MariaDB-Speicher und -Konfiguration — der Datenbankstatus.
Große Bibliotheken nicht standardmäßig auf ZimaOS-HD speichern
Die Quelle mischte /media/ZimaOS-HD/AppData und /DATA/AppData. Aktuelles ZimaOS empfiehlt, Anwendungsdaten und Bibliotheken auf einem echten Speicherpool zu speichern, statt das Systemlaufwerk zu füllen.
USER_ID und GROUP_ID prüfen, statt 1000 anzunehmen
Die Quelle verwendete fest codierte UID/GID 1000. Das kann in einer Umgebung funktionieren, aber bei aktuellen Containern und Host-Ordnern sollten die tatsächlichen Eigentümer und Berechtigungen der ausgewählten Speicherpfade geprüft werden.
Aktuelles Compose fügt eine BookLore-Gesundheitsprüfung hinzu
Modernes Upstream-Compose enthält eine HTTP-Gesundheitsprüfung für BookLore sowie eine Gesundheitsabhängigkeit von der Datenbank. Dadurch wird das Startverhalten verbessert, anstatt einfach beide Container zu starten und zu hoffen, dass MariaDB rechtzeitig bereit ist.
Das mobile Problem der Quelle war kein fehlgeschlagener ZimaOS-Installationsvorgang
Der Autor sagte, die Weboberfläche sei gut gewesen, aber die Versuche, eine mobile Verbindung mit Komga-Kompatibilität herzustellen, seien erfolglos gewesen. Später sagte er, dass MoonReader über OPDS funktionierte.
Das sollte als Kompatibilitätsproblem zwischen BookLore und dem Client diagnostiziert werden, nicht als Beweis dafür, dass der BookLore-Server selbst fehlgeschlagen ist.
OPDS passt besser zu vielen Lese-Apps
Aktuelles BookLore setzt neben dem Lesen im Web und der Bibliotheksverwaltung auf OPDS. Wenn eine mobile App OPDS unterstützt, verwenden Sie den aktuellen OPDS-Endpunkt von BookLore und einen authentifizierten Benutzer, statt eine Kompatibilitätsschicht für Komga zu erzwingen.
Datenbank und Bibliothek sichern
Die Datenbank enthält Metadaten, Benutzer, Regale, Lesestatus und Konfiguration. Der Bücherordner enthält die eigentlichen Dateien. Ein Sicherungsplan sollte beides schützen.
Aktuelles BookLore unterscheidet zwischen LOCAL- und NETWORK-Speicher
Aktuelles BookLore umfasst eine DISK_TYPE Einstellung. LOCAL ist der normale Modus, wenn BookLore Dateien direkt verwalten kann. NETWORK ist für NFS-/SMB-ähnlichen Speicher vorgesehen und deaktiviert einige Vorgänge zur Dateiumorganisation.
Wählen Sie den Modus abhängig davon, wo die Bibliothek eingebunden ist, statt die YAML-Datei aus der Quelle ohne dieses neuere Verhalten zu kopieren.
BookDrop ist ein Importpostfach, nicht die maßgebliche Bibliothek
Der /bookdrop Der Ordner ist für Dateien vorgesehen, die BookLore aufnehmen soll. Halten Sie ihn getrennt von /books damit automatische Importe die Unterscheidung zwischen neu eingehenden Dateien und der verwalteten Bibliothek nicht verwischen.
MariaDB konsistent sichern
Das Kopieren eines aktiven Datenbankverzeichnisses ist nicht immer gleichbedeutend mit einer konsistenten Datenbanksicherung. Verwenden Sie für wichtige Bibliotheken einen MariaDB-kompatiblen Dump oder stoppen Sie die Datenbank vor einer Sicherung auf Dateisystemebene ordnungsgemäß. Überprüfen Sie anschließend die Wiederherstellungsverfahren.
Versionen vor automatischen Aktualisierungen festlegen oder prüfen
In der Quelle wurde latest für BookLore. Das ist praktisch, aber ein zukünftiger Abruf kann unerwartet Änderungen an der Anwendung oder Datenbank einführen. Wenn Stabilität wichtig ist, prüfen Sie die Upstream-Versionshinweise und sichern Sie die Datenbank, bevor Sie den Stack mit einem neueren Image neu erstellen.
BookLore auf ZimaOS – FAQ
Hat die YAML-Datei aus der Quelle BookLore erfolgreich gestartet?
Ja. Der Autor veröffentlichte ein funktionierendes BookLore-Dashboard.
Sollten die öffentlich sichtbaren Passwortwerte aus der Quelle wiederverwendet werden?
Nein. Erstellen Sie eindeutige BookLore- und MariaDB-Zugangsdaten.
Welcher mobile Ansatz funktionierte für den Autor der Quelle?
Sie berichteten, dass MoonReader über OPDS funktionierte, während ihre Versuche mit Komga-Kompatibilität erfolglos waren.
