Inetd e i servizi di rete: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (da adottare)
 
(8 versioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
La soluzione pi� diffusa e stabile, per la messa on-line di un applicativo scritto in ruby on rails, � data dall'accoppiata Mongrel e Apache2!
{{Guida da adottare}}
==Il superdemone inetd==


= Introduzione =
===Introduzione===
La struttura del nostro ambiente di produzione � descritta nella seguente figura:
Inetd ('''Internet Super-Server''') è un [[demone]] che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta. Esso controlla tramite dei [[wrapper]] i file <code>'''/etc/hosts.allow'''</code> e <code>'''/etc/hosts.deny'''</code> per verificare che la connessione sia consentita.


TODO!!!
Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.


Il vantaggio di usarlo è di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.


Tutte le richieste arriveranno al server web apache, che si occuper� di dirottare le richieste dinamiche a uno dei server mongrel, mentre servir� i contenuti di tipo statico direttamente, senza cos� appesantire le istanze di mongrel con richieste che possono essere processate direttamente da apache.
Sebbene possa essere usato per gestire quasi tutti i servizi è consigliabile farlo solo per quelli a basso e occasionale traffico.


Questa struttura, inoltre, permette espansioni future per garantire una buona scalabilit� in caso di un forte aumento delle richieste: potremo, in futuro, spostare le verie istanze di mongrel su server differenti, distribuire il filesystem in modo da avere "pi� apache" pronti ad accettare le richieste, ...
===Installazione===
Se per qualche motivo il demone inetd non dovesse essere installato è sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:
<pre># apt-get install openbsd-inetd tcpd</pre>


===Configurazione===
Per prima cosa è necessario modificare i permessi al file <code>'''/etc/inetd.conf'''</code> in modo che solo root abbia accesso:
<pre># chmod 600 /etc/inetd.conf</pre>


= Installazione =
Ogni riga di <code>'''/etc/inetd.conf'''</code> corrisponde ad un servizio che viene gestito da inetd. Se è commentata con un <code>#</code> il servizio non viene avviato e inetd non mette la relativa porta in listening. Esempio:
== Apache2 ==
Per installare Apache � sufficiente un  
<pre>
# apt-get install apache2-mpm-prefork libapache2-mod-proxy-html
</pre>


Consiglio la versione "prefork" in quanto � supportata pienamente anche da php5, e di conseguenza non ci saranno problemi ad installare anche applicazioni come phpmyadmin, molto comoda per la gestione di database mysql. L'installazione base di apache, per�, non � sufficiente per i nostri fini, infatti dobbiamo abilitare alcuni moduli:
<pre># These are standard services. 
* deflate
#
* proxy_balancer
#ftp    stream  tcp  nowait  root  /usr/sbin/tcpd  in.ftpd -l -a 
* proxy_connect
#telnet stream  tcp  nowait  root  /usr/sbin/tcpd  in.telnetd
* proxy_html
#
* proxy_http
# Shell, login, exec, comsat and talk are BSD protocols. 
* proxy
* rewrite
#shell  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rshd 
#login  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rlogind 
#exec  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rexecd 
#comsat dgram  udp    wait    root    /usr/sbin/tcpd  in.comsat 
#talk  dgram  udp    wait    root    /usr/sbin/tcpd  in.talkd 
#ntalk  dgram  udp    wait    root    /usr/sbin/tcpd  in.ntalkd 
#dtalk  stream  tcp    waut    nobody  /usr/sbin/tcpd  in.dtalkd</pre>


per abilitarli:
Il formato tipico di ogni riga è il seguente:
<pre>
# a2enmod deflate
# a2enmod proxy_balancer
# a2enmod proxy_connect
# a2enmod proxy_html
# a2enmod proxy_http
# a2enmod proxy
# a2enmod rewrite
</pre>


La configurazione di default del modulo proxy permette connessioni solo dall'indirizzo ip 127.0.0.1. Questa situazione rende impossibile, per�, l'accesso al VirtualHost che andremo a configurare dall'esterno. A tal proposito dobbiamo modificare il file di configurazione del modulo (''nome del file di configurazione'') modificando la seguente riga:
<pre>service type protocol wait user server cmdline</pre>


TODO
Un esempio pratico di una riga presente in <code>'''/etc/inetd.conf'''</code>:
<pre>ftp stream tcp nowait root /usr/sbin/in.ftpd –l


Una volta abilitati i moduli e fatte le modifiche necessarie, riavviamo apache:
ftp: nome del servizio
<pre>
stream: indica il tipo
# /etc/init.d/apache2 restart
tcp: indica il protocollo
</pre>
nowait: indica se deve attendere
user: indica l'utente che ha il privilegio di accesso
server: indica dove si trova il programma
cmdline:indica il nome dell’eseguibile e eventuali flag</pre>


L'installazione e la configurazione base di apache sono terminate.
Inoltre inetd si appoggia su un altro file di configurazione dei servizi: <code>/etc/services</code>, file che assegna un nome di servizio alla relativa porta e che viene usato anche da altri programmi come file di riferimento.


== Ruby ==
Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:
Se non � gi� presente sulla macchina, provvediamo ad installare ruby ed i componenti pi� importanti, necessari alla compilazione di mongrel:
<pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd –l</pre>


<pre>
Nelle distribuzioni Linux, solitamente inetd è già configurato per supportare i tcp wrappers.
# apt-get install ruby irb ri rdoc ruby1.8-dev build-essential
</pre>


===TCP wrappers===
I tcp wrapper '''TCPD''', sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.


== Rails ==
In pratica da una configurazione:
Prima di tutto scarichiamo rubygems dal sito ufficiale: http://www.rubygems.org/


In questo momento l'ultima versione � la [http://rubyforge.org/frs/download.php/28174/rubygems-0.9.5.tgz 0.9.5]:
<pre>client -----> inetd -----> servizio</pre>
<pre>
# wget http://rubyforge.org/frs/download.php/28174/rubygems-0.9.5.tgz
# tar xzvf rubygems-0.9.5.tgz
# cd rubygems-0.9.5
# ruby setup.rb
</pre>


Ora possiamo installare rails, facendo attenzione alla versione richiesta dal nostro applicativo:
Si passa ad una configurazione:
* Ultima versione
<pre>
# gem install rails
</pre>
* Una versione specifica
<pre>
# gem install rails -v 1.2.5
</pre>


<pre>client -----> inetd -----> TCPD -----> servizio</pre>


== Mongrel ==
Nella nuova configurazione i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalità anti-spoofing e anti tcp sequence guessing. La configurazione dei tcp wrappers si fa essenzialmente in due file.
Mongrel si installa allo stesso modo di rails, inoltre installeremo anche mongrel-cluster, che ci semplificher� moltissimo la vita:
<pre>
# gem install mongrel
# gem install mongrel_cluster
</pre>


= Configurazione =
Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP:
== Mongrel ==
<code>/etc/hosts.allow</code>
La configurazione del cluster di server mongrel � semplice, e si riduce a creare un semplice file di configurazione. Questo � quello base, da cui partire:
<pre>
---
cwd: /opt/applicativo/
log_file: log/mongrel.log
port: "3000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3
</pre>


Nei dettagli tutte le voci:
Questo file permette di specificare come limitare l'accesso a specifici servizi:
; cwd : ''current work directory'', cio� la directory in cui � presente l'applicativo. � consigliato usare SEMPRE un percorso assoluto.
<code>/etc/hosts.deny</code>
; log_file : dove conservare i log di mongrel. Il valore di default va pi� che bene
; port : la porta iniziale per l'array di server mongrel
; environment : l'envirorment di rails da utilizzare... normalmente si usa production (essendo un server di produzione), ma in casi particolari si pu� inserire un nuovo ambiente.
; address : l'indirizzo IP su cui mettersi in ascolto. Le scelte pi� comuni sono:
:; 127.0.0.1 : il cluster sar� raggiungibile solo da applicazioni residenti sul server su cui � in esecuzione mongrel, impostazione consigliata a meno di configurazioni pi� complesse
:; 0.0.0.0 : il cluster sar� raggiungibile da qualsiasi indirizzo esterno, scelta sconsigliata a meno che non ci si trovi in un ambiente protetto
; pid_file : dove inserire i [[pid]] dei vari processi mongrel
; servers : il numero di server mongrel da lanciare.  


===Comandi utili===
Per avviare, riavviare, fermare il servizio inetd:
<pre># service openbsd-inetd start/stop/restart</pre>


== Apache ==
===Configurazioni utili===
Questo � un classico file di configurazione di apache per un VirtualHost, che sfrutta 3 server mongrel.
Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>File da applicare: /etc/hosts.deny
ALL:ALL@ALL,PARANOID</pre>


<pre>
Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
da inserire
<pre>File da applicare: /etc/hosts.allow
</pre>
ALL: LOCAL 192.168.1.0/255.255.255.0</pre>
le spiegazioni sono nei commenti del file di configuarzione. Consiglio di non cancellarli quando si utilizza questo template, in quanto possono sempre tornare utili nel futuro ;)


