.Shad.

Alors j'ai eu exactement le problème donc c'est pour ça que j'ai dit que j'avais compris. 😛

2ème screen, ce n'est pas remote, mais local qu'il faut choisir.

Tu peux faire un screen de la première proposition que tu as après avoir eu changer ton mot de passe ? Le fameux écran que tu as avec Endpoint URL ? Je crois que j'ai compris.

Ok pour s'assurer que le problème ne vient pas du/des volume(s), je te conseillerais de ne pas mettre de volume pour /data, il ira créer ça par lui-même dans un dossier obscur. Tu montes par contre le docker.sock via /var/run/docker.sock:/var/run/docker.sock Pour le reste tu ne touches pas.

Et pour le volume que tu n'utilises pas, t'es sûr de ton coup ? voir l'edit de mon précédent message.

Difficile à dire, je n'ai pas poussé plus loin l'utilisation de LibreNMS, car je trouve l'exécution assez lente. Disons que quand j'ai ajouté mon raspberry à LibreNMS, je me suis retrouvé avec tout un tas d'infos, qui m'intéressaient, mais quand j'ai voulu avoir d'autres infos ou customiser un peu j'ai galéré, mais c'est à 99% certain que le problème se situait entre ma chaise et mon clavier. 😉 Grafana plus simple à mettre en place ? Je ne crois pas, mais par contre je m'y retrouve mieux, même si je n'y connais rien en requête SQL je comprends la logique du langage et j'arrive à sortir 2-3 trucs. Le mieux c'est que tu testes les deux en fait, et que tu te fasses ta propre idée.

A quel niveau as-tu cette erreur ? dans les logs du container à son démarrage ? Parce que même s'il y avait un problème avec le docker.sock, tu aurais juste un souci pour sélectionner un endpoint dans Portainer, ça ne t'empêcherait pas d'accéder à la page, de te logger, et de te balader dans les menus... J'imagine que tu as vérifié que le port 9000 est accessible sur ton réseau local ? EDIT : Tu n'as pas une interférence entre ton volume portainer_data et les volumes que tu montes dans le service ? Essaie de commenter la définition du volume, ça devrait marcher si ton port 9000 est accessible avec ce que tu as écrit là.

De rien !

J'ai suivi ce tutoriel, il contient beaucoup d'infos et n'est pas spécialement complexe, par contre il demande pas mal d'adaptation aux dernières versions de DSM, mais dans les grandes lignes : Il faut : - Créer un réseau bridge - Il faut créer un container mariadb et le mettre dans le bridge - Générer l'app_key pour le container librenms - Créer le container librenms et le mettre dans le bridge - Lancer le tout et configurer librenms J'ai trouvé ça fastidieux, et je trouve le résultat moins probant qu'avec Grafana.

Oui pour jackett. Non pour ouroboros. Là tu utilises la variable LABELS_ONLY, donc par conséquent il ne se basera que sur ce critère pour mettre à jour les containers, MONITOR sera donc complètement ignoré. Ce que tu peux faire c'est avoir LABEL_ENABLE=true, ne pas utiliser LABELS_ONLY (donc false par définition), et laisser MONITOR, même si ça n'a pas beaucoup de sens à mon goût. Pour moi, les deux "bonnes" solutions sont : version: "2" services: ouroboros: image: pyouroboros/ouroboros container_name: ouroboros network_mode: bridge environment: - CLEANUP=true - SELF_UPDATE=true - LOG_LEVEL=debug - LABEL_ENABLE=true - LABELS_ONLY=true - CRON="0 * * * *" - TZ=Europe/Madrid labels: - "com.ouroboros.enable=true" volumes: - "/var/run/docker.sock:/var/run/docker.sock" restart: unless-stopped et t'assurer que les autres containers (jackett, influxdb, telegraf, grafana) ont bien le label "com.ouroboros.enable=true". Ou bien : version: "2" services: ouroboros: image: pyouroboros/ouroboros container_name: ouroboros network_mode: bridge environment: - CLEANUP=true - SELF_UPDATE=true - LOG_LEVEL=debug - CRON="0 * * * *" - TZ=Europe/Madrid - MONITOR="jackett influxdb grafana telegraf" labels: - "com.ouroboros.enable=true" volumes: - "/var/run/docker.sock:/var/run/docker.sock" restart: unless-stopped Pour le coup je me dis qu'ajouter le label à ouroboros lui-même ne doit pas être utile, car SELF_UPDATE va gérer l'auto màj. Ça peut être utile si un autre container ouroboros devait mettre à jour celui-ci, cas peu probable... 😛

