Configurare Buildbot per le Macchine Virtuali - Principi generali

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

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.


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/ sarà necessario per l'installazione di tutte le macchine virtuali.

Serial port

The vms are configured to use the (emulated) serial port as the console. When running KVM on the host, the console then maps to the stdin/stdout. This is useful to get kernel log messages available to easier debug any problems. The bootloader Grub is similarly configured to use the serial port.

The vms are also set up to give a login prompt on the serial port (running getty). In retrospect this has proven not really needed, as if needing to manually log in and investigate things, it is often as easy to just run KVM in graphics mode. It may be useful in cases where the host machine is remote though (in this case graphics mode does still work but can be a bit slow).

To configure for serial console, the following two files are referenced below, and should be prepared in advance:


# 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

exec /sbin/getty 115200 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 rc RUNLEVEL=[2345]
stop on runlevel [!2345]

exec /sbin/getty -L 115200 ttyS0 vt102

Unattended MariaDB install on Debian/Ubuntu


The MariaDB (and MySQL) package on Debian and Ubuntu prompts the user about the root password to set. We want to test this important step, but we do not want the prompt of course. To do this we use the following configuration file for defaults for debconf. This file is needed in the steps below under the name "my.seed" (be careful to preserve it exactly as here, including trailing space and tab characters!)

    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	

For some background see here. The file my.seed can be generated from an existing install using debconf-get-selections.


For Debian/Ubuntu, we add a local repository to the list of apt source to be able to test `apt-get install`. For this, the following file "sources.append" must be prepared:

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

Emulation options

The default network card emulated by KVM has poor performance. To solve this we instead use the "virtio" network device, using the KVM options "-net nic,model=virtio -net user". Except on Debian 4, which has an old kernel without support for virtio. Background info here.

A detail is that some 32-bit vms crashed during boot with default options. This was fixed by using the kvm "-cpu qemu32,-nx" option. Some background information here.


Sto caricando i commenti......
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.