J'ai un programe lancé au démarrage de ma machine, or je voudrais pouvoir "prendre la main" dessus par réseau en cas de problème ou pour teste. En gros, je voudrais avoir un espèce de shell et un affichage type ncurse.
Pour l'affichage, il existe readline et ncurse. Mais est-il possible de connecter ça à une socket réseau ? (et telnet ferais un beau client pas secure mais je m'en fous)
A moins qu'il existe des programmes qui savent récupérer stdin/stdout d'un autre programme qui tourne ?
Bref une idée ?
Journal dialogué avec un deamon
25
fév.
2004
# Re: dialogué avec un deamon
Posté par jaroug (site web personnel) . Évalué à 2.
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Re: dialogué avec un deamon
Posté par Pascal . Évalué à 2.
Déja un daemon par définition n'a pas de stdin/stdout.
Normallement un daemon communique par l'intermediaire de Syslog
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je veux pouvoir interréagir avec comme avec un terminal normal pour des testes. Je veux aussi faire le minimum d'effort.
Screen semble être ce qu'il faut comme proposer plus bas.
"La première sécurité est la liberté"
[^] # Re: dialogué avec un deamon
Posté par Epsos . Évalué à 2.
Syslog n'est la que pour logguer les logs d'une application grace a l'appel syslog (voir la manpage).
La definition d'un demon, c'est un programme qui tourne en standalone et qui est decorrele d'une session utilisateur.
Pour faire ca, ca implique quelques fork et quelques changement avec seteuid je crois.
Ensuite, la notion de stdin/stdout est tres subjective. stdin c'est juste le canal 0, stdout c'est juste le canal 1.
Souvent d'ailleurs, un demon comme inetd/xinetd s'amuse avec les descripteurs de la socket et les dup() pour que le serveur auquel il passe la main puisse directement utiliser stdin/stdout comme entree/sortie vers la socket.
C'est un moyen de "passer" la socket d'un processus pere vers un processus fils.
Si tu as envie que ton programme puisse repondre a des requetes utilisateurs, ce n'est pas tres complique :
1- tu lance ton demon (donc fork() et refork() et seteuid())
2- tu ouvres une socket en ecoute
3- lors d'une connection entrante, tu cree la socket cliente
4- ensuite, suivant si tu veux traiter les connections 1 par 1 ou simultanement, tu vas lancer une thread par socket cliente ou non
5- pour repondre a la requete du client, il faut que tu definisse un protocole, c'est a dire le langage compris a la fois par l'application cliente et ton serveur
6- tu lis la requete, tu fais le traitement, tu repond.
En ce qui concerne le protocole, il peut etre binaire ou texte.
S'il est texte, tu pourras alors utiliser telnet pour te connecter a ton serveur.
Un protocole texte peut etre du style :
requete client : HELO
reponse serveur : HELO!
requete client : LIST
reponse serveur : la liste des fichiers d'un repertoire particulier separe par des espaces par exemple.
Il faut evidemment prendre en compte les cas ou le client s'interrompt en plein milieu d'une requete ou de la session. Mais apres c'est de la gestion reseau.
Si ta question c'est comment faire pour rediriger stdin et stdout de mon serveur vers un client, la reponse est "tu peux le faire", mais comme stdin et stdout vont passer par la socket tu devras quand meme prendre en compte les problemes reseaux pour blinder ton serveur, donc autant utiliser directement la socket.
Sinon, fclose(), dup(), sont tes amis.
[^] # Re: dialogué avec un deamon
Posté par Epsos . Évalué à 1.
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Mais est-ce que readline continuera de fonctionner pareil ? Est-ce que les combinaisons de touches et autres seront géré par la socket comme c'est gérer normalement par un terminal ?
"La première sécurité est la liberté"
[^] # Re: dialogué avec un deamon
Posté par Epsos . Évalué à 1.
S'il n'a besoin pour fonctionner que de stdin, a priori il n'y a pas de raisons pour que ca ne fonctionne pas. Apres tout, une touche tapee au clavier envoie un code ASCII.
Maintenant, si readline utilise stdin + autre chose (genre ttyS*) pour gerer plus de choses, comme la detection d'appuis sur des touches multiples, le relachement de touches, etc alors tu risques de ne pas avoir le comportement attendu.
Ceci dit, il me semble que readline doit etre utilise du cote utilisateur (gestion d'un historique ...)
De plus, d'apres la manpage http://www.rtr.com/winpak/Documentation/readline.htm(...) readline a besoin d'un terminal pour fonctionner (ttyS* il me semble) donc stdin ne lui suffit pas.
Dans tous les cas, il ne me semble pas opportun d'utiliser readline du cote serveur, alors que tu ne veux recevoir que les commandes tapees par l'utilisateur (quel est l'interet de conserver et de manipuler un historique cote serveur ?)
Donc ce que tu veux certainement faire c'est un read (bloquant ou non bloquant) qui lit une string et la met dans un buffer.
A chaque fois qu'un '\n' est trouve, tu sais que la ligne a ete validee du cote utilisateur et donc tu n'as plus qu'a executer l'action correspondante suivant ton protocole.
Ceci dit, comme l'on dit de nombreux posts avant moi, si tu nous expliquais un peu plus ce que tu voulais faire on pourrait certainement etre un peu plus precis.
[^] # Re: dialogué avec un deamon
Posté par Epsos . Évalué à 1.
Tu configures inetd/xinetd sur un port particulier pour qu'il lance bash.
Qu'est ce qui va se passer ?
1- telnet machine port_qui_va_bien
2- inetd/xinetd qui ecoute sur le port_qui_va_bien fait :
2.1- duplication de la socket vers stdin/stdout
2.2- exec bash
3- bash prend la main comme s'il etait execute dans un terminal et repond aux requetes qui lui sont envoyes comme si tu les tapais en live.
J'ai jamais essaye mais ca doit marcher (au passage, a peu de choses pret c'est comme ca qu'on installe une back door)
Le seul truc qu'il faut voir c'est comment passer la bonne option a bash pour qu'il s'execute en mode sans terminal (il me semble qu'il sait gerer ca)
Par exemple, la manpage de bash http://pegasus.rutgers.edu/~elflord/unix/bash.html(...) me dit qu'il ne faudrait pas utiliser l'option -i (interactive), qu'il faudra certainement utiliser l'option --noprofile (pour ne pas lire les fichiers /etc/profile .profile ...), qu'on peut aussi utiliser l'option --noediting (pour justement ne pas utiliser readline) ...
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je veux pouvoir interréagir avec un programme qui utilise ncurse et readline pour son affichage.
Le truc, c'est qu'il tourne déjà car lancer au démarage.
Et je n'ai pas envis de coder un client réseau.
Readline doit utiliser le stty donc le truc à coup de screen devrait faire l'affaire.
"La première sécurité est la liberté"
[^] # Re: dialogué avec un deamon
Posté par Epsos . Évalué à 1.
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En gros, la socket ne serait qu'un tuyau d'échange. Les trucs spéciaux de terminaux étant executé par telnet.
inetd est un lanceur de réseau, cela évite d'avoir plein de serveur qui tourne pour rien. Je ne pense pas que Bash puisse se connecter comme ça, IMHO. Par contre telnetd ou sshd oui.
"La première sécurité est la liberté"
# Re: dialogué avec un deamon
Posté par LaBienPensanceMaTuer . Évalué à 2.
1/ Tu crée un joli socket que tu fais réagir à un certain jeu de commande (exemple; le client envoi status, tu renvois une ligne décrivant ce dernier). En gros tu te crée un ti protocole.
2/ Tu écrit ton client qui lui sait parler ton protocole et s'occupe lui meme de l'affichage de tout ça (curses voir même gtk).
mais faudrait que tu décrive plus précisement ce que tu veut faire...
# Re: dialogué avec un deamon
Posté par Benoit . Évalué à 2.
Regarde du côté de la fonction fdopen qui pourrait être utile.
# Re: dialogué avec un deamon
Posté par Nap . Évalué à 3.
# Re: dialogué avec un deamon
Posté par daggett . Évalué à 2.
Si tu ne veux pas t'embeter avec un protocoles réseau à sécuriser, fais juste une interface ligne de commande (le shell que tu proposes avec readline), et lance ton programme (sans qu'il soit daemonisé, donc en "foreground") sous le programme screen (man 1 screen) puis détache screen.
Quand tu voudras te reconnecter par réseau, logue-toi par ssh comme d'hab et réattache screen à ton terminal pour reprendre la main.
C'est pas une solution "tout integrée" à ton programme mais si c'est juste pour débugguer, ca peut suffire ?
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Re: dialogué avec un deamon
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
aussi. C'est ce qu'utilise Fvwm pour pouvoir le commander avec fvwmcommand si mes souvenirs sont bons.
[^] # Re: dialogué avec un deamon
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.