Hello, Le wiki donne plus d'infos à ce sujet, à titre d'exemple : Donc les uns à la suite des autres. Avec le "-e" en lignes de commande, et dans environment comme tu dis dans le fichier docker-compose. Pour les labels, c'est à la création d'un container que ça s'ajoute oui, donc il faut recréer les containers qu'on souhaite mettre à jour si on veut utiliser cette méthode. Si tu n'utilises pas docker-compose ou que tes données ne sont pas persistantes ça peut être compliqué de tout refaire, dans ce cas-là autant passer par MONITOR ou IGNORE suivant le nombre. Pour ajouter un label, voir l'exemple de ligne de commande ou le fichier docker-compose joint.

Celle-ci : https://github.com/jarischaefer/docker-librenms

Oui c'est vrai, je trouve en revanche que ça offre beaucoup plus de possibilités.

Dans les faits, le container mssql utilise bien moins de mémoire qu'à mes premières versions. Je dépasse rarement 200 Mo de mémoire vive. Et puis l'idée de soutenir le projet Bitwarden me plaît assez, j'ai souscrit à l'offre premium et j'ai fait une organisation avec ma famille, honnêtement je ne pourrais plus m'en passer...

Plus simple mais je ne pense pas que l'image Docker soit souvent mise à jour... Je mettrai quelques détails ce soir, je suis dans le train là 😉

Si ton routeur a le protocole SNMP oui, c'est le cas de beaucoup. Et s'il l'a et qu'il est correctement configuré, alors LibreNMS le verra.

Pour la dernière mise à jour, la 1.31.1, il faut créer le dossier .../bwdata/logs/events sinon l'installation plante.

Bienvenue !

@seb_74 Moi je te dis de le cocher si tu te connectes en HTTPS (port 7001 et option HTTPS cochée) et de le décocher si tu te connectes en HTTP (port 7000, option HTTPS décochée). Au vu de ta réponse je ne suis pas sûr que ce soit ce que tu fais. 😉

