Remote Install Server

Se, come me, vi ritrovate a gestire un parco macchine virtuale distribuito su diversi datacenters e dovete installare macchine piu' o meno giornalmente (quasi) sempre seguendo le stesse linee guida, dopo un po' cominciate a cercare un modo di sveltire le operazioni.

Idealmente quello che volete e' schiacciare un pulsante ed ottenere un server gia' installato (o quasi).

Con le macchine virtuali in genere e' possibile clonare un server ed usare la copia, ma alle volte capita di dover installare o re-installare una macchina vera. O si vuole un po' piu' di flessibilita'.

In questi casi e' di aiuto l'avere un Server di Installazione Remota a disposizione.

Quando avviamo un computer, virtuale o reale, questo cerca di eseguire il boot. In molti casi il boot viene eseguito da disco fisso o da DVD/CDRom/USB. Ma in molti altri casi e' possibile far eseguire il boot dalla rete.

Il boot dalla rete e' alla base dei sistemi diskless, in cui l'intero sistema operativo e filesystem sono caricati e gestiti via rete e la macchina vera e propria non ha nessun dispositivo di memoria di massa. Ma, dato che possiamo avviare un OS, possiamo anche installare lo stesso OS sul sistema nello stesso modo.

In entrambi i casi (semplice boot o installazione), la macchina si aspetta di ricevere un indirizzo IP via DHCP e di ricevere dal server DHCP alcuni parametri che sono usati per trovare il suo sistema operativo con il quale eseguire il boot.

Nota: io descrivo solo il protocollo dhcp.

Una volta ottenute queste informazioni la macchina scarichera' il kernel e le altre 'parti' necessarie via tftp (Trivial FTP), che altro non e' che una versione semplificata di ftp.

La prima cosa da fare quindi e' quella di configurare un server con dhcpd (server dhcp) e tftpd (server tftp). Per RedHat/CentOS basta installare i packages -server per Slackware, se avete installato tutto di default ce li avete gia'.

Un altra cosa utile e' un server http (Apache) per poter fare il download dei vari packages, files et simila. E' anche possibile usare NFS o FTP, ma io preferisco http per la semplicita' e' perche' posso fare le verifiche usando un semplice browser.

Decidiamo dove mettere la nostra directory di installazione, teniamo a mente che lo spazio necessario per il tutto e' pari alla somma di tutti i CD/DVD che ci servono per le installazioni. Se vogliamo avere pronte all'uso 3 versioni di CentOS, ci serviranno almeno 12 Gb di spazio (3 DVD).

Supponiamo che la nostra directory di installazione sia /install:

mkdir /install
mkdir /install/pxelinux.cfg

Configuriamo dhcpd per consentire ai clients di fare il boot e caricare il sistema, nella sezione 'globale' di in dhcpcd.conf mettiamo:

allow booting;
allow bootp;
next-server xxx.xxx.xxx.xxx;
filename "/pxelinux.0";

Dove 'xxx.xxx.xxx.xxx' e' l'indirizzo IP del vostro server di installazione. Nel mio caso sto' usando una VLan per le installazioni e l'IP del mio server di installazione e' 172.16.22.1, quindi per me sara' next-server 172.16.22.1;.

Questo e' quanto, riavviamo (o avviamo) dhcpd.

A questo punto dobbiamo configurare tftp, per fare questo basta aggiungere ad inetd.conf:

tftp  dgram   udp     wait    root    /usr/sbin/in.tftpd  in.tftpd -s /install

Se usate xinetd invece di inetd dovrete semplicemente abilitare il corrispondente file di configurazione in /etc/xinetd.d mettendo 'disable' a 'no' e riavviare xinetd.

Apache serve per poter downloadare files in maniera semplice, come gia' detto e' possibile usare ftp, tftp, nfs, samba o altro, io ho scelto http. Quindi mi limito a configurare un VirtualHost in Apache in questo modo:

NameVirtualHost xxx.xxx.xxx.xxx:80
<VirtualHost xxx.xxx.xxx.xxx:80>
	ServerName xxx.xxx.xxx.xxx

	DocumentRoot "/install"
	<Directory "/install">
		Options Indexes
		Order deny,allow
		Deny from all
		Allow from xxx.xxx.xxx.
	</Directory>
</VirtualHost>

Come al solito 'xxx.xxx.xxx.xxx' e' l'IP del mio server di install. Notare che io in 'allow' consento l'accesso solo alle macchine nella stessa sottorete.

Se tutto funziona, dovreste poter vedere la directory di installazione via browser. Se non funziona.... bhe', non ha senso andare avanti finche' questo non e' a posto no?

