Linux: come rendere un demone/servizio utilizzabile con xinetd?

Question

Qualcuno sa quali modifiche sono necessarie per il funzionamento di un server con xinetd?

Il server è un server di posta .NET che gira su Linux.

vedere il fondo di questo post per riferimento: Lumisoft Mailserver Forum Post

Nota: xinetd, non mono-servizio. [x] inetd è un superserver di internet.
Un superserver avvia un servizio server su richiesta.
(Contrariamente al servizio server in esecuzione continua, ovvero ciò che fa il servizio mono)

Answer 1

Un servizio inetd viene eseguito in modo diverso da un server autonomo. i servizi inetd leggono lo stdin e scrivono su stdout, lasciando inetd gestire i dettagli cruenti di TCP/IP, piuttosto che tenere traccia dei propri socket. Se vuoi far funzionare un server sotto inetd, dovrà fare lo stesso.

Il seguente programma funziona bene sotto xinetd sulla mia macchina:

#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 io non sono affatto preoccupato per le prese - xinetd dispone le cose in modo che il servizio può leggere lo standard input e scrivere su standard di produzione. Devi solo scrivere la tua app come se fossi in esecuzione sulla console, per la maggior parte. I dettagli del socket sono specificati nel file di configurazione per il servizio. (Nota, potresti essere in grado di ottenere/impostare i dettagli sul socket usando stdin/stdout, che potrebbe essere il socket reale - non sono sicuro - ma dovresti lasciare tutto ciò inetd.)

Answer 2

I servizi inetd sono davvero grandiosi per le app one off che devono acquisire dati e agire con un certo grado di interazione con l'utente. Funziona su tcp/udp convogliando i dati in viva un socket da (x) inetd a std {in, out, err}. le app inetd funzionano bene anche con gli tcpwrapper per garantire la massima sicurezza dei file di policy di sistema e ACL.

Quindi sì, dovresti scrivere la tua app come un'app per console in quanto in realtà è un'app per console. Basti pensare a inetd come proxy inverso trasparente dalla rete agli input della tua app.

Una parola di consiglio, scrivi il tuo codice per gestire correttamente i segnali di processo e se hai bisogno di interagire con un altro processo sul sistema usa unix sockets/fifo per quello.

Inoltre, non provare a scrivere un'app che esegue lo streaming di molti dati contemporaneamente o richiede molte connessioni. La scalabilità è un problema dato che inetd diventa un collo di bottiglia, questo è il motivo per cui Apache e Sendmail hanno abbandonato il supporto per inetd e si sono seduti come app mono. HTTP si adatta meglio a questo ruolo e uno script fastcgi (o insert framework preferito) con nginx funziona meglio per quel caso d'uso.

Un buon esempio di un inetd sarebbe:

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 

Modificare il /etc/services per inserire la tua app come questo: porta myapp #/proto

e aggiungere la vostra applicazione per /etc/inetd.conf (o xinetd. d) in questo modo: myapp stream tcp6 nowait myappuser/percorso/a/myapp myapp -arg_flags