La publication originale du forum est une présentation accompagnée d’un lien vers un tutoriel externe, et non un compte rendu complet du déploiement. Elle promet une configuration rapide de CasaOS pour Obsidian Self-hosted LiveSync, mais ne conserve pas l’image CouchDB, les chemins des volumes, les identifiants, la configuration HTTPS ni la configuration des clients utilisées dans la vidéo originale.
Pour une installation actuelle, utilisez le projet maintenu Self-hosted LiveSync comme référence technique. La configuration en amont repose toujours principalement sur CouchDB et documente explicitement Docker, la persistance des données et de la configuration CouchDB, l’exposition en HTTPS ainsi qu’un URI de configuration pour configurer les clients Obsidian.
Self-hosted LiveSync est une couche de synchronisation, pas l’application Obsidian elle-même
Obsidian reste installé sur vos appareils de bureau ou mobiles. Self-hosted LiveSync ajoute un plugin de synchronisation communautaire ainsi qu’une base de données côté serveur, afin que les modifications apportées aux coffres puissent être synchronisées entre les appareils sans dépendre du service payant Obsidian Sync.
Le projet en amont est un logiciel communautaire, et non un service officiel d’Obsidian.
CouchDB est le composant serveur principal
Le guide de configuration actuel en amont utilise CouchDB comme backend auto-hébergé principal. Son exemple Docker crée des répertoires persistants pour les données et la configuration de CouchDB avant de démarrer le conteneur.
Utilisez la configuration actuelle du serveur Self-hosted LiveSync plutôt que de recopier d’anciennes balises d’image présentées dans une vidéo.
Conservez la base de données CouchDB en dehors du conteneur éphémère
La base de données contient la représentation synchronisée de vos notes et l’état associé. Mappez les répertoires de données et de configuration de CouchDB vers un stockage CasaOS persistant afin que la recréation du conteneur n’efface pas le backend de synchronisation.
Conservez ces dossiers séparément des couches Docker temporaires ordinaires.
Utilisez des identifiants CouchDB uniques
Ne conservez pas les noms d’utilisateur ou mots de passe d’exemple d’un tutoriel. Créez des identifiants d’administrateur CouchDB robustes et uniques, et ne les incluez pas dans des captures d’écran, des fichiers Compose partagés ou des publications publiques sur le forum.
Si des identifiants sont exposés, renouvelez-les et examinez immédiatement toute instance CouchDB accessible à distance.
La synchronisation à distance doit utiliser HTTPS
Si plusieurs appareils doivent se synchroniser en dehors du réseau local, exposez CouchDB via une connexion HTTPS sécurisée plutôt que de publier directement du HTTP non chiffré sur Internet. La documentation en amont fournit des exemples de proxy inverse et de configuration de domaine.
Un réseau VPN ou superposé constitue une autre option lorsque seuls vos propres appareils doivent y accéder.
Les paramètres CORS et d’origine doivent correspondre au fonctionnement du client
La configuration de sécurité de CouchDB peut bloquer les requêtes provenant d’un navigateur ou d’une vue web, même lorsque le serveur est accessible. La procédure de configuration de Self-hosted LiveSync configure le comportement requis de CouchDB, au lieu de considérer qu’un conteneur de base de données générique est prêt dès que le port 5984 est ouvert.
Utilisez l’URI de configuration avec précaution
Les recommandations actuelles en amont permettent de générer un URI de configuration afin qu’un autre appareil Obsidian puisse importer les paramètres de connexion. Cet URI peut contenir des informations de connexion sensibles.
Traitez-le comme un secret : envoyez-le uniquement à votre propre appareil de confiance et évitez de le publier dans des captures d’écran ou un historique de discussion auquel d’autres personnes pourraient accéder.
La synchronisation en temps réel n’élimine pas les conflits de modification
Deux appareils qui modifient presque simultanément la même note peuvent toujours créer des conflits ou nécessiter une réconciliation. L’auto-hébergement vous donne le contrôle du serveur ; il ne transforme pas l’édition distribuée en système de fichiers à rédacteur unique.
Testez le fonctionnement avec un coffre temporaire avant de migrer votre unique copie de notes importantes.
La synchronisation n’est pas une sauvegarde
Si une note est supprimée et que cette suppression est synchronisée avec tous les clients, le système synchronisé a fait son travail. Conservez des sauvegardes indépendantes et versionnées du coffre Obsidian et, lorsque cela est approprié, des données CouchDB.
Cela vous protège contre les suppressions accidentelles, les bugs de plugin, la corruption de la base de données ou une modification groupée effectuée par erreur.
La source est spécifique à CasaOS
Le tutoriel historique ciblait CasaOS. Si l’hôte utilise désormais ZimaOS, employez le flux actuel de l’App Store ou de Compose de ZimaOS ainsi que les chemins de stockage actuels, plutôt que de supposer que la même structure de paquets CasaOS s’applique.
FAQ sur Obsidian LiveSync
La publication originale du forum contient-elle la configuration Compose complète ?
Non. Elle renvoie principalement vers le tutoriel externe de Big Bear.
Quel backend la documentation actuelle de Self-hosted LiveSync utilise-t-elle ?
La configuration actuelle en amont utilise CouchDB et fournit une procédure de déploiement Docker.
La synchronisation auto-hébergée remplace-t-elle les sauvegardes ?
Non. Conservez une sauvegarde indépendante du coffre, car les suppressions et les mauvaises modifications peuvent elles aussi être synchronisées.
