Commandes non reconnues par root

Support Debian
Tags: #<Tag:0x00007fc9db0b69c0>
#1

Bonjour à tous,

C’est mon premier post ici, je n’ai pas aperçu de section de présentation mais s’il y en a une je mettrai quelques mots afin que vous cerniez mieux mon profil et mes attentes.

J’ai installé hier soir Debian 10 sur une partition de test de mon portable. (j’étais sous Deb9 depuis pas mal de temps sur ma partition courante)

Passé les galères des firmwares non reconnus j’ai pu me lancer dans l’installation de tous mes logiciels et outils favoris et à la personnalisation de mon bureau.

J’ai été vite freiné dans mes hardeurs au moment d’ajouter mon utilisateur, crée lors de l’installation, dans le groupe sudo

En effet après être passé en root via “su”, le bash ne reconnaissait pas les commandes “adduser” ou “useradd” !!! Alors que lorsque j’étais loggé en utilisateur je les voyais très bien ainsi que les manpages mais bien sur par l’autorisation de m’en servir.

Pas mal de recherches plus tard (sur le web), j’essaye de faire directement "/sbin/adduser monuser sudo`" et là enfin ça fonctionne. ( bon normal j’ai lancé directement l’exécutable me direz vous)

Avez vous une idée de la source du problème ? un paramètre système/chemin mal configuré durant l’install ? une nouvelle sécurité de Deb10 (j’ai lu qu’elle avait fortement progressé)? Car si à chaque fois que j’ai une manip qui requiert “su” il ne reconnait pas les commandes de base, je vais être bien embêté !!!

Bon sinon j’ouvrirai aussi un autre post concernant dconf/gnome car je n’ai pas retrouvé non plus tous les paramètres que j’avais l’habitude de personnalisé…

#2

salut

  • su tout seul passe en root sur le path de l’utilisateur, lequel n’a pas accès à tout. il suffit de le vérifier par
env | grep -i path
  • Pour passer root avec l’environnement de root et tous ses droits il faut utiliser
su -

En français: su suivi d’un tiret

repasse la commande env | grep -i path et tu noteras la différence

su -
Mot de passe : 
root@debian:~# env | grep -i path
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
#3

sur mon install en Deb9

su

et

su -

me font rentré dans une session où le path retourne la même chose ! Tu pense que j’avais modifié les path de l’utilisateur ? je n’en ai pas souvenir.

#4

https://manpages.debian.org/stretch/login/su.1.fr.html

forcement tu as du appliquer un tuto quelconque qui casse la sécurité

#5

lorsque je fais

env | grep -i path

en tant qu’utilisateur effectivement je ne vois pas :/sbin

mais dans le cas de

su

avec ou sans option j’ai :/sbin qui apparait dans le path.

Par contre je vois bien une différence dans le prompt au niveau du répertoire courant, /root avec l’option et /home/user sans le “-”.

J’ai regardé un peu mon .bash-history et je ne vois pas la manipulation que j’ai fait pour en arriver là sur mon Debian9. En tout cas je te remercie sur mes nouvelles install si je suis amené à le refaire maintenant je saurai le faire proprement.

Reste à trouver comment restaurer la sécurité que j’aurais cassé sur mes autres postes.

#6

Lors de l’install de ma debian buster, j’ai aussi rencontré ce problème (la commande reboot pas reconnue en su. Obligé de se déloguer et de se reloguer root pour pouvoir rebooter la machine).

Depuis, j’ai installé sudo, ajouté mon username à la fin de la ligne “sudo” dans /etc/group et tout roule.

Amicalement.

Jean-Marie

#7

Pour ma part j’ai eu ce problème sur mon serveur de développement, j’ai juste ajouter /sbin à la variable PATH pour pouvoir avoir les bonnes commandes.

un exemple ici: http://dev.petitchevalroux.net/linux/ajouter-repertoire-dans-path-linux.253.html

#8

Beaucoup de problèmes avec Sudo depuis buster.

#9

Bonjour Ricardo

Avec sudo
l’équivalent de

su -

qui permet d’obtenir un login shell sous le compte root
est :

sudo -i

EDIT:

Le but de la commande su avec l’option –login (ou -l ou - )
est d’ouvrir un shell “propre” => qui ne soit ni un sous-shell ni une imbrication de shells.

la variable SHLVL doit être à 1 pour indiquer qu’on n’est pas dans une imbrication de shells
et la variable BASH_SUBSHELL doit être à 0 pour indiquer qu’on n’est pas dans un sous-shell

Pour vérifier que vous êtes bien dans un login shell
qui n’est ni un sous-shell ni le résultat d’une imbrication de shells
la commande

echo ${0::1}

ne doit retourner qu’un simple tiret :

michel@debg53sw:~$ su -
Mot de passe : 
root@debg53sw:~# 
root@debg53sw:~# echo ${0::1}
-
root@debg53sw:~# 
root@debg53sw:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@debg53sw:~# 
root@debg53sw:~# echo $SHLVL
1
root@debg53sw:~# 
root@debg53sw:~# echo $BASH_SUBSHELL
0
root@debg53sw:~#

Voir aussi :
unix.stackexchange -> difference between login shell and non login shell

Je reviendrai plus tard ajouter d’autres infos à ce message,
là, je suis au bar du coin avec un Pastis et sur mon smartphone,
ça fait trois handicaps pour rédiger un message cohérent :crazy_face:

#10

Bonjour,
Trois ?

#11

Oui, j’aurai plutôt dû dire “…au moins trois…”
puisque c’est sans compter tous ceux que la MDPH a reconnu jusqu’à présent.

#12

Merci, MicP.
J’ai pris note que ‘sudo’ devient ‘sudo -i’
Je suppose qu’il en va de même quand on est dans une console graphique, ce qui m’arrive quand il faut recopier un texte pour le coller ailleurs, car en console Alt F4 (par exemple) il est difficile de copier.

Dans le même style, tu ne saurais pas par quoi a été remplacé ‘startx’ ???

#13

En fait,

sudo -i

c’est pour ouvrir un “login shell” sous le compte root <=> avec toutes les variables d’environnement initialisées comme quand le compte root vient juste d’ouvrir une session shell.

C’est l’équivalent de

su -

Aucune idée :frowning_face:

J’utilise XFCE et c’est le gestionnaire de session graphique lightdm qui se charge de démarrer le serveur X pour moi.

Pour KDE, il y avait KDM mais je crois qu’avec buster (ou plus précisément depuis stretch),
c’est SDDM (Simple Desktop Display Manager) qui le remplace

#14

Oui, pour KDM, je sais.
Problème, j’ai un de mes Buster qui est fatiguée, de ma faute.
Mon KDE ouvre aussi en automatique, mais là, j’aurais voulu tester sous console, pour voir si je peux quand même ouvrir X, mais …

#15

https://www.debian.org/doc/manuals/debian-reference/ch01.fr.html#_the_literal_path_literal_variable

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.fr.html#su-environment-variables

1 J'aime
#16

Super ces liens, merci du partage.

#17

celle là explique la nouveauté dans Buster , en particulier su

https://wiki.debian.org/NewInBuster