«

»

Dic 19

Manuale Amministratore di Sistema

Questa guida la potete scaricare dalla barra destra in amministratore di sistema Basi con una formattazione migliore 🙂

 Guida dell’amministratore di sistema di Linux
 Versione 0.6.2
 Joanna Oja
viu@iki.fi
Introduzione all’amministrazione di un sistema Linux per principianti.
Copyright 1993–1998 Lars Wirzenius.
Traduzione di Eugenia Franzoni <eugenia@pluto.linux.it>
Versione italiana copyright 1998–1999 Eugenia Franzoni.
L’aggiornamento della traduzione italiana è stato finanziato da HOPS libri (http://www.hopslibri.com).
Le sezioni “Le shell” e “X e xdm” del capitolo “Login e logout” sono proprie dell’edizione italiana.
I marchi registrati sono marchi dei rispettivi titolari.
È permesso copiare e distribuire copie esatte di questo manuale, purché la nota di copyright e questa nota vengano mantenute su tutte le copie.
È permesso processare il sorgente del documento con TeX o con altri formattatori, stampare i risultati e distribuire il documento stampato, purché questo contenga una copia identica di questa licenza di distribuzione, inclusi i riferimenti a dove il codice sorgente possa essere trovato ed alla home page ufficiale.
È permesso copiare e distribuire copie modificate di questo manuale sotto le condizioni delle copie identiche, purché l’intero lavoro risultante sia distribuito sotto i termini di una licenza identica a questa.
È permesso copiare e distribuire traduzioni di questo manuale in altre lingue, sotto le stesse condizioni delle versioni modificate.
L’autore apprezza comunicazioni delle modifiche, delle traduzioni e delle versioni stampate. Grazie.
Trademarks are owned by their owners.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to process the document source code through TeX or other formatters and print the results, and distribute the printed document, provided the printed document carries copying permission notice identical to this one, including the references to where the source code can be found and the official home page.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.
The author would appreciate a notification of modifications, translations, and printed versions. Thank you.
Sommario

Dedica
Disponibilità del sorgente e delle versioni preformattate
1. Introduzione
Il Linux Documentation Project
2. Panoramica di un sistema Linux
Le componenti di un sistema operativo
Le parti principali del kernel
I principali servizi in un sistema UNIX
init
Login dai terminali
Syslog
Esecuzione periodica dei comandi: cron e at
GUI – interfaccia grafica utente
Le reti
Login in rete
Filesystem condivisi
La posta elettronica
La stampa
La struttura del filesystem
3. L’albero delle directory
Premesse
La radice del filesystem
La directory /etc
La directory /dev
Il filesystem /usr
Il filesystem /var
Il filesystem /proc
4. Uso dei dischi e di altre memorie di massa
Due tipi di dispositivi
Gli hard disk
I floppy
I CD-ROM
Le unità nastro
La formattazione
Le partizioni
L’MBR, i settori di boot e la tabella delle partizioni
Partizioni estese e partizioni logiche
Tipi di partizione
Ripartizionare un hard disk
File di device e partizioni
I filesystem
Cosa sono i filesystem?
Filesystem a go-go
Quale filesystem bisogna usare?
Come creare un filesystem
Montare e smontare un filesystem
Il controllo dell’integrità di un filesystem con fsck
Il controllo degli errori sul disco con badblocks
Combattere la frammentazione
Altri strumenti per tutti i filesystem
Altri strumenti per il filesystem ext2
Dischi senza filesystem
Allocare spazio disco
Schemi di partizionamento
Requisiti di spazio
Esempi di allocazione di hard disk
Aggiungere altro spazio disco per Linux
Suggerimenti per risparmiare spazio su disco
5. La gestione della memoria
Cosa è la memoria virtuale?
La creazione di uno spazio di swap
Come si usa lo spazio di swap
La condivisione dello spazio di swap con altri sistemi operativi
Allocare lo spazio di swap
La cache di buffer
6. Avvio e spengimento del sistema
Introduzione all’avvio ed allo spengimento del sistema
Il processo di boot più da vicino
Ancora sullo shutdown
Il reboot
Modalità utente singolo
Dischetti di avvio di emergenza
7. init
init prima di tutto
Configurazione di init per inizializzare le getty: il file /etc/inittab
I runlevel
Configurazioni speciali in /etc/inittab
Fare il boot in modalità utente singolo
8. Login e logout
Login via terminale
Login via rete
Cosa fa login
La shell
X e xdm
Il controllo degli accessi
9. La gestione degli account degli utenti
Che cos’è un account?
Come creare un utente
/etc/passwd ed altri file informativi
Gli identificativi numerici per gli utenti e i gruppi
Ambiente iniziale: /etc/skel
Creazione manuale di un utente
Modifica delle proprietà degli utenti
Rimozione di un utente
Disabilitazione temporanea di un utente
10. I backup
Sull’importanza delle copie di backup
La scelta del mezzo di backup
La scelta dello strumento di backup
Backup semplici
Fare backup con tar
Recuperare file con tar
Backup multilivello
Di cosa fare backup
Backup compressi
11. Tenere il tempo
I fusi orari
Gli orologi hardware e software
Impostazione e lettura dell’ora
Quando l’orologio si sbaglia
Glossario (BOZZA)
Bibliografia

 Disponibilità del sorgente e delle versioni preformattate
Potete trovare il codice sorgente ed altri formati leggibili da computer su Internet: sono disponibili in FTP anonimo sulla home page del Linux Documentation Project (http://metalab.unc.edu/LDP/) o sulla home page di questo libro a http://www.iki.fi/viu/linux/sag/, almeno in formato Postscript e TeX .DVI.
La versione italiana è disponibile in FTP anonimo dallo stesso Linux Documentation Project e sul sito del PLUTO: ftp://ftp.pluto.linux.it/pub/pluto/ildp/.
 Capitolo 1. Introduzione
“In principio, il file era informe e vuoto, e il vuoto era sulla faccia dei bit. E le Dita dell’Autore si mossero sulla faccia della tastiera. E l’Autore disse “Siano le parole!”, e le parole furono.”
Questo manuale, la Guida dell’amministratore di sistema di Linux, descrive appunto gli aspetti di amministrazione di sistema di Linux; è rivolto a chi non sa quasi niente di amministrazione di sistema (del tipo “ma che è?”), ma che già conosce almeno le basi dell’utilizzo comune. In questo manuale non viene spiegato come installare Linux: è compito dell’Installation and Getting Started [IGS]. Più avanti verranno date altre informazioni sui manuali di Linux disponibili.
L’amministrazione di sistema comprende tutto quello che bisogna fare per mantenere un sistema informatico in una forma utilizzabile; include cose come fare il backup dei file (e il restore, se è necessario), installare nuovi programmi, creare account per i nuovi utenti (e cancellarli quando non servono più), assicurarsi che il filesystem non sia corrotto e così via. Se un computer fosse, diciamo, una casa, l’amministrazione di sistema si chiamerebbe manutenzione, e comprenderebbe pulire, riparare le finestre rotte e altre cose del genere. L’amministrazione di sistema non si chiama manutenzione perché sarebbe troppo semplicistico[1].
La struttura di questo manuale è tale che molti dei capitoli possono essere letti indipendentemente l’uno dall’altro, quindi se vi servono delle informazioni diciamo sui backup, potete leggere solo quel capitolo. Si spera che questo renda il libro più facile da usare come riferimento ma contemporaneamente lasci la possibilità di leggerne solo una piccola parte quando serve, invece che essere costretti a studiare tutto. Comunque, questo manuale è per prima cosa un corso di amministrazione di sistemi, e un manuale di riferimento solo per una coincidenza fortuita.
Questo manuale non è inteso per essere usato completamente da solo. Gran parte dell’altra documentazione di Linux è importante per gli amministratori di sistema; dopotutto questi sono semplicemente utenti con privilegi e doveri speciali. Una risorsa molto importante sono le pagine man, che dovrebbero essere sempre consultate quando trovate un comando che non vi è familiare.
Anche se questo manuale è specifico su Linux, il principio generale seguito è che debba essere utile anche per altri sistemi operativi di tipo UNIX. Sfortunatamente, dato che c’è molta varietà tra le varie versioni di UNIX in generale, ed in particolare nell’amministrazione di sistema, c’è poca speranza di poter trattare tutte le varianti. Anche solo trattare tutte le versioni di Linux è difficile, per come si è sviluppato.
Non esiste una distribuzione di Linux ufficiale, quindi persone diverse hanno configurazioni diverse, e molti usano configurazioni personalizzate. Questo libro non è specifico su una distribuzione, anche se io uso quasi solamente la Debian GNU/Linux. Quando mi è stato possibile, ho tentato di evidenziare le differenze e di spiegare diverse alternative.
Ho provato a descrivere come funziona ciascuna cosa, piuttosto che elencare semplicemente “quattro facili lezioni” per ogni argomento. Ciò significa che il libro contiene molte informazioni che non sono indispensabili per tutti: queste parti sono però contrassegnate, e possono essere saltate se usate un sistema preconfigurato. Naturalmente leggere tutto aumenterà la vostra comprensione del sistema e vi dovrebbe rendere più gradevole amministrarlo.
Come tutto lo sviluppo che riguarda Linux, il mio lavoro è stato fatto su basi volontarie: l’ho fatto perché pensavo che sarebbe stato divertente, e perché credevo che fosse utile. Comunque, come per tutto il lavoro di volontari, c’è un limite al tempo che ci ho potuto spendere, e anche alla mia esperienza e conoscenza. Questo significa che il manuale non è necessariamente valido come sarebbe se fosse stato scritto da un guru pagato lautamente e che abbia avuto un paio d’anni per perfezionarlo. Naturalmente credo che sia piuttosto buono, ma ritenetevi avvisati.
Un caso particolare in cui ho un po’ tagliato è che non ho coperto in maniera estensiva molti argomenti già spiegati dettagliatamente in altri manuali disponibili gratuitamente, in particolare per la documentazione specifica dei programmi, come i dettagli dell’uso di mkfs. Io descrivo solo lo scopo del programma e quanto del suo uso è necessario per lo scopo del manuale; per altre informazioni, rimando il gentile lettore a questi altri documenti. Di solito, tutta la documentazione a cui mi riferisco fa parte della documentazione completa di Linux.
Lars ha tentato di rendere questo manuale migliore possibile, e a me, come attuale manutentore, piacerebbe veramente sapere da voi se avete qualche idea su come migliorarlo. Errori di linguaggio, di concetto, idee per nuovi argomenti da trattare, parti riscritte, informazioni su come si comportano le varie versioni di UNIX… mi interessa tutto. Le informazioni su come contattarmi sono disponibili via World Wide Web su http://www.iki.fi/viu/.
Molte persone mi hanno aiutato con questo libro, in maniera diretta o indiretta. Vorrei ringraziare specialmente Matt Welsh per avermi dato l’ispirazione ed aver guidato LDP, Andy Oram per avermi fatto tornare al lavoro dopo aver ricevuto tanto prezioso feedback, Olaf Kirk per avermi dimostrato che era possibile, e Adam Richter della Yggdrasil ed altri per avermi dimostrato che anche altre persone possono trovarlo interessante.
Stephen Tweedie, H. Peter Anvin, Rémy Card, Theodore T’so, e Stephen Tweedie mi hanno permesso di prendere in prestito il loro lavoro (e quindi far sembrare il libro più grosso e molto più imponente): un paragone tra i filesystem xia ed ext2, l’elenco dei dispositivi ed una descrizione del filesystem ext2; non fanno più parte del libro. Gliene sono molto grato, e mi scuso per le versioni precedenti in cui mancava un riferimento preciso.
Oltre a questi vorrei ringraziare Mark Komarinski per avermi mandato il suo materiale nel 1993, e tutti gli articoli sull’amministrazione di sistema del Linux Journal. Sono molto utili e fonte di grande ispirazione.
Moltissime persone mi hanno mandato dei commenti utili. Il piccolo buco nero che ho per archivio non mi consente di ritrovare tutti i loro nomi, ma alcuni di questi sono, in ordine alfabetico: Paul Caprioli, Ales Cepek, Marie-France Declerfayt, Dave Dobson, Olaf Flebbe, Helmut Geyer, Larry Greenfield e suo padre, Stephen Harris, Jyrki Havia, Jim Haynes, York Lam, Timothy Andrew Lister, Jim Lynch, Michael J. Micek, Jacob Navia, Dan Poirier, Daniel Quinlan, Jouni K Seppänen, Philippe Steindl, G.B. Stotte. Le mie scuse a quelli che ho dimenticato.
 Il Linux Documentation Project
Il Linux Documentation Project, o LDP, è un gruppo libero di autori, correttori di bozze e curatori che lavorano insieme per fornire una documentazione completa del sistema operativo Linux. Il coordinatore generale del progetto è Greg Hankins.
Questo manuale fa parte di una collana distribuita dall’LDP, che comprende la Guida dell’Utente (Linux Users’ Guide) [UG], la Guida dell’Amministratore di Sistema (System Administrators’ Guide) [SAG], la Guida dell’Amministratore di Rete (Network Administrators’ Guide) [NAG] e la Guida del Kernel (Kernel Hackers’ Guide) [KHG]. Questi manuali sono tutti disponibili in formato sorgente, .dvi e postscript in FTP anonimo su metalab.unc.edu nella directory /pub/Linux/docs/LDP.
Incoraggiamo chiunque abbia propensione per la scrittura o l’editoria ad aggiungersi a noi per migliorare la documentazione di Linux. Se avete accesso e-mail ad Internet, potete contattare Greg Hankins a <gregh@sunsite.unc.edu>.
(N.d.T. Per quanto riguarda la traduzione in italiano, trovate le guide LDP nella sottodirectory translations/it delle directory di ciascuna guida inglese. Per collaborare alla traduzione di altre guide, o per eventuali correzioni di questa, contattate me, all’email <eugenia@pluto.linux.it>)
 Note
[1]
Ci sono persone che la chiamano così, ma solo perché non hanno mai letto questo manuale, poverini.

 Capitolo 2. Panoramica di un sistema Linux
Sommario
Le componenti di un sistema operativo
Le parti principali del kernel
I principali servizi in un sistema UNIX
“E Dio guardò quello che aveva fatto, e vide che era cosa buona. ” (Genesi 1:31)
Questo capitolo dà una panoramica di un sistema Linux: per prima cosa verranno descritti i principali servizi forniti, poi, senza scendere nei dettagli, i programmi che implementano tali servizi. Lo scopo di questo capitolo è dare delle nozioni sul sistema in generale, le singole componenti sono descritte in altre parti della guida.
 
 Le componenti di un sistema operativo
Un sistema operativo UNIX è formato da un kernel e da programmi di sistema, oltre ad applicazioni con cui si fa il vero lavoro. Il kernel è il cuore del sistema operativo[1]: tiene traccia dei file sul disco, avvia i programmi e li fa girare contemporaneamente, assegna la memoria ed altre risorse ai vari processi, scambia i pacchetti con la rete e così via. Il kernel fa pochissime cose da solo, ma fornisce gli strumenti con cui si possono costruire tutti i servizi; evita anche che chiunque acceda all’hardware direttamente, forzando tutti a utilizzare gli strumenti che fornisce: in questo modo protegge gli utenti l’uno dall’altro. Gli strumenti forniti dal kernel vengono usati attraverso chiamate di sistema: consultate le pagine man della sezione 2 per ulteriori informazioni su questo argomento.
I programmi di sistema usano gli strumenti forniti dal kernel per implementare i vari servizi propri di un sistema operativo. I programmi di sistema, come tutti gli altri programmi, girano `sopra al kernel’, in quella che viene chiamata modalità utente (user mode). La differenza tra i programmi di sistema e gli applicativi è lo scopo: le applicazioni sono concepite per fare delle cose utili (o per giocare, se si tratta di un gioco), mentre i programmi di sistema servono per fare funzionare il sistema stesso. Un word processor è un’applicazione, telnet è un programma di sistema. La differenza è comunque spesso non ben definita, ed è importante solo per chi è abituato a dividere tutto in categorie.
Un sistema operativo può anche contenere dei compilatori e le corrispondenti librerie (sotto Linux in particolare GCC e la libreria C), anche se non c’è bisogno che tutti i linguaggi di programmazione ne siano parte integrante. Ne possono fare parte anche la documentazione, e qualche volta anche dei giochi. Tradizionalmente, il sistema operativo è stato definito come il contenuto del nastro o dei dischi di installazione; con Linux non è così chiaro, perché è sparso su tutti i siti FTP del mondo.
 Note
[1]
In effetti viene spesso in modo errato considerato il sistema operativo stesso, ma non lo è: un sistema operativo fornisce molti più servizi di un semplice kernel.

 

 

 Le parti principali del kernel
Il kernel di Linux consiste di diverse parti importanti: la gestione dei processi, la gestione della memoria, i driver per i dispositivi hardware, quelli per i filesystem, la gestione della rete ed altre parti minori. In Figura 2-1 ne sono mostrati alcuni.
Figura 2-1. Alcune delle parti più importanti del kernel di Linux

Probabilmente le parti più importanti del kernel (nient’altro funziona senza di esse) sono la gestione della memoria e dei processi. La gestione della memoria si occupa di assegnare le aree di memoria e di spazio di swap ai processi, a parti del kernel e per la cache di buffer. La gestione dei processi crea i processi ed implementa il multitasking cambiando il processo attivo sul processore.
Al livello più basso, il kernel contiene un driver per ciascun dispositivo hardware che supporta. Dato che il mondo è pieno di tipi diversi di hardware il numero dei driver è enorme. Ci sono spesso molti componenti hardware simili che differiscono solo in come vengono controllati dal software; queste similitudini rendono possibile avere delle classi generali di driver che supportano operazioni simili: ogni membro della classe ha la stessa interfaccia con il resto del kernel, ma si distingue in quello che serve per implementarlo. Ad esempio, tutti i driver dei dischi sembrano uguali dal punto di vista del resto del kernel, cioè hanno tutti operazioni come `inizializza il driver’, `leggi il settore N’ e `scrivi il settore N’.
Alcuni dei servizi software forniti dal kernel stesso hanno proprietà simili e possono dunque essere astratti in classi. Ad esempio, i vari protocolli di rete sono stati astratti in un’interfaccia di programmazione, la BSD socket library. Un altro esempio è il livello filesystem virtuale (VFS), che astrae le operazioni su filesystem senza considerare la loro implementazione. Ciascun tipo di filesystem fornisce un’implementazione di ogni operazione; quando un’entità prova ad usare un filesystem, la richiesta passa per il VFS che la gira al driver opportuno.

 I principali servizi in un sistema UNIX
Questa sezione descrive alcuni dei servizi di UNIX più importanti, ma senza scendere molto nei dettagli; verranno descritti più accuratamente nei capitoli successivi.
 init
Il servizio più importante di un sistema UNIX è fornito da init. init viene inizializzato come primo processo su ciascun sistema UNIX ed è l’ultima cosa che il kernel fa all’avvio. Quando parte, init continua il processo di avvio portando avanti vari compiti (controlla e monta i filesystem, avvia i daemon ecc.).
L’elenco esatto delle cose che init fa dipende dal suo tipo: ce ne sono diversi tra cui scegliere. init di solito fornisce il concetto di modalità a singolo utente, in cui nessuno si può collegare e root usa una shell alla console; la modalità usuale viene chiamata modalità multiutente. Alcuni tipi generalizzano questo concetto in runlevel; le modalità utente singolo e multiutente sono considerate due runlevel, e ce ne possono essere altri, ad esempio, per far girare X sulla console.
Nelle normali operazioni, init si assicura che stia girando getty (per poter far collegare gli utenti), e adotta i processi orfani (quelli il cui padre è morto: in UNIX tutti i processi devono essere in un singolo albero, quindi gli orfani devono venire adottati).
Quando il sistema viene spento, è init che deve uccidere tutti gli altri processi, smontare i filesystem e fermare il processore, oltre agli altri compiti per cui è stato configurato.
 Login dai terminali
I login dai terminali (attraverso linee seriali) e dalla console (quando non si sta usando X) vengono forniti dal programma getty. init avvia una getty separata per ogni terminale da cui sono consentiti i login, getty legge il nome dell’utente ed avvia il programma login, che legge la password; se questa corrisponde al nome utente, login avvia la shell. Quando questa termina, cioè l’utente si scollega, o quando login termina perché il nome dell’utente e la password non corrispondono, init lo nota ed avvia un’altra copia di getty. Il kernel non ha nozione dei login, che vengono tutti gestiti dai programmi di sistema.
 Syslog
Il kernel e molti programmi di sistema producono messaggi di errore, di avvertimento e di altro tipo. Spesso è importante che questi messaggi possano essere letti in un secondo tempo, anche dopo parecchio, quindi devono essere scritti in un file. Il programma che lo fa è syslog, che può essere configurato per distribuire i messaggi in file diversi a seconda di chi li genera o del loro grado di importanza; ad esempio quelli del kernel sono spesso rediretti in un file separato dagli altri, dato che spesso sono più importanti e devono essere letti regolarmente per individuare gli eventuali problemi.
 Esecuzione periodica dei comandi: cron e at
Sia gli utenti che gli amministratori di sistema hanno spesso bisogno di avviare periodicamente dei programmi, ad esempio l’amministratore di sistema potrebbe voler avviarne uno che ripulisca le directory che contengono file temporanei (/tmp e /var/tmp) dai file vecchi, per evitare che i dischi si riempiano, dato che non tutti i programmi cancellano correttamente i file generati.
Il servizio di cron funziona proprio per questo. Ciascun utente ha un file crontab, dove elenca i comandi che vuole eseguire ed il momento in cui farlo; il daemon cron avvia poi i comandi scelti al momento specificato.
Il servizio di at è simile a cron, ma vale per una sola volta: il comando viene eseguito al momento indicato, ma non viene ripetuto.
 GUI – interfaccia grafica utente
UNIX e Linux non hanno incorporata l’interfaccia nel kernel, ma la fanno implementare da programmi a livello utente, sia per l’ambiente testuale che per quello grafico.
Questa soluzione rende il sistema più flessibile, ma ha lo svantaggio che è facile implementare un’interfaccia diversa per ciascun programma, rendendo il sistema più difficile da imparare.
L’ambiente grafico usato principalmente con Linux si chiama Sistema X Window (in breve, X). X stesso non implementa un’interfaccia utente, ma solo un sistema di finestre, cioè degli strumenti con cui poterne implementare una. I tre stili più conosciuti in X sono Athena, Motif e Open Look.
 Le reti
Una rete è un mezzo per connettere due o più computer in modo che possano comunicare tra di loro. I metodi usati di connessione e comunicazione sono piuttosto complessi, ma il risultato finale è molto utile.
I sistemi operativi UNIX hanno molte capacità di connessione in rete. La maggior parte dei servizi di base (i filesystem, la stampa, i backup ecc.) possono essere usati attraverso la rete; questo può rendere l’amministrazione di sistema più semplice, dato che permette di centralizzare i compiti amministrativi, sfruttando nel contempo i lati positivi dei microcomputer e dell’informatica distribuita, come i costi minori e una più alta tolleranza degli errori.
Questo libro, comunque, dà solo un accenno sulle reti; per ulteriori informazioni c’è la Guida dell’amministratore di rete di Linux (Linux Network Administrators’ Guide [NAG]), che comprende anche una descrizione di base del funzionamento delle reti stesse.
 Login in rete
I login in rete funzionano in modo leggermente diverso da quelli normali: in questi ultimi infatti c’è una linea seriale fisica separata per ciascun terminale attraverso cui ci si collega, mentre per ciascuna persona che si collega via rete c’è una connessione virtuale separata, e ce ne possono essere infinite[1]. Non è quindi possibile avviare una getty separata per ciascuna connessione virtuale possibile. Ci sono poi diversi modi per collegarsi attraverso una rete: i principali nelle reti di tipo TCP/IP sono telnet e rlogin.
I login di rete hanno, invece di un insieme di getty, un daemon singolo per ciascun modo di collegamento (telnet e rlogin hanno daemon separati) che sta in ascolto per i tentativi di login in ingresso. Quando ne nota uno, inizializza una copia di se stesso per gestire quel singolo tentativo; l’istanza originale continua ad aspettarne altri. La nuova istanza funziona in modo simile a getty.
 Filesystem condivisi
Una delle cose più utili che si possono fare con i servizi di rete è la condivisione di file attraverso un filesystem di rete. Quello che viene usato di solito si chiama Network File System, o NFS, ed è sviluppato dalla SUN.
Con un filesystem condiviso qualsiasi operazione su file fatta da un programma su una macchina viene spedita attraverso la rete ad un altro computer. In questo modo si inganna il programma e gli fa pensare che tutti i file sull’altro computer siano in realtà sul computer su cui sta girando, il che rende molto semplice la condivisione di informazioni, non richiedendo modifiche ai programmi.
 La posta elettronica
La posta elettronica è di solito il metodo più importante per comunicare usando il computer. Un messaggio di posta elettronica viene immagazzinato in un file in un formato speciale e per inviare e leggere i messaggi vengono usati dei programmi appositi.
Ciascun utente ha una casella di posta in arrivo (un file nel formato speciale) dove viene immagazzinata tutta la nuova posta in ingresso. Quando qualcuno spedisce un messaggio, il programma di posta ritrova la casella del destinatario e lo aggiunge al file. Se la casella di posta del destinatario si trova su un altro computer il messaggio viene inviato a quella macchina, che lo aggiunge alla casella nel modo che ritiene migliore.
Il sistema di posta consiste di molti programmi: la distribuzione a caselle locali o remote viene fatta dall’agente di trasferimento di posta (mail transfer agent o MTA), cioè sendmail o smail, mentre i programmi utilizzati dagli utenti sono molti e vari (gli agenti di posta utente, mail user agent o MUA, come ad esempio pine o elm). Le caselle di posta vengono in genere tenute in /var/spool/mail.
 La stampa
Solo una persona alla volta può usare una stampante, ma è poco economico non condividerla tra vari utenti. La stampante viene quindi gestita da un software che implementa una coda di stampa: tutti i job di stampa vengono messi in una coda e quando la stampante ne ha finito uno gliene viene mandato un altro automaticamente. Questo solleva gli utenti dall’organizzazione della coda di stampa e dal litigare per il controllo della stampante[2].
Il software di stampa fa anche lo spool delle stampe sul disco, cioè il testo viene mantenuto in un file finché il job è in coda. Ciò permette ad un programma applicativo di inviare velocemente i job di stampa al software di coda; l’applicazione non deve così aspettare finché il job è realmente stato stampato per poter continuare. È veramente conveniente, dato che permette di stampare una versione di un file e non dover aspettare che abbia finito per farne una nuova completamente diversa.
 La struttura del filesystem
Il filesystem è diviso in molte parti: di solito in un filesystem radice, con /bin, /lib, /etc e /dev che formano un singolo filesystem, /usr con i programmi ed i dati che non vengono modificati, /var con quelli che vengono modificati (come i file di log), ed /home con i file personali dei vari utenti. A seconda della configurazione dell’hardware e delle decisioni dell’amministratore di sistema la divisione può cambiare, e potrebbe esserci anche un unico filesystem che comprende tutto.
Il Capitolo 3 descrive la struttura del filesystem abbastanza approfonditamente: il Linux Filesystem Standard [LFS] lo fa in maniera ancora più dettagliata.
 Note
[1]
Beh, almeno ce ne possono essere parecchie. La larghezza di banda della rete è ancora una risorsa piuttosto scarsa, c’è ancora una limitazione pratica al numero di login contemporanei su una singola connessione di rete.
[2]
Invece formano una nuova coda alla stampante, aspettando le stampe, dato che nessuno sembra mai capace di far sapere esattamente al software di coda quando i vari job sono veramente finiti: un gran passo avanti per le relazioni sociali inter-ufficio.

 Capitolo 3. L’albero delle directory

Questo capitolo descrive le parti più importanti di un albero delle directory standard di Linux, basato sullo standard FSSTND per i filesystem; descrive come esso viene normalmente diviso in filesystem separati con scopi diversi, e spiega le motivazioni che stanno dietro questo modo di fare. Vengono descritti anche altri tipi di suddivisione.
 Premesse
Questo capitolo è basato sullo standard dei filesystem Linux, FSSTND, versione 1.2 [LFS], che tenta di impostare uno standard per l’organizzazione dell’albero delle directory nei sistemi Linux. Uno standard del genere ha il vantaggio che è più facile scrivere o fare porting del software per Linux e amministrare le macchine Linux, dato che tutto si trova nel posto designato. Non c’è nessuna autorità che impone di uniformarsi allo standard, ma questo ha il supporto della maggior parte, se non di tutte, le distribuzioni Linux, quindi non è una buona idea discostarsi da esso se non per ragioni molto particolari. Il FSSTND tenta di seguire la tradizione Unix e le tendenze più recenti, rendendo i sistemi Linux familiari per chi ha esperienza con altri sistemi Unix e viceversa.
Questo capitolo non è dettagliato come il FSSTND, e gli amministratori di sistema dovrebbero leggere anche quello per avere una comprensione completa dell’argomento; inoltre non descrive tutti i file in dettaglio: lo scopo infatti è quello di dare una visione del sistema dal punto di vista del filesystem. Ulteriori informazioni sui singoli file possono essere trovate in altre parti di questo libro o nelle pagine man.
L’albero delle directory completo è concepito in modo che possa essere diviso in parti più piccole, ciascuna sulla sua partizione o nel suo disco, per ottimizzare le cose in dipendenza dalla dimensione dei dischi stessi e per rendere più semplice il backup ed il resto dell’amministrazione. Le parti principali sono i filesystem radice, /usr, /var e /home (vedere la Figura 3-1), e ciascuna ha uno scopo diverso. L’albero delle directory è stato strutturato in modo che funzioni bene in una rete di macchine Linux che condividano delle parti del filesystem su un dispositivo a sola lettura (ad esempio un CD-ROM), o sulla rete con NFS.

 

Figura 3-1. Parti di un albero delle directory Unix. Le linee tratteggiate indicano i limiti delle partizioni.
 
Descriviamo ora i ruoli delle diverse parti dell’albero delle directory.
• Il filesystem radice è specifico per ciascuna macchina (generalmente viene immagazzinato su un disco locale, anche se può trattarsi di un disco RAM o di uno in rete) e contiene i file necessari per avviare il sistema e per portarlo ad uno stato tale da poter montare gli altri filesystem. Il contenuto del filesystem radice sarà quindi sufficiente per la modalità a singolo utente; conterrà inoltre gli strumenti per recuperare un filesystem danneggiato o copiare dai backup i file perduti.
• Il filesystem /usr contiene tutti i comandi, le librerie, le pagine man e altri file che non vengono modificati durante le normali operazioni. Nessun file in /usr dovrebbe essere specifico per nessuna macchina data, né dovrebbe essere modificato durante il normale uso. Questo permette di condividere i file in rete, risparmiando spazio disco (/usr può arrivare facilmente a centinaia di megabyte) e rendendo l’amministrazione molto più semplice (basta modificare solo l’/usr principale quando si aggiorna un’applicazione, e non c’è bisogno di farlo separatamente su ciascuna macchina). Anche se il filesystem si trova su un disco locale, può essere montato con accesso a sola lettura, per diminuire le possibilità di corruzione durante un crash.
• Il filesystem /var contiene file che vengono modificati, come le directory di spool (per la posta, le news, le stampanti eccetera), i file di log, le pagine man formattate ed i file temporanei. Tradizionalmente tutto quello che si trova in /var si trovava in qualche posto sotto /usr, ma questo rendeva impossibile montare /usr a sola lettura.
• Il filesystem /home contiene le home directory degli utenti, cioè tutti i veri dati sul sistema. Separare le home directory su un albero o su un filesystem a parte rende molto più semplici i backup: le altre parti in genere non ne hanno bisogno, o almeno non frequentemente (cambiano poco nel tempo). Una /home grande potrebbe dover essere separata in vari filesystem, aggiungendo dei sottolivelli, ad esempio /home/students e /home/staff.
Anche se le diverse parti sono state chiamate fino ad ora filesystem, non è richiesto che si trovino realmente su filesystem diversi; possono essere tenute sullo stesso se il sistema è piccolo e monoutente e si vogliono mantenere le cose semplici. L’albero delle directory può essere diviso in filesystem in modo diverso da quanto spiegato, a seconda di quanto sono grandi i dischi e di come lo spazio è allocato per i vari scopi. La parte importante, piuttosto, è che tutti i nomi importanti funzionino: anche se, ad esempio, /var e /usr sono in realtà sulla stessa partizione, i nomi /usr/lib/libc.a e /var/adm/messages devono funzionare; si possono ad esempio spostare i file sotto /var in /usr/var, e rendere /var un link simbolico a /usr/var.
La struttura dei filesystem Unix raggruppa i file a seconda del loro scopo, cioè tutti i comandi si trovano nello stesso posto, tutti i file di dati in un altro, la documentazione in un terzo e così via. Un’alternativa sarebbe raggruppare i file a seconda del programma a cui appartengono, cioè tutti i file di Emacs in una stessa directory, tutti quelli di TeX in un altra, eccetera. Il problema di quest’ultimo approccio è che rende difficile condividere i file (le directory dei programmi spesso contengono sia file statici che condivisibili, e sia file che cambiano che file che restano invariati) e spesso anche trovare dei file (ad esempio, le pagine man sarebbero in un numero enorme di posti e fare in modo che i programmi di lettura le possano trovare è l’incubo degli amministratori di sistema).

 La radice del filesystem
Il filesystem radice dovrebbe generalmente essere piccolo, dato che contiene file estremamente critici e un filesystem piccolo che viene modificato poco ha migliori possibilità di non venire corrotto. Un filesystem radice corrotto in genere significa che diventa impossibile avviare il sistema tranne che con misure eccezionali (ad esempio da un floppy), quindi è meglio non rischiare.
La directory principale in genere non contiene nessun file, tranne a volte l’immagine standard di avvio per il sistema, che di solito si chiama /vmlinuz. Tutti gli altri file sono in sue sottodirectory:
/bin
Comandi necessari durante l’avvio del sistema che devono essere usati dagli utenti normali (in genere dopo l’avvio).
/sbin
Come /bin, ma i comandi non sono intesi per gli utenti normali, anche se questi li possono usare se necessario e se hanno i permessi.
/etc
File di configurazione specifici della macchina.
/root
La home directory dell’utente root.
/lib
Le librerie condivise necessarie ai programmi sul filesystem radice.
/lib/modules
I moduli caricabili del kernel, specialmente quelli che sono necessari per avviare il sistema quando lo si sta recuperando da un disastro (ad esempio i driver di rete e dei filesystem).
/dev
I file di device.
/tmp
I file temporanei. I programmi che vengono avviati dopo il boot dovrebbero usare /var/tmp, non /tmp, dato che il primo si trova probabilmente in un disco con più spazio.
/boot
I file usati dal bootstrap loader, cioè LILO. Le immagini del kernel spesso vengono tenute qui invece che nella directory principale. Se ce ne è più di una, la directory può facilmente crescere parecchio, e spesso può essere meglio tenerla in un filesystem separato, anche per assicurarsi che le immagini del kernel siano comprese nei primi 1024 cilindri di un disco IDE.
/mnt
Il punto di mount dove l’amministratore di sistema possa montare temporaneamente delle directory. I programmi non dovrebbero montarsi su /mnt automaticamente. /mnt può essere diviso in sottodirectory (ad esempio /mnt/dosa può essere il floppy che usa un filesystem MS-DOS, e /mnt/exta lo stesso con un filesystem ext2).
/proc, /usr, /var, /home
Punti di mount per gli altri filesystem.

 La directory /etc
La directory /etc contiene moltissimi file: alcuni di essi sono descritti qui sotto, per gli altri dovreste determinare a quale programma appartengono e leggere la pagina man corrispondente. Anche molti file di configurazione per la rete si trovano in /etc, e sono descritti nella Guida dell’amministratore di rete.
/etc/rc o /etc/rc.d o /etc/rc?.d
Script o directory di script da eseguire all’avvio o quando si cambia il runlevel. Vedere la sezione su init per altre informazioni.
/etc/passwd
Il database degli utenti, con dei campi che danno il nome dell’utente, il vero nome, la home directory, la password criptata ed altre informazioni su ciascun utente. Il formato è documentato nella pagina man di passwd .
/etc/fdprm
La tabella dei parametri dei floppy disk. Descrive le caratteristiche di diversi formati di floppy e viene usata da setfdprm; vedere la pagina man di quest’ultimo per altre informazioni.
/etc/fstab
Elenca i filesystem montati automaticamente all’avvio dal comando mount -a (in /etc/rc o in un file di avvio equivalente). Sotto Linux contiene anche delle informazioni sulle aree di swap usate automaticamente da swapon -a. Vedere la sezione Montare e smontare un filesystem nel Capitolo 4 e la pagina man di mount per ulteriori informazioni.
/etc/group
Simile a /etc/passwd, ma descrive i gruppi anziché gli utenti. Vedere la pagina man di group per altre informazioni.
/etc/inittab
File di configurazione di init.
/etc/issue
L’output di getty prima del prompt di login. Di solito contiene una breve descrizione del sistema o un messaggio di benvenuto, la scelta del quale è lasciata all’amministratore di sistema.
/etc/magic
Il file di configurazione di file; contiene la descrizione di vari formati di file, basandosi sui quali file indovina il tipo di file. Vedere la pagina man di magic e file per altre informazioni.
/etc/motd
Il messaggio del giorno, visualizzato subito dopo ogni login riuscito. Il contenuto è a scelta dell’amministratore di sistema, e spesso viene usato per dare delle informazioni agli utenti, come ad esempio l’avviso degli orari di spengimento del sistema.
/etc/mtab
Elenco dei filesystem montati al momento; viene impostato inizialmente dagli script di avvio, aggiornato automaticamente dal comando mount, ed usato quando c’è bisogno di un elenco dei filesystem montati, come per il comando df.
/etc/shadow
Il file delle shadow password sui sistemi in cui sono installate. Le shadow password spostano le password criptate da /etc/passwd a /etc/shadow; quest’ultimo non è leggibile da nessuno tranne root, così è più difficile craccare le password.
/etc/login.defs
File di configurazione del comando login.
/etc/printcap
Come /etc/termcap, ma per le stampanti; ha una sintassi diversa.
/etc/profile, /etc/csh.login, /etc/csh.cshrc
File eseguiti al login o all’avvio dalle shell di tipo Bourne o C, permettono all’amministratore di sistema di impostare dei valori di default globali per tutti gli utenti. Vedere le pagine man per le rispettive shell.
/etc/securetty
Identifica i terminali sicuri, cioè quelli da cui root può accedere al sistema. Tipicamente vengono elencate solo le console virtuali, in modo che sia impossibile (o almeno più difficile) acquistare i privilegi di superutente craccando un sistema da un modem o dalla rete.
/etc/shells
Elenca le shell considerate sicure. Il comando chsh permette agli utenti di cambiare la loro shell di login solo con le shell elencate in questo file. ftpd, il processo server che dà i servizi FTP per la macchina controllerà che la shell dell’utente sia elencata in /etc/shells e non permetterà di collegarsi a chi usa una shell non in elenco.
/etc/termcap
Il database dei terminali, descrive con quali “sequenze di escape” si controllano i vari terminali. I programmi vengono scritti in modo che invece di mandare in output una sequenza di escape che funzioni solo su una particolare marca di terminali, cercano la sequenza corretta per fare quello che vogliono fare in /etc/termcap. Come risultato la maggior parte dei programmi funzionano con quasi tutti i tipi di terminali. Vedere le pagine man di termcap, curs_termcap e terminfo per altre informazioni.
 La directory /dev
La directory /dev contiene degli speciali file di device per i vari dispositivi. I file di device vengono chiamati usando delle convenzioni speciali, che sono descritte nell’elenco dei dispositivi (Device list, vedi [DEVICE-LIST]). I file di device vengono creati durante l’installazione, ma lo si può fare anche in seguito usando lo script /dev/MAKEDEV. /dev/MAKEDEV.local è uno script scritto dall’amministratore di sistema che crea file di device o collegamenti solo locali (cioè quelli che non fanno parte dello standard MAKEDEV, come i file di device per i driver di alcuni dispositivi non standard).

 Il filesystem /usr
Il filesystem /usr è spesso grande, dato che vi sono installati tutti i programmi. Tutti i file in /usr vengono di solito da una distribuzione di Linux; i programmi installati in locale e il resto vanno sotto /usr/local: in questo modo è possibile aggiornare il sistema a una nuova versione della distribuzione, o addirittura ad una distribuzione completamente nuova, senza dover reinstallare tutti i programmi da capo. Alcune delle sottodirectory di /usr sono elencate qui sotto (alcune di quelle meno importanti sono state saltate, vedere il FSSTND [LFS] per altre informazioni).
/usr/X11R6
Il sistema X Window, tutti i suoi file. Per semplificare lo sviluppo e l’installazione di X, i suoi file non sono stati integrati nel resto del sistema, ma c’è un albero di directory sotto /usr/X11R6 simile a quello sotto /usr stesso.
/usr/X386
Simile a /usr/X11R6, ma per X11 Release 5.
/usr/bin
Quasi tutti i comandi utente. Alcuni sono in /bin o in /usr/local/bin.
/usr/sbin
I comandi di amministrazione di sistema che non sono necessari sotto il filesystem radice, come la maggior parte dei programmi di server.
/usr/man, /usr/info, /usr/doc
Rispettivamente le pagine man, la documentazione info della GNU ed altri file di documentazione.
/usr/include
File di header per il linguaggio di programmazione C. Per essere consistenti con il resto del filesystem si sarebbero dovuti trovare in /usr/lib ma la tradizione è del tutto in favore di questo nome.
/usr/lib
File di dati che non vengono modificati per i programmi ed i sottosistemi, tra cui anche alcuni file di configurazione validi per tutto il sistema. Il nome lib viene da libreria: originariamente in /usr/lib erano memorizzate le librerie delle subroutine di programmazione.
/usr/local
Il posto per il software installato in locale e per gli altri file.
 Il filesystem /var
/var contiene i dati che vengono modificati quando il sistema lavora normalmente. è specifico per ciascun sistema, cioè non viene condiviso in rete con altri computer.
/var/catman
Una cache per le pagine man che vengono formattate a richiesta. I sorgenti delle pagine man vengono di solito immagazzinati in /usr/man/man*; alcune hanno una versione preformattata, che si trova in /usr/man/cat*, altre devono essere formattate la prima volta che vengono visualizzate; la versione formattata viene posta in /var/man in modo che chi le volesse visualizzare di nuovo non debba ripetere l’operazione (/var/catman viene ripulita spesso nello stesso modo delle directory temporanee).
/var/lib
I file che vengono modificati mentre il sistema viene normalmente usato.
/var/local
I dati variabili per i programmi che vengono installati in /usr/local (cioè quelli che sono stati installati dall’amministratore di sistema). Notate che anche i programmi installati in locale dovrebbero usare le altre directory /var se sono appropriate, ad esempio /var/lock.
/var/lock
File di lock. Molti programmi seguono una convenzione per creare dei file di lock in /var/lock per indicare che stanno usando un particolare dispositivo o file; altri programmi noteranno il lock e non accetteranno di usare il dispositivo o il file in questione.
/var/log
I file di log di vari programmi, specialmente di login (/var/log/wtmp, dove vengono memorizzati tutti i login e i logout del sistema) e di syslog (/var/log/messages, dove vengono immagazzinati tutti i messaggi del kernel e dei programmi di sistema). I file in /var/log possono spesso crescere indefinitamente, e possono richiedere che la directory venga ripulita ad intervalli regolari.
/var/run
File che contengono informazioni sul sistema valide fino al successivo reboot. Ad esempio, /var/run/utmp contiene informazioni sugli utenti collegati in quel momento.
/var/spool
Directory per le mail, le news, le code di stampa ed altre code. Ciascuno spool diverso ha la sua sottodirectory sotto /var/spool, ad esempio le caselle di posta degli utenti sono in /var/spool/mail.
/var/tmp
File temporanei troppo grandi o che devono esistere per un tempo più lungo di quello permesso per /tmp (anche se l’amministratore di sistema può non permettere file molto vecchi neanche in /var/tmp).
 Il filesystem /proc
Il filesystem /proc contiene un filesystem virtuale: non esiste sul disco, ma viene creato nella memoria dal kernel. Viene usato per fornire informazioni sul sistema (originariamente lo faceva sui processi, da cui il suo nome). Alcuni dei file e delle directory più importanti in esso contenute sono descritte qui sotto; maggiori dettagli si possono trovare nella pagina man di proc.
/proc/1
Una directory con le informazioni sul processo numero 1. Ciascun processo ha una directory sotto /proc indicata dal numero di identificazione del processo.
/proc/cpuinfo
Informazioni sul processore, come il tipo, la marca, il modello e la performance.
/proc/devices
Un elenco dei device driver configurati nel kernel in uso.
/proc/dma
I canali DMA usati al momento.
/proc/filesystems
I filesystem configurati nel kernel.
/proc/interrupts
Gli interrupt in uso e quanti ne sono stati chiamati di ciascuno.
/proc/ioports
Le porte di I/O in uso al momento.
/proc/kcore
Un’immagine della memoria fisica del sistema, della stessa dimensione di quest’ultima; non occupa così tanto spazio, ma viene generata in tempo reale quando i programmi vi accedono (ricordate: a meno che non lo copiate da qualche altra parte, nessun file sotto /proc occupa spazio disco).
/proc/kmsg
Messaggi di output del kernel. Vengono mandati anche a syslog.
/proc/ksyms
La tabella dei simboli per il kernel.
/proc/loadavg
La media del carico (load average) del sistema: tre indicatori senza significato di quanto lavoro deve fare il sistema in ciascun momento.
/proc/meminfo
Informazioni sull’uso della memoria, sia fisica che di swap.
/proc/modules
Quali moduli del kernel sono caricati al momento.
/proc/net
Informazioni di stato sui protocolli di rete.
/proc/self
Un link simbolico alla directory dei processi del programma che sta guardando in /proc. Quando due processi guardano in /proc, ottengono link diversi. Serve più che altro per facilitare ai programmi il raggiungimento della loro directory dei processi.
/proc/stat
Varie statistiche sul sistema, come il numero di page fault da quando è stato avviato.
/proc/uptime
Il tempo per cui il sistema è stato attivo.
/proc/version
La versione del kernel.
Notate che mentre i file descritti qui sopra tendono ad essere file di testo leggibili facilmente, altri possono essere formattati in modo da non essere facilmente digeribili. Ci sono molti comandi che fanno poco più che leggere questi ultimi e formattarli in modo da poterli capire meglio. Ad esempio, il programma free legge /proc/meminfo e converte le quantità date in byte a kilobyte (aggiungendo anche altre informazioni).

 Capitolo 4. Uso dei dischi e di altre memorie di massa
Quando si installa o si aggiorna un sistema, si lavora molto sui dischi: bisogna crearvi dei filesystem in modo da poterci memorizzare dei file e riservare spazio per le varie parti del sistema.
Questo capitolo spiega tutte queste attività iniziali. Di solito, una volta impostato il sistema, non dovrete ripetere queste operazioni, tranne che per i floppy: dovrete ritornare a questo capitolo per aggiungere un nuovo disco o per rifinire l’utilizzo di quelli che avete.
I compiti di base nell’amministrazione dei dischi sono:
• La formattazione, che fa diverse cose per preparare il disco all’uso, come controllare se ci sono settori danneggiati (oggigiorno non è necessario formattare la maggior parte degli hard disk).
• Il partizionamento, se volete usare il disco per attività diverse che non devono interferire l’una con l’altra. Dovete ripartizionare se volete usare diversi sistemi operativi sullo stesso disco, o se volete tenere i file degli utenti separati da quelli di sistema, cosa che aiuta a proteggere questi ultimi e semplifica i backup.
• La creazione di un filesystem (di tipo adatto) su ciascun disco o partizione. I dischi non risultano a Linux finché non ci create un filesystem: a quel punto potete memorizzarci file ed accedere a quelli presenti.
• Il montaggio (mount) di diversi filesystem per formare una singola struttura ad albero, sia automaticamente che manualmente, a seconda delle circostanze (dovete smontare a mano i filesystem montati manualmente).
Il Capitolo 5 contiene informazioni sulla memoria virtuale e sulla cache del disco, di cui dovete essere coscienti quando usate i dischi.
 Due tipi di dispositivi
UNIX, e quindi Linux, riconosce due tipi diversi di dispositivi: quelli a blocchi ad accesso casuale (come i dischi) e quelli a carattere (come i nastri e le linee seriali), alcuni dei quali sono seriali, altri ad accesso casuale. Ogni dispositivo supportato viene rappresentato nel filesystem come un file di device. Quando si legge o si scrive un file di device, i dati provengono o vanno al dispositivo che esso rappresenta; in questo modo per accedere ai dispositivi non è necessario nessun programma speciale (e nessuna metodologia speciale per la programmazione delle applicazioni, come la cattura degli interrupt o il mandare richieste ad una porta seriale); ad esempio, per mandare un file alla stampante, basta dire
$ cat nomefile > /dev/lp1
$
ed il contenuto del file viene stampato (il file deve, naturalmente, essere in una forma riconoscibile dalla stampante). Comunque, dato che non è una buona idea avere diverse persone che inviano file usando cat contemporaneamente alla stampante, di solito si usa un programma speciale per farlo (normalmente lpr); un programma del genere si assicura che venga stampato solo un file alla volta e manderà gli altri in stampa in sequenza a mano a mano che la stampante ne finisce uno. Anche per la maggior parte degli altri dispositivi serve una cosa del genere; in effetti, in genere non ci si deve preoccupare per niente di questo tipo di file.
Dato che i dispositivi appaiono come file nel filesystem (nella directory /dev), è facile vedere quali file di device esistono usando ls o un altro comando adatto. Nell’output di ls -l la prima colonna contiene il tipo di file ed i suoi permessi. Ad esempio, per un dispositivo seriale sul mio sistema appare:
$ ls -l /dev/cua0
crw-rw-rw-   1 root     uucp       5,  64 Nov 30  1993 /dev/cua0
$
Il primo carattere della prima colonna, ad esempio `c’ in crw-rw-rw- qui sopra, indica agli utenti informati il tipo del file, in questo caso un dispositivo a caratteri. Per i file ordinari il primo carattere è `-‘, per le directory è `d’, e per i dispositivi a blocchi `b’; leggete la pagina man di ls per altre informazioni.
Notate che di solito tutti i file di device esistono anche se il dispositivo corrispondente può non essere installato, quindi se avete un file /dev/sda, non è detto che abbiate realmente un hard disk SCSI. Avere tutti i file di device rende più semplici i programmi di installazione e semplifica l’aggiunta di nuovo hardware (non c’è bisogno di trovare i parametri corretti e creare il file di device per il nuovo dispositivo).

 Gli hard disk
In questa Sezione viene introdotta la terminologia relativa agli hard disk: se già conoscete i termini ed i concetti potete saltarla.
In Figura 4-1 viene riportato un disegno schematico delle parti più importanti di un hard disk; questo consiste di una o più piastre circolari[1] con entrambe le superfici ricoperte da una sostanza magnetica usata per la memorizzazione dei dati. Per ciascuna superficie c’è una testina di lettura e scrittura che esamina o altera i dati memorizzati. Le piastre ruotano su un asse comune, con una velocità tipica di 3600 rotazioni al minuto, anche se gli hard disk ad alte prestazioni raggiungono velocità maggiori. Le testine si spostano lungo il raggio della piastra, e questo movimento, combinato con la rotazione della piastra stessa, permette alla testina di accedere a tutti i punti delle superfici.
Il processore (CPU) e il disco in sé comunicano attraverso un controller che solleva il resto del computer dalla necessità di sapere come utilizzare l’hard disk, dato che si possono fare diversi tipi di controller per diversi tipi di disco che usino la stessa interfaccia verso il resto del computer. Quindi il computer può dire semplicemente “hey disco, dammi quello che voglio”, invece di una serie lunga e complessa di segnali elettrici per spostare la testina al punto desiderato, aspettare che la parte giusta ruoti sotto la testina e tutte queste cose antipatiche (in realtà, l’interfaccia al controller è comunque complessa, ma molto meno di come sarebbe dovuta essere altrimenti). Il controller può anche fare altre cose, come gestire la cache o isolare automaticamente i settori danneggiati.
Di solito è sufficiente sapere questo sull’hardware. In realtà ci sono anche molte altre cose, come il motore che fa girare le piastre e sposta le testine e l’elettronica che controlla le operazioni delle parti meccaniche, ma tutto questo non è rilevante per la comprensione del principio di funzionamento di un hard disk.
Le superfici sono di solito divise in anelli concentrici, chiamati tracce, e queste a loro volta sono divise in settori. Questa divisione viene usata per specificare punti dell’hard disk e per allocare lo spazio disco per i file. Per trovare un punto determinato dell’hard disk si potrebbe dire “piastra 3, traccia 5, settore 7”. Di solito il numero dei settori è lo stesso per tutte le tracce, ma in alcuni hard disk ci sono più tracce nei settori più esterni (tutti i settori sono delle stesse dimensioni fisiche, quindi nelle tracce più esterne ce ne entrano di più). Tipicamente, un settore conterrà 512 byte di dati. Il disco stesso non può gestire quantità di dati più piccole di un settore.
Figura 4-1. Schema di un hard disk.
 
Ciascuna superficie è divisa in tracce (e settori) nello stesso modo. Ciò significa che quando la testina di una superficie è su una traccia, quella dell’altra superficie è anch’essa sulla traccia corrispondente. Tutte le tracce corrispondenti prese insieme si chiamano cilindro. Ci vuole del tempo per spostare le testine da una traccia (cilindro) ad un’altra, quindi, mettendo i dati a cui si accede in contemporanea (diciamo un file) in modo che si trovino tutti all’interno dello stesso cilindro, non è necessario spostare la testina per leggerli tutti e viene migliorata la performance del disco. Non è sempre possibile mettere i file in questo modo: i file che vengono immagazzinati in posti diversi dell’hard disk vengono chiamati frammentati.
Il numero di superfici (o testine, che è la stessa cosa), cilindri e settori variano molto: le specifiche sul numero di ciascuno di questi elementi vengono chiamate geometria di un hard disk. La geometria viene di solito memorizzata in una locazione di memoria speciale, alimentata a batterie, chiamata RAM CMOS, da cui il sistema operativo la può leggere durante l’avvio del computer o l’inizializzazione dei driver.
Sfortunatamente, il BIOS[2] ha una limitazione che rende impossibile specificare un numero di tracce più alto di 1024 nella RAM CMOS, che è troppo poco per un hard disk grande. Per superare questo problema il controller degli hard disk mente sulla geometria e traduce gli indirizzi dati dal computer in qualcosa di adatto. Ad esempio, un hard disk può avere 8 testine, 2048 tracce e 35 settori per traccia[3]. Il suo controller può mentire al computer e dire che ha 16 testine, 1024 tracce e 35 settori per tracce, non superando così il limite per le tracce, e tradurre gli indirizzi che il computer gli dà dimezzando il numero della testina e raddoppiando quello della traccia. La matematica può in realtà essere molto più complicata perché i numeri in genere non sono così carini, ma i dettagli non sono rilevanti per la comprensione del principio. Questa traduzione distorce la visione del sistema operativo di come è organizzato il disco, rendendo poco pratico usare il trucco di mettere tutti i dati su uno stesso cilindro per aumentare la performance.
Questa traduzione è un problema solo per i dischi IDE; quelli SCSI usano un numero di settori sequenziale (cioè il controller traduce un numero di settore sequenziale nella tripletta testina, cilindro e settore) ed un metodo totalmente diverso per la comunicazione tra la CPU e il controller, quindi il problema non si pone. Notate, comunque, che il computer può non sapere la geometria reale neanche di un disco SCSI.
Dato che Linux spesso non conosce la geometria reale di un disco, i suoi filesystem non provano neanche a mantenere i file all’interno di un singolo cilindro; provano invece ad assegnare ai file settori numerati sequenzialmente, cosa che dà quasi sempre una performance simile. La questione è complicata ulteriormente dalle cache sul controller e dai precaricamenti automatici fatti dal controller stesso.
Ciascun hard disk è rappresentato da un file di device separato. Di solito ci possono essere solo due o quattro hard disk IDE, che corrispondono rispettivamente a /dev/hda, /dev/hdb, /dev/hdc, e /dev/hdd. Gli hard disk SCSI corrispondono a /dev/sda, /dev/sdb, e così via. Esistono delle convenzioni simili anche per altri tipi di hard disk: per altre informazioni vedere [DEVICE-LIST]. Notare che i file di device per gli hard disk danno accesso al disco intero, senza considerare le partizioni (che verranno spiegate più avanti) ed è facile rovinare i dati in essi contenuti se non si fa attenzione. I file di device dei dischi di solito vengono usati solo per accedere al loro master boot record (che verrà anch’esso spiegato più avanti).
 Note
[1]
Le piastre sono fatte di un materiale duro, come l’alluminio, da cui il nome hard disk, cioè “disco duro”.
[2]
Il BIOS è un software fisso immagazzinato nei chip della ROM. Ha il compito, tra le altre cose, degli stadi iniziali del processo di avvio.
[3]
I numeri sono completamente inventati.

 I floppy
Un floppy disk consiste di una membrana flessibile coperta su uno solo o su entrambi i lati con una sostanza magnetica simile a quella degli hard disk. Il floppy in sé non ha una testina di lettura e scrittura, ma questa è inclusa nel lettore. Un floppy corrisponde ad una piastra di un hard disk, ma è rimuovibile ed un lettore può essere usato per accedere a diversi floppy, mentre l’hard disk è una singola unità indivisibile.
Come un hard disk, un floppy è suddiviso in tracce e settori (e le due tracce corrispondenti sui due lati di un floppy formano un cilindro), ma ne ha meno di un hard disk.
Un lettore di floppy può di solito usare diversi tipi di dischi: ad esempio, un lettore da 3.5 pollici può usare sia dischi da 720 kB che da 1.44 MB; dato che il lettore deve operare in maniera leggermente diversa e che il sistema operativo deve conoscere la dimensione del disco, ci sono più file di device per ciascun lettore di floppy, uno per ciascuna combinazione di lettore e tipo di disco. Quindi, /dev/fd0H1440 è il primo lettore di floppy (fd0), un lettore a 3.5 pollici, che usa un dischetto da 3.5 pollici ad alta densità (H) di dimensioni 1440 kB (1440), cioè un normale floppy da 3.5 HD. Per altre informazioni sulle convenzioni per i nomi dei dispositivi floppy, vedere [DEVICE-LIST].
I nomi dei device dei floppy sono complessi, comunque, quindi Linux ne ha uno che individua automaticamente il tipo di disco nel lettore; funziona provando a leggere i primi settori di un dischetto inserito nel lettore usando diversi tipi di floppy finché trova quello corretto. Naturalmente ciò richiede che il dischetto sia prima stato formattato. I device automatici sono /dev/fd0, /dev/fd1, e così via.
I parametri che il device automatico usa per accedere ad un disco possono essere impostati anche usando il programma setfdprm. Una cosa del genere può essere utile se dovete usare dei dischi che non seguono le normali dimensioni dei floppy: ad esempio se hanno un numero di settori non usuale, o se per qualche ragione il riconoscimento automatico non funziona e manca il corrispondente file di device.
Linux può gestire molti formati non standard di floppy in aggiunta a tutti quelli standard, anche se alcuni di questi richiedono di usare dei programmi di formattazione speciali. Non vedremo questi tipi di disco ora, ma nel frattempo potete esaminare il file /etc/fdprm, che specifica le impostazioni riconosciute da setfdprm.
Il sistema operativo deve sapere quando viene cambiato il disco nel drive dei floppy, ad esempio per evitare di usare dati messi in cache dal disco precedente. Sfortunatamente, la linea di segnale che viene usata per questo qualche volta non funziona e, peggio, non sarà sempre individuabile quando il lettore viene usato da MS-DOS. Se avete degli strani problemi quando usate i floppy, forse la ragione è questa. L’unico modo di correggere questo problema è riparare il lettore dei floppy.
 I CD-ROM
I lettori di CD-ROM usano dischi a lettura ottica ricoperti di plastica. Le informazioni vengono registrate sulla superficie del disco[1] in piccoli `fori’ allineati lungo una spirale che va dal centro verso l’esterno. Il lettore dirige un raggio laser lungo la spirale per leggere il disco. Quando il laser colpisce un buco, il raggio viene riflesso in un modo, quando colpisce la superficie liscia viene riflesso in un altro, rendendo facile codificare i bit e quindi le informazioni. Il resto è facile, semplice meccanica.
I lettori di CD-ROM sono lenti se paragonati agli hard disk. Mentre un tipico hard disk ha un tempo di ricerca medio minore di 15 millisecondi, un CD-ROM veloce si attesta sui decimi di secondo; una velocità di trasferimento dati reale di centinaia di kilobyte al secondo è piuttosto alta. La lentezza sta a significare che i lettori di CD-ROM non sono comodi da usare al posto degli hard disk (alcune distribuzioni di Linux forniscono filesystem `live’ su CD-ROM, rendendo inutile copiare i file sull’hard disk e quindi facilitando l’installazione e salvando molto spazio su disco), anche se è sempre possibile. Per installare nuovo software, i CD-ROM sono molto validi, perché non è essenziale una velocità altissima durante l’installazione.
Ci sono diversi modi di sistemare i dati su un CD-ROM; il modo più comune è specificato dallo standard internazionale ISO 9660. Questo standard specifica un filesystem minimale, anche più povero di quello usato dall’MS-DOS; d’altra parte, è talmente minimale che qualsiasi sistema operativo dovrebbe essere in grado di mapparlo sul suo sistema nativo.
Per l’uso normale sotto UNIX non si può usare il filesystem ISO 9660, quindi è stata sviluppata un estensione allo standard: le estensioni Rock

Manuale Amministratore di Sistemaultima modifica: 2008-12-19T14:45:00+01:00da falchibaiso
Reposta per primo quest’articolo

Lascia un commento