Diplo95

Bonjour, j'ai moi aussi installé stirling récemment (aujourd'hui en fait 🙂 ) Je n'ai pas eu trop de soucis. J'étais parti du même tuto que toi @PascalFr, pour finalement utiliser le fichier docker-compose.yml que l'on trouve sur le github du projet. J'ai utilisé la version complète. Dans le message que tu as publié, je vois qu'il y a déjà des problèmes : en particulier des messages d'erreur qui arrivent assez vite : Trying to download from: https://github.com/Stirling-Tools/Stirling-PDF/releases/download/v0.22.0/Stirling-PDF-with-login.jar /scripts/init.sh: line 19: usermod: command not found id: unknown user stirlingpdfgroup /scripts/init.sh: line 23: groupmod: command not found Il faut peut-être chercher par ici. Pourrais-tu poster ton fichier docker-compose ?

Bonjour @.Shad., merci de te pencher sur mon problème. APP_PORT : je prends ta remarque, mais j'avoue que je trouve Docker très pratique, mais que je n'ai encore tout compris des rouages du fonctionnement. Donc Joplin fonctionnant parfaitement, pour l'instant je ne creuse pas plus loin, je ne suis pas assez calé en réseau pour être sûr de ne pas répondre une bêtise, j'essaie quand même : je pensais rendre joignable gotify par l'intermédiaire de mon proxy inverse. J'imagine alors que n'importe quelle appli qui souhaite ensuite push des notifications fera appel à ce service par une requête qui passera par le wan. Si c'est le cas, effectivement, ça peut être plus intéressant de ne pas faire sortir ces messages de mon réseau local. J'ai cependant résolu mon problème. Il était dû à ces warnings concernant les containers orphelins. J'ai fait une rapide recherche et découvert que docker compose utilise le nom du dossier dans lequel le docker-compose.yml est situé ici. Ainsi, si on met tous ses docker-compose.yml dans des dossiers qui portent le même nom, docker-compose trouve alors différents projets qui portent le même nom. J'ai résolu en utilisant cette méthode : https://stackoverflow.com/questions/50947938/docker-compose-orphan-containers-warning Dans mon dossier script, j'ai crée un fichier .env dans lequel j'ai inséré une variable d'environnement : COMPOSE_PROJECT_NAME=myproject Et j'ai maintenant un container qui se construit sans intérférer avec le container joplin et une appli qui tourne. Ne me reste plus qu'à me pencher sur la config réseau de mon appli.