= Avvio, Arresto e Riavvio di un cluster Mongrel =
Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1
In questa parte del tutorial vedremo come lanciare, fermare e riavviare una batteria di server mongrel:
<pre>File da applicare: /etc/hosts.allow
== Avvio ==
sshd: 10.0.0.1 prova.it</pre>
== Arresto ==
== Riavvio ==


Manda una email all'indirizzo specificato admin_mail ogni qualvolta qualcuno si connette attraverso il servizio telnet, indicando l'indirizzo del client (%a) e l'utente (%u), la lista di questi parametri è contenuta nella man page hosts_access.
<pre>File da applicare: /etc/hosts.allow
in.telnetd : ALL@ALL : spawn ( /bin/mail -s "Connessione telnet da: %a %u" admin_mail ) & </pre>


= Conclusione =
==Da inetd a Xinetd==
Giunti a questo punto abbiamo configurato alla perfezione sia apache che mongrel... se tutto funziona a dovere il nostro applicativo dovrebbe essere visibile dall'esterno ;)
===Differenze===
A differenza del precedessore, xinetd (e'''x'''tended inetd):
 
:*Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
:*Offre un sistema di logging indipendente da syslog;
:*Permette di limitare l'accesso ai servizi in determinate ore della giornata;
:*Supporta il protocollo IPv6;
:*Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.
 
