script distant par ssh

Christophe PEREZ <christophe@novazur.com> writes:

Bonjour,

Sur mon serveur sous Mdk 9.1, j'ai un script qui pilote la carte radio FM.

J'ai connecté la sortie audio de cette carte en entrée sur la carte son de
mon poste (en effet, je ne suis pas encore parvenu à faire du streaming
audio de cette carte)

J'ai donc fait un script, que je lance sur mon poste client, qui
communique avec le serveur via ssh, du genre :
ssh -f serveur "/usr/local/perso/radi list > /tmp/radio.list
(clef autorisée etc...)

Or, avec ce principe, chaque action a un retard de plusieurs secondes, à
cause de l'authentification je suppose.

Quelle solution pourrais-je adopter pour n'avoir jamais ce délai, ou alors
au pire, qu'une fois, au lancement du script.
Quelque chose qui m'ouvrirait un "canal permanent" au lieu d'une
authentification à chaque action, ou alors un autre protocole ? telnet ?

Merci d'avance pour vos suggestions, mais restez simple svp, tout ceci
n'est vraiment qu'un début pour moi ;-)

--
Christophe PEREZ

On pourrait essayer avec un algorithme de cryptage différent ou avec
des clés moins grandes, qui serait plus rapide.


On pourrait activer une liaison PPP sur SSH et alors on utiliserait
librement des protocoles plus légers comme rsh sans problème sur la
liaison PPP.


On pourrait envisager d'avoir un canal SSH ouvert, et un script au
deux bouts communiquant. Le doute que j'ai avec cette solution, c'est
que je note que mes sessions SSH de longue durée et inactives sont
souvent coupées.

Quelque chose comme ça:

#!/bin/bash
mkdir /tmp/commandes > /dev/null 2>&1 || true
if [ "$1" = "--daemon" ] ; then
cd /tmp/commandes
while sleep 1 ; do
if [ -r cmd1 ] ; then
rm cmd1
echo cmd1
elif [ -r cmd2 ] ; then
rm cmd2
echo cmd2
else
echo ping
fi
done | ssh remote 'while read command ; do case $command in cmd1) "/usr/local/perso/radi list > /tmp/radio.list" ;; cmd2) /usr/local/bin/command-2 ;; *) ;; esac ; done' & disown
else
case "$1" in
--cmd1) touch /tmp/commandes/cmd1 ;;
--cmd2) touch /tmp/commandes/cmd2 ;;
*) echo "unknown command $1" ;;
esac
fi



On pourrait dire que tout ça se passe sur le réseau local entre deux
machines dont on a seul l'accès physique au même endroit, alors on n'a
pas vraiment besoin d'un canal encrypté et authentifié. rsh pourrait
suffire. Ou un démon sur le serveur de radio qui écouterait sur un
port donné et qui se contenterait de n'accepter que les connections
venant de l'IP de la machine cliente locale. Un simple telnet ou
netcat sur le port en question permetrait de déclancher les commandes.


Peut être que SSL serait plus adapté que SSH?

--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

Le Mon, 18 Aug 2003 02:42:43 +0200, Pascal Bourguignon a écrit:

[... beaucoup de choses]

On pourrait envisager d'avoir un canal SSH ouvert, et un script au
deux bouts communiquant.

Oui, c'est un peu ce à quoi je pensais.

Quelque chose comme ça:


#!/bin/bash
mkdir /tmp/commandes > /dev/null 2>&1 || true
[...]

Je vais décortiquer ça, pour comprendre, avant d'essayer d'appliquer.

On pourrait dire que tout ça se passe sur le réseau local entre deux
machines dont on a seul l'accès physique au même endroit, alors on n'a
pas vraiment besoin d'un canal encrypté et authentifié.

C'est ce que je me disais aussi.

rsh pourrait suffire.

Faut que je regarde ce que c'est que rsh et comment ça fonctionne alors.

Ou un démon sur le serveur de radio qui écouterait sur un
port donné et qui se contenterait de n'accepter que les connections
venant de l'IP de la machine cliente locale.

Ça, ça aurait été le top à mon avis, mais je ne saurai pas faire ce démon.

Un simple telnet ou
netcat sur le port en question permetrait de déclancher les commandes.

C'est effectivement l'idéal, j'y avais pensé, mais ne saurait pas mettre en
oeuvre.

Peut être que SSL serait plus adapté que SSH?

Connais pas non plus.
Bon, je m'oriente vers quoi moi alors ? :-)

Merci pour toutes ces idées.


--
Christophe PEREZ

Christophe PEREZ <christophe@novazur.com> wrote:

