bruno78

@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.

@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.

@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 ....

@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) ....

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 ...

@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

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 .....

@axb Bonjour, oui, problème avec la CK ... Soit la validité, soit mal recopiée .....

@.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 ....

@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é ...

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.

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 ...

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.

Bonjour, d'après ce que je vois dans les logs, zerossl est apparu pour la première fois lors de l’exécution du script le 14/juin, avec un upgrade en version 3.0.0. [Mon Jun 14 00:41:00 UTC 2021] ===Starting cron=== [Mon Jun 14 00:41:00 UTC 2021] Using config home:/acme.sh [Mon Jun 14 00:41:00 UTC 2021] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Mon Jun 14 00:41:00 UTC 2021] GET [Mon Jun 14 00:41:00 UTC 2021] url='https://api.github.com/repos/acmesh-official/acme.sh/git/refs/heads/master' [Mon Jun 14 00:41:00 UTC 2021] timeout= [Mon Jun 14 00:41:00 UTC 2021] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Mon Jun 14 00:41:00 UTC 2021] ret='0' [Mon Jun 14 00:41:00 UTC 2021] Installing from online archive. [Mon Jun 14 00:41:00 UTC 2021] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Mon Jun 14 00:41:00 UTC 2021] GET [Mon Jun 14 00:41:00 UTC 2021] url='https://github.com/acmesh-official/acme.sh/archive/master.tar.gz' [Mon Jun 14 00:41:00 UTC 2021] timeout= [Mon Jun 14 00:41:00 UTC 2021] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Mon Jun 14 00:41:01 UTC 2021] ret='0' [Mon Jun 14 00:41:01 UTC 2021] Extracting master.tar.gz [Mon Jun 14 00:41:01 UTC 2021] default_acme_server [Mon Jun 14 00:41:01 UTC 2021] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90' [Mon Jun 14 00:41:01 UTC 2021] Skip install cron job [Mon Jun 14 00:41:01 UTC 2021] Using config home: /acme.sh [Mon Jun 14 00:41:01 UTC 2021] Installing to /root/.acme.sh [Mon Jun 14 00:41:02 UTC 2021] Installed to /root/.acme.sh/acme.sh [Mon Jun 14 00:41:02 UTC 2021] OK [Mon Jun 14 00:41:02 UTC 2021] Install success! [Mon Jun 14 00:41:02 UTC 2021] Using config home:/acme.sh [Mon Jun 14 00:41:02 UTC 2021] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Mon Jun 14 00:41:02 UTC 2021] GET [Mon Jun 14 00:41:02 UTC 2021] url='https://api.github.com/repos/acmesh-official/acme.sh/git/refs/heads/master' [Mon Jun 14 00:41:02 UTC 2021] timeout= [Mon Jun 14 00:41:02 UTC 2021] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Mon Jun 14 00:41:02 UTC 2021] ret='0' [Mon Jun 14 00:41:02 UTC 2021] Upgrade success! [Mon Jun 14 00:41:02 UTC 2021] Using config home:/acme.sh [Mon Jun 14 00:41:02 UTC 2021] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Mon Jun 14 00:41:02 UTC 2021] Auto upgraded to: 3.0.0 Par contre, le script se déroule ensuite normalement, aucune demande d'enregistrement ni de directive particulière dans le fichier account. Le log indique clairement la directive suivante sans que je ne lui ai rien demandé explicitement ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' Le script se termine ensuite normalement (en arrêt puisque date de renouvellement non atteinte, je n'ai pas fais le -force). Comportement identique sur 4 domaines utilisant cette même méthode . Bruno78

@.Shad. @MilesTEG1, la bonne nouvelle avec Syno Photo en DSM7-RC (Synology Photo 1.0.0-0182), c'est que l'appli ainsi que ses réglages et dossiers est maintenant backupable via Hyper Backup. Ce n'était pas le cas jusque là avec la Beta.

Ok nickel 😄 J'attends ton retour 😉 @MilesTEG1 sans grande surprise, le script de création du MACVLAN au boot du NAS fonctionne impecc en DSM7-RC .

