oracle7

@krillvoile Bonjour, Tu es sûr de ton coup là ? Car sauf erreur de ma part, en ouvrant le port 5000 tu donnes un accès direct à ton NAS. Pas terrible du point de vue sécurité du NAS ! As-tu essayé de réinitialiser ton décodeur TV ? Le service uPnP IGD est-il activé sur la LB (onglet réseau) ? Sinon je ne vois pas trop le rapport entre le replay et le protocole RSTP, tu peux éclairer ma lanterne ? Cordialement oracle7😉

Bonjour, @Pinpon_112 As-tu essayé d'exporter ton token entre guillemets càd : export INFOMANIAK_API_TOKEN="*************************token**********************" @Tex5 Bah NON, il faut justement mettre les guillemets. Regardes bien les commandes que j'ai indiqué dans le TUTO. @Stixen92 Peux-tu vérifier que : la variable d'environnement DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' est bien définie dans le fichier account.conf (/usr/local/share/acme.sh/account.conf). il n'y a pas (plus) dans ta zone DNS chez OVH d'enregistrements TXT du type " _acme-challenge.ndd.tld ". Si Oui supprimes le(s). Ils sont normalement créés et supprimés par acme.sh mais restent en cas d'erreurs. Cordialement oracle7😉

@aurelp Bonjour, Si ta box ne supporte pas le loopback alors la meilleure solution pour toi est d'installer une zone locale DNS (pas plus) avec le package DSN Server. Voir le TUTO DNS Server. Cordialement oracle7😉

@pepe49 Bonjour, A ma connaissance, le réseau 172.16.0.0 est le réseau utilisé par défaut par Docker mais il est aussi utilisé pour le VPN L2TP/IPsec. Il y a peut-être d'autres utilisations mais je ne les connais pas. Cela, certains l'utilisent pour leur réseau local en lieu et place du 192.168.x.x. L'@IP 172.16.0.1 est en générale l'@IP de la passerelle du réseau 172.16.0.0. Quand tu autorises le réseau 172.16.0.0/12 (CIDR 12 <==> masque de sous-réseau 255.240.0.0) dans ton pare-feu tu autorises implicitement 1048574 @IP (donc toute la plage correspondant au CIDR/masque de sous-réseau. Non absolouement pas, 192.168.0.0 ou 192.168.1.0 sont deux réseau locaux distincts. Tu choisis ce lui que tu veux mais attention à bien rester cohérent ensuite pour toutes tes @IP que tu attribueras à tes périphériques dans ton réseau lccal. NE FAIT PAS de mélanges, sinon cetains périphériques ne seront pas accessibles. Tu me suis ? Par contre, par rapport au TUTO tu peux modifier le masque de sous-réseau pour limiter le nombre d'@IP de la plage autorisée. Le masque 255.255.255.0 autorise 254 machines/@IP alors que le masque 255.255.0.0 en autorise 65534 ce qui m'étonnerait fort que tu en ais besoin d'autant sur ton réseau local, non ? Pas de soucis, c'est en quelque sorte le minimum à faire dans le pare-feu du NAS pour le sécuriser. Ensuite on est plus dans le fait d'ouvrir certains ports pour permettre le fonctionnement de certaines applications. Par exemple ouvrir/autoriser le port 1194 limité à la France (sauf si tu te connecte depuis l'étranger) pour faire du VPN avec OpenVPN. Donc à minima : Au final, je me permet de réitérer ce conseil : prends bien le temps de lire et assimiler les notions de réseau décrites dans le second lien que je t'ai fourni. Tout y est expliqué de façon simple et claire. Après cela tu seras plus à l'aise pour suivre le TUTP VPN Server ainsi que celui de sécurisation du NAS. Mais c'est toi qui vois ... Cordialement oracle7😉 oracle7

@.Shad. Bonjour, Oui, j'avais déjà bien mis les variables d'environnement pour les disk inputs. Au détail près du montage du volume /run/udev et des volumes de montages des MIBs, mon docker-compose est très proche du tien. D'ailleurs quelle est l'utilité de ce /run/udev ? Au passage, pour réinitialiser InfluxDB2 proprement, à part supprimer l'image et vider le contenu du dossier d'installation /volume1/docker/monitoring/influxdb2-data, y-a-t-il autre chose à nettoyer ailleurs ? J'ai perdu le dashbord fourni en standard avec influxDB2 et j'aimerai le retrouver. Je n'ai rien trouvé de vraiment semblable sur https://github.com/influxdata/community-templates . Cordialement oracle7😉

