[TUTO]Création d'un Certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh"

[oracle7]

@Pascalou59

Bonjour,

il y a 28 minutes, Pascalou59 a dit :

je peux supprimer complètement via wincp tous les dossiers qui ont été crée dans mon Nas  sans risque  ,et supprimer aussi les fichiers  et les  règles dans le planificateur de tache  ?

Effectivement si tu recommence à zéro, alors OUI. Pas la peine de désinstaller acme.sh. Sauf si  tu fais une RAZ totale !

il y a 29 minutes, Pascalou59 a dit :

edit : je suis sur la page DELETE /cdn/dedicated/{serviceName}/ssl Remove SSL of the CDN

????? je ne comprends pas ce que tu fais sur cette page, perso je n'ai jamais eu besoin d'y aller dans le cadre de acme.sh ... Comme on dit, dans le doute : s'abstenir !

Cordialement

oracle7😉

[Einsteinium]

il y a 50 minutes, Pascalou59 a dit :

Je vais commencer par la c'est déja ça  et recommencer a 0, je peux supprimer complètement via wincp tous les dossiers qui ont été crée dans mon Nas  sans risque  ,et supprimer aussi les fichiers  et les  règles dans le planificateur de tache  ?

Voilà pourquoi j'ai fais un tutoriel version express en docker, pas de pollution du nas 🙂

C'est le caractère % alors qui fessait le brin, maintenant si tu as fait changement, faut attendre un peu la propagation aux services tiers (api dans le cas présent)

[Pascalou59]

il y a une heure, oracle7 a dit :

@Pascalou59

????? je ne comprends pas ce que tu fais sur cette page, perso je n'ai jamais eu besoin d'y aller dans le cadre de acme.sh ... Comme on dit, dans le doute : s'abstenir !

Cordialement

oracle7😉

je dois etre neuneu mais quand  je me  connecte et je tombe sur cette page et j'obtiens tout ça , il y en a beaucoup !! et je sais pas dans quelle rubrique je dois aller

 

 

Modifié le 27 janvier 2021 par Pascalou59

[oracle7]

@Pascalou59

Bonjour,

Il y a 2 heures, Pascalou59 a dit :

edit : je suis sur la page DELETE /cdn/dedicated/{serviceName}/ssl Remove SSL of the CDN

Je t'ai répondu par rapport à cette page que tu indiquais.

Les liens que je t'ai donné précédemment font référence à cette rubrique :

Donc quand tu cliques sur le lien en question, il te faut ensuite user de l'ascenseur de la page pour atteindre la rubrique "/me". Tu me suis ?

Cordialement

oracle7😉

[Pascalou59]

@oracle7

Ok je suis dessus , dernière question

je suis dans la partie DELETE /me/api/application/{applicationId}

applicationId *   ou puis retrouver le nom ou la valeur que je dois entrer  ??

Edit1 c'est bien çela l' ID ??

Edit 2 le chiffre en bleu répond bien   , j' ai effacé l'api que je ne voulais pas garder

Modifié le 27 janvier 2021 par Pascalou59

[oracle7]

@Pascalou59

Bonjour,

Je comprends donc après ton "Edit 2" que tout est bon maintenant.

Codialement

oracle7😉

[Pascalou59]

@oracle7 J' ai un autre soucis maintenant je t'ai envoyé un MP  .

Les certif c'est pas la panacée , il y a toujours un truc qui coince

[oracle7]

@Pascalou59

Bonjour,

Effectivement, mais ce truc qui coince comme tu le dis, relève le plus souvent d'une erreur d'attention bénigne et ce malgré les mises en gardes que je fais dans le TUTO. Je constate à la vue des retours que la lecture est parfois faite un peu en "diagonale" car on croit savoir et on va du coup plus vite que la musique ou encore on ne percute pas sur la mise en garde. Rassures-toi tu n'es pas le premier et ne sera pas le dernier ...🤪 Toi c'était les caractères spéciaux, d'autres ce sera autre chose ...

Cordialement

oracle7

 

[Pascalou59]

@oracle7