@MilesTEG1 je n'avais pas lu le script, mais je vois que tu utilises "synoservicecfg". A priori en DSM7 ce sera plutôt "synosystemctl" # synoservicecfg -ash: synoservicecfg: command not found # synosystemctl --help synosystemctl {COMMAND} ... Commands: start [--no-block] NAME... Start (activate) one or more units stop [--no-block] NAME... Stop (deactivate) one or more units enable NAME... Enable one or more unit files disable NAME... Disable one or more unit files restart [--no-block] NAME... Start or restart one or more units try-restart [--no-block] NAME... Restart one or more units if active reload [--no-block] NAME... Reload one or more units reload-or-restart [--no-block] NAME... Reload or restart one or more units reenable NAME... Reenable one or more unit files isolate [--no-block] NAME... Start one unit and stop all others mask [--runtime] NAME... Mask one or more units unmask [--runtime] NAME... Unmask one or more units uninstall NAME Remove units from system, as well as relating symlinks and flags daemon-reload Reload unit config get-default Get the name of the default target set-default NAME Set the default target get-enable-status NAME Get the enable status of given unit get-active-status NAME Get the active status of given unit get-load-status NAME Get the load status of given unit stop-service-by-reason REASON NAME... Stop one or more services by a reason start-service-by-reason REASON NAME... Start one or more services by a reason remove-service-reason REASON NAME... Remove reason for one or more services list-service-reason NAME List service reason get-unit-by-pid PID Get unit name that the pid belongs to list-service-by-mnt-path PATH List services using given mount path register-volume NAME VOLUME Register a volume for a unit package-register-volume NAME VOLUME Register a volume for a package unregister-volume NAME VOLUME Unregister a volume for a unit package-unregister-volume NAME VOLUME Unregister a volume for a package

@MilesTEG1 ce script fonctionne toujours parfaitement en DSM7 Beta. Pas encore passé en RC, mais je ne vois pas pourquoi il ne fonctionnerai plus .... Je te dis ... dans la journée peut-être ...

@MilesTEG1 bonjour, rien d'anormal à tous ces téléchargements. Une image Docker peut être composée de plusieurs "layers" suivant ce que le concepteur aura décider d'y intégrer. Quant à la fréquence d’exécution, de mon côté je le fais 1 fois par mois. Je n'ai pas vu d'effet secondaire négatif ... Cdt, Bruno78

@GrOoT64 j'ai ça dans la clé publique (j'ai tronqué le milieu): bruno@ds918blam:~$ sudo -i Password: root@ds918blam:~# cat /root/.ssh/authorized_keys ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20210515" AAAAB3NzaC1yc2EAAAABJQAAAf8kQ9Tjubc3LnoB3fehcYe/adZDpuvRJL1pP0XU h3/GR/pvoCq107QkY85cwQaTNGGih/8Dfs3wfjO2v6r+unlyHoyOLoSoTdJIjaVd [......] DQbDEShnudMIRd7qxb/D28f1asNRj5piBqDqGn5IDZFJGd3I+MtzunUBN+boEMVK ETKt/0Zg2PPV9RvLwXxqfUzbXf+JF6cVn2zSXhKEpyFXEKQkm4z9FQjuTmGxdQ0f 9O4J ---- END SSH2 PUBLIC KEY ---- root@ds918blam:~# Question bête cependant : comment on sait si on est en "vrai" root ou pas ? J'ai un doute tout d'un coup .... @GrOoT64 OK c'est bon à présent, merci. Effectivement, il faut bien copier/coller ce qui est donné dans la fenêtre de puttyKey Generator, et rien d'autre. Donc OK. Mais, je n'y avais pas trop prêté attention, si je fais "simplement" un sudo -i depuis un compte admin, je semble me retrouver en vrai root sans passer par la clé ssh privée/publique ? est-ce une illusion ? comment le vérifier ? Synology strongly advises you not to run commands as the root user, who has the highest privileges on the system. Doing so may cause major damages to the system. Please note that if you choose to proceed, all consequences are at your own risk. bruno@ds918blam:~$ bruno@ds918blam:~$ bruno@ds918blam:~$ sudo -i Password: root@ds918blam:~# whoami root root@ds918blam:~#

@GrOoT64 content que cela fonctionne chez toi. Du coup j'ai tenté de régénérer une nouvelle paire de clés pour l'accès root au NAS, et j'ai invariablement un refus : Il me semble pourtant avoir suivi le Tuto correctement .... . je referai à tête reposée. Pour le FTPS, je ne sais pas trop a priori ... .

@GrOoT64 parfait ! Pour l'accès root, je vérifie cela dans la journée. Je l'ai fait, je suis sûr que ça marche, mais .... là il faut que je régénère un jeu de clé .... je ne suis pas dispo ce matin .... . J'ai fait un peu trop de ménage depuis .....

