Bonjour,
J’ai installé certbot et après chaque utilisation debian 9 me donne le message d’erreur suivant :
certbot --v
-su: /usr/bin/certbot : /usr/bin/python3 : mauvais interpréteur: Permission non accordée
Merci d’avance pour votre aide,
Cordialement,
Bonjour belallioui
Donne nous plutôt le message complet,
avec le prompt de départ et l’intégralité de la ligne de commande entrée suite à ce prompt
l’intégralité du message retourné,
jusqu’au prompt de retour inclus.
Comme dans l’exemple qui suit :
michel@debT450:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
michel@debT450:~$
dans lequel on peut voir le prompt de départ avec la ligne de commande :
michel@debT450:~$ lsb_release -a
Puis le retour intégral de la ligne de commande:
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
et le prompt de retour :
michel@debT450:~$
Dans ton message, sans ces informations,
Sans ces informations, il est difficile de savoir ce qu’il s’est passé,
vu qu’on ne sait pas dans quel contexte le messsage que tu nous donnes a été affiché.
Exactement. Toujours se dire que si on ne comprend pas d’où vient l’erreur, la réponse est peut être à côté de ce que l’on regarde ( la vérité est ailleurs )
S’il s’agit de la ligne de commande,
il n’existe pas d’option longue (commençant par deux tirets) d’une seule lettre :
soit c’est l’option courte qui est précédée d’un seul tiret : -v
ou alors, c’est son équivalente sous la forme longue qui est précédée de deux tirets : --version
Il doit sans doute s’agir simplement d’une erreur de frappe, dans la ligne de commande effectivement entrée ou bien dans la retranscription (dans ton message) de cette ligne de commande.
Dans les deux cas, le message d’erreur retourné sera différent selon le type (privilégié ou non) du compte utilisateur qui aura été utilisé pour entrer la commande certbot -v
Le dernier caractère du prompt qui précédait la ligne de commande nous aurait permis de lever ce doute.
Bonjour,
je travail avec root et voici les lignes entières :
root@vps424505:~# certbot -v
-su: /usr/bin/certbot : /usr/bin/python3 : mauvais interpréteur: Permission non accordée
root@vps424505:~#
root@vps424505:~# lsb_release -a
-su: lsb_release : commande introuvable
Merci
Bonjour,
Avez vous une solution ?
Merci
Bonsoir
Merci beaucoup pour tes retours de commande
qui nous donnent déjà énormément plus d’informations. 
Je n’ai aucune expérience avec les serveurs,
tout ce que j’ai tenté de faire pour essayer de comprendre
a été d’installer cerbot dans une machine virtuelle debian
et d’essayer d’obtenir un message d’erreur ressemblant
à celui que t’ont retourné ces lignes de commandes
mais je n’ai rien pu obtenir qui y ressemble,
même de très très loin.
Je trouve inquiétant que ces deux lignes de commande
retournent un message d’erreur commençant par -su:
ce qui indiquerait que ce soit la commande su
qui n’arrive pas à accéder au programme certbot
et rencontre des problèmes de permission d’accès
à l’interpréteur python
Mais le plus étonnant est que la commande lsb_release
ne retourne qu’un message d’erreur
nous indiquant que la commande su n’arrive pas à trouver
la commande lsb_release
Je ne comprends pas pourquoi, sous le compte root
toute exécution de ligne de commande entrée
aurait besoin de l’être par la commande su
Pourrais-tu nous donner un copié/collé,
exactement comme tu l’as fait,
du retour des lignes de commande suivantes :
echo $PATH
echo $SHELL
cat ~/.bashrc
Merci.
Le programme lsb_release fait partie du paquet lsb-release qui n’est pas forcément installé par défaut.
L’affichage de « -su: » est apparemment normal si on passe par su pour exécuter une commande en root.
Le message d’erreur « permission non accordée » pourrait s’expliquer si /usr/bin/python3 ou sa cible n’est pas exécutable. Qu’affiche
ls -l /usr/bin/python*Bonjour,
Merci beaucoup et voici le résultat des commandes que vous avez demandé :
root@vps424505:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@vps424505:~# echo $SHELL
/bin/bash
root@vps424505:~# cat ~/.bashrc
dircolors »#alias python3=« python3.7 »
root@vps424505:~#
Salut,
Bonjour,
Merci pour votre explication c’est dessous le retour de la demande que vous avez demandé :
root@vps424505:~# ls -l /usr/bin/python*
lrwxrwxrwx 1 root root 9 janv. 24 2017 /usr/bin/python -> python2.7
lrwxrwxrwx 1 root root 9 janv. 24 2017 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root 3779512 sept. 26 2018 /usr/bin/python2.7
lrwxrwxrwx 1 root root 33 sept. 26 2018 /usr/bin/python2.7-config -> x86_64-linux-gnu-python2.7-config
lrwxrwxrwx 1 root root 16 janv. 24 2017 /usr/bin/python2-config -> python2.7-config
lrwxrwxrwx 1 root root 25 janv. 24 12:37 /usr/bin/python3 -> /etc/alternatives/python3
-rwxr-xr-x 2 root root 4751184 sept. 27 2018 /usr/bin/python3.5
lrwxrwxrwx 1 root root 33 sept. 27 2018 /usr/bin/python3.5-config -> x86_64-linux-gnu-python3.5-config
-rwxr-xr-x 2 root root 4751184 sept. 27 2018 /usr/bin/python3.5m
lrwxrwxrwx 1 root root 34 sept. 27 2018 /usr/bin/python3.5m-config -> x86_64-linux-gnu-python3.5m-config
lrwxrwxrwx 1 root root 16 janv. 20 2017 /usr/bin/python3-config -> python3.5-config
-rwxr-xr-x 1 root root 976 févr. 28 2016 /usr/bin/python3-jsondiff
-rwxr-xr-x 1 root root 3662 févr. 28 2016 /usr/bin/python3-jsonpatch
-rwxr-xr-x 1 root root 1342 avril 30 2016 /usr/bin/python3-jsonpointer
lrwxrwxrwx 1 root root 10 janv. 20 2017 /usr/bin/python3m -> python3.5m
lrwxrwxrwx 1 root root 17 janv. 20 2017 /usr/bin/python3m-config -> python3.5m-config
-rwxr-xr-x 1 root root 152 sept. 21 2016 /usr/bin/python3-pbr
-rwxr-xr-x 1 root root 284 août 22 2016 /usr/bin/python3-qr
lrwxrwxrwx 1 root root 16 janv. 24 2017 /usr/bin/python-config -> python2.7-config
root@vps424505:~#
Salut,
Je vois pas la version Python 3.7.3 dans le résultat de la commande sachant que cette version est installée :
root@vps424505:~# python3 --version
Python 3.7.3
root@vps424505:~# ls -l /etc/alternatives/python3
lrwxrwxrwx 1 root root 24 janv. 24 12:37 /etc/alternatives/python3 → /usr/local/lib/python3.7
Cette installation de python dans /usr/local ne provient pas des dépôts Debian officiels.
Que retournent
which python3
ls -ld /usr/local/lib/python3.7root@vps424505:~# which python3
/usr/local/bin/python3
root@vps424505:~# ls -ld /usr/local/lib/python3.7
drwxr-sr-x 35 root staff 4096 mars 28 2019 /usr/local/lib/python3.7
root@vps424505:~#
j’aime bien enlever la version 3.5 et la remplacer par 3.7. mais je ne sais pas est ce possible ?
Je m’en doutais. L’exécution directe de python3 fonctionne parce que c’est le chemin /usr/local/bin qui est utilisé. Par contre le lien symbolique /usr/bin/python3 pointe au final vers /usr/local/lib/python3.7 qui est un répertoire et non un exécutable, donc forcément ça ne peut pas marcher.
Il faut corriger le lien avec update-alternatives (ou manuellement, mais ça risque de revenir à la prochaine mise à jour d’un paquet python3).
Comment cette version 3.7 a-t-elle été installée ?
Je me rappel plus 
apparemment je l’ai téléchargé puis installé
Que proposez vous pour corriger le lien et passer à la version python 3.7 ?
Merci
Utiliser update-alternatives pour corriger le lien défaillant, où à défaut le recréer manuellement. Qu’affiche
update-alternatives python3root@vps424505:~# update-alternatives python3
update-alternatives: erreur: paramètre inconnu « python3 »