-
Compteur de contenus
6673 -
Inscription
-
Dernière visite
-
Jours gagnés
154
Tout ce qui a été posté par .Shad.
-
[Résolu][Réglé] Récupérer des fichiers présents dans Download Station, mais disparus de File Station
.Shad. a répondu à un(e) sujet de Honu2070 dans Download Station
Il doit falloir regarder du côté des fichiers cachés via SSH. -
@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 !
-
SYNOFOX : Nouvelle Extension Pour FIREFOX
.Shad. a répondu à un(e) sujet de Synofox dans Download Station
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 !
- 1449 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
C'est root:docker et pas l'inverse.
- 1449 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
@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 ?
- 1449 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Tutoriel mis à jour avec les constatations des dernières pages.
- 1449 réponses
-
2
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
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.
- 1449 réponses
-
2
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
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.
- 937 réponses
-
- letsencrypt
- certificat
-
(et 1 en plus)
Étiqueté avec :
-
@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.
- 937 réponses
-
- letsencrypt
- certificat
-
(et 1 en plus)
Étiqueté avec :
-
Ç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.
-
@oracle7 Attention que par défaut, le trafic DNS (port 53) n'est pas chiffré, c'est aussi le cas de DNS-over-HTTPS, sauf que le trafic étant noyé dans le flux sur le 443, il est quasi impossible de l'analyser, d'où le fait qu'on considère ce protocole "sécurisé", contrairement à DNS-over-TLS, où là c'est usuellement le port 853 qui est utilisé, et où le trafic est effectivement chiffré. A ma connaissance, DNS Server (sur DSM) ne permet ni DoT ni DoH.
-
@molinadiaz Ton routeur Paris n'a pas à utiliser l'IP publique de ton NAS à Paris, il peut utiliser son IP privée directement, pourquoi passer en résolution publique ? Ce que DNS Serveur Paris ne saura résoudre, il le transfèrera aux redirecteurs (a priori tout sauf ce qui a été mis en cache et ce qui concerne ton nom de domaine, vu que tu fais autorité pour répondre). Et en deuxième DNS, l'IP publique de celui à Madrid. A Madrid tu peux faire l'inverse par exemple. Quelle zone est esclave de l'autre ? Est-ce que la modification de la zone maître entraine bien la mise à jour de la zone esclave ? EDIT : Je trouve ça non intuitif d'utiliser ta propre IP publique pour la résolution DNS de ton routeur. Une partie des problèmes pourrait venir de ce point.
-
Hormis sur certains périphériques (sur certains modèles Android par exemple, où Google force ses DNS par-dessus ceux reçus par DHCP sur un réseau wifi), les DNS envoyés par le serveur DHCP seront ceux utilisés par le périphérique, point. Donc pour les clients c'est bon, pour le routeur lui-même si tu laisses l'IP du modem dans ses serveurs DNS, oui il utilisera les DNS de ton FAI car il hérite de la résolution DNS de ton modem. Si tu en spécifies d'autres il en utilisera d'autres, tout simplement.