Torna al sito principale

7. Migliorie

7.1. Partizioni FAT e permessi
7.2. Servizi, demoni ed altre cose utili
7.3. Gli script di avvio
7.4. Demoni servizievoli

Funziona, ma così è meglio

Qui vedremo alcune piccole modifiche che ci possono rendere l'uso di Fedora ancora più semplice e confortevole.

7.1. Partizioni FAT e permessi

Se al momento di installare abbiamo creato anche una partizione di scambio fra Windows e Linux (Sezione 3.2, «Un solo disco e niente spazio») o ne avevamo già una, con filesystem FAT o FAT32, e la abbiamo fatta montare in automatico all'avvio di Linux sotto una directory, che possiamo immaginare sia /win, abbiamo un problema: solo l'utente root può scriverci dentro. Tutti gli altri possono solo leggerne il contenuto. Ovviamente così è inutile.

Il problema si risolve abbastanza facilmente, e si può scegliere fra due differenti possibilità: una più semplice, ma infinitamente meno sicura se il computer lo usano più persone, ed una poco più complessa che garantisce un minimo di sicurezza.

Il problema nasce dal fatto che il filesystem FAT non possiede indicazioni sul proprietario dei singoli file, cosa che invece in Linux è fondamentale. Quindi, quando si vanno a montare partizioni FAT, Linux in mancanza di indicazioni assegna la proprietà di tutti i file all'utente root ed al gruppo root. Poi stabilisce che solo il proprietario può scrivere, mentre tutti gli altri possono solo leggere, e dato che i singoli file nel filesystem FAT non hanno dati di appartenenza, tutti i file e le directory sono assegnati allo stesso utente e con gli stessi permessi. Per capirci, se la partizione è montata nella directory /win, avremo:

$ ls -l /
...  
drwxr-xr-x  14 root root   4096 18 gen 09:09 usr
drwxr-xr-x  25 root root   4096 19 feb 23:11 var
drwxr-xr-x   7 root root   8192  1 gen  1970 win

ossia la directory appartiene a root e solo il proprietario ha il permesso di scrittura (la prima 'w'). Non solo, ma tutti i file dentro /win avranno lo stesso tipo di permessi ed apparterranno a root.

Se vogliamo applicare la modifica semplice (consigliata solo se ad usare Linux è una sola persona), basta aprire il file /etc/fstab da root e puntare la riga dove si fa riferimento alla directory in cui è montata la partizione FAT, come in questo esempio:

...
proc           /proc       proc    defaults        0 0
/dev/sda3      /win        vfat    defaults        0 0

In questo esempio la riga è l'ultima. Va modificata in questo modo:

...
proc           /proc       proc    defaults        0 0
/dev/sda3      /win        vfat    defaults,umask=0     0 0

ossia aggiungendo il parametro umask, separato da una virgola. Non va inserito nessuno spazio, la modifica deve essere esattamente come mostrato, pena non solo il non funzionamento, ma il probabile blocco all'avvio per via del file /etc/fstab errato.

Per capire cosa fa il parametro umask, basta dire che elenca in modo numerico i permessi da togliere al momento dell'operazione di mount. Mettendo uno zero, si impone di lasciare tutti i permessi.

Per rendere effettive le modifiche il sistema più semplice è riavviare, oppure da utente root dare questi comandi in sequenza:

# umount /win
# mount -a	  

che “smontano” la partizione e la rimontano con i nuovi parametri. Ora la situazione dovrebbe essere:

$ ls -l /
...  
drwxr-xr-x  14 root root   4096 18 gen 09:09 usr
drwxr-xr-x  25 root root   4096 19 feb 23:11 var
drwxrwxrwx   7 root root   8192  1 gen  1970 win

con la directory /win che ha tutti i permessi per tutti, ossia chiunque può scrivere, modificare e cancellare i file al suo interno.

Ovviamente questo non è il massimo della sicurezza, soprattutto se il computer lo usano più persone. Se ad esempio non vogliamo che altri possano modificare il contenuto della partizione FAT, o vogliamo che neanche possano guardarci dentro, questo tipo di modifica non ce lo permette.

Possiamo allora decidere per la strada un po più complessa, ma certamente più sicura. In questo caso le modifiche al file /etc/fstab saranno più articolate, per la precisione:

...
proc           /proc       proc    defaults        0 0
/dev/sda3      /win        vfat    defaults,umask=002,gid=users    0 0

sempre prendendo ad esempio la versione mostrata prima. Oltre ad aver aggiunto un nuovo parametro, abbiamo che il valore per umask è differente. In questo caso abbiamo definito che viene tolto il permesso di scrittura, tranne a proprietario e gruppo di appartenenza. Inoltre il parametro gid (che sta per group id), indica che il gruppo di utenti a cui appartiene la directory sarà il gruppo users, uno dei gruppi predefiniti già presenti in quasi tutte le distribuzioni Linux. Il risultato, dopo un riavvio o i comandi mostrati prima, sarà:

