.Shad.

La politique de Synology tend à abandonner la maintenance de paquets tiers au sein de son magasin (c'est dommageable pour les modèles non compatibles Docker, et pour les utilisateurs qui n'ont pas l'envie ni le temps de s'y intéresser). Donc à ta place je veillerais à tout basculer sur Docker dès maintenant avant migration, ça t'évitera des désagréments futurs probables. Ne pas migrer tant que tu n'as pas réussi à reproduire le comportement voulu de tes applications via Docker.

Si tu peux contextualiser un peu plus s'il-te-plaît. Je comprends que tu as une installation fonctionnelle de Domoticz (si j'en crois tes derniers messages), quelle image utilises-tu ? celle de Linuxserver ?

@oracle7 @MilesTEG1 J'ai ajouté cette variable dans mon conteneur InfluxDB depuis quelques temps : INFLUXDB_META_RETENTION_AUTOCREATE=false Ca ne permet de ne plus créer automatiquement la politique de rétention "autogen" (durée de 1 an, shards de 1 semaine). A la place je crée manuellement mes politiques de rétention pour chaque base de données InfluxDB, par exemple : CREATE RETENTION POLICY "2w" ON "nas_telegraf" DURATION 2w REPLICATION 1 DEFAULT Ici c'est deux semaines, pour deux jours c'est "2d", etc... Plus d'info ici pour la manipulation des politiques de rétention des données : https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#create-retention-policies-with-create-retention-policy Je garde deux semaines pour les périphériques, et deux jours pour les speedtests, qui sont effectivement sur des instances InfluxDB séparées.

Salut, Pas que je sache en tout cas.

En ramenant la politique de rétention à une durée de 2 semaines pour les périphériques, et 2 jours pour le speedtest, je suis passé à 1 Go de mémoire pour InfluxDB, ce qui est beaucoup² plus raisonnable. Ca n'explique pas les envois multiples de pfSense, que je vais réactiver pour vérifier s'il influe beaucoup (c'est lui qui remonte le plus de données je pense). Normalement Telegraf stock les données dans une mémoire tampon le temps qu'InfluxDB soit prêt à les recevoir. Il ne fait pas d'envois successifs. Après Telegraf tourne en tant que paquet tiers sur pfSense, et ce n'est pas mis à jour tous les quatre matins, peut-être que l'implémentation n'est pas optimale... A suivre 🙂

Je suis d'accord avec toi, jusqu'à peu encore je pensais comme toi. DSM 7 a apporté une amélioration sur ce point, c'est beaucoup plus clair.

Pourquoi faire du HTTPS -> HTTPS ? d'autant que là tu restes sur la même machine. Au final ça fonctionne ou pas ?

Bienvenue parmi nous !

Une impression d'écran de tes entrées de proxy inversé (les 3 stp).

Pour de l'IPv4 en WAN, les enregistrements nas1, nas2, etc... n'ont pas d'utilité, tout est derrière une même IP publique. C'est en effet les adresses pour les services qui doivent y être si tu souhaites un accès externe.

Tu en vois d'autres qui ont 3 NAS dans le coin 😄 Oui c'est toi, désolé j'aurais dû te citer. 😉

Non car son serveur de nom est son routeur, le wildcard doit pointer sur le proxy inversé, donc le NAS. @GrOoT64 Mais c'est le même problème que d'habitude avec ce tutoriel, tu confonds périphérique et service. Là tu définis le nom pour les périphériques. nas1.ndd.tld ce n'est pas DSM, c'est le NAS lui-même. Si tu veux que ça marche tu crées des entrées dsm-nas1, dsm-nas2 et dsm-nas3, qui pointent toutes vers nas1.ndd.tld (en laissant tes entrées nas1, nas2 et nas3 existantes). Ensuite dans ton proxy inversé tu transformes tes entrées nas1.ndd.tld en dsm-nas1.ndd.tld, nas2.ndd.tld en dsm-nas2.ndd.tld, etc... Et tu verras que ça marche. EDIT : Je pense que je vais créer un petit tutoriel / memento pour expliquer le système DNS dans les grandes lignes, ce sont toujours les mêmes questions qui reviennent (gros manque du tutoriel).

C'était effectivement possible mais la manière dont c'était rédigé ne le laissait pas facilement présager.

Si tu peux mettre une copie d'écran de ta zone DNS sans cacher les IP locales (pour la compréhension). Ainsi que celles de tes entrées de proxy inversé.

Si tu as un Raspberry tu l'installes aussi dessus. Moi j'ai deux Pi-hole pour justement éviter la perte de résolution lors du redémarrage de l'un ou l'autre des périphériques.

Donc c'est un problème lié à ton navigateur. Essaie de faire Shift+F5 quand ça plante avec Firefox. EDIT : Il faut uniquement envoyer l'IP de Adguard, sinon ça peut passer par le secondaire, et forcément ça ne fonctionne plus.

Normalement rien de spécial. Tu peux toujours exporter ton conteneur avant de mettre à jour. Si tu as créé une interface virtuelle pour réseau macvlan il faudra relancer le script après la maj, c'est tout.

Si tu as un disque dur en rab quelque part, tu peux essayer de remplacer le disque et voir si tu arrives à commencer la procédure d'installation de DSM. Ça permettra de voir si c'est le NAS ou le disque qui pose problème.

Quand tu rencontres le problème, fais un nslookup pour vérifier quel serveur répond.

Explique nous pourquoi déjà tu utilises 3 proxy inversés en premier lieu.

Ca pourrait être bien que tu commences par te présenter dans la section prévue à cet effet. Tu ne donnes ni ton matériel ni ta version de DSM, ni ton niveau. Du coup difficile d'orienter et calibrer nos réponses. Visiblement il n'existe pas de paquet maintenu correctement pour ton application. Il faut dans ce cas-là passer par une VM ou par Docker, et leur disponibilité dépend de ton modèle de NAS.

Bienvenue et courage 🙂

C'est bien pour un NAS sur DSM 5 ou moins ? Difficile à dire comme ça, surtout si tu as déjà épluché tous les logs. Que dit /var/log/messages à l'heure où le deuxième mail te parvient ?

A moins d'un package personnalisé je ne pense pas. Il existe ceci en revanche : OpenWRT n'est pas flashable sur les routeurs Syno. Liste de matériels compatibles : https://openwrt.org/toh/start?dataflt[Brand*~]=

C'est étrange car ça devrait fonctionner. Est-ce que tu peux taper ceci en SSH et en poster le résultat : docker network inspect bridge Pense à ajouter sudo devant si tu n'es pas connecté via l'utilisateur root. Et vérifier dans le pare-feu de ton NAS que tu autorises les IP 172.16.0.0/12 (mais je doute que ce soit ça car si c'était interdit, même avec l'IP locale ça ne passerait pas). A la place de l'IP locale tu peux aussi utiliser le nom NetBIOS normalement, moins de chance que le nom change contrairement à l'IP (changement de box, réorganisation du réseau, etc... pas sûr que tu penses à màj le script... c'est l'avantage de l'IP passerelle qui ne change jamais).