Basi di Linux - Gestione del server: standalone e xinetd

September 21, 2007

Gestione del server: standalone e xinetd

Parliamo adesso di programmi server, cioè i demoni che girano nel nostro sistema.
Definizione8: Affinché gli utenti possano accedere ad un servizio come quello web nel nostro sistema, il programma che gestisce queste richieste (il demone httpd di apache) deve essere attivo e funzionate. Se nel nostro sistema è presente un sito web, questo sarà visibile alla rete internet (o alla intranet) solo se esiste appunto questo server web. Lo stesso vale per gli altri servizi come quello della telnet, dell’ftp, dell’nfs etc. Per vedere i servizi attualmente in esecuzione nel nostro sistema digitiamo:
[roberto@diamondhead roberto]$ ps -aux

Il comando ps, come abbiamo già visto mostra un’istantanea dei processi correnti. l’opzione a (subito dopo il trattino) sta ad indicare che vogliamo visualizzare anche i processi degli altri utenti, l’opzione u visualizza il nome dell’utente e l’ora di start del processo. La x finale mostra i processi senza il terminale di controllo. Se volete conoscere le altre opzione basta fare un:

[roberto@diamondhead roberto]$ man ps

TEST6: se vogliamo visualizzare in tempo reale lo stato e le varie caratteristiche dei processi attualmente in esecuzione, come possiamo fare? Considerate che basterebbe avviare un ciclo infinito con all’interno il comando ps. Provate a farlo.

Si possono visualizzare i processi attualmente in esecuzione anche con il comando top. A differenza del comando ps, top aggiorna costantemente lo stato dei processi in modo da monitorarli in tempo reale. Digitiamo top:

[roberto@diamondhead roberto]$ top

Vediamo un momento i server attivi nella nostra linux box:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.1 0.1 1368 544 ? S 10:27 0:04 init [3]
root 2 0.0 0.0 0 0 ? SW 10:27 0:00 [keventd]
root 3 0.0 0.0 0 0 ? SW 10:27 0:00 [kapm-idled]
root 969 0.0 0.5 5344 2004 ? S 10:28 0:00 sendmail:
accepting connections
….

(spiegare brevemente i vari servizi attivi come l’httpd, il sendmail, etc.)

Ci sono due modi (anzi tre) per avviare un programma server come il server web apache o sendmail. Il primo è quello di avviare il demone direttamente a linea di comando da superutente, per esempio:

[root@diamondhead init.d]# su -

[root@diamondhead /root]# /etc/init.d/httpd start

per fermarlo scriveremo:

[root@diamondhead /root]# /etc/init.d/httpd stop

per stopparlo e riavviarlo in una sola volta:

[root@diamondhead /root]# /etc/init.d/httpd restart

se scriviamo:

[root@diamondhead init.d]# ps -ef | grep httpd

vedremo che il server httpd è partito. Proviamo a lanciare netscape
da linea di comando con:

[root@diamondhead init.d]# netscape &

e nell’url digitiamo l’indirizzo di loopback 127.0.0.1 che identifica la nostra macchina (è possibile anche digitare localhost). Vedremo la pagina di index.html di apache che ci conferma che il web server è attivo e pronto per ricevere richieste di connessione.
Se ora proviamo a stoppare apache con il comando:

[root@diamondhead init.d]# /etc/init.d/httpd stop

prima di tutto non vedremo più il demone che gira. Proviamo a fare:

[root@diamondhead init.d]# ps -ef | grep httpd

difatti non troveremo l’httpd che gira. Se andiamo nel browser netscape e ricarichiamo la pagina vedremo che effettivamente la richiesta della prima pagina index.html che non verrà soddisfatta.
Abbiamo visto il primo modo per far partire o fermare un servizio. Il secondo modo consiste nel modificare gli script di avvio automatici in modo da attivare il servizio all’accensione della macchina. Se visualizziamo il contenuto del file:

[root@diamondhead xinetd.d]# more /etc/inittab

