Configurare Buildbot per le Macchine Virtuali - Principi generali
Contents
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.