bruno78

@Fabe56, as-tu une sauvegarde complète de tes données ?

Merci @PPJP, je vais donc refaire des tests un peu plus complets ce weekend, en ne redémarrant que les packages (isPkg=True). Bruno78

ouais, en me relisant, j'avoue ne pas comprendre ce que j'ai écrit ou voulu dire. Dsl, trop confus. J'essayai, j'imagine, de comprendre pourquoi DSM indique 1 disque en panne, et 2 disques à réparer .... .

@Fabe56, je ne suis pas spécialiste du SHR, mais j'analyse comme suit (avec un vocabulaire intuitif, les spécialistes me pardonneront) : si tu regardes bien, tu as 1 disque en panne, mais 2 disques à réparer. en fait, ton volume SHR est composé de 3 "unités" de 4Go : les 2 disques de 4Go, et la dernière "unité" est composée par les 2 disques 2Go qui représenteraient ensembles le 3ème disque 4Go. je suppose que si on allait voir les tables de partitions des différents disques, cela se verrait d'une façon ou d'une autre. je ne vois pas d'autre méthode pour le DSM de construire un volume SHR de 7.2To avec la combinaison de disques dont tu disposes. Donc : as-tu un backup externe de tes données ?? sinon, il est temps d'en faire un ! ensuite, si ma vision est exacte, cela veut dire que tu peux sortir les 2 disques de 2Go : ton volume SHR sera en mode dégradé, mais il devrait toujours être accessible et operationnel à ce moment, voir ce que demande DSM pour reparer le volume SHR, et en particulier si un troisieme disque de 4Go fait l'affaire ou pas ? je ne vois pas pourquoi il refuserai .... J'insiste : avant toute chose : t'assurer d'avoir sauvegardées toutes tes données. et peut-être attendre un second avis, plus spécialisé, sur ce forum

@oracle7, là, c'est au-delà de mes connaissances. je ne peux faire que des suppositions. Et dans le doute, je redémarre tout ce qui touche au certificat .... mais c'est un peu bourrin ! encore des essais à faire (et là tu m'as donné une nouvelle piste à explorer .... 🙂 )

Hello, j'ai aussi par exemple le cas d'AudioStation : "display_name" : "AudioStation - audio", "isPkg" : false, "owner" : "root", "service" : "AudioStation", "subscriber" : "AppPortal" }, { "display_name" : "AudioStation - 45000", "isPkg" : false, "owner" : "root", "service" : "AudioStation_AltPort", "subscriber" : "AppPortal" isPkg est à "false", et pourtant AudioStation est bien un package. Je me demande que faire dans ce cas ....??? redemarrage ? Je peux tester 1 par un, pour ceux qui sont configurés chez moi, quoi faire (si redemarrage necessaire ou pas), mais je préfèrerai une règle générale, connaitre le principe de la mécanique mise en place. Sinon c'est difficilement généralisable.

Bonjour Fabe56 et bienvenu sur ce forum, un petit tour par la case "présentation" sera appréciée pour mieux connaitre ta configuration et ainsi permettre de mieux te répondre. Peux-tu ici détailler la configuration de tes disques ? (volumes, groupes de stockage, ...) afin de mieux cerner ta config ? Ainsi que les erreurs que DSM remonte ? Bruno78

Bonjour @PPJP, @oracle7, je n'ai pas encore testé le script de @PPJP. Je comprends bien le redémarrage des packages (IsPkg=true) et la distribution des fichiers *.pem du nouveau certificat. Je suis arrivé au même résultat. Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false) ? Par exemple, pas de redémarrage de smbftpd/ftpd ou de ReverseProxy/a0c1ca98-2ef5-4c98-85c1-xxxxxx ? Dans ces cas là on enregistre bien les nouveaux *.pem, mais pas de redémarrage ? Merci de votre éclairage avisé Bruno78

Bonjour @PPJP, inutile de préciser que je vais regarder de près ce script. Merci pour ce travail dont je suis bien incapable (et j'ai assez peu de temps libre en ce moment , donc ca traine ) De mon côté, j'étais (je suis encore ... ) bloqué à l'étape de récupération de la liste des packages concernés et actifs, puis à leur redemarrage ... en essayant d'exploiter la sortie de la commande # synoservicecfg --status .... et c'est galère !

@vincentbls oui ca doit passer manuellement. Sauvegarde tes anciens fichiers *.pem avant. Ensuite, je ne suis pas certain de la nécessité de redemarrer, ou pas, nginx. Il me semble avoir constaté que cela est pris en compte même sans redemarrer nginx, ... mais bon au cas ou ....

@vincentbls, oui, si on regarde sur l'interface graphique du DSM (securité > certificat), le certificat est installé et on y voit les services associés. Maintenant si tu effaces le cache de ton navigateur, et que tu recharges le site en question, puis que tu examines le certificat utilisé par le navigateur, je suis prêt à parier que c'est toujours l'ancien (verifie par exemple la date d'expiration). En fait il en est ainsi, pour un certificat web, car dans la procedure tu n'as pas mis à jour les fichiers *.pem dans le repertoire /usr/local/etc/certificate/WebStation/vhost_xxxxx correspondant. Ce sont toujours les anciens fichiers.

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 ?