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
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
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 envisager d'avoir un canal SSH ouvert, et un script au
deux bouts communiquant.
Quelque chose comme ça:
#!/bin/bash
mkdir /tmp/commandes > /dev/null 2>&1 || true
[...]
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?
On pourrait envisager d'avoir un canal SSH ouvert, et un script au
deux bouts communiquant.
Quelque chose comme ça:
#!/bin/bash
mkdir /tmp/commandes > /dev/null 2>&1 || true
[...]
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?
On pourrait envisager d'avoir un canal SSH ouvert, et un script au
deux bouts communiquant.
Quelque chose comme ça:
#!/bin/bash
mkdir /tmp/commandes > /dev/null 2>&1 || true
[...]
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?
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.
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.
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.
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.
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.
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) :-)
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) :-)
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) :-)
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.
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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
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
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
server = /usr/bin/xargs
et tu dois pouvoir indiquer des options pour ce serveur, où tu met
/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
$ echo "list" | nc serveur 5000
bloque, même s'il lance bien un processus xargs /usr/local/perso/radi sur
le serveur.
$ echo "list" | nc serveur 5000
bloque, même s'il lance bien un processus xargs /usr/local/perso/radi sur
le serveur.
$ 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
Avec un retour de chariot en plus?
echo "listn" | nc serveur 5000
Avec un retour de chariot en plus?
echo "listn" | nc serveur 5000