| |Intro | Install | Using | Monitor | Tuning | Teambuilder | |
[Prev: Introduction] [Home] [Next: Using Teambuilder]
Untar the package and change into the teambuilder directory:
# gunzip teambuilder-[package].tar.gz # tar xvf teambuilder-[package].tar # cd teambuilder
Now run the install program and read the license agreement.
# ./install Welcome to Trolltech Teambuilder You must read the Teambuilder license agreement carefully and agree to be bound by the terms of the license before installing Teambuilder. Press [Space] to view the Teambuilder license agreement.
If you accept the terms of the license agreement, type "yes" to continue. When prompted, type the full path of the directory that you would like to install teambuilder in. The default path is /opt/teambuilder. You will then be asked to confirm the location for teambuilder. If the path is correct, type 'y' and press Enter.
Where do you wish to install Teambuilder [/opt/teambuilder]? Install in "/opt/teambuilder" (y/n)? y
Teambuilder will then be unpacked into the specified directory.
Run the scheduler on a fast stable machine; this machine will be the Teambuilder Scheduler:
# /opt/teambuilder/bin/tbscheduler -debug Ready for connections...
The scheduler needs the following ports to be accessible by all machines in the farm:
10247 TCP
10248 UDP
Each machine in the compiler farm must run the Teambuilder Daemon (tbdaemon).
# /opt/teambuilder/bin/tbdaemon -debug Connecting to: scheduler... Adding handler gcc, /usr/bin/gcc 2.95.2 Adding handler g++, /usr/bin/g++ 2.95.2 Connected to scheduler: scheduler
The output displayed will vary depending upon the compilers you have installed. See Configuring Daemons below if no compilers are found.
Make sure tbdaemon is running on at least two machines.
The daemons require that port 10246 TCP is available.
Make sure that the Teambuilder bin directory precedes the system compilers in the user's path:
For csh users: setenv PATH /opt/teambuilder/bin:$PATH
For sh users: export PATH=/opt/teambuilder/bin:$PATH
If you now run make with parallel compilation enabled, (e.g. make -j4) the compilations will be distributed among the available daemons. You can verify that the jobs are being distributed using the Teambuilder Monitor. If the jobs are not being handled by Teambuilder see Using Teambuilder.
The value you choose for the -j parameter to make should be roughly the same as the number of machines in your farm. Making it a little higher will help to keep all machines busy.
One scheduler should be run per compiler farm. The Teambuilder Scheduler is called tbscheduler. It can be run as either root or a normal user. When run as root, tbscheduler switches user to "nobody" and reads its configuration from /etc/tbscheduler.conf. When run as a normal user, tbscheduler reads its configuration from $HOME/.tbschedulerrc.
tbscheduler accepts the following command-line switches:
-config file -- specify the config file to use
-debug -- print debugging output
-no-fork -- do not fork and run in the background
-log-file file -- specify the log file to use (default stderr)
-version -- display the Teambuilder version
-help -- display help for Teambuilder Scheduler
If tbscheduler is run on a machine that already has tbscheduler running, the new instance will exit immediately.
tbscheduler usually doesn't require any configuration. It accepts broadcast requests from Teambuilder Daemons and Teambuilder Compilers and responds if the system types match.
The tbscheduler configuration file starts with [Settings] followed by name=value pairs, e.g:
[Settings] Accept = all
You can restrict the hosts allowed to connect to the scheduler by setting Accept and Deny. By default anyone can connect. The Accept and Deny settings are adopted by the daemons that connect to the scheduler as well.
The parameter to Accept and Deny is a comma-delimited list of the form address[/mask]. Address is an IP address (names are not accepted). Mask can be either a network mask or a number specifying the number of 1's in the left of the network mask. For example, a mask of 24 is equivalent to 255.255.255.0.
For example:
[Settings] Accept = 10.1.1.0/24 Deny = ALL
accepts everyone in the 10.1.1.0 network.
Accept and Deny can be an effective way of partitioning groups of machines into individual compiler farms.
A Teambuilder Daemon must be run on each machine that is to participate in the compiler farm. The Teambuilder Daemon is called tbdaemon. It can be run as either root or a normal user. When run as root, tbdaemon switches user to "nobody" and reads its configuration from /etc/tbdaemon.conf. When run as a normal user, tbdaemon reads its configuration from $HOME/.tbdaemonrc.
tbdaemon accepts the following command-line switches:
-config file -- specify the config file to use
-debug -- print debugging output
-no-fork -- do not fork and run in the background
-log-file file -- specify the log file to use (default stderr)
-version -- display the Teambuilder version
-help -- display help for Teambuilder Daemon
If tbdaemon is run on a machine that already has a tbdaemon running, the new instance will exit immediately.
In the simplest case tbdaemon requires no configuration. tbdaemon will broadcast a request for a scheduler and connect to the first scheduler that responds with the same system type. By default tbdaemon will allow one job to be run at a time and attempt to register compilers named cc, CC, gcc, g++ and c++ in your $PATH. Provided one or more of these compilers are in the $PATH, tbdaemon can be used immediately.
The tbdaemon configuration file starts with [Settings] followed by name=value pairs, e.g:
[Settings] MaxJobs = 2 Scheduler = ccfarm1
Teambuilder is capable of finding a scheduler on its own, but if you have two or more distinct groups of machines that you want to keep separate you can specify the scheduler to use with the Scheduler setting. The scheduler may be specified by either name or IP address.
The number of concurrent jobs (compilations) run on each daemon can be specified via the MaxJobs setting. A good rule of thumb is that MaxJobs should be set equal to the number of processors in the machine.
You can prevent machines from compiling jobs by setting MaxJobs to 0. This is desirable if you have a group of dedicated compiling machines and don't want to load developer's less powerful hardware.
The number of concurrent jobs can also be reduced using the Teambuilder Monitor.
Local jobs are processes that must be run on the machine where the build is initiated. These include generating compiles and linking. The MaxLocalJobs setting is used to indicate the number of concurrent local jobs that can be run in excess of the MaxJobs setting. For example, if MaxJobs is set to 1 and MaxLocalJobs is set to 2, there can be no more than 1 compilation being performed, but there could be up to 3 local jobs if there is no compilation in progress.
The default value for MaxLocalJobs is 1 and this is usually sufficient. If you have a very fast machine (e.g. dual processor) then increasing this number should keep all available machines busy during large compilations.
By default tbdaemon attempts to register compilers named cc, CC, gcc and g++ that are in the $PATH. You can specify the compilers that tbdaemon will support by listing them using the Compilers setting:
Compilers = gcc,g++,arm-linux-gcc,arm-linux-g++
tells tbdaemon to handle the ARM GCC cross-compilers as well as the normal gcc compilers. You must specify all the compilers you want the daemon to handle, including any compilers that are otherwise autodetected.
It will also be necessary to make a link from the new compiler's name to tbcompiler in /opt/teambuilder/bin. For example, to add the arm-linux-gcc compiler:
cd /opt/teambuilder/bin ln -s tbcompiler arm-linux-gcc
Note that the compiler must be named identically on all machines. For example, you cannot run gcc on a native ARM machine and use arm-linux-gcc on x86 machines.
Since machines participating in compilation are often desktop machines, it is possible to lower the priority of the compiler processes initiated by tbdaemon via the Priority setting. Priority should be set to a value between 0 (normal) and 19 (lowest). The default priority is 5.
The compiler priority can also be changed via the Teambuilder Monitor.
In some situations it may be necessary to have more than one Teambuilder farm. For example, if different operating systems are used, then each operating system will require its own separate Teambuilder farm. This is achieved by running a scheduler on one machine from each group of machines that use a particular operating system. The daemons and compilers will connect automatically to the correct Teambuilder farm.
It is also possible to have two or more farms that run on machines which use the same operating system. In this situation the scheduler that each daemon should connect to must be specified in the daemon's configuration file. It is also possible to let the schedulers decide which daemons they will allow to connect via the Accept and Deny configuration options.
While basic security precautions have been taken in the design of Teambuilder, it is assumed that Teambuilder will be used in house by trusted users. In particular, Teambuilder has no user authentication. For these reasons Teambuilder should never be installed on a publicly accessible network.
[Prev: Introduction] [Home] [Next: Using Teambuilder]
| Copyright © 2001-2002 Trolltech | Trademarks | Teambuilder version 1.0
|