Debian-based distributions

Debian-based distributions

These instructions cover Debian and all distributions based upon Debian, including Ubuntu. The supported versions of Debian and Ubuntu are:

Distribution Codename Number Support
Debian experimental n/a Yes [1]
Debian sid n/a Yes
Debian stretch n/a [2]
Debian jessie 8.0 Yes [3]
Ubuntu wily werewolf 15.10 No [4] [5]
Ubuntu vivid vervet 15.04 No [4] [5]
Ubuntu utopic unicorn 14.10 No [4] [5]
Ubuntu trusty tahr LTS 14.04 No [4] [5]

Debian uses codenames for releases (jessie, wheezy, squeeze) and names for suites (unstable, testing, stable & oldstable). The packages in all suites except unstable will change codename once a release of Debian stable is made. The testing suite then gains a new codename and the oldstable suite will gain the codename of the former stable suite.

To allow the table to refer to the same package versions consistently over time, codenames are used. When a Debian release is made, a new codename is applied to the testing suite and LAVA releases after that point will include that codename in the table.

Ubuntu codenames change with each 6 monthly release and there will be no further updates of LAVA in Ubuntu after 2015.9.post1. See Installing on Ubuntu

[1]experimental allows updates to be selected on top of unstable (or the current testing) during times when testing is frozen ahead of a release of Debian stable. Experimental will typically have no LAVA packages outside of a Debian release freeze.
[2]stretch is the name of the next Debian release after Jessie, which is supported automatically via uploads to sid (unstable).
[3]Jessie was released on April 25th, 2015. All updates to LAVA packages for jessie will be made using jessie-backports. Systems using Debian Jessie are recommended to enable jessie-backports. LAVA packages and dependencies which are installed using jessie-backports are fully supported by upstream and are the same codebase as the relevant production release available from the LAVA repositories.
[4](1, 2, 3, 4) Ubuntu vivid vervet 15.04 was released on April 23rd, 2015 and wily werewolf on October 22nd 2015. LAVA packages no longer migrate from Debian into the current development release of Ubuntu, so wily werewolf has the last lava-server update, 2015.8.1-1. Once Ubuntu makes a release, the LAVA packages in that release do not receive updates. Support for lava-server on Ubuntu Trusty 14.04LTS, Ubuntu Vivid 15.04 and Ubuntu Wily 15.10 stopped at 2015.9.post1. Support for lava-dispatcher on Ubuntu Trusty 14.04LTS, Ubuntu Vivid 15.04 and Ubuntu Wily 15.10 stopped at 2015.9. See Ubuntu Trusty Tahr 14.04 LTS or Ubuntu Utopic Unicorn 14.10.
[5](1, 2, 3, 4) To install on Ubuntu, ensure the universe repository is enabled.

You can track the versions of LAVA packages in the various Debian by following links from the Debian package trackers for lava-dispatcher and lava-server.

LAVA repositories

As well as being uploaded to Debian, Production releases of LAVA are uploaded to a Linaro production-repo repository which uses the LAVA Archive signing key - a copy of the key is available in the repository.

In times when the current production release has not made it into jessie-backports (e.g. due to a migration issue in Debian), this repository can be used instead. The only apt source to use with Debian Jessie, Stretch or Sid is the production-repo for sid because the same LAVA packages are used on Jessie and Stretch as on Sid:

deb http://images.validation.linaro.org/production-repo sid main

Note

There are no packages currently in the repository except in sid.

The codename sid is used simply as that is the codename for unstable which is where all Debian uploads arrive, so to allow the production repo to include precisely the same upload as was made to Debian, we use sid. It makes no difference to how the packages get installed on Jessie, Stretch or Sid.

The services-trace.txt file in the repository shows the latest update timestamp and is accompanied by a GnuPG signature of the trace file, signed using the LAVA Archive signing key.

Interim builds (including release candidates) are available in the staging repository:

deb http://images.validation.linaro.org/staging-repo sid main

This repository uses the same key as the production repository and uses sid in the same way.

Production releases

LAVA is currently packaged for Debian unstable using Django1.7 and Postgresql. LAVA packages are now available from official Debian mirrors for Debian unstable. e.g. to install the master, use:

$ sudo apt install postgresql
$ sudo apt install lava-server

If the default Apache configuration from LAVA is suitable, you can enable it immediately:

$ sudo a2dissite 000-default
$ sudo a2ensite lava-server.conf
$ sudo service apache2 restart

Edits to the /etc/apache2/sites-available/lava-server.conf file will not be overwritten by package upgrades unless the admin explicitly asks dpkg to do so.

TFTP support requirement

LAVA uses tftp to serve files to a variety of device types.