@pepe49 Bonjour, Désolé mais tu te mélanges encore les pinceaux 🤪. Pas grave 🤣, je t'explique. Dans le TUTO on te demande d'ouvrir/autoriser dans le pare-feu les @IP du réseau 10.0.0.0 qui a pour masque de réseau 255.0.0.0 et non pas toutes les @IP de 10.0.0.0 à 255.0.0.0. Voir ici pour la définition d'un adressage IPv4 et au passage voici un peu de lecture qui t'éclairera en matière de réseau et notament sur la notion de masque de sous-réseau. Donc si tu suis attentivement le TUTO, tu n'auras pas de problèmes pour configurer correctement ton serveur VPN. Le plus simple est d'utilser le protocole OpenVPN. Mais ce n'est que mon avis, c'est toi qui vois ... Pour ta seconde question, je n'ai pas de freebox donc je suis bien en peine pour te répondre. Je tague ici @Jeff777 qui je pense saura mieux te répondre que moi sur ce point. Cela dit, une recherche sur le forum te donnera aussi des éléments de réponse car il me semble bien que le sujet a déjà été évoqué. Cordialement oracle7😉

@.Shad. Bonjour, Pourrais-tu STP essayer de m'expliquer ce comportement (en espérant que je vais être clair dans sa description et que tu auras une réponse !) : Sous SSH, le répertoire /run/docker a les droits 0755 et le répertoire /run/docker/netns a les droits 0700 sachant que tous les deux sont root:root. J'accède sans problème au contenu de /run/docker/netfs. Dans le docker-compose de telegraf, je monte le volume " - /:/hostfs:ro " conformément à la doc de https://registry.hub.docker.com/_/telegraf pour monitorer le docker engine host. Maintenant, lorsque que je rentre dans le conteneur telegraf (docker exec -it telegraf bash), il m'est impossible d'accèder au répertoire /hostfs/run/docker/netns. Par ailleurs lors de l'exécution du conteneur telegraf, je récolte ce type d'erreur dans le log de telegraf, ce qui semble confirmer le point précédant et être l'origine de l'erreur : 2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Wrote batch of 119 metrics in 30.460364ms 2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5fdd4d03d1d4"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/a23d3dd3c162"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/597f58313571"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/cbb43ff4dc01"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5eeb93e81603"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/c2c97a718e7d"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/0984314f543e"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/b06ebc0f4f59"): permission denied Pour me sortir, de ce type d'erreur, je suis obligé d'activer la commande : mount_points = ["/"] dans [[inputs.disk]] dans le fichier telegraf.conf : #---------------------------------------------------------- ## Read metrics about disk usage by mount point [[inputs.disk]] ## Set mount_points will restrict the stats to only the specified mount points. mount_points = ["/"] ## Ignore mount points by filesystem type. ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"] Selon toi est-ce normal ? en SNMPV2c, il n'y avait pas besoin de cela. Pour mémoire je suis en SNMPv3. Je ne vois pas le lien et du coup je ne comprends pas et donc, saurais-tu STP éclairer ma lanterne ? D'avance Merci. Cordialement oracle7😉

@TuringFan Bonjour, Supprimer des clés API : Se connecter sur OVH ici : https://api.ovh.com/console/ (avec le compte -ovh, pas l'@eMail) Aller sur : https://api.ovh.com/console/#/me/api/application#GET et cliquer sur le bouton « execute » On obtient la liste des ID d’applications API déjà créées Dans https://api.ovh.com/console/#/me/api/application/%7BapplicationId%7D#GET saisir/coller l’ID dans le champ « applicationId » puis « execute » Pour supprimer l’application : aller dans : https://api.ovh.com/console/#/me/api/application/%7BapplicationId%7D#DELETE et saisir/coller l’ID dans le champ « applicationId » puis « execute ». Cordialement oracle7😉

@Romuald_ Bonjour, Vas lire ce post tu y trouveras les réponses à tes interrogations. Dans tous les cas : CMR impératif ! Cordialement oracle7😉

@pbai Bonjour, A tout hasard, regardes dans le TUTO Calibre-web via Docker en page 2, dans mon Edit 1 j'ai donné un fichier docker-compose.yml qui fonctionne. Cordialement oracle7😉