e andiamo alla linea dove c’è scritto “Default runlevel”. Vediamo una serie di numeri che vanno da 0 a 6. Ognuno di questi numeri identifica il runlevel di avvio della macchina. Il runlevel 0 porta la nostra linux box allo spegnimento (halt). C’è anche scritto di non utilizzare questo numero per l’initdefaults, altrimenti la macchina non partirebbe mai.
Il numero 1 porta la macchina nella modalita single user, disabilitando la multiutenza e i servizi di rete (questo runlevel è usato generalmente per l’amministrazione del sistema escludendo interferenze dagli altri utenti).
Il numero 2 porta la macchina in uno stato di multiutenza senza la rete, quindi anche senza il servizio NFS. Il numero 3 porta la macchina alla piena operatività: multiutenza, servizi di rete, etc. Questa è l’opzione di default, infatti se si vede un pò più giù si vedrà che l’initdefault è settato al runlevel 3. Il numero 4 non è utilizzato. Poi abbiamo il numero 5 che è la stessa identica cosa del 3 solo che il sistema si porta in modalità grafica: quindi piena operatività ma con l’interfaccia grafica. Bisogna fare attenzione che la modalità grafica sia settata correttamente altrimenti il sistema quando tenta di passare in modalità grafica si blocca. Per finire abbiamo il numero 6 che riavvia il sistema e si porta nella modalità specificata in initdafault. Se vogliamo fare come S. Tommaso proviamo a verificare quanto detto. Proviamo a riavviare la nostra macchina. Prima di specificare il runlevel dobbiamo usare il comando init o telinit:

[root@diamondhead xinetd.d]# telinit 6

Il sistema si riavvierà portandoci nel runlevel specificato da initdefault.

(aspettare che il sistema si porta nello stato operativo)

Proviamo ora a portare la nostra macchina al runlevel 1.

[root@diamondhead xinetd.d]# telinit 1

Definizione9: Il runlevel 1 viene usato spesso per ripristinare le inconsistenze create nelle varie partizioni causate da continui spegnimenti brutali. (arresti macchina senza la normale procedura di spegnimento. Faremo anche questo: simuleremo uno stato simile portandoci ad eseguire manualmente i controlli necessari per il ripristino del file system danneggiato).

Proviamo ora a portare la nostra macchina al runlevel 5 (piena funzionalità ma in modalità grafica):

[root@diamondhead xinetd.d]# telinit 5

Portiamo adesso il sistema nel runlevel 3:

[root@diamondhead xinetd.d]# telinit 3

Ok, visto questo, eravamo rimasti al modo automatico di avvio dei servizi, come l’httpd. Se vogliamo che questo servizio parta in automatico, quando il sistema si avvia al runlevel 3, dobbiamo entrare su:

[root@diamondhead xinetd.d]# cd /etc/rc.d/rc3.d/

diamo in ls per visualizzare i file, e troviamo tutti i demoni che girano silenziosamente in background al runlevel 3, ossia quello nel quale attualmente ci troviamo. Questi file che vediamo non sono altro che link simbolici agli script contenuti nella directory

/etc/rc.d/init.d/. Se infatti scriviamo:

[root@diamondhead rc3.d]# ls -l

vediamo che effettivamente sono file che si riferiscono ad altri dentro init.d.
Proviamo ad entrarci un attimino:

[root@diamondhead rc3.d]# cd /etc/rc.d/init.d/

visualizziamo il contenuto della directory con un ls. Questi file sono gli script di avvio e di chiusura dei demoni installati nel server. Ogni volta che installiamo un processo o demone, lo script di avvio e di chiusura viene creato qui dentro. Proviamo a visualizzare lo script di gestione dei apache:

[root@diamondhead init.d]# more httpd

Vediamo il codice scritto nella shell bash che gestisce questo servizio. Ora torniamo nella directory rc3.d:

[root@diamondhead rc3.d]# cd /etc/rc.d/rc3.d/

diamo il comando:

[root@diamondhead rc3.d]# ls S*

vediamo tutti i processi che partono a questo runlevel (S sta per start) e la loro sequenza di avvio (il numero indica la sequenza). Inversamente, se facciamo un:

