Munin contributed plugins

Linux servers (running munin-node) used to collect data from other systems 

Password for BOINC (default: none) 

Using of variable B<password> poses a security risk. Even if the Munin 

configuration file for this plugin containing BOINC-password is properly 

protected, the password is exposed as environment variable and finally passed 

to boinccmd as a parameter. It is therefore possible for local users of the 

machine running this plugin to eavesdrop the BOINC password. 

Using of variable password is therefore strongly discouraged and is left here 

It should be always possible to use B<boincdir> variable instead - in such case 

the file gui_rpc_auth.cfg is read by boinccmd binary directly. 

If this plugin is used to fetch data from remote system, the gui_rpc_auth.cfg 

can be copied to special directory in a secure way (e.g. via scp) and properly 

This plugin shows the estimated remaining computation time for all CPUs of 

The estimation is based on assumption that the workunits of different lengths 

The warning level can be used to warn in forward about the risk of workunits 

Although such warning can be achieved by configuring Munin master, there is 

BOINC is running on local machine. The BOINC binaries are installed in 

F</usr/local/boinc/> under username boinc, group boinc and the password is used 

Warning will be set when estimated work for any of CPUs will decrease under 

BOINC is running on 2 remote machines C<foo> and C<bar>. 

On the local machine the binary of command-line interface is installed in 

The BOINC password used on the remote machine C<foo> is stored in file 

The BOINC password used on the remote machine C<bar> is stored in file 

These files are owned and readable by root, readable by group munin and not 

readable by others. 

There are 2 symbolic links to this plugin created in the munin plugins 

directory (usually F</etc/munin/plugins/>): F<snmp_foo_boincestwk> and 

This way the plugin can be used by Munin the same way as the Munin plugins 

The estimation is based on simple assumption, that longest workunits will be 

processed first. This is the case when work is distributed evenly among CPUs. 

But this is not always the case, because various deadlines for various 

workunits may fire the "panic mode" of BOINC and scheduling could be much 

different. 

For example, there can be 4 CPUs, and BOINC having downloaded 4 workunits 

with estimated run-time 1 hour each and 3 workunits with estimated run-time 

4 hours each. 

But if deadline of those 1-hour workunits will be much shorter than deadline 

of those 4-hours workunits, BOINC will schedule short workunits first (for all 

remaining 4th CPU. So after 1 hour of computation 1 of CPUs will run out of 

There is no C<autoconf> capability at the moment. This is due to the fact, that 

BOINC installations may vary over different systems, sometimes using default 

directory from distribution (e.g. F</var/lib/boinc/> in Debian or Ubuntu), but 

Also the user-ID under which BOINC runs often differs. 

Under these circumstances the C<autoconf> would be either lame or too