.Shad.

@oracle7 Normalement ça devrait marcher, moi j'ai : - WATCHTOWER_SCHEDULE=0 0 5 * * 6 et ça fonctionne correctement (tous les dimanche matin à 5h). Est-ce que tu as un message d'erreur quelconque ? Est-ce que la mise à jour n'est pas apparue entre le dernier scan et maintenant ? Tu peux ajouter la variable d'environnement : - WATCHTOWER_DEBUG=true pour essayer d'identifier l'origine du problème. @Lelolo : Yep, très pratique ! 😉

Il met à jour suivant ceci : Qu'as-tu utilisé comme méthode ?

Il existe un paquet Synology, mais tu es dépendant du bon vouloir des développeurs concernant la fréquence des mises à jour. Tu peux passer par la virtualisation ou la conteneurisation pour déployer ce genre de logiciel.

monitoring_influxdb c'est bien le nom du conteneur ?

Est-ce que tu t'y es repris à plusieurs fois ? Si oui, tu peux essayer de vider le cache de ton navigateur ou tester un autre, outre les problèmes de mauvais login/mdp que je mets de côté d'après tes dires, ça peut être un problème de cache de tentatives antérieures.

Salut @Kramlech Si tu laisses InfluxDB créer la base de données, la durée par défaut de la politique de rétention des données est de 0s, donc infinie. Et la durée des "shard groups" est de 7j (168h). Donc en l'état, tu gardes tes données infiniment, sous forme de paquets de 7 jours de données. En l'état pour info, pour en moyenne 9 mois de monitoring de 5 périphériques, j'ai au total 3 Go de données. Sur un NAS ce n'est pas spécialement gênant, mais si on cherche à optimiser l'espace, ça peut effectivement être gênant ! (sur un VPS par exemple) Dans ce cas-là, il y a plusieurs possibilités : - Si la base de données existe, il faut se connecter au conteneur InfluxDB puis à Influx, et effectuer une requête pour modifier la politique de rétention des données : https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#modify-retention-policies-with-alter-retention-policy - Si on crée une nouvelle base de données, tu peux suivre ce qui est indiqué ici : https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#create-retention-policies-with-create-retention-policy

Mettre un NAS au milieu de tout ça n'a aucun intérêt selon moi. En gros il ne servirait qu'à partager l'exécutable d'installation du logiciel de prise de contrôle ? Pour ça tu peux déjà créer un partage public sans mot de passe du dit fichier depuis DSM ou File Station. Et comme l'ont dit mes prédécesseurs, autant partir sur une solution TeamViewer, VNC, ou le bureau distant de Windows (ou toute autre solution existante). Pour le boulot, je me connecte au VPN de la boîte, puis j'utilise le bureau distant sur mon PC via son IP, ça marche très bien.

Ben si tu les enlèves ils sont toujours là, c'est juste qu'ils ne sont plus accessibles par un périphérique extérieur qui interrogerait le NAS. Mais Telegraf peut parfaitement communiquer avec InfluxDB et Grafana sans translater les ports, ils sont dans le même réseau bridge personnalisé.

@MilesTEG1 Il faut essayer autant que possible de n'exposer que les ports qui ont une utilité. Sauf utilisation extérieure des données de Telegraf, et que Telegraf n'exporterait pas celles-ci mais qu'un autre programme viendrait les importer, les ports n'ont pas besoin d'être translatés (il y a une note à ce sujet après chaque docker-compose.yml dans le tutoriel). Le seul port que tu as besoin d'exposer c'est celui de Grafana, a priori tout le reste est superflu dans ton cas.

Bienvenue !

Ou alors je n'ai pas trouvé comment faire. En outre je ne sais plus aller consulter mon profil.

Et impossible d'éditer ses propres messages.

Toujours pas trouvé comment on accède à ses messages privés. Soit ce n'est pas faisable, soir je suis complètement aveugle.

Est-ce que tu avais bien mis une validité infinie à la création de l'API ? Il se pourrait que la validé ait expiré et que du coup l'authentification ne fonctionne pas car les credentials n'existent plus. Il faut vérifier dans l'API d'OVH.

Bienvenue parmi nous !