$ ls -l /
...  
drwxr-xr-x  14 root root   4096 18 gen 09:09 usr
drwxr-xr-x  25 root root   4096 19 feb 23:11 var
drwxrwxr-x   7 root users  8192  1 gen  1970 win

con la directory /win che appartiene ora al gruppo di utenti users, che possono modificarne il contenuto, e tutti gli altri solo vederlo. Se volessimo invece anche nascondere il contenuto a tutti, il parametro umask deve valere 007, ed il risultato sarà:

$ ls -l /
...  
drwxr-xr-x  14 root root   4096 18 gen 09:09 usr
drwxr-xr-x  25 root root   4096 19 feb 23:11 var
drwxrwx---   7 root users  8192  1 gen  1970 win

e nessun permesso viene concesso a gli utenti non appartenenti al gruppo users.

I permessi in umask sono quelli da togliere

Una cosa che spesso manda in confusione è il fatto che i permessi elencati in umask sono quelli da togliere, non quelli che vogliamo.

Rimane il fatto che nessun utente appartiene a questo gruppo, quindi per il momento nessuno può accedere al contenuto della partizione FAT, a parte l'utente root. Niente di più semplice: usando la gestione utenti vista in precedenza (Figura 72, «L'amministrazione degli utenti»), che troviamo nel menù Sistema, Amministrazione, alla voce Utenti e gruppi, possiamo aggiungere al gruppo users tutti gli utenti a cui vogliamo dare accesso alla partizione FAT, selezionando l'utente da modificare, premendo il pulsante Proprietà, dal pannello che si apre punteremo la sezione Gruppi (Figura 143, «Aggiungere un utente ad un gruppo»), e spunteremo il gruppo users per assegnare l'utente anche a quel gruppo.

Figura 143. Aggiungere un utente ad un gruppo

Aggiungere un utente ad un gruppo


Si può aggiungere un utente a tutti i gruppi che si vuole, senza restrizioni, anche se ovviamente solo l'utente root può aggiungere o togliere utenti, per ovvi motivi.

Per chi invece preferisce la shell, si usa il comando usermod, in questo modo:

# usermod -G users mario

dove dopo il parametro -G si devono elencare tutti i gruppi a cui l'utente appartiene, meno quello primario, in questo caso solo users, terminando con lo username dell'utente che vogliamo modificare, in questo caso mario. Attenzione che se l'utente appartiene ad altri gruppi devono essere elencati tutti, altrimenti verrà rimosso da quelli non elencati.

Le modifiche avranno effetto solo dopo essere usciti dalla sessione, dal menù Sistema, Termina sessione di.... Quando rientreremo con il nostro utente solito, potremo accedere a piacimento alla partizione FAT, e solo chi appartiene al gruppo users potrà.

7.2. Servizi, demoni ed altre cose utili

Ad ogni accensione e ad ogni spegnimento del computer abbiamo certamente notato i vari messaggi che informano dell'avvio o dell'arresto di una serie di programmi dai nomi più o meno fantasiosi. Questa sequenza di operazioni è eseguita in tutti i sistemi operativi degni di questo nome, e serve a preparare per l'uso delle particolari applicazioni necessarie durante la nostra normale attività al computer. Alcuni esempi: il servizio di stampa, l'esecuzione di programmi ad un certo orario, il servizio di shell remota, i log di sistema. Prendiamo l'esecuzione ad orario di programmi: l'applicazione che se ne occupa è il cron daemon, il cui programma si chiama crond. Questo programma ogni minuto controlla se ci sono programmi da eseguire, secondo una serie di istruzioni molto semplici contenute nel file /etc/crontab e nelle directory /etc/cron.d, /etc/cron.daily, /etc/cron.weekly e /etc/cron.monthly. Se non c'è nulla da fare, il programma torna in uno stato di “sonno” (il termine tecnico è proprio sleep, sonno, dormire). Sebbene questa operazione sia eseguita ogni minuto, il tempo totale consumato dopo ore ed ore di funzionamento del computer è praticamente nullo: in un computer che esegue normali attività è circa un secondo a settimana. Questo è reso possibile sia dai meccanismi interni del sistema operativo, sia dal funzionamento stesso dell'applicazione, che sfrutta proprio questi meccanismi per i suoi compiti.

