.Shad.

Alors avec la version 2.0 ça marche toujours. Quid du chiffrage pour une instance distante avec l'agent ?

Beau boulot :

Outre le port 80, le gros avantage : tu installes une nouvelle application sur ton NAS, tu mets en place un proxy inversé. Et là problème, tu veux par exemple créer nextcloud.ndd.tld, mais il ne fait évidemment pas partie des sous-domaines pour lesquels ton certificat est valide. Du coup tu dois recréer un certificat en ajoutant ce domaine. Avec un wildcard tous les noms possibles sont déjà validés. Tu n'as rien à faire. Gros gain de temps si tu crées souvent des nouveaux sous-domaines, et beaucoup plus facile dans tous les cas.

Pareillement.

Moi je ferais un truc du genre à ta place : /volume1/docker/MIBs/:/usr/share/snmp/mibs/hiks:ro Le defaut path pour la recherche de MIBs reste le même, si ça marche pas jette un oeil à ça (fin du post) : https://ma.ttias.be/autoloading-mib-files-in-client-snmp-configuration-on-linux/ Pas le temps de répondre à la suite pour l'instant. 😉

Watchtower scanne tous les réseaux, qu'ils soient avec le driver bridge par défaut, créé par l'utilisateur ou macvlan. Est-ce que le label a été correctement entré dans les conteneurs que tu souhaites superviser et est-ce que tu as recréé les conteneurs suite à cela ? EDIT : Je n'avais pas vu que @Jeff777 t'avait déjà fait la suggestion. 😉 Pour le problème d'envoi de mail, si tu as un nom de domaine chez OVH essaie de voir si tu as la même erreur avec leur serveur SMTP.

Tu peux passer sur portainer-ce sans souci. Je l'ai fait il y a juste l'intégration de Kubernetes en plus. La partie qui nous intéresse a bénéficié également de quelques correctifs d'après le patch note.

@Jeff777 Tu peux la voir ici dans Grafana : Pour les notifications, Ouroboros se base sur : https://github.com/caronc/apprise (source : https://github.com/pyouroboros/ouroboros/wiki/Notifications) A la limite je te conseille d'expérimenter quelques temps puis de passer sur https://hub.docker.com/r/containrrr/watchtower, je mettrai peut-être mon tutoriel à jour pour Watchtower au lieu d'Ouroboros. Mais je sais que @EVOTk en a déjà fait un sur un autre forum, voir si je ne mettrais pas directement le lien. 😉 @oracle7 Je pense que tu essaies d'utiliser un port SSL au lieu de TLS, or SSL n'est pas pris en charge par Watchtower. J'utilise personnellement le port 587 du serveur SMTP d'OVH. Concernant le message des credentials, ce ne sont pas des erreurs mais juste des informations. Pour moi c'est juste qu'il n'a trouvé aucun dépôt privé hébergeant cette image dans le fichier config.json, et donc il passe sur le hub Docker après. Tu peux toujours demander sur le github de Watchtower.

Ca implique à première vue d'utiliser la fonction de lien qui est dépréciée, au profit des réseaux bridge créés par l'utilisateur justement. Si tu essaies d'utiliser l'IP du conteneur InfluxDB à la place du nom de conteneur, est-ce que tu as toujours l'erreur ?

@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.