J'ai donc fait un script, que je lance sur mon poste client, qui
communique avec le serveur via ssh, du genre :
ssh -f serveur "/usr/local/perso/radi list > /tmp/radio.list
(clef autorisée etc...)

Or, avec ce principe, chaque action a un retard de plusieurs secondes, à
cause de l'authentification je suppose.

Si l'authentification n'a pas d'interet, tu peux faire un serveur pour
inetd: sur le serveur, tu met ca dans ton /etc/services
radi 5000/tcp

Dans /etc/inetd.conf:
radi stream tcp nowait root /usr/local/perso/radi radi list

kill -1 sur inetd. Ensuite si tu te connectes sur le port 5000 de la
machine, tu récuperes la sortie de ton script. Tu peux faire ca avec
telnet, ou avec netcat si ca ne fait pas tout à fait ce qu'il te faut.

Eventuellement met le client dans /etc/hosts sur le serveur pour eviter
de eprdre du temps sur les résolutions de noms, si ton inetd est linké
avec les tcp wrappers, par exemple.

--
Emmanuel Dreyfus
manu@netbsd.org

Le Mon, 18 Aug 2003 09:00:27 +0200, Emmanuel Dreyfus a écrit:

Si l'authentification n'a pas d'interet, tu peux faire un serveur pour
inetd: sur le serveur, tu met ca dans ton /etc/services
radi 5000/tcp

Dans /etc/inetd.conf:
radi stream tcp nowait root /usr/local/perso/radi radi list

Je pinaille, mais avec xinetd ça donnerait quoi ?
Et puis, je n'ai pas qu'une seule option que je passe à radi, "list"
n'était qu'un exemple, et elle ne peuvent être connues d'avance puisque ça
peut être un nom de station, un fréquence, etc...

kill -1 sur inetd. Ensuite si tu te connectes sur le port 5000 de la
machine, tu récuperes la sortie de ton script. Tu peux faire ca avec
telnet, ou avec netcat si ca ne fait pas tout à fait ce qu'il te faut.

Ça aussi, ça me laisse un peu perplexe, par méconnaissance.

Eventuellement met le client dans /etc/hosts sur le serveur pour eviter
de eprdre du temps sur les résolutions de noms, si ton inetd est linké
avec les tcp wrappers, par exemple.

De plus en plus perplexe (tcp-wrappers) :-)

Bon, j'ai résolu mon problème, grace à votre aide en :
1) mettant le script sur le serveur, et en exportant juste l'affichage
graphique, donc lancement d'un seule commande à distance, les autres
s'effectuant en local sur le serveur.
(Je voulais depuis longtemps m'essayer à ces exports graphiques :-) )

2) en utilisant rsh, relativement simple finalement.

Maintenant, c'est nickel, c'est immédiat comme réaction, le script est
centralisé sur le serveur, inutile de le mettre sur plusieurs postes (oui,
j'en ai plusieurs côte à côte).
Pour info, le script de commande, je l'ai fait en tcl/tk, mon
apprentissage aussi.
J'ai juste eu à modifier un peu le script pour gérer les droits sur les
fichiers créés, si plusieurs utilisateur lance cette interface.

Ceci dit, si le principe en haut (inet->xinetd) peut m'être un peu plus
détaillé, avec la possibilité de passer n'importe qu'elle option, ça me
plairait bien d'explorer un peu cette voix, par pure curiosité.

Merci à tous les 2 pour vos réponses.

--
Christophe PEREZ

Christophe PEREZ <christophe@novazur.com> wrote:

Dans /etc/inetd.conf:
radi stream tcp nowait root /usr/local/perso/radi radi list

Je pinaille, mais avec xinetd ça donnerait quoi ?

La même chose en plus compliqué. Recopie le fichier de config de telnet,
met ton port radi à la place du port telnet, et /usr/local/perso/radi à
la place de telnetd. Vire les options données à telnetd.

Et puis, je n'ai pas qu'une seule option que je passe à radi, "list"
n'était qu'un exemple, et elle ne peuvent être connues d'avance puisque ça
peut être un nom de station, un fréquence, etc...

Dans ce cas modifie ton script pour prendre les options sur la ligne de
commande, ou passe par xargs:

radi stream tcp nowait root /usr/bin/xargs xargs /usr/local/perso/radi

kill -1 sur inetd. Ensuite si tu te connectes sur le port 5000 de la
machine, tu récuperes la sortie de ton script. Tu peux faire ca avec
telnet, ou avec netcat si ca ne fait pas tout à fait ce qu'il te faut.
Ça aussi, ça me laisse un peu perplexe, par méconnaissance.

client$ echo "list" | nc serveur 5000

(netcat est souvent installé en tant que nc). Tu peux remplacer netcat
par telnet, mais ca pose parfois des petits soucis.

Eventuellement met le client dans /etc/hosts sur le serveur pour eviter
de eprdre du temps sur les résolutions de noms, si ton inetd est linké
avec les tcp wrappers, par exemple.
De plus en plus perplexe (tcp-wrappers) :-)

