Archive for Marzo, 2009
Installare un kernel modulare su un RPS di OVH
Gli RPS (Real Private Server) di OVH sono server “reali” (e non virtuali) con la sola differenza che non hanno un disco proprio ma piuttosto utilizzano iSCSI per accedere ad un disco di rete.
Di default gli RPS effettuano il boot via netboot, ossia dalla rete. OVH utilizza un sistema per il quale è possibile tramite interfaccia web (manager) selezionare che tipo di boot si voglia effettuare tra hd, rescue-pro, vKVM e vari kernel precompilati da OVH con o senza supporto di ipv6 e con o senza supporto GRSEC (patch che migliora la sicurezza del kernel).
Alla consegna esiste già un kernel installato anche sull’hd ed è quindi possibile fare il boot da hd: basta selezionare “hd” e poi riavviare l’RPS ed aspettare un po’.
Ebbene sì, il boot da HD risulta molto più lento del netboot ed impiega circa 15 minuti, durante i quali riceverete alcune email da OVH che si accorge che il sistema non è raggiungibile ed apre automaticamente un ticket di assistenza per poi richiuderlo (sempre automaticamente) appena il server torna online.
Nei numerosi test che ho effettuato qualche volta mi è capitato che i tecnici di OVH gestissero il ticket prima che venisse effettivamente richiuso in automatico. In questi casi mi sono ritrovato il server impostato sul netboot del primo kernel di rete e riavviato con quello.
Utilizzare un kernel su hd per un RPS è quindi fortemente sconsigliato ma ci sono casi in cui può essere fondamentale poter utilizzare un kernel personalizzato, come ad esempio l’uso di un driver particolare (e.g: DRBD), di una particolare regola iptables oppure del supporto per i moduli del kernel (e.g: per installare vmware server). Il kernel di rete non è modulare e non è modificabile quindi in tutti questi casi avrete bisogno di ricompilare il kernel, installarlo ed attivare il boot da hd.
Nel mio caso l’OS dell’RPS è una Fedora Core 9 Italiano, ma le istruzioni dovrebbero essere sostanzialmente le stesse con tutte le distribuzioni.
Scarichiamo i sorgenti del kernel usato da OVH dal loro server. Mentre scrivo questo articolo la 2.6.28.4 è l’ultima disponibile:
# lavoriamo in /usr/src, cartella standard per i sorgenticd /usr/src/
# download del kernelwget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz
# decompressionetar xzf linux-2.6.28.4-ovh.tar.gz
# link a /usr/src/linux per comoditàln -s linux-2.6.28.4-ovh linux
Scarichiamo poi il file di configurazione usato da OVH, come base prima delle nostre modifiche. Sempre nell’ftp precedente OVH ne fornisce 2, quello a 32bit e quello a 64bit.
# entriamo nella cartella del kernelcd linux
# scarichiamo il file di configuraizone (nel mio caso a 32bit)wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-32
# rinominiamo il file a .configmv 2.6-config-xxxx-std-ipv4-32 .config
A questo punto siamo pronti per riconfigurare il kernel secondo le nostre esigenze:
# lancio della configurazione del server:
make menuconfig
A questo punto potete apportare le modifiche di configurazione che vi servono.
Nel mio caso si trattava dell’abilitazione del supporto dei moduli con “Enable loadable module support” e la sotto funzione “Module unloading“, da “Device Drivers” la funzione “Connector – unified userspace <-> kernelspace linker” e il “Real Time Clock“, che in questo caso attivo come moduli esterni (<M>)
Per distinguere correttamente il nostro kernel dovremo poi cambiare il suffisso nel menu “General setup” alla voce “Local version – append to kernel release“.
Io ho scelto “-custom-std-ipv4-32-mod”
Completate le modifiche uscite memorizzando il .config e proseguiamo con la compilazione che richiederà tra i 15 e i 30 minuti e l’installazione:
# compilamake
# installazione dei modulimake modules_install
# installazione degli headersmake headers_install
Completata questa procedura il kernel è pronto. Evitate di usare il classico “make install” per l’installazione perchè l’installazione ovh usa un initrd molto particolare (per l’uso del disco iscsi) che non vogliamo rigenerare.
# copia del kernelcp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod
# copia della System.mapcp /usr/src/linux/System.map /boot/System.map-2.6.28.4-custom-std-ipv4-32-mod
Non ci resta che abilitare il nuovo kernel in lilo (credo che in tutte le RPS sia installato lilo)
# lancia l'editing (vi o il vostro editor preferito).vi /etc/lilo.conf
# mantengo il vecchio kernel come "linux-orig" e aggiungo la configurazione del nuovo. Il file risultante è:prompt timeout=10 default=linux boot=/dev/sda map=/boot/map install=/boot/boot.b lba32 image=/boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod label=linux read-only root=/dev/ram0 initrd=/initrd-iscsi.img append="libusual.bias=ub" image=/boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32 label=linux-orig read-only root=/dev/ram0 initrd=/initrd-iscsi.img append="libusual.bias=ub"
# salviamo ed aggiorniamo il bootloader:lilo -v
# risultato del comando liloLILO version 22.8, Copyright (C) 1992-1998 Werner Almesberger Development beyond version 21 Copyright (C) 1999-2006 John Coffman Released 19-Feb-2007 and compiled at 09:15:23 on Feb 19 2007. Reading boot sector from /dev/sda Using MENU secondary loader Calling map_insert_data Boot image: /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod Mapping RAM disk /initrd-iscsi.img Added linux * Boot image: /boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32 Mapping RAM disk /initrd-iscsi.img Added linux-orig Writing boot sector. /boot/boot.0800 exists - no boot sector backup copy made.
Riavviamo la macchina (shutdown -r now
) e dopo 10-15 minuti la macchina dovrebbe essere caricata con il nuovo kernel. Il comando uname -r
dovrebbe perciò dirci “2.6.28.4-custom-std-ipv4-32-mod” e non più “2.6.28.4-xxxx-std-ipv4-32” e il comando lsmod dovrebbe funzionare (mostra l’elenco dei moduli se il kernel è modulare).
Se la macchina non dovesse ripartire potete sempre andare nel manager ed impostare il netboot sul kernel di rete per poi forzare in riavvio.
Nel prossimo articolo vi mostro il mio .config con il quale ho ridotto le dimensioni dell’immagine del kernel da 4.5MB a 1.8MB così da ridurre i tempi di reboot a circa 6-7 minuti.
Pagine
Articoli recenti
Archivi
- Luglio 2009 (1)
- Giugno 2009 (3)
- Maggio 2009 (2)
- Aprile 2009 (8)
- Marzo 2009 (1)