Altre applicazioni di questo tipo sono invece attivate da eventi specifici: ad esempio il servizio di stampa rimane totalmente inattivo fino a quando un altro programma lo contatta per avviare una stampa. Oppure, nel caso del servizio di remote shell, rimane in attesa di una connessione in arrivo dalla rete, a seguito della quale si attiva.

In una normale installazione di Linux, per uso desktop, possono esserci venti o trenta di questi servizi in funzione, mentre in una installazione server possono arrivare a superare la quarantina, in funzione del tipo di server.

Esistono vari modi per controllare i servizi attivi, cambiarne lo stato, decidere se avviarli automaticamente: il più immediato è da interfaccia grafica, nel menù Sistema, Amministrazione, Impostazioni server alla voce Services (Figura 144, «La GUI per la gestione dei servizi»).

Figura 144. La GUI per la gestione dei servizi

La GUI per la gestione dei servizi


Questa interfaccia può essere chiamata anche da un terminale X usando il comando system-config-services. Oppure, da una console o da un terminale X possiamo utilizzare l'interfaccia in modo testo semplificata, lanciando il comando ntsysv (Figura 145, «Gestione dei servizi da console»). In ogni caso occorrono i privilegi dell'utente root per toccare queste impostazioni, cosa abbastanza ovvia.

Figura 145. Gestione dei servizi da console

Gestione dei servizi da console


Il terzo ed ultimo modo è con l'uso del comando chkconfig, che consente tutte le operazioni degli altri due metodi, ma dalla shell.

C'è un ulteriore aspetto dei servizi da tenere in conto: ogni servizio può essere avviato in funzione del runlevel (Sezione 5.12, «Per tornare alla modalità grafica: i runlevel»), cioè essere in funzione ad esempio solo per il runlevel in cui abbiamo il desktop grafico e non quando il desktop non è avviato. Questa che a prima vista sembra una complicazione, è in realtà una caratteristica che conferisce una flessibilità ed una adattabilità che altrimenti sarebbero impossibili. Quello che occorre ricordare è che se non diversamente specificato le modifiche sono riferite al runlevel attivo nel momento in cui si opera. Con il comando ntsysv si può indicare usando una opzione apposita:

# ntsysv --level 35

indica ad esempio che i servizi che andiamo a modificare sono quelli per i runlevel 3 e 5. Nella versione GUI, nel menù Modifica runlevel si può selezionare quello su cui si intende operare, il predefinito è sempre quello corrente.

7.3. Gli script di avvio

Come viene realizzato tutto questo? Nella directory /etc/init.d/ vi sono parecchi file, ognuno dei quali è uno script shell, ossia un breve programma, che di solito accetta un parametro, scelto fra due: start e stop. Se vogliamo avviare un servizio basta chiamare il relativo script con il parametro start, e per fermarlo lo chiameremo con stop. Per esempio, per fermare il servizio di cui parlavamo, quello di esecuzione programmi ad orario, il comando sarà:

# /etc/init.d/crond stop
Interruzione di crond:                                     [  OK  ]      

mentre per avviarlo il comando sarà:

# /etc/init.d/crond start
Avvio di crond:                                            [  OK  ]	

Alcuni di questi script accettano anche altri parametri, come restart (ferma e riavvia il servizio), status (riporta se il servizio è avviato), reload (costringe il servizio a rileggere la sua configurazione senza interrompere le operazioni, a differenza di restart) e condrestart (riavvia il servizio solo se è già avviato, mentre restart lo avvia anche se non era in funzione). Ma quelli che servono sono start e stop.

Esistono poi sette directory in /etc, chiamate /etc/rcN.d, dove N è un numero da 0 a 6, una per ogni runlevel, contenenti dei link simbolici agli script in /etc/init.d. Questi link simbolici hanno dei nomi particolari, che hanno uno scopo ben preciso:

  • Il nome inizia per 'S' o per 'K'. La ragione è che al momento di entrare in quel runlevel vengono eseguiti gli script che iniziano per 'K' con il parametro stop, e con il parametro start quelli che iniziano con 'S'.

  • Dopo la prima lettera, segue un numero a due cifre, da 00 a 99. Questo numero indica la precedenza, ossia l'ordine con cui vengono eseguiti gli script, partendo da 00 e via via andando verso il 99.

  • L'ultima parte indica il servizio a cui ci si riferisce.

Per esempio, in /etc/rc5.d, esiste il file S90crond, e tenendo presente quanto appena detto sappiamo che all'ingresso in runlevel 5 sarà eseguito lo script /etc/init.d/crond con il parametro start. Il numero 90 ci dice anche che il servizio sarà avviato quasi al termine della sequenza di avvio.

