This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

bruno78

Membres
  • Compteur de contenus

    682
  • Inscription

  • Dernière visite

  • Jours gagnés

    12

bruno78 a gagné pour la dernière fois le 17 juin

bruno78 a eu le contenu le plus aimé !

À propos de bruno78

  • Date de naissance 01/11/1963

Mon Profil

  • Pays / Ville
    Région Parisienne (78)
  • Intérêts
    Geek - Réseaux IP/MPLS - Photographie
  • Mon NAS
    DS918+

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

bruno78's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Posting Machine Rare
  • Week One Done Rare

Recent Badges

75

Réputation sur la communauté

  1. @Ivanovitch effectivement, il y a des fois ou ça passe, ...et de fois ou ça ne passe pas (403) ! J'ai repéré un cas ou c'est passé, et derrière le certificat est bien généré, mais il y a erreur sur la suppression du record TXT _acme-challenge. D'où le fait que ces enregistrements restent à polluer les zones DNS.
  2. @Ivanovitch bonjour, je viens de regarder rapidement mes logs, et je trouve a priori cette action (get /domain/zone/_acme.ndd.tld ...) dans les renouvellements réussis . Je n'ai pas poussé l'étude du log et des messages aussi loin que toi, mais du coup je ne sais pas trop quel est le problème avec ces enregistrements TXT _acme-challenge. Toujours est'il que si il n'y en a pas au moment de la demande de renouvellement, ca se passe beaucoup mieux. Curieux de voir le traitement de ta demande de modification.
  3. @Einsteinium si je te dis que je créée un token global avec les droits suivants : GET /domain/zone GET /domain/zone/* DELETE /domain/zone/* Restricted IPs : xxx.yyy.zzz.ttt (mon ip publique) Je me fais incendier ou pas ? Je pense que oui et tu auras raison ... Effectivement ça évite de se poser des questions, mais c'est trop large : tu vas me dire qu'il faut limiter explicitement aux domaines (zones) que l'on veut exposer à ce script, et donc prendre individuellement les clés utilisées pour le renouvellement acme .... je vais modifier mon script en conséquence.
  4. @Einsteinium Oui exact. Ayant plusieurs domaines, j'ai simplifié en créant un jeu de clés supplémentaire me permettant d'accéder d'un coup d'un seul à l'ensemble des domaines dispo sous mon compte OVH. C'est effectivement peut-être optimisable ....
  5. @Einsteinium ok pas de problème pour mettre en ligne. Le temps de le mettre au propre et de faire un mini mode d'emploi (là encore, pour accéder à l'API, il faut générer des clés au préalable) ....
  6. Bonjour @Ivanovitch, j'ai eu également ces derniers jours beaucoup (trop ?) d'erreurs de renouvellement de certificats à cause des enregistrements TXT. Du coup, via l'API OVH, j'ai un script qui tourne et "nettoie" systématiquement les enregistrements TXT de type "_acme-challenge" (dans la terminologie OVH : fieldType='TXT',subDomain='_acme-challenge'). Je n'ai pas suffisemment de recul, mais pour le moment, mais je n'ai plus d’échec de renouvellement sur les 2 dernières tentatives. C'est un petit script python qui tourne quotidiennement sur un RPI4. Si intéressé(s), me faire signe ...
  7. @Bruno21 bonjour, oui les permaliens fonctionnent en DSM7. Il faut juste noter que le fichier server.webstation-vhost.conf se trouve désormais à l'emplacement suivant : /etc/nginx/sites-enabled (qui est un lien vers /usr/local/etc/nginx/sites-enabled). PS : pour ma part j'ai abandonné ce type d'installation (sans paquet WP) du fait des risques d'effacement de ta config lors de mises à jours DSM. Mieux vaut, à mon humble avis et lorsque c'est possible, se tourner vers des solutions de type Docker qui ne toucheront pas au système DSM) Cdt, bruno78
  8. Bonjour @.Shad., j'ai déjà une période d'acquisition de 60 secondes. Par contre, en passant la durée de conservation des données de 90j à 30j , je gagne bien environ 66% de consommation mémoire . Quant à la production de graphes long terme, Influxdb2 repose sur le principe de "task", qui permettent de faire du "down sampling" , finalement assez facilement. Du coup je garde des graphes sur 1 an, avec une periode de 15min. Pour le moment ça a l'air de bien fonctionner. Curieux de voir pourquoi le monitoring du pfsense ferait planter influxdb .....
  9. @axb Bonjour, oui, problème avec la CK ... Soit la validité, soit mal recopiée .....
  10. @.Shad. oui je suis sûr que ca existe, faut juste prendre le temps. Je me disais qu'en ne gardant les données brutes de moins de 90j cela suffirait, mais apparemment non. C'est mon prochain chantier ....
  11. @Jeff777, en fait je ne suis pas sûr que le nombre de graphes soit le problème, a priori cela concerne plutôt Grafana ? Par contre la quantité de données rapatriées vers Influxdb doit être le vrai problème. En regardant rapidement, j'ai plus de 3G de données dans la db influxdb2. Si il met tout en mémoire ...... PS : idem en passant à la dernière version (2.0.7) d'influxdb2. Faut que je regarde comment "compacter" les données anciennes, par exemple supérieure à 1 mois. Pas forcement besoin de garder 1 échantillon par minutes sur 90j ? Je faisais ça sous Influxdb1 (retention policy et continuous query), mais je ne l'ai pas reconduit sous influxdb2, le mécanisme a changé ...
  12. Bonjour @Jeff777, ça me laisse rêveur ! je dois avoir mal configuré quelque chose .... mais je n'ai rien gagné au passage Influxdb => Influxdb2. J'avais déjà cette consommation mémoire avant. Pour info, 21 dashboards avec une quinzaine de graphes par dashboard, et en général une période de refresh de 1mn. Période de retention des données de 90j. @.Shad., je vais tenter le coup. Cependant la doc Influxdb2 indique : et je suis bien en V2.0.4. quay.io/influxdb/influxdb v2.0.4 4be70a587e97 4 months ago 227MB v2.0.4 General Availability [2021-02-04] Docker ARM64 This release extends the Docker builds hosted in quay.io to support the Linux/ARM64 platform. 2.x nightly images Prior to this release, competing nightly builds caused the nightly Docker tag to contain outdated binaries. This conflict is fixed, and the image tagged with nightly now contains 2.x binaries built from the HEAD of the master branch. Breaking Changes inmem index option removed This release fully removes the inmem indexing option, along with the associated config options: max-series-per-database max-values-per-tag The startup process automatically generates replacement tsi1 indexes for shards that need it.
  13. Bonjour @MilesTEG1, @.Shad., je suis sous Influxdb2 depuis plusieurs mois, .... et je n'ai vu aucune amélioration sur la consommation mémoire, toutes choses égales par ailleurs. Par ailleurs, je suis jaloux de la conso mémoire de @MilesTEG1. De mon côté, j'ai certes beaucoup (trop ?) de graphes et dashboards, mais ma conso mémoire est plutôt de l'ordre de 3.5GB !! Du coup j'ai été obligé de prendre une VPS à 8GB RAM, ce qui financièrement parlant ne tient pas la route. Je vais surement migrer influxdb2/grafana sur un RPI4 à 8GB ...
  14. @MilesTEG1, non, a priori pas possible d'enregistrer les modifs faites via l'UI dans le fichier conf.yml. Même les modifs de conf via le menu "config" ne sont que locales. Il faut faire un copier coller manuel dans son fichier conf.yml et régénerer le tout pour que ce soit pris en compte.
  15. Quelques explications ici : https://github.com/acmesh-official/acme.sh/wiki/Change-default-CA-to-ZeroSSL Où il est notamment précisé : Starting from August-1st 2021, acme.sh will release v3.0, in which the default CA will use ZeroSSL instead. This change will only affect the newly created(issued) certs after August-1st (with v3.0), any pre-existing certs will still be renewed automatically aginst the current CA.