The current dispatcher relies on TFTP downloads, NFS share directories and master image downloads to all be made from a single directory: /var/lib/lava/dispatcher/tmp. To do this, the configuration file for tftpd-hpa needs to be modified to use the LAVA directory instead of the default, /srv/tftp.

Note

The TFTP support in LAVA has had to be changed from the 2015.8 release onwards to stop LAVA enforcing a configuration change on the tftpd-hpa package without explicit configuration by the admin. Previously, installation may have prompted about changes in /etc/default/tftpd-hpa, now this change needs to be made manually as the configuration of the tftpd-hpa package should not have been up to LAVA to impose. If you are already running a version of LAVA installed prior to the 2015.8 release (and have working TFTP support), then the configuration change will have been imposed by LAVA and then maintained by dpkg and tftpd-hpa. Check that your /etc/default/tftpd-hpa file references /var/lib/lava/dispatcher/tmp and continue as before.

Admins can either manually change the /etc/default/tftpd-hpa to set the TFTP_DIRECTORY to /var/lib/lava/dispatcher/tmp or copy the file packaged by lava-dispatcher:

$ sudo cp /usr/share/lava-dispatcher/tftpd-hpa /etc/default/tftpd-hpa

The change is required whichever Debian-based distribution you use as your base install, including Ubuntu.

This behaviour has been fixed in the refactoring such that whatever location is configured for tftpd-hpa, LAVA will use temporary subdirectories in that location for all TFTP operations and other LAVA operations will use the /var/lib/lava/dispatcher/tmp directory. The equivalent change was not practical to implement in the current dispatcher. If all of your devices are exclusive, to the pipeline, then the tftpd-hpa configuration can be set to the tftpd original value (/srv/tftp), the LAVA historical value (/var/lib/lava/dispatcher/tmp) or another directory specified by the admin.

Extra dependencies

The lava package brings in extra dependencies which may be useful on some instances.

Note

Some dependencies of the lava package require the addition of the Linaro Tools PPA. See https://launchpad.net/~linaro-maintainers/+archive/tools for more information - click on Technical details about this PPA to get information on the apt sources required to use it. Adding the Linaro Tools PPA.

Installing on Debian Jessie

Debian Jessie was released on April 25th, 2015, containing a full set of packages to install LAVA.

Updates are uploaded to jessie-backports

deb http://http.debian.net/debian jessie-backports main

LAVA Archive signing key

pub  2048R/C77102A9 2014-06-06 LAVA build daemon (Staging) <lava-lab@linaro.org>
     Key fingerprint = 45AD 50DC 41AE D421 FF5B  33D4 ECF3 C05C C771 02A9
uid                  LAVA build daemon (Staging) <lava-lab@linaro.org>

Each of the support archives on images.validation.linaro.org is signed using same key, 0xC77102A9, which can be downloaded and added to apt:

$ wget http://images.validation.linaro.org/staging-repo/staging-repo.key.asc
$ sudo apt-key add staging-repo.key.asc
OK

Then update to locate the required dependencies:

$ sudo apt-get update

Installing just lava-server

The lava-server package is the main LAVA scheduler and frontend.

To install just the lava-server from the current packages, use:

$ sudo apt-get install lava-server
$ sudo a2dissite 000-default
$ sudo a2ensite lava-server.conf
$ sudo service apache2 restart

This will install lava-dispatcher and lava-server.

Other packages to consider:

  • lavapdu-client to control a PDU to allow LAVA to automatically power cycle a device.
  • lavapdu-daemon - only one daemon is required to run multiple PDUs.
  • ntp - some actions within LAVA can be time-sensitive, so ensuring that devices within your lab keep time correctly can be important.
  • linaro-image-tools which provides linaro-media-create for tests which use hardware packs from Linaro

Installing the full lava set

Production installs of LAVA will rarely use the full lava set as it includes tools more commonly used by developers and test labs. These tools mean that the lava package brings more dependencies than when installing lava-server to run a production LAVA instance.

The lava package installs support for:

  • lava-dev - scripts to build developer packages based on your current git tree of lava-server or lava-dispatcher, including any local changes.
  • linaro-image-tools which provides linaro-media-create for tests which use hardware packs from Linaro
  • vmdebootstrap for building your own Debian based KVM images.
  • lavapdu-client to control a PDU to allow LAVA to automatically power cycle a device.
  • lavapdu-daemon is recommended or you can use a single daemon for multiple PDUs.
  • ntp - some actions within LAVA can be time-sensitive, so ensuring that devices within your lab keep time correctly can be important.

All of these packages can be installed separately alongside the main lava-server package, the lava package merely collects them into one set.