Suite a tes conseils en MP j'ai supprimé l'enregistrement TXT et tout est rentré dans 'l ordre

[Wed Jan 27 19:18:33 CET 2021] Cert success.

 

[oracle7]

@Pascalou59

Bonjour,

Bien c'est super ! 🤗👍

il faut maintenant passer au déploiement et mettre en place le renouvellement auto ...

Cordialement

oracle7😉

[Stixen92]

Salut @oracle7

J'ai enfin réussi le déploiement de mon certificat via la console SSH.
C'est la connexion en HTTPS qui posait problème...En HTTP, le déploiement se fait sans problème.

Merci à toi et @bruno78 pour votre travail.

Cependant, il me reste quelques questions:

1) J'ai lancé manuellement le script "ACME_RENEW.PY"  via la console SSH (WinSCP).
J'ai utilisé le paramètre -f pour forcer le renouvellement du certificat.

Tout se passe bien (création du certificat, etc..) sauf qu'à la fin, au moment du déploiement du certificat, j'ai une drôle d'erreur:

[Wed Jan 27 17:15:03 CET 2021] _ret='0'
[Wed Jan 27 17:15:03 CET 2021] Return code: 0
[Wed Jan 27 17:15:03 CET 2021] _error_level='2'
[Wed Jan 27 17:15:04 CET 2021] _set_level='2'
[Wed Jan 27 17:15:04 CET 2021] The NOTIFY_HOOK is empty, just return.
--- Fin de la procedure
[Wed Jan 27 17:15:03 CET 2021] http services were NOT restarted
[Wed Jan 27 17:15:03 CET 2021] Success
[Wed Jan 27 17:15:04 CET 2021] ===End cron===

Puis j'obtiens le message : "Le certificat n'a pas été renouvelé."

Pourtant le nouveau certificat a bien été crée... C’est au niveau du déploiement que ça coince?

Pourtant si je fais le déploiement via le script ACME, tout passe normalement...

Ces codes erreur te disent quelque chose?

 

2) Concernant la date d'expiration du cookie DID (double authentification), vu que la modification de la date se fait depuis la navigateur Firefox et que le cookie en question reste dans Firefox, comment le NAS fait pour avoir connaissance de la nouvelle d'expiration du cookie?


3) Les valeurs "OVH_AK" (application key) et "OVH_AS" (application secret) se trouvent dans le fichier account.conf situé dans "/usr/local/share/acme.sh"

Mais je ne vois pas dans ce fichier la valeur "OVH CK" (consumer key)...

Est-ce normal?

Si oui, dans quel fichier se trouve la valeur "OVH CK"?

 

[Pascalou59]

@oracle7

Bon

encore un truc qui m' est refusé pour le renouvellement , je ne peux pas déposer le fichier  avec  winscp : /volume1/Scripts/acme_renew.py: Permission denied

J'ai coché tous les droits sur ce dossier

Modifié le 27 janvier 2021 par Pascalou59

[oracle7]

@Pascalou59

Bonjour,

Tu es bien sous "root" (le vrai !) quand tu fais cela ?

Les droits chez moi sont :

Cordialement

oracle7😉

[Pascalou59]

@oracle7

oui j'utilise le vrai compte admin pour me connecter avec winscp et je préfère wincp pour transférer le fichier  , j'ai fait toutes les manip avec putty en root  mais je ne connais pas la commande pour envoyer un fichier avec putty. J'ai vu ça comme exemple

scp /home/mickael/data/Ficher2 root@192.168.10.131:/var/www/

Je suis suis presque a la fin Grrr

avec winscp

La commande 'cp -p -r -f  "acme_renew.py" "/volume1/Scripts/acme_renew.py"'
 a échoué avec pour code de retour 1 et pour message
cp: cannot create regular file '/volume1/Scripts/acme_renew.py': Permission denied.

 

Modifié le 27 janvier 2021 par Pascalou59

[oracle7]

@Stixen92

Bonjour,

il y a 13 minutes, Stixen92 a dit :

Puis j'obtiens le message : "Le certificat n'a pas été renouvelé."

Pourtant le nouveau certificat a bien été crée... C’est au niveau du déploiement que ça coince?

