Development: BuildbotOnDebian

From WxWiki
Jump to navigation Jump to search

Setting up a Buildslave on a Debian based Linux System.

Before you begin

Choose a name and password for your buildbot and let Vadim know what they are. Also tell him the IP address you will be connecting from so that he can make a firewall rule to let you in.

Make sure that the machine has everything it needs to check out and build wxWidgets, for GTK+ for example:

   # aptitude install g++ subversion libgtk2.0-dev

It is a good idea to try out a build manually to make sure that everything required is installed.

For the buildbot install the following packages:

# aptitude install buildbot stunnel4 ccache libcppunit-dev sudo \
    gdb xvfb lwm ttf-freefont

Stunnel

The build master listens on port 9990 for SSL connections, however Buildbot doesn't support SSL at the moment. So we'll use stunnel to forward a non-SSL local port 9989 to the master's 9990. The buildbot will then be configured to connect to the local end of the tunnel.

You can fetch the build master's certificate as follows:

# cd /etc/stunnel
# openssl s_client -connect buildbot.tt-solutions.com:9990 < /dev/null \
    | openssl x509 > certs.pem

If this fails with the message:

   connect: Protocol not available

it indicates that the TT-Solutions firewall is preventing the connection, check with Vadim about the firewall rule.

Next edit /etc/stunnel/stunnel.conf, here is a configuration:

# cd /etc/stunnel
# cat stunnel.conf
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = TLSv1

; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside chroot jail
pid = /stunnel4.pid

; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
;compression = rle

; Authentication stuff
verify = 2
CAfile = /etc/stunnel/certs.pem

; Some debugging stuff useful for troubleshooting
;debug = 7
;output = /var/log/stunnel4/stunnel.log

; Use it for client mode
client = yes

; Service-level configuration

[buildbot]
accept = 127.0.0.1:9989
connect = buildbot.tt-solutions.com:9990

You may also need to add an entry in hosts.allow. If not, messages like this will appear on the logs:

Aug 13 00:31:40 (none) stunnel: LOG4[1873:3074575216]: Service buildbot REFUSED by libwrap from 127.0.0.1:49058

To fix this, just add an entry to hosts.allow allowing localhost for the buildbot service, the name is the sames as the service name in stunnel.conf (buildbot in this example):

buildbot: LOCAL: ALLOW

Edit /etc/default/stunnel4 and change ENABLED to 1 so that the tunnel is started at boot up:

# Change to one to enable stunnel
ENABLED=1

Then start the tunnel running:

   # invoke-rc.d stunnel4 start

You can check that it is ok with netstat, you should see it listening on 9989:

# netstat -tl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 localhost:9989          *:*                     LISTEN
...

To check that everything is working, you can use wget:

wget -O /dev/null localhost:9989

It should not report any errors.

Buildbot

Next become the buildbot user and create a working directory for it as follows:

# su -s /bin/bash buildbot
$ buildbot create-slave /var/lib/buildbot/wxslave localhost:9989 \
    SLAVENAME PASSWORD

This will create files 'admin' and 'host' under the directory '/var/lib/buildbot/wxslave/info' which you can fill in with a description of your slave and your contact details.

Also created is the file buildbot.tac, this is the main configuration file.

