bruno78

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

Bonjour, j'ai loué, autant par besoin que pour manipuler un peu avec, un VPS chez OVH dans le cadre du TUTO sur l'ouverture de ports en 4G (bien que je n'ai pas de routeur 4G) L'installation de OpenVPN ne pose pas de problème particulier (sauf le fait que je n'arrive pas à configurer une adresse statique en 10.0.0.x pour un user particulier, mais c'est un autre sujet). Mon NAS se connecte en tant que client et le VPN monte sans problème dans une plage en 172.27.224.xxx/24. L'ouverture de port via la configuration de la DMZ d'OpenVPN est ok également. Or sur le NAS tourne également une suite telegraf/influxdb/grafana, en Docker (mode bridge, sur 172.20.0.x). J'ai installé a priori sans problème telegraf sur le VPS. Et la le problème : comment depuis telegraf tournant sur le VPS OVH je peux adresser en envoyer les stats relevées vers influxdb en 172.20.0.x:8086 en docker sur le NAS. Telegraf me dit évidemment qu'il n'arrive pas à se connecter à influxdb ! Soit une chaine qui pourrait se représenter ainsi. (IP publique) - VPS/OVH(telegraf) (172.27.224.1) ==(VPN)== NAS(172.27.224.x) ** [NAS] ** Docker/Bridge(172.20.0.x) == influxdb(172.20.0.3:8086) Que faudrait' il a priori configurer au niveau d'OpenVPN sur le VPS, du FireWall OVH, du NAS pour que la connectivité soit OK ? Merci, ... je tourne en rond. Merci d'avance (si ce n'est pas clair, je ferai un schema !) Bruno78

[emoji16] Envoyé de mon STF-L09 en utilisant Tapatalk

Oui et éventuellement vérifier les alimentations électriques (multiprise ? .... ) Envoyé de mon STF-L09 en utilisant Tapatalk

@oracle7, reconfiguration manuelle à chaque renouvellement : non bien sûr ce n'est pas la mer à boire (ca peut même avoir certaines vertues). ... mais cela aurait été the cherry on the cake !...... . Je vais continuer à chercher sur ce sujet, .... étant moi aussi un peu têtu ! Bon courage, Bruno78

Bonjour, Donc le NAS est connecté en Ethernet sur la Box et tes autres appareils sont en Wifi, c'est ca ? Ta connexion NAS est bien un Ethernet 1G, pas du 100M ? ce sont des débits entre quoi et quoi sur ton Wifi ? peux-tu stp donner dans les 2 cas les caractéristiques de la connexion Wifi ? par exemple quelle est la vitesse synchro réelle du Wifi (avant et après) ? Par exemple je suis synchro à 650M (oscille entre 650 et 720Mbps) sur mon wifi N Qui est DHCP ? Quels sont les DNS ? Est-ce systématique sur tous des appareils en Wifi ? je ne comprends toujours pas à quoi correspondent exactement les courbes ? quels sont les types d'équipements connectés en Wifi ? ... Bref problème bizarroide !

Bonjour à vous, grace à l'option --staging , j'ai refais quelques essais ce matin. J'arrive bien à forcer le renouvellement de certificat (--force --staging) bien que la date de renouvellement ne soit pas atteinte, par contre même en prenant la méthode dite "annule et remplace", je me retrouve avec un nouveau certificat importé dans DSM, nouvelle date d'expiration, mais toujours par defaut et vièrge de tout service. J'ai l'impression que l'on n'évitera pas, quelle que soit la méthode, le fait de reconfigurer à la main, à chaque renouvellement, nos services sur le nouveau certificat. Remarque : lorsque l'on crée un certificat LE avec l'option --staging, le detail du certificat indique : Emis par : FAKE LE Intermediate X1 Cdt, Bruno78

Merci @oracle7, je vais relire tout cela à tête reposée, il y a beaucoup d’informations dans ces 3 pages de TUTO, extrêmement intéressant. faut que je remette un peu tout cela dans l'ordre, et sans faire de bêtise ! Bruno78

Du coup en conjonction de l'instruction "--staging" et en employant tout simplement la méthode "annule et remplace" du § 5.2.1 ? A voir ... Donc si je comprends bien, il faut que je fasse : deployement "annule et remplace" du certificat par defaut : SYNO_Certificate="" $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm Puis job periodique de renouvellement, avec éventuellement --force, --staging, --days, .... (je viens de voir les dernières reponses)

@PPJP, merci pour l'info sur --staging. Néanmoins, je ne sais plus trop quoi tester pour avoir un renouvellement et non pas la création d'un nouveau certificat .... @Jeff777, oui, une fois le nouveau certificat créé, je peux basculer dessus l'ensemble des services, ... mais ça reste manuel. On cherchait ici une solution de renouvellement automatisée ....

Bonjour @oracle7, j'ai fait des essais en spécifiant SYNO_Create=1 [et SYNO_Certificate="nom du certificat", mais a priori seul SYNO_Create est nécessaire], et le résultat est que le certificat est bien créé .... mais c'est un nouveau certificat qui est importé dans DSM, en plus de celui existant. Ce nouveau Certificat devient "default", mais ne porte aucun service. Je n'ai pas trouvé comment remplacer l'ancien certificat par le nouveau dans DSM. Et maintenant, puisque j'ai fait "trop" d'essais en peu de temps, .... mes tentatives sont bloquées 😭. ("Error creating new order :: too many certificates already issued for exact set of domains") (Duplicate Certificate limit of 5 per week) Donc je suppose que dans la semaine qui vient je ne pourrais plus faire de tests .....

Non, je n'ai pas exporté ces variables, en particulier SYNO_Create qui semble manquer. Je ferais le test ce soir.

La solution d' @oracle7 est automatisée de bout en bout (et fait même le nettoyage de ta zone DNS en fin de procédure, fait l'import du certificat dans DSM , .... ). So what else ? Par contre, en relisant l'utilisation de l'option --force, il est noté que cela permet de renouveler les certificats immediatement (et donc avant le terme). Je vais donc positionner la tache periodique de renouvellement en exécution mensuelle ( puisque c'est tout les mois ou tout les 3 mois ....), avec --force. --force, -f Used to force to install or force to renew a cert immediately. Alors je viens de faire le test de renouvellement avec --force : la création est bien lancée mais l'import de fonctionne pas: deploy error : [Mon Jun 1 08:19:13 CEST 2020] Getting certificates in Synology DSM /usr/local/share/acme.sh/deploy/synology_dsm.sh: line 113: SYNO_Create: parameter null or not set [Mon Jun 1 08:19:13 CEST 2020] Deploy error Tâche : Renew Certif LE WildCard Heure de début : Mon, 01 Jun 2020 08:19:01 GMT Heure d’arrêt : Mon, 01 Jun 2020 08:19:13 GMT État actuel : 1 (Interrompu) Sortie standard/erreur : [Mon Jun 1 08:19:01 CEST 2020] ===Starting cron=== [Mon Jun 1 08:19:01 CEST 2020] Installing from online archive. [Mon Jun 1 08:19:01 CEST 2020] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Mon Jun 1 08:19:02 CEST 2020] Extracting master.tar.gz [Mon Jun 1 08:19:02 CEST 2020] Installing to /usr/local/share/acme.sh/ [Mon Jun 1 08:19:02 CEST 2020] Installed to /usr/local/share/acme.sh//acme.sh [Mon Jun 1 08:19:02 CEST 2020] Good, bash is found, so change the shebang to use bash as preferred. [Mon Jun 1 08:19:04 CEST 2020] OK [Mon Jun 1 08:19:04 CEST 2020] Install success! [Mon Jun 1 08:19:04 CEST 2020] Upgrade success! [Mon Jun 1 08:19:04 CEST 2020] Auto upgraded to: 2.8.6 [Mon Jun 1 08:19:04 CEST 2020] Renew: 'xxxxx.eu' [Mon Jun 1 08:19:05 CEST 2020] Multi domain='DNS:xxxxx.eu,DNS:*.xxxxx.eu' [Mon Jun 1 08:19:05 CEST 2020] Getting domain auth token for each domain [Mon Jun 1 08:19:09 CEST 2020] Getting webroot for domain='xxxxx.eu' [Mon Jun 1 08:19:09 CEST 2020] Getting webroot for domain='*.xxxxx.eu' [Mon Jun 1 08:19:09 CEST 2020] xxxxx.eu is already verified, skip dns-01. [Mon Jun 1 08:19:09 CEST 2020] *.xxxxx.eu is already verified, skip dns-01. [Mon Jun 1 08:19:09 CEST 2020] Verify finished, start to sign. [Mon Jun 1 08:19:09 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/87515198/xxxxxxxxxxxxxxx [Mon Jun 1 08:19:11 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/xxxxxxxxxxxxxxxxx [Mon Jun 1 08:19:11 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- MIIGYzCCBUugAwIBAgISBO57EPc9vBLFBmBAJwtzP9M/MA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA2MDEwNTE5MTBaFw0y MDA4MzAwNTE5MTBaMBgxFjAUBgNVBAMTDWxlc21vbmdldHMuZXUwggIiMA0GCSqG ..... FeEGXB6uxNy+bT7eMVPc6uwf/sFLsuRNoGyE5WraKHOlx3Ohx9VyL2uMEEwZOOq8 PWVPcGomXQ== -----END CERTIFICATE----- [Mon Jun 1 08:19:11 CEST 2020] Your cert is in /volume1/Certs/xxxxx.eu/xxxxx.eu.cer [Mon Jun 1 08:19:11 CEST 2020] Your cert key is in /volume1/Certs/xxxxx.eu/xxxxx.eu.key [Mon Jun 1 08:19:11 CEST 2020] The intermediate CA cert is in /volume1/Certs/xxxxx.eu/ca.cer [Mon Jun 1 08:19:11 CEST 2020] And the full chain certs is there: /volume1/Certs/xxxxx.eu/fullchain.cer [Mon Jun 1 08:19:12 CEST 2020] Logging into localhost:5000 [Mon Jun 1 08:19:13 CEST 2020] Getting certificates in Synology DSM /usr/local/share/acme.sh/deploy/synology_dsm.sh: line 113: SYNO_Create: parameter null or not set [Mon Jun 1 08:19:13 CEST 2020] Deploy error. [Mon Jun 1 08:19:13 CEST 2020] Error renew xxxxx.eu. [Mon Jun 1 08:19:13 CEST 2020] ===End cron===

Non, pas d'écrasement, à condition de bien choisir la methode de déploiement avec mode ajout .... (ce que j'ai fais). Et ensuite tu configures comme tu veux depuis l'interface DSM.