Je ne crois pas, avec @bruno78 on connait le problème, de mémoire cela viendrait a priori du script mais sous toutes réserves. Bruno78 devait regarder cela, je ne sais où il en est sur ce point qui est finalement est plus déroutant qu'il n'est bloquant en pratique.

Pour les codes d'erreur [Wed Jan 27 17:15:03 CET 2021] _error_level='2' c'est, si je ne m'abuse, une information de acme.sh qui dit avoir utiliser  le niveau d'erreur 2 pour ses logs.

il y a 19 minutes, Stixen92 a dit :

comment le NAS fait pour avoir connaissance de la nouvelle d'expiration du cookie?

Elle est stockée dans le DID.

il y a 20 minutes, Stixen92 a dit :

Mais je ne vois pas dans ce fichier la valeur "OVH CK" (consumer key)...

Est-ce normal?

Bonne remarque, Non ce n'est pas normal elle devrait y figurer. Edites le fichier account.conf et ajoute à la fin une ligne tel que :

OVH_CK= 'xxxxxxxxxxxxxxxxxx valeurcléConsumerKeyxxxxxxxxxxxxxxxxxxxx'

N'oublies pas d'enregistrer.

Cordialement

oracle7😉

 

@Pascalou59

Bonjour,

L'astuce est de copier via WIN/Mac le fichier acme_renew.py dans un dossier partagé du NAS (par exemple : "mondossierpartagé").

Ensuite soit directement sous WINSCP tu transferts par glisser/déposer ou C/C le fichier depuis "/volume1/mondossierpartagé" vers "/volume1/Scripts".

Ou bien soit sous root avec sous PuTTY/Terminal_Mac tu tapes : " cp -p /volume1/mondossierpartagé/acme_renew.py /volume1/Scripts "

Cordialement

oracle7😉

[Stixen92]

@oracle7

il y a 32 minutes, oracle7 a dit :

Je ne crois pas, avec @bruno78 on connait le problème, de mémoire cela viendrait a priori du script mais sous toutes réserves. Bruno78 devait regarder cela, je ne sais où il en est sur ce point qui est finalement est plus déroutant qu'il n'est bloquant en pratique.

Pour les codes d'erreur [Wed Jan 27 17:15:03 CET 2021] _error_level='2' c'est, si je ne m'abuse, une information de acme.sh qui dit avoir utiliser  le niveau d'erreur 2 pour ses logs.

Donc malgré ces messages d'erreur suite à l'exécution du script Python , tout s'est bien passé (création du certificat + déploiement)?

 

il y a 34 minutes, oracle7 a dit :

Elle est stockée dans le DID.

Ah oui? Pourtant la valeur du DID n'a pas changé après que j'ai modifié la date d'expiration.

 

il y a 36 minutes, oracle7 a dit :

Bonne remarque, Non ce n'est pas normal elle devrait y figurer. Edites le fichier account.conf et ajoute à la fin une ligne tel que :

OVH_CK= 'xxxxxxxxxxxxxxxxxx valeurcléConsumerKeyxxxxxxxxxxxxxxxxxxxx'

N'oublies pas d'enregistrer.

J'ai rajouté, via l'éditeur de texte, la ligne SAVED_OVH_CK='XXXX' dans le fichier account.conf

Mais c'est quand même étrange. J'ai réessayé, quelques minutes avant, de rajouter cette valeur via la console SSH en utilisant la commande export OVH_CK="XXXX" mais cela n'a rien donné au niveau du fichier...
Bizarre...

D'ailleurs, la valeur OVH_END_POINT=ovh-eu n'apparait pas non plus dans le fichier account.conf, je dois aussi la rajouter?

Pourtant, tout a fonctionné sans problème pour la création du certificat, à 2 reprises, cet après-midi...

[oracle7]

@Stixen92

Bonjour,

il y a 40 minutes, Stixen92 a dit :

Ah oui? Pourtant la valeur du DID n'a pas changé après que j'ai modifié la date d'expiration.