bonjour @GrOoT64, de ce que je viens de regarder, sous DSM7, les packages sont gérés via "systemctl" : bruno@ds918blam:~$ systemctl status sshd ● sshd.service - OpenBSD Secure Shell server Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/sshd.service.d └─synorelay-service-handler.conf Active: active (running) since Wed 2021-05-12 17:14:51 CEST; 2 days ago Main PID: 8225 (sshd) CGroup: /sshd.slice/sshd.service ├─ 4420 sleep 1 ├─ 4481 systemctl status sshd ├─ 8225 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups ├─13125 sshd: bruno [priv] ├─13418 sshd: bruno [priv] ├─13419 sshd: bruno@pts/0 ├─13662 -sh ├─13732 sshd: bruno@notty ├─13733 sh -c while [ -d /proc/$PPID ]; do sleep 1;head -v -n 8 /proc/meminfo; head -v -n 2 /proc/stat /proc/version /proc/uptime /proc/loadavg /proc/sys/... └─13736 sshd: bruno@internal-sftp Mais si Synology a fait des utilitaires spécifiques, c'est qu'ils doivent bien faire quelque chose de plus ? Donc sous DSM7 il y a la commande Syno "synosystemctl" : bruno@ds918blam:~$ synosystemctl -h synosystemctl {COMMAND} ... Commands: start [--no-block] NAME... Start (activate) one or more units stop [--no-block] NAME... Stop (deactivate) one or more units enable NAME... Enable one or more unit files disable NAME... Disable one or more unit files restart [--no-block] NAME... Start or restart one or more units try-restart [--no-block] NAME... Restart one or more units if active reload [--no-block] NAME... Reload one or more units reload-or-restart [--no-block] NAME... Reload or restart one or more units reenable NAME... Reenable one or more unit files isolate [--no-block] NAME... Start one unit and stop all others mask [--runtime] NAME... Mask one or more units unmask [--runtime] NAME... Unmask one or more units uninstall NAME Remove units from system, as well as relating symlinks and flags daemon-reload Reload unit config get-default Get the name of the default target set-default NAME Set the default target get-enable-status NAME Get the enable status of given unit get-active-status NAME Get the active status of given unit get-load-status NAME Get the load status of given unit stop-service-by-reason REASON NAME... Stop one or more services by a reason start-service-by-reason REASON NAME... Start one or more services by a reason remove-service-reason REASON NAME... Remove reason for one or more services list-service-reason NAME List service reason get-unit-by-pid PID Get unit name that the pid belongs to list-service-by-mnt-path PATH List services using given mount path register-volume NAME VOLUME Register a volume for a unit package-register-volume NAME VOLUME Register a volume for a package unregister-volume NAME VOLUME Unregister a volume for a unit package-unregister-volume NAME VOLUME Unregister a volume for a package Donc dans ton cas 2 options a priori : via la commande native systemctl : systemctl restart sshd via la commande syno : synosystemctl restart sshd Cdt, bruno78 PS : et oui, le login root c'est toujours avec la clé ssh !

@RaZor83 merci pour ces évolutions. Si tu n'y vois pas d’inconvénient, elles seront intégrées (et te seront attribuées) dans ma prochaine édition du script (rien de planifié à ce jour). Cdt, Bruno78

Bonsoir, le script python pour le monitoring de la Freebox a été mis à jour, et est passé en version 061. Le Tuto a été mis à jour en première page. Je vous redonne le lien : https://github.com/bruno78310/Freebox-Revolution-Monitoring.git Les évolutions sont les suivantes : Prise en compte de l’agrégation de liens xdsl / lte-4g pour les Freebox Delta. Pour faire remonter ces compteurs, il faut invoquer le paramètre '-4' dans la liste des paramètres disponibles. Correction d'un bug lors de la demande de statistiques disques ('-D') sur une Freebox Mini4K qui n'a pas de disque. La demande faisait planter le script. Correction d'un bug lorsque l'état de la connexion est 'down' (paramètre 'state' lors de la requête sur la connexion) : dans ce cas, le script plantait. Désormais on positionne : media='None' ipv4='None' ipv6='None' ipv4_port_range=[0,0] Je remercie ici vivement @Galm et @Denisra76Frog qui m'ont prêté main forte pour valider cette évolution du script sur leur modèles respectifs de Fbox. Ainsi, le script est passé sur une Mini4K (fibre), une Delta (xdsl/4g) et une Révolution v2 (fibre). N'hésitez pas à me faire part de vos remarques. Cdt, bruno78