Un filtre qui permet de restreindre des services à certaines adresses.
Les programes qui l'utilisent passent par /etc/hosts.allow et
/etc/hosts.deny pour savoir qui passe ou pas. Et pour verifier il faut
resoudre les noms, ce qui prends un peu de temps.

--
Emmanuel Dreyfus
manu@netbsd.org

Le Mon, 18 Aug 2003 23:32:11 +0200, Emmanuel Dreyfus a écrit:

La même chose en plus compliqué. Recopie le fichier de config de telnet,
met ton port radi à la place du port telnet, et /usr/local/perso/radi à
la place de telnetd. Vire les options données à telnetd.

Ok, c'est plus clair.

J'ai donc au départ :

# cat /etc/xinetd.d/radio
# default: off
# description: Radio
service radio
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/local/perso/radi
disable = no
}

La connexion par telnet, ou nc, me lance bien le script radi, c'est un
excellent début :-)

Dans ce cas modifie ton script pour prendre les options sur la ligne de
commande

Mais... mon script reçoit déjà les arguments par la ligne de commande
puisque sur le serveur je fais "/usr/local/perso/radi list" pour avoir la
liste des stations, "radi on" pour mettre en route, "radi off" pour couper
etc...
Je ne comprends pas bien, là.

, ou passe par xargs:

radi stream tcp nowait root /usr/bin/xargs xargs /usr/local/perso/radi

Soit, mais la modif de la ligne :
server = /usr/local/perso/radi
par :
server = /usr/bin/xargs xargs /usr/local/perso/radi
ou en :
server = /usr/bin/xargs /usr/local/perso/radi

me provoque l'erreur :
xinetd[14747]: Must specify a server in radio

client$ echo "list" | nc serveur 5000

Ok, mais ne passe pas pour l'instant puisque mon script ne reçoit pas les
arguments

(netcat est souvent installé en tant que nc). Tu peux remplacer netcat
par telnet, mais ca pose parfois des petits soucis.

Ok, effectivement, nc installé.

Un filtre qui permet de restreindre des services à certaines adresses.
Les programes qui l'utilisent passent par /etc/hosts.allow et
/etc/hosts.deny pour savoir qui passe ou pas. Et pour verifier il faut
resoudre les noms, ce qui prends un peu de temps.

Je comprends.
C'est bon, les autorisations dans /etc/hosts.allow laissent passer, et le
délai est tout à fait correct.

--
Christophe PEREZ

Christophe PEREZ <christophe@novazur.com> wrote:

Soit, mais la modif de la ligne :
server = /usr/local/perso/radi
par :
server = /usr/bin/xargs xargs /usr/local/perso/radi
ou en :
server = /usr/bin/xargs /usr/local/perso/radi

server = /usr/bin/xargs
et tu dois pouvoir indiquer des options pour ce serveur, où tu met
/usr/local/perso/radi

--
Emmanuel Dreyfus
manu@netbsd.org

Le Tue, 19 Aug 2003 08:22:27 +0200, Emmanuel Dreyfus a écrit:

server = /usr/bin/xargs
et tu dois pouvoir indiquer des options pour ce serveur, où tu met
/usr/local/perso/radi

donc :
# cat /etc/xinetd.d/radio
# default: off
# description: Radio
service radio
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/bin/xargs
server_args = /usr/local/perso/radi
disable = no
group = audio
}

Mais, soit je n'en pas encore compris, soit il faut faire autrement, mais
sur le client :
$ echo "list" | nc serveur 5000
bloque, même s'il lance bien un processus xargs /usr/local/perso/radi sur
le serveur.

Encore un petit coup de pouce ? ;-)

Merci, et désolé d'insister.

--
Christophe PEREZ

Christophe PEREZ <christophe@novazur.com> wrote:

$ echo "list" | nc serveur 5000
bloque, même s'il lance bien un processus xargs /usr/local/perso/radi sur
le serveur.

Avec un retour de chariot en plus?
echo "listn" | nc serveur 5000

--
Emmanuel Dreyfus
manu@netbsd.org

Le Thu, 21 Aug 2003 08:52:17 +0200, Emmanuel Dreyfus a écrit:

Avec un retour de chariot en plus?
echo "listn" | nc serveur 5000

:-))
J'y avais pensé, et essayé, mais idem, reste bloqué, et aucun argument
passé dans la ligne de commande.

Si prêt du but...:-((

--
Christophe PEREZ