WATCHTOWER 1. Préambule Le but de ce tutoriel est de mettre en place une application, containrrr/watchtower (Docker Hub, Github) qui va vérifier suivant un intervalle que vous définirez la présence d'une nouvelle version pour totalité ou partie de vos images Docker. C'est un fork de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près de deux ans. Ce tutoriel se basait historiquement sur l'image pyouroboros/ouroboros, qui n'est plus maintenue. NOTES : Les commentaires concernant watchtower (et pas ouroboros) commencent au milieu de la page 2. Avantages : - Plus besoin de vérifier via Docker Hub si une mise à jour est disponible - Processus entièrement automatisé - Ne consomme quasi aucune ressource Inconvénients : - Nécessite un accès à docker.sock, d'un point de vue sécurité ça peut être gênant pour certains - Suivant l'intervalle de vérification que vous définissez, la quantité de données échangée peut être importante, à surveiller si vous avez un quota - On ne peut l'installer par l'interface Docker de DSM (en fait si, mais c'est fastidieux). Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés dans les tutoriels de référence de ce forum vous ne devriez pas avoir de souci à vous faire. 2. Prérequis - Savoir se connecter en SSH (root) - Avoir Docker installé sur son NAS C'est parti ! On commence par se connecter en SSH avec l'utilisateur root (voir le tutoriel [TUTO] Accès SSH et ROOT via DSM 6). On télécharge l'image : docker pull containrrr/watchtower Il ne reste plus qu'à créer le conteneur, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose dans la documentation, et en particulier sur cette page. C3es paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur. 3. Configuration 3-A. Fréquence de mise à jour - INTERVAL : Définit un intervalle de mise à jour en secondes. Ex : WATCHTOWER_POLL_INTERVAL=300 - SCHEDULING : Le plus intéressant pour des particuliers je trouve, cron permet de définir une périodicité très personnalisable : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... la documentation de l'image renvoie vers ce site, mais je trouve ce générateur ou celui-ci très pratiques. L'image utilise un format CRON à 6 champs, contrairement aux liens ci-avant qui n'utilisent que 5 champs, en réalité, tous les champs sont décalés vers la droite pour proposer un réglage sur les secondes. Donc au lieu d'avoir : minutes | heures | jour du mois | mois | jour de la semaine vous avez secondes | minutes | heures | jour du mois | mois | jour de la semaine Ex : WATCHTOWER_SCHEDULE=0 0 5 * * 6 Cela correspond à une exécution hebdomadaire, tous les samedi matin à 5:00 Un conseil : Évitez d'utiliser 2:00 ou 3:00, à cause des changements d'heure 😉 Ces deux méthodes sont exclusives, c'est donc l'une ou l'autre. 3-B. Tri sélectif Par défaut, watchtower surveille tous les conteneurs. Mais on ne souhaite pas spécialement mettre à jour tous ses conteneurs automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden par exemple), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues de collectifs reconnus (Linuxserver, Bitnami, etc...). Plusieurs méthodes de tri sont proposées : - LABEL ENABLE : Permet d'utiliser les labels (des tags en quelque sorte) comme signes de distinction. Lorsqu'on crée un conteneur, on peut décider de lui ajouter un label, composé d'un intitulé et d'une valeur de type chaîne ou entier. Pour permettre à watchtower de mettre à jour un conteneur donné, il doit avoir parmi ses labels : com.centurylinklabs.watchtower.enable=true L' avantage énorme c'est que le nom du conteneur cible n'a pas d'importance, le fait qu'il n'existerait plus à un instant t n'a pas davantage d'incidence. Pour faire en sorte que la sélection des conteneurs à surveiller se fasse par label, il faut ajouter la variable suivante à la création du conteneur watchtower : WATCHTOWER_LABEL_ENABLE=true - FULL EXCLUDE (Ce n'est pas une variable d'environnement !!) : L'approche est exclusive au lieu d'être inclusive, elle se base sur le comportement par défaut de watchtower (surveillance de tous les conteneurs), mais il n'y a ici aucune variable d'environnement à préciser à la création du conteneur watchtower, en revanche les conteneurs que vous ne souhaiteriez pas surveiller doivent avoir le label suivant : com.centurylinklabs.watchtower.enable=false Notes : - Il n'est pas possible d'ajouter un label à un conteneur déjà existant. Il faut le recréer et insérer le label dans le script de création du conteneur. Si vous savez les recréer facilement (peu de paramètres à entrer, vos volumes sont persistants et les fichiers de configuration sont maintenus à la suppression du conteneur, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez la méthode FULL EXCLUDE. - La documentation est particulièrement claire à ce sujet. 3-C. Gestion des images - CLEANUP : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau conteneur a été créé. Cette fonctionnalité est désactivée par défaut. Ex : WATCHTOWER_CLEANUP=true - ROLLING RESTART : Par défaut, watchtower met à jour toutes les images avant de relancer les conteneurs, cette variable d'environnement permet de relancer les conteneurs au fur et à mesure, utilise si on souhaite réduire les périodes d'indisponibilités. Ex : WATCHTOWER_ROLLING_RESTART=true - WAIT UNTIL TIMEOUT : Par défaut, watchtower attend 10 secondes qu'un conteneur s'arrête une fois le signal d'extinction transmis. Certaines applications lourdes nécessitent plus de temps, cette variable permet d'ajuster ce délai. Ex : WATCHTOWER_TIMEOUT=30s Notes : - On notera la présence du "s" pour "seconde". - LINKED CONTAINERS : Certains conteneurs peuvent nécessiter que d'autres conteneurs soient opérationnels avant d'être créés, on prend souvent comme exemple le cas typique d'une application et d'une base de données. Afin d'éviter des erreurs, on souhaite que la base de données soit disponible avant l'application à la création, et inversement à la suppression. Ces relations existent par exemple lorsqu'on utilise l'argument --link en ligne de commande, ou avec l'instruction depends_on via docker-compose. On peut écraser ces réglages via le label : com.centurylinklabs.watchtower.depends-on tel que par exemple, si on applique ce label à un conteneur MariaDB : com.centurylinklabs.watchtower.depends-on=wordpress,caldav En cas de mise à jour disponible pour ce dernier, watchtower arrêtera au préalable les conteneurs wordpress et caldav. 3-D. Autres paramètres - DEBUG : Augmente le niveau de verbosité du stdout dans les logs du conteneur. Ex : WATCHTOWER_DEBUG=true - TRACE : Un debug encore plus verbeux, attention les credentials éventuels sont en clair ! Ex : WATCHTOWER_TRACE=true - TZ : Permet de définir le fuseau horaire, assure le lien entre la variable CRON si vous l'utilisez et votre fuseau horaire. La liste des timezone est disponible à cette adresse. Ex : TZ=Europe/Brussels Il y a encore énormément de fonctionnalités que je n'aborderai pas ici, citons parmi les plus notables : - les notifications => https://containrrr.dev/watchtower/notifications/ - La supervision de plusieurs instances Docker via un seul conteneur watchtower => https://containrrr.dev/watchtower/remote-hosts/ et https://containrrr.dev/watchtower/secure-connections/ (pour une connexion sécurisée (TLS), une lecture de https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ peut être instructive 😉) - la possibilité d'exécuter des scripts avant et après la mise à jour (par l'utilisation de labels) => https://containrrr.dev/watchtower/lifecycle-hooks/ - la possibilité d'utiliser d'autres dépôts que Docker Hub, ouvrant la voie à des dépôts privés => https://containrrr.dev/watchtower/private-registries/ Au final ce tutoriel se contente de traduire et de mettre en valeur les variables importantes, la documentation (je crois que je me répète 😛) est très complète. 4. Création du conteneur On a maintenant tous les outils en main, on va pouvoir créer notre conteneur. Pour se faire, plusieurs possibilités : 4-A. En lignes de commande (SSH) Voici un exemple de configuration : docker create --name=watchtower \ --hostname=watchtower-nas --restart=unless-stopped \ --label "com.centurylinklabs.watchtower.enable=true" \ -e WATCHTOWER_CLEANUP=true \ -e WATCHTOWER_DEBUG=true \ -e WATCHTOWER_LABEL_ENABLE=true\ -e WATCHTOWER_TIMEOUT=30s \ -e WATCHTOWER_SCHEDULE="0 0 5 * * 6"\ -e TZ=Europe/Brussels \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower Notes : - On est obligé de monter en volume le socket Docker au vu des opérations que doit pouvoir effectuer watchtower sur les autres conteneurs. - On peut tout à fait demander via le label de mise à jour que watchtower se mette lui-même à jour. Si tout a bien fonctionné, vous devriez avoir comme retour une suite de chiffres et de lettres (correspondant à l'ID du conteneur), il ne reste plus qu'à le démarrer : docker start watchtower 4-B. Par Docker-compose (SSH) Une autre personnalisation de l'image au format docker-compose : docker-compose.yml version: '2.1' services: watchtower: image: containrrr/watchtower container_name: watchtower hostname: watchtower-nas network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_SCHEDULE=0 0 5 * * 6 - TZ=Europe/Brussels env_file: - /volume1/docker/watchtower/watchtower.env labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock - /volume1/docker/watchtower/config.json:/root/.docker/config.json restart: unless-stopped Notes : - J'ai cette fois-ci ajouté les notifications par mail, mais on remarque qu'on ne retrouve pas les autres variables qui sont liées au relais SMTP (https://containrrr.dev/watchtower/notifications/#email). En réalité, pour des raisons de confidentialié, j'ai regroupé les variables qui sont plus "sensibles" dans un fichier .env qui est invoqué par : env_file: - /volume1/docker/watchtower/watchtower.env Fichier qui se présente sous la forme, et dont les permissions sont correctement réglées pour assurer le niveau de confidentialité désiré : WATCHTOWER_NOTIFICATION_EMAIL_FROM=... WATCHTOWER_NOTIFICATION_EMAIL_TO=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=... WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=... - J'ai monté le fichier config.json pour y ajouter des credentials pour des dépôts privés. Pour créer le conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape : docker-compose up -d 5. Configuration Ci-après un exemple de logs suite à un déclenchement programmé de Watchtower : 2020-11-14 05:01:31 (info): Found new grafana/grafana:latest image (sha256:68f75fcab5a9372fb0844f5898c65a40b0ca34cff4176e269bade17ddb17ee75) 2020-11-14 05:01:48 (info): Found new telegraf:latest image (sha256:146c415345a26f48f8ef06c2f62ebde90c8ca4ca518db5d88137e60eeb0abeec) 2020-11-14 05:01:59 (info): Found new authelia/authelia:latest image (sha256:d05b2f15beecd4c164a861e0464ddfef1d574b1c67f8e343779daec26c7bbde9) 2020-11-14 05:03:17 (info): Found new linuxserver/mariadb:latest image (sha256:f48f265a3ed8b786973e85c2c681f2f79db1b64d38660c43900bfc48651c6f83) 2020-11-14 05:03:19 (info): Stopping /grafana (bfdbba3a284d51c1a5c5c807f8583857a0c6a03718a083e93e5bcf9671f7130f) with SIGTERM 2020-11-14 05:03:21 (info): Stopping /telegraf (56e1c8624a98344cba07ca6f745c0cd8a93d66b36ebc0af8992cac210c8e0d51) with SIGTERM 2020-11-14 05:03:22 (info): Stopping /authelia (6d4202898398cf0b46886d38c6591a15b83334e00fe20a0025fcd4437747f84c) with SIGTERM 2020-11-14 05:03:23 (info): Stopping /mariadb (763aeebe73c029c20de2a15d114c054ba70b26879fdaf82b3019944179f31573) with SIGTERM 2020-11-14 05:03:27 (info): Creating /mariadb 2020-11-14 05:03:31 (info): Creating /authelia 2020-11-14 05:03:34 (info): Creating /telegraf 2020-11-14 05:03:40 (info): Creating /grafana 2020-11-14 05:03:42 (info): Removing image sha256:ec8e3ebf50429170fa6387bb04e64e5b5f3d87f3221c42750b7fb5d922c5e978 2020-11-14 05:03:43 (info): Removing image sha256:48121fbe19c845fa401be9fdbf3cbeef50840b7537d8a0b9ca2eab081117beb6 2020-11-14 05:03:43 (info): Removing image sha256:7606d5ee069fcab20036c4bd521e1133ac8ca31e44f7d241f0d83a36315d6ca6 2020-11-14 05:03:43 (info): Removing image sha256:900b03b57e41a8bf7f43b8979872bb2d6642d9a4bcb738d053fb67e1d989e926 MàJ : 10/04/2021

Ajout de la partie concernant le monitoring d'un raspberry.

Il y a toujours l'option d'installer Docker manuellement sur ton DS216se, mais le packagé n'étant "officiellement" pas compatible, Synology n'offrira pas de support pour cette application. Mais ça te permettrait de t'affranchir de toutes les limitations dues à la version de DSM d'un autre côté. Et comme le dit Zeus, le portail d'applications doit pouvoir fournir tout ce dont tu as besoin. Tu peux même depuis quelques mises à jour ajouter des en-têtes personnalisés pour chaque entrée.

Si tu y accèdes depuis ton smartphone en 4G c'est que nécessairement le port 5001 est redirigé. As-tu vérifié que la configuration du routeur n'est pas activée sur le NAS et qu'elle n'a pas automatiquement ouvert les portes dont elle estime avoir besoin ? Sur ta box, ça devrait être renseigné sous l'appellation uPnP pour peu que l'information ait été séparée des ports redirigés manuellement.

J'ai ajouté la partie pour monitorer docker. Tuto pour ajout du Raspberry en cours de rédaction...

Et tu as bien cliqué sur la roue crantée en bas à gauche, et coché Vérifier le certificat quand tu actives l'HTTPS ?