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.

Jeff777

Membres
  • Compteur de contenus

    1 608
  • Inscription

  • Dernière visite

  • Jours gagnés

    29

Activité de réputation

  1. Upvote
    Jeff777 a réagi à jacaj dans Installation Freebox Révolution/Onduleur Eaton   
    Bonjour,
    L'idée de Jef777 peut aussi consister à mettre une alim supplémentaire non Cpl qui alimentera la freebox serveur en courant secouru,
    Ex: https://www.amazon.fr/alimentation-freebox-revolution/s?k=alimentation+freebox+revolution

    Le boitier CPL alimenté par le 220V non secouru n'alimentera pas la Freebox serveur par le jack mais sera raccordé à elle par le câble réseau, pour envoyer la vidéo en CPL vers le boitier freebox TV.

    Branchement dans le cas de l'achat d'une alim ordinaire: (cette solution limite les problèmes d'appairages CPL multiples)
    220V secouru sortie onduleur > Alim 12V 5A du commerce >  Jack > Freebox serveur (la freebox reste allumée en cas de coupure secteur)
    Prise murale non secourue > Freeplug existant> Jack non raccordé + Cable réseau raccordé entre la sortie réseau du Freeplug et les ports réseau de la box serveur..
    La liaison CPL entre les deux boxes se fera sauf en cas de coupure secteur.
  2. Like
    Jeff777 a reçu une réaction de GrOoT64 dans [RESOLU] Aide connexion externe   
    Les dernières, tout cela c'est écrit dans le tuto sur le reverse proxy que je t'avis dit de suivre😏 pour l'installation de webstation.
     
     
    Si cette fois-ci cela ne fonctionne pas je vends mon NAS 😂
  3. Thanks
    Jeff777 a reçu une réaction de Didic dans [RESOLU] Aide connexion externe   
    Les dernières, tout cela c'est écrit dans le tuto sur le reverse proxy que je t'avis dit de suivre😏 pour l'installation de webstation.
     
     
    Si cette fois-ci cela ne fonctionne pas je vends mon NAS 😂
  4. Upvote
    Jeff777 a reçu une réaction de Sabre Wolf dans Présentation pour un nouveau   
    Bienvenue et à bientôt sur ce forum
  5. Like
    Jeff777 a reçu une réaction de GrOoT64 dans [RESOLU] Aide connexion externe   
    Bonjour 
    Avec ceci en htaccess :
     
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    RewriteCond %{HTTP_HOST} ^photo.ndd.tld$
    RewriteRule ^$ https://photo.ndd.tld/photo [L,R=301]
     
    Et un reverse :  https://photo.ndd.tld ==> iplocaledu NAS
    ça fonctionne bien  😉
  6. Upvote
    Jeff777 a reçu une réaction de niklos0 dans Récupération de données chiffrées d'un NAS ne démarrant plus   
    Un disque dur d'un NAS peut bien sûr contenir une sauvegarde d'un PC ou d'un autre NAS à condition qu'il ne s'agisse pas d'une synchronisation de l'original ou du miroir de l'original par RAID.
    Hyperbackup et Active Backup for Business sont des applications qui créent des sauvegardes sur NAS
  7. Upvote
    Jeff777 a réagi à mario2711 dans je n'arrive pas à désactiver la vérification en deux étapes   
    C'est bon j'ai trouvé la solution.
    En plus de désactiver la double vérification dans "utilisateurs", "avancé", il fallait en plus allait en haut à droite, cliquer sur le petit bonhomme, puis "perso" et enfin désactiver "activer la vérification en 2 étapes"
    😀
  8. Thanks
    Jeff777 a reçu une réaction de glattering dans Connexion externe marche .. ou pas.   
    Merci pour ton retour @breaker85 et c'est bien de l'avoir posté aussi sur ce sujet, ça évitera à ceux qui  le lise de se casser les dents 😊
    Et je me permet d'afficher le lien pour faciliter la recherche:
     
  9. Thanks
    Jeff777 a réagi à oracle7 dans [TUTO]Création d'un Certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh"   
    Bonjour,
    Objectif de ce tutoriel : Créer un certificat « Wilcard » Let’s Encrypt (LE) afin :
           d’une part, de prendre en compte tous les domaines de second niveau de votre domaine personnel,        et d’autre part, de s’affranchir de la limite fatidique de 256 caractères imposée par Synology pour les SAN (Subject Alternative Name – Autre nom de l’objet) lors de la création des certificats dans DSM. Pour mémoire, la méthode de création du certificat « wilcard » LE décrite dans le Tutoriel « Certificat TLS/SSL - Let's Encrypt "Wildcard" » de @unPixel utilisait le service ‘SSL For Free’. Malheureusement, ce service n’étant plus gratuit depuis le 18 mai 2020, il convenait alors pour moi de m’orienter sur un autre moyen pour obtenir un certificat « wilcard » LE et gratuit de surcroît.
    Nota : ‘SSL For Free’ fournit toujours gratuitement son service mais uniquement pour un seul nom de domaine du type « ndd.tld » (NomDeDomaine.Top-LevelDomain).
    En fouillant un peu la toile, j’ai fini par trouver cet autre moyen. Il est basé sur l’utilisation du client ACME via le Shell script « acme.sh » disponible sur GitHub.
    Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ...
    Sachez que c'est un mixte de différents tutoriels trouvés sur la toile, car aucun pris individuellement ne donnait complètement satisfaction vis-à-vis du but à atteindre et il fallait souvent s’adapter et/ou corriger en fonction de leurs contextes parfois légèrement différents.
    Je ne m’en cache pas, je n’ai pas réinventé la roue, vous retrouverez ici certaines explications directement extraites et traduites de ces tutoriels. Selon le cas, le lien vers l’original sera donné.
    Mais avant toutes choses, il convient pour mémoire, de faire un petit rappel contextuel.
    Depuis que Synology a introduit LE dans la gestion des certificats associés à ses NAS et Routeurs, beaucoup d'entre nous bénéficient du SSL gratuit et c’est très bien. D'un autre côté, beaucoup d'entre nous ne veulent pas exposer les ports 80 et 443 à Internet, y compris l'ouverture de ces ports sur le routeur.
    Malheureusement, l'actuelle implémentation Synology de LE ne prend en charge que la méthode de validation dite WEB, basée sur le protocole « HTTP-01 » qui nécessite d'exposer notamment le port 80 à Internet.
    Une alternative à cette non exposition est de passer par l’utilisation de la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode.
    Mais pour utiliser cette méthode de validation par DNS, il est obligatoire d’avoir la main sur la zone DNS du domaine concerné. En effet, LE vérifie la présence d’un enregistrement de type « TXT » sous la forme de « _acme‑challenge.votre-domaine.tld » contenant la valeur d’autorisation. Cet enregistrement permet de prouver que la personne qui demande le certificat, contrôle également la zone DNS du domaine en question.
    Il convient aussi de noter que le protocole « DNS-01 » est utilisé pleinement par les fonctions d’API (Application Programming Interface) développées par nos fournisseurs de domaines tels que OVH et que l’on va utiliser ici.
    Pour l’exemple, la méthode présentée ici, utilise les API de mon fournisseur OVH. Mais vous pouvez très bien utiliser les API d’un autre fournisseur car ACME prend en charge de nombreux autres services DNS. Il faudra alors adapter la méthode en fonction de ces autres fournisseurs. Rien de bien compliqué en soit, les paramètres diffèrent quelque peu mais le principe de mise en œuvre reste le même.
    Par ailleurs, l’utilisation du Shell script ‘acme.sh’ est rendu possible par le fait que nous pouvons accéder au NAS via une connexion SSH pour le configurer pour renouveler les certificats au lieu d'utiliser le tableau de bord WEB.
    Maintenant, cerise sur le gâteau si je puis dire, depuis peu Synology a introduit dans DSM le code nécessaire pour qu’il ne soit plus nécessaire d'exécuter le Shell script ‘acme.sh’ sur votre NAS pour renouveler le certificat. Le Shell script ‘acme.sh’ devra simplement être exécuté sur quelque chose (votre PC/Mac ou autre) qui a accès à l'interface d'administration de DSM. Du coup, les méthodes de déploiement du certificat généré sont considérablement simplifiées et c’est qui va être exploité dans la présente méthode.
    Voilà pour le discours préliminaire, on passe aux choses sérieuses …
    1         Pré-requis
    ·      Disposer d’un nom de domaine personnel chez OVH. ·      Attribuer l’@IP externe de votre Box/Routeur à votre nom de domaine personnel.
    Pour cela, se rendre sur l'espace client d'OVH. Une fois connecté :        Si vous avez une @IP fixe :           aller dans l'onglet : « Web / Domaines / votre-domaine.tld / Zone DNS »           vous devez avoir un enregistrement de type « A » dans le quel votre « votre-domaine.tld » pointe vers cette @IP fixe.           Si vous avez une @IP dynamique :            aller dans l'onglet : « Web / Domaines / votre-domaine.tld / DynHost »            vous devez avoir une ligne avec « votre-domaine.tld » qui a pour cible votre @IP du moment (i.e. l’@IP externe de votre Box/Routeur).           Ce même DynHost doit être également défini sur le NAS (« Panneau de configuration / Accès externe / DDNS » où le nom d’hôte est : « votre-domaine.tld ». 2         Installation du Shell script ‘acme.sh’
    L’installation du Shell script ‘acme.sh’ doit s’effectuer dans un répertoire qui n’est pas modifié/réinitialisé lors des mises à jour de DSM. Pour ce faire, on va donc créer un répertoire spécifique d’installation « Certs/Acme_install » sous « /volume1 » et surtout pas sous le répertoire « /root » qui lui est régulièrement « nettoyé » par le système. Ce répertoire « /root » est également utilisé par défaut par ACME. Ceci expliquant cela.
    ·      Sous Windows ouvrir une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP » ·      Sous Mac ouvrir une session SSH en lançant le « Terminal » puis tapez :        ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalié        sudo -i (pour passer en « root » - c'est la procédure normale). ·         EDIT : Il s'avère que passer sous « root » via un « sudo -i» sur PC comme sur Mac, génère une erreur dans l'exécution de la commande « ./acme.sh». Aussi, je vous invite à suivre le Tuto sur les "Accès SSH et ROOT via DSM6" de      @unPixel et ainsi de configurer un accès par le "vrai" « root ». Cela marche tout de suite bien mieux ...
    Nota 1 : Pour ma part sous Windows, je préfère l’utilisation de « WinSCP » à « PuTTY », tout simplement à cause de son interface graphique qui est très agréable de mon point de vue et aussi parce que l’on peut accessoirement directement sélectionner le texte affiché dans la Console pour le Copier/Coller ailleurs dans une autre application. C’est tout bête mais bien pratique au demeurant. Certes « PuTTY » le permet aussi mais je le trouve beaucoup moins souple de ce point de vue, et ce n’est que mon avis ...
     
    Nota 2 : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes.
    Je préfère prévenir même si c’est évident pour certains initiés …
    ·         Tapez successivement les commandes suivantes :    On crée le répertoire d’installation d’ACME : « /volume1/Certs/Acme_install » et on s’y place : $ cd /volume1 $ mkdir -p Certs/Acme_install
    $ cd Certs/Acme_install
           On télécharge ACME chez GitHub
    $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
     
           On décompresse le fichier téléchargé et on se place dans le répertoire qui a été automatiquement créé lors de la décompression : $ tar xvf master.tar.gz
    $ cd acme.sh-master
           On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle)
    $ ACME_HOME="/usr/local/share/acme.sh"
    $ CERT_HOME="/volume1/Certs"
    « CERT_HOME » est le répertoire où seront générés les fichiers du certificat. Vous pouvez l’adapter à besoins.
     
    $ ./acme.sh --install --nocron --home "$ACME_HOME" --cert-home "$CERT_HOME" --accountemail "email@gmail.com"  
    --nocron : spécifie de ne pas installer par défaut le « cron job ». Vous comprendrez de vous-même pourquoi plus loin.
    --home : désigne le répertoire « customisé » d’installation du Shell script ‘acme.sh’. C’est un répertoire dit « invariant ». C’est-à-dire qu’il n’est pas modifié par les mises à jour de DSM. Sinon par défaut, le script aurait été installé dans « ~/.acme.sh » où « ~ » correspond au répertoire ‘home’ de l’utilisateur « root » en l’occurrence : « /root ». Pour mémoire le répertoire « /root » est lui, dit « variant », donc sujet à modifications par les mises à jour de DSM.
    --cert-home : désigne le répertoire où seront générés les fichiers du certificat « wilcard » LE. Cette disposition permet de les sécuriser d’une part et d’autre part permet de les rendre accessibles facilement sans avoir à replonger dans les acarnes de DSM pour les retrouver en cas de besoin autre.
     
    Durant la courte installation, vous aurez certainement un message du style :
    It is recommended to install socat first.
    We use socat for standalone server if you use standalone mode.
    If you don't use standalone mode, just ignore this warning.
    Il faut savoir que ‘Acme.sh’ recommande l'installation du paquet « socat » pour gérer les certificats en mode standalone, mais comme nous n'allons pas utiliser ce mode, vous pouvez largement ignorer ce message.
    Vous trouverez donc, le dossier d'installation d’ACME dans le répertoire : « /usr/local/share/acme.sh ».
    Maintenant, il faut régénérer le fichier « .profile » de l'utilisateur courant (« root ») pour pouvoir utiliser immédiatement les commandes Shell. Pour cela, tapez simplement : $ source ~/.profile ·         Vérifier si besoin les droits d'exécution du fichier « acme.sh » : $ cd $ACME_HOME
    $ ls -al
    Normalement c’est bon mais si besoin, tapez : $ chmod a+x acme.sh

    ·         On active la mise à jour automatique du client (c’est préférable mais ce n’est pas une obligation) : $ ./acme.sh --upgrade --auto-upgrade
    Nota 1 : si vous souhaitez désactiver la mise à jour automatique d’ACME, tapez :
    $ ./acme.sh --upgrade --auto-upgrade 0
    Comme vous pouvez aussi commenter manuellement la ligne : AUTO_UPGRADE="1" dans le fichier « /usr/local/share/acme.sh/account.conf » par l’ajout du caractère « # » en tout début de ligne.
    Nota 2 : Si vous êtes curieux et que vous souhaitez voir toutes les commandes disponibles pour ACME, tapez :
    $ ./acme.sh --help
    NE PAS quitter la session SSH
    3         Configuration DNS
    3.1        Création des clés
    Pour générer un certificat « wilcard » et pouvoir le renouveler automatiquement, on va donc utiliser l’API d’OVH.
    Pour ce faire, on va créer une application dans l’API qui va nous permettre de générer trois clés nommées respectivement : « application key », « application secret » et « consumer key ».
    Il est aussi une bonne pratique de sécurité que de limiter ce qu'une clé API donnée peut faire, dans le cas où elle serait perdue, volée ou que quelque chose de mal se produirait et ce, pour en limiter les dommages potentiels.
    Cela tombe bien, les clés API OVH peuvent être limitées à une zone de domaine spécifique à l'aide d'un mécanisme de modèle simple. On va donc en profiter pour restreindre une clé API OVH à la gestion de « votre-domaine.tld », en utilisant les paramètres suivants :
    GET=/domain/zone/votre-domaine.tld/*
    &POST=/domain/zone/votre-domaine.tld/*
    &PUT=/domain/zone/votre-domaine.tld/*
    &GET=/domain/zone/votre-domaine.tld
    &DELETE=/domain/zone/votre-domaine.tld/record/*
    Il est clair que cela peut facilement être personnalisé pour prendre en charge un ou plusieurs domaines si le besoin en est. Je vous renvoie à la documentation en ligne d’OVH pour plus de détails.
    ·         On se rend donc sur l’API d’OVH en saisissant l’URL suivante dans un navigateur WEB : https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/*
    Nota : Dans le cas où vous ne souhaiteriez pas restreindre la gestion de la clé API OVH à votre domaine, il suffit simplement d’utiliser les paramètres suivants :
    ?GET=/domain/zone/*
    &POST=/domain/zone/*
    &PUT=/domain/zone/*
    &DELETE=/domain/zone/*/record/*
    o   L’URL à utiliser pour aller sur l’API d’OVH, est alors : https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/*
     
    ·         Donc avec le premier cas, on arrive sur l’écran suivant :
    Nota : Dans le second cas l’écran est très similaire, je vous laisse vous adapter.      

     
    ·         On saisit les informations : o   Account ID : votre identifiant principal de connexion chez OVH
    Nota : Si vous utilisez votre @Mail vous aurez un message d’erreur lors de la création des clés.
    o   Password : votre mot de passe de connexion chez OVH.
    o   Script name : Ce que vous voulez (par ex : « Synology_acme_sh ») mais avec que des caractères, pas d’espaces ni de points et pas de caractères spéciaux sinon cela bloque.
    o   Script description : Ce que vous voulez (par ex : « Certificat wilcard LE – ACME ».
    o   Validity : Dans le popup sélectionnez l’item « Unlimited ».
     
    ·         On clique en fin sur le bouton « Create keys ».
      ·         On obtient l’écran suivant, où il convient immédiatement de copier les clés et de les sauvegarder dans un fichier « .txt » :
    3.2        Retour dans la session SSH
    ·         Taper successivement les commandes suivantes : $ export OVH_END_POINT=ovh-eu $ export OVH_AK="votre application key" $ export OVH_AS="votre application secret" $ export OVH_CK="votre consumer key" 4         Création du certificat
    Avant de créer effectivement le certificat il convient de préciser un point sur la méthode de chiffrement associée à la génération du certificat LE.
    Sans aucun paramètre spécifique, ACME utilise une clé de chiffrement de type RSA fixée à 2048 bits par défaut.
    Dans notre cas, on va directement forcer cette clé RSA à 4096 bits pour renforcer le niveau de sécurité, ce qui se fait par l’emploi du paramètre « -- keylength 4096 » dans la commande de création du certificat.
    Maintenant pour ceux qui le souhaitent, on peut aussi passer en mode « paranoïaque » et poussez plus loin les choses en adoptant un chiffrement basé sur une clé ECDSA qui elle s’appuie sur des courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes et peut-être bien plus sécures que les clés RSA et sachant aussi que ces dernières sont déjà bien suffisantes pour nos besoins courants.
    Pour comparaison, une clé ECDSA 256 bits est équivalente à une clé RSA 3072 bits, et une clé ECDSA 384 bits est équivalente à une clé RSA 7680 bits !
    À noter que LE reconnait les courbes elliptiques P-256 et P-384 mais le P-521 n'est pas encore reconnu.
    Donc dans ce dernier cas de figure, le paramètre à employer serait par exemple : « -- keylength ec-394 ». A vous de voir …
     
    Bon, il est maintenant vraiment temps de créer le certificat « wilcard » LE pour « votre-domaine.tld » :
    ·         Tapez successivement les commandes suivantes : $ cd $ACME_HOME
    $ export CERT_DOMAIN="votre-domaine.tld" $ export CERT_WDOMAIN="*.votre-domaine.tld" $ export CERT_DNS="dns_ovh" $ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"  
    Le processus de création du certificat se déroule et affiche un message du type :
    /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"
    [Sun May 24 22:42:07 CEST 2020] Create account key ok.
    [Sun May 24 22:42:07 CEST 2020] Registering account
    [Sun May 24 22:42:08 CEST 2020] Registered
    [Sun May 24 22:42:08 CEST 2020] ACCOUNT_THUMBPRINT='l7IOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfro'
    [Sun May 24 22:42:08 CEST 2020] Creating domain key
    [Sun May 24 22:42:13 CEST 2020] The domain key is here: /volume1/Certs/votre-domaine.tld/ votre-domaine.tld.key
    [Sun May 24 22:42:13 CEST 2020] Multi domain='DNS:votre-domaine.tld,DNS:*.votre-domaine.tld'
    [Sun May 24 22:42:13 CEST 2020] Getting domain auth token for each domain
    [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='votre-domaine.tld'
    [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='*.votre-domaine.tld'
    [Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain:  _acme-challenge.votre-domaine.tld
    [Sun May 24 22:42:15 CEST 2020] Using OVH endpoint: ovh-eu
    [Sun May 24 22:42:15 CEST 2020] Checking authentication
    [Sun May 24 22:42:16 CEST 2020] Consumer key is ok.
    [Sun May 24 22:42:16 CEST 2020] Adding record
    [Sun May 24 22:42:17 CEST 2020] Added, sleep 10 seconds.
    [Sun May 24 22:42:27 CEST 2020] The txt record is added: Success.
    [Sun May 24 22:42:27 CEST 2020] Adding txt value: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain:  _acme-challenge.votre-domaine.tld
    [Sun May 24 22:42:27 CEST 2020] Using OVH endpoint: ovh-eu
    [Sun May 24 22:42:27 CEST 2020] Checking authentication
    [Sun May 24 22:42:27 CEST 2020] Consumer key is ok.
    [Sun May 24 22:42:27 CEST 2020] Adding record
    [Sun May 24 22:42:28 CEST 2020] Added, sleep 10 seconds.
    [Sun May 24 22:42:38 CEST 2020] The txt record is added: Success.
    [Sun May 24 22:42:38 CEST 2020] Let's check each dns records now. Sleep 20 seconds first.
    [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.jcrobin56.fr
    [Sun May 24 22:42:58 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success.
    [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld
    [Sun May 24 22:42:59 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success.
    [Sun May 24 22:42:59 CEST 2020] All success, let's return
    [Sun May 24 22:42:59 CEST 2020] Verifying: votre-domaine.tld
    [Sun May 24 22:43:02 CEST 2020] Success
    [Sun May 24 22:43:02 CEST 2020] Verifying: *.votre-domaine.tld
    [Sun May 24 22:43:06 CEST 2020] Success
    [Sun May 24 22:43:06 CEST 2020] Removing DNS records.
    [Sun May 24 22:43:06 CEST 2020] Removing txt: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld
    [Sun May 24 22:43:06 CEST 2020] Using OVH endpoint: ovh-eu
    [Sun May 24 22:43:06 CEST 2020] Checking authentication
    [Sun May 24 22:43:06 CEST 2020] Consumer key is ok.
    [Sun May 24 22:43:09 CEST 2020] Removed: Success
    [Sun May 24 22:43:09 CEST 2020] Removing txt: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld
    [Sun May 24 22:43:09 CEST 2020] Using OVH endpoint: ovh-eu
    [Sun May 24 22:43:09 CEST 2020] Checking authentication
    [Sun May 24 22:43:09 CEST 2020] Consumer key is ok.
    [Sun May 24 22:43:13 CEST 2020] Removed: Success
    [Sun May 24 22:43:13 CEST 2020] Verify finished, start to sign.
    [Sun May 24 22:43:13 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxx/xxxxxxxxxxxxxx
    [Sun May 24 22:43:14 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5c1f
    [Sun May 24 22:43:15 CEST 2020] Cert success.
    -----BEGIN CERTIFICATE-----
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    -----END CERTIFICATE-----
    [Sun May 24 22:43:15 CEST 2020] Your cert is in  /volume1/Certs/votre-domaine.tld/votre-domaine.tld.cer
    [Sun May 24 22:43:15 CEST 2020] Your cert key is in  /volume1/Certs/ votre-domaine.tld/votre-domaine.tld.key
    [Sun May 24 22:43:15 CEST 2020] The intermediate CA cert is in  /volume1/Certs/votre-domaine.tld/ca.cer
    [Sun May 24 22:43:15 CEST 2020] And the full chain certs is there:  /volume1/Certs/votre-domaine.tld/fullchain.cer
     
    Voilà déjà une bonne chose de faite …
    NE PAS quitter la session SSH
    5         Déploiement du certificat
    Comme expliqué en préambule, Synology nous a facilité la vie pour le déploiement des fichiers du(des) certificat(s) généré(s). Cela se passe par l’emploi du « Synology DSM deployhook ».
    5.1        Cas de la double authentification
    Si vous n’utilisez pas la double authentification pour vous connecter à votre NAS, passez directement au §5.2 ci-dessous.
    Mais avant de réaliser le déploiement effectif du certificat, il y a encore un point préciser car il y a un paramètre supplémentaire à prendre en compte dans le cas où, comme moi vous utilisez la double authentification pour vous connecter à votre NAS. En effet, si on ne renseigne pas ce paramètre, le processus de double authentification viendrait bloquer le déploiement du certificat tel qu’il sera décrit ci-après. Ce serait dommage convenez-en.
    Donc, habituellement lorsqu’on se connecte au NAS après avoir saisi son id/pseudo et son mot de passe, la double authentification réclame la saisie d’un code à six chiffres que l’on obtient à partir d’une application tierce installée idéalement sur un smartphone/iPhone. Pour n’en citer que quelques-unes, il y a : « FreeOTP Authenticator », « Google Authenticator », « Microsoft Authenticator », etc … (le choix est grand ! - pour la mise en place de la double authentification sur le NAS, reportez-vous à l’excellent Tutoriel de @Fenrir sur la sécurisation des accès au NAS).
    Bref, on récupère et on saisit donc ce code à six chiffres et on coche la case « Faire confiance à ce périphérique ». Cette dernière action a pour effet caché de créer un « cookie » dans votre navigateur qui lui, évite par la suite que ce code à six chiffres, ne vous soit systématiquement demandé à chaque connexion.
    Ce « cookie » stocke en interne un code nommé « DID » dont il nous faut récupérer la valeur pour alimenter le paramètre suscité.
    Pour récupérer la valeur de ce code « DID », normalement un simple clic gauche sur le cadenas situé à gauche de la barre d’URL du navigateur, suivi de la sélection de l’item « cookies » permet d’afficher ce code « DID ». Sauf que cela ne marche pas avec le navigateur FireFox. Pour contourner le problème, j’ai installé l’excellent module complémentaire « Cookie Quick Manager » dans FireFox. Ensuite on procède ainsi :
    ·         Se placer sur la page de connexion ou si déjà connecté, sur la page du navigateur affichant le bureau DSM de votre NAS. ·         Dans le popup de « Cookie Quick Manager », clic gauche et sélectionner l’item « Rechercher les cookies pour : URL de la page suscitée ». Cela peut-être selon : « https://nom-du-nas.ndd.tld » ou http://@IP_du_NAS:5000 ou encore « https://@IP_du_NAS:5001 ». ·         Une nouvelle page s’ouvre dans le navigateur, vous montrant tous le détail du cookie associé à la page du NAS. ·         Dans la partie droite de cette page, on trouve la valeur du fameux code « DID ». ·         Sélectionnez et Copiez cette valeur et refermez la page du cookie. ·         Revenez sur la session SSH et tapez la commande suivante en y collant la valeur du « DID » : $ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx 5.2        Réalisation du déploiement du certificat
    Nota préliminaire : Tout ce qui suit présume que vous n’avez pas quitté la présente session SSH. Sinon, il faut réexporter toutes les variables définies précédemment. Sans quoi rien ne fonctionnera correctement ! Ce serait dommage, non ?
    Maintenant, deux cas de figure se présentent selon que l’on procède à un déploiement du nouveau certificat :
    ·         avec un mode « Annule et remplace » du certificat existant marqué « par défaut », ·         ou que l’on se contente d’ajouter simplement le nouveau certificat à la liste existante de vos certificats. Vous avez le choix, c’est vous qui décidez …
    5.2.1        Mode « annule et remplace » du certificat par défaut
    Rappel : Ici on va ECRASER le certificat marqué par défaut dans le tableau de bord de DSM. Il n’existera plus !!! Vous êtes prévenus …
    ·         Dans la session SSH tapez successivement les commandes suivantes : o   Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ».
    $ pwd o   Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes :
    # export SYNO_Scheme="http" Par défaut : « http » mais on peut fixer à « https » # export SYNO_Hostname="localhost" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Port="5000" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS. o   On poursuit les définitions de variables d’environnement :
    Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse.
    $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir remplacer le certificat par défaut, il est nécessaire de spécifier une chaîne vide pour ce paramètre. Ne me demandez pas pourquoi ! (si un « initié » sait, je corrigerai en conséquence avec l’explication du pourquoi).
    $ export SYNO_Certificate="" ·         Et on déploie enfin le certificat …
    $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm  
    5.2.2        Mode « ajout » du nouveau certificat
    Ici, on va simplement ajouter le nouveau certificat à la liste des certificats éventuellement déjà présents sur le NAS.
    Le processus est sensiblement le même que celui décrit au §5.2.1 ci-dessus.
    ·         Dans la session SSH tapez successivement les commandes suivantes : o   Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ».
    $ pwd o   Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes :
    Par défaut : « http » mais on peut fixer à « https »
    # export SYNO_Scheme="http" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront.
    # export SYNO_Hostname="localhost" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS
    # export SYNO_Port="5000" o   On poursuit les définitions de variables d’environnement :
    Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse.
    $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123'  
    La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir ajouter le nouveau certificat, il est nécessaire de spécifier une chaîne non vide pour ce paramètre. Là, cela paraît évident … (Quoi que …)
    Vous nommez votre certificat comme bon vous semble. Pour ma part je lui donne le nom qui précise mon domaine « ACME_Wilcard_LE_*.ndd.tld » pour plus de clarté. Encore une fois, c’est vous qui voyez …
    $ export SYNO_Certificate="Nom_du_certificat" o   Une dernière variable d’environnement :
    Par défaut : ce paramètre est sur « off » et n’est pas enregistré mais on peut le fixer à « 1 » pour indiquer au système de créer le certificat s’il n’existe pas déjà.
    $ export SYNO_Create=1
     
    ·         Et on déploie enfin le certificat …
    $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm Dans cette commande, pour le cas où vous le souhaiteriez, on peut préciser un domaine de second niveau. La commande est alors :
    $ ./acme.sh --deploy -d "secondNiv.$CERT_DOMAIN" --deploy-hook synology_dsm
    Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés.
    Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence.
     
    Toujours est-il, le nouveau certificat est maintenant visible dans « Panneau de configuration / Sécurité /Certificat » de DSM :

    Ici par défaut on constate que :
    ·         d’une part le nouveau certificat a été automatiquement marqué pour une utilisation « par défaut », ·         et d’autre part il n'a pas repris les assignations aux services qui existaient pour le certificat que j’avais précédemment marqué par défaut. Donc il vous faut reprendre ces assignations manuellement. Toujours pareil, vous les adaptez à votre besoin … Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe !
     
    6         Configurer le renouvellement du certificat
    Maintenant que le certificat « wilcard » LE a été créé et déployé sur le NAS, il faut assurer son renouvellement à l’échéance fatidique de 3 mois. En fait, cette échéance est variable dans le sens où selon la date de génération du certificat il peut se passer entre 89, 90, 91 et 92 jours. Par sécurité, on demandera donc le renouvellement tous les 85 jours.
    Mais avant toute choses, sachez qu’Il n'est pas conseillé de configurer directement un « cron job » personnalisé car le conseiller de sécurité DSM va rapidement vous rappeler à l’ordre et vous dira que vous avez un avertissement critique concernant un ou des cron job(s) inconnu(s).
    Donc pour ce faire, on va configurer une tâche dans le planificateur de tâches de DSM.
    ·         Dans « Panneau de configuration / Planificateur de tâches », cliquer sur le bouton « Créer » et sélectionner dans le popup : « Tâche planifiée / Script défini par l’utilisateur »
    ·         Dans la fenêtre « Créer une tâche » onglet « Général » nommez la tâche à exécuter périodiquement. Par exemple : « RenewCertif_W_LE ». L’utilisateur doit être « root » et la case « Activé » est cochée.
    ·         Dans l’onglet « Paramètres de la tâche » : o   Pour la partie « Paramètres généraux » : si vous voulez recevoir par eMail les détails d’exécution de la tâche : cochez la case correspondante et saisissez votre @Mail. Vous pouvez aussi décider de ne recevoir ces eMails uniquement si l’exécution de la tâche se termine de façon anormale. Dans ce cas cochez la case correspondante.
    o   Pour la partie « Exécuter la commande » : saisir la commande suivante :
    bash /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/
    ·         Dans l’onglet « Programmer » : o   Sélectionner « Exécuter à la date suivante »
    o   Saisir via le calendrier une date plus 85 jours suivant la date de création du présent certificat.
    o   Dans le popup sous cette date de prochaine exécution, sélectionner l’item « Répéter tous les trois mois ».
    o   Dans la zone « Temps » : laisser les valeurs par défaut.

    ·         Valider l’ensemble de votre paramétrage en cliquant sur le bouton « OK ». 7         En cas de problème suite à une mise à jour de DSM
    En cas de problème suite à une mise à jour de DSM, on peut réparer l’environnement ACME en exécutant les commandes suivantes dans une session SSH sous l’utilisateur « root » :
    $ cd /usr/local/share/acme.sh
    $ ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh
     
    Vous pouvez aussi ajouter la ligne suivante dans le fichier « /root/.profile » et régénérer le « .profile » en tapant :
    . "/usr/local/share/acme.sh/acme.sh.env" $ source /root/.profile 8         Arrêter le renouvellement du certificat
    Pour arrêter le renouvellement d’un certificat, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes pour supprimer le certificat de la liste de renouvellement :
    $ cd /usr/local/share/acme.sh
    $ ./acme.sh --remove -d votre-domaine.tld
     
    Les fichiers « .cert » et « .key » de votre certificat ne sont pas supprimés du disque.
    Vous pouvez supprimer le répertoire correspondant (par exemple : « /volume1/Certs/votre-domaine.tld ») par vous-même.
    9         Un dernier truc utile
    Vous pouvez éventuellement avoir besoin de convertir votre certificat en un fichier « .p12 » ou « .pfx » exploitable sous Android. C’est utile par exemple, pour un client VPN installé sur le smartphone.
    Dans ce cas, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes :
    $ ACME_HOME="/usr/local/share/acme.sh"
    $ CERT_HOME="/volume1/Certs"
    $ cd $ACME_HOME
    $ ./acme.sh --toPkcs -d votre-domaine.tld
     
    Enter Export Password:
    Verifying - Enter Export Password:
    [Mon May 25 20:00:28 CEST 2020] Success, Pfx is exported to: /volume1/Certs/votre-domaine.tld/votre-domaine.tld.pfx
    « Password » est le mot de passe utilisé pour ouvrir la session SSH.
     
    Voilà c’est fini, profitez bien de votre certificat « wilcard » Let’sEncrypt !!! GRATUIT !!! et ne nécessitant plus d’ouvrir les ports 80 et/ou 443 sur votre NAS pour son renouvellement. À l’usage, on en oublierait presque la chose …
    Le fichier ".pdf" de cette procédure : Creation_Certif_Wilcard_LE_avec_ACME_20200523.pdf
    Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ...
    Merci à @maxou56 pour ses compléments d’informations liées au monde Mac.
    Cordialement
    Oracle7😉
     
  10. Thanks
    Jeff777 a réagi à bruno78 dans [TUTO] Monitorer sa Freebox Revolution   
    Bonjour @Jeff777
    Pour l'afficher : Type=Number, Unit=Duration, Decimals=1

    Bruno78
  11. Upvote
    Jeff777 a reçu une réaction de EVOTk dans Duo de NAS et Onduleur   
    Bonjour,
    Oui avec le logiciel gratuit WiNUT
    Je ne retrouve plus le tuto mais il suffit de programmer Winut sur le PC que tu veux arrêter. 
    ça marche très bien, j'ai fait des essais avec 7 minutes de délais pour sauvegarder mes documents. Si rien est fait, au bout de cette période mon PC et 2 NAS sont arrêtés automatiquement en toute sécurité. Puis box et routeur alimentés également par la batterie s'arrêtent.
    Trouvé : 
     
    https://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/WinNUT.shtml
     
  12. Like
    Jeff777 a reçu une réaction de fab&cler dans Duo de NAS et Onduleur   
    Bonjour,
    Oui avec le logiciel gratuit WiNUT
    Je ne retrouve plus le tuto mais il suffit de programmer Winut sur le PC que tu veux arrêter. 
    ça marche très bien, j'ai fait des essais avec 7 minutes de délais pour sauvegarder mes documents. Si rien est fait, au bout de cette période mon PC et 2 NAS sont arrêtés automatiquement en toute sécurité. Puis box et routeur alimentés également par la batterie s'arrêtent.
    Trouvé : 
     
    https://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/WinNUT.shtml
     
  13. Like
    Jeff777 a reçu une réaction de Jeff21 dans Présentation Jeff21   
    Salut @Jeff21
    Bienvenue sur ce forum où tu ne te sentiras pas seul. Il y a bien une dizaine de Jeff 😅
     
  14. Upvote
    Jeff777 a reçu une réaction de GrOoT64 dans [TUTO] DNS Server   
    Parfois si tu as atteints le maximum de renouvellement autorisés (5) dans la semaine écoulée tu ne peux plus créer de nouveaux certificats et effectivement le message n'est pas toujours clair sur le motif de refus.
    Si c'est le cas, il ne te reste plus qu'a attendre et réessayer plus tard.
    https://letsencrypt.org/docs/rate-limits/
  15. Thanks
    Jeff777 a réagi à bruno78 dans [TUTO] Monitorer sa Freebox Revolution   
    Bonjour,
    j'ai donc continué à chercher ... . Premier constat : l'exit code n'est pas fiable. Certains containers le positionnent, d'autre non; difficile de se baser dessus. Par ailleurs, il faut laisser remonter tous les états de containers via telegraf.
    Donc :
    modification du fichier de configuration de telegraf : telegraf.conf. la section "input plugin" / # # Read metrics about docker containers / [[inputs.docker]], décommenter la ligne contenant les états à charger : container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] sur grafana, on crée une requête chargeant le PID, le uptime et l'exitcode.
    On obtient quelque chose comme ceci (après mise en forme des colonnes) avec le PID entre autre.
    Ensuite je stoppe manuellement 2 containers (pour montrer la différence de comportement de l'exit code)
    On voit que l'exit code reste à 0 pour l'un, alors qu'il est positionné à 137 pour l'autre. Par contre les 2 remontent "0" comme PID
    On peut agrémenter d'un petit recap, par exemple :

    Je relance les 2 containers : et je retrouve bien mon affichage complet, sans doublon, avec les nouveaux PID pour les containers relancés.
     
    Bruno78
     
     
  16. Like
    Jeff777 a reçu une réaction de Derski dans Bonjour, débutant en approche...   
    Bienvenue @Derski
    Super, tu vas faire baisser la moyenne d'âge des membres 😄
  17. Upvote
    Jeff777 a réagi à bruno78 dans [TUTO] Monitorer sa Freebox Revolution   
    Bonjour,
    alors effectivement, si on utilise la table globale ifTable, les réferences docker sont "codées", du style "docker-e9f01980". Par contre, si on prend les données à partir de "docker_container_net", pas de problème.

     
    Par contre je tourne en rond sur un autre type de monitoring : je souhaite avoir un monitoring global des containers dockers : un pavé synthétique vert/en marche ou rouge/arret pour chaque container ..... Quelles variables utiliser ? comment visualiser sur grafana ? comment as-tu codé ton pavé "container overview" ?
    Bruno78
  18. Upvote
    Jeff777 a réagi à bruno78 dans [TUTO] Monitorer sa Freebox Revolution   
    @Jeff777,
    intéressant le problème ! Je parie que dans tes données (noms de stations, ...) tu as des caractères accentués .... ? 🙂
    Je te propose alors la choses suivante :
    dans ton docker telegraf, il faut installer le module python unidecode : # pip install unidecode root@fbx_telegraf:/usr/local/py# pip install unidecode Collecting unidecode Downloading Unidecode-1.1.1-py2.py3-none-any.whl (238 kB) |################################| 238 kB 2.9 MB/s Installing collected packages: unidecode Successfully installed unidecode-1.1.1 root@fbx_telegraf:/usr/local/py# tu utilises le script suivant : freebox_053_d1.pyfreebox_053_d1.py avant de le configurer dans telegraf.conf, tu peux déjà simplement le charger dans /usr/local/py et le lancer à la main comme pour les tests précédants: python3 freebox_053_d1.py -XW ce script contient la suppression des caractères accentués selon ton retour, je l'intègrerai (ou pas) dans une nouvelle version de script
  19. Thanks
    Jeff777 a reçu une réaction de .Shad. dans [TUTO] Monitorer sa Freebox Revolution   
    Du bon et du moins bon.
    Ce qui est bien c'est que je suis arrivé au bout du tuto , que mon dasboard nas fonctionne toujours et que influxdb reçoit bien de nas_telegraf et fbx_telegraf le tout avec un seul conteneur telegraf :
    [httpd] 172.18.0.4 - nas_telegraf [09/May/2020:08:59:00 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 52b773e6-91d3-11ea-81bc-0242ac120003 638407
    [httpd] 172.18.0.4 - fbx_telegraf [09/May/2020:08:59:00 +0000] "POST /write?consistency=any&db=fbx_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 52b6a9dd-91d3-11ea-81bb-0242ac120003 643651
    [httpd] 172.18.0.4 - fbx_telegraf [09/May/2020:08:59:10 +0000] "POST /write?consistency=any&db=fbx_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 58abe7a6-91d3-11ea-81bd-0242ac120003 909981
    [httpd] 172.18.0.4 - nas_telegraf [09/May/2020:08:59:10 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 58ad605c-91d3-11ea-81be-0242ac120003 901069
     
    Ce qui est moins bien c'est que le dashboard freebox affiche toujours nodata🙄
    Et là au moment où j'écris, en vérifiant une dernière fois,  je reçois enfin des données ! Pourtant telegraf dans les log affiche toujours une erreur :
     
      2020-05-09T09:18:51Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):...
    2020-05-09T09:19:01Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):...
    2020-05-09T09:19:11Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):...
     
    Mias ça s'est un peu décoincé et je me souviens que j'avais eu le même phénomène avec le dashboard du NAS.

    😎
    A partir de là je crois que je vais m'en sortir. Merci à @bruno78 et @.Shad. . Super forts !
     
  20. Thanks
    Jeff777 a réagi à .Shad. dans [TUTO] Monitorer sa Freebox Revolution   
    Ça me semble bon, pense bien à créer les dossiers py et log dans le dossier telegraf.
    Et t'assurer que ton NAS accepte les connexions depuis le sous-réseau de ta Freebox.
  21. Thanks
    Jeff777 a réagi à bruno78 dans [TUTO] Monitorer sa Freebox Revolution   
    Pas de problème. Je m'absente jusqu'en fin de matinée ....
  22. Upvote
    Jeff777 a reçu une réaction de .Shad. dans [TUTO] Monitorer sa Freebox Revolution   
    De retour sur l'ouvrage. J'ai démarré les 3 conteneurs :

    Je continue le tuto.
    Edit : j'ai fini la partie NAS/UPS/Docker   j'ai importé mondashboard à nouveau fonctionnel.
    La suite demain.....
  23. Upvote
    Jeff777 a reçu une réaction de pluton212+ dans [Résolu] Connexion Administrateur impossible   
    Je n'ai pas tout compris sur ton problème mais l'essentiel est que tu as pu le résoudre.
    Bonne continuation
  24. Thanks
    Jeff777 a réagi à Brunchto dans Journal des connexions   
    Je présume quand même que les règles du firewall sont appliquées en amont du reverse proxy.
     
  25. Thanks
    Jeff777 a reçu une réaction de GrOoT64 dans version compatible ou pas ?   
    Oui c'est urgent de le changer tant qu'il y en a encore un d'intègre. Bien vu @GrOoT64