[root@diamondhead rc3.d]# ls K*

vediamo tutti i processi che si fermano quando usciamo dal runlevel 3. Anche in questo caso il numero identifica la sequenza di chiusura del runlevel. Diamo un’occhiata al demone httpd, ossia al web server apache, digitando il comando:

[root@diamondhead rc3.d]# ls *httpd

vediamo che è collocato come S85httpd nella sequenza di avvio, ma non c’è nessun riferimento per la chiusura - stranamente - (vabbè, si vede che non ne ha bisogno). Per fare in modo che il web server apache non parta più al runlevel3, non dobbiamo fare altro che cancellare il link S85httpd:

[root@diamondhead rc3.d]# rm S85httpd

In questo modo non cancelliamo lo script vero e proprio che si trova dentro /etc/rc.d/init.d/, ma solo il link di riferimento. Proviamo a riavviare il server al runlevel 3 sempre per fare il S. Tommaso della situazione: per vedere che effettivamente il server httpd non verrà caricato.

[root@diamondhead rc3.d]# telinit 3

Se un domani volessimo ripristinarlo possiamo riscrivere il link con:

[root@diamondhead rc3.d]# ln -s /etc/rc.d/init.d/httpd S85httpd

il comando ln scrive un link simbolico (con l’opzione s) che si chiama S85httpd nella directory corrente, del file httpd situato su /etc/rc.d/init.d/. Un link praticamente è un riferimento virtuale ad un’altro file reale. Se si cancella un link il file reale rimane inviolato, mentre se si cancella il file reale un eventuale link a questo rimarrà irrisolto. Cerco di chiarire subito la relazione tra questi: editiamo con il VI un file:

[roberto@diamondhead roberto]$ vi pippo
ciao al mondo

ora abbiamo un file reale. Se vogliamo creare un link a questo faremo:

[roberto@diamondhead roberto]$ ln -s pippo pippoln

ora abbiamo un file reale che si chiama pippo e un link a questo che si chiama pippoln. Proviamo adesso a editare il link pippoln con l’editor VI:

[roberto@diamondhead roberto]$ vi pippoln
ciao al mondo infame

ora visualizziamo il file reale pippo:

[roberto@diamondhead roberto]$ more pippo

Le modifiche sono state apportate anche se abbiamo editato il link. Se cancelliamo il link pippoln, al file pippo non succede nulla, ma se cancelliamo il file pippo:

[roberto@diamondhead roberto]$ rm pippo

e vediamo il contenuto di pippoln con:

[roberto@diamondhead roberto]$ more pippoln
pippoln: File o directory inesistente

il sistema ci dà un messaggio d’errore. Ora se editiamo il link pippoln con il VI:

[roberto@diamondhead roberto]$ vi pippoln
sono ancora io

proviamo a fare:

[roberto@diamondhead roberto]$ ls

il file pippo è risorto e conterrà la frase appena scritta.

TEST7: Per ritornare al discorso di prima, cioè quello dei vari processi che partono a determinati runlevel, potremo far eseguire solo al momento dell’avvio del runlevel 3 lo script di backup che abbiamo già fatto. Non si tratta di un processo che deve partire, ma in ogni caso sarebbe uno script che verrebbe eseguito. In sostanza il backup verrà avviato solo quando il sistema viene acceso al runlevel 3. Cercate di dare un numero piuttosto alto, tipo S87 o
S88. Dai, provate a farlo.

Esempio risolto:

[root@diamondhead roberto]# cp script2.sh /etc/rc.d/init.d/.

[root@diamondhead roberto]# cd /etc/rc.d/rc3.d/

[root@diamondhead rc3.d]# ln -s ../init.d/script2.sh S87backup

Siamo arrivati al terzo sistema per avviare un demone.

Definizione10: Utilizzando il comando chkconfig possiamo specificare il servizio che si vuole avviare e il runlevel in cui deve essere avviato.
Proviamo a far partire il web server apache al runlevel 3:

[root@diamondhead rc3.d]# chkconfig –level 3 httpd on