Bonjour j'ai un serveur joplin qui fonctionne parfaitement depuis des mois. J'essaie aujoud'hui de monter un serveur de notifications gotify en docker. Mais il semble qu'il y ait un conflit entre les deux, sans que j'arrive à comprendre où. Voici le docker-compose de joplin : version: '3' services: db: image: postgres:13.1 # Download latest postgres image container_name: postgres-db # Here you can give the container a name of your liking restart: unless-stopped # Restart if not stopped manually volumes: - /volume1/docker/joplin/joplin-data:/var/lib/postgresql/data # Make database files persistent. Otherwise your data is lost when the container is destroyed. environment: - APP_PORT=22300 # Specify port joplin-server is reachable at - POSTGRES_PASSWORD=****** # Specify database password - POSTGRES_USER=****** # Specify database user - POSTGRES_DB=joplin # Specify database name app: image: joplin/server:latest # Download joplin-server image 2.2.5 the latest at the time container_name: joplin-server labels: - com.centurylinklabs.watchtower.enable=true depends_on: - db ports: - "22300:22300" # Expose internal port to LAN restart: unless-stopped environment: - APP_BASE_URL=https://joplin.**********.fr # If you do not want to expose joplin-server to the internet use your LAN-IP and port - DB_CLIENT=pg - POSTGRES_PASSWORD=****** # Must be the same as above - POSTGRES_DATABASE=joplin # Must be the same as above - POSTGRES_USER=******* # Must be the same as above - POSTGRES_PORT=5432 # Postgres internal port - POSTGRES_HOST=db Voici le docker-compose du serveur gotify : version: "3" services: app: image: gotify/server container_name: gotify restart: unless-stopped ports: - 127.0.0.1:8764:80 environment: - TZ='Europe/Paris' - GOTIFY_DEFAULTUSER_NAME=admin - GOTIFY_DEFAULTUSER_PASS=admin - GOTIFY_PASSSTRENGTH=10 - GOTIFY_UPLOADEDIMAGESDIR=data/images - GOTIFY_PLUGINSDIR=data/plugins volumes: - ./data:/app/data Lorsque j'essaie de monter le conteneur gotify, voici le retour en ligne de commandes : root@DS220:/volume1/docker/gotify/script# docker-compose up -d [+] Running 5/5 ⠿ app Pulled 9.3s ⠿ 00d3338ddf14 Pull complete 3.5s ⠿ 557ea8465e9a Pull complete 4.6s ⠿ 3ecb6f16884e Pull complete 5.5s ⠿ 793754435704 Pull complete 6.6s WARN[0009] Found orphan containers ([sabnzbd sonarr radarr jellyfin postgres-db watchtower]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. [+] Running 1/2 ⠿ Container joplin-server Recreated 39.9s ⠼ Container gotify Starting 6.4s Error response from daemon: driver failed programming external connectivity on endpoint gotify (a9b441ca577a1716274272aca0f4d30b8df97e992610938065568ad31b04d1fa): Error starting userland proxy: listen tcp4 127.0.0.1:8000: bind: address already in use root@DS220:/volume1/docker/gotify/script# Et donc je constate qu'il me recrée l'image joplin, et je ne sais pas pourquoi. Plus problématique : en fait, il le recrée, mais ça plante : je ne peux plus synchroniser avec les clients joplin. J'ai pensé à un problème de ports, alors j'ai cherché des conflits : root@DS220:/volume1/docker/gotify/script# netstat -tulpn | grep LISTEN tcp 0 0 0.0.0.0:662 0.0.0.0:* LISTEN 10076/statd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9150/sshd: /usr/bin tcp 0 0 127.0.0.1:33304 0.0.0.0:* LISTEN 2004/synomibactiono tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 20407/postgres tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:892 0.0.0.0:* LISTEN 10052/mountd tcp 0 0 0.0.0.0:8989 0.0.0.0:* LISTEN 501/docker-proxy tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 13522/smbd tcp 0 0 0.0.0.0:8096 0.0.0.0:* LISTEN 419/jellyfin tcp 0 0 127.0.0.1:512 0.0.0.0:* LISTEN 29315/termd tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 29198/docker-proxy tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:161 0.0.0.0:* LISTEN 10516/snmpd tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 3325/docker-proxy tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN 5194/syncd tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 18872/transmission- tcp 0 0 0.0.0.0:10211 0.0.0.0:* LISTEN 26005/docker-proxy tcp 0 0 0.0.0.0:10212 0.0.0.0:* LISTEN 25963/docker-proxy tcp 0 0 0.0.0.0:7878 0.0.0.0:* LISTEN 32194/docker-proxy tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 29171/docker-proxy tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 13522/smbd tcp 0 0 0.0.0.0:5357 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:4045 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 7439/rpcbind tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3351/docker-proxy tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:10002 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 127.0.0.1:915 0.0.0.0:* LISTEN 23389/httpd24 tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN 18872/transmission- tcp6 0 0 :::662 :::* LISTEN 10076/statd tcp6 0 0 :::22 :::* LISTEN 9150/sshd: /usr/bin tcp6 0 0 :::3001 :::* LISTEN 23745/AdGuardHome tcp6 0 0 :::443 :::* LISTEN 15980/nginx: master tcp6 0 0 :::892 :::* LISTEN 10052/mountd tcp6 0 0 :::8989 :::* LISTEN 506/docker-proxy tcp6 0 0 :::3261 :::* LISTEN - tcp6 0 0 :::445 :::* LISTEN 13522/smbd tcp6 0 0 :::3263 :::* LISTEN - tcp6 0 0 :::8000 :::* LISTEN 29203/docker-proxy tcp6 0 0 :::3264 :::* LISTEN - tcp6 0 0 :::3265 :::* LISTEN 5859/scsi_plugin_se tcp6 0 0 :::2049 :::* LISTEN - tcp6 0 0 :::9090 :::* LISTEN 3331/docker-proxy tcp6 0 0 :::6690 :::* LISTEN 5194/syncd tcp6 0 0 :::10211 :::* LISTEN 26020/docker-proxy tcp6 0 0 :::10212 :::* LISTEN 25969/docker-proxy tcp6 0 0 :::7878 :::* LISTEN 32200/docker-proxy tcp6 0 0 :::9000 :::* LISTEN 29177/docker-proxy tcp6 0 0 :::5000 :::* LISTEN 15980/nginx: master tcp6 0 0 :::5001 :::* LISTEN 15980/nginx: master tcp6 0 0 :::139 :::* LISTEN 13522/smbd tcp6 0 0 :::5005 :::* LISTEN 17507/httpd tcp6 0 0 :::5357 :::* LISTEN 15980/nginx: master tcp6 0 0 :::4045 :::* LISTEN - tcp6 0 0 :::5006 :::* LISTEN 17507/httpd tcp6 0 0 :::111 :::* LISTEN 7439/rpcbind tcp6 0 0 :::8080 :::* LISTEN 3360/docker-proxy tcp6 0 0 :::80 :::* LISTEN 15980/nginx: master tcp6 0 0 :::10002 :::* LISTEN 15980/nginx: master tcp6 0 0 :::51413 :::* LISTEN 18872/transmission- tcp6 0 0 :::53 :::* LISTEN 23745/AdGuardHome root@DS220:/volume1/docker/gotify/script# Mais il n'y a rien qui me saute aux yeux. Une petite idée ? Merci

