Le installazioni sono mantenute minimali, utilizzando per lo più le opzioni predefinite. In questo modo si testano meglio le installazioni di default e si risparmia fatica durante la creazione delle macchine virtuali.

Siccome la maggior parte della logica è gestita nello slave Buildbot su una macchina host e nel master Buildbot, non occorre installare Buildbot o altre cose complesse fuori dalle VM.

ssh

Le macchine virtuali sono configurate con accesso ssh. Viene creato un account chiamato 'buildbot', che usa il login senza password (utilizzando la chiave ssh pubblica), e con accesso sudo senza password (necessario per l'automazione tramite script). La chiave pubblica per l'utente buildbot è installata in ogni VM, mentre la chiave privata viene aggiunta all'account che esegue il master Buildbot sulla macchina host.

Per generare le chiavi ssh:

ssh-keygen -t dsa

Si lasci vuota la passphrase. Questi comandi vanno eseguiti dall'utente che esegue lo slave Buildbot sulla macchina host KVM. Il file risultante /.ssh/id_dsa.pub sarà necessario per l'installazione di tutte le macchine virtuali.

Porta seriale

Le VM sono configurate per usare una porta seriale (emulata) come console. Quando si esegue KVM sull'host, la console è mappata a stdin/stdout. Ciò è utile per poter leggere più facilmente i messaggi di log del kernel durante il debug. Anche il bootloader Grub è configurato per usare la porta seriale.

Le VM sono inoltre configurate per dare un prompt di login sulla porta seriale (tramite getty). In retrospettiva questa caratteristica non era realmente necessaria, perché se occorre loggarsi manualmente per indagare una anomalia, spesso è più semplice eseguire semplicemente KVM in modalità grafica. Può però essere utile nei casi in cui la macchina host è remota (la modalità grafica aiuta anche in questa situazione, ma può essere un po' lenta).

Per configurare la console seriale, i due file seguenti verranno usati e devono essere preparati in anticipo:

ttyS0

# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc2
start on stopped rc3
start on stopped rc4
start on stopped rc5

stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /sbin/getty 115200 ttyS0

ttyS0.conf

# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/getty -L 115200 ttyS0 vt102

Unattended MariaDB install on Debian/Ubuntu

my.seed

Il pacchetto di MariaDB (e MySQL) per Debian e Ubuntu chiede all'utente la password da impostare per root. Vogliamo testare questo passaggio importante, ma naturalmente non vogliamo il prompt. Pertanto utilizziamo il seguente file di configurazione con i valori di default di debconf. Tale file è necessario nei passaggi successivi e deve chiamarsi "my.seed" (occorre preservarlo esattamente come è esposto qui, compresi gli spazi e i tab!)

    mariadb-server-5.1	mysql-server/root_password_again	password	rootpass
    mariadb-server-5.1	mysql-server/root_password	password	rootpass
    mariadb-server-5.1	mysql-server/error_setting_password	error	
    mariadb-server-5.1	mysql-server-5.1/nis_warning	note	
    mariadb-server-5.1	mysql-server-5.1/really_downgrade	boolean	false
    mariadb-server-5.1	mysql-server-5.1/start_on_boot	boolean	true
    mariadb-server-5.1	mysql-server-5.1/postrm_remove_databases	boolean	false
    mariadb-server-5.1	mysql-server/password_mismatch	error	
    mariadb-server-5.1	mysql-server/no_upgrade_when_using_ndb	error

Per alcuni retroscena si veda qui. Il file my.seed può essere generato da un'installazione esistente usando debconf-get-selections.

sources.append

Per Debian e Ubuntu, aggiungiamo un repository locale alla lista delle fonti apt per poter testare `apt-get install`. Occorre quindi preparare il file "sources.append":

deb file:///home/buildbot/buildbot/debs binary/
deb-src file:///home/buildbot/buildbot/debs source/

Opzioni di emulazione

Le performance della scheda di rete predefinita emulata da KVM lasciano a desiderare. Per ovviare questo inconveniente si può usare il dispositivo di rete "virtio", utilizzando le opzioni KVM "-net nic,model=virtio -net user". Eccetto su Debian 4, che è basata su un vecchio kernel che non supporta virtio. Ulteriori informazioni qui.

Purtroppo alcune macchine virtuali a 32 bit crashavano durante il boot con le opzioni predefinite. Questo problema è stato corretto utilizzando l'opzione di kvm "-cpu qemu32,-nx". Ulteriori informazioni qui.

Commenti

Sto caricando i commenti......