Andando a curiosare nella directory /etc/rc6.d, troviamo che tutti i link iniziano con 'K', tranne due: S00killall e S01reboot. Sappiamo che il runlevel 6 è il riavvio del computer, per cui il contenuto di questa directory diventa immediatamente comprensibile: vengono arrestati tutti i servizi, poi viene mandato un segnale particolare (il kill) a tutti i servizi rimasti in esecuzione (tra cui quelli avviati da noi e che non era previsto fossero avviati) usando lo script /etc/init.d/killall, e di seguito viene effettivamente riavviato il computer.

La numerazione, e quindi la posizione nella sequenza di avvio o spegnimento, è definita nello script del servizio stesso, e deve essere stabilita da chi crea il servizio. Dato che solo lui sa da quali altri servizi dipende, solo lui può stabilire in quale ordine deve essere avviato o spento. Un esempio: il servizio shell remota (avviato con lo script /etc/init.d/sshd) ha bisogno che ci siano le interfacce di rete attive (avviate con lo script /etc/init.d/network), e se andiamo a curiosare in /etc/rc5.d scopriamo che i rispettivi link sono S55sshd e S10network, quindi siamo certi che la shell remota viene avviata solo dopo le interfacce di rete.

Stili di init: System V e BSD

Esistono due stili per gestire l'inizializzazione del sistema: quello detto System V è quello di Fedora, Debian, RedHat, Suse, ed usa il metodo qui descritto, mentre ad esempio Slackware usa lo stile BSD, dove esiste un solo script per ogni runlevel che contiene tutto, anche se questa divisione non è più così rigida, e ora lo stile BSD ha la possibilità di eseguire script aggiuntivi di avvio, rendendo molto più flessibile.

I tre programmi di cui abbiamo parlato, quello in GUI (Figura 144, «La GUI per la gestione dei servizi»), ntsysv e chkconfig, non fanno altro che modificare i nomi dei link simbolici nelle varie directory dei runlevel. Se ad esempio andiamo a disattivare l'avvio del servizio di shell remota nel runlevel 5, viene cancellato dalla directory etc/rc5.d il link dal nome S55sshd e ne viene creato uno dal nome K25sshd.

Questo non modifica attuale lo stato del servizio

Queste modifiche non toccano il servizio, nel senso che se la shell remota è in esecuzione non viene fermata se la disattiviamo, occorre farlo esplicitamente chiamando lo script apposito con il parametro stop, dalla GUI usando il pulsante Ferma, oppure riavviando il computer (manovra che dovremmo aver compreso essere eccessiva per un solo servizio, e nella maggior parte dei casi).

Le modifiche avranno effetto solo al prossimo avvio del computer o al prossimo cambio di runlevel.