@pepe49 Bonjour, Je crains que tu ne te mélanges les pinceaux 🤪. En fait tes deux solutions que tu évoques, n'en sont qu'une (la 1 ci-après). En matière de VPN voici les deux solutions qui existent : Accéder à ton réseau local depuis internet à partir de périphériques externes au réseau (Extérieur --> NAS). Naviguer sur internet de façon "anonyme" (NAS --> Extérieur). Dans le premier cas VPN serveur de Synology est la solution. Il te permet depuis l'extérieur de connecter un périphérique a ton réseau local de façon sécurisé comme s'il était physiquement branché sur le réseau. Dans le second cas tu passes par un fournisseur externe (NordVPN, CyberGost, etc ...) qui te fournit un accès sécurisé (ou presque) à SON réseau et à une porte "anonyme" vers internet. Au final je comprends que c'est la 1ère solution qui t'intéresse. Il te faut donc installer sur ton NAS le package VPN Server et te connecter avec un client VPN adapté au protocole que tu retiendras (OpenVPN, Ip2sec, etc ...). Pour cela tu as un excellent TUTO VPN Server sur le présent site. En terme de protection/sécurisation du NAS je t'invite (si ce n'est déjà fait !) à suivre ce TUTO : Sécuriser les accès à son NAS avant d'installer VPN Server. Cordialement oracle7😉

@corrs78 Bonjour et Bienvenue à toi sur ce forum. Cordialement oracle7😉

@limannzerga Bonjour, Bienvenue à toi sur ce forum, tu as dû voir que c'est une mine d'informations. Cordialement oracle7😉

Bonjour, @.Shad., @MilesTEG1 Merci à tous les deux d'avoir complété mon information. Je ne connaissais pas cette astuce avec la liste de fichiers préconfigurés. Je dormirais moins "bête" ce soir 🤣. Je corrige de ce pas ma définition de reverse proxy pour Calibre-web. @pbai Désolé pour ma mausaise indication, tu peux donc supprimer la dernière ligne de l'entête reverse proxy pour Calibre-web. Cordialement oracle7😉

@MilesTEG1 Bonjour, Effectivement pour ma part j'ai fait que suivre la préconisation de @.Shad. dans son TUTO, ni plus ni moins. EDIT : Pour info, le nom de l'interface réseau "br_xxxxxx" que l'on donne à la création du réseau bridge personalisé, apparaît (entre autre) dans le moniteur de ressources de DSM dans l'onglet Réseau. Sinon, de mon coté j'ai regroupé : Acme et Portainer dans un réseau unique synology-network Gotify et Watchtower dans un réseau gotify-network puisque ces derniers communiquent ensembles (enfin surtout watchtower vers gotify !). Maintenant, sauf erreur de ma part, ce n'est pas parce que des conteneurs utilisent le docker.sock qu'ils doivent partager le même réseau, cela ne me parait pas utile voire pas nécessaire ou impératif mais je peux me tromper. Cordialement oracle7😉

@limannzerga Bonjour, Une chose est sûre, ton NAS ne peut être à la fois client et serveur VPN pour un même protocole (OpenVPN par exemple). Avec un VPN Tiers pour accéder à l'extérieur de façon "anonymisée", il y a de très fortes chances que le protocole OpenVPN soit utilisé par ce serveur VPN Tiers. Si tu veux en même temps accéder à ton NAS depuis l'extérieur avec une connexion VPN il te faut alors utiliser un autre protocole que OpenVPN, soit par exemple Ip2sec qui sera configuré sur le serveur VPN Synology de ton NAS et sur le client que tu utilises depuis l'extérieur. Cordialement oracle7😉

@.Shad. Bonjour, Comme tu le dis c'est le nom de l'interface créée et pas le nom du réseau. Donc manisfestement les noms de réseaux, eux, supportent sans problème plus de 15 car. Dans tous les cas voici ma source : https://gist.github.com/brthor/b035052bad98e0a2d7c0e925d2d86a2a Cordialement oracle7😉

@MilesTEG1 Bonjour, A quoi cela sert,très franchement je n'en sais rien (Nginx et moi .... 😪) je fait confiance à la doc ici : https://hub.docker.com/r/linuxserver/calibre-web Cordialement oracle7😉

@bliz Bonjour, Certes en apparence, @firlin pourrait le confirmer, sauf erreur de ma part (mais je peux me tromper) les outils tiers que tu évoques ne font pas tout à fait la même chose que badblocks. Il me semble bien que cela a déjà été évoqué dans les échanges du TUTO. Il faudrait prendre le temps de relire les 26 pages en question ...🥴 Mais je suis d'accord avec toi pour un neophyte ce n'est pas simple même si parfois il faut aussi prendre le taureau par les cornes et "mettre les mains dans le cambouis" avec nos chers joujous que sont les NAS. Mais ce n'est que mon avis ... Cordialement oracle7😉