@Einsteinium, @oracle7 Bonjour, pour mon cas personnel, en changeant dans le fichier account.conf les variables SAVED_SYNO_Username et SAVED_SYNO_Password en respectivement SYNO_Username et SYNO_Password, je n'ai plus aucun message d'erreur, le déploiement se fait à nouveau. En toute humilité, je pense comme @Eridani78 qu'il faudrait modifier le tuto.

@oracle7 Je comprends toutes les remarques que tu me fais et elles sont toutes cohérentes. MAIS : tout fonctionnait à merveille depuis des mois avec la configuration que j'avais. Je sais que ce n'est pas un argument recevable lorsque soudainement ça bugge, et c'est donc l'occasion de repartir sur des bases plus saines. 1. Je suis d'accord avec tes remarques. Cependant, je ne me rappelle plus pourquoi j'avais dû adapter le fichier account.conf à l'époque. J'ai changé les ports d'accès à mon NAS en suivant les très bons tutos trouvés sur ce forum. Je pense que tu as raison pour le port 443 : c'est l'unique port d'entrée à mon NAS, mais depuis l'extérieur uniquement, grâce à l'utilisation du reverse proxy. Je vais revoir cet aspect. 2. Je vais donc essayer en enlevant tous les caractères spéciaux. Mais encore une fois, tout fonctionnait bien jusqu'à il y a quelques jours. Est-ce que ça ne baisse pas le niveau de protection du mot de passe ? 3. J'ai bien lu le tuto, et plusieurs fois. Je ne comprends toujours pas l'utilité du docker-compose.yml. En effet, n'est-ce pas la tache planifiée quotidienne qui crée le docker ?