En réalité, il faut bien différencier ce que fait : user: "x:y" et ce que font les variables PUID, PGID. Dans le premier cas, ça revient à chown dans le conteneur de ce qu'on met dans "volumes:" Donc les fichiers et dossiers auront pour utilisateur x et groupe y. Ca peut parfois mener à des problèmes de fonctionnement. PUID et PGID, variables généralisées sur les images Linuxserver, mais on trouve l'équivalent sur bien d'autres images, fait correspondre l'utilisateur dans le conteneur, souvent "abc" dans les images de LS, avec l'utilisateur dont on précise les uid/gid. C'est beaucoup plus subtil et n'impacte pas le fonctionnement du conteneur.

Toutes ces variables sont des variables créées par le conteneur nécessaire pour son fonctionnement. La liste des variables qui représentent un intérêt pour l'utilisateur : https://hub.docker.com/r/linuxserver/calibre-web Quand tu ne précises rien, le conteneur est créé en mode bridge, c'est lié aux réglages par défaut du démon dockerd (et c'est l'utilisation qu'on désire habituellement). Exactement.

Et bien j'imagine la même utilité qu'ailleurs pour le PATH, mais pour tous les binaires situés à l'intérieur du conteneur. HOME c'est assez clair ^^ TERM j'imagine que ça a un rapport avec le terminal, mais comme ça... je ne sais pas.

A partir du moment où tu as exécuté acme.sh une fois et déployé dans la foulée, le fichier ndd.tld.conf comprend d'une part les variables SAVED_SYNO et d'autre part l'option Le_DeployHook avec l'appel au plugin synology_dsm.sh qui déclenche le déploiement automatiquement après le renouvellement du certificat. Sans possibilité de l'empêcher. Supposons que je souhaite déployer le script sur 2 instances de DSM, la première fois que je vais exécuter le script, il n'y aura pas de fichier ndd.tld.conf, donc il va faire un issue, puis un renew, puis un deploy_1 et un deploy_2. 60j après, lors du premier renouvellement de certificat, au moment du renew, il va directement déployer dans la foulée. Si j'ai laissé les variables SAVED_SYNO dans le fichier .conf, il va déployer sur le NAS2, puis viendra le déploiement sur NAS1, puis re-NAS2. Avec le même script j'ai donc un comportement différent suivant qu'un certificat antérieurement ou pas. En supprimant également la ligne Le_DeployHook, je m'assure qu'il reproduise à chaque exécution le même script : issue -> renew -> deploy_1 ->deploy_2 En supprimant les variables SAVED_SYNO, je suis sûr et certain de l'ordre dans lequel les certificats vont se déployer. Si des variables SAVED_SYNO existent déjà dans le fichier ndd.tld.conf, acme.sh --deploy ne les écrasera pas, même si on en spécifie d'autres avant le déploiement.

Ces variables sont créées par l'image lors du déploiement du conteneur. Oui tout se fait par l'interface d'administration par après.

De rien 🙂

Salut @oracle7 Merci de ton retour, alors pour la première remarque tu as vu juste, elle est obligatoire après chaque déploiement pour supprimer notamment le "cache" des variables SYNO_XXXX qui peut mener à des erreurs, surtout si on déploie sur plusieurs NAS. Ok pour le DID, je l'ai ajouté et je vais préciser ceci dans le tutoriel en pointant vers le tien. Pour les variables à récupérer, ok pour récupérer le CERT_DIR (renommé CERT_HOME pour une question de cohérence avec la variable dans le fichier account.conf). Pour le fichier .conf du certificat, je n'ai rien à y récupérer (acme.sh oui mais ça c'est son problème), je dois même justement enlever des variables (Le_DeployHook et les SAVED_SYNO en l'occurrence). Pour la commande cp -p, bonne remarque merci c'est ajouté. 🙂 PS : Idéalement j'aurais souhaité utiliser la commande getopts pour passer les variables de personnalisation dans la commande du script, j'en ai compris les grands traits mais pas réussi à la mettre en application pour le moment, si tu as un point de vue je suis tout ouïe. 😉

Les permissions pour Photo Station se gèrent dans Photo Station, c'est moche je suis d'accord mais c'est comme ça. 😞

Ca ne peut pas fonctionner car tu fais correspondre le port 32785 (tu as sûrement laissé en "auto") du NAS avec le port 8083 du conteneur, en gros il te faut : et toi tu fais : Pour l'accès à la DB, il faudrait voir ce que tu as monté comme volume, quel est l'équivalent chez toi de l'image de @quart-temps ?

Bienvenue !