Désolé je me suis mal exprimé en parlant de la date d'expiration, le DID comporte en fait une durée de validité fixée par la date d'expiration par rapport à sa date de création. Du coup, quand la date courante est supérieure à Date création + durée de validité alors le DID n'est plus valide. Quand tu changes manuellement la date d'expiration du DID dans FF pour la repousser aux calandres grecques, il te faut ensuite aller recopier dans le fichier account.conf la nouvelle valeur du DID dans la variable SAVED_DID. Il en est aussi de même après une mise à jour de FF car le DID est réinitialisé, il faut donc remodifier sa date d'expiration. Seulement à partir de là le NAS saura ... C'est chi... mais on n'a pas le choix que de subir cet état de fait.

il y a 40 minutes, Stixen92 a dit :

J'ai rajouté, via l'éditeur de texte, la ligne SAVED_OVH_CK='XXXX' dans le fichier account.conf

Tu m'as lu ma précédente réponse en "diagonale" ! Je n'ai jamais parlé de variable SAVED_OVH_CK mais de variable OVH_CK.

il y a 40 minutes, Stixen92 a dit :

J'ai réessayé, quelques minutes avant, de rajouter cette valeur via la console SSH en utilisant la commande export OVH_CK="XXXX" mais cela n'a rien donné au niveau du fichier...
Bizarre...