A questo punto si tratta di mettere i files di boot in /install, per fare cio' e' necessario prenderli da syslinux, in Slackware /usr/lib/syslinux, in RedHat/CentOS occorre prima installare il package e poi copiare i files da /usr/lib/syslinux:

cp /usr/lib/syslinux/pxelinux.0 /install
cp /usr/lib/syslinux/menu.c32 /install
cp /usr/lib/syslinux/memdisk /install
cp /usr/lib/syslinux/mboot.c32 /install
cp /usr/lib/syslinux/chain.c32 /install

Dulcis in fundo, creiamo un menu' di installazione in /install/pxelinux.cfg/, basta creare un file chiamato 'default' contenente:

default menu.c32
prompt 0
timeout 300
ontimeout local
menu title PXE Menu

label CentOS 5.4 i386 eth0
	menu label CentOS 5.4 i386 
	kernel CentOS/5.4/i386/vmlinuz
	append ks=http://xxx.xxx.xxx.xxx/CentOS/5.4/i386/kickstart.ks \
		initrd=CentOS/5.4/i386/initrd.img ramdisk_size=100000 \
		ksdevice=eth1 ip=dhcp

Rapida spiegazione: 'default' indica quale "formato" di menu usare, menu.c32 crea un grazioso (per certi valori di 'grazioso') menu semigrafico che dovrebbe essere visibile ed usabile con qualsiasi display, ontimeout specifica che se non si sceglie niente la macchina fara' il boot dal suo disco locale, questo serve ad evitare che una macchina si riavvii e rimanga in attesa in eterno.

Seguono 'n' sezioni, ogni sezione inizia con 'label' e finisce alla successive sezione (o alla fine del file se e' l'ultima). La voce 'menu label' e' quello che viene visualizzato nel menu' di scelta, 'kernel' indica quale kernel avviare (DOH!) ed 'append' consente di specificare i parametri da attaccare al kernel durante il boot.

Nel mio caso riportato sopra io specifico che il kernel e' CentOS/5.4/i386/vmlinuz ed i parametri specificano un Kickstart file ed altre cose. Nel Kickstart file sara' specificato da dove prendre i packages, nel mio caso nel mio kickstart riporto:

url --url http://xxx.xxx.xxx.xxx/CentOS/5.4/i386/

Questo e' il minimo per un server di boot per iniziare, adesso si tratta di aggiungere il kernel ed il resto.

Warning: Come al solito 'xxx.xxx.xxx.xxx' e' l'Ip del server di installazione.

Creiamo una directory che conterra' i files necessari all'installazione di CentOS via rete:

mkdir -p /install/CentOS/5.4/i386/images
mkdir -p /install/CentOS/5.4/i386/CentOS
mkdir -p /install/CentOS/5.4/i386/repodata

Ora si tratta di riempirla.

Dal DVD di CentOS copiamo il contenuto nelle directory corrette, per prima cosa prendiamo il kernel ed il suo initrd.img dalla directory images/pxeboot.

In parole povere, supponendo che voi abbiate il DVD montato in /mnt/dvd:

cp /mnt/dvd/images/pxeboot/vmlinuz /install/CentOS/5.4/i386/
cp /mnt/dvd/images/pxeboot/initrd.img /install/CentOS/5.4/i386/

Copiamo il resto dei files *.img da images nella corrispondente directory nella nostra struttura, i dati dei packages da repodata ed infine gli RPMS da CentOS.

cp /mnt/dvd/images/*.img /install/CentOS/5.4/i386/images
cp /mnt/dvd/repodata/* /install/CentOS/5.4/i386/repodata
cp /mnt/dvd/CentOS/* /install/CentOS/5.4/i386/CentOS

Questo e' quanto per CentOS.

Il kickstart per CentOS deve contenere, come minimo, l'indicazione di dove trovare i packages. Un kickstart minimale e':

install
url --url http://xxx.xxx.xxx.xxx/CentOS/5.4/i386
lang en_US.UTF-8
keyboard us

Di nuovo 'xxx.xxx.xxx.xxx' e' l'ip del server di installazione.

Mettiamo il file in /install/CentOS/5.4/i386 chiamato (come riportato tra i parametri del file di configurazione del boot sopra) kickstart.ks.

Verifichiamo che i files siano visibili via browser puntandolo a http://xxx.xxx.xxx.xxx/CentOS/ e se tutto sembra ok, dovremmo poter avviare la nostra macchina e vedere il menu' di boot e, scegliendo l'unica voce momentaneamente esistente, avviare l'installazione di CentOS.

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

No messages this document does not accept new posts

Previous Next

Davide Bianchi, works as Unix/Linux administrator for an hosting provider in The Netherlands.

Do you want to contribute? read how.

This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.