Funziona, ma così è meglio
Qui vedremo alcune piccole modifiche che ci possono rendere l'uso di Fedora ancora più semplice e confortevole.
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.
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ù
, , alla voce
, possiamo aggiungere al gruppo users tutti gli utenti a cui vogliamo dare accesso alla
partizione FAT, selezionando l'utente da modificare, premendo il pulsante
, 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.
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ù
, . Quando
rientreremo con il nostro utente solito, potremo accedere a piacimento alla partizione FAT,
e solo chi appartiene al gruppo users potrà.
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ù , , alla voce (Figura 144, «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.
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 35indica ad esempio che i servizi che andiamo a modificare sono quelli per i runlevel 3 e 5. Nella versione GUI, nel menù si può selezionare quello su cui si intende operare, il predefinito è sempre quello corrente.
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.
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.
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
, 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.
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.