Et pour cause, exporter une variable (par ex export OVH_CK="XXXX") n'est valable que durant la session SSH courante durant laquelle la variable reste en mémoire pour d'autres utilisations. La variable exportée n'est pas détruite à la fin du script qui l'utilise puisqu'elle n'a pas été définie dans ce script, ainsi si tu relances le script, la variable (et donc la valeur qu'elle stocke) est toujours disponible. Par contre elle est bien détruite à la fin de la session SSH. Il n'y a donc rien de bizarre. Ce que tu as constaté, est simplement normal.

Par ailleurs, saches qu'en aucun cas cet export n'écrit dans un quelconque fichier et donc pas dans account.conf. Seul le script acme.sh le fait.

il y a 40 minutes, Stixen92 a dit :

D'ailleurs, la valeur OVH_END_POINT=ovh-eu n'apparait pas non plus dans le fichier account.conf, je dois aussi la rajouter?

NON, cette variable ne sert que pour et lors de la création du certificat. Le fichier account.conf sert lui, aux renouvellements du certificat.

Cordialement

oracle7😉

 

Modifié le 27 janvier 2021 par oracle7

[Stixen92]

il y a 22 minutes, oracle7 a dit :

Tu m'as lu ma précédente réponse en "diagonale" ! Je n'ai jamais parlé de variable SAVED_OVH_CK mais de variable OVH_CK.

J'ai bien lu ce que tu m'as écrit mais je pensais que tu avais oublié le partie "SAVED".

Je l'ai écrit sous la forme "SAVED_OVH_CK" car dans le fichier account.conf les autres variables apparaissent sous la forme "SAVED_OVH_XX"

En effet, j'ai "SAVED_OVH_AK" et "SAVED_OVH_AS" dans mon fichier account.conf

Donc je suis perdu...Pourquoi pour "OVH_CK" cela serait différent?

il y a 22 minutes, oracle7 a dit :

Et pour cause, exporter une variable (par ex export OVH_CK="XXXX") n'est valable que durant la session SSH courante durant laquelle la variable reste en mémoire pour d'autres utilisations. La variable exportée n'est pas détruite à la fin du script qui l'utilise puisqu'elle n'a pas été définie dans ce script, ainsi si tu relances le script, la variable (et donc la valeur qu'elle stocke) est toujours disponible. Par contre elle est bien détruite à la fin de la session SSH. Il n'y a donc rien de bizarre. Ce que tu as constaté, est simplement normal.

Par ailleurs, saches qu'en aucun cas cet export n'écrit dans un quelconque fichier et donc pas dans account.conf. Seul le script acme.sh le fait.

Oulah, je suis perdu là.

Pourquoi les variables "OVH_AK" et "OVH_AS" apparaissent bien dans mon fichier account.conf sous les formes respectives: "SAVED_OVH_AK" et "SAVED_OVH_AS" mais pas la variable "OVH_CK" qui n'apparaît pas du tout?

Pourtant j'ai suivi ton tuto à la lettre et ai entré ces 3 variables ("OVH_AK", "OVH_AS" et "OVH_CK") à la suite suite lors de la session SSH...

Modifié le 27 janvier 2021 par Stixen92

[bruno78]

Il y a 9 heures, Stixen92 a dit :

Il y a 10 heures, oracle7 a dit :

Je ne crois pas, avec @bruno78 on connait le problème, de mémoire cela viendrait a priori du script mais sous toutes réserves. Bruno78 devait regarder cela, je ne sais où il en est sur ce point qui est finalement est plus déroutant qu'il n'est bloquant en pratique.

Pour les codes d'erreur [Wed Jan 27 17:15:03 CET 2021] _error_level='2' c'est, si je ne m'abuse, une information de acme.sh qui dit avoir utiliser  le niveau d'erreur 2 pour ses logs.

Donc malgré ces messages d'erreur suite à l'exécution du script Python , tout s'est bien passé (création du certificat + déploiement)?

@oracle7, @Stixen92,

tout d'abord désolé de ne pas être plus présent sur le forum, mais je n'ai que très peu de temps dispo ces denrières semaines (à cause du boulot , et d'autres projets autour du RPi4 ....).

Donc oui et oui aux 2 questions ci-dessus :

• oui l'erreur est connue, mais je n'ai pas eu le temps de la régler
• oui cela indique qu'acme utilise le niveau d'erreur 2 pour ses logs.

Pour être tout à fait franc, je n'utilise plus cette méthode depuis mon passage en DSM7. Je passe par le docker acme, et je tente de faire fonctionner le hook de déployement Synology.

Néanmoins, je vais quand même essayer de regarder le premier point pour voir si je peux améliorer la chose dans le script python. Mais si correction il y a, je vous solliciterai pour valider car je n'ai plus l'environnement complet pour cela.

Cdt

Bruno78

[Pascalou59]

 

Il y a 13 heures, oracle7 a dit :

@Pascalou59

Bonjour,

L'astuce est de copier via WIN/Mac le fichier acme_renew.py dans un dossier partagé du NAS (par exemple : "mondossierpartagé").

Ensuite soit directement sous WINSCP tu transferts par glisser/déposer ou C/C le fichier depuis "/volume1/mondossierpartagé" vers "/volume1/Scripts".

Ou bien soit sous root avec sous PuTTY/Terminal_Mac tu tapes : " cp -p /volume1/mondossierpartagé/acme_renew.py /volume1/Scripts "

Cordialement

oracle7😉

Bonjour @oracle7

Après avoir testé sous toutes les coutures  , impossible de déplacer un fichier dans un dossier crée en mode root ou admin que ce soit avec winscp ou putty  et c'est même pire car impossible de supprimer le(s) dossiers mentionnés , une fois crée je ne peux même plus les renommer.

Impossible de mettre un fichier comme celui ci acme_renew.py dans le dossier scripts , j' ai crée un dossier similaire script2 en mode putty  et c'est pareil , je n'ai plus la main dessus comme ci il y a un super admin mais je suis formel j' utilise le vrai compte admin , je précise que ces 2 dossiers sont vide

 

 

Depuis DSM si je veux créer un dossier partagé qui a le meme nom que ceux mentionné ci dessus  echec de l' opération

Modifié le 28 janvier 2021 par Pascalou59

[Stixen92]

Bonjour @bruno78 @oracle7

Je rajouterai à mon message d'hier soir le problème suivant, très étrange:

1) Si j'utilise la commande "python acme_renew.py -f -l nomdedomaine.fr" depuis la console WinSCP, le renouvellement et le déploiement du certificat se fait sans problème.

2) Si j'utilise la commande "python3 /volume1/Scripts/acme_renew.py -f -l nomdedomaine.fr", manuellement depuis le "Planificateur de tâches de DSM", le renouvellement du certificat refuse de se faire...

J'ai obtenu ces messages d'erreur:

[Thu Jan 28 08:36:08 CET 2021] _currentRoot='dns_ovh'
[Thu Jan 28 08:36:08 CET 2021] get to authz error.

[Thu Jan 28 08:36:08 CET 2021] _on_issue_err

[Thu Jan 28 08:36:08 CET 2021] Return code: 1
[Thu Jan 28 08:36:08 CET 2021] Error renew nomdedomaine.fr
[Thu Jan 28 08:36:08 CET 2021] _error_level='1'
[Thu Jan 28 08:36:08 CET 2021] _set_level='2'
[Thu Jan 28 08:36:08 CET 2021] The NOTIFY_HOOK is empty, just return.
[Thu Jan 28 08:36:08 CET 2021] ===End cron===

 

Surprenant alors que les paramètres dans les fichiers nomdedomaine.cong et account.conf sont identiques...
Je n'ai rien touché...

J'ai fait, en premier, l’exécution du renouvellement en manuel via le Planificateur de tâches de DSM puis je l'ai fait en manuel via la console SSH de WinSCP...

Je n'ai pas atteint les 5 renouvellements par semaine autorisés.

Du coup, le renouvellement automatique ne marchera pas.
 

D'où vient le problème?
Sur la console SSH, j'ai parfois un message lors du renouvellement du certificat ou lors du déploiement de celui-ci:

"L'hôte n'a pas communiqué depuis plus de 15 secondes, en attente..."

J'attends et ça passe toujours.

Cela pourrait venir de là? D'ailleurs?

Merci.

 

[oracle7]

@Stixen92

Bonjour,

Il y a 11 heures, Stixen92 a dit :

Pourquoi les variables "OVH_AK" et "OVH_AS" apparaissent bien dans mon fichier account.conf sous les formes respectives: "SAVED_OVH_AK" et "SAVED_OVH_AS" mais pas la variable "OVH_CK" qui n'apparaît pas du tout?

Pourtant j'ai suivi ton tuto à la lettre et ai entré ces 3 variables ("OVH_AK", "OVH_AS" et "OVH_CK") à la suite suite lors de la session SSH...

Je vais être abrupte et j'en suis désolé, mais il te faut faire avec cette syntaxe c'est comme cela et pas autrement, faute en est aux développeurs du script acme.sh. Seuls eux pourraient t'expliquer ce qui te paraît être une incohérence.

Ce que je peux t'en dire : c'est que les variables sont nommées "OVH_AK" , "OVH_AS" et  "OVH_CK" pour leur usage dans le script, les deux premières sont ensuite sauvegardées sous le nom "SAVED_OVH_AK" et "SAVED_OVH_AS" dans le fichier account.conf. La variable "OVH_CK" est quant à elle normalement sauvegardée sous le même nom.

Si la variable "OVH_CK" n'apparaît pas, tu la rajoutes comme je te l'ai expliqué précédemment. C'est vrai, sans que je ne sache vraiment l'expliquer, cette variable semble parfois disparaître du fichier account.conf. C'est un phénomène aléatoire bizarre, qui apparaît a priori après un renouvellement. Comme acme.sh se réinstalle tout seul systèmatiquement lorsque l'on exécute le script (pour un renouvellement par ex), peut-être qu'il réécrit complètement le fichier account.conf à cette occasion mais en le faisant malheureusement incomplètement, d'où la disparition de la variable OVK_CK. Ce n'est qu'une intuition, mais je peux me tromper ...

Par ailleurs, dans la procédure, on exporte les trois variables sous leur nom "simple" pour communiquer leurs valeurs respectives au script acme.sh, c'est en quelque sorte une forme de passage de paramètres externes au script pour son fonctionnement.

Donc, ne le prends pas mal, mais ne cherches pas "midi à quatorze heures", tout ceci est de la syntaxe pure, admets le simplement. Je crains que tu ne te tortures l'esprit pour rien car c'est un simplement un fait de programmation, pas propre à mon sens, je te l'accorde bien volontiers.

Pour ton point2 :

• As-tu au moins installé le package Python3 et ses éventuelles dépendances sur le NAS ?
• As-tu aussi vérifié si ton NAS était compatible pour accueillir Python3 --> voir ici.

il y a 19 minutes, Stixen92 a dit :

"L'hôte n'a pas communiqué depuis plus de 15 secondes, en attente..."

Ceci est lié au script acme.sh qui met du temps pour réaliser certaines opération et à des temporisations dans les communications entre acme.sh et les serveurs d'OVH, sans parler que parfois si tu observes bien les logs, tu verras que ces serveurs OVH ne répondent pas dans les temps ce qui force acme.sh a réitérer plusieurs fois ses demandes/requêtes.

J'ai constaté personnellement plusieurs fois jusqu"à plus d'une minute d'attente. Du coup la console WinSCP prend cela pour de l'inactivité (i.e. comme un programme planté) et cherche à se déconnecter. Pour éviter cela il faut éditer les paramètres de ta session SSH sous WinSCP.

Tu vas dans "Session / SItes /Gestionnaire de Site" là tu sélectionnes ta session SSH via son nom de site et tu cliques sur "Editer" puis sur "Avancé ...". Tu sélectionnes la rubrique "Connexion" dans la liste à gauche et tu fixes le "time out de connexion" à 120 secondes :

Cordialement

oracle7😉

 

@bruno78

Bonjour,

Il y a 3 heures, bruno78 a dit :

Mais si correction il y a, je vous solliciterai pour valider car je n'ai plus l'environnement complet pour cela.

Pas de soucis, je reste à ta disposition pour cela.

Cordialement

oracle7😉

[bruno78]

@Stixen92, peut-être une porte ouverte, mais pour ton point #2, avec le planificateur de tâche, quel est le "user" paramétré dans la tache ?

Bruno78

[oracle7]

@Pascalou59

Bonjour,

Par extension à ma mise en garde au §2 du TUTO, concernant l'usage du "vrai" root et du problème de la commande "sudo -i", je t'invites à recréer une session SSH WinSCP et/ou PuTTY pour l'utilisateur 'root' avec son mdp propre (surtout SANS caractères "exotiques" spéciaux !!!) et NE PAS utiliser de connexion SSH autre, même à partir d'un utilisateur de type "Administrateur". Il te faudra peut-être pour cela regénérer un couple de clés Privé./Publique pour "root" (voir le TUTO Accés SSH et root via DSM6).

Maintenant, il est quand même étonnant que tu ne puisses pas déposer un fichier depuis Windows dans un dossier partagé du NAS. Tu as peut-être un problème réseau, aussi tout bêtement, reboot le PC et le NAS ...

PS : Précédemment, quand je disais d'utiliser un dossier partagé du NAS tel que "mondossierpartagé", il faut que ce dossier partagé (au sens Synology) soit déjà existant donc avoir été créé via DSM dans "Panneau de configuration / Dossiers partagés" avec aucune restriction dessus en termes de  droits. Il ne faut surtout pas que "mondossiermartagé" soit créé directement via WINSCP par ex.

Ensuite tu appliques l'astuce que je t'ai donnée précédemment et la commande "cp" sous Terminal PuTTY ou WinSCP.

Là cela devrait le faire 🤔

Cordialement

oracle7😉

 

[Stixen92]

@oracle7 @bruno78

il y a 42 minutes, oracle7 a dit :

Pour ton point2 :

• As-tu au moins installé le package Python3 et ses éventuelles dépendances sur le NAS ?
• As-tu aussi vérifié si ton NAS était compatible pour accueillir Python3 --> voir ici.

- Oui, "Python3" et "Python Module", sont bien installés sur mon NAS.

- Oui, mon NAS est bel et bien compatible pour accueillir Python3.

Donc je ne comprends pas pourquoi le renouvellement refuse de se faire via le Planificateur de tâches, en mode manuel (commande "python3 /volume1/Scripts/acme_renew.py -f -l nomdedomaine.fr")...

 

il y a 30 minutes, bruno78 a dit :

@Stixen92, peut-être une porte ouverte, mais pour ton point #2, avec le planificateur de tâche, quel est le "user" paramétré dans la tache ?

C'est l'user "root" qui est paramétré dans la tâche, comme indiqué dans le tuto.