[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Nel momento dell'imprevisto si può agire solo se si è stati previdenti, pensando ai tipi di situazioni che si possono presentare e preparando gli strumenti necessari in anticipo. Le copie di sicurezza sono la prima cosa da fare per prepararsi ai guai, ma da sole non bastano: occorrono altri strumenti per rimettere in sesto un sistema prima di poter effettuare un eventuale recupero dalle copie.
Di fronte a un problema qualunque di una gravità tale da non permettere l'avvio di un sistema locale, l'unica possibilità di intervenire è data da strumenti su dischetti. Esistono diversi tipi di dischetti che possono essere stati preparati in precedenza:
dischetti di avvio;
dischetti di installazione della distribuzione GNU/Linux;
dischetti preparati appositamente.
Un dischetto di avvio può essere utile quando, per qualche motivo, il metodo normale di caricamento del sistema operativo non funziona più. Esistono almeno tre tipi di dischetti di questo tipo:
La prima soluzione, quella del dischetto senza kernel, non è adatta per avviare un sistema in difficoltà: è solo un modo per verificare una configurazione di LILO quando non si vuole interferire con l'MBR del disco fisso. In pratica si ottiene semplicemente indicando nel file /etc/lilo.conf la riga boot=/dev/fd0, come nell'esempio seguente:
boot=/dev/fd0
prompt
timeout=50
image=/boot/vmlinuz
label=linux
root=/dev/hda2
read-only
Quando viene avviato l'eseguibile lilo con questa configurazione, si ottiene la scrittura del primo settore del primo dischetto (il dischetto deve essere stato inizializzato in precedenza e può anche non contenere alcun file system). Ma in questo modo si intende che i file per il caricamento del sistema si devono trovare nella directory /boot/ del momento in cui si esegue lilo, ovvero nel file system in funzione in quel momento e non nel dischetto. Inoltre, anche il kernel /boot/vmlinuz si intende contenuto in quel file system e non nel dischetto.
Quando si avvia con un dischetto fatto in questo modo, il programma contenuto nel primo settore va alla ricerca del kernel e degli altri file, necessari per il caricamento del sistema, nel disco fisso nel momento dell'utilizzo di LILO. Se il sistema non si avvia perché questi file o il kernel sono stati spostati, a nulla serve un dischetto fatto in questo modo.
Per fare in modo che il dischetto avvii un kernel contenuto al suo interno, è necessario che questo dischetto contenga un file system, che vi sia stata copiata la directory /boot/ con il suo contenuto, la directory /etc/ con il file lilo.conf e che sia stata riprodotta la directory /dev/ con il file di dispositivo fd0 (assieme agli altri file di dispositivo necessari a individuare i dischi o le partizioni a cui si vuole fare riferimento). Quindi è sufficiente eseguire lilo con l'opzione -r, come descritto nella sezione 18.4.
|
Esiste anche la possibilità di usare SYSLINUX, che permette di realizzare un dischetto con le stesse caratteristiche e con meno difficoltà. SYSLINUX è descritto nel capitolo 16. |
Rispetto alla prossima tecnica, un dischetto contenente LILO e il kernel, come appena descritto, è uno strumento di avvio più completo perché permette di specificare, sia attraverso la configurazione del file /etc/lilo.conf che per mezzo del cosiddetto bootprompt, alcuni parametri di avvio particolari del quale il proprio sistema potrebbe avere bisogno.
L'ultima possibilità è la più semplice e, sotto questo aspetto, anche la più sicura: il file del kernel viene copiato sul dispositivo del dischetto, senza fare uso di alcun file system. Si può utilizzare uno dei due modi seguenti.
# cp vmlinuz /dev/fd0
# dd if=vmlinuz of=/dev/fd0
Evidentemente, il file del kernel è speciale perché riesce ad avviare se stesso. Il kernel da solo, però, potrebbe non sapere quale dispositivo contiene il file system principale da montare al momento dell'avvio. È necessario utilizzare il programma rdev per inserire questa e altre notizie nel kernel.
Supponendo che si debba avviare la partizione /dev/hda2, inizialmente in sola lettura, si procede come segue per fare queste annotazioni in un kernel copiato in un dispositivo /dev/fd0:
# rdev /dev/fd0 /dev/hda2
# rdev -R /dev/fd0 1
La maggior parte delle distribuzioni GNU/Linux predispone dei dischetti di emergenza che consentono generalmente di accedere al disco fisso e di fare delle piccole riparazioni.
Tra tutti, i dischetti più rudimentali sono quelli della distribuzione Slackware. La loro semplicità è da considerare un pregio, dal momento che utilizzandoli ci si trova di fronte un sistema GNU/Linux più o meno tradizionale, senza ottimizzazioni particolari.
Ogni sistema ha le proprie caratteristiche ed esigenze. I dischetti di emergenza preparati da altri, oppure ottenuti da una distribuzione GNU/Linux, possono adattarsi a un certo insieme di situazioni, ma non a tutte.
Quando si vuole essere sicuri di avere gli strumenti giusti al momento giusto, occorre che questi siano stati preparati e collaudati bene, in modo da non sprecare tempo inutilmente. In sostanza, la realizzazione o la personalizzazione di dischetti di emergenza è una tappa importante per chi vuole amministrare seriamente il proprio sistema.
L'utilizzo di dischetti di emergenza preparati da altri è un buon punto di partenza, ma le particolarità che ogni sistema può avere consigliano almeno una personalizzazione del kernel.
Per poter costruire o almeno personalizzare dei dischetti di emergenza è particolarmente utile attivare nel kernel la gestione diretta delle immagini di questi (sezione 29.2.7).
In questo modo, un'immagine non compressa di un dischetto può essere montata con un comando simile a quello seguente:
mount -o loop -t tipo_di_file_system file_immagine punto_di_innesto
Il file system principale può essere caricato in memoria centrale (RAM) e montato da lì. Si ottiene un cosiddetto disco RAM. A parte ogni considerazione sui vantaggi che questo può avere nelle prestazioni del sistema, si tratta di una modalità quasi obbligata per l'utilizzo di dischetti di emergenza. Infatti, un disco RAM può essere ottenuto a partire da un'immagine compressa: è il kernel stesso che la espande in memoria all'atto del caricamento. Quindi, si può fare stare in un dischetto un'immagine di dimensioni superiori alla sua capacità.
Oltre a questo vantaggio, che però richiede la presenza di molta memoria RAM, un dischetto contenente un file system che è stato trasferito nella RAM, può essere rimosso subito dopo il suo caricamento, permettendo il riutilizzo dell'unità a dischetti, magari per accedere ad altri programmi di servizio non inclusi nel disco RAM.
Per la gestione di un disco RAM occorre che il kernel sia configurato appositamente (29.2.7).
Quando il kernel carica un disco RAM da un'immagine contenuta in un dischetto, deve conoscere la posizione di inizio di questa immagine. Ciò è importante quando sia il kernel che l'immagine da caricare risiedono nello stesso dischetto. Quando l'immagine da caricare nel disco RAM è contenuta in un dischetto separato, questa si troverà normalmente a partire dall'inizio di questo, cioè da uno scostamento pari a zero.
I dischetti della distribuzione Slackware sono i più semplici ed efficaci in situazioni di emergenza. Per essere avviati necessitano di un dischetto di avvio (boot) contenente il kernel, ma questo può essere eventualmente predisposto localmente in modo da avere a disposizione la configurazione più adatta al proprio sistema. Questi dischetti sono reperibili normalmente presso gli indirizzi seguenti:
<http://www.ibiblio.org/pub/Linux/distributions/slackware/rootdsks/>
<http://www.ibiblio.org/pub/Linux/distributions/slackware/bootdsks.144/>
Il dischetto migliore per la soluzione di problemi è rappresentato dall'immagine compressa rescue.gz. Se si intende utilizzare anche un dischetto di avvio ottenuto dalla distribuzione, occorre sceglierlo in base alle indicazioni che si trovano nei file di testo inclusi nelle directory indicate.
L'immagine rootdsks/rescue.gz è compressa e contiene in pratica un disco in formato Ext2 di qualche mebibyte (simbolo: Mibyte). Questo implica che per poterne fare uso occorre molta memoria RAM.
|
Se si intende utilizzare l'immagine |
Come già accennato, la distribuzione Slackware mette a disposizione immagini di dischetti di avvio, contenenti essenzialmente il kernel, assieme a immagini di dischetti contenenti il file system principale (root).
Le immagini per l'avvio rappresentano dischetti con un file system normale, contenente un settore di avvio, la directory /boot/ e il kernel. Si tratta in pratica di dischetti realizzati in modo analogo a quanto descritto in precedenza nella sezione 347.1.1, quando si faceva riferimento a dischetti contenenti questi elementi. Le immagini dei dischetti di avvio, anche se non sono di dimensioni pari a quelle di un dischetto normale, non dovrebbero essere compresse e si possono copiare semplicemente sul dispositivo del dischetto di destinazione.
# dd if=net.i of=/dev/fd0
Le immagini dei dischetti contenenti il sistema minimo (root), sono invece dischetti di qualche mebibyte, compressi in modo da poter essere collocati all'interno di un dischetto da 1 440 Kibyte, costringendo però all'uso di un disco RAM.
Per abbinare un kernel personalizzato a un dischetto contenente il sistema minimo della distribuzione Slackware, si potrebbe ricostruire un dischetto di avvio seguendo le stesse modalità usate dalla distribuzione stessa, oppure in maniera più semplice, copiando il kernel in un dischetto direttamente attraverso il suo dispositivo e poi intervenendo con il programma rdev. Viene descritta l'ultima di queste modalità.
# dd if=zImage of=/dev/fd0
La copia di un kernel in un dischetto, attraverso il suo dispositivo, genera il solito dischetto di avviamento già descritto tante volte. Questo kernel su dischetto deve però essere informato di dove e come fare il caricamento del sistema. Il file system principale viene caricato da un dischetto, quindi si scrive questo messaggio nel kernel attraverso rdev.
# rdev /dev/fd0 /dev/fd0
I dischetti contenenti il sistema minimo della distribuzione Slackware non prevedono il controllo del file system e il successivo montaggio in lettura e scrittura. In pratica, il file system principale deve essere montato inizialmente in lettura-scrittura.
# rdev -R /dev/fd0 0
Infine si deve specificare che:
l'immagine del dischetto contenente il sistema (compressa o meno che sia) si trova in un dischetto separato e parte dalla posizione iniziale: lo scostamento è pari a zero;
si vuole, oppure non si vuole, che tale dischetto sia caricato in un disco RAM;
si vuole un preavviso per sapere quando si può togliere il dischetto del kernel per inserire il dischetto contenente il sistema.
Per fare questo si agisce su una serie di bit configurabili attraverso rdev con l'opzione -r:
i primi 11 (dal bit 0 al bit 10) permettono di definire l'indirizzo dello scostamento (in blocchi di 1 024 byte);
il bit 15 indica che si vuole avere una pausa per lo scambio dei dischetti.
Se si vuole caricare il file system principale in un disco RAM si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 49152
infatti, 215 + 214 + 0 = 49 152.
Se invece non si vuole il disco RAM si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 32768
infatti, 215 + 0 + 0 = 32 768.
Quando si configura un kernel da utilizzare assieme a dischetti di emergenza, occorre tenere presente che non è ragionevolmente possibile utilizzare i moduli ed è importante attivare determinate caratteristiche che di solito non vengono considerate per i sistemi normali.
I dischetti di emergenza obsoleti sono nel vecchio formato a.out. Il kernel deve essere stato predisposto per gestirli.
Kernel support for a.out binaries
Il file system più utilizzato in passato per i dischetti di emergenza, specialmente quando questi dovevano essere di dimensioni minime, è Minix. Anche se adesso i dischetti di emergenza che si trovano in circolazione sono prevalentemente in formato Ext2, conviene includere la gestione di questo vecchio tipo di formato.
Minix fs support
Anche se non si intendono utilizzare dischetti caricati in memoria RAM, vale la pena di preparare un kernel che ne permetta comunque l'utilizzo.
RAM disk support
Porta parallela PLIP.
Un kernel per un dischetto di emergenza deve permettere la gestione della rete (TCP/IP) e, in particolare, invece di attivare la gestione della porta parallela per la stampa, conviene attivare la gestione della connessione PLIP.
PLIP (parallel port) support
Quando si usano dei dischetti di emergenza si hanno già molte limitazioni e a queste si aggiunge anche la scomodità di una tastiera che non combacia con quella USA.
Si può risolvere il problema direttamente nel kernel senza dover tentare di inserire il programma loadkeys in dischetti già troppo piccoli. È sufficiente trovare il file della mappa della tastiera italiana (di solito si tratta del file it.kmap collocato nella directory /usr/share/keymaps/piattaforma/qwerty/) e quindi generare il sorgente defkeymap.c. Si procede come segue, nel caso si utilizzi la piattaforma i386.
# cd /usr/src/linux/drivers/char
# loadkeys --mktable /usr/share/keymaps/i386/qwerty/it.kmap <-'
`->> defkeymap.c
La compilazione successiva di un nuovo kernel utilizzerà la mappa italiana come predefinita e non ci sarà bisogno di utilizzare loadkeys.
Quando si ha la disponibilità di più elaboratori, è probabile che il danno presentatosi su uno di questi non si sia riprodotto in tutti. Una piccola rete locale potrebbe essere di aiuto in situazioni di emergenza e in sua mancanza potrebbero andare bene anche dei cavi paralleli PLIP. Questo tipo di cavo viene descritto nella parte xciv. La sua realizzazione non è difficile: basta un piccolo saldatore, un po' di stagno, due connettori maschi DB-25 e una piattina multipolare con almeno 13 fili. La schermatura non è necessaria.
Con i dischetti della distribuzione Slackware, preferibilmente con l'immagine resque.gz, è possibile stabilire una semplice connessione con un servente NFS.
Attraverso una connessione Ethernet, con un'interfaccia riconosciuta come eth0, si può agire come nell'esempio seguente. Si suppone in particolare che l'indirizzo di rete sia 192.168.1.0, che la maschera di rete sia 255.255.255.0 e di poter utilizzare l'indirizzo IP 192.168.1.17 per l'elaboratore avviato con i dischetti di emergenza.
# ifconfig eth0 192.168.1.17 netmask 255.255.255.0
# route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
Per verificare la connessione si può fare un ping verso l'elaboratore da raggiungere: potrebbe trattarsi dell'indirizzo 192.168.1.1.
# ping 192.168.1.1
Se tutto è andato bene si può procedere. Si suppone che l'elaboratore 192.168.1.1 metta a disposizione il suo file system a partire dalla directory radice.
# mount -t nfs 192.168.1.1:/ /mnt
Nel caso di una connessione PLIP, la procedura è un po' differente. In particolare bisogna ricordare che l'elaboratore dal quale si vogliono attingere i dati attraverso il protocollo NFS, deve avere un kernel compilato in modo da gestire questo tipo di connessione.
Si fa riferimento allo stesso esempio riportato nella sezione precedente. L'unica differenza sta nell'interfaccia usata per la comunicazione: si suppone che sia stata riconosciuta la plip1 da entrambi i lati.
Il procedimento di connessione va fatto da entrambi i capi, infatti, raramente un elaboratore ha una connessione PLIP stabile, per cui non si trova ad avere un indirizzo e una tabella di instradamento già pronti.
Dal lato dell'elaboratore avviato con i dischetti si procede come segue:
rescue# ifconfig plip1 192.168.1.17 pointopoint 192.168.1.1
rescue# route add -host 192.168.1.17 dev plip1
rescue# route add -host 192.168.1.1 dev plip1
Dal lato dell'elaboratore servente si effettua l'operazione inversa.
server# ifconfig plip1 192.168.1.1 pointopoint 192.168.1.17
server# route add -host 192.168.1.1 dev plip1
server# route add -host 192.168.1.17 dev plip1
Per verificare la connessione si può fare un ping.
rescue# ping 192.168.1.1
Se tutto è andato bene si può procedere montando il file system di rete.
rescue# mount -t nfs 192.168.1.1:/ /mnt
Il dischetto di emergenza ha bisogno di un altro punto di innesto per accedere a un disco fisso locale. È sufficiente creare un'altra directory.
Quando si accede a un servente NFS e non è possibile farlo mantenendo i privilegi dell'utente root, una semplice copia attraverso cp -dpR non dà un risultato garantito: alcuni file potrebbero risultare inaccessibili in lettura. La cosa si risolve facilmente impacchettando quello che serve nell'elaboratore di origine e dando a questo archivio tutti i permessi necessari.
Quando si utilizza un sistema operativo minimo, avviato attraverso dischetti di emergenza, per recuperare i dati da uno o più archivi, occorre fare mente locale al problema dell'abbinamento utenti/gruppi, UID/GID.
Trattandosi di un sistema minimo, conterrà alcuni nomi di utenti e di gruppi, presumibilmente non «umani», ma comunque esistenti. Solitamente, questi nomi di utenti e di gruppi sono standardizzati, tuttavia il loro abbinamento con numeri UID/GID non è sempre uniforme. A questo punto, se si recuperano i dati di un sistema in cui questi nomi non corrispondono esattamente, si rischia di riprodurre una copia differente, che non sarà valida quando il sistema normale sarà ripristinato.
Se non ci sono alternative, si può accettare l'inconveniente, riavviare il sistema rigenerato e ripetere il recupero. In questo modo, i file verranno sovrascritti e le proprietà saranno abbinate in base ai nuovi file /etc/passwd e /etc/group.
|
In generale, proprio per questo problema, sarebbe opportuno che il dischetto di emergenza contenesse esclusivamente l'indicazione dell'utente e del gruppo root, eliminando qualunque altro tipo di utente di sistema. |
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome emergenza_con_gnu_linux.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]