.Shad.

Pour moi ça marche, j'évite les wildcard quand je peux (préférence personnelle) mais c'est tout aussi fonctionnel.

Comme quoi la publicité a bien fonctionné sur toi. 😄

Oui c'est possible. Mais avant de restaurer attend d'avoir un contact avec le support, c'est peut-être tout simple à réparer. 😉

Non j'ai bien la liste de toutes les applications dans ce cadre. Essaie peut-être de réinstaller certaines des applications qui devraient y figurer, voir si ça résout le problème.

Quel est l'intérêt de faire ça pour Orange ? j'ai du mal à comprendre.

@oracle7 Il n'y a aucune redondance dans la configuration de sa zone. Il essayait simplement d'atteindre DSM via le domaine qu'il avait attribué à son NAS, or les deux doivent être bien distincts. La seule différence entre ce que tu proposes et ce qu'il a c'est que tu utilises un enregistrement wildcard.

Aïe aïe aïe, Microsoft et LEUR protocole SMB, qui est mieux implémenté sur Linux que sur Windows. 😄 Je n'ai pas de solution magique à te proposer, mais les sujets traitant de problème de montage CIFS font florès sur le forum... Je ne pense pas que ce soit lié à DSM 7, même si c'est survenu lors de la màj du NAS. Essaie peut-être d'accéder au NAS en SMB via son IP par exemple au lieu de son nom NetBIOS.

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.

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

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.