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.

Pagina di gestione del netboot nel manager v3 di OVH

Gestione del netboot nel manager v3 di OVH

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 sorgenti
cd /usr/src/
# download del kernel
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz
# decompressione
tar 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 kernel
cd 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 .config
mv 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

Interfaccia ncurses della riconfigurazione del kernel

Interfaccia ncurses della riconfigurazione del kernel


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“.

Scelta del suffisso del kernel

Scelta del suffisso del kernel


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:

# compila
make
# installazione dei moduli
make modules_install
# installazione degli headers
make 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 kernel
cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod
# copia della System.map
cp /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 lilo

LILO 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.

Tags: , , ,

martedì, Marzo 31st, 2009 Sysadmin 4 Comments