se andiamo a controllare dentro /etc/rc.d/rc3.d vedremo che il link è stato creato dal comando chkconfig:

[root@diamondhead rc3.d]# cd /etc/rc.d/rc3.d/
[root@diamondhead rc3.d]# ls


K16rarpd K65identd S06reconfig S55sshd S85httpd

per disabilitarlo scriviamo:

[root@diamondhead rc3.d]# chkconfig –level 3 httpd off

meglio abilitarlo:

[root@diamondhead rc3.d]# chkconfig –level 3 httpd on

per conoscere le informazioni di avvio di un servizio scriviamo:

[root@diamondhead rc3.d]# chkconfig –list httpd
httpd 0:off 1:off 2:off 3:on 4:off 5:off 6:off

vediamo che il web server apache è disattivato al runlevel 0, 1 e 2, attivato al 3, disattivato al 4, 5 e 6. Un modo per vedere lo stato di tutti i servizi del nostro sistema è digitare:

[root@diamondhead rc3.d]# chkconfig –list

qui abbiamo un elenco di tutti gli stati dei servizi. Verso la fine dell’output vediamo una dicitura “servizi basati su xinetd”. Questi sono servizi che vengono mandati in esecuzione SOLO quando c’è una richiesta da soddisfare. Non sono perennemente in ascolto, come gli altri, ma in uno stato di riposo. Sul mio sistema ho l’rsh su on, se provo a vederlo con un ps non lo troverò:

[root@diamondhead rc3.d]# ps -ef | grep rsh

C’è qualcuno di voi che ha un servizio xinetd su on? Provate a visualizzarlo come ho fatto io con rsh. Non lo troverete. Questo perchè il servizio parte solo quando serve, quindi è fermo, e non appena serve parte per l’occasione per spegnersi subito dopo. Un server come httpd che abbiamo visto è detto standalone, mentre un server che parte quando serve è detto “extended internet services daemon” o xinetd. In pratica, un server di questo tipo non ha tante richieste da soddisfare: qui troveremo il server telnet, l’ftp etc. Mentre se abbiamo un sito molto trafficato ci conviene fare in modo di tenere l’httpd sia perennemente in ascolto.

Per dimostrare questo abilitiamo il servizio telnet dentro la directory
/etc/xinet.d:

[root@diamondhead /root]# vi /etc/xinetd.d/telnet
disable = no

qui ci sono tutti i servizi xinetd. Adesso per fare in modo di aggiornare l’xinetd dobbiamo riavviarlo:

[root@diamondhead /root]# /etc/rc.d/init.d/xinetd restart

Come si vede lo stesso xinetd è un servizio che resta in ascolto in background, e che gestisce però tutti i servizi xinetd che si trovano dentro la directory /etc/xinetd.d/. Riavviando il servizio xinetd aggiorneremo tutte le impostazioni dei server dentro la directory /etc/xinetd.d compreso il disable=no appena impostato del servizio telnetd.

proviamo a fare un:

[root@diamondhead rc3.d]# ps -ef | grep telnetd

non troveremo nulla, anche se il telnetd è stato abilitato. Questo perchè parte il demone telnetd parte solo su richiesta. Ora proviamo ad aprire un’altra console e a fare un:

[root@diamondhead /root]# telnet 192.168.1.1

ovviamente sostituite l’ip con quello del vostro computer. Autenticativi con la vostra username e password. Una volta autenticati proviamo dall’altra console a fare un:

root 1605 1522 0 11:27 ? 00:00:00 in.telnetd: geelong.r3d.it

vediamo appunto che il demone telnetd è partito e resterà attivo fino alla chiusura della sessione.

Il comando chkconfig può gestire anche i servizi xinetd in questo
modo:

[root@diamondhead /root]# chkconfig telnet on
[root@diamondhead /root]# chkconfig –list telnet
telnet on

ora proviamo a disabilitarlo:

[root@diamondhead /root]# chkconfig telnet off
[root@diamondhead /root]# chkconfig –list telnet
telnet off

Leave a Reply