Shell
Le
BERTRAND Jo=c3=abl
Bonjour à tous,
Considérons mon infrastructure. J'ai un serveur principal qui tourne
sous NetBSD (serveur de boot, serveur NIS/NFSv3) et qui se débrouille
pour exporter tout ce qu'il faut à un certain nombre de stations
diskless. Ces stations fonctionnent sous FreeBSD et Linux/Debian.
Problème : bash est par défaut sous Debian dans /bin/bash. Sous
FreeBSD, il se trouve dans /usr/local/bin/bash. Sous NetBSD, c'est dans
/usr/pkg/bin/bash.
Je me suis cru malin en écrivant :
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash
else
/bin/sh
fi
fi
exit 0
et en déclarant ce script comme shell de l'utilisateur.
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun
problème. Mais il m'est impossible d'effectuer en sftp.
Je suppose qu'il existe un mécanisme dans ssh spécifique à sftp pour
refuser cette astuce mais je sèche.
Une idée ?
Bien cordialement,
JKB
Considérons mon infrastructure. J'ai un serveur principal qui tourne
sous NetBSD (serveur de boot, serveur NIS/NFSv3) et qui se débrouille
pour exporter tout ce qu'il faut à un certain nombre de stations
diskless. Ces stations fonctionnent sous FreeBSD et Linux/Debian.
Problème : bash est par défaut sous Debian dans /bin/bash. Sous
FreeBSD, il se trouve dans /usr/local/bin/bash. Sous NetBSD, c'est dans
/usr/pkg/bin/bash.
Je me suis cru malin en écrivant :
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash
else
/bin/sh
fi
fi
exit 0
et en déclarant ce script comme shell de l'utilisateur.
J'arrive à me connecter à n'importe quelle machine en ssh sans aucun
problème. Mais il m'est impossible d'effectuer en sftp.
Je suppose qu'il existe un mécanisme dans ssh spécifique à sftp pour
refuser cette astuce mais je sèche.
Une idée ?
Bien cordialement,
JKB
Via env, cela donne quoi ?
#!/usr/bin/env bash
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
Pareil. Mais /bin/sh étant présent sur tous les systèmes, je doute que
ce soit le fautif (d'autant que je peux me connecter par ssh sur toutes
les machines).
Bien cordialement,
JKB
Bonsoir,
Au risque de passer à côté du sujet, j'ai rencontré un problème
similaire. Si j'édite le fichier de ressource de mon shell pour
lui faire afficher quelque chose, alors ça me plante sftp, mais
pas ssh :
$ head -n2 ~/.bashrc
#!/bin/bash
echo plante
$ ssh localhost
plante
$ echo 'Dans une session ssh... :)'
Dans une session ssh... :)
$ sftp localhost
Received message too long 1886151022
$ echo 'Pas dans une session sftp... :('
Pas dans une session sftp... :(
« Il suffit » d'enlever tout ce qui pourrait écrire dans stdout
pour corriger le problème. Si j'efface mon « echo plante »,
alors le problème est corrigé :
$ head -n2 ~/.bashrc
#!/bin/bash
$ sftp localhost
Connected to localhost.
sftp>
Sauf que, et à moins que j'ai loupé quelque chose, votre script
ne devrait pas engendrer de message dans stdout. Est-ce que le
problème se présentait si vous aviez l'un des bash codé en dur
dans votre entrée NIS, en vous loguant en sftp sur le système
correspondant ?
À plus,
--
Étienne Mollier
Effectivement, le script en question ne renvoie rien sur stdout (ni sur
stderr du reste).
Si je mets l'un des bash en dur, ça fonctionne sur le poste en question
(mais pas sur les autres...).
La question que je me suis posé est de savoir si /etc/shells doit
contenir mon script ou non. Visiblement non puisque l'exécutable réel
est le vrai shell.
Bien cordialement,
JKB
Bonjour,
Pardon, j'ai envoyé mon message en privé au lieu de l'envoyer sur la liste.
Je reposte.
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
Ce script ne prend en charge aucun argument alors qu'en principe
c'est le cas d'un shell. Éventuellement tenter de faire ça (où
"$@" permet de reprendre les arguments passés au script) :
------------------------
#!/bin/sh
if [ `uname -s` = Linux ]; then
/bin/bash "$@"
else
if [ -e /usr/pkg/bin/bash ]; then
/usr/pkg/bin/bash "$@"
else
/bin/sh "$@"
fi
fi
------------------------
Enfin si bash est correctement installé sur le système, la logique
voudrait qu'il soit dans le PATH. Dans ce cas, je tenterais plutôt :
if which bash >/dev/null
then
bash "$@"
else
/bin/sh "$@"
fi
--
François Lafont
Je remplace juste ce test par celui-là
if [ "$(uname -s)" = Linux ]; then
cela permet d'assurer à 100% d'avoir une vraie chaîne à gauche
et sur le principe, le $() est plus sur que le `` (car récursif).
gabriel
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
D'accord, on peut écarter ce problème de sortie texte.
Dans le doute, je l'y mettrais tout de même. Si j'en juge par le
manuel, les vénérables dæmons ftp pouvaient interdire l'accès
s'ils ne trouvaient pas le shell de l'utilisateur dans la liste
fournie par le fichier /etc/shells.
man 5 shells :
Ça n'apparaît pas dans le manuel de sftp, mais rien ne dit qu'il
n'a pas hérité, ou n'héritera pas, de ce comportement.
François Lafont, le 2018-02-13 :
Bien vu, sans le transfert des arguments, l'option de login shell
« -l » ne peut pas être transférée par le wrapper au shell du
système. Il y a fort à parier que ça aide à résoudre pas mal de
problèmes. :-)
Pour aller encore plus loin, il est possible de transférer
complètement la main au shell et obtenir du même coup la remontée
des éventuels codes d'erreurs en ajoutant des directives exec.
Cela donnerait :
#!/bin/sh
if which bash >/dev/null
then
exec bash "$@"
fi
exec /bin/sh "$@"
À plus,
--
Étienne Mollier
Ah oui, tout à fait, c'est encore mieux avec le exec. :)
--
François Lafont
Bonsoir à tous,
Je vais regarder tout cela attentivement et ferai un retour dès que
possible (j'ai un truc beaucoup plus important sur le feu).
Bien cordialement,
--
http://www.systella.fr