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

Question

Quelqu'un sait quels changements sont nécessaires pour qu'un serveur fonctionne avec xinetd?

Le serveur étant un serveur de messagerie .NET fonctionnant sous Linux.

Voir le bas de ce post pour référence: Lumisoft Mailserver Forum Post

Note: xinetd, sans un service mono. [x] inetd est un super serveur internet. Un superserveur démarre un service de serveur à la demande

(Contrairement au service serveur qui s'exécute en continu, ce que fait le mono-service)

Answer 1

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

Le programme suivant exécute très bien sous xinetd sur ma machine:

#include <iostream> 
#include <string> 

using namespace std; // yeah, i'm lazy. 

int main() 
{ 
    string name; 
    cout << "What's your name? " << flush; 
    cin >> name; 
    cout << "Hi, " << name << "!" << endl; 
} 

Remarque je ne suis pas du tout inquiet au sujet des prises - xinetd arrange les choses pour que le service peut lire l'entrée standard et écrire à la norme sortie. Vous écrivez simplement votre application comme si vous l'utilisiez 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 pourriez obtenir/définir des détails sur le socket en utilisant stdin/stdout, qui peut être le socket réel - je ne suis pas sûr - mais vous devriez vraiment laisser ces choses à inetd.)

Answer 2

Les services inetd sont vraiment parfaits pour les applications uniques qui ont besoin de prendre des données et d'agir avec un certain degré d'interaction avec l'utilisateur. Il fonctionne sur TCP/UDP en transmettant les données viva un socket de (x) inetd à std {in, out, err}. Les applications inetd fonctionnent également bien avec tcpwrappers pour améliorer la sécurité par le biais de fichiers de règles système et d'ACL.

Alors oui, vous écrivez votre application comme une application de console, car en réalité, il s'agit d'une application de console. Pensez à inetd comme un proxy inverse transparent du réseau aux entrées de votre application.

Un mot de 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 unix sockets/fifo pour cela. De même, n'essayez pas d'écrire une application qui diffuse beaucoup de données en même temps ou qui nécessite un grand nombre 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 s'installent comme applications mono à la place. HTTP correspond mieux à ce rôle et un script fastcgi (ou insert framework favori) avec nginx fonctionne mieux pour 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 

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

et ajoutez votre application à /etc/inetd.conf (ou xinetd. d) comme ceci: myapp flux tcp6 nowait myappuser/chemin/vers/myapp myapp -arg_flags