@MilesTEG1 Bonjour, Je vais laisser notre gourou @.Shad. te répondre sur ce point précis qu'il maitrise mieux que moi 😜. Pour ma part je procède ainsi : Création du réseau via la commande adhoc. Dans chaque conteneur je désigne le réseau à utiliser networks:RéseauX:external: true. Pour chaque conteneur, j'affecte une @IPv4 et une @MAC pour pouvoir le cas échéant atteindre directement le conteneur (même si ce n'est pas toujours utile je te l'accorde). Idem quand plusieurs conteneurs sont sur un même réseau, mais alors je laisse la résolution DNS par nom faire son boulot pour qu'ils communiquent entre eux. Bon tout cela est mal dit mais c'est le principe. Cordialement oracle7😉

@limannzerga Bonjour, Sauf erreur de ma part, il me semble bien que cela aurait du être le cas puisque ton ndd pointe sur ton @IP externe réelle alors qu'elle a été remplacée par une autre @IP avec ta connexion VPN. Mais au final quel est ton besoin réel car un VPN peut être utilisé de deux manière : Accéder à ton réseau local depuis internet à partir de périphériques externes au réseau ? Naviguer sur internet de façon "anonyme" ? Dans le premier cas VPN serveur de Synology est la solution. Il te permet de connecter un périphérique a ton réseau local de façon sécurisé comme s'il était physiquement branché sur le réseau. Dans le second cas tu passes par un fournisseur externe qui te fournit un accès sécurisé (ou presque) à SON réseau et à une porte "anonyme" vers internet. Dans ce cas, il faudrait que ton serveur VPN accepte de rediriger ta requête entrante vers ton NAS (ce qui n’est généralement pas prévu dans les VPN commerciaux. Donc impossible d'atteindre ton NAS de puis l'extérieur. Enfin Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7😉

@pbai Bonjour, Déjà il te faut préciser le port 8083 dans ton URL soit : 192.168.1.xxx:8083. Si tu es sous FireFox, il arrive parfois effectivement qu'il te refuse l'accès quand tu valides l'URL (page Synology non trouvée). Dans ce cas, dans un autre onglet j'essaie une connexion au NAS avec un 192.168.1.xxx:5000 puis je reviens à l'onglet initial et je relance 192.168.1.xxx:8083 et là cela doit passé (ce n'est pas instantané !). Essaies aussi en configurant une règle de reverse proxy telle que : htttps ebooks.xxx.synology.me 443 vers http localhost 8083. Dans l'entête personnalisé tu saisis aussi ceci Ensuite dans ton navigateur tu tapes https://ebooks.xxx.synology.me. Cordialement oracle7😉

Bonjour, @bliz C'est pour cela que l'on profite que le NAS (DSM) est sous un Linux "adapté" pour lancer l'opération badblocks sur le NAS avec une connexion root sous SSH. Pas la peine de chercher plus loin ... Maintenant ce que j'en dit ... @cotp Normalement le service client d'amazon est assez arrangeant, contactes le (si bien sûr ton achat est récent !). --> https://www.amazon.fr/gp/css/returns/homepage.html?ref_=footer_hy_f_4 Cordialement oracle7😉

@MilesTEG1 Bonjour, Désolé mais je crains que tu ne mélanges les choses. Pas grave ! 🤪 Ce n'est pas dans le docker-compose qu'il y a problème mais lorsque tu crées la première fois ton réseau bridge personnalisé : Soit tu passes par l'interface de docker dans DSM et là pas soucis. Soit tu utilises sous SSH en CLI la commande et là risque de soucis : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring Le problème que j'ai souligné se passe au niveau de l'option "com.docker.network.bridge.name" de cette dernière. Par exemple ici "br_monitoring" ne pose pas de problème car < 15 caractères. Par contre si dans l'option tu saisis par exemple : "br_nextcloud_network" tu auras l'erreur et pas de création du réseau. Pour l'intant, je n'ai pas recontré d'anomalies avec des noms "longs" pour les réseaux. Par exemple ici "monitoring". Donc dans ton cas "nextcloud_network", bien que faisant lui plus de 15 caractères, doit passer aussi. C'est donc juste le nom donné pour l'option de la commande CLI qui est limité à 15 car. Cela dit à mon humble avis une bonne pratique serait de ne pas dépasser 15 car dans tous les cas. Maintenant ce que j'en dit ... Est-ce plus clair comme cela ? Cordialement oracle7😉

@.Shad. Bonjour, Finalement pour ma question : J'ai trouvé le problème : l'option "com.docker.network.bridge.name" ne supporte pas un nom de réseau > 15 caractères sinon on récupère le message d'erreur. A toi de voir, mais il serait peut-être judicieux d'insérer dans ton TUTO cette précision pour éviter des déconvenues, non ? Cordialement oracle7😉