Re: dialogué avec un deamon

• [^]Re: dialogué avec un deamon

  Posté par Nicolas Boulay () le 25/02/2004 à 13:49. (lien). Évalué à 1.

  ben non. Pour que cela fasse l'affaire, il faudrait lancer un programe pour avoir ses sorties, là il tourne déjà.

  --
  "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

Re: dialogué avec un deamon

• [^]Re: dialogué avec un deamon

  Posté par Nicolas Boulay () le 25/02/2004 à 12:36. (lien). Évalué à 1.

  Donc, j'écris un programe "résident" qui est lancé au démarage de la machine.
  
  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.

  --
  "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

• [^]Re: dialogué avec un deamon

  Posté par Epsos (page perso, ) le 25/02/2004 à 12:53. (lien). Évalué à 2.

  Pas du tout efface.
  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 (page perso, ) le 25/02/2004 à 13:00. (lien). Évalué à 1.

    Je viens de verifier : il faut remplacer seteuid par setsid (comme session id)

  • [^]Re: dialogué avec un deamon

    Posté par Nicolas Boulay () le 25/02/2004 à 13:01. (lien). Évalué à 1.

    Pour résumer, il est donc tout à fait possible de connecter stdin/stdout sur une socket. Je ne croyais pas ça possible ou simple :)
    
    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 ?

    --
    "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

    • [^]Re: dialogué avec un deamon

      Posté par Epsos (page perso, ) le 25/02/2004 à 13:15. (lien). Évalué à 1.

      Ca je ne sais pas trop. Ca depend de comment readline fonctionne.
      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 (page perso, ) le 25/02/2004 à 13:27. (lien). Évalué à 1.

        Tiens un petit exemple pour faire un truc simple :
        
        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 () le 25/02/2004 à 13:41. (lien). Évalué à 1.

        je ne sais pas comment être plus précis :/
        
        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.

        --
        "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

        • [^]Re: dialogué avec un deamon

          Posté par Epsos (page perso, ) le 25/02/2004 à 14:12. (lien). Évalué à 1.

          Oui, je ne connais pas screen, mais effectivement c'est qui semble le plus approprie.

      • [^]Re: dialogué avec un deamon

        Posté par Nicolas Boulay () le 25/02/2004 à 13:45. (lien). Évalué à 1.

        Readline utilise un ttyS* mais est-ce que le client (telnet) ne pourrait pas executer ces commandes ?
        
        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.

        --
        "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

Re: dialogué avec un deamon

Re: dialogué avec un deamon

Re: dialogué avec un deamon

Re: dialogué avec un deamon

• [^]Re: dialogué avec un deamon

  Posté par Nicolas Boulay () le 25/02/2004 à 12:37. (lien). Évalué à 1.

  Cela a l'air d'être le plus pratique en effet.

  --
  "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

Re: dialogué avec un deamon

• [^]Re: dialogué avec un deamon

  Posté par Nicolas Boulay () le 25/02/2004 à 14:03. (lien). Évalué à 1.

  mais là plus de terminal donc :)

  --
  "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."