Linux: Comment rendre un démon / service utilisable avec xinetd?

Un service inetd s’exécute différemment d’un serveur autonome. Les services inetd lisent stdin et écrivent dans stdout, laissant inetd gérer les détails gores de TCP / IP, plutôt que de garder une trace de leurs propres sockets. Si vous voulez faire fonctionner un serveur sous inetd, il devra faire la même chose.

Le programme suivant s’exécute parfaitement sous xinetd sur ma machine:

#include  #include  using namespace std; // yeah, i'm lazy. int main() { ssortingng name; cout << "What's your name? " << flush; cin >> name; cout << "Hi, " << name << "!" << endl; } 

Notez que je ne m'inquiète pas du tout des sockets - xinetd organise les choses de manière à ce que le service puisse lire les entrées standard et écrire sur la sortie standard. Vous écrivez simplement votre application comme si vous l'exécutiez sur la console, pour la plupart. Les détails du socket sont spécifiés dans le fichier de configuration du service. (Notez que vous pouvez obtenir / définir des détails sur le socket en utilisant stdin / stdout, qui peut être la socket - je ne suis pas sûr - mais vous devriez vraiment laisser ce genre de choses à inetd.)

Les services inetd sont vraiment parfaits pour les applications uniques qui nécessitent des données et agissent avec un certain degré d’interaction avec l’utilisateur. IT fonctionne sur tcp / udp en canalisant les données dans un socket de (x) inetd à std {in, out, err}. Les applications inetd fonctionnent également bien avec tcpwrappers pour améliorer la sécurité grâce aux fichiers de stratégie système et à la liste de contrôle d’access.

Donc, oui, vous écrivez votre application comme une application de console car en réalité, il s’agit d’une application de console. Il suffit de penser à inetd comme un proxy inverse transparent du réseau vers les entrées de votre application.

Un conseil, écrivez votre code pour gérer les signaux de processus correctement et si vous avez besoin d’interagir avec un autre processus sur le système, utilisez pour cela les sockets / fifo Unix.

De même, n’essayez pas d’écrire une application qui diffuse un grand nombre de données en une seule fois ou qui nécessite beaucoup de connexions. L’évolutivité est un problème car inetd devient un goulot d’étranglement, c’est pourquoi Apache et Sendmail ont abandonné le support pour inetd et se sont assis en tant qu’applications mono à la place. HTTP correspond mieux à ce rôle et un script fastcgi (ou insérer un cadre préféré) avec nginx est le mieux adapté à ce cas d’utilisation.

Un bon exemple pour un inetd serait:

 lock = Mutex.new trap :HUP { #log the connection and cleanup } trap :USR1 { lock.synchronize do #stuff; end } trap :TERM { #clean up } trap :KILL { #clean up and die with error codes } puts "App name - version" loop do ('%s> ' % Console.prompt).display input = gets.chomp command, *params = input.split /\s/ case command when /\Ahelp\z/i puts App.help_text when /\Ado\z/i Action.perform *params when /\Aquit\z/i exit else puts 'Invalid command' end end exit 

Modifiez vos /etc/services pour inclure votre application comme ceci: myapp port # / proto

et ajoutez votre application à /etc/inetd.conf (ou xinetd.d) comme ceci: le stream monapplication tcp6 nowait myappuser / path / to / myapp myapp -arg_flags