This document will go over how to set up a local Autotest server for developing purposes.
Note that there is a script which helps to automate this process: src/third_party/autotest/files/site_utils/setup_dev_autotest.sh
You will want to do this for changes that are not easily testable in the production server. Generally this will not be needed for test development. This is if you are changing RPCs, The Scheduler, Any of the frontend GUI or common library changes.
These instructions will only work with a Debian based installation. Most likely you can use the package names to set up Autotest for Fedora/Redhat.
After installing all of the packages below you will end up with a server running MySQL, Apache, and have the supporting libraries need to bootstrap the Autotest installation.
**Be sure to remember the password you set up for the root user in Mysql (If any)
sudo apt-get install mysql-server mysql-common libapache2-mod-wsgi python-mysqldb gnuplot apache2-mpm-prefork unzip python-imaging libpng12-dev libfreetype6-dev sqlite3 python-pysqlite2 git-core pbzip2 openjdk-6-jre openjdk-6-jdk python-crypto python-dev subversion build-essential python-setuptools
*Note you will be prompted to enter a 'root' user password for MySQL this is reserved for administering the MySQL instance itself. You should not use this for the next section but do not forget it either.
Autotest use MySQL for all of its result storing and queuing jobs for the scheduler to interface with.
Setup the Autotest MYSQL user:
*some_password can be whatever you want. Make note of it as you will need it later on.
NOTE: Do not try to make the autotest server run directly from your home directory and DO follow the "/usr/local/autotest" bind mount or checkout. Changing all the paths in the source and making it work at the same time seems downright impossible.
*Preferred way, if you have a Chromium OS checkout you should already have the Autotest soure.
If you don't have a Chromium OS checkout and just want the Autotest bits:
Edit the global_config.ini, or better yet, create a shadow configuration (place it in shadow_config.ini) to update the following areas:
# Run this as the user you want to run the Autotest server as.
If you ran the above package install command you should already have a running apache server. All we need to do is point that configuration at the Autotest configuration.
If you try http://localhost, and Autotest afe page fails to load, you might want to check the apache's port configuration file (/etc/apache2/ports.conf) to make sure the file has port 80 listed:
Otherwise, apache will not be listening on port 80.
If you get 503 errors and see the following message in /var/log/apache2/error.log:
(2)No such file or directory: mod_wsgi: Couldn't bind unix domain socket '/etc/apache2/run/wsgi.30365.0.1.sock'.
Just create the /etc/apache2/run directory.
***This is the end of what is done for you by setup_dev_autotest.sh.***
Start the scheduler.
*You may want to run the scheduler in screen
The user that started the scheduler needs to have root access to the devices you are connecting to. All test images include a authorized key that developers have access to.
You can get the key from the chromiumos checkout under chromiumos/src/scripts/mod_for_test_scripts/ssh_keys/testing_rsa
If the user you are using is specifically for testing you can add this key in the default ssh key path under ~/.ssh/id_rsa and it will automatically get used when connections are tried to any computer with SSH.
If this is not an option you need to either set up an SSH agent (http://upc.lbl.gov/docs/user/sshagent.shtml) or configure your ~/.ssh/config file to use the testing_rsa key above when specific hosts are connected to.
Example host entry in ~/.ssh/config
You can test any of these set ups by trying to connect to the system as root:
To view logs of a currently running job from the AFE click on the "Debug logs" link. From there you have a few different choices, you will most likely want to look at all the logs which are all in autoserv.DEBUG. Although this file does not automatically update when viewed in your browser if you refresh your view you will see the progress of the job.
All logs from jobs run via the scheduler are stored under: /usr/local/autotest/results.
If you get 403 Forbidden when viewing the results, or if the AFE starts giving Error 500 and strugging to import code, then you either need to re-run
# Setup permissions so that Apache web user can read the proper files.
Or (recommended) edit /etc/apache2/envvars so that it reads
where <user> is what is returned by running |id -un| and <group> is the result of running |id -gn|