bruno78

Bonjour @vincentbls certes, mais tu vas te rendre compte, comme nous, que cela ne suffit pas. Voir, entre autre, le post de @PPJP un peu plus haut. Avoir les nouveaux certificats dans ./_archive est insuffisant (nous aussi on y a cru !). J'ai quasiment terminé mon script pour automatiser ce déploiement, j'espère pouvoir tester ce weekend .... (j'ai d'ailleurs inclus un test de date de renouvellement (T0+60j), afin de pouvoir se passer de l'option --force)

@Jeff777, oui, l'AP_ref #0 c'est le Wifi b/g/n, et l'AP_ref #1 c'est l'AP wifi ac (Freebox Revolution v2) et donc pour l’affichage, pour la Table Grafana de lla colonne AP_Ref Ça me donne les station en Wifi B/G/N en vert, et celles en wifi ac en bleu ...

Merci @Einsteinium, je vais reprendre le sujet et refaire quelques tests en suivants tes indications. En ce qui concerne HSTS, j'avais cru comprendre que c'était irreversible ? Càd. une fois activé, on ne peut plus repasser en http ? je vais aller voir https://hstspreload.org très interessé par le dernier point (wild card avec renouvellement auto). De mon côté je regarde ce problème de renouvellement auto d'un wildcard sur DSM (cf tuto de @oracle7). Ca avance doucement, le problème étant le déployement automatique des services sur le nouveau certificat renouvellé dans DSM)

Bonjour @Jeff777 non non, il ne faut pas redemarrer du début, heureusement. Il suffit de mettre à jour le docker telegraf : placer le nouveau script python dans le repertoire /usr/local/py du docker mettre à jour le fichier de configuration de telegraf, section "input plugin" (remplacer freebox_054.py par freebox_058.py) on redemarre le docker telegraf

@PPJP merci. La tache semble lourde ! Je ne lâche pas le sujet, mais ça risque de prendre du temps. Je vais regarder jq que je ne connais pas. Et peut-être en parallèle continuer malgré tout en Python pour valider l'ensemble de la mécanique ..... .

@PPJP waouh !! . Bon d'abord merci PPJP. Effectivement ces aspects étaient passés sous le radar. Là du coup je crains que ce ne soit un peu (beaucoup) au delà de mes capacités, soyons honnête. Quand au Python, il faut avouer que pour traiter un fichier .json, c'est pratique. Quel outil natif proposerais-tu dans ce cas ? Merci en tout cas de t'être intéressé au sujet. Bruno78

@oracle7, @Jeff777, du coup, je viens via le DSM de basculer le service en cause sur un autre certificat puis de le ramener sur celui par défaut que j'avais renouveler, .... et là c'est bon, le certificat renouvelé est bien pris en compte ! Mais je ne trouve dans les arborescences /volume1/Certs ou /usr/syno/etc/certificate aucun fichier ayant été modifié suite à cette modif (à part bien sûr le fichier INFO puisque le service a été bougé de certificat). Mais au final le fichier INFO est bien le même qu'avant cet aller-retour ! En particulier, les fichiers .pem inclus dans system/default n'ont pas bougé. Existe t'il une commande linux un peu globale pour voir les fichiers qui ont été modifiés dans une arborescence dans un certain laps de temps ?

@Jeff777, oui c'est exactement cela. Et ayant mené le process quasiment jusqu'au bout, je ne comprends pas que le navigateur me dise utiliser un certificat que j'ai supprimé du NAS .... Il doit y avoir un flag quelque part ....??

Bonjour, je reviens vers vous à propos de l'automatisation complète du processus sur DSM. ... Et là je me casse les dents .... il doit me manquer une info ... j'ai fait un petit script python qui réalise les opérations suivantes : sauvegarde des fichiers INFO et DEFAULT (/usr/syno/etc/certificate/_archive) lecture des fichiers INFO et DEFAULT renouvellement du certificat (SYNO_Create = 1; /usr/local/share/acme.sh/acme.sh --cron --force --home /usr/local/share/acme.sh/) (--orce pour le forcer à renouveller le certificat puisque la date de renouvellement [T0+60j par defaut] n'est pas atteinte. lecture des nouveaux fichiers INFO et DEFAULT suite au renouvellement mise à jour de INFO en inscrivant les services sur le nouveau certificat par defaut renommage de la description de l'ancien certificat en "xxx_old" tous les contrôles et traces prouvent que le script fonctionne. le nouveau fichier INFO est correct et contient bien la référence du nouveau certificat créé. Ce nouveau certificat est bien créé dans l'arborecence ./_archive le nouveau fichier INFO est bien déployé dans le DSM SYno (contrôle de la fenêtre Sécurité > certificat) la trace de la commande acme.sh montre que c'est OK la date d'expiration du nouveau certificat est bien à T0+90j, la date de renouvellement à T0+60j les fichiers LetsEncrypt mis à jour dans /volume1/Certs sont cohérents avec ce nouveau certificat généré. malgré cela, un test sur un domaine xxx.domain.tld qui a donc été renouvelé montre que le certificat utilisé est toujours l'ancien ! (qui pourtant est vierge de services) le supprime l'ancien certificat via le DSM : idem je redémarre nginx : idem Donc je ne comprends pas comment le site peut utiliser un certificat qui n'existe plus sur le DSM ! (et oui, je nettoie le cache des navigateurs à chaque essai) Donc si une bonne âme avait des pistes de réflexions, je suis preneur .... Il doit surement rester une référence à l'ancien certificat quelque part ? mais même dans ce cas là, puisqu'il a été supprimé, il ne devrait pas pouvoir être utilisé ? Merci

Bonjour, je vous livre ici une mise à jour du fichier python pour le monitoring de la Freebox Revolution.freebox_058.py Evolution : affichage de la version et de la date du fichier python requete Grafana : SELECT last("nom_fichier"), last("last_updated"), last("version_script") FROM "freebox" WHERE ("tag1" = 'python') AND $timeFilter visualisation : Ma nouvelle Fbox étant une V2, j'ai 2 AP Wifi, N et AC. requete Grafana : SELECT last("primary_name"), last("addripv4"), last("last_activity_date"), last("host_type"), last("active"), last("rx_bytes") AS "rx_bytes", last("tx_bytes") AS "tx_bytes", last("rx_rate") AS "rx_rate", last("tx_rate") AS "tx_rate", last("AP_ref") AS "AP ref" FROM "autogen"."freebox" WHERE ("tag1" = 'wifi_list') AND $timeFilter GROUP BY "tag3" visualisation : Affichage du status de la connexion fibre (cas de resynchro sans perte de signal) et visualmisation de la plage de ports dispo suivant que l'on est en full stack ou pas : requete Grafana : SELECT last("sfp_has_signal") AS "Signal", last("ipv4") AS "IPv4", last("ipv6") AS "IPv6", last("media") AS "Media", last("cnx_state") AS "state", last("ipv4_port_range_low") AS "Port Low", last("ipv4_port_range_up") AS "Port Up" FROM "autogen"."freebox" WHERE ("tag1" = 'box') AND $timeFilter visualisation : A priori pour le moment je n'ai pas d'autres évolutions en prévisions .... sauf manque flagrant ? Bruno78

Bonjour, aucun problème de redemarrage constaté non plus .... Des changements de configuration ou des ajouts particuliers qui pourraient être mis en cause ? ou à configuration strictement équivalente ?

Bonjour à tous, à @oracle7, le script d'automatisation avance, mais j'ai eu assez peu de temps dispo ces derniers jours. J'ai refais des essais, l'automatisation semble bien fonctionner, mais j'ai un soucis : à savoir que le certificat que LE me crée est toujours "FAKE", donc a priori non utilisable. Et pourtant, j'ai enlevé le paramètre --staging. Mais sinon j'arrive bien à rendre le nouveau certificat opérationnel et déployé, avec tous les services pré-existants déclarés et actifs. Donc on n'est plus très loin je pense ..... . PS : ce sera un script écrit en Python.

Bonjour, ayant repris un peu la documentation (oui c'est quand même bien utile !), la déconnexion toutes les 24 heures correspond au token de session, dont la valeur par défaut et de 86400sec, soit 24h. Mais comme à présent, suite à la mise à jour auto cette nuit à 03:00, le VPN a été redémarré à cette heure là, dorénavant le tunnel va redémarrer toutes les nuits à 03:00. Ça ne me gêne pas, d'autant que la reconnexion est quasi immédiate. Par contre, je me demande comment fonctionne le FW mis à disposition par OVH : j'ai suivi scrupuleusement ce tuto d' @Einsteinium. Tous les problèmes rencontrés se situaient en fait entre la chaise et le clavier .... Très beau TUTO ! Plus que par réelle nécessité, cela permet d'apprendre. une fois compris à peu prêt le principe, je coince sur le FW, parce que : j'utilise la partie proxy, et donc renvoie vers un virtual host de mon SYNO. OK et donc pas besoin d'ouverture de port (DMZ) sur OpenVPN. OK sur le FW d'OVH, je n'autorise spécifiquement que les ports 443, 1194, 943 et un port SSL (autre que 22) et je bloque tout le reste. => je ne vois donc pas comment le bloc #1 de /etc/nginx/conf.d/default.conf ( la redirection http vers https ) peut fonctionner, puisque cela suppose que le port 80 passe le FW d'OVH sur le VPS ?? Par contre, ce blocage du port 80 semble opérationnel si on cherche à atteindre le serveur nginx que l'on a configuré sur le VPS. Je n'atteints le serveur nginx du VPS que si je passe par le https sur 443. Le http sur 80 est bien bloqué (et pas redirigé vers https). j'aurai tendance à conclure que le trafic entant par le VPN OpenVPN ne passe pas par le FW de la VPS d'OVH. Ce trafic ne sera filtré que par le FW du NAS en entrée du NAS. Est-ce que cela correspond à ce que vous observez ? Est-ce le comportement normal ? Merci

@_Megalegomane_ lors de ta demande de certificat, es-tu sur d'avoir bien initialisé correctement toutes les variables d'environnement ?

Bonjour, @oracle7 pour info je suis en train de travailler sur l'aspect automatisation du deployment (modification du fichier INFO après renouvellement du certificat du repertoire _archive). C'est en cours de tests .... mais faut être prudent pour être sûr de ne pas tout mélanger et véroler. On aurait ainsi une automatisation complète. @_Megalegomane_: es-tu bien connecté en "vrai" root pour réaliser toutes les commandes (et non pas en sudo -i) ?

Bonjour, j'ai une question spécifique à OpenVPN : je constate que le VPN est reseté et ré-établi immédiatement, à l'initiative du serveur (donc du VPS OVH), toutes les 24h heures. Cela ne me gêne pas en soit, mis je ne me souviens pas l'avoir configuré quelque part. Et en particulier cela se produit tous les jours à 17:59 à quelques secondes prêt. Je préfèrerai pouvoir fixer cet horaire dans la nuit. Il y a t'il un paramètre à configurer ? Bruno78

arf !! piégé ! ok je n'ai rien dit. On a tellement l'habitude des /24 ! Well done !

Effectivement, en plus tu joues sur des réseaux différents. Et non, Docker ne crée pas les dossiers tout seul. Par contre je suis surpris de l'adresse de ton docker (avant dernière ligne) en 172.16.2.211 ... ??? ce n'est pas plutôt 172.16.0.211 ??

+1 pour le PiHole sur Rasberry !

@bagu, @anorec, je veux bien passer un peu de temps, mais vous ne donnez aucun détail de vos configrations respectives, .... donc difficile. De quelle(s) configuration(s) fonctionnelle(s) partez vous pour mettre en œuvre DNS server + Pihole ? quelle est votre config DHCP ? quelle est votre configuration DNS server ? quelle est votre config docker pihole ? fichier de conf ? docker-compose.yaml ?) quelle est votre config macvlan ? avez-vous créé l'interface supplémentairement pour permettre au docker macvlan de communiquer avec le NAS ? docker inspect <nom du docker pihole> docker network inspect <nom du reseau macvlan sur lequel est configuré pihole>

il faut que tu nous donnes les détails de tes configurations ....

@anorec, pour avoir DNS server et PiHole/Docker opérationnels en même temps, tu dois avoir le docker Pihole installé sur un reseau de type macvlan, sur lequel Pihole aura une adresse indépendante de celle du NAS (ce qui lui permettra d'ouvrir également le port 53). Là je pense que ton installation du Docker Pihole n'est pas en macvlan.

Bonjour, peux-tu stp en dire un peu plus ? c'est la configuration que j'utilise : 1er DNS attaqué c'est le DNS serveur du NAS, qui lui même attaque le PiHole (docker macvlan). J’étais en Pihole4, upgrade en pihole 5 automatique. RAS. Peut-être vider les caches des navigateurs et des stations réseaux ? Bruno78

Et bien oui mais c'est bien sûr !! Impecc ! Je m'échinais à essayer de joindre directement influxdb Il faut donc que je règle mon problème d'adresse fixe pour mon client VPN. Merci encore ! Bruno78

Log telegraf sur le VPS : Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Starting Telegraf 1.14.3 Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Loaded inputs: mem processes swap system cpu disk diskio kernel Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Loaded aggregators: Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Loaded processors: Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Loaded outputs: influxdb Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! Tags enabled: host=vps-xxxxxxxx Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"vps-xxxxxxxx", Flush Interval:10s Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z D! [agent] Initializing plugins Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z D! [agent] Connecting outputs Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z D! [agent] Attempting connection to [outputs.influxdb] Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z D! [agent] Successfully connected to outputs.influxdb Jun 06 06:46:59 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:46:59Z D! [agent] Starting service inputs Jun 06 06:47:15 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:15Z E! [outputs.influxdb] When writing to [http://172.20.0.3:8086]: Post http://172.20.0.3:8086/write?consistency=any&db=vps_ovh_telegraf: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) Jun 06 06:47:15 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:15Z D! [outputs.influxdb] Buffer fullness: 24 / 10000 metrics Jun 06 06:47:15 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:15Z E! [agent] Error writing to outputs.influxdb: could not write any address Jun 06 06:47:25 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:25Z E! [outputs.influxdb] When writing to [http://172.20.0.3:8086]: Post http://172.20.0.3:8086/write?consistency=any&db=vps_ovh_telegraf: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) Jun 06 06:47:25 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:25Z D! [outputs.influxdb] Buffer fullness: 37 / 10000 metrics Jun 06 06:47:25 vps-xxxxxxxx telegraf[1186]: 2020-06-06T06:47:25Z E! [agent] Error writing to outputs.influxdb: could not write any address