Linux: ¿Cómo hacer que un daemon/servicio se pueda usar con xinetd?

Question

¿Alguien sabe qué cambios son necesarios para que un servidor funcione con xinetd?

El servidor es un servidor de correo .NET que se ejecuta en Linux.

Ver la parte inferior de este post para referencia: Lumisoft Mailserver Forum Post

Nota: xinetd, no mono-servicio. [x] inetd es un superservidor de internet.
Un superservidor inicia un servicio de servidor bajo demanda.
(A diferencia del servicio de servidor que se ejecuta continuamente, que es lo que hace el mono-servicio)

Answer 1

Un servicio inetd se ejecuta de forma diferente a un servidor independiente. Los servicios de inetd leen stdin y escriben en stdout, permitiendo a inetd manejar los detalles sangrientos de TCP/IP, en lugar de hacer un seguimiento de sus propios sockets. Si desea que un servidor se ejecute en inetd, tendrá que hacer lo mismo.

El siguiente programa funciona muy bien bajo xinetd en mi máquina:

#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; 
} 

Nota que no estoy en absoluto preocupado por tomas - xinetd arregla las cosas para que el servicio pueda leer la entrada estándar y escribir en norma salida. Simplemente escribes tu aplicación como si estuvieras ejecutándola en la consola, en su mayor parte. Los detalles del socket se especifican en el archivo de configuración para el servicio. (Tenga en cuenta que es posible que pueda obtener/configurar detalles sobre el zócalo usando stdin/stdout, que puede ser el zócalo real - no estoy seguro - pero debería dejar eso en inetd.)

Answer 2

Los servicios inetd son realmente geniales para aplicaciones que necesitan incorporar datos y actuar con cierto grado de interacción con el usuario. Funciona sobre tcp/udp conectando los datos a un socket de (x) inetd a std {in, out, err}. Las aplicaciones inetd también funcionan bien con tcpwrappers para mejorar la seguridad a través de los archivos de políticas del sistema y la ACL.

Así que sí, escribiría su aplicación como si fuera una aplicación de consola, ya que en realidad es una aplicación de consola. Solo piense en inetd como un proxy inverso transparente de la red a las entradas de su aplicación.

Un consejo, escriba su código para manejar las señales del proceso correctamente y si necesita interactuar con otro proceso en el sistema, use unix sockets/fifo para eso.

Además, no intente escribir una aplicación que transmita una gran cantidad de datos a la vez o que necesite muchas conexiones. La escalabilidad es un problema ya que inetd se convierte en un cuello de botella, por eso Apache y Sendmail dejaron de admitir inetd y sentarse como aplicaciones mono en su lugar. HTTP se adapta mejor a este rol y una secuencia de comandos fastcgi (o insertar un marco favorito) con nginx funciona mejor para ese caso de uso.

Un buen ejemplo de una inetd sería:

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 

Editar su /etc/services de incluir su aplicación como esta: puerto miaplicacion #/proto

y una su aplicación a /etc/inetd.conf (o xinetd. d) de esta manera: myapp stream tcp6 nowait myappuser/ruta/a/myapp myapp -arg_flags