Preparazione all'esame per la Certificazione LPI 101 (release 2), Parte 4Il lettore è il benvenuto ad "Amministrazione avanzata", l'ultima di quattro brevi guide pensate come preparazione per l'esame 101 (release 2) del Linux Professional Institute. In questa breve guida (Parte 4), sarà rinforzata la propria conoscenza nelle tecniche avanzate di amministrazione in Linux coprendo una varietà di argomenti fra i quali i filesystem in Linux, il processo di avvio (o boot) di Linux, i runlevel, le quote sui filesystem e i log di sistema. Questa breve guida è particolarmente adatta a qualcuno che dovesse svolgere il ruolo di amministratore di sistema principale per la prima volta, dato che copre molti problemi di basso livello che tutti gli amministratori di sistema dovrebbero conoscere. Se si è nuovi in Linux, è raccomandato di cominciare con la Parte 1 e continuare attraverso la serie fino a questo punto. Per qualcuno, molto di questo materiale sarà nuovo, ma alcuni utenti Linux con più esperienza potrebbero trovare questa breve guida solo un bel modo di "smussare" i propri fondamenti sulle capacità come amministratori di sistema Linux e prepararsi così per il prossimo livello della certificazione LPI. Verso la fine di questa serie di brevi guide (otto in tutto che coprono gli esami 101 e 102 del LPI), si avrà la conoscenza necessaria per diventare un Amministratore di Sistema Linux e il lettore sarà pronto a conseguire la certificazione LPIC di Livello 1 del Linux Professional Institute se lo desidera. Per coloro che hanno prelevato la versione di rilascio 1 di questa breve guida per ragioni ulteriori oltre alla preparazione dell'esame del LPI, probabilmente non è necessario prendere anche questa. Comunque, se si sta pianificando di sostenere l'esame, si dovrebbe considerare seriamente la lettura di questa breve guida revisionata. Il logo LPI è un marchio del Linux Professional Institute. Per questioni tecniche riguardo i contenuti di questa breve guida, contattare gli autori:
Daniel Robbins vive in Albuquerque, New Mexico, ed è l'Architetto Capo di Gentoo Technologies, Inc., il creatore di Gentoo Linux, un'avanzata versione di Linux per Pc, e del sistema Portage, un sistema di porting per Linux di prossima generazione. Ha anche dato il suo contributo come autore per i libri Macmillan Caldera OpenLinux Unleashed, SuSE Linux Unleashed e Samba Unleashed. Daniel è stato coinvolto con i computer in molti modi fino dalla seconda classe, quando fu avviato per la prima volta al linguaggio di programmazione Logo così come ad una potenzialmente pericolosa dose di Pac Man. Questo forse spiega perché è stato fino da allora impiegato come un Lead Graphic Artist (letteralmente, artista grafico di punta) dalla SONY Electronic Publishing/Psygnosis. Daniel si diverte passando il proprio tempo con la moglie, Mary, e sua figlia, Hadassah. Chris Houser, conosciuto dagli amici come "Chouser", è diventato un sostenitore di UNIX fin dal 1994 quando ha preso parte al gruppo di amministrazione delle reti scentifiche di calcolatori alla Taylor University nell'Indiana, dove ha conseguito la sua laurea in Scienze Informatiche e Matematiche. Fino da allora, ha continuato a lavorare nella programmazione di applicazioni Web, sviluppo di interfacce utente, supporto professionale al software video e ora alla programmazione di driver per dispositivi Tru64 UNIX alla Compaq. Ha anche contribuito a diversi progetti di software libero, più recentemente a Gentoo Linux. Vive con sua moglie e due gatti in New Hampshire. Aron Griffis è diplomato alla Taylor University con una laurea in Scienze Informatiche e un premio che dichiara, "Futuro Fondatore di un utopistico gruppo UNIX". Lavorando verso questo obiettivo, Aron è impiegato presso Compaq scrivendo driver di rete per Tru64 UNIX e spende il suo tempo libero accordando il piano o sviluppando Gentoo Linux. Vive con sua moglie Amy (anche lei ingegnere UNIX) in Nashua, NH. 2. Filesystem, partizioni e dispositivi a blocchi Introduzione ai dispositivi a blocchi In questa sezione sarà data una buona base agli aspetti orientati al disco di Linux, inclusi i filesystem in Linux, le partizioni e i dispositivi a blocchi. Una volta che si avrà preso familiarità con i particolari su dischi e filesystem, il persorso continuerà attraverso il processo di preparazione delle partizioni e dei filesystem in Linux. Per cominciare, saranno introdotti i "dispositivi a blocchi". Il più famoso dispositivo a blocchi è probabilmente quello che rappresenta il primo componente sull'IDE in un sistema Linux:
Se il proprio sistema usa dispositivi SCSI, il primo disco fisso sarà:
Il dispositivo a blocchi di cui sopra rappresenta un'interfaccia astratta per il disco. I programmi utente possono usare questi dispositivi a blocchi per interagire con il disco senza preoccuparsi se l'interfaccia è realmente un'IDE, SCSI o qualsiasi cosa. Il programma può semplicemente indirizzare la memoria sul disco come un gruppo di blocchi contigui ad accesso casuale con dimensione pari a 512 byte. Sotto Linux, si creano filesystem usando uno speciale comando chiamato mkfs (0 mke2fs, mkreiserfs, etc.), specificando un particolare dispositivo a blocchi come argomento a riga di comando. Comunque, nonostante sia teoricamente possibile usare un "intero disco" come dispositivo a blocchi (uno che rappresenti l'intero disco) come /dev/hda o /dev/sda per ospitare un singolo filesystem, questo non avviene quasi mai in pratica. Invece, dispositivi a blocchi disco interi vengono divisi in più piccole e maneggevoli dispositivi a blocchi chiamati partizioni. Le partizioni sono create usando uno strumento chiamato fdisk, che è usato per creare e modificare la tabella delle partizioni che è immagazzinata in ogni disco. La tabella delle partizioni definisce esattamente come suddividere l'intero disco. È possibile dare un'occhiata alla tabella delle partizioni di un disco eseguendo fdisk, specificando un dispositivo a blocchi che rappresenta un intero disco come argomento.
Una volta in fdisk, l'utente sarà accolto da un prompt che assomiglia al seguente:
Digitare p per mostrare la configurazione attuale delle partizioni su disco:
Questo particolare disco è configurato per ospitare sette filesystem Linux (ognuno con una corrispondente partizione elencata come "Linux") così come una partizione di swap (elencata come "Linux swap"). Panoramica su dispositivi a blocchi e partizionamento Notare i nomi delle corrispondenti partizioni dei dispositivi a blocchi sul lato sinistro, questi iniziano da /dev/hda1 e proseguono fino a /dev/hda9. Nei primi PC, il software di partizionamento permetteva solo un massimo di quattro partizioni (chiamate partizioni primarie). Questo era troppo limitativo, quindi è stato escogitato un modo per ovviare a questo problema, ovvero tramite il partizionamento esteso. Una partizione estesa è molto simile ad una partizione primaria e si somma al limite di quattro partizioni primarie. Comunque, le partizioni estese possono contenere un qualsiasi numero delle così dette partizioni logiche al loro interno, fornendo un modo effettivo per superare il limite delle quattro partizioni. Panoramica sulle partizioni, continua Tutte le partizioni come hda5 e superiori sono partizioni logiche. I numeri da 1 a 4 sono riservati per partizioni primarie ed estese. Nell'esempio sopra, da hda1 a hda3 sono partizioni primarie, hda4 è una partizione estesa che contiene le partizioni logiche da hda5 a hda9. In effetti non dovrebbe mai essere usata /dev/hda4 per immagazzinare direttamente un filesystem -- semplicemente assume il ruolo di contenitore per le partizioni da hda5 a hda9. Inoltre, bisogna notare che ogni partizione ha un "Id", anche chiamato tipo di partizione. Ogni volta che viene creata una nuova partizione, ci si deve assicurare che il tipo di partizione sia impostato correttamente. 83 è il tipo di partizione corretto per le partizioni che dovranno ospitare filesystem Linux e 82 è il tipo di partizione corretto per partizioni swap Linux. È possibile impostare il tipo di partizione usando l'opzione t in fdisk. Il kernel Linux usa il tipo di partizione impostato per auto-rilevare il filesystem e i dispositivi di swap sul disco all'avvio. Usare fdisk per configurare le partizioni Adesso che è stata data un'introduzione al modo in cui il partizionamento del disco avviene sotto Linux, è il momento di procedere attraverso il processo di configurazione delle partizione del disco e dei filesystem per una nuova installazione di Linux. In questo processo, sarà impostato un disco con quattro nuove partizioni e quindi verranno creati filesystem su di esse. Questi passi condurranno ad un disco completamente pulito senza dati al suo interno che può essere usato come base per una nuova installazione di Linux.
Come sarà il disco partizionato Dopo aver attraversato il processo di creazione delle partizioni sul proprio disco, la configurazione delle partizioni dovrebbe assomigliare alla seguente:
Commento all'esempio di partizionamento Nella configurazione delle partizioni "da principianti" proposta, ci sono tre partizioni. La prima (/dev/hda1) all'inizio del disco è una piccola partizione chiamata partizione d'avvio (o di boot). Lo scopo della partizione di boot è quella di contenere tutti i dati critici relativi all'avvio -- informazioni sul boot loader GRUB (se si userà GRUB) così come anche i(l) kernel Linux. La partizione di boot fornisce un posto sicuro per immagazzinare tutto ciò che è legato all'avvio di Linux. Durante il normale uso di Linux di tutti i giorni, la propria partizione di boot dovrebbe rimanere non montata per sicurezza. Se si è impostato un sistema SCSI, la partizione di boot probabilmente risulterà essere chiamata /dev/sda1. È raccomandato avere partizioni di boot (contenenti tutto ciò che è necessario per far funzionare il boot loader) all'inizio del disco. Anche se non è più un requisito necessario ad oggi, è una utile tradizione dai giorni in cui il boot loader LILO non era capace di caricare kernel da filesystem che si estendevano oltre il cilindro 1024 del disco. La seconda partizione (/dev/hda2) è usata per lo spazio di swap. Il kernel usa lo spazio di swap come memoria virtuale quando la RAM scarseggia. Questa partizione, relativamente parlando, non è molto grande, di solito qualcosa come 512 MB. Se si sta impostando un sistema SCSI, questa partizione probabilmente risulterà essere chiamata /dev/sda2. La terza partizione (/dev/hda3) è abbastanza grande e copre il resto del disco. Questa partizione è chiamata partizione di root (radice) e sarà usata per ospitare il proprio filesystem che conterrà il filesystem principale di Linux. Su un sistema SCSI, la partizione risulterà essere chiamata /dev/hda3. Adesso bisogna creare le partizioni come nell'esempio e la tabella sopra. Primo, entrare in fdisk digitando fdisk /dev/hda o fdisk /dev/sda, a seconda che si usi IDE o SCSI. Quindi, digitare p per vedere la propria configurazione attuale di partizionamento. Se c'è qualcosa sul disco che si desidera recuperare, fermarsi subito. Continuando in questa direzione, tutti i dati esistenti sul proprio disco saranno cancellati.
Eliminare le partizioni esistenti Ora, è il momento di cancellare le partizioni esistenti. Per farlo, digitare d e premere invio. Verrà chiesto all'utente il numero di partizione che desidera cancellare. Per eliminare una pre-esistente /dev/hda1, bisogna digitare:
La partizione è stata accodata per la cancellazione. Non apparirà più digitando p, ma non sarà cancellata fino a che le proprie modifiche non verranno salvate. Se si è fatto un errore e si vuole interrompere senza salvare le modifiche, digitare immediatamente q e premere invio a la propria partizione non sarà cancellata. Adesso, assumendo che davvero si vogliano cancellare tutte le partizioni sul proprio sistema, digitare ripetutamente p per stampare una lista delle partizioni e quindi digitare d e il numero della partizione da cancellare. In conclusione, si finirà per avere una tabella delle partizioni vuota:
Ora che la tabella delle partizioni in memoria è vuota, si è pronti per creare una partizione di boot (avvio). Per farlo, digitare n per creare una nuova partizione, quindi p per dire a fdisk che si vuole una partizione primaria. Ancora, digitare 1 per creare la prima partizione primaria. Quando viene chiesto qualcosa al riguardo dell'ultimo cilindro, digitare +100M per creare una partizione della dimensione di 100MB. Di seguito il risultato di questi passi:
Adesso, digitando p, dovrebbe essere mostrato il seguente listato in merito alle partizioni:
Proseguendo, bisogna creare la partizione di swap. Per farlo, digitare n per creare una nuova partizione, quindi p per dire a fdisk che si vuole una partizione primaria. Ancora, digitare 2 per creare la seconda partizione primaria, /dev/hda2 nel caso proposto. Quando viene chiesto qualcosa al riguardo del primo cilindro, premere invio. Quando viene chiesto qualcosa al riguardo dell'ultimo cilindro, digitare +512M per creare una partizione delle dimensioni di 512MB. Dopo aver fatto tutto questo, premere t per impostare il tipo della partizione e quindi digitare 82 per assegnare il tipo di partizione "Linux Swap". Alla fine di questi passi, digitando p dovrebbe essere mostrata una tabella delle partizioni che assomiglia alla seguente:
Alla fine, è necessario impostare il flag "bootable" (avviabile) sulla propria partizione di boot e poi scrivere le modifiche su disco. Per etichettare /dev/hda1 come partizione "avviabile", premere a nel menù e quindi digitare 1 come numero di partizione. Premendo adesso p, è possibile vedere che /dev/hda1 ha un "*" nella colonna "Boot". Ora, bisogna scrivere le modifiche su disco. Per farlo, digitare w e premere invio. Le partizioni del proprio disco saranno adesso correttamente configurate per l'installazione di Linux.
Partizionamento esteso e logico Nell'esempio sopra, è stata creata una singola partizione primaria che conterrà un filesystem usato per immagazzinare tutti i propri dati. Questo significa che, dopo aver installato Linux, questo filesystem principale sarà montato come "/" e conterrà un albero di cartelle che contiene tutti i propri file. Sebbene questo sia un modo comune di impostare un sistema Linux, c'è un altro approccio con cui si dovrebbe avere familiarità. Questo approccio usa partizioni multiple che ospitano filesystem diversi e sono quindi "collegate" insieme per formare un albero di filesystem coeso. Per esempio, è comune mettere /home e /var ognuno sul proprio filesystem. La partizione hda2 potrebbe essere fatta come partizione estesa piuttosto che come partizione primaria. Quindi, potrebbero essere create hda5, hda6 e hda7 come partizioni logiche (che dovrebbero essere tecnicamente contenute "dentro" a hda2), che potrebbero ospitare rispettivamente i filesystem /, /home e /var. È possibile imparare altro riguardo questi tipi di configurazione a filesystem multipli studiando le risorse elencate nel prossimo paragrafo. Per maggiori informazioni sul partizionamento, si può dare un'occhiata ai seguenti trucchi al riguardo:
Adesso che le partizioni sono state create, è il momento di impostare i filesystem sulle partizioni di boot e root così che possano essere montate e usate per immagazzinare dati. Bisogna anche configurare la partizione di swap per essere usate come memoria swap. Linux supporta una varietà di diversi tipi di filesystem; ogni tipo ha i suoi punti forti e le sue debolezze e il proprio insieme di caratteristiche prestazionali. In questa breve guida verrà discussa la creazione dei filesystem ext2, ext3, XFS, JFS e ReiserFS. Prima di creare filesystem sul sistema di esempio, verrà fatto un breve riassunto dei vari filesystem disponibili sotto Linux. Saranno discussi in modo più dettagliato i filesystem più avanti in questa stessa guida. Il filesystem per Linux ext2 è del tipo testato e provato, ma non ha metadati per il journaling e ciò significa che i processi di controllo del filesystem ext2 al momento dell'avvio possono essere abbastanza lunghi. Ad oggi esiste una selezione abbastanza ampia di filesystem journaled di nuova generazione che possono essere controllati nella loro consistenza molto velocemente e sono perciò solitamente preferiti al posto delle loro controparti non-journaled. I filesystem journaled impediscono lunghe attese all'avvio del proprio sistema quando il proprio filesystem sembra essere in uno stato inconsistente. Il filesystem ext3 è la versione journaled del filesystem ext2, fornisce metadati di journaling per un veloce recupero in aggiunta a metodi di journaling migliorati, come il journaling totale o logico dei dati. Il filesystem ext3 e molto buono e affidabile. Offre in genere prestazioni decenti in molteplici situazioni. Poiché non fa uso estensivo di "alberi" nella propria struttura interna, non risulta molto scalabile e ciò significa che non è una scelta ideale per filesystem molto grandi o situazioni in cui si gestiranno file molto grossi o abbondanti quantità di file in una sola cartella. Quando usato nel rispetto dei parametri di progettazione, però, ext3 è un eccellente filesystem. Una delle cose positive di ext3 è che un filesystem ext2 esistente può essere aggiornato "sul posto" ad ext3 abbastanza facilmente. Questo permette un facile percorso di aggiornamento per sistemi Linux esistenti che già usano ext2. ReiserFS è un filesystem basato sui B-alberi (o B-tree) che ha prestazioni complessivamente molto buone e estremamente superiori sia a ext2 che ext3 quando ha a che fare con file piccoli (file minori di 4k), spesso di un fattore di 10x-15x. ReiserFS è anche estremamente scalabile e ha metadati di journaling. Dal kernel 2.4.18 in poi, ReiserFS è solido come una roccia e altamente raccomandato per essere usato sia come filesystem multiuso che nei casi estremi come la creazione di grandi filesystem, l'uso di molti piccoli file, file molto grandi e cartelle che contengono decine o centinaia di file. ReiserFS è il filesystem che l'Autore raccomanda di base per tutte le partizioni non di boot. XFS è un filesystem con metadati di journaling. È fornito con un robusto insieme di caratteristiche e ottimizzato per la scalabilità. L'Autore raccomanda l'uso di questo filesystem su sistemi Linux con dispositivi di alto livello SCSI e/o memorie con canali in fibra e una fornitura di corrente senza interruzione. Poiché XFS memorizza in cache su RAM i dati di passaggio in modo aggressivo, programmi progettati in modo improprio (quelli che non prendono le giuste precauzioni quando scrivono file su disco, e ce ne sono svariati di questo tipo) possono perdere una discreta somma di dati se il sistema cede improvvisamente. JFS è un filesystem journaling ad alte prestazioni di IBM. È diventato recentemente pronto alla produzione e sarebbe preferibile aspettare ancora un po' di tempo prima di commentare in modo positivo o negativo la sua generale stabilità a questo punto. Raccomandazioni per i filesystem Se si sta cercando il più robusto dei filesystem con journaling, si usi ext3. Se si sta cercando un filesystem multiuso dalle alte prestazioni con supporto al journaling, si usi ReiserFS; sia ext3 che ReiserFS sono maturi, ben fatti e raccomandati per uso generale. Basandosi sull'esempio sopra, saranno usati i seguenti comandi per inizializzare tutte le partizioni per l'uso:
È stato scelto ext3 per la partizione di boot /dev/hda1 poiché è un filesystem con journaling robusto e supportato da tutti i principali boot loader. Viene usato mkswap per la partizione di swap /dev/hda2 -- la scelta è ovvia in questo caso. Per il filesystem principale della partizione radice su /dev/hda3 è stato scelto ReiserFS, dato che è un solido filesystem con journaling che offre eccellenti prestazioni. Adesso, andando avanti devono essere inizializzate le proprie partizioni. mkswap è un comando che viene usato per inizializzare le partizioni di swap:
A differenza dei filesystem regolari, le partizioni di swap non vengono montate. Piuttosto, sono abilitate usando il comando swapon:
I propri script di avvio del sistema Linux si preoccupano automaticamente di abilitare le partizioni di swap. Quindi, il comando swapon è di solito necessario solo quando si ha bisogno di aggiungere immediatamente un po' di swap appena creata. Per vedere i dispositivi di swap correntemente abilitati, digitare cat /proc/swaps. Creare filesystem ext2, ext3 e ReiserFS Si può usare il comando mke2fs per creare filesystem ext2:
Per chi desidera usare ext3, è possibile creare un filesystem ext3 usando mke2fs -j:
Per creare un filesystem ReiserFS, usare il comando mkreiserfs:
Per creare un filesystem XFS, usare il comando mkfs.xfs:
Per creare un filesystem JFS, usare il comando mkfs.jfs:
Una volta creato il filesystem, è possibile montarlo usando il comando mount:
Per montare un filesystem, specificare il dispositivo a blocchi della partizione come primo argomento e un "punto di montaggio (mount-point)" come secondo argomento. Il nuovo filesystem sarà "agganciato" al mount-point. Questo ha anche l'effetto di "nascondere" ogni file che era nella cartella /mnt sul filesystem ospite. Più tardi, una volta smontato il filesystem, questi file riappariranno. Dopo aver eseguito il comando mount, ogni file creato o copiato dentro /mnt sarà immagazzinato sul nuovo filesystem ReiserFS montato. Si supponga di voler montare la propria partizione di boot dentro /mnt. È possibile farlo seguendo i passi esposti di seguito:
Adesso, il filesystem di boot è disponibile dentro /mnt/boot. Se si creano file all'interno di /mnt/boot, saranno immagazzinati sul filesystem ext3 che risiede fisicamente su /dev/hda1. Se si creano file dentro /mnt ma non in /mnt/boot, questi saranno depositati sul filesystem ReiserFS che risiede su /dev/hda3. E se si creano file fuori da /mnt, non verranno immagazzinati su alcun filesystem se non su quello del sistema Linux attuale o sul disco di boot. Per vedere quali filesystem sono montati, digitare mount da solo. Di seguito il risultato di mount su uno dei sistemi Linux attualmente in esecuzione dell'Autore, che ha le partizione configurate allo stesso modo di quelle proposte nell'esempio sopra:
È possibile anche vedere informazioni simili digitando /proc/mounts. Il filesystem di root, /dev/hda3 viene montato automaticamente dal kernel all'avvio e prende il nome simbolico di /dev/hda3. Sul sistema di esempio, sia /dev/hda3 che /dev/root puntano allo stesso dispositivo a blocchi sottostante usando un collegamento simbolico:
Concetti ulteriori sul montaggio Qualcuno potrebbe chiedersi cosa è quindi il file "/dev/ide/host0....". Sistemi come quello dell'Autore che usano devfs o device-management filesystem (gestione dispositivi via filesystem) per /dev hanno nomi ufficiali più lunghi per le partizioni e i dispositivi a blocchi su disco rispetto a quelli usati da Linux in passato. Per esempio, /dev/ide/host0/bus1/target0/lun0/part7 è il nome ufficiale per /dev/hdc7 e /dev/hdc7 stesso è solo un collegamento simbolico che punta al dispositivo a blocchi ufficiale. È possibile determinare se il proprio sistema sta usando devfs controllando se esiste il file /dev/.devfsd; se così fosse, allora devfs è attivo. Quando viene usato il comando mount per montare filesystem, questo cerca di auto-rilevare il tipo di filesystem. Talvolta, potrebbe non riuscirci e l'utente deve specificare il filesystem che deve essere montato digitandolo manualmente tramite l'uso dell'opzione -t, come segue:
oppure
È anche possibile personalizzare i vari attributi del filesystem da montare specificando opzioni a mount. Per esempio, è possibile montare un filesystem come "sola lettura" usando l'opzione ro:
Con /dev/hdc6 montato in sola lettura, nessun file può essere modificato in /mnt -- solo letti. Se il proprio filesystem è già montato come "lettura/scrittura" e si vuole passare alla modalità in sola lettura, si può usare l'opzione "remount" per evitare di dover smontare e montare il filesystem di nuovo:
Da notare che non è necessario specificare la partizione per il dispositivo a blocchi poiché il filesystem è già montato e mount sa che /mnt è associato con /dev/hdc6. Per rendere di nuovo il filesystem scrivibile, lo si può rimontare in lettura-scrittura:
Si noti che questi comandi per rimontare non termineranno con successo se qualche processo ha aperto qualche file o cartella in /mnt. Per familiarizzare con tutte le opzioni di montaggio disponibili sotto Linux, digitare man mount. Fin'ora è stato illustrato come partizionare un disco di esempio e montare i filesystem manualmente da un disco di avvio. Ma una volta che il sistema Linux è installato, è interessante scoprire quale sia il modo di configurarlo per montare i filsystem corretti al momento giusto. Per esempio, si supponga di installare Gentoo Linux sulla configurazione di filesystem dell'esempio visto. C'è da chiedersi in che modo il sistema saprà come scovare il filesystem di root che si trova su /dev/hda3. Se anche qualche altro filesystem -- come swap -- necessita di essere montato all'avvio, è utile scoprire come può il sistema scoprire quali siano questi filesystem. Il kernel Linux è informato su quale filesystem di root usare dal boot loader e i boot loader saranno discussi più avanti in questa breve guida. Ma per ogni altra cosa, il proprio sistema Linux ha un file chiamato /etc/fstab che lo informa riguardo a quali filesystem sono disponibili per essere montati. Bisogna dargli un'occhiata, adesso. Verrà illustrato ora un file /etc/fstab di esempio:
Sopra, ogni riga non commentata in /etc/fstab indica una partizione di dispositivo a blocchi, un punto di aggancio, un tipo di filesystem, le opzione del filesystem da usare quando viene montato il filesystem e due campi numerici. Il primo campo numerico è usato per specificare al comando di backup dump i filesystem che dovrebbero essere salvati. Ovviamente, per chi non avesse pianificato l'uso di dump sul proprio sistema c'è la possibilità di ignorare questo campo senza subire alcuna conseguenza. L'ultimo campo è usato dal programma di controllo di integrità per filesystem fsck e lo informa sull'ordine in cui i filesystem presenti dovrebbero essere controllati all'avvio. Nei prossimi paragrafi fsck sarà discusso ancora. Focalizzarsi sulla riga relativa a /dev/hda1; è possibile vedere che /dev/hda1 ospita un filesystem ext3 che dovrebbe essere montato sul punto di aggancio /boot. Adesso, ci si concentri sulle opzioni per /dev/hda1 nella colonna dedicata. L'opzione noauto informa il sistema che /dev/hda1 non deve essere montato automaticamente al momento dell'avvio; senza questa opzione /dev/hda1 sarebbe montato in modo automatico su /boot all'avvio del sistema. Da notare anche l'opzione noatime, che disattiva la registrazione delle informazioni sull'a(ccess)time (orario dell'ultimo accesso) sul disco. Questa informazione è di solito non necessario e disattivare l'aggiornamento dell'atime ha un effetto positivo sulle prestazione del filesystem. Adesso, dando un'occhiata alla linea che presenta /proc si nota come opzioni defaults. Usare defaults ogni volta in cui si desidera che il filesystem venga montato con le sole opzioni predefinite di mount. Dato che /etc/fstab ha più campi, non è possibile lasciare semplicemente il campo opzioni bianco. Da notare anche la linea in /etc/fstab per /dev/hda2. Questa linea definisce /dev/hda2 come dispositivo di swap. Dato che i dispositivi di swap non sono montati come filesystem, none (ndt, nessuno) è specificato nel campo del punto di aggancio. Grazie a questa voce in /etc/fstab, il dispositivo di swap /dev/hda2 sarà abilitato automaticamente all'avvio del sistema. Con una voce in /etc/fstab per /dev/cdrom come quella sopra, montare i dispositivi CD-ROM diventa semplice. Invece di digitare:
È possibili digitare ora:
In realtà, usare /etc/fstab permette di godere dei vantaggi riguardo all'opzione user. L'opzione user invita il sistema a permettere il montaggio del determinato filesystem da parte di ogni utente. Questo diviene utile per dispositivi di supporto rimovibili come dispositivi CD-ROM. Senza questa opzione di montaggio in fstab, solo l'utente root sarebbe capace di usare il dispositivo CD-ROM. Di solito, tutti i filesystem montati sono smontati automaticamente dal sistema a seguito di un riavvio o dello spegnimento. Quando un filesystem è smontato, ogni dato relativo ad esso riposto in memoria è scaricato sul disco. Comunque, è anche possibile smontare filesystem manualmente. Prima che un filesystem possa essere smontato, è necessario assicurarsi che non ci siano processi in esecuzione che hanno aperto file sul filesystem in questione. Quindi, usare il comanda umount, specificando o il nome del dispositivo o il punto di aggancio come argomento:
or
Una volta smontato, ogni file in /mnt che era stato "coperto" dal filesystem precedentemente montato adesso riapparirà. Se il proprio sistema crolla o si ferma per qualche ragione, potrebbe non avere un'opportunità per smontare in modo pulito i filesystem. Quando questo succede, i filesystem sono lasciati in uno stato inconsistente (e impredicibile). Al riavvio del sistema, il programma fsck rileverà che questi filesystem non sono stati smontati correttamente e vorrà effettuare un controllo di consistenza sui filesystem elencati in /etc/fstab.
Talvolta, potrebbe succedere che dopo un riavvio fsck non sia capace di riparare completamente un filesystem parzialmente danneggiato. In questi casi, tutto ciò che l'utente deve fare è portare il proprio sistema in modalità singolo utente ed eseguire fsck manualmente, fornendo le partizioni su dispositivo a blocchi come argomento. Mentre fsck effettua la riparazione dei filesystem, potrebbe chiedere all'utente se vuole correggere particolari difetti del filesystem. In genere, si dovrebbe rispondere y (si) a tutte le domande e permettere a fsckdi fare il suo dovere. Uno dei problemi con le analisi di fsck è che queste possono prendere abbastanza tempo per essere portate a termine, dato che i metadati del filesystem (strutture dati interne) necessitano di essere analizzate nelle loro totalità in modo da assicurare che siano consistenti. Con filesystem estremamente grandi, non è inusuale che un fsck esaustivo prende più di un'ora. Per poter risolvere il problema, un nuovo tipo di filesystem è stato progettato, chiamato filesystem journaling. I filesystem con journaling registrano un log su disco delle modifiche recenti ai metadati del filesystem stesso. In caso di collasso, il driver del filesystem ispeziona il log. Poiché il log contiene un'accurato resoconto delle modifiche recenti sul disco, solo queste parti di metadati del filesystem necessitano di essere controllate in cerca di errori. Grazie a questa importante modifica di progetto, verificare la consistenza di un filesystem con journaling di solito impiega solo pochi secondi, in relazione alla dimensione del filesystem. Per questa ragione, i filesystem con journaling stanno riscuotendo successo nella comunità Linux. Per maggiori informazioni sui filesystem con journaling, si faccia riferimento a Advanced filesystem implementor's guide, part 1: Journaling and ReiserFS (guida avanzata per sviluppatori di filesystem, parte 1: Journaling e ReiserFS). Di seguito saranno discussi i maggiori filesystem disponibili in Linux, insieme ai comandi associati e le opzioni. Il filesystem ext2 è stato il filesystem principale in Linux per molti anni. Ha in genere buone prestazioni per molte applicazioni ma non offre alcuna capacità di journaling. Questo lo rende inutilizzabile per filesystem molto grandi, dato che fsck può impiegare un tempo estremamente lungo. In aggiunta, ext2 ha molte limitazioni intrinseche dovute al fatto che ogni filesystem ext2 ha un numero fisso di inode che può trattare. Presto detto, ext2 è di solito considerato un filesystem estremamente robusto ed efficiente ma senza journaling.
Il filesystem ext3 usa lo stesso formato su disco di ext2 ma aggiunge la capacità di journaling. In realtà, di tutti i filesystem in Linux, ext3 presenta il più ampio supporto al journaling, supporta non solo metadati per il journaling ma anche journaling regolato (il predefinito) e journaling totale dati più metadati. Questa "speciale" modalità journaling aiuta ad assicurare l'integrità sui dati, non solo un breve controllo come altre implementazioni di journaling. Per questa ragione, ext3 è il miglior filesystem da usare se l'integrità dei dati è una priorità primaria assoluta. Comunque, queste caratteristiche di integrità dei dati talvolta impattano sulle prestazioni. In aggiunta, poiché ext3 usa lo stesso formato su disco di ext2, soffre ancora delle stesse limitazioni alla scalabilità del suo cugino senza journaling. Ext3 è una buona scelta per chi cerca un discreto filesystem con journaling multi uso che sia anche molto robusto.
ReiserFS è un filesystem relativamente nuovo che è stato progettato con lo scopo di fornire prestazioni molto buone su piccoli file, prestazioni ottime in genere ed alta scalabilità. Di solito, ReiserFS offre prestazioni molto buone in quasi tutte le situazioni. ReiserFS è preferito da molti per la sua velocità e scalabilità.
Il filesystem XFS è un filesystem con journaling di classe aziendale che è stato portato in Linux da SGI. XFS è un filesystem con journaling pieno di caratteristiche e scalabile che rappresenta una buona scelta per hardware affidabile di alta qualità (dato che conta pesantemente sulla memorizzazione dei dati in RAM) ma non una buona idea per hardware di scarsa qualità.
JFS è un filesystem con journaling ad alte prestazioni portato su Linux da IBM. JFS è usato dai server aziendali IBM e è progettato per applicazioni ad alte prestazioni. È possibile scoprire di più riguardo a JFS sul sito Web del progetto JFS.
Il filesystem VFAT non è davvero un filesystem che si potrebbe scegliere per immagazzinare file in Linux. Piuttosto, è un filesystem compatibile col driver DOS che permette di essere montato e di scambiare dati con filesystem basati su DOS e sul FAT di Windows. Il driver per filesystem VFAT è presente nel kernel base di Linux. Questa sezione introduce la procedura di avvio in Linux. Saranno discussi il concetto di boot loader, come impostare le opzioni del kernel all'avvio e come esaminare i log di avvio alla ricerca di errori. Il processo di avvio è simile per tutte le macchine, indipendentemente dalla distribuzione installata. Si consideri il seguente disco rigido di esempio:
Per prima cosa, il BIOS del computer legge i primi pochi settori del disco rigido. Questi settori contengono un programma molto piccolo, chiamata il "Master Boot Record" o "MBR". Il MBR ha memorizzata la locazione del kernel Linux sul disco rigido (la partizione 1 nell'esempio sopra), quindi carica il kernel in memoria a lo avvia. Il processo di avvio del kernel La cosa successiva (nonostante probabilmente comparirà solo per pochi istanti) è una linea simile alla seguente:
Questa è la prima linea stampata del kernel quando ne viene avviata l'esecuzione. La prima parte è la versione del kernel, seguita dall'identificazione dell'utente che ha creato il kernel (di solito root), il compilatore con cui è stato compilato e un identificativo temporale relativo al momento della compilazione. Di seguito a questa linea c'è una grande quantità di messaggi da parte del kernel riguardanti l'hardware del proprio sistema: il processore, il bus PCI, il controller del disco, i dischi, le porte seriali, il dispositivo a floppy, i dispositivi USB, gli adattatori di rete, le schede audio e potenzialmente altro saranno riportati ognuno insieme al loro stato. Quando il kernel termina il caricamento, avvia un programma chiamato init. Questo programma rimane in esecuzione fino a che il sistema non viene spento. È sempre assegnato all'ID di processo 1, come si può vedere:
Il programma init avvia il resto della propria distribuzione eseguendo una serie di script. Questi script di solito risiedono in /etc/rc.d/init.d o /etc/init.d ed effettuano servizi come l'impostazione dell'hostname (nome della macchna) sul sistema, il controllo di errori sul filesystem, il montaggio di filesystem addizionali, l'abilitazione della rete, l'avvio di servizi di stampa, etc. Quando gli script hanno completato, init avvia un programma chiamato getty che mostra il prompt per il login, e l'utente può procedere. Adesso che è stata fatta una breve panoramica attraverso il processo di avvio, sarà vista più da vicino la prima parte: il MBR e il caricamento del kernel. Il mantenimento del MBR è una responsabilità del "boot loader". I due boot loader più popolari per sistemi basati su x86 sono "LILO" (LInux LOader) e "GRUB" (GRand Unified Bootloader). Dei due, LILO è il boot loader più vecchio e più comune. La presenza di LILO sul proprio sistema è evidenziata all'avvio, con il breve prompt "LILO boot:". Da notare che potrebbe esserci il bisogno di tenere premuto il tasto di shift durante l'avvio per ottenere il prompt, dato che spesso un sistema è configurato per passare oltre senza fermarsi. Il prompt di LILO è abbastanza povero ma premendo il tasto <tab> verrà presentata una lista di potenziali kernel (o altri sistemi operativi) da avviare. Spesso c'è una sola voce nella lista. È possibile avviare uno di questi digitandolo e premendo <enter>. In alternativa si può semplicemente premere <enter> e il primo elemento sulla lista sarà avviato in modo predefinito. Occasionalmente si potrebbe voler passare un'opzione al kernel al momento dell'avvio. Alcune delle più comuni opzioni sono root= per specificare un filesystem radice alternativo, init=per indicare un programma init alternativo (come init=/bin/sh per recuperare un sistema mal configurato) e mem= per specificare la quantità di memoria nel sistema (per esempio mem=512M nel caso in cui Linux autorilevi solamente 128M). È possibile passare queste opzioni al kernel tramite il prompt di avvio di LILO:
Se c'è bisogno di specificare regolarmente opzioni da riga di comando, si dovrebbe considerare il caso di aggiungerle a /etc/lilo.conf. Il formato di questo file è descritto nella pagine di manuale lilo.conf. Un importante puntualizzazione su LILO Prima di passare a GRUB, c'è un importante nota per LILO. Ogni volta che vengono fatte modifiche a /etc/lilo.conf o quando viene installato un nuovo kernel, bisogna lanciare lilo. Il programma lilo riscrive il MBR per riflettere le modifiche fatte, includendo la registrazione della locazione assoluta su disco del kernel. L'esempio sotto fa uso dell'opzione -v per avere maggiori informazioni:
Il boot loader GRUB può essere considerato un boot loader di prossima generazione, successore di LILO. Più visibilmente per gli utenti, fornisce una interfaccia a menù invece del prompt primitivo di LILO. Per gli amministratori di sistema, il cambiamento è più significativo. GRUB supporta più sistemi operativi di LILO, mette a disposizione funzioni di sicurezza basate su password nel menù di avvio ed è più facile da amministrare. GRUB è di solito installato con il comando grub-install. Una volta installato, il menù di GRUB è amministrato modificando il file /boot/grub/grub.conf. Entrambi questi processi vanno oltre lo scopo di questo documento; si possono leggere le pagine info di GRUB prima di provare ad installare o amministrare GRUB stesso. Per passare parametri al kernel, è possibile digitare e nel menù di avvio. Questo dà la possibilità di modificare (premendo ancora e) sia il nome del kernel da caricare che i parametri da passare. Quando la modifica è stata effettuata, premere <invio> e quindi b per riavviare con le modifiche fatte. I messaggi di avvio del kernel e degli script di init di solito scorrono molto veloci. Si potrebbe notare un errore ma questo potrebbe essersene andato prima di riuscire a leggerlo correttamente. In questo caso, ci sono due posti dove poter guardare dopo l'avvio del sistema per scoprire cosa è andato storto (e se tutto va bene farsi un'idea di come correggere le cose). Se l'errore è apparso mentre il kernel veniva caricato o venivano testati i dispositivi hardware, è possibile recuperare una copia del log del kernel usando il comando dmseg:
Questa riga dovrebbe essere già nota. Questa è la prima linea che il kernel stampa quando viene caricato. Infatti, se si ridireziona il risultato di dmesg in un paginatore, è possibile vedere tutti i messaggi che il kernel stampa all'avvio, più ogni messaggio che il kernel ha stampato sulla console nel frattempo. Il secondo posto dove guardare per informazioni è nel file /var/log/messages. Questo file è registrato dal demone syslog, che accetta dati in ingresso da librerie, demoni e il kernel. Ogni linea nel file messages ha un riferimento temporale. Questo file è un buon posto dove guardare alla ricerca di errori che avvengono durante la fase degli init script o all'avvio. Per esempio, per vedere gli ultimi pochi messaggi dal nameserver:
Informazioni aggiuntive relative a questa sezione possono essere trovate nei collegamenti elencati di seguito:
Si ricorda dalla sezione precedente riguardo ai boot loader che è possibile passare parametri al kernel al momento dell'avvio. Uno dei parametri usati più di frequente è s, che causa l'avvio del sistema in modalità "singolo utente". Questa modalità di solito monta solo il filesystem radice, avvia un sotto insieme minimale degli script di init e avvia una shell piuttosto che fornire un prompt per il login. In aggiunta, la rete non viene configurata, così da eliminare la possibilità che fattori esterni influenzino il lavoro. Capire la modalità singolo utente Viene da chiedersi che lavoro può essere fatto con il sistema in questo stato. Per rispondere a questa domanda, bisogna tenere di conto della grossa differenza fra Linux e Windows. Windows è progettato per essere usato di norma da una persona alla volta, seduta alla console. È effettivamente sempre in modalità "singolo utente". Linux, d'altra parte, è usato più spesso per fornire applicazioni di rete o mettere a disposizione shell o sessioni X remote agli utenti della rete. Queste variabili aggiuntive non sono desiderabili quando si vogliono effettuare le operazioni di manutenzione come un ripristino da un backup, creare o modificare filesystem, aggiornare il sistema da un CD e via dicendo. In questi casi si dovrebbe usare la modalità a singolo utente. In realtà, non è del tutto necessario riavviare per poter raggiungere la modalità singolo utente. Il programma init gestisce la modalità attuale, o "runlevel", per il sistema. I runlevel standard per un sistema Linux sono definiti come segue:
Questi runlevel variano tra le distribuzioni, quindi ci si assicuri di consultare la documentazione della propria distribuzione. Per passare alla modalità singolo utente, usare il comando telinit, che indica a init di cambiare runlevel:
Si può notare dalla tabella sopra che è anche possibile spegnere o riavviare il sistema in questo modo. telinit 0 arresterà il computer; telinit 6 riavvierà il computer. Quando si indica al comando telinit di cambiare runlevel, un sotto insieme degli script di init saranno eseguiti per fermare o lanciare servizi di sistema. Comunque, è da notare che questo è piuttosto scortese se in quel momento ci sono utenti sul sistema (che potrebbero risultare abbastanza arrabbiati con l'amministratore). Il comando shutdown fornisce un metodo per cambiare runlevel in un modo che tratta gli utenti ragionevolmente. In maniera simile alla capacità del comando kill di inviare una varietà di segnali ad un processo, shutdown può essere usato per arrestare, riavviare o passare in modalità singolo utente. Per esempio, per passare alla modalità singolo utente entro 5 minuti:
Premendo <control-c> a questo punto, è possibile cancellare il passaggio imminente alla modalità singolo utente. Il messaggio sopra dovrebbe apparire su tutti i terminali del sistema, così gli utenti hanno un ragionevole lasso di tempo per salvare il loro lavoro e uscire (Qualcuno potrebbe discutere se 5 minuti sono o no "ragionevoli"). Se si è la sola persona sul sistema, è possibile usare "now" (ora) invece di un argomento in minuti. Per esempio, per riavviare il sistema immediatamente:
Nessuna possibilità di premere <control-c> in questo caso; il sistema è già in fase di spegnimento. Infine, l'opzione -h arresta il sistema:
A questo punto dovrebbe essere chiaro che il programma init è abbastanza importante in un sistema Linux. È possibile configurare init modificando il file /etc/inittab, che è descritto dalla pagina di manuale inittab(5). Sarà discussa solamente una linea chiave di questo file:
Sul sistema dell'Autore, il runlevel 3 è quello predefinito. Può essere utile cambiare questo valore per chi preferisse avere un sistema che si avvia immediatamente con una veste grafica (di solito nei runlevel 4 0 5). Per farlo, basta modificare il file e cambiare il valore nella linea indicata. Ma bisogna fare attenzione. Modificando il valore in qualcosa di non valido, probabilmente bisognerà mettere in pratica il trucco del init=/bin/sh accennato precedentemente. Informazioni aggiuntive relative a questa sezione posso essere trovate su:
Le quote sono la caratteristica di Linux che permettere all'amministratore di tracciare l'uso del disco da parte degli utenti o di un gruppo. Possono essere utili per prevenire l'uso da parte di un singolo utente o un gruppo di una porzione non equa di un filesystem o il suo riempimento completo. Le quote possono essere abilitate e gestite solo dall'utente root. In questa sezione, sarà descritto come impostare le quote sul proprio sistema Linux e gestirle efficacemente. Le quote sono una caratteristica del filesystem; Quindi, richiedono il supporto nel kernel. La prima cosa da fare è verificare di avere il supporto per le quote nel proprio kernel. È possibile farlo usando grep:
Se questo comando restituisce qualcosa di meno decisivo (come il fatto che CONFIG_QUOTA non è impostato) allora bisogna ricompilare il proprio kernel includendo il supporto alle quote. Non è un processo difficoltoso ma è fuori dallo scopo di questa sezione della guida. Se non si ha familiarità con le procedure di compilazione e installazione di un nuovo kernel, bisogna considerare l'idea di fare riferimento a questa breve guida. Prima di scendere a fondo nell'amministrazione delle quote, si prega di notare che il supporto ad esse in Linux nei kernel serie 2.4.x non è completo. Ci sono al momento problemi con le quote nei filesystem ext2 e ext3 e ReiserFS non sembra supportarle per niente. Questa breve guida basa i suoi esempi su XFS, che sembra supportare in modo adeguato le quote. Per cominciare con la configurazione delle quote nel proprio sistema, bisogna modificare /etc/fstab per montare il filesystem interessato con le quote abilitate. Nell'esempio proposto, sarà usato un filesystem XFS montato con le quote per utenti e gruppi abilitate:
Da notare che le opzioni usrquota e grpquota non abilitano necessariamente le quote su un filesystem. Bisogna assicurarci che le quote vengano abilitate usando il comando quotaon:
Esiste il comando corrispondente quotaoff per i casi in cui si desidera disabilitare le quote in futuro:
Ma per il momento, per chi proverà alcuni degli esempi proposti in questa breve guida, assicurarsi di avere abilitato l'uso delle quote. Il comando quota mostra l'uso del disco da parte dell'utente e i suoi limiti per tutti i filesystem montati in quel momento. L'opzione -v include nella lista i filesystem con le quote abilitate ma per cui non esiste spazio di immagazzinamento allocato attualmente per l'utente.
La prima colonna, blocks (blocchi), mostra quanto spazio su disco l'utente root sta usando al momento su ciascun filesystem. Le colonne seguenti, quota e limit (quote e limiti), si riferiscono ai limiti attualmente idonei impostati per lo spazio su disco. Sarà spiegata in seguito la differenza tra quote e limiti e il significato della colonna grace (grazia). La colonna files mostra quanti file l'utente root possiede sul particolare filesystem. Le colonne quota e limit seguenti si riferiscono ai limiti relativa ai file. Ogni utente può usare il comando quota per vedere il proprio rapporto sulle quote come mostrato nell'esempio precedente. In ogni caso solo l'utente root può guardare le quote degli altri utenti e gruppi. Per esempio, supposto di avere un filesystem, /dev/hdc1 montato su /usr/users, con due utenti: jane e john. Primo, bisogna dare un'occhiata all'uso del disco e i limiti di jane.
In questo esempio, si può vedere che le quote di jane sono impostate a zero, il che indica nessun limite. Adesso, si supponga di voler assegnare quote all'utente jane. Lo si può fare con il comando edquota. Prima di cominciare a modificare le quote, bisogna vedere quanto spazio è disponibile su /usr/users:
Non è un filesystem particolarmente grande, solo 600MB o quasi. Sembra prudente assegnare a jane una quota così che non possa usarlo oltre la sua equa partizione. Eseguendo edquota, viene creato un file temporaneo per ogni utente o gruppo specificato su riga di comando. Il comando edquota porta l'utente in un editor di testi e lo abilita ad aggiungere e/o modificare quote attraverso questo file temporaneo.
In modo simile al risultato del comando quota di cui sopra, le colonne blocks (blocchi) e inodes (inode) in questo file temporaneo si riferiscono allo spazio su disco e numero di file attualmente in uso da jane. Non è possibile modificare il numero di blocchi o inode; ogni tentativo di farlo sarà sommariamente scartato dal sistema. Le colonne soft (debole, inferiore) e hard (forte, superiore) mostrano le quote di jane, che come si può vedere sono attualmente illimitate (ancora, zero indica nessuna quota). Il limite inferiore (soft) è la quantità massima di spazio su disco che jane ha allocato per sé sul filesystem (in altre parole, la sua quota). Se jane usa più spazio su disco di quanto allocato nel proprio limite inferiore, sarà avvertita riguardo la sua violazione delle quote via e-mail. Il limite superiore (hard) indica il limite assoluto di spazio su disco, che un utente non può eccedere. Se jane prova ad usare più spazio su disco di quanto specificato nel limite superiore, riceverà un errore "Disk quota exceeded" (Quota su disco superata) e non avrà la possibilità di completare l'operazione. Adesso saranno cambiati i limiti inferiore e superiore per jane e quindi salvato il file:
Eseguendo il comando quota, è possibile ispezionare le modifiche fatte:
Non bisogna dimenticare di avere un altro utente, john, su questo filesystem. Se si vuole dare a john la stessa quota di jane, è possibile usare l'opzione -p per edquota, che usa la quota di jane come prototipo per tutti gli utenti seguenti su riga di comando. Questo è un modo facile di impostare quote per gruppi o utenti.
È anche possibile usare edquota per restringere l'allocazione dello spazio su disco basandosi sulla proprietà di gruppo dei file. Per esempio, per modificare le quote assegnate al gruppo users:
Quindi per vedere le quote modificare per il gruppo users:
Analizzare le quote per ogni utente usando il comando quota può essere tedioso se si hanno molti utenti su un filesystem. Il comando repquota effettua un riassunto delle quote per un filesystem in un gradevole rapporto. Per esempio, per vedere le quote per tutti gli utenti e gruppi su /usr/users:
Ci sono un paio di altre opzioni per repquota che bisogna citare. repquota -a tratterà tutti i filesystem attualmente montati in lettura-scrittura che hanno le quote abilitate. repquota -n non risolverà gli uid e i gid in nomi. Questo può accelerare il risultato per grandi liste. Se chi legge è un amministratore di sistema, potrebbe voler avere un modo per monitorare le quote così da assicurarsi che non vengano sorpassate. Una via semplice per farlo è l'uso di warnquota. Il comando warnquota invia e-mail agli utenti che hanno ecceduto i propri limiti inferiori. Di solito warnquota è eseguito da cron. Quando un utente supera il suo limite inferiore, la colonna grace (grazia) nel risultato del comando quota indica il periodo di grazia -- il tempo concesso prima che il limite inferiore sia reso effettivo per questo filesystem.
In modo predefinito, il periodo di grazia per blocchi e inode è di sette giorni. Modificare il periodo di grazia È possibile modificare il periodo di grazie per il filesystem usando edquota:
Questo mostra all'utente un editor di testo dove è presente un file temporaneo simile al seguente:
Il testo nel file è piacevolmente auto-esplicativo. Bisogna assicurarsi di lasciare agli utenti abbastanza tempo per ricevere la loro e-mail di avvertimento e trovare qualche file da cancellare. Controllare le quote all'avvio Qualcuno potrebbe anche voler controllare le proprie quote all'avvio. Lo si può fare usando uno script per eseguire il comando quotacheck; c'è uno script di esempio sul Quota Mini HOWTO. Il comando quotacheck ha anche la capacità di riparare file quota danneggiati; è utile familiarizzare con esso leggendo la pagina di manuale quotacheck(8). Bisogna ricordare anche cosa è stato detto in precedenza riguardo a quotaon e quotaoff. Si potrebbe incorporare quotaon nel proprio script di avvio così che le quote vengano abilitate. Per abilitare le quote su tutti i filesystem dove le quote sono supportate, usare l'opzione -a:
Il demone syslog fornisce un avanzato meccanismo client-server per registrare messaggi da parte di programmi in esecuzione sul sistema. Syslog riceve un messaggio da un demone o programma e lo classifica in base a priorità e tipo, quindi lo registra in accordo ad alcune regole configurabili dall'amministratore. Il risultato è un robusto e unificato approccio per gestire i log. Adesso bisogna scendere in dettaglio e guardare ai contenuti di un file di log registrato da syslog. In seguito, è possibile tornare indietro alla configurazione di syslog. Il FHS (vedere la Parte 2 di questa serie di brevi guide) impone che i file di log siano posizionati in /var/log. Di seguito sarà usato il comando tail per mostrare le ultime 10 linee nel file "messages":
Bisognerebbe ricordare dalla discussione sull'elaborazione del testo che il comando tail mostra le ultime linee in un file. in questo caso, è possibile vedere che il server di nomi named è stato recentemente avviato sul sistema, che è chiamato bilbo. Se si sta usando IPv6, si potrebbe notare che named non ha trovato alcuna interfaccia IPv6, il che indica un potenziale problema. In aggiunta, si può notare che un utente potrebbe avere di recente avviato GNOME, il che è indicato dalla presenza di gnome-name-server. Leggere la parte finale dei file di log Un amministratore si sistema con esperienza potrebbe usare tail -f per seguire il contenuto di un file di log in caso di necessità:
Per esempio, nel caso di analisi dell'ipotetico problema con IPv6, eseguire il comando sopra in un terminale mentre si arresta e si avvia named dovrebbe immediatamente mostrare i messaggi in arrivo dal demone. Questa può essere un'utile tecnica in fase di analisi. A molti amministratori spesso piace tenere costantemente in esecuzione tail -f su messages in un terminale così da poter dare un'occhiata sugli eventi di sistema. Un'altra utile tecnica è quella di cercare in un file di log usando lo strumento grep, descritto nella Parte 2 di questa serie di brevi guide. in questo caso, si potrebbe usare grep per cercare dove il comportamento di "named" è cambiato:
Di seguito sono riassunti i file di log tipicamente presenti in /var/log e mantenuti da syslog:
In effetti, questo potrebbe essere un buon momento per investigare il file di configurazione di syslog, /etc/syslog.conf. (Nota: se non è presente syslog.conf, continuare a leggere per amore dell'informazione, ma potrebbe essere in uso un demone syslog alternativo). Esplorando questo file, si nota che ci sono voci per ognuno dei file di log più comuni menzionati sopra, più forse qualche altra voce. Il file ha il formato abilità.priorità azione (facility.priority action), dove questi campi sono definiti come segue: Abilità: specifica il sotto sistema che produce il messaggio. Parole valide per questo campo sono auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp e da local0 fino a local7. Priorità: indica la severità minima del messaggio, il che significa che i messaggi con questa priorità e una maggiore saranno riscontrati da questa regola. Parole valide per questo campo sono debug, info, notice, warning, err, crit, alert, e emerg. Azione: il campo azione potrebbe essere sia un nome di file, un tty (come /dev/console), macchine remote con prefisso @, lista di utenti separati da virgole o indicazione di inviare un messaggio a chiunque sia presente sul sistema. L'azione più comune è un semplice nome di file. Ri-caricamento e informazioni aggiuntive Se tutto va bene questa panoramica del file di configurazione aiuterà il lettore a prendere conoscenza con il punto di forza del sistema syslog. Bisognerebbe leggere la pagina di manuale syslog.conf(5) per maggiori informazioni prima di fare modifiche. In aggiunta la pagina di manuale syslogd(8) fornisce molte informazioni dettagliate. Da notare che vi è la necessità di informare il demone syslog dei cambiamenti al file di configurazione per far si che abbiano effetto. Inviando un segnale SIGHUP si ottiene quanto detto ed è possibile usare il comando killall per farlo facilmente:
Bisognerebbe preoccuparsi che i file di log scritti da syslogd siano creati dal programma se questi non esistono. In relazione al proprio valore di umask impostato al momento, i file saranno creati leggibili da tutti. Se si ha a cuore la sicurezza, bisognerebbe usare chmod sui file per renderli di sola lettura-scrittura per l'utente root. Inoltre, il programma logrotate (descritto sotto) può essere configurato per creare nuovi file di log con i permessi appropriati. Il demone syslog mantiene sempre gli attributi correnti di un file di log esistente, quindi non bisogna preoccuparsi di lui una volta che il file è stato creato. I file di log in /var/log cresceranno col tempo con la possibilità potenzialmente di riempire il filesystem. È consigliabile usare un programma come logrotate per gestire l'archiviazione automatica dei log. Il programma logrotate di solito esegue come compito giornaliero di cron e può essere configurato per rotare, comprimere, rimuovere o inviare via mail i file di log. Per esempio, una configurazione predefinita di logrotate potrebbe ruotare i log settimanalmente, mantenendo 4 settimane intere di log arretrati (aggiungendo un numero di sequenza al nome del file) e comprimendo i log più datati per salvare spazio. In aggiunta, il programma può essere configurato per inviare un segnale SIGHUP a syslogd così che il demone noti i file di log vuoti e aggiunga in coda ad essi in modo appropriato. Per maggiori informazioni su logrotate, vedere la pagina di manuale logrotate(8), che contiene una descrizione del programma e la sintassi del file di configurazione. Prima di lasciare syslog, sarebbe interessante introdurre un paio di argomenti avanzati per i lettori più ambiziosi. Questi trucchi possono evitare molti dispiaceri nel tentativo di capire gli argomenti relativi a syslog. Primo, il demone syslog è al momento parte del pacchetto sysklogd, che contiene un secondo demone chiamato klogd. I demone klogd serve a ricevere informazioni e messaggi di errore dal kernel e quindi passarli a syslogd per la categorizzazione e registrazione. I messaggi ricevuti da klogd sono esattamente gli stessi che si possono recuperare usando il comando dmesg. La differenza è che dmesg stampa il contenuto corrente di un buffer circolare nel kernel, mentre klogd passa i messaggi a syslogd così che questi non vengano persi quando si torna all'inizio dell'anello. Argomento avanzato -- gestori di log alternativi Secondo, si sono alternative al pacchetto predefinito sysklogd. Le alternative mirano ad essere più efficienti, facili da configurare e possibilmente con più caratteristiche di sysklogd. Syslog-ng e Metalog sembrano essere alcune delle più popolari alternative: è possibile investigare su di esse se si ritiene che sysklogd non fornisca il livello di potenza necessario. Terzo, è possibile memorizzare messaggi nei propri script usando il comando logger. Vedere la pagina di manuale logger(1) per maggiori informazioni. Congratulazioni, è stato raggiunta la fine di questa breve guida. O quasi. Ci sono un paio di argomenti per cui non c'è stata la possibilità di essere inclusi in queste prime quattro brevi guide a causa di limiti sullo spazio. Fortunatamente, ci sono ancora un po' di buone risorse che potranno aiutare ad accelerare la comprensione di questi argomenti. Assicurarsi di coprire queste brevi guide particolari se si sta pianificando di conseguire la certificazione di livello 1 del LPIC. Non c'è quasi più spazio per coprire l'importante argomento dei backup di sistema in questa breve guida. Fortunatamente, IBM developerWorks già propone una breve guida sull'argomento, chiamata Backing up your Linux machines (Backup della propria macchina Linux). In questa introduzione, sarà spiegato come effettuare backup del sistema Linux usando una variante di tar chiamata star. Sarà anche discusso come usare il comando mt per controllare le funzioni di registrazione. Il secondo argomento di cui non c'è possibilità di discussione è la programmazione periodica. Fortunatamente, c'è della buona documentazione per cron disponibile all'Indiana University. cron è usato per programmare lavori da essere eseguiti ad un momento specifico e è un importante strumento per ogni amministratore di sistema. Nella prossima pagina, si possono trovare un numero di risorse che potranno tornare utili nell'apprendere di più riguardo gli argomenti presentati in questa breve guida. Per saperne di più sul supporto alle quote in Linux, assicurarsi di dare un'occhiata al Linux Quota mini-HOWTO. Inoltre assicurarsi di consultare le pagine di manuale quota(1), edquota(8), repquota(8), quotacheck(8) e quotaon(8) sul proprio sistema. Informazioni aggiuntive per il processo di avvio del sistema e sui boot loader possono essere trovate su:
Per apprendere ulteriori informazioni sui filesystem in Linux, leggere la guida avanzata in più parti per implementatori di filesystem sull'area di IBM developerWorks dedicata a Linux, che ricopre:
Per maggiori informazioni sul partizionamento, dare un'occhiata ai seguenti trucchi sul partizionamento nella zona dedicata a Linux sull'IBM developerWorks:
Risorse su ReiserFS:
Risorse su ext3:
Risorse su XFS e JFS:
Da non dimenticare anche linuxdoc.org. Si scoprirà che le collezioni di guide, HOWTO, FAQ e pagine di manuale di linuxdoc sono inestimabili. Assicurarsi di controllare anche la Linux Gazette e LinuxFocus. La Guida per Amministratori di Sistema Linux, disponibile nella sezione "Guides" (Guide) di Linuxdoc.org, è un buon complemento a questa serie di brevi guide -- dargli un'occhiata. Potrebbe essere utile anche il Unix and Internet Fundamentals HOWTO (HOWTO sulle basi di Unix e Internet) di Eric S. Raymond. Nella serie di articoli Bash tramite esempi su developerWorks, Daniel mostra come usare i costrutti della programmazione bash per scrivere i propri script. Questa serie su bash (in particolare la Parte 1 e 2) sarà una eccellente preparazione ulteriore per l'esame LPIC Level 1:
È fortemente raccomandato FAQ tecniche da parte di utenti Linux di Mark Chapman, una lista approfondita di 50 pagine su domande poste di frequente in merito a Linux, corredate di risposte dettagliate. Le FAQ sono in formato PDF (Adobe Acrobat). Per chi fosse un utente principiante o intermedi di Linux, dare un'occhiata a queste FAQ rappresenta una cosa da fare. Inoltre è raccomandato anche il Glossario su Linux per utenti Linux, anch'esso da parte di Mark. Per chi non fosse familiare con l'editor vi, è fortemente raccomandato di dare uno sguardo alla Introduzione a Vi -- bignami di Daniel. Questa breve guida fornisce una leggera ma coinvolgente introduzione a questo potente editor di testo. Considerare questo materiale come una lettura obbligatoria se non si sa come usare vi. Si prega di mandare ogni commento riguardo questa breve guida agli autori:
|
|