===File di configurazione===
La configurazione del demone e dei servizi può essere suddivisa in più file non compatibili con i vecchi file di configurazione del demone inetd. Le directory contenenti i file di configurazione sono leggermente cambiate:
<pre>/etc/xinetd.conf
File di configurazione del demone
 
/etc/xinetd.d/*
Directory che contiene i singoli file dei servizi offerti da xinetd</pre>
 
Il file di configurazione di xinetd è un file di testo che indica i servizi gestiti da xinetd. Contiene delle sezioni, ognuna delle quali identifica un servizio, con la seguente sintassi:
<pre>service service_name
{
    attribute assign_op [value] [value] [...]
    [...]
}</pre>
 
Dove i seguenti attributi indicano:
:* <code>'''service_name'''</code>  è l'indicazione di un servizio gestito da xinetd;
:* <code>'''attribute'''</code>  indica un attributo relativo al servizio service_name;
:* <code>'''assign_op'''</code>  è un operatore di assegnamento, e può essere <code>=</code> (specifica l’unico valore dell’attributo), <code>+=</code> (aggiunge un valore all'attributo) o <code>-=</code> (rimuove un valore dall’attributo).
 
===Esempi di configurazione di Xinetd===
Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione <code>'''/etc/xinetd.conf'''</code>:
<pre>service shell
          {
                socket_type        = stream
                wait                = no
                user                = root
                instances          = UNLIMITED
                server              = /usr/etc/in.rshd
                log_on_success      += HOST RECORD
          }
 
service ftp                                                             
          {
                socket_type        = stream
                wait                = no
                nice                = 10
                user                = root
                server              = /usr/etc/in.ftpd
                server_args        = -l
                instances          = 4
                log_on_success      += DURATION HOST USERID
                access_times        = 2:00-9:00 12:00-24:00
          }</pre>
 
Per una guida dettagliata di ogni singolo parametro è possibile consultare il '''man''' una volta installato xinetd. Xinetd è un demone molto flessibile e tramite il suo file di configurazione è possibile specificare decine e decine di opzioni.
 
===Opzioni di Xinetd===
Le opzioni che possono essere utilizzate per la modalità di funzionamento di xinetd sono le seguenti:
:* <code>'''-d'''</code>: abilita la modalità di debug;
:* <code>'''-syslog syslog_facility'''</code>: imposta la facility relativa al system log secondo quanto specificato da <code>syslog_facility</code>;
:* <code>'''-filelog logfile'''</code>: indica di redirigere il log degli eventi di xinetd nel file logfile;
:* <code>'''-f config_file'''</code>: indica il file di configurazione da considerare secondo quanto specificato da <code>config_file</code> (default <code>/etc/xinetd.conf</code>);
:* <code>'''-pidfile pid_file'''</code>: indica di scrivere nel file <code>pid_file</code> il PID del processo lanciato;
:* <code>'''-stayalive'''</code>: indica di rimanere in esecuzione anche se nel file di configurazione non è stato specificato nessun servizio;
:* <code>'''-limit proc_limit'''</code>: imposta il numero massimo di processi che xinetd può lanciare secondo quanto specificato da <code>proc_limit</code>;
:* <code>'''-logprocs limit'''</code>: imposta il numero massimo di daemon che possono essere lanciati in esecuzione per ogni utente, secondo quanto specificato da <code>limit</code>;
:* <code>'''-version'''</code>: visualizza la versione di xinetd;
:* <code>'''-inetd_compat'''</code>: indica di considerare anche il file di configurazione <code>'''/etc/inetd.conf'''</code> subito dopo <code>'''/etc/xinetd.conf'''</code>;
:* <code>'''-cc interval'''</code>: indica di controllare un controllo periodico del proprio stato ogni <code>interval</code> secondi;
 
Il processo xinetd effettua le operazioni elencate in corrispondenza dei seguenti segnali:
 
:*<code>'''SIGHUP'''</code>: rilegge il file di configurazione e termina l’esecuzione dei daemon relativi a servizi non più attivi (secondo quanto specificato nel file di configurazione);
:* <code>'''SIGQUIT'''</code>: termina la sua esecuzione;
:* <code>'''SIGTERM'''</code>: termina l’esecuzione di tutti i daemon prima di terminare anche la sua esecuzione;
:* <code>'''SIGUSR1'''</code>: scrive il suo stato interno (dump) nel file <code>'''/var/run/xinetd.dump'''</code>;
:* <code>'''SIGIOT'''</code>: controlla la consistenza delle sue strutture dati, visualizzando quindi un messaggio relativo.
 
[[Categoria:Monitoraggio]]
[[Categoria:Shell]]

Versione attuale delle 19:19, 3 nov 2019

Guida da adottare! Bannermv.png


Il superdemone inetd

Introduzione

Inetd (Internet Super-Server) è un demone che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta. Esso controlla tramite dei wrapper i file /etc/hosts.allow e /etc/hosts.deny per verificare che la connessione sia consentita.

Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.

Il vantaggio di usarlo è di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.

Sebbene possa essere usato per gestire quasi tutti i servizi è consigliabile farlo solo per quelli a basso e occasionale traffico.

Installazione

Se per qualche motivo il demone inetd non dovesse essere installato è sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:

# apt-get install openbsd-inetd tcpd

Configurazione

Per prima cosa è necessario modificare i permessi al file /etc/inetd.conf in modo che solo root abbia accesso:

# chmod 600 /etc/inetd.conf

Ogni riga di /etc/inetd.conf corrisponde ad un servizio che viene gestito da inetd. Se è commentata con un # il servizio non viene avviato e inetd non mette la relativa porta in listening. Esempio:

# These are standard services.  
# 
#ftp    stream  tcp   nowait  root  /usr/sbin/tcpd  in.ftpd -l -a  
#telnet stream  tcp   nowait  root  /usr/sbin/tcpd  in.telnetd 
# 
# Shell, login, exec, comsat and talk are BSD protocols.  
#  
#shell  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd  
#login  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rlogind  
#exec  stream   tcp     nowait  root    /usr/sbin/tcpd  in.rexecd  
#comsat dgram   udp     wait    root    /usr/sbin/tcpd  in.comsat  
#talk   dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd  
#ntalk   dgram  udp     wait    root    /usr/sbin/tcpd  in.ntalkd  
#dtalk  stream  tcp     waut    nobody  /usr/sbin/tcpd  in.dtalkd

Il formato tipico di ogni riga è il seguente:

service type protocol wait user server cmdline

Un esempio pratico di una riga presente in /etc/inetd.conf:

ftp stream tcp nowait root /usr/sbin/in.ftpd –l

ftp:	nome del servizio
stream:	indica il tipo
tcp:	indica il protocollo
nowait:	indica se deve attendere
user:	indica l'utente che ha il privilegio di accesso
server:	indica dove si trova il programma
cmdline:indica il nome dell’eseguibile e eventuali flag

Inoltre inetd si appoggia su un altro file di configurazione dei servizi: /etc/services, file che assegna un nome di servizio alla relativa porta e che viene usato anche da altri programmi come file di riferimento.

Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd –l

Nelle distribuzioni Linux, solitamente inetd è già configurato per supportare i tcp wrappers.

TCP wrappers

I tcp wrapper TCPD, sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.

In pratica da una configurazione:

client -----> inetd -----> servizio

Si passa ad una configurazione:

client -----> inetd -----> TCPD -----> servizio

Nella nuova configurazione i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalità anti-spoofing e anti tcp sequence guessing. La configurazione dei tcp wrappers si fa essenzialmente in due file.

Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP: /etc/hosts.allow

Questo file permette di specificare come limitare l'accesso a specifici servizi: /etc/hosts.deny

Comandi utili

Per avviare, riavviare, fermare il servizio inetd:

# service openbsd-inetd start/stop/restart

Configurazioni utili

Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:

File da applicare: /etc/hosts.deny
ALL:ALL@ALL,PARANOID

Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:

File da applicare: /etc/hosts.allow
ALL: LOCAL 192.168.1.0/255.255.255.0

Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1

File da applicare: /etc/hosts.allow
sshd: 10.0.0.1 prova.it

Manda una email all'indirizzo specificato admin_mail ogni qualvolta qualcuno si connette attraverso il servizio telnet, indicando l'indirizzo del client (%a) e l'utente (%u), la lista di questi parametri è contenuta nella man page hosts_access.

File da applicare: /etc/hosts.allow
in.telnetd : ALL@ALL : spawn ( /bin/mail -s "Connessione telnet da: %a %u" admin_mail ) & 

Da inetd a Xinetd

Differenze

A differenza del precedessore, xinetd (extended inetd):

  • Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
  • Offre un sistema di logging indipendente da syslog;
  • Permette di limitare l'accesso ai servizi in determinate ore della giornata;
  • Supporta il protocollo IPv6;
  • Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.

File di configurazione

La configurazione del demone e dei servizi può essere suddivisa in più file non compatibili con i vecchi file di configurazione del demone inetd. Le directory contenenti i file di configurazione sono leggermente cambiate:

/etc/xinetd.conf
File di configurazione del demone

/etc/xinetd.d/*
Directory che contiene i singoli file dei servizi offerti da xinetd

Il file di configurazione di xinetd è un file di testo che indica i servizi gestiti da xinetd. Contiene delle sezioni, ognuna delle quali identifica un servizio, con la seguente sintassi:

service service_name
{
    attribute assign_op [value] [value] [...]
    [...]
}

Dove i seguenti attributi indicano:

  • service_name è l'indicazione di un servizio gestito da xinetd;
  • attribute indica un attributo relativo al servizio service_name;
  • assign_op è un operatore di assegnamento, e può essere = (specifica l’unico valore dell’attributo), += (aggiunge un valore all'attributo) o -= (rimuove un valore dall’attributo).

Esempi di configurazione di Xinetd

Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione /etc/xinetd.conf:

service shell
          {
                socket_type         = stream
                wait                = no
                user                = root
                instances           = UNLIMITED
                server              = /usr/etc/in.rshd
                log_on_success      += HOST RECORD
          }

service ftp                                                              
          {
                socket_type         = stream
                wait                = no
                nice                = 10
                user                = root
                server              = /usr/etc/in.ftpd
                server_args         = -l
                instances           = 4
                log_on_success      += DURATION HOST USERID
                access_times        = 2:00-9:00 12:00-24:00
          }

Per una guida dettagliata di ogni singolo parametro è possibile consultare il man una volta installato xinetd. Xinetd è un demone molto flessibile e tramite il suo file di configurazione è possibile specificare decine e decine di opzioni.

Opzioni di Xinetd

Le opzioni che possono essere utilizzate per la modalità di funzionamento di xinetd sono le seguenti:

  • -d: abilita la modalità di debug;
  • -syslog syslog_facility: imposta la facility relativa al system log secondo quanto specificato da syslog_facility;
  • -filelog logfile: indica di redirigere il log degli eventi di xinetd nel file logfile;
  • -f config_file: indica il file di configurazione da considerare secondo quanto specificato da config_file (default /etc/xinetd.conf);
  • -pidfile pid_file: indica di scrivere nel file pid_file il PID del processo lanciato;
  • -stayalive: indica di rimanere in esecuzione anche se nel file di configurazione non è stato specificato nessun servizio;
  • -limit proc_limit: imposta il numero massimo di processi che xinetd può lanciare secondo quanto specificato da proc_limit;
  • -logprocs limit: imposta il numero massimo di daemon che possono essere lanciati in esecuzione per ogni utente, secondo quanto specificato da limit;
  • -version: visualizza la versione di xinetd;
  • -inetd_compat: indica di considerare anche il file di configurazione /etc/inetd.conf subito dopo /etc/xinetd.conf;
  • -cc interval: indica di controllare un controllo periodico del proprio stato ogni interval secondi;

Il processo xinetd effettua le operazioni elencate in corrispondenza dei seguenti segnali:

  • SIGHUP: rilegge il file di configurazione e termina l’esecuzione dei daemon relativi a servizi non più attivi (secondo quanto specificato nel file di configurazione);
  • SIGQUIT: termina la sua esecuzione;
  • SIGTERM: termina l’esecuzione di tutti i daemon prima di terminare anche la sua esecuzione;
  • SIGUSR1: scrive il suo stato interno (dump) nel file /var/run/xinetd.dump;
  • SIGIOT: controlla la consistenza delle sue strutture dati, visualizzando quindi un messaggio relativo.