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.

PPJP

Membres
  • Compteur de contenus

    375
  • Inscription

  • Dernière visite

  • Jours gagnés

    3

PPJP a gagné pour la dernière fois le 19 octobre 2019

PPJP a eu le contenu le plus aimé !

À propos de PPJP

  • Rang
    Chevalier des Syno
  • Date de naissance 19/07/1949

Profile Information

  • Gender
    Male
  • Location
    Penn Ar Bed
  • Interests
    Ma Bro

Visiteurs récents du profil

1 843 visualisations du profil
  1. @oracle7 Je vais également essayer de répondre point à vos remarques Tout d'abord, je tiens à que je n'utilise pas acme et que je ne l'ai que rapidement consulté lorsque je suis intervenu sur le tuto de unPixel. Le seul problème à l'époque était le non redémarrage de quelques paquets, car je n'avais pas pris le temps de creuser aussi profondément que ne l'a fait @bruno78 (bravo) sur les dépendances. Le but de mes suggestions était simplement de simplifier d'une part les opérations pour les utilisateurs du tuto et d'autre part de simplifier drastiquement le script de renouvellement. J'ai bien compris le message et n'interviendrai plus sur ce fil. Réponses valables si pas de changements de ACME depuis mon intervention sur le tuto de unPixel. Non, , étant positionné dans /usr/local/share/acme.sh un wget installe directement tous les fichiers nécessaires dans ce dossier Non mais dans /usr/local/share/acme.sh Cette info est transmise par l'option --dns xxx de la commande de création du certificat Le script de renouvellement peut parfaitement vérifier l"ancienneté du certificat et décider s'il faut lancer le renouvellement (il le fait) La commande de renouvellement utilisant l’option --dns ne nécessite pas l'ouverture de ports Enfin concernant le script Il est obligé d''aller récupérer toutes les personnalisations faites lors de la création initiale! Quel est l’intérêt de conserver l'ancien certificat (durée de vie limitée) et d'en créer un nouveau ? Ce qui entraine de mémoriser les data de l'ancien fichier INFO pour de les transférer dans le nouveau. Le transfert des fichiers créés par ACME et renommés, ainsi que le redémarrage des packagses et services tels que réalisés par le script actuel seraient suffisants. La liste des certificats dans DSM va grossir ! @bruno78 Il n'en était question que lors de la création initiale du certificat le script actuel s'en chargeant lors du renouvellement. Fin de mon intervention sur ce fil. Cordialement
  2. Bonjour, Très beau travail de @oracle7 et @bruno78 Mais je vais me permettre de donner mon humble avis, sans intention blesser qui que ce soit. Je trouve ce tuto trop compliqué, ce qui entraine des anomalies comme celle rencontré par @Audio (certainement variable CERT_HOME non définie lors de la création initiale du certificat) . Pourquoi ne pas avoir procédé ainsi: Installation acme: Création du dossier acme Après s'y être positionné, installation par un simple wget (ou curl) On laisse tous les paramétrages par défaut Création initiale d'un certificat: On ne renseigne les variables d'environnement que pour les clé API On lance uniquement la commande de création du certificat (pas d'utilisation de deploy) On crée le certificat depuis DSM avec les nouveaux fichiers obtenus de ACME. On configure les services pour ce certificat. Renouvellement: Le script après les test initiaux se contente de Lancer la même commande que lors de la création Copier ( et renommer ) les nouveaux fichiers obtenus de ACME dans les packages et services concernés Relancer les packages et services concernés Enfin je trouve dommage que le script de renouvellement soit en python 2.7. Python 2 est obsolète et n'est plus maintenu. Si un jour DSM7 sort, il est très probable que seul python 3 y subsistera, rendant ce script inutilisable.
  3. Le redémarrage des services n’est pas nécessaire, Je ne suis même pas certain que ce soit utile pour tous les packages avec (IsPgg = True) Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA. La rajout de quelques lignes de code sera suffisant pour remédier au problème. Mais je ne pourrai faire de tests que la semaine prochaine (quota LE). Si un utilisateur éprouve le besoin de changer de type de clé de chiffrement, n’est-il pas plus simple de changer un paramètre de ce script et de le relancer avec le paramètre 0 que de relancer la création d’un certificat en suivant votre tuto qui est un processus assez lourd (je reconnais ne n’avoir lu qu’en diagonale), Ce serait faisable,mais il faudrait rajouter d’autres paramètres comme l’API DNS à utiliser. Et il resterait le problème des clés d’accès à cet API Elles sont différentes selon les API ( nombre, noms, longueurs …) et ces API sont nombreuses !! Comme je n’utilise pas acme je n’ai jamais pris le temps de vraiment de détailler son fonctionnement. Je ne sais pas exactement quelles sont infos que l’on peut trouver dans le fichier account.conf. Si c’est simple dans le cas d’un certificat unique, qu’en est-il dans le cas de l’existence de plusieurs certificats (chez un ou plusieurs registrars) ? L’objectif d’un script ‘généraliste’ me semble trop ambitieux. Ce qui me semble envisageable, c’est un script limité à un certificat LE unique dont le DNS est soit chez OVH, soit chez Gandi. Oui. Vous pouvez vérifier dans la crontab que vous n'avez pas de lignes correspondantes (je ne pense pas). Il n’est pas utile de redémarrer AudioStation, Surtout le temps d’exécution du script va sérieusement augmenter. PS: Ces clés sont uilisées pour permettre l’accès à l’API. Les valeurs TXT inscrites dans le DNS sont différentes à chaque exécution par LE, ce ne sont pas les clés API .
  4. @bruno78 Le script que j'ai fourni est buggé! Je viens de m'en apercevoir car j'avais programmé une tâche pour le lancer périodiquement pour test. Il ne fonctionne pas pour les clé elliptiques. (que j'avais mis en exemple pour le paramétrage du script alors que je n'avais pas testé cette configuration!) Il ne doit donc être lancé que pour des clé RSA. Je pense le corriger rapidement, mais les test seront long (j'ai déjà épuisé mon quota pour la semaine et des tests en staging ne me semblent pas suffisants pour valider un script) Il y a de nombreuses combinaisons à tester (RSA vers RSA, EDSA vers EDSA, RSA vers EDSA, EDSA vers RSA) Désolé @oracle7 Pouvez vous me transmettre une copie de ce fichier (expurgé des données personnelles) Chez moi ce fichier ne mentionne pas de clés. Pourquoi? ce fichier peut être mis n'importe où à partir du moment où c'est un emplacement non concerné par les mise à jour DSM. Noz vat JC ☺️
  5. Bonjour, Comme prévu, je viens de repasser sur ce forum. Le renouvellement automatique du certificat LE générique n’y figurant pas, je me suis libéré un petit créneau pour essayer de vous aider. Je n’ai pas suivi le tuto pour installer acme,sh Je me suis simplement positionné dans le dossier /usr/local/share/acme.sh installé acme par curl https://get.acme.sh | sh J’ai ensuite réalisé la création initiale du certificat : définir la clé l’API key : export GANDI_LIVEDNS_KEY="?????????????" (pour OVH cela aurait été export OVH_AK="???" et export OVH_AS="???") lancer la demande de certificat par la commande : /usr/local/share/acme.sh/acme.sh --issue -d nom_domaine.tld -d *.nom_domaine.tld --dns dns_gandi_livedns -- keylength ec-384 --home /usr/local/share/acme.sh --nocron --force (pour OVH il aurait fallu -dns dns_ovh) rajouté les deux enregistrements TXT dans la zone DNS du domaine (infos récupérés dans le message de l’étape précédente) relancer la demande de certificat par la même commande que précédemment Les fichiers de certificats créés ont ensuite été injectés par l’interface du syno. Le renouvellement automatique sera réalisé par un script lancé quotidiennement (en root) par le planificateur de tâche. Le script joint n’est qu’une ébauche et demande à être adapté et finalisé. Il doit être paramétré avant utilisation (paramétrage en début de script). Par défaut, il réalise le renouvellement tous les 84 jours. Il relance les packages concernés par ce certificat (et non arrêtés avant le renouvellement). Cela n’est pas forcément obligatoire et peut être supprimé en commentant la ligne 202 du script. Ces redémarrages avaient été introduits suite au constat de l’arrêt de certains paquets par UnPixel sur un précédent tuto, ce que je n’ai jamais constaté chez moi. PS commande à renseigner dans le planificateur de tâche : bash /volume1/script/forum/majcertificat_v04.sh (à adapter selon l’emplacement du script) ou pour avoir une trace de la dernière exécution : bash /volume1/script/forum/majcertificat_v04.sh > /volume1/script/forum/certificat/majcertificat.log 2>&1 Enfin on peut ajouter un paramètre( de 0 à 90)) si l’on veut une périodicité de renouvellement différente. Par exemple pour tester durant une courte période un renouvellement tous les 2 jours : bash /volume1/script/forum/majcertificat_v04.sh 2 > /volume1/script/forum/certificat/majcertificat.log 2>&1 Bon tests pour ceux qui aiment les risques! majcertificat_v04.sh
  6. @bruno78 Le manuel de jq : https://stedolan.github.io/jq/manual/
  7. @bruno78 Pour mes besoins, sur les NAS où j’interviens, je ne code presque qu’exclusivement en Python. Je n’ai pratiqué le shell que pour aider sur quelques scripts de tuto de ce forum où je suis intervenu. Je le connais donc que très mal et trouve sa lecture pénible (manque de pratique) Les fichiers json se traitent en shell avec jq. J’essaierai de passer sur ce forum de temps en temps pour voir où vous en êtes. Si vous êtes bloqués j’essaierai de vous aider. Bon courage
  8. Bonjour @bruno78, Je n’ai pas parcouru les 4 pages de ce tutoriel, j’ai seulement lu votre dernier message. A partir de la situation que vous décrivez, il vous manque pour finir ce script. Dans un premier temps vous devez, en exploitant le dossier INFO (pour ce qui concerne ce nouveau certificat) : - Copier les nouveaux dossiers du certificat dans les dossiers des packages concernés puis redémarrer ceux-ci - Copier les nouveaux dossiers du certificat dans les dossiers des reverse-proxies concernés - redémarrer ngix, Cependant vous constaterez qu’ainsi vous avez redémarré des packages qui étaient arrêtés avant le renouvellement du certificat Dans un second temps vous devez donc tester et mémoriser l’état initial des packages afin de ne relancer que ceux qui étaient précédemment actifs. Et pour finir une (petite) remarque : Cela étant un tuto, je trouve dommage de proposer un script en Python, car cela nécessitera d’installer ce paquet. Si c’est pour cette seule utilisation, je trouve cela dommage.
  9. Bonjour, Panneau de configuration Services d’indexation Bouton Dossier indexé Bouton créer
  10. @oracle7 L'option steging correspond à un serveur de test sans limitation.
  11. @bruno78 Pour éviter d'être bloqué par un nombre d'essais trop importants durant vos tests, sachez que acme.sh accepte l'option --staging
  12. Si c'est pour avoir des copies d'écran pour faire un tuto, il faut que vous supprimiez provisoirement la ligne A de votre zone DNS chez OVH.
  13. Bonjour, Alors pourquoi vouloir en installer un, c'est inutile.
  14. Bonjour @Brenac Oui et NON! Oui: car cette commande doit être passée en tant que root Pour cela sudo -i puis le mot de passe admin (tapé en aveugle) NON: car j'avais omis de le préciser!!!
  15. Bonjour, Le port 25 est bloqué chez Orange. Il n'y a pas de possibilité de le débloquer.