Je me suis décidé a installer sur mon serveur linux Kresus.
J’ai (j’espere) suivi toute la documentation.
J’ai choisi d’installé via docker-compose.
J’ai crée mon docker-compose.yml et mon fichier .env
Dans le docker-compose j’ai supprimé la partie traefik ainsi que la partie apprise car je n’en ai pas besoin.
J’ai deja un nginx de configurer sur le serveur qui me permet d’exposer certains de mes services donc j’aimerai bien aussi l’utiliser a la place de traefik (est-ce possible ?)
J’ai cloné le contenu du git de woob dans le dossier /home/xavier/XXXXXXX/woob
Lorsque je fais « sudo docker compose up -d » tout s’execute mais quand je regarde dans Portainer les logs du container de Kresus j’ai l’erreur suivante:
├─ universalify@0.1.2
├─ utils-merge@1.0.1
├─ uuid@9.0.1
├─ vary@1.1.2
├─ warning@4.0.3
├─ xml2js@0.4.23
├─ xtend@4.0.2
├─ yargs-parser@21.1.1
└─ yargs@17.7.2
Done in 2.18s.
[ENTRYPOINT] Done.
[ENTRYPOINT] Changing rights on user home directory…
at Object.mkdirSync (node:fs:1391:3)
at mkdir (/usr/local/share/.config/yarn/global/node_modules/streamroller/lib/RollingFileWriteStream.js:270:19)
at RollingFileStream._renewWriteStream (/usr/local/share/.config/yarn/global/node_modules/streamroller/lib/RollingFileWriteStream.js:299:5)
at new RollingFileWriteStream (/usr/local/share/.config/yarn/global/node_modules/streamroller/lib/RollingFileWriteStream.js:94:10)
at new RollingFileStream (/usr/local/share/.config/yarn/global/node_modules/streamroller/lib/RollingFileStream.js:18:5)
at openTheStream (/usr/local/share/.config/yarn/global/node_modules/log4js/lib/appenders/file.js:64:20)
at fileAppender (/usr/local/share/.config/yarn/global/node_modules/log4js/lib/appenders/file.js:84:16)
at Object.configure (/usr/local/share/.config/yarn/global/node_modules/log4js/lib/appenders/file.js:144:10)
at /usr/local/share/.config/yarn/global/node_modules/log4js/lib/appenders/index.js:117:29
at Object.onlyOnMaster (/usr/local/share/.config/yarn/global/node_modules/log4js/lib/clustering.js:87:50) {
errno: -13,
syscall: ‹ mkdir ›,
code: ‹ EACCES ›,
path: ‹ /home/xavier/XXXXXXXXXX/.kresus ›
}
Node.js v18.20.5
Je n’arrive pas a comprendre, j’ai du surement faire des erreurs mais je n’arrive pas a savoir lesquelles ?
Pourriez vous m’aider ?
J’ai deja un nginx de configurer sur le serveur qui me permet d’exposer certains de mes services donc j’aimerai bien aussi l’utiliser a la place de traefik (est-ce possible ?)
Tout à fait possible, je n’utilise que nginx également. Selon si ton nginx est sur l’hôte ou dans une instance docker également, la configuration va changer :
si nginx est sur l’hôte, tu auras besoin d’assigner une IP fixe au service kresus dans un réseau pont entre les docker et le réseau de ta machine, puis de faire un upstream vers cette IP fixe sur le port de Kresus (9876 par défaut)
si nginx est dans une instance docker aussi, tu auras besoin que les instances de kresus et de nginx soient sur le même réseau docker ; ensuite tu peux configurer un upstream vers le nom de l’instance kresus (plutôt qu’une IP) + le port.
On pourra revenir là-dessus si besoin, en attendant…
Alors il y a un souci de droits :
l’image de Kresus, au démarrage, essaie de changer les droits à l’intérieur du container, pour avoir tous les droits sur les fichiers à l’intérieur ; ça permet de mettre à jour woob plus facilement, etc.
il semblerait que tu aies instancié l’image de Kresus avec sudo, ou bien qu’il y ait un souci sur /home/xavier/XXXX/.kresus.
Donc, je vois deux pistes :
soit /home/xavier/XXXX n’existe pas, et je ne sais plus si dans ce cas-là docker-compose va créer le répertoire : s’il n’existe pas, essaie de le créer à la main au préalable avec mkdir -p /home/xavier/XXXX
s’il existe déjà, peut-être qu’il a hérité des droits root, dans ce cas-là, tu peux essayer de le supprimer avec les droits root, et de le recréer dans un second temps :
# rm -r /home/xavier/XXXX # en root
$ mkdir -p /home/xavier/XXXX # avec ton user habituel xavier
Ensuite, tu peux essayer de lancer l’image avec ton user à toi, plutôt que root ; c’est généralement une bonne pratique d’éviter de lancer docker avec sudo :
# docker-compose down # en root
$ docker-compose up -d # avec ton user habituel xavier
Merci beaucoup pour votre retour rapide et tres constructif!
En effet je lance mon docker compose en root car j’avais des soucis de droits quand je le lancais avec mon user (xavier).
J’ai suivi la doc (lien vers doc) et ajouté un group docker que j’ai assigné a mon user xavier. J’ai pu ensuite lancer la commander docker compose avec mon user sans soucis.
Cependant le meme probleme apparait (avec la meme stacktrace).
Petite question: dans la variable « KRESUS_DIR » est-ce qu’il faut que le nom du dossier soit « .kresus » ?
Le dossier .kresus est crée avec xavier:xavier (et il existe avant que je lance le conteneur)
Dans ma variable KRESUS_DIR j’ai mis le path suivant « /home/xavier/Docker_files/kresus-config/.kresus » , le dossier kresus-config est assigné avec les droits de mon user xavier, en revanche j’ai vu que une fois que le docker compose a été lancé le dossier « /home/xavier/Docker_files/kresus-config/data » (qui est mappé a /home/user/data dans le container) n’a plus les droits avec xavier:xavier mais il a xavier:bitwarden (un autre groupe que j’ai dans mon system) et tous les sous-dossiers en ont aussi herité), mais je ne comprends pas comment il arrive a selectionner ce groupe…
J’espere avoir apporté quelques informations supplementaires?
Avec un setup docker il est préférable de ne pas toucher à ça je vois que par défaut c’est défini à /home/user/data, qui est un volume exposé par notre image.
Du coup je pense qu’il n’est pas nécessaire de créer le dossier au préalable. Au mieux vous pouvez bind le volume histoire que les données ne soient pas perdues entre deux redémarrages de l’instance, par exemple dans un docker-compose :
kresus:
image: "bnjbvr/kresus"
restart: always
# et toutes les autres entrées
volumes:
- ./data:/home/user/data
C’est « normal » : l’image fait usage d’un user avec un userid « virtuel » qui peut correspond à un userid qui existe sur la machine hôte. Donc sur la machine hôte, si certains programmes essaient de remapper le userid vers un nom d’utilisateur, ça peut être un peu surprenant : par exemple, si sur ma machine hôte 1001 est le user bitwarden, et que l’instance Docker de Kresus utilise un user 1001 pour son utilisateur principal, alors sur la machine hôte les données écrites par le user principal de Kresus peuvent apparaître comme venant du user bitwarden.
TL;DR : en supprimant le KRESUS_DIR de la configuration, je pense que ça va marcher
