bruno78

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%

Bonjour, je reviens sur la question du renouvellement tous les 3 mois. dans les tâches planifiées, on choisit une date à T0+85 jours, et on donne une période de 3 mois au script. Donc si je comprends bien, on aura un premier renouvellement dans 85 jours, mais le suivant ne sera que 3 mois après, et non pas 85 jours. Donc pas de marge ? Par ailleurs, j'ai fait un test du script ce matin. Ci-dessous le retour du script : Tâche : Renew Certif LE WildCard Heure de début : Sun, 31 May 2020 07:12:36 GMT Heure d’arrêt : Sun, 31 May 2020 07:12:37 GMT État actuel : 0 (Normal) Sortie standard/erreur : [Sun May 31 07:12:36 CEST 2020] ===Starting cron=== [Sun May 31 07:12:37 CEST 2020] Already uptodate! [Sun May 31 07:12:37 CEST 2020] Upgrade success! [Sun May 31 07:12:37 CEST 2020] Auto upgraded to: 2.8.6 [Sun May 31 07:12:37 CEST 2020] Renew: 'xxxxxxx.eu' [Sun May 31 07:12:37 CEST 2020] Skip, Next renewal time is: Wed Jul 29 16:26:24 UTC 2020 [Sun May 31 07:12:37 CEST 2020] Add '--force' to force to renew. [Sun May 31 07:12:37 CEST 2020] Skipped xxxxx.eu [Sun May 31 07:12:37 CEST 2020] ===End cron=== Que faut'il en conclure ? Certificat créé hier, donc il "skip" la demande de renouvellement aujourd'hui estimant que c'est trop tôt, pas nécessaire ? date de prochain renouvellement 29 juillet 16:26 UTC 2020, soit 60 jours après la création ? si on période de 3 mois pour la tache periodique est trop longue, puiqu'a priori on ne peut pas faire une tâche avec une période de 2 mois, alors une tâche planifiée mensuelle ne serait'elle pas la solution ? Bruno78 @Jeff777, j'ai eu exactement ce problème (devoir mettre --force). En fait cela ne fonctionne pas même avec --force. Je suppose que tu as du passer en root avec un sudo ? C'était mon cas (sur PC avec Putty, je passais par un compte admin puis sudo -i), et il a fallu, sur les conseils bien avisés d' @oracle7, que je configure une "vraie" connexion root (voir tuto "Accès SSH et ROOT via DSM6"). Ca te règlera au moins ce problème là. Pour le reste, c'est au delà de mes compétences actuelles ..... Bruno78

Déployement Nickel !! Merci

