Microsoft's Internet Explorer browser has no built-in vector graphics machinery required for "loss-free" gradient background themes.
Please upgrade to a better browser such as Firefox, Opera, Safari or others with built-in vector graphics machinery and much more. (Learn more or post questions or comments at the Slide Show (S9) project site. Thanks!)
Il System Administrator di un sistema ha in genere delle esigenze molto diverse da quelle dell’utente di un sistema Desktop.
Sebbene molte delle tecnologie alla base sono le stesse (in altre parole server e client GNU/Linux hanno in comune un analogo core ) le diverse esigenze spesso impongono un diverso workflow e l’uso di tool di amministrazione di sistema diversi da quelli grafici destinati agli utenti desktop.
Il sysadmin deve poter controllare con precisione quali servizi devono essere attivi nel sistema e quali no, sapere quali file di configurazione o dati sono necessari alle applicazioni installate.
Il sysadmin ha la necessità di poter decidere con precisione cosa utilizzare, potendo eliminare ciò che non è necessario (o che potrebbe essere dannoso) e aggiungere ciò che si rende necessario per fornire i servizi richiesti, correggere un problema segnalato, supportare una nuova periferica, etc. etc.
Il syadmin deve poter riprodurre più volte i risultati ottenuti, possibilmente senza dover ripetere tutti i passi intermedi rivelatisi necessari la prima volta. Spesso infatti i server amministrati da un sysadmin non sono tutti eterogenei tra di loro, ma hanno sempre molte caratteristiche comuni. Inoltre una volta messo online un servizio si deve essere in grado di sostituirlo in qualsiasi momento e il più velocemente possibile.
La scelta del Sistema Operativo (o la particolare Distribuzione GNU/Linux) da utilizzare deve derivare da diverse valutazioni:
Per definire lo schema di partizionamento del sistema occorre tenere conto:
In un tipico sistema ad accesso multiutente, ad esempio, sarà
opportuno tenere separate partizioni come /usr
, /var
, /tmp
,
/home
, o /srv
.
In un sistema dove l’accesso al disco è frequente sarà opportuno
creare partizioni ext3
piuttosto che ext2
(il realtà al giorno d’oggi
l’uso di ext2
è ancora presente in scenari dove il supporto è in sola lettura,
come i sistemi embedded).
Altri filesystem sono da prendere in considerazione in caso di requisiti
particolari in termini di caratteristiche di accesso e storage dei dati.
Le dimensioni delle partizioni devono essere proporzionate alle dimensioni dei supporti. E lo spazio dovrà essere ripartito coerentemente alle esigenze dei vari mount point.
Una regola empirica (ma molto diffusa) è quella di creare partizioni di swap di dimensioni pari a circa il doppio della memoria RAM disponibile.
Le precedenti valutazione porteranno poi a definire lo schema di partizionamento in termini di:
Lo scopo del partizionamento è quello di utilizzare lo spazio disponibile con maggiore criterio, in modo da:
La procedura di installazione di un sistema operativo si presenta (indipendentemente dai sistemi operativi e tool utilizzati) sempre come la sequenza (manuale o automatica) delle seguenti fasi:
Oltre ai supporti di installazione dotati di interfaccia grafica, esistono molto spesso le distribuzioni GNU/Linux forniscono ulteriori possibilità:
Tutte le soluzioni automatizzate ci porteranno sino al passo di riavvio lasciando a noi il compito di effettuare l’installazione e configurazione dei servizi aggiuntivi, così come il compito di salvare un template del sistema ottenuto.
Di solito le soluzioni automatizzate non consentono l’installazione di sistemi “template”, o comunque lo consentono solo attraverso complicate procedure di preparazione.
I motivi che portano a scegliere sistemi di installazione alternativi all’installer grafico e/o automatizzato sono:
Un LiveCD molto leggero e maneggevole, sufficientemente versatile da poter essere utile in fase di installazione, recupero dati, cloning etc. è RIPLinux
Essendo basato su Slackware presenta un sistema di pacchetti molto semplice basato su pacchetti tgz.
Debootstrap è un tool Debian (quindi ereditato da tutte le distribuzioni Debian-based, in particolare Ubuntu) che consente di installare un sistema minimo totalmente via rete.
Debootstrap è basato esclusivamente su bash , wget , ar e tar e per questo motivo è in grado di funzionare da un qualsiasi sisteam *nix-like.
# debootstrap RELEASE ./local-chroot [http://server.org/path] I: Retrieving Release I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://server.org/path... I: Retrieving adduser I: Validating adduser I: Retrieving apt [...] I: Configuring libc6... I: Configuring initramfs-tools... I: Base system installed successfully. #
Dopo l’installazione del sistema base è necessario effettuare alcune post-configurazioni:
sudo chroot /mnt/mychroot
apt-get install linux-image-server
echo “mytesthostname” > /etc/hostname
proc /proc proc defaults 0 0 /dev/hda1 / ext3 defaults,errors=remount-ro 0 1 #/dev/hda2 none swap sw 0 0
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp iface eth0 inet static address 192.168.0.5 netmask 255.255.255.0 gateway 192.168.0.1
nameserver 192.168.1.2 search inland
All’interno della chroot sarà necessario effettuare l’installazione del bootloader (in genere grub):
# apt-get install grub [...] # update-grub [...] # cp /usr/lib/grub/i386-pc/* /boot/grub/ [...]
Dopo essere usciti dalla chroot è possibile installare il bootloader nell’MBR:
# grub > root (hd0,0) > setup (hd0) [...] > quit
Durante il riavvio si potrebbero presentare i primi problemi:
In caso di difficoltà con l’avvio del bootloader è consigliabile provare a reinstallare il bootloader in maniera corretta o nel caso in cui venga identificato un codice di errore verificarne il significato sulla manualistica del bootloader o sulle risorse presenti in rete.
In caso di difficoltà con il kernel è invece utile (avendo a disposizione un bootloader come GRUB) entrare nel menù di controllo ed eliminare i parametri quite e splash allo scopo di avere maggiori log su cui basare una diagnosi del problema. La console di GRUB consente inoltre di provare a riconfigurare completamente la voce di boot nel caso in cui il problema sia riconducibile ad un problema di configurazione di GRUB.
QEMU è un semplice quanto emulatore libero, è in grado di emulare diverse architetture (x86, ARM, MIPS, etc.) e per questo motivo è molto utilizzato negli ambiti legati allo sviluppo di software per sistemi embedded.
Nel nostro caso ci sarà di aiuto per il testing dell’installazione base effettuata:
### sulla macchina ospite è utile abilitare l'ip forward ### ed effettuare il MASQUERADING del traffico in uscita ### sull'interfaccia eth1 ### per effettuare il routing del traffico generato dalla macchina virtuale rpl@ubik:~$ sudo su root@ubik:~$ echo 1 > /proc/sys/net/ipv4/ip_forward root@ubik:~$ iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE rpl@ubik:~$ sudo qemu -hda /dev/sdb -net nic -net tap
L’interfaccia di rete della macchina ospite (di solito tap0) e quella della macchina della macchina virtuale (di solito eth0) devono essere configurate opportunamente:
### MACCHINA OSPITE ifconfig tap0 tap0 Link encap:Ethernet HWaddr ba:be:f3:e5:42:3f inet addr:172.20.0.1 Bcast:172.20.255.255 Mask:255.255.0.0 ### MACCHINA VIRTUALE ifconfig eth0 172.20.0.5 netmask 255.255.0.0 route add default gw 172.20.0.1 echo "nameserver YOUR.ROUTER.IP.ADDRESS" > /etc/resolv.conf ping -c 1 172.20.0.1 ping -c 1 YOUR.ROUTER.IP.ADDRESS ping -c 1 google.com
Completato il riavvio del sistema con successo, è il momento di aggiungere gli ulteriori servizi che il nuovo server dovrà fornire.
Ogni Sistema Operativo / Distribuzione fornisce un proprio insieme di tool allo scopo di consentire una gestione dei pacchetti il più semplice possibile.
Sui sistemi derivati da Debian tale toolset è composto dall’accoppiata dpkg / apt , attraverso i seguenti comandi comuni :
apt-cache apt-get dpkg aptitude
La lista dei repository di pacchetti è controllata dal file /etc/apt/sources.list e dai file /etc/apt/sources.list.d/REPONAME.list
deb http://it.archive.ubuntu.com/ubuntu intrepid main universe restricted multiverse deb http://it.archive.ubuntu.com/ubuntu intrepid-backports main universe restricted multiverse deb http://it.archive.ubuntu.com/ubuntu intrepid-updates main universe restricted multiverse deb-src http://it.archive.ubuntu.com/ubuntu intrepid main universe restricted multiverse
Con le sorgenti software così configurate è possibile ad esempio:
Sotto lo strato di gestione dei repository remoti e di gestione delle dipendenze tra i pacchetti fornito dai tool apt vi è lo strato di gestione vera e propria del pacchetti presenti nel sistema: dpkg (Debian PacKaGe).
Attraverso il tool in linea di comando dpkg è possibile ad esempio:
Molti dei pacchetti software conterranno al loro interno alcuni script di utilità:
Gli script relativi alle fasi di installazione sono script bash che fanno uso dell’api debconf e vengono installati nella directory /var/lib/dpkg/info
Mentre gli script relativi al boot vengono installati nella directory /etc/init.d e fanno parte di quello che viene comunemente chiamato sistema SYSV init
Gli script debconf vengono avviati automaticamente durante l’installazione, rimozione e aggiornamento dei pacchetti, ma è possibile avviare il task di config in qualunque momento attraverso il comando dpkg-reconfigure :
sudo dpkg-reconfigure -phigh dash
NOTA : questo task spesso sovrascrive i file di configurazione e potrebbero andare perse alcune delle personalizzazioni aggiunte manualmente.
Gli script SYSV init vengono invece eseguiti ad ogni riavvio (se abilitati) e possono essere gestiti manualmente mediante il comando invoke-rc.d o dalle script stesso.
/etc/init.d/apache2 (start|stop|restart) invoke-rc.d apache2 (start|stop|restart)
Gli script che non dovessero essere necessari (o che si comunque vuole disabilitare) non devono essere rimossi, ma semplicemente disabilitati mediante il tool update-rc.d :
update-rc.d -f apache2 remove
Altre attività che spesso si svolgono congiuntamente alla installazione e configurazione dei servizi aggiuntivi sono quele di testing di rete, mediante i seguenti comandi:
ifconfig route dhclient ip host dig whois ping tracepath/traceroute tcpdump netstat
Ad esempio per verificare o configurare in maniera temporanea (cioè non persistente tra un riavvio e l’altro a differenza del file /etc/network/interfaces) è possibile utilizzare quello che è il comune toolset *nix a riguardo:
La maggior parte dei tool elencati sino ad ora sono presenti su tutte le distribuzione, ma ogni famiglia di distribuzioni si differenza dalle altre per piccole e grandi differenze riguardanti:
Tra le soluzioni comuni di cui è necessario quanto meno aver sentito parlare e/o conoscerne il funzionamento di massima ci sono:
E’ opportuno (soprattutto se si tratta di un sistema da mettere in produzione) conservare delle immagini template del sistema configurato, in modo da essere in grado di ricrearlo in qualsiasi momento nel minor tempo possibile.
In caso contrario il sistema presenterà diversi malfunzionamenti, nella migliore delle ipotesi
Ogni distribuzione fornisce dei metodi di installazione rapida di un sistema precedentemente prototipato, ma allo stato attuale nessuna consente di ottenere un sistema realmente replica e senza il controllo che è possibile ottenere utilizzando i normali tool presenti sui sistemi *nix e un LiveCD come RIPLinux.
NOTA E’ opportuno sempre effettuare un check della memoria e delle altre periferiche hardware prima di procedere all’installazione e messa in produzione di un clone.
Non è affatto scontato che il partizionamento del nuovo clone debba essere identica a quella del sistema originale.
Nel caso in cui fosse necessario è possibile utilizzare sfdisk :
sfdisk /dev/hdd -O hdd-partition-sectors.save sfdisk /dev/hdd -I hdd-partition-sectors.save
A questo punto a seconda del tool utilizzato per salvare l’immagine del sistema, sarà necessario o meno ricreare i filesystem, mountare il filesystem e scriverci sopra il contenuto del sistema originale.
Una volta ripristinato il contenuto dei vecchi filesystem è necessario ricordare di modificare/ricontrollare il sistema nelle sue componenti essenziali:
Se fosse necessario effettuare dei test o delle operazioni di configurazione all’interno del sistema clonato prima del suo effettivo riavvio (come l’installazione di un kernel e riconfigurazione del boot menù) è possibile utilizzare il comando chroot :
RIPLinux:~# mount -t proc proc /mnt/clone/proc RIPLinux:~# mount -o sys sys /mnt/clone/sys RIPLinux:~# mount -o bind /dev /mnt/clone/dev RIPLinux:~# chroot /mnt/clone clone:~# apt-get install linux-image-server [...] clone:~# update-grub clone:~# grub-install /dev/hdd
ATTENZIONE: spesso alcuni script debconf avviano dei servizi in background che impediscono il successivo umount dei filesystem, attraverso il comando fuser è possibile identificarli ed eliminarli.
Il riavvio successivo alla creazione di un clone potrebbe non funzionare correttamente.
Se siamo comunque riusciti ad installare correttamente GRUB sarà possibile modificare interattivamente la configurazione di boot per riuscire ad effettuare il boot da disco.
In caso contrario sarà necessario riavviare il LiveCD e ripetere la procedura di installazione del bootloader.
Di solito i problemi di boot sono relativi ad:
A seconda dello scopo del clone realizzato, dopo il riavvio sarà possibile effettuare le ulteriori necessarie configurazioni, che lo distinguano dall’originale.
Quando si gestiscono diverse istanze di un medesimo server diventa necessario poter identificare e conservare le differenze tra le diverse istanze (tra loro e nel tempo).
A questo scopo sono disponibili diversi sistemi più o meno complessi e completi:
Scegliendo il tool si deve decidere con quale granularità salvare le differenze, a seconda delle proprio esigenze e dello scopo del clone, potrebbe essere semplice come effettuare una sincronizzazione mediante rsync ed una lista predefinita di file di EXCLUDE o complesso come un sistema client-server di backup e ripristino.