Attached is the new documentation for piuparts-master/slave
configuration to the end. This will be included in the next upload, but
I'm adding it to the bug so that it is accessible to everyone earlier.
--
I've never seen anyone wear a Freudian slip.
Master configuration file
-------------------------
piuparts-master uses the configuration file
/etc/piuparts/piuparts-master.conf. The syntax is defined
by the Python ConfigParser class, and is, briefly, like
this:
[master]
foo = bar
where "master" is the name of a section. There can only be
one section in the master configuration file, but it must
be named "master". "foo" is the name of a configuration
item, and "bar" is the value.
The following configuration items are defined for the master:
* "log-file" is the name of a file to where the master should
write its log messages. In the default configuration file
it is "/dev/null", that is, log messages are not put in a
file.
* "packages-url" is a URL to the Packages.bz2 file for your
mirror. It is usually best to use the Packages.bz2 for
sid (unstable), unless you know what you're doing. For
example, you might use
http://ftp.debian.org/debian/dists/sid/main/
binary-i386/Packages.bz2
(all on one line, of course), but you really do want
to replace "ftp.debian.org" with the name of your local
mirror.
Both configuration items must be in the configuration file,
or master will refuse to run.
Slave configuration file
------------------------
piuparts-slave uses the configuration file
/etc/piuparts/piuparts-slave.conf. It has the same
general syntax as the master's configuration file. The
section is called "slave" and the configuration items
are as follows:
* "idle-sleep" is the length of time the slave should wait
before querying the master again if the master didn't have
any new packages to test. In seconds, so a value of 300
would mean five minutes, and that seems to be a good
value when there are fairly few slaves per master.
* "master-host" is the host where the master exists. The
slave will give this host to ssh.
* "master-user" is the username of the master. The slave will
log in using this username.
* "master-directory" is the directory where the master keeps
its files. Can be relative to the master's home directory.
* "master-command" is the command to run on master-host to
start the master. When the master has been installed from
the Debian package, the command is
"python /usr/share/piuparts/piuparts-master.py".
* "mirror" tells the slave which mirror it is to use. The
slave gives this to piuparts when it runs it.
* "piuparts-cmd" is the command the slave uses to start
piuparts. It should include "sudo" if necessary so that
piuparts runs with sufficient priviledges to do its testing
(and that means root priviledges).
* "distro" is the distribution the slave should tell piuparts
to use for basic install/purge testing.
* "chroot-tgz" is the name of the file the slave should
use for the tarball to keep the chroot for the basic
install/purge testing. If the tarball doesn't exist, the
slave creates it.
* "upgrade-test-distros" is the space delimited list of
distributions the slave should use for testing upgrades
between distributions (i.e., Debian versions). Currently,
"sarge etch sid" is a good choice.
* "upgrade-test-chroot-tgz" is the name of the file the slave
should use for the tarball to keep the chroot for the
first distribution in upgrade-test-distros. If the file
does not exist, the slave creates it.
* "max-reserved" is the maximum number of packages the
slave will reserve at once. It should be large enough
that the host that runs master is not unduly stressed by
frequent ssh logins and running master (both of which
take quite a bit of CPU cycles), yet at the same time it
should not be so large that one slave grabs so many
packages all other slaves just sit idle. The number
obviously depends on the speed of the slave. A good
value seems to be enough to let the slave test packages
for about an hour before reporting results and reserving
more. For a contemporary AMD64 machine with a reasonably
fast disk subsystem the value 50 seems to work fine.
* "debug" tells the slave whether to log debug level
messages. The value should be "yes" or "no", with the
default being "no".
Some of the configuration items are not required, but it
is best to set them all to be sure what the configuration
actually is.