Merco @oracle7 effectivement si on ne se trompe pas dans la génération des API Keys ni en les recopiant, et si on utilise la "vraie" connexion root (càd avec les clés ssh comme tu me l'as indiqué cf tuto "Accès SSH et ROOT via DSM6") et non pas du sudo alors ca fonctionne !! Il me reste maintenant à déployer le certificat ... Merci

Oui, on a également le message "Tout les paquets" La connexion a échoué, vérifiez votre réseau et paramètre de l'heure" . cf Néanmoins, est-ce la cause de tes problèmes ? je ne sais pas ....

Merci @oracle7 pour ce super Tuto ..... je suis bloqué à l'étape de création du Certificat .... c'est ballot ! tout d'abord, via putty et après sudo -i pour passer en root, je me fais jeter sur certaine commandes ./acme.sh : 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 idem pour la création du certificat. Du coup obligé d'utiliser l'option --force ensuite, sur OVH, je n'ai réussi à créer les API Keys qu'avec mon identifiant OVH, mais pas avec mon login (email). et au final, en generant le certificat avec --force et les APi Keys générées avec mon identifiant OVH, j'ai l'erreur suivante (ndd masqué avec xxxx) ainsi que les clés: [Sat May 30 16:34:13 CEST 2020] Adding txt value: xxxxxxxxxxxxxxxxxx-0Y2a290 for domain: _acme-challenge.xxxx.eu [Sat May 30 16:34:13 CEST 2020] Using OVH endpoint: ovh-eu [Sat May 30 16:34:13 CEST 2020] OVH_API='https://eu.api.ovh.com/1.0' [Sat May 30 16:34:13 CEST 2020] Checking authentication [Sat May 30 16:34:13 CEST 2020] domain [Sat May 30 16:34:13 CEST 2020] GET [Sat May 30 16:34:13 CEST 2020] url='https://eu.api.ovh.com/1.0/auth/time' [Sat May 30 16:34:13 CEST 2020] timeout=30 [Sat May 30 16:34:13 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header -g --connect-timeout 30' [Sat May 30 16:34:13 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60 [Sat May 30 16:34:13 CEST 2020] ret='60' [Sat May 30 16:34:13 CEST 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)' [Sat May 30 16:34:13 CEST 2020] GET [Sat May 30 16:34:13 CEST 2020] url='https://eu.api.ovh.com/1.0/domain' [Sat May 30 16:34:13 CEST 2020] timeout= [Sat May 30 16:34:13 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header -g ' [Sat May 30 16:34:13 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60 [Sat May 30 16:34:13 CEST 2020] ret='60' [Sat May 30 16:34:13 CEST 2020] error [Sat May 30 16:34:13 CEST 2020] The consumer key is invalid: OlZrPWfCuyLxxxxxxxxxxxxxxxxx [Sat May 30 16:34:13 CEST 2020] Please retry to create a new one. [Sat May 30 16:34:13 CEST 2020] Error add txt for domain:_acme-challenge.xxxx.eu J'ai recréé 2 fois les API Keys, toujours la même erreur. Je cherche .....

Hello , effectivement, idem, "connexion a échoué. ......".

Bonjour @aware j'utilise la visualisation "Single Stat", Show "Current" Ceci dit, je ne sais pas pourquoi a priori ce que tu utilises ne semble pas fonctionner .....

Bonjour, merci pour ton commentaire 🙂 A propos de l'uptime, ..... c'est extrèmement surprenant ! Le script est capable de remonter 2 valeurs depuis la freebox : "uptime_val" : il s'agit du uptime en secondes "uptime" : il s'agit du uptime, exprimé par la Freebox en valeur lisible (chaine de caractères). C'est la Freebox qui fait la conversion. Je viens de faire le test directement depuis un terminal sur fbx_telegraf: root@fbx_telegraf:/usr/local/py# python3 freebox_058.py -H | grep uptime freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL sys_uptime_val=1976296 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL uptime="22 jours 20 heures 58 minutes 16 secondes" root@fbx_telegraf:/usr/local/py# sys_time = 1976296 secondes, ce qui équivaut à 22j, 20h, 58 min, 16sec uptime remonté lisible par la Freebox = "22 jours 20 heures 58 minutes 16 secondes". => c'est cohérent. A moins que ta Freebox ne soit pas à l'heure ????? mais je ne vois pas comment ! Peux-tu faite la vérification ci-dessus et reverifier avec l'uptime directement sur la Freebox ? Bruno78 PS : j'ai peut-être été trop vite ! C'est sur la Freebox ou sur le NAS que tu as 2 jours de décalage ?? . Ceci dit, pas plus de raison d'avoir 2 jours de décalage sur le NAS !

Bonjour @Jeff777 Pour l'afficher : Type=Number, Unit=Duration, Decimals=1 Bruno78

Bonjour, peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ? en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug .... Merci

@Jeoffrey Stinson-Cooper, sur la méthode à employer .... je ne pense pas que la difficulté soit très différente entre les méthodes. Via Portainer nécessite d'installer Portainer en préalable ..... Chaque méthode a ses adeptes 🙂. As tu configuré un accès ssh sur ton NAS ? le montage de volumes : permet d'avoir les données de certains répertoires du Docker synchronisées avec un répertoire de ton NAS. En particulier, si tu effaces ton Docker, si tu le mets à jour .... donc avec une nouvelle image, alors cette "synchronisation" va permettre à ta nouvelle image de repartir de là où elle avait été arrêtée. Cela permet de ne pas perdre les données (configuration, base de données, .....) DHCP Freebox : si tu souhaites utiliser le docker pihole du NAS en priorité, il faut positionner son adresse en première position dans la liste des DNS de la Freebox dans la section DHCP. Et ensuite, tu ajoutes les DNS secondaires, dans l'ordre de ton choix. Et si tu ne l'as pas encore suivi, je te conseille vivement de suivre le tuto suivant: de @Fenrir