Ah mais oui mais non, .... je n'avais pas fait attention à la remarque .... mais je suis également sur PC sous Win10. Donc sous Win10, avec putty, je n'ai pas réussi à faire fonctionner acme.sh même avec --force tant que je me connectais avec un compte admin "normal" puis avec sudo -i. Il a fallu que je passe une vraie connexion root/ssh pour que cela fonctionne correctement. Désolé si j'ai pu laisser à penser que j'étais sous MAC .... . J'ai l'impression que quelle que soit la plateforme, il ne faut pas utiliser sudo dans ce genre d'opération. Après, si tu dis que pour toi cela a fonctionné avec --force .... . très bien mais peut-être avons-nous d'autres différences de configuration qui font que cela a fonctionné chez toi ? Mais ne serait-ce que pour la première commande, si exécutée sous sudo : root@ds918blam:/usr/local/share/acme.sh# ./acme.sh --upgrade --auto-upgrade It seems that you are using sudo, please read this link first: https://github.com/acmesh-official/acme.sh/wiki/sudo root@ds918blam:/usr/local/share/acme.sh# Il fait une remarque sur l'utilisation du sudo, mais a priori pas d'erreur signalée. Et pourtant, si on va vérifier le fichier account.conf, on s'aperçoit que la commande n'a pas été exécutée, le fichier n'est pas mis à jour. Donc je crains que l'utilisation du sudo apporte des problèmes pas forcement très visibles (droits, .... ). C'est pour cela que du coup je ne saurais que trop recommander de ne pas utiliser sudo, et de n'utiliser que la connexion root/ssh, histoire d'être sûr à 100%