Merci @oracle7 de te pencher sur mon problème. J'aurais dû rentrer en peu plus dans les détails : 1. Pour le AUTOUPGRADE : Je ne savais pas. Cependant, après avoir défini la tâche paramétrable comme ceci : docker pull neilpang/acme.sh:3.0.5 docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart always neilpang/acme.sh:latest daemon et changé account.conf comme ceci : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='0' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='**************' SAVED_OVH_AS='*************************' SAVED_OVH_CK='**************************' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='192.168.*.*' SAVED_SYNO_Port='443' SAVED_SYNO_Username='*******************' SAVED_SYNO_Password='*********************' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='ACME_Wilcard_LE_*.*************.fr' UPGRADE_HASH='***************************************' lorsque je lance manuellement la tache, je m'attends donc à avoir la version 3.0.5 du script acme.sh. Or : 2. J'ai lu comme toi le message d'erreur et j'ai bien vérifié les variables du fichier account.conf -> elles sont correctes et ne créaient pas d'erreur jusque là. J'ai un doute sur un caractère que j'ai utilisé dans mon MDP : '&' . En effet, dans mon message d'erreur, il recopie le mot de passe après ce caractère. Peut être est un caractère qui induit une particularité, y compris entre ' '. 3. J'aurais dû être beaucoup plus précis en effet. Je trouve bien le fichier docker-compose en première page du post (d'ailleurs comment sais tu que je porte effectivement des lunettes 🙂 ). Je ne le retrouve par contre dans aucun de mes dossiers sur le NAS.

Bonjour à tous, j'ai un soucis lors du renouvellement de mon certificat depuis quelques jours. J'ai lu les commentaires récents et je l'attribue donc éventuellement au déploiement de la version 3.0.6 du script Acme. Tout d'abord, voici mon message d'erreur : Le planificateur de tâches a terminé une tâche planifiée. Tâche : RenewCertifLE_Docker Heure de début : Sun, 05 Feb 2023 05:00:01 GMT Heure d'arrêt : Sun, 05 Feb 2023 05:00:02 GMT État actuel : 1 (Interrompu) Sortie/erreur standard : /usr/local/bin/acme.sh: eval: line 2401: **************: not found [Sun Feb 5 04:00:02 UTC 2023] SYNO_Username & SYNO_Password must be set [Sun Feb 5 04:00:02 UTC 2023] Error deploy for domain:gpointeau.fr [Sun Feb 5 04:00:02 UTC 2023] Deploy error. Il se trouve que les ************* correspondent à une partie de mon mot de passe pour accéder au compte créé exclusivement pour le renouvellement de mon certificat Let's Encrypt. Je rajoute que ce renouvellement se passait sans aucun soucis jusqu'à maintenant. Pour faire un test, je souhaite donc revenir à la version 3.0.5 du script Acme. C'est là que mes lacunes apparaissent. J'ai suivi le tuto de la première page, mais je ne trouve plus le fichier docker-compose.yml en Cbis. Je pense donc que j'ai dû faire uniquement la partie C. J'ai donc modifié la tache récurrente en : docker pull neilpang/acme.sh:3.0.5 docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart always J'ai lancé manuellement cette tâche, mais la version du script reste toujours la même : 3.0.6. Pouvez-vous m'expliquer comment revenir à la version 3.0.5 svp ? Merci

Bonjour @.Shad. si je suis ta procédure, le dossier se monte correctement. Le problème est dans le montage automatique au démarrage.

Merci @.Shad., je suis en déplacement en ce moment. J'essaierai dès que possible.

J'ai bien des services qui portent ces noms : ... network-online.target network-pre.target network.target ...

Je rencontre un autre problème : au boot, le dossier ne se monte pas automatiquement. Voici le message d'erreur dans journalctl -u media-greg-DonneesPartagees.mount : sept. 19 22:18:07 greg-nuc systemd[1]: Mounting cifs mount for DonneesPartagees shared folder... sept. 19 22:18:07 greg-nuc mount[1150]: mount error(101): Network is unreachable sept. 19 22:18:07 greg-nuc mount[1150]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) lines 1-38 Je vous remets le fichier media-greg-DonneesPartagees.mount : [Unit] Description = cifs mount for DonneesPartagees shared folder Requires=network-online.target After=network-online.target [Mount] What=//192.168.1.4/DonneesPartagees Where=/media/greg/DonneesPartagees Type=cifs Options=uid=1000,gid=1000,credentials=/home/greg/.synology/ds220,vers=2.0 [Install] WantedBy=multi-user.target Je ne comprends pas pourquoi il n'attend pas que le réseau s'initialise. J'ai pourtant bien inséré les lignes Requires et After. Une idée ? Merci.

Oups, non ! Il faut donc mettre comme protocole maximum SMB 3 j'imagine. Mais pour le minimum ? Est ce qu'il y a des versions de SMB obsolètes présentant un risque, ou bien, on peut laisser SMB1 ? Merci

Bonjour à tous, je me joins à la discussion car je rencontre un problème lorsque je tente de monter un dossier partagé sur mon DS220+ sur mon PC avec Ubuntu 22.04. Mon but : monter le dossier volume1/DonneesPartagees de mon NAS sur mon PC J'ai donc suivi le tuto : 1 : j'ai supprimé la ligne dans /etc/fstab (et oui, j'avais aussi commencé par cette méthode) 2: j'ai créé un fichier ds220 à l'emplacement /home/greg/.synology j'ai rempli les noms d'utilisateurs et password nécessaires pour me connecter à la session propriétaire du dossier partagé 3 : j'ai ensuite créé le fichier /etc/systemd/system/media-greg-ds220.mount [Unit] Description = cifs mount for DonneesPartagees shared folder Requires=network-online.target After=network-online.target [Mount] What=//192.168.1.4/volume1/DonneesPartagees Where=/media/greg/ds220 Type=cifs Options=uid=1000,gid=1000,credentials=/home/greg/.synology/ds220 [Install] WantedBy=multi-user.target Lorsque je teste le montage, j'ai ce résultat : greg@greg-nuc:~/.synology$ sudo systemctl start media-greg-ds220.mount && sudo systemctl status media-greg-ds220.mount Job failed. See "journalctl -xe" for details. greg@greg-nuc:~/.synology$ sudo journalctl -u media-greg-ds220.mount sept. 19 16:02:02 greg-nuc systemd[1]: Mounting cifs mount for DonneesPartagees shared folder... sept. 19 16:02:02 greg-nuc mount[9849]: mount: /media/greg/ds220: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program. sept. 19 16:02:02 greg-nuc systemd[1]: media-greg-ds220.mount: Mount process exited, code=exited, status=32/n/a sept. 19 16:02:02 greg-nuc systemd[1]: media-greg-ds220.mount: Failed with result 'exit-code'. sept. 19 16:02:02 greg-nuc systemd[1]: Failed to mount cifs mount for DonneesPartagees shared folder. sept. 19 16:09:21 greg-nuc systemd[1]: Mounting cifs mount for DonneesPartagees shared folder... sept. 19 16:09:21 greg-nuc mount[10516]: mount error(95): Operation not supported sept. 19 16:09:21 greg-nuc mount[10516]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) sept. 19 16:09:21 greg-nuc systemd[1]: media-greg-ds220.mount: Mount process exited, code=exited, status=32/n/a sept. 19 16:09:21 greg-nuc systemd[1]: media-greg-ds220.mount: Failed with result 'exit-code'. sept. 19 16:09:21 greg-nuc systemd[1]: Failed to mount cifs mount for DonneesPartagees shared folder. sept. 19 16:26:42 greg-nuc systemd[1]: Mounting cifs mount for DonneesPartagees shared folder... sept. 19 16:26:42 greg-nuc mount[11447]: mount error(95): Operation not supported sept. 19 16:26:42 greg-nuc mount[11447]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) sept. 19 16:26:42 greg-nuc systemd[1]: media-greg-ds220.mount: Mount process exited, code=exited, status=32/n/a sept. 19 16:26:42 greg-nuc systemd[1]: media-greg-ds220.mount: Failed with result 'exit-code'. sept. 19 16:26:42 greg-nuc systemd[1]: Failed to mount cifs mount for DonneesPartagees shared folder. greg@greg-nuc:~/.synology$ J'ai installé cifs-utils, mais ça ne résout pas mon problème. Auriez-vous une idée du problème ? EDIT : J'ai trouvé la solution. L'erreur 95 renvoie visiblement un problème de version du protocole SMB. Il faut rajouter la version 2.0 dans les options pour lancer "le montage" : <code> [Unit] Description = cifs mount for DonneesPartagees shared folder Requires=network-online.target After=network-online.target [Mount] What=//192.168.1.4/DonneesPartagees Where=/media/greg/ds220 Type=cifs Options=uid=1000,gid=1000,credentials=/home/greg/.synology/ds220,vers=2.0 [Install] WantedBy=multi-user.target </code>

Je n'ai pas la possibilité de le répéter tous les deux mois : j'ai tous les mois, ou ensuite tous les 3 mois. Comment faites-vous pour personnaliser la fréquence ?

Bonjour @Einsteinium, j'ai tenté d'utiliser le script python pour le renouvellement de mon certificat, mais ça s'est soldé par un échec à chaque fois. Ayant entre temps basculé sur DSM 7, j'ai donc décidé de basculer sur la méthode par docker. J'ai sauté le pas ce jour. Il m'a fallu environ 3 heures pour arriver au bout du tuto. En effet, j'ai buté longtemps sur deux points : Lors de l'édition du fichier account.conf : malgré le fait de l'avoir créé dans notepad++, les sauts de ligne n'étaient pas correctement codés, générant des erreurs de création de certificats chez OVH. Le symptôme était ce message d'erreur : Les lignes en question étant les lignes ne comportant qu'un saut de ligne. J'ai aussi rencontré beaucoup de difficultés pour résoudre les problèmes d'identification lors du lancement de la commande suivante : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" En effet, il a fallu que je m'y reprenne à plusieurs fois pour effectivement supprimer la vérification en 2 étapes pour le compte que j'ai créé spécialement pour le renouvellement. Maintenant, je me pose des questions pour l'automatisation du certificat. Si je comprends bien le tuto, il faut créer deux taches : Une pour la création du conteneur : point 2.C Une pour le renouvellement du certificat : point 2.D Mais à quelle fréquence faut-il les déclencher dans le planificateur ? Tous les jours, tous les mois ? En tout cas, merci pour le boulot !