Logging in

Your account to the lab will consist of a login on chicken, aka dilab.debian.net. To log in, ssh to dilab.debian.net port 222. Note that your use of this machine and the lab should be limited to testing/developing the Debian installer and related parts of Debian.

A partial Debian mirror is available at http://chicken/debian. To serve files to the lab via http, you can put them in a ~/html directory. Do not use this machine for serving public files and avoid large downloads and uploads. Use jigdo or rsync for transferring iso imges to the lab.

Console access and remote power control

The machine list tells the names of each of the machines for various architectures, as well as how their console is accessed and power is controlled. Note that machines are generally left turned off when not in use, although this doesn't really matter. Just remember that you may need to turn a machine on before using it.

Many machines have power controlled via x10; you can use the br program to turn them on and off. They're all on house code A, do not play with other house codes, as this could really annoy the lab's host and get the lab evicted. Also note that some x10 ports (currenlty port 1) have more than one machine on them. A few machines have power control or remote reboot available as part of their management interface and do not use x10.

Most of the machines have serial consoles, and these are all hooked up via conserver. Use the command console machine-name to get access; see the conserver docs for details. Machines with other means of access will have it documented in the machine list.

netboot files

Files for tftp booting can be placed in /var/lib/tftpboot; this directory should be accessible to all lab users. Also, ox's nfs root boot directory can be accessed by creating a new directory in /srv/nfs/ox/d-i/ and pointing the /srv/nfs/ox/d-i/boot sysmlink to it. donkey has iLO, which supports loading iso images and maybe floppies via http. Feeding images to iLO is too complicated to explin here, it's easiest to use digress to do it.

digress

The recommended way to run tests is not manually as documented above, but by using the digress test framework. This is recommended both because it's somewhat easier, and because it includes locking to help avoid using a machine when someone else is running a test with it, or the automated testing is running.

To get started with digress, check it out of d-i svn:

cd; svn co svn://svn.debian.org/d-i/trunk/scripts/digress

Now you need to configure it for the machines you'll use. At least part of this will include preseed files for the installs, which need to be in your html directory. It may be easiest to check it all out into that directory. Joey has a working digress setup for all the machines in the lab, which you can check out of svn as follows:

cd; mkdir html; cd html; svn co svn://svn.debian.org/d-i/people/joeyh/autoinstall d-i

Note: this is Joey's personal setup, please don't commit to it. Feel free to make a copy in svn and commit to there.

Now to run digress, set DI_TESTDIR to point to the location you checked out the digress configuration. Run this and/or put it in your profile:

DI_TESTDIR=~/html/d-i
export DI_TESTDIR

Now run ~/digress/test-harness. Without parameters, this will list configured machines. Pick a machine and run it again with that machine as a parameter to list available actions. You'll see some such as "off" and "on" that don't do full installs; the ones containing "d-i" in their name do various types of installs. Some machines have "manual" entires; these set up an installation environment but let you run the install by hand afterwards. Choose an action and finally, run "~/digress/test-harness machine action".

It's likely that it will fail the first few times, as the configs rely on various password settings that need to be in files in your home directory. Most of these are unimportant things such as the root password to use for the automatically installed system; just make something up; might as well make the file mode 400, although beware that the passwords can generally be intercepted during install.

Digress also expects you to provide various d-i images for the machines to boot; Joey typically keeps these in his ~/lib/dq/ directory, so the error message might refer to files in such a directory. You can either copy his, symlink to it, or modify html/d-i/schemes to use different filenames.

development systems

Each test machine has a (nfs rooted) development system installed for it, this is a debian testing system which can be used to build images, etc when the machines arn't running a test. Currently, you have to ask joey to get root on these. To boot a machine into its development system, tell digress to run its devel-system action.

help

This document is probably quite incomplete, and is currently not up-to-date, so mail Joey if you need help.