.Shad.

Si tu ne prévois pas d'autre utilisation pour ton NAS que du stockage et de la synchronisation, je ne vois pas de raison de t'orienter nécessairement vers un modèle "+". C'est surtout aux primo-acquérants que je conseille d'envisager un modèle "+" car on peut vite se rendre compte de toutes les possibilités qu'offrent ces petites bêtes et on se retrouve avec un modèle bridé sur les bras. Dans ton cas, tu as eu le temps visiblement d'évaluer tes besoins, donc un DS420 me semblerait tout à fait approprié (en revanche si tu trouves un DS918+ au même prix, à titre personnel je le choisirais, c'est une machine formidablement bien dimensionnée). C'est vrai que 2 baies on est vite limité si les besoins enflent. Un 4 baies permet également d'avoir de la continuité de service (RAID-1 ou SHR) à moindre coût en terme de stockage (50% perdus sur un 2 baies, 25% sur un 4 baies).

Moi qui étais un fervent client de LDLC, je dois reconnaître que leurs prix sont incompréhensiblement hauts, sur la quasi totalité de leur assortiment. Si encore ils pratiquaient une vraie politique de promotion, mais c'est généralement autour de 5-10% plus que 20-25%.

Essaie de lister ce que tu trouves dans @download : ls -l /volume1/@download

Il doit falloir regarder du côté des fichiers cachés via SSH.

Bienvenue parmi nous !

@CyberFr Meuh non, vous n'avez plus de rouge dans les logs, ça vaut tout l'or du monde. 🤪

Oui dans le fichier ovpn exporté se trouvent le ca et le ca-bundle. OpenVPN râle parce qu'il n'a pas de certificat extérieur, mais la connexion est tout aussi sécurisée ainsi.

Est-ce que les deux premiers ne nécessitent pas des disques Synology pour éviter les avertissements d'incompatibilité sur DSM 7 ?

Bienvenue parmi nous !

Bienvenue et à bientôt au détour d'un sujet !

Si tu as un modèle de NAS "+" tu peux installer vDSM 7 via Virtual Machine Manager et faire tous les tests dont tu as besoin.

Oui, mais quand tu le lis en SSH c'est utilisateur:groupe, d'où le fait que je te reprenais. Ca me semble tout à fait sain !

C'est root:docker et pas l'inverse.

@oracle7 Bien vu pour les paramètres de l'input docker, je corrigerai ça, j'ai fait la modification sur certaines de mes instances mais pas toutes (pas urgent vu que c'est rétro-compatible). Concernant le socket, je ne suis pas chez moi pour vérifier les permissions d'origine, mais ça doit être 660 en root:docker de souvenir. Une fois le fichier chmodé, je relancerais le paquet Docker à ta place. Si ton utilisateur telegraf appartient au groupe docker, aucune raison que ça ne fonctionne pas en 660. Je ne me rappelle plus, c'est la même instance telegraf qui reprend le monitoring de ton réseau et de ta Freebox ou tu as deux conteneurs distincts ?

Tutoriel mis à jour avec les constatations des dernières pages.

Pour Telegraf, le changement vient de là, c'est bien ce que je soupçonnais, ce n'est plus root qui exécute le conteneur : https://www.influxdata.com/blog/docker-run-telegraf-as-non-root/ Du coup j'ai corrigé ça assez facilement : - je crée un utilisateur telegraf qui n'a d'accès qu'au dossier partagé docker. - je l'ajoute au groupe docker. - je note les id de mon nouvel utilisateur et du groupe docker, par exemple chez moi c'est 1040/65536. - je fais en sorte que ce soit ce combo là qui exécute le conteneur telegraf : version: '2.1' services: [...] telegraf: image: ... [...] user: 1040:65536 [...] - je recrée le conteneur docker.sock appartenant au groupe docker, je n'ai aucun mal à accéder au fichier. Je ferai une màj du tutoriel demain sûrement.

En Docker ou pas ça ne change rien à ce que fait acme. 😉 Si vous êtes plusieurs à avoir le même problème à la même période ça pourrait être indépendant de vous.

@Kiki91800 Est-ce que tu as le même problème qu'ici ? De mon côté, j'ai un renouvellement automatique d'acme le 17/11 pour mon VPS, pour mon serveur local j'utilise Certbot plutôt qu'acme donc difficile de comparer. Du coup le 17/11 si ça se renouvelle pas non plus pour moi c'est que le problème est chez acme ou OVH. Question, est-ce que tu as essayé de mettre à jour acme ? ça se fait avec l'argument --upgrade.

Ici :

Ça ne me semble pas choquant, c'est quand même beaucoup de stockage. Tu as bien utilisé le réglage permettant d'attribuer plus de ressources à la reconstruction ?

La DMZ ne concerne que le sens entrant, en sortant ça n'a aucune influence.

Si tes nameservers tombent, ce n'est pas juste ton NAS qui n'est plus accessible, mais l'entièreté de tes domaines. Tu utiliserais des logiciels différents j'aurais dit ok. Mais là un bug dans DNS Server et c'est tout ton domaine qui est en échec aux yeux du net. D'où l'intérêt selon moi de prévoir un serveur de nom délocalisé. Tu auras dans ces conditions une vraie redondance (hésite pas à regarder les recommandations de la RFC 2182). Enfin comme l'a dit @PiwiLAbruti, oui, ton trafic passe forcément par ton FAI, ils peuvent donc voir les paquets qui transitent depuis ton IP. Reste que comme il l'a dit aussi, il faut une sacrée bonne raison pour qu'ils s'intéressent à toi en particulier. Ce qu'on cherche généralement à éviter c'est le blocage DNS éventuel du FAI (faut pas croire non plus qu'ils te bloquent l'accès à plein de choses hein, c'est pas spécialement dans leur intérêt, c'est plus souvent lié à des décisions de justice (PirateBay par exepare)). A partir du moment où ton routeur utilise des DNS autres que ceux du FAI, et ton DHCP aussi, l'éventuel filtrage DNS effectué par le FAI ne sera plus d'actualité.

@molinadiaz Je parle pas de ton réseau, mais de l'accès du monde extérieur à ton nom de domaine. Si plus de serveur de nom actif, tu accèdes comment à chez toi depuis l'extérieur ?

@molinadiaz Oui, si problème avec DSM ou DNS Server, comment tu fais pour tes noms de domaine ?

Imagine un problème avec DNS Server, ça touchera aussi bien ton NAS à Paris qu'à Madrid. Et ton domaine ne pourra plus être résolu publiquement, sauf pour les endroits où le cache sera encore actif. Avoir un serveur de nom délocalisé chez un hébergeur type Cloudflare, Hurricane Electric ou d'autres permet une vraie redondance. Pour ce genre de choses c'est la commande tcpdump qu'il faut utiliser, ou Wireshark via Docker en mode host. C'est de l'analyse de trames qui te donne ces informations, il n'y a pas de logs pour ce type de requêtes.