In there 'usepty' must be changed to 0 ('1' doesn't work for some versions of buildbot).

The checkouts and builds will be done under the directory specified by the 'basedir' variable. We change it to /var/local/run/sandbox and set the umask to 002 to share the files with the 'sandbox' user created in the next section.

The slave's environment can be set up. You will need to add the directory of the sandbox script to the path. The $LANG variable should be 'C' or unset.

Here's an example:

from twisted.application import service
from buildbot.slave.bot import BuildSlave
import os

basedir = r'/var/local/run/sandbox'
buildmaster_host = 'localhost'
port = 9989
slavename = 'SLAVENAME'
passwd = 'PASSWORD'
keepalive = 600
usepty = 0
umask = 002

HOME = os.environ['HOME']
PATH = os.environ['PATH']
PATH = "/var/lib/buildbot/wxslave/bin:" + PATH
os.environ = { 'PATH': PATH, 'HOME': HOME, 'DISPLAY': ':5' }

application = service.Application('buildslave')
s = BuildSlave(buildmaster_host, port, slavename, passwd, basedir,
               keepalive, usepty, umask=umask)
s.setServiceParent(application)

You can add a cron job to stop the logs building indefinitely:

   # crontab -u buildbot -e

For example:

# m h  dom mon dow   command
 24 4   *   *   *    rm -f /var/lib/buildbot/*/twistd.log.??

Sandbox

Under the slave's directory create a sandbox script:

# cd /var/lib/buildbot/wxslave
# mkdir bin
# vi bin/sandbox

You can use this script, which changes user to the sandbox user:

#!/bin/sh
sudo -H -u sandbox sh -c "$@"

Save it and make it executable:

# chmod +x bin/sandbox

Create a sandbox user and group, add the buildbot user to the group and give it access to the sandbox directory:

# adduser --system --home /var/local/run/sandbox --group sandbox
# adduser buildbot sandbox
# chmod g+sw /var/local/run/sandbox

Run visudo to edit the sudoers file, to allow the buildbot to become the sandbox user without a password:

   # visudo

In there add the following, and save the file:

# Allow buildbot to become sandbox
buildbot    ALL = (sandbox) NOPASSWD: ALL

Create a firewall rule so that the sandbox user has no internet access:

   # iptables -A OUTPUT \! -d localhost -m owner --uid-owner sandbox -j DROP

You may already have a way to save the rules so that they are restored on boot, if not you can set one up as follows:

   # iptables-save > /etc/iptables.up.rules

Then edit /etc/network/interfaces and add:

# Load iptables rules
pre-up iptables-restore < /etc/iptables.up.rules

You can check the rule is still in place after a boot with:

# iptables -L
...
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            owner UID match sandbox

Set up some locales

Install a selection of locales, for example:

ar_AE.UTF-8 A right to left one.
fr_FR.UTF-8 The test program uses wxLANGUAGE_FRENCH, so this should be useful.
it_IT.UTF-8 It also uses wxLANUAGE_ITALIAN.
ru_RU.UTF-8 A Cyrillic one.
en_US.UTF-8

The command to install locales varies between distributions. On Debian run the command:

   # dpkg-reconfigure locales

then pick the required locales from the list that appears.

On Ubuntu, for example:

   # cd /usr/share/locales
   # ./install-language-pack fr_FR.UTF-8

then repeat for each additonal language.

X11 environment for the GUI tests

We'll use Xvfb as a fake X server for running the GUI tests, and lwm as the window manager.

Add it to the sandbox's crontab so that it runs on bootup, with.:

   # crontab -u sandbox -e

Edit the crontab to look like:

# m h  dom mon dow   command
@reboot xinit /usr/bin/lwm -- /usr/bin/Xvfb :5 -screen 0 800x600x24 >& /dev/null &

You can set it running now, before the next reboot, with:

# su -s /bin/bash sandbox
$ xinit /usr/bin/lwm -- \
    /usr/bin/Xvfb :5 -screen 0 800x600x24 >& /dev/null &

Start it running

Edit /etc/default/buildbot so that your buildbot starts on boot-up, for example:

# cat /etc/default/buildbot
# buildbots to manage
# add a new set of variables for each buildbot to start

BB_NUMBER[0]=0                  # index for the other values; negative disables the bot
BB_NAME[0]="wxslave"              # short name printed on startup / stop
BB_USER[0]="buildbot"           # user to run as
BB_BASEDIR[0]="/var/lib/buildbot/wxslave"         # basedir argument to buildbot (absolute path)
BB_OPTIONS[0]=""                # buildbot options
BB_PREFIXCMD[0]=""              # prefix command, i.e. nice, linux32, dchroot

The default order is for buildbot to start up before stunnel during boot-up. This doesn't stop it working but it does show up as a 'fail' every boot, so reverse the order like this:

# update-rc.d -f buildbot remove
# update-rc.d buildbot defaults 80 20

Then start it running:

   # invoke-rc.d buildbot start