4 slide per pagina

Le workstation
Manuale di Laboratorio
Laboratorio di Amministrazione di
Sistemi - a.a. 2006/2007
Amministrazione e macchine
• Molte delle attività che svolgeremo
– richiedono i privilegi di amministratore
• modifica di permessi, invio di segnali, uso di funzioni
di rete riservate, manipolazione dei filesystem, ...
– possono di conseguenza causare danni
• cancellazione di file di sistema, modifica di file di
configurazione, ...
– non sono quindi attuabili su macchine la cui
stabilità deve essere garantita
• Le stazioni di lavoro del laboratorio
possono essere utilizzate in modalità Linux
o Windows, scegliendo al boot
• Utilizzeremo sempre Linux
• Le modalità di login sono descritte nel
materiale disponibile in laboratorio
• RICORDATE DI SPEGNERE LE
MACCHINE AL TERMINE DELL'USO
Virtualizzazione
• Sistemi come VMware, Xen, Qemu, UML, KVM lanciati
come una normale applicazione in un sistema (host )
emulano il funzionamento di un PC (o altro hardware), e
permettono quindi l'esecuzione di un altro S.O. (guest )
• Utilizzeremo Qemu per lanciare macchine virtuali su cui
lavorare con pieni privilegi
– libertà d'azione
– facilità di ripristino
Qemu
• Qemu è un progetto di Fabrice Bellard rilasciato opensource sotto licenza GPL
• Software e documentazione sono disponibili sul sito
dell'autore
http://fabrice.bellard.free.fr/qemu/
• L'avvio di Qemu con le (numerose) giuste opzioni è
facilitato da uno script predisposto appositamente
File immagine
• È possibile inizializzare un numero arbitrario di file "diff"
diversi, tutti basati sulla stessa immagine di riferimento
– persistenza delle modifiche apportate singolarmente a
diverse macchine virtuali, anche più d'una per studente
– spazio occupato molto contenuto
• Se cambia l'immagine di riferimento i "diff" diventano
inutilizzabili (vedere più avanti come cancellarli)
File immagine
• L'immagine binaria dell'intero disco
visto dal sistema operativo guest è
condensata in un singolo file
• Replicare tale file per ogni macchina
virtuale di ogni studente è impossibile
per vincoli di spazio
Accesso
ai file
Diff img.
(Read-Write)
Base img.
• Qemu consente una soluzione molto
efficace per mezzo di file "differenza"
(Read Only)
Script di avvio
• Lanciando
/opt/qemu/goqemu.sh [parametro]
non solo si avvia Qemu ma si gestisce anche in modo
ottimale l'immagine "diff"; lo script infatti:
– copia la versione compressa del file "diff" dalla home
dell'utente alla /tmp locale
– al termine della sessione di lavoro esegue una copia di
backup del file diff originale
– comprime il file "diff" utilizzato e lo copia nella home
– attenzione alla quota disco!
Script di avvio
• Il parametro può essere
– un numero N compreso tra 1 e 9, per avviare diverse
macchine linux
– la stringa "win" per avviare una (sola) macchina windows (in
via di implementazione)
• Precauzioni:
– non avviare due macchine con lo stesso numero
– attendere il completo avvio di una prima di avviarne un'altra
• Nota: Qemu viene eseguito in una finestra del sistema grafico
dell'host. Cliccando sulla finestra tutti i sistemi di input vengono
"catturati" da Qemu, per "liberarli" premere CTRL+ALT
Login e logout
• Sulle macchine virtuali sono definiti
– un account standard che all'occorrenza può eseguire
comandi come super-utente
• utente admin, password admin
– il super-utente vero e proprio
• utente root, password gennaio.marzo
• Benchè virtuali, le macchine devono essere spente
correttamente per evitare corruzioni del file "diff" dovute al
buffering
– comando halt, il primo esempio di operazione ristretta
Script e file diff
• Nel caso un crash di sistema o altri problemi corrompano
l'immagine della MV, e quindi questa non si avvii più
correttamente, è possibile semplicemente eliminare i file
diff per ripristinare la situazione di partenza:
– linux.diff-N.tgz
nella propria home
– linux.diff-N
in /tmp
• Se la sessione di lavoro precedente a quella che ha
creato il problema era invece terminata correttamente, è
possibile recuperare il backup
– rinominare linux.diff-N.tgz.bak in linux.diff-N.tgz
Uso degli account
• Anche quando si lavora come sysadm, la quantità di
operazioni da svolgere coi privilegi di root è molto limitata
– è fortemente consigliabile utilizzare sempre l'account
standard, che anche in caso di errori può provocare danni
molto limitati
– esistono modi diversi per operare come root all'occorrenza
• comando su (switch user) permette di "diventare" l'utente
specificato come parametro, a patto di conoscerne la password
• comando sudo (super-user do) permette di eseguire un singolo
comando come root, se abilitati, senza conoscerne la password
Organizzazione
Architettura di rete
• È utile disporre di diversi terminali per ogni macchina
– digitando xterm & in una macchina virtuale si aprirà un suo
terminale sullo schermo dell'host
– se il sistema lamenta di non poter accedere al server X,
digitare il comando xhost + localhost sull'host
• Alcune esercitazioni prevedono l'uso contemporaneo di
diverse macchine virtuali (es. per svolgere in una rete i
ruoli di client - router - server)
– affollamento e confusione del desktop host
– suggerimento: lanciare macchine virtuali diverse su desktop
virtuali diversi dell'host
• In ogni macchina virtuale sono disponibili quattro interfacce
di rete:
– eth0
( indirizzo 10.0.2.2N )
• dà accesso ad una serie di macchine emulate da Qemu:
– router e host all'indirizzo 10.0.2.2
– dns all'indirizzo 10.0.2.3
– eth1
( indirizzo 172.20.2.N )
• utilizzabile per connettere le diverse macchine virtuali tra di loro
– eth2 ed eth3 funzionano come eth1 ma non sono configurate
di default. Le ethN di tutte le macchine virtuali lanciate su di
un host sono logicamente sulla vlan N
Architettura di rete
Esempio d'utilizzo
Vista dell'HOST offerta da Qemu - 10.0.2.2
Vista dell'HOST offerta da Qemu - 10.0.2.2
eth0 - 10.0.2.21
eth0 - 10.0.2.22
eth0 - 10.0.2.23
eth0 - 10.0.2.21
MV1
MV2
MV3
Client
eth1 eth2 eth3
eth1 eth2 eth3
eth1 eth2 eth3
10.1.1.1
eth1 eth2 eth3
eth0 - 10.0.2.22
VLAN3
10.9.9.1
Server
10.9.9.254
Router
10.1.1.254
eth1 eth2 eth3
VLAN1
VLAN2
eth0 - 10.0.2.23
eth1 eth2 eth3
VLAN1 (non usata)
VLAN2
non configurate
VLAN3
Gestione dei file
• Qemu, come qualsiasi software, non è privo di bug
– sconsigliabile fare affidamento esclusivamente sui file "diff"
come storage persistente
• Le macchine virtuali
– non hanno accesso a tutto ciò che è visibile dall'host, ad
esempio ai dispositivi USB
– non dispongono di browser web (indispensabili in sede
d'esame per la consegna dei file testati sulle MV)
– non dispongono di editor grafici, solo di vi
Indispensabile trasferire file da host a MV e viceversa
Esempi di scp
• Si è loggati sull'host come utente x0123456
• Si sta operando nella MV come utente admin
1) Si vuole copiare il file prova.txt dalla directory corrente della
MV alla propria home sull'host
scp prova.txt [email protected]:
[inserire la password di x0123456]
2) Si vuole copiare il file work.sh dalla directory test presente
sotto la propria home sull'host nella directory corrente della
MV
scp [email protected]:test/work.sh .
Gestione dei file
• Il trasferimento deve essere sempre pilotato dalla MV,
poichè l'host non ha modo di contattare le MV
• Si utilizza il comando scp (secure copy), che utilizza il
diffusissimo protocollo di comunicazione sicura ssh
– da MV a host:
scp sorgente_locale username@host:destinazione_remota
– da host a MV
scp username@host:sorgente_remota destinazione_locale
– in ogni caso chiederà la vostra password per autenticarvi
sull'host (impareremo ad automatizzare il passaggio)
– ricordate che da ogni MV l'host è visibile come 10.0.2.2
Esempi di scp
• Naturalmente scp può trasferire file anche tra macchine
virtuali diverse, ricordando che per la connessione tra MV
non si usa eth0 ma eth1, che ha indirizzo 172.20.2.N
1) Si sta operando come admin sulla MV1 e si vuole copiare il file
prova.txt dalla directory corrente alla home dell'utente root sulla MV2
scp prova.txt [email protected]:
[inserire la password dell'utente root della MV2]
2) Si sta operando come admin sulla MV1 e si vuole copiare il file
cmd.sh dalla home dell'utente admin sulla MV2 alla dir. corrente.
Quando l'utente sulla macchina remota coincide con quello che
lancia scp, si può omettere "username@"
scp 172.20.2.2:cmd.sh .
[inserire la password dell'utente admin della MV2]