et quand tu fais un simple su - toto tu termines bien en utilisateur toto ?
oui, bien sûr, avec les fichiers .profile et .bashrc non exécutés
ta commande strace -r su - toto ne prendrait-elle pas le - et le toto comme paramètre de strace plutot que de su ? executant du coup un simple su donc avec le mot de passe de root et non de toto
il faudrait peut-être taper strace -r 'su - toto'
Bien vu, mais … non. J'avais essayé, mais ça ne marche pas : strace prend "su - toto" comme le nom d'un exécutable et non comme une commande avec ses arguments:
$ strace 'su - toto'
strace: su - toto: command not found**
Au passage : j'ai une autre machine que je fais tourner sous OpenMandriva version LX 4.0 Nitrogen qui, elle, est récente (téléchargée et installée l'année dernière). Je viens d'y ajouter strace (absent dans la distribution de base), et j'ai fait le test sur cette autre machine : là aussi "strace su - toto" échoue pour la même raison : mot de passe refusé. Donc, "it's not a bug, it's a feature", je serai curieux d'éclaircir la question (peut-être dans un autre post).
En attendant, le seul moyen que j'ai trouvé jusqu'à présent pour contourner ce problème de mot de passe est de lancer à partir de root (puisque dans ce cas 'su' ne demande pas de saisir le mot de passe) :
# strace -f -o __stracef.root2toto.log su - toto
(avec l'option -f pour que le traçage continue après le fork qui transfère le contrôle de 'su' à 'bash')
Pas facile de s'y retrouver, le fichier de log fait dans les 10000 lignes, et je sèche un peu. Je trouve quand même des trucs du genre :
…
write (1, "lancement de /etc/profile\n", 26) = 26
…
write (1, "lancement de /etc/bashrc\n", 25) = 25
…
ce qui signifie que sous strace lancé par root, le "su - toto" fonctionne correctement et qu'une fois lancé, bash lit les fichiers de démarrage /etc/profile et /etc/bashrc, mais pas les fichiers ~toto/.profile ou ~toto/.bashrc
Là, je fatigue un peu, je vais laisser un peu décanter les choses. Ce que je retiens, c'est que STRACE est vraiment un outil intéressant, mais pas parfait puisque la commande "su - toto" ne se comporte pas pareil selon qu'elle est lancée directement ou via STRACE. Hmmm!…
Les forums de gens bloqués en 2006 sur ce problème-là, si tu en trouves, dis-le moi je suis preneur. Avant de me décider à poster sur ce forum, j'ai quand même cherché un peu sur le web si le problème n'avait pas été posé auparavant, bien sûr. Je n'ai rien trouvé, d'où ce post.
Je suis d'accord avec toi que regarder les logs et vérifier les permissions, c'est la base de la base, et ça fait partie des choses que j'ai faites avant d'appeler de l'aide sur ce forum. Mea culpa, j'ai oublié de le préciser dans mes posts précédents :
-- j'ai été éplucher les fichiers du répertoire /var/log sans rien y trouver de significatif (mais je n'ai peut être pas tout bien regardé, et il y a peut-être d'autres fichiers que ceux de /var/log/ )
-- vérifier les permissions des /etc/profile, /etc/bashrc, etc. etc. ainsi que /bin/su, et jouer à les modifier pour élargir les droits de lecture/exécution, je l'ai fait aussi, sans noter de grande différence (mais je n'ai peut-être pas exploré toutes les combinaisons)
si, si ça existait en 2006, et même probablement bien avant, à une époque où dans le monde UNIX on donnait aux programmes des noms en rapport avec ce qu'ils faisaient, au lieu de leur donner des noms d'oiseau ou de mammifères comme on est obligé de le faire maintenant vu l'inflation de logiciels en circulation (mais on ne va pas se plaindre :-)
pourquoi je n'ai pas utilisé "strace" ? tout simplement parce que j'ignorais l'existence de cet outil, n'en ayant jusqu'à présent jamais eu besoin (pour mes développements, gdb me suffisait).
Mais du coup, ça me semble effectivement pertinent de l'utiliser pour mon problème, et vérification faite, j'ai bien un "strace" sur mon système, je tape donc :
$ strace -r su - toto 2>__strace.log
je saisis en aveugle le mot de passe de toto et ….
rien ! le système refuse d'ouvrir un shell à toto et renvoie plein de choses, dont notamment :
write(2, "su: ", 4su: ) = 4
write(2, "Mot de passe incorrect.", 23Mot de passe incorrect.) = 23
write(2, "\n", 1
) = 1
exit_group(1) = ?
Process 13094 detached
ça commence mal, parce que j'ai bien tapé le bon password. Quelque chose a dû m'échapper, ou bien "strace" est lui aussi dans les choux ?
Bonjour et merci à tous de répondre, mais il me semble nécessaire de recadrer un peu les choses :
-- d'abord, l'objet de ce post n'est pas de discuter des avantages et des inconvénients à travailler en 2020 avec une distribution datant de 2006. Moi je veux bien en discuter, mais dans un autre post, ici c'est hors sujet, à moins qu'on m'explique que mon problème est spécifiquement lié à l'âge de ma distribution.
-- ensuite, les subtilités de l'ordre et des renvois de lecture de tous les fichiers bash_rc, bash_login, profile, etc. sont elles aussi à côté de la plaque, car comme je l'ai précisé à plusieurs reprises, mon problème est qu'AUCUN de ces fichiers n'est lu au démarrage du shell, quel que soit l'utilisateur, à l'exception de ROOT. Et c'est apparu soudainement, après des années de fonctionnement correct de ma plate-forme de travail.
Par expérience, quand un problème de cet ordre apparaît (ça marchait et ça ne marche plus) sans que j'ai fait quoi que ce soit de spécial, c'est généralement un truc bête du genre :
-- la partition sur laquelle le système écrit des fichiers temporaires, ou des fichiers de log, ou d'autres fichiers … est pleine
-- des fichiers nécessaires au fonctionnement de l'application ont été effacés, corrompus, ou leurs droits ont été modifiés par accident sans que je m'en rende compte
-- (en théorie, ça ne m'est encore jamais arrivé sous LINUX) : un virus informatique
Or, dans le cas présent, les fichiers de lancement (bashrc, profile …) sont là, ils fonctionnent parfaitement puisque je peux, une fois le shell démarré, les lancer à la main en tapant par exemple
$ . ~/.bashrc
Je m'en suis assuré en plaçant EN TÊTE DE CHACUN DE CES FICHIERS, avant toute autre instruction, une ligne de traçage
echo "lancement de (nom du fichier)"
… et la question est : pourquoi aucun des fichiers de démarrage n'est-il lu ?
La faute à BASH lui-même ? la faute à LOGIN / SU qui lancerait BASH avec de mauvais arguments ?
Je sèche lamentablement, d'où cet appel à l'aide, et si ça continue, je vais finir par adopter la solution extrême : réinstaller le système d'exploitation (ce que je ne peux malheureusement pas faire pour l'instant car je n'ai pas sous la main de DVD d'installation)
En attendant je reste ouvert à toutes les pistes … merci d'avance
Bonjour NeoX, et merci du tuyau, mais la présence ou l'absence de bash_profile ou bash_login ne semble pas jouer ici :
aucun des comptes utilisateurs n'a de ~/.bash_login, certains ont un ~/.bash_profile et d'autre non, mais ils sont tous traités à la même enseigne : hormis ROOT, aucun n'a ses fichiers de démarrage lancés à l'ouverture de BASH
C'est ma plate-forme de développement : en 25 ans j'ai écrit à mon usage personnel et professionnel des tonnes et des tonnes de programmes et d'utilitaires, en C, C++, lex/yacc, bash, awk, perl, php et j'en passe, et j'en avais marre de passer ma vie à les upgrader à chaque fois que je changeais de version des compilateurs, voire carrément de distribution. J'en suis venu à adopter une ligne de conduite très simple : tant qu'une installation fonctionne, je la garde.
Alors bien sûr, quand je veux surfer sur le web, lire des vidéos en streaming, etc. etc., j'ai un autre ordi qui tourne sous une version plus récente de Mandriva, mais le coeur de mes applis, ma comptabilité, mes utilitaires … reste sous Mandriva 2006.
Bonjour JDD, merci pour ta réponse, mais ça ne fait pas avancer mon problème. Tout ça je le sais déjà, quoique je ne me suis jamais posé la question de savoir dans quel ordre étaient lus /etc/bashrc, /etc/profile, ~/.bashrc et ~/.profile.
J'ai rajouté au début de chacun de ces fichiers une ligne de traçage :
echo "lancement de /etc/profile" # dans /etc/profile
et l'équivalent dans /etc/bashrc, ~/.profile, ~/.bashrc
… et voilà ce que ça donne pour un login root (qui n'a pas de fichier .profile) :
-bash-3.00$ su -
Password:
lancement de /etc/profile
lancement de /root/.bashrc
lancement de /etc/basrc
[root@pc-126 ~]#
… et voilà ce que ça donne pour un login toto
-bash-3.00$ su - toto
Password:
-bash-3.00$ whoami
toto
-bash-3.00$
Je suis bien logué sous toto, mais aucun des fichiers /etc/profile, /etc/bashrc, ~toto/.bashrc, ~toto/.profile n'a été exécuté. Pourtant ils sont bien là (le login de root les exécute sans problème) et ils ont les bons droits (du moins il me semble) :
-bash-3.00$ ls -l /etc/profile /etc/bashrc
-rw-r--r-- 1 root root 944 Jun 2109:24 /etc/bashrc
-rw-r--r-- 1 root root 963 Jun 2109:23 /etc/profile
-bash-3.00$
Bref, tout devrait fonctionner, ça fonctionnait d'ailleurs parfaitement jusqu'à cette semaine, et ça ne fonctionne plus, sans que j'arrive pas à comprendre pourquoi. J'en suis donc à chercher des pistes.
[^] # Re: recadrage
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
oui, bien sûr, avec les fichiers .profile et .bashrc non exécutés
Bien vu, mais … non. J'avais essayé, mais ça ne marche pas : strace prend "su - toto" comme le nom d'un exécutable et non comme une commande avec ses arguments:
$ strace 'su - toto'
strace: su - toto: command not found**
Au passage : j'ai une autre machine que je fais tourner sous OpenMandriva version LX 4.0 Nitrogen qui, elle, est récente (téléchargée et installée l'année dernière). Je viens d'y ajouter strace (absent dans la distribution de base), et j'ai fait le test sur cette autre machine : là aussi "strace su - toto" échoue pour la même raison : mot de passe refusé. Donc, "it's not a bug, it's a feature", je serai curieux d'éclaircir la question (peut-être dans un autre post).
En attendant, le seul moyen que j'ai trouvé jusqu'à présent pour contourner ce problème de mot de passe est de lancer à partir de root (puisque dans ce cas 'su' ne demande pas de saisir le mot de passe) :
# strace -f -o __stracef.root2toto.log su - toto
(avec l'option -f pour que le traçage continue après le fork qui transfère le contrôle de 'su' à 'bash')
Pas facile de s'y retrouver, le fichier de log fait dans les 10000 lignes, et je sèche un peu. Je trouve quand même des trucs du genre :
…
write (1, "lancement de /etc/profile\n", 26) = 26
…
write (1, "lancement de /etc/bashrc\n", 25) = 25
…
ce qui signifie que sous strace lancé par root, le "su - toto" fonctionne correctement et qu'une fois lancé, bash lit les fichiers de démarrage /etc/profile et /etc/bashrc, mais pas les fichiers ~toto/.profile ou ~toto/.bashrc
Là, je fatigue un peu, je vais laisser un peu décanter les choses. Ce que je retiens, c'est que STRACE est vraiment un outil intéressant, mais pas parfait puisque la commande "su - toto" ne se comporte pas pareil selon qu'elle est lancée directement ou via STRACE. Hmmm!…
[^] # Re: recadrage
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
Kerro,
Les forums de gens bloqués en 2006 sur ce problème-là, si tu en trouves, dis-le moi je suis preneur. Avant de me décider à poster sur ce forum, j'ai quand même cherché un peu sur le web si le problème n'avait pas été posé auparavant, bien sûr. Je n'ai rien trouvé, d'où ce post.
Je suis d'accord avec toi que regarder les logs et vérifier les permissions, c'est la base de la base, et ça fait partie des choses que j'ai faites avant d'appeler de l'aide sur ce forum. Mea culpa, j'ai oublié de le préciser dans mes posts précédents :
-- j'ai été éplucher les fichiers du répertoire /var/log sans rien y trouver de significatif (mais je n'ai peut être pas tout bien regardé, et il y a peut-être d'autres fichiers que ceux de /var/log/ )
-- vérifier les permissions des /etc/profile, /etc/bashrc, etc. etc. ainsi que /bin/su, et jouer à les modifier pour élargir les droits de lecture/exécution, je l'ai fait aussi, sans noter de grande différence (mais je n'ai peut-être pas exploré toutes les combinaisons)
Pour info :
[root@pc]# ll /etc/profile /etc/bashrc /bin/su /bin/login
-rwsr-sr-x 1 root root 19516 sep 20 2005 /bin/login*
-rwsr-xr-x 1 root root 20308 aoû 18 2005 /bin/su*
-rw-r--r-- 1 root root 944 jun 21 09:24 /etc/bashrc
-rw-r--r-- 1 root root 963 jun 21 09:23 /etc/profile
Par contre, "remplacer par le nécessaire pour capturer les arguments", là si tu peux préciser, je suis aussi preneur. Tu fais allusion à "strace" ?
[^] # Re: recadrage
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
si, si ça existait en 2006, et même probablement bien avant, à une époque où dans le monde UNIX on donnait aux programmes des noms en rapport avec ce qu'ils faisaient, au lieu de leur donner des noms d'oiseau ou de mammifères comme on est obligé de le faire maintenant vu l'inflation de logiciels en circulation (mais on ne va pas se plaindre :-)
[^] # Re: recadrage
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
pourquoi je n'ai pas utilisé "strace" ? tout simplement parce que j'ignorais l'existence de cet outil, n'en ayant jusqu'à présent jamais eu besoin (pour mes développements, gdb me suffisait).
Mais du coup, ça me semble effectivement pertinent de l'utiliser pour mon problème, et vérification faite, j'ai bien un "strace" sur mon système, je tape donc :
$ strace -r su - toto 2>__strace.log
je saisis en aveugle le mot de passe de toto et ….
rien ! le système refuse d'ouvrir un shell à toto et renvoie plein de choses, dont notamment :
write(2, "su: ", 4su: ) = 4
write(2, "Mot de passe incorrect.", 23Mot de passe incorrect.) = 23
write(2, "\n", 1
) = 1
exit_group(1) = ?
Process 13094 detached
ça commence mal, parce que j'ai bien tapé le bon password. Quelque chose a dû m'échapper, ou bien "strace" est lui aussi dans les choux ?
# recadrage
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
Bonjour et merci à tous de répondre, mais il me semble nécessaire de recadrer un peu les choses :
-- d'abord, l'objet de ce post n'est pas de discuter des avantages et des inconvénients à travailler en 2020 avec une distribution datant de 2006. Moi je veux bien en discuter, mais dans un autre post, ici c'est hors sujet, à moins qu'on m'explique que mon problème est spécifiquement lié à l'âge de ma distribution.
-- ensuite, les subtilités de l'ordre et des renvois de lecture de tous les fichiers bash_rc, bash_login, profile, etc. sont elles aussi à côté de la plaque, car comme je l'ai précisé à plusieurs reprises, mon problème est qu'AUCUN de ces fichiers n'est lu au démarrage du shell, quel que soit l'utilisateur, à l'exception de ROOT. Et c'est apparu soudainement, après des années de fonctionnement correct de ma plate-forme de travail.
Par expérience, quand un problème de cet ordre apparaît (ça marchait et ça ne marche plus) sans que j'ai fait quoi que ce soit de spécial, c'est généralement un truc bête du genre :
-- la partition sur laquelle le système écrit des fichiers temporaires, ou des fichiers de log, ou d'autres fichiers … est pleine
-- des fichiers nécessaires au fonctionnement de l'application ont été effacés, corrompus, ou leurs droits ont été modifiés par accident sans que je m'en rende compte
-- (en théorie, ça ne m'est encore jamais arrivé sous LINUX) : un virus informatique
Or, dans le cas présent, les fichiers de lancement (bashrc, profile …) sont là, ils fonctionnent parfaitement puisque je peux, une fois le shell démarré, les lancer à la main en tapant par exemple
$ . ~/.bashrc
Je m'en suis assuré en plaçant EN TÊTE DE CHACUN DE CES FICHIERS, avant toute autre instruction, une ligne de traçage
echo "lancement de (nom du fichier)"
… et la question est : pourquoi aucun des fichiers de démarrage n'est-il lu ?
La faute à BASH lui-même ? la faute à LOGIN / SU qui lancerait BASH avec de mauvais arguments ?
Je sèche lamentablement, d'où cet appel à l'aide, et si ça continue, je vais finir par adopter la solution extrême : réinstaller le système d'exploitation (ce que je ne peux malheureusement pas faire pour l'instant car je n'ai pas sous la main de DVD d'installation)
En attendant je reste ouvert à toutes les pistes … merci d'avance
[^] # Re: Fichiers d'initialisation bash
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 1.
Bonjour NeoX, et merci du tuyau, mais la présence ou l'absence de bash_profile ou bash_login ne semble pas jouer ici :
aucun des comptes utilisateurs n'a de ~/.bash_login, certains ont un ~/.bash_profile et d'autre non, mais ils sont tous traités à la même enseigne : hormis ROOT, aucun n'a ses fichiers de démarrage lancés à l'ouverture de BASH
[^] # Re: HS
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 2.
C'est ma plate-forme de développement : en 25 ans j'ai écrit à mon usage personnel et professionnel des tonnes et des tonnes de programmes et d'utilitaires, en C, C++, lex/yacc, bash, awk, perl, php et j'en passe, et j'en avais marre de passer ma vie à les upgrader à chaque fois que je changeais de version des compilateurs, voire carrément de distribution. J'en suis venu à adopter une ligne de conduite très simple : tant qu'une installation fonctionne, je la garde.
Alors bien sûr, quand je veux surfer sur le web, lire des vidéos en streaming, etc. etc., j'ai un autre ordi qui tourne sous une version plus récente de Mandriva, mais le coeur de mes applis, ma comptabilité, mes utilitaires … reste sous Mandriva 2006.
[^] # Re: Fichiers d'initialisation bash
Posté par andrias . En réponse au message problème d'exécution de bashrc lors du lancement d'un shell. Évalué à 2. Dernière modification le 22 juin 2020 à 15:33.
Bonjour JDD, merci pour ta réponse, mais ça ne fait pas avancer mon problème. Tout ça je le sais déjà, quoique je ne me suis jamais posé la question de savoir dans quel ordre étaient lus /etc/bashrc, /etc/profile, ~/.bashrc et ~/.profile.
J'ai rajouté au début de chacun de ces fichiers une ligne de traçage :
echo "lancement de /etc/profile" # dans /etc/profile
et l'équivalent dans /etc/bashrc, ~/.profile, ~/.bashrc
… et voilà ce que ça donne pour un login root (qui n'a pas de fichier .profile) :
… et voilà ce que ça donne pour un login toto
Je suis bien logué sous toto, mais aucun des fichiers /etc/profile, /etc/bashrc, ~toto/.bashrc, ~toto/.profile n'a été exécuté. Pourtant ils sont bien là (le login de root les exécute sans problème) et ils ont les bons droits (du moins il me semble) :
Bref, tout devrait fonctionner, ça fonctionnait d'ailleurs parfaitement jusqu'à cette semaine, et ça ne fonctionne plus, sans que j'arrive pas à comprendre pourquoi. J'en suis donc à chercher des pistes.