$ sudo apt-get install postgresql
$ sudo apt-get install lava
$ sudo a2dissite 000-default
$ sudo a2ensite lava-server.conf
$ sudo service apache2 restart

Upgrading LAVA packages on Jessie

Updates are uploaded to jessie-backports

deb http://http.debian.net/debian jessie-backports main

Adding the Linaro Tools PPA

To get updated versions of linaro-media-create and other optional packages which come from the Linaro PPA, use the apt source:

deb http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu precise main

The PPA uses this signing key:

http://keyserver.ubuntu.com:11371/pks/lookup?search=0x1DD749B890A6F66D050D985CF1FCBACA7BE1F97B&op=index

Installing on Ubuntu

LAVA recommends the use of Debian - Ubuntu installs are no longer supportable and 2015.9.post1 marks the last available version.

Always ensure that the Ubuntu universe repository is enabled on all Ubuntu instances before installing LAVA.

Installing on Ubuntu Utopic, Vivid and Wily

Warning

Support for Ubuntu Xenial 16.04LTS was removed as unsupportable, leaving the last Ubuntu version of LAVA at 2015.9.post1. No further updates will be made for Ubuntu and no new installs (master or remote worker) should be made on Ubuntu.

Ubuntu Unicorn 14.10 includes all packages needed by LAVA up to the 2014.07 release.

Installing on Unicorn, Vivid and Wily is the same as Installing on Debian Jessie.

See also Developing LAVA on Debian or Ubuntu for information on building updated LAVA packages on your own, LAVA will not be making backports to Ubuntu.

Ubuntu Trusty Tahr 14.04 LTS

Warning

Support for Ubuntu Trusty 14.04LTS was frozen at 2015.9.post1 for lava-server and 2015.9 for lava-dispatcher. No further updates will be made for Trusty and no new installs (master or remote worker) should be made on Trusty.

Ubuntu Utopic Unicorn 14.10

Warning

Support for Ubuntu Utopic 14.10 was frozen at 2015.9.post1 for lava-server and 2015.9 for lava-dispatcher. No further updates will be made for Utopic and no new installs (master or remote worker) should be made on Utopic.

Setting up a reverse proxy

In order to use lava-server behind a reverse proxy, configure lava-server as usual and then setup a reverse proxy using Apache. The folowing Apache configuration will work for most setup:

ProxyPass / http://lava_server_dns:port/
ProxyPassReverse / http://lava_server_dns:port/
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https" env=HTTPS

This configuration will work when proxifying:

http://example.com/ => http://lava.example.com/

If you want the application to answer on a specific base URL, configure lava-server to answer on this base URL and then configure the reverse proxy to proxify the same base URL. For instance you can have:

http://example.com/lava => http://lava.example.com/lava

Having two differents base URLs is difficult to setup due to a limitation in the Django framework. In this case you will have to also setup Apache modules, like Substitute to alter the HTML content on the fly. This is obviously not a recommended setup.

Superuser

OpenID or LDAP

In LAVA instances that use external authentication mechanisms such as OpenID or LDAP, login once with the user account that has to be granted superuser privileges on LAVA web UI. After logging in with OpenID or LDAP successfully, make use of the following command to make this user a superuser:

$ sudo lava-server manage authorize_superuser --username {username}

Note

{username} is the username of OpenID or LDAP user.

LDAP

In LAVA instances that use LDAP as authentication mechanism, the addldapuser command can be used to populate a user from LDAP and also grant superuser privilege as follows:

$ sudo lava-server manage addldapuser --username {username} --superuser

Note

{username} is the username of LDAP user.

Local Django Account

A default lavaserver superuser is setup during package installation with a random password. The default superuser is not the same as the lavaserver system user nor the postgres user (despite the name):

$ sudo lava-server manage createsuperuser --username default --email=$EMAIL

This will prompt for name, email address and password.

You can always delete this user later, but at least it gets you a default [sic] admin user with a password you know.

To change the password of the dummy superuser, login as this new superuser at http://localhost/admin and select Users in the administrator interface. Selecting lavaserver brings up the details of the installation superuser and below the password field is a link to change the password without needing to know the random password.

To delete the dummy superuser, login as this new superuser at http://localhost/admin and select Users in the administrator interface. Select lavaserver and click the Delete link at the bottom of the page.

Note

The above superuser created with createsuperuser command will be added as a local Django user account, in other words the user account lives on the LAVA instance’s database, even if the LAVA instance uses external authentication mechanisms such as OpenID or LDAP.

An existing local Django superuser account can be upgraded to an LDAP user account without losing data, using the mergeldapuser command, provided the LDAP username does not already exist in the LAVA instance:

$ sudo lava-server manage mergeldapuser --lava-user <lava_user> --ldap-user <ldap_user>