Se abbiamo seguito il discorso (effettivamente un po' difficile e specialistico), dovremmo aver capito l'estrema flessibilità e il livello di controllo che è possibile avere su un computer in cui è installato Linux.

7.4. Demoni servizievoli

Vediamo una breve carrellata dei servizi disponibili in una tipica installazione di Fedora, con le funzioni che mettono a disposizione. Distingueremo fra demoni e non: i demoni sono applicazioni che vengono avviate e rimangono attive fino allo spegnimento del computer, in attesa di essere chiamate a svolgere i compiti per cui sono pensate; gli altri invece sono invece dei servizi che eseguono il loro compito quando vengono chiamati e poi terminano, non rimanendo ad occupare risorse. Per ogni servizio vedremo se e quando serve tenerlo attivo.

  • NetworkManager e NetworkManagerDispatcher: è un demone che tiene sotto controllo le interfacce di rete e opera per passare da una all'altra se serve. Ad esempio, se abbiamo sia la ethernet che la wireless, siamo collegati con ethernet e stacchiamo il cavo, il demone attiva quella wireless, ovviamente se disponibile. Il dispatcher è legato appunto a questa operazione di commutazione e si usa per avvertire eventuali altri servizi del cambiamento. Ovviamente vanno configurati in modo specifico per il nostro computer e per la nostra infrastruttura di rete per operare correttamente. Se usiamo un solo tipo di connessione di rete, sono del tutto inutili e li possiamo tenere disattivati.

  • acpid: è un demone che riceve gli eventi riguardanti l'alimentazione del computer e altri relativi ad esempio alla chiusura del display nei notebook, secondo lo standard ACPI. In Fedora, per alcune funzioni, è sostituito dall'applicazione gnome-power-manager che si occupa di tutti gli aspetti dell'alimentazione, compreso lo spegnimento del computer, ma solo se c'è il desktop attivo. Conviene tenerlo attivo.

  • anacron: è un demone, e si occupa di eseguire i compiti che erano previsti per un certo orario, per l'apposito demone di esecuzione ad orario, e che per qualche motivo non sono stati completati, di solito perché il computer è spento, o per via di un fermo per manutenzione. Possiamo tenerlo attivo, dato che anche sui computer per uso personale alcune funzioni sono configurate per essere eseguite intorno alle 04:00, orario in cui il computer normalmente è spento. All'accensione, dopo una pausa e solo se il computer non sta lavorando a qualche cosa di impegnativo, vengono eseguiti i compiti rimasti indietro.

  • apmd: è un demone dedicato alla gestione dell'alimentazione e del risparmio energetico tramite APM, esattamente come acpid, ma solo per i computer più “anziani”. Nei moderni computer non si usa più, e possiamo tenerlo spento. In ogni caso dovrebbe disattivarsi se non trova il supporto per APM, e se abbiamo un computer costruito dopo il 2001 è del tutto inutile.

  • atd: è un demone, parente del crond, che serve ad eseguire altri programmi ad un certo orario o dopo un certo tempo. Ad esempio possiamo decidere di far eseguire al computer un download a partire da mezzanotte di oggi, oppure fra 16 ore esatte a partire da ora. A differenza del crond, il compito viene eseguito una sola volta e non periodicamente. Se non ci serve lo lasciamo disattivato.

  • autofs: serve a montare automaticamente filesystem fisicamente esterni al computer, come condivisioni file su server Windows o NFS. Se non sappiamo cosa sia, lasciamolo spento.

  • avahi-daemon e avahi-dnsconfd: se abbiamo nella nostra rete un server di configurazione automatica Avahi, questi demoni si occupano di rilevare e configurare tutto quanto riguarda la connessione di rete. Se non sappiamo cosa sia Avahi, possiamo lasciarli entrambi spenti.

  • bluetooth: è un demone (in realtà sono due, hcid e sdpd), che come suggerisce il nome serve a gestire le periferiche Bluetooth visibili dal computer. Se non abbiamo interfaccia Bluetooth o non abbiamo periferiche di questo tipo, possiamo tenerlo spento.

  • capi e isdn: sono due demoni usati per la gestione di connessioni con linea di tipo ISDN. Se non abbiamo questo tipo di interfacce e non usiamo una linea ISDN, possiamo tenerli spenti.

  • cpuspeed: permette di sfruttare la variazione di velocità del processore per risparmiare energia e ridurre la dissipazione termica, ovviamente nei computer che lo permettono. Tutti i notebook relativamente recenti (dal 2002-2003 in poi) e gran parte dei computer desktop moderni permettono questa funzione, che nei notebook è fondamentale per aumentare la durata della batteria. Se il nostro computer ha questa funzione lo lasciamo certamente abilitato. Ha una duplice personalità: funziona come demone dove il controllo non è automatizzato nel kernel, mentre in caso contrario si limita ad impostare quello che serve ed esce.

  • crond: questo demone lo conosciamo già (Sezione 7.2, «Servizi, demoni ed altre cose utili»), e lo lasciamo attivo.

  • cups: è un demone che si occupa di gestire il servizio di stampa. Se vogliamo poter stampare, anche se la stampante è collegata ad un altro computer, dobbiamo averlo attivo.

  • dhcdbd: è un demone e si usa in congiunzione con NetworkManager. Se non usiamo NetworkManager possiamo tenerlo spento.

  • diskdump: se è attivata la rispettiva funzione nel kernel serve a salvare un file di diagnostica nel caso in cui il computer fosse andato in crash per via di un problema nel kernel. Se non stiamo facendo sviluppo per il kernel è inutile.

  • dund: è un demone che attiva automaticamente una connessione di rete via Bluetooth, usando una determinata periferica come modem (ad esempio un telefono cellulare abilitato). Anche qui se non abbiamo Bluetooth o non usiamo il cellulare come modem è inutile.

  • firstboot: serve per eseguire il wizard di impostazione alla prima installazione di Linux (Sezione 4.11, «Non poteva mancare...»). Una volta fatta, possiamo disabilitarlo.

  • gpm: è un demone che permette di usare il mouse in una console testo. Se non usiamo mai la console lo possiamo lasciare disabilitato. Non influisce minimamente sull'uso del desktop grafico.

  • haldaemon: è un demone fondamentale per l'uso con il desktop grafico. Si occupa di raccogliere tutte le informazioni sull'hardware e sugli eventi correlati, come l'inserimento di un CD nel lettore, o il cambio di alimentazione da rete a batteria. Lo disabilitiamo solo se sappiamo cosa stiamo facendo.

  • hidd: anche questo demone è legato alla presenza di interfaccia Bluetooth, e serve per utilizzare tastiere e mouse collegate via Bluetooth.

  • hplip: sono due demoni (hpiod e hpssd) che permettono una gestione più completa di stampanti e scanner HP™. Lavora in tandem con Cups. Se abbiamo una stampante, uno scanner o un multifunzione di questo produttore lasciamo attivo il servizio.

  • ip6tables e iptables: serve ad impostare il firewall di Linux (ip6tables è per IPv6). Prevede altri due parametri da usare in casi particolari: save e panic. Con save viene salvata l'attuale configurazione del firewall (nel file /etc/sysconfig/iptables), quella in esecuzione. E' molto comodo perché consente di lavorare sulla configurazione con il firewall attivo e quando si raggiunge lo stato desiderato si “fotografa” per avere pronte le impostazioni ad ogni avvio. Con panic invece si ottiene l'effetto di scollegare i cavi di rete: si isola il computer da tutte le reti a cui è connesso. Come è facile capire, serve in situazioni di emergenza estrema. Lasciando attiva questa voce ad ogni avvio viene impostato il firewall secondo la configurazione salvata in /etc/sysconfig/iptables. Lo lasciamo attivo solo se abbiamo bisogno del firewall.

  • irda: è un demone che gestisce le interfacce a raggi infrarossi, usate su alcuni telefoni cellulari e su alcune periferiche. Se non abbiamo questo tipo di interfaccia o non abbiamo periferiche di questo tipo possiamo disattivarlo.

  • irqbalance: è un demone che si usa per ripartire il lavoro di gestione delle periferiche del computer fra due o più processori. Se abbiamo un computer del tipo dual-core o simili lo lasciamo abilitato, altrimenti è inutile.

  • kudzu: serve a rilevare nuove periferiche o cambiamenti nelle periferiche esistenti ed applicare le modifiche necessarie ai file di configurazione. Dovrebbe essere sostituito a breve perché sta progressivamente diventando inutile, soppiantato da tecnologie più moderne ed efficaci. Viene eseguito solo all'avvio, e lo possiamo lasciare attivo, a meno di problemi specifici.

  • lm_sensors: è un demone che permette di tenere sotto controllo i parametri hardware del computer come temperature, tensioni di alimentazione, velocità delle ventole, ovviamente se il computer è dotato delle relative funzioni. Permette anche di essere avvisati se qualcuno dei parametri di funzionamento va fuori limite. Per maggiori informazioni possiamo fare riferimento alla documentazione di lm_sensors.

  • mcstrans e restorecond: sono demoni che si usano con SELinux. Se non sappiamo cosa siano, o abbiamo disabilitato SELinux all'avvio, possiamo lasciarli disabilitati.

  • mdmonitor: è il demone che tiene sotto controllo il RAID software di Linux. Se usiamo questa funzione del kernel per la nostra installazione, questo demone ci tiene informati di anomalie e problemi.

  • mdmpd e multipathd: sono due demoni che permettono di avere la funzione detta multipath per i dispositivi di archiviazione. Detto in modo molto semplice, possiamo avere più interfacce per accedere agli stessi dischi ed in caso di guasto di una di esse, il demone multipathd si occupa di passare all'altra interfaccia in modo trasparente e senza interruzioni di servizio, mentre il demone mdmpd si occupa di tenere sotto controllo la situazione ed avvisare in caso di problemi. Ovviamente devono essere opportunamente configurati. Se non sappiamo cosa sia il multipath, possiamo lasciarli disabilitati entrambi.

  • messagebus: è un demone che si occupa di far comunicare vari componenti del computer e del sistema operativo fra loro. E' fondamentale per l'uso desktop, dove si occupa ad esempio di trasmettere informazioni su stato dell'alimentazione, inserimento di supporti di archiviazione, cambio di stato delle interfacce di rete e molti altri eventi. Se usiamo il desktop grafico deve essere abilito, pena la perdita di gran parte degli automatismi e di tutta la comodità nell'uso.

  • microcode_ctl: è uno script che permette di aggiornare il microcodice della CPU, se il produttore ne ha rilasciato uno. Se non sappiamo a cosa serve possiamo lasciarlo disabilitato.

  • netdump: è una funzione collegata con l'attività di sperimentazione del kernel. In caso di crash del kernel permette di trasmettere via rete ad un server tutti i dati necessari per individuarne il motivo. Se non facciamo attività di sviluppo e collaudo del kernel non ci serve.

  • netfs: è uno script che si occupa di montare i dispositivi di memorizzazione accessibili via LAN, tipicamente condivisioni disco Windows o Samba, NFS o NetWare™. Ovviamente deve essere configurato, e se non abbiamo condivisioni disco a cui accedere possiamo lasciarlo disattivato. Non serve se dobbiamo accedere saltuariamente a dischi condivisi con Windows, e non serve neanche se dobbiamo condividere noi spazio disco dal computer su cui è installato Linux. Per chi usa Windows, è l'equivalente di spuntare la casella Riconnetti all'avvio in una unità di rete. In generale non si usa se non in ambienti di lavoro specifici. Possiamo lasciarlo disattivato.

  • netplugd: è un demone per gestire interfacce di rete che vengono connesse e sconnesse dinamicamente. Se ad esempio il computer ha due interfacce di rete ethernet, è in grado di rilevare quando il cavo viene connesso o scollegato ed operare di conseguenza. Deve essere configurato opportunamente, ed il suo uso è strettamente specialistico. Possiamo lasciarlo disattivato.

  • network: è lo script che si occupa di avviare le interfacce di rete configurate per attivarsi alla partenza del computer, indipendentemente dal tipo. E' fondamentale per usare il computer, anche se non connesso in rete, dato che in caso di computer totalmente isolato dal mondo serve ad attivare una interfaccia particolare detta loopback, necessaria per il funzionamento del sistema operativo e di parecchie applicazioni. Anche se non abbiamo collegamento in rete lo lasciamo sempre attivo.

  • nfs: è il demone del server di Network File System, un sistema di condivisione disco simile a quello di Windows, ma fatto per i sistemi Unix, e quindi che tiene conto della presenza di utenti, gruppi e permessi. Questo demone è il server, ossia ci consente di condividere spazio dai nostri dischi. Se non dobbiamo condividere specificamente con questo sistema possiamo lasciarlo spento.

  • nsflock, portmap, rpcgssd, rpcidmapd, rpcsvcgssd: sono tutti demoni connessi con l'uso di Network File System. Se non usiamo NFS, possiamo lasciarli tutti spenti.

  • nscd: è un demone di cache per alcuni servizi lenti tipo NIS e LDAP. Se non sappiamo cosa siano, possiamo lasciarlo spento.

  • ntpd: è il demone di sincronizzazione oraria che usa il Network Time Protocol. Se abbiamo configurato al momento dell'installazione i server NTP (Sezione 4.13, «Sempre puntuali») lo lasciamo attivo.

  • pand: è un demone che permette di attivare interfacce di rete connesse attraverso il protocollo Bluetooth. Se abbiamo le relative periferiche, lo configuriamo ed attiviamo, altrimenti è inutile.

  • pcscd: è il demone che permette l'accesso e l'uso di smartcard in Linux. Se abbiamo un lettore di smartcard compatibile con Linux e le relative schede possiamo attivarlo ed utilizzarlo, altrimenti è inutile.

  • psacct: è un demone che permette di tenere sotto controllo l'uso delle risorse del sistema da parte dei processi. E' di uso specialistico e se non sappiamo a cosa serve possiamo lasciarlo disattivato.

  • rdisc: è un demone che si occupa di collezionare informazioni sui router presenti in rete e raggiungibili dal computer. E' di uso specialistico, e lo possiamo lasciare disattivato. Non sostituisce la configurazione tramite server DHCP.

  • readahead_early e readahead_later: si occupano di caricare in anticipo programmi in memoria prima che servano, per rendere più veloce l'avvio del computer. Possiamo lasciarli abilitati.

  • sendmail: è il demone di invio messaggi, sia interni al computer che tramite il protocollo SMTP. Se opportunamente configurato può spedire direttamente messaggi via Internet a chiunque. Lo possiamo lasciare attivo, nella configurazione base è in grado di consegnare i messaggi interni.

  • smartd: è il demone che si occupa di controllare lo stato e l'operatività dei dischi interni del computer attraverso la tecnologia detta SMART (Self Monitoring, Analysis and Reporting Technology). Per i dischi fissi dotati di questa tecnologia è possibile avere informazioni in anticipo sulla eventualità di un guasto distruttivo, attraverso l'autocontrollo che i dischi stessi fanno di alcuni parametri di funzionamento. Ovviamente questo sistema permette di prevedere i guasti per usura, non i guasti improvvisi dovuti ad un cedimento di un componente elettronico o di una parte meccanica. Questo demone, opportunamente configurato, avvisa sia attraverso i log di sistema che attraverso un messaggio di posta elettronica che qualcosa sta per succedere.

  • smb e winbind: è il demone Samba, che permette di condividere spazio disco e stampanti da un computer Linux per computer con installato Windows. Normalmente è sufficiente il solo servizio smb, il servizio winbind serve solo in casi limitati, come ad esempio quando si aggancia il computer con Linux come server ad un dominio preesistente. Per maggiori dettagli è meglio consultare la documentazione di Samba. Se intendiamo far accedere computer con Windows ai nostri file ed alla stampante installata su Linux, dobbiamo attivare il servizio smb. Se invece dobbiamo accedere da Linux a file o stampanti su un computer Windows, questi servizi non sono necessari e possiamo lasciarli spenti.

  • snmpd e snmptrapd: sono due demoni che usano il protocollo SNMP per fornire due differenti servizi. Nel caso di snmpd, permette di tenere sotto controllo alcuni parametri di funzionamento del computer da un altro computer, interrogando appunto il servizio. Questi parametri possono andare da spazio disco e memoria occupata, per arrivare all'elenco di programmi installati o alla temperatura di alcuni componenti del computer. Esistono poi delle particolari applicazioni che collezionano questi dati e li presentano in forma grafica, consentendo di tenere sotto controllo il funzionamento di molti computer da un solo punto di osservazione (vedere ad esempio: OpenNMS, Nagios, Cacti, tutti prodotti Open Source, gratuiti, ed analoghi a prodotti commerciali molto noti). Non ultimo, il demone snmpd può inviare allarmi in caso di problemi, come un disco pieno su un server o una temperatura eccessiva del processore.

    Il servizio snmptrapd serve per una ulteriore funzione definita nel protocollo SNMP, detta di trap. Quando si verifica un evento che richiede attenzione immediata, un dispositivo o un computer può inviare un messaggio che quando viene ricevuto attraverso questo servizio può scatenare azioni predeterminate, come mandare un messaggio e-mail o avviare una applicazione.

    Sono comunque entrambi servizi ad uso specialistico, e se non sappiamo cosa siano possiamo lasciarli spenti.

  • spamassassin: è il servizio di filtro antispam per i messaggi di posta elettronica. Si usa solo se il computer agisce da server di posta aperto su Internet, altrimenti è inutile. I client di posta come Thunderbird ed Evolution hanno i loro sistemi antispam, ed Evolution usa spamassassin, ma lo gestisce autonomamente, per cui possiamo lasciarlo disattivato. In realtà si può usare anche per filtrare la nostra posta Internet, ma occorre sapere come configurarlo e come istruire il programma di posta elettronica per utilizzarlo come filtro.

  • sshd: è il servizio di Secure Shell, utilissimo per gestire il computer via rete da un altro computer. Se sappiamo come usare ssh possiamo lasciarlo attivo, altrimenti è inutile. Ovviamente serve solo per consentire ad altri computer di collegarsi al nostro, mentre non serve se dobbiamo collegarci via ssh ad altri computer.

  • syslog: è il servizio che si occupa di registrare i log di sistema, un diario dettagliato di quello che succede dentro il nostro computer. E' fondamentale per tirarci fuori d'impaccio quando siamo nei guai, per capire cosa è andato storto. Lasciamolo sempre attivo.

  • wpa_supplicant: è il servizio che consente di utilizzare la cifratura WPA nelle reti WiFi. Se abbiamo una di queste reti e dobbiamo accedervi, va configurato e lasciato attivo, altrimenti è inutile.

  • xfs: è il demone che fornisce il servizio X Font Server, ossia offre all'applicazione che mostra il desktop i font di caratteri. Non si usa quasi più, e possiamo lasciarlo disattivato: il nostro server X troverà tutti i font che gli servono accedendo direttamente alle directory dove sono conservati.

    Storicamente si usava per centralizzare tutti i font, in modo che tutti i computer di una rete usassero gli stessi e quindi la visualizzazione fosse uniforme indipendentemente dal computer.

  • ypbind: Yellow Pages (YP) è un servizio “storico” per centralizzare informazioni riguardo account utente e permessi di accesso alle risorse. Il servizio ypbind serve a connettersi ad un server Yellow Pages e leggerne le informazioni. Non c'entra nulla con le Pagine Gialle™, e lo useremo solo se abbiamo nella nostra rete un server di questo tipo, ma è abbastanza improbabile. Possiamo lasciarlo spento.

  • yum-updatesd: è il servizio di notifica degli aggiornamenti, che si può configurare anche per scaricarli ed installarli autonomamente. Nella configurazione predefinita controlla soltanto la presenza nuovi pacchetti da scaricare. Personalmente preferisco tenerlo disattivato ed essere iscritto alla mailing list di Fedora che notifica gli aggiornamenti con la relativa priorità, e scelgo io se e quali installare.

Se abbiamo installato anche server specifici come Apache o MySQL, troveremo nella lista dei servizi anche questi. Quelli elencati qui sono presenti un una normale installazione di tipo desktop/workstation.

Dopo aver deciso cosa serve e cosa no, possiamo spegnere tutti i servizi inutili. Al prossimo avvio potremo constatare che l'elenco sarà notevolmente più corto, ed il tempo di attesa fra la schermata di GRUB e il desktop si sarà sensibilmente ridotto.

Torna al sito principale