Scheduler restrictions
From Pirates@Home
Under normal circumstances the scheduler for your project will be open to the entire network, either the Internet (for a public project) or your Local Area Network (LAN) for a private project. But there are cases in which you may wish to limit access to your scheduler, and there are several ways this may be done.
You can also limit access to your project by restricting who can create an account using invitation codes, but that is a separate subject.
Contents |
Turning the scheduler off
You can turn off the scheduler in several ways. If you create a file in your project directory called stop_sched then nobody will be allowed to connect to the scheduler, but all other daemons will continue to run. An empty file is fine for this, so you can use the command
touch stop_sched
If you create a file named stop_daemons then all daemon processes will exit and the scheduler will not respond to requests.
touch stop_daemons
Delete the file to allow access again. If you stop the daemons you will need to restart the project.
You can also turn off the scheduler and file_upload_handler individually by using the Unix chmod command to turn off the execution bit for those files.
This sends an error message back to the clients which can be a little disconcerting to your project volunteers.
Restriction based on IP address
When your project is just starting you may want to restrict access to the scheduler to just a local network, or to selected networks, so that you give out work to just a few hosts. An easy way to do this is with a .htaccess file in your cgi-bin directory.
For this to work your web server configuation must allow for a .htaccess file in that directory. This is done with the AllowOverride AuthConfig directive. An example taken from Pirates@Home is
<Directory "/usr02/pirates/cgi-bin">
Options ExecCGI
AllowOverride AuthConfig Limit
Order allow,deny
Allow from all
</Directory>
You then place in the cgi-bin directory a file called .htaccess which contains the restrictions, which should be based on IP address or network name. Again, an example is the easiest way to see how it's done:
# This .htaccess file controls WWW access to the files in this directory. # This configuration only allows access from selected sites/domains AuthName "Pirates@Home scheduler" AuthType Basic AuthUserFile /dev/null AuthGroupFile /dev/null Order deny,allow Deny from all # Internal network: Allow from 192.168.1. # Our local domains Allow from .spy-hill.net Allow from .spy-hill.com # Vassar: Allow from 143.229. Allow from .vassar.edu # SUNY New Paltz: Allow from 137.140. Allow from .newpaltz.edu # My room when traveling for LIGO meetings # Comfort Inn in Baton Rouge: Allow from adsl-155-114-45.btr.bellsouth.net # Penn State Day's Inn: Allow from 69.162.39.218
You can easily lift the restriction by renaming this file (moving it out of the way), and reinstate it by changing the filename back to .htaccess.
According to the Apache documentation there is a performance penalty for enabling the AuthConfig option,[1] so you should turn this mechanism off when your project grows and you start thinking seriously about performance.
Restriction by BOINC version
You can use project settings in the config.xml file to require that your project's participants use a newer version of BOINC, and you can even announce plans to implement such a requirement in the future. More specific restrictions based on version number are also possible, but you will have to edit the BOINC source code for that level of refined control.
Requiring up-to-date versions
You can require that your project's particpiants use a current version of the BOINC client by setting the min_core_client_version in the config.xml file. [1] The value is an integer which represents the major and minor version numbers combined. For example, to require BOINC 5.4.0 or better you would set this parameter to 504. The configuration line to do this is
<min_core_client_version> 504 </min_core_client_version>
This mechanism does not pay any attention to the "release" number (eg. the '11' in 5.4.11).
You can also announce your intention to require a newer version of the BOINC client software at a future date, by setting the parameters min_core_client_version_announce
and min_core_client_upgrade_deadline . The first is a version number in the same format as the example above. The second is a Unix timestamp. For example
<min_core_client_version_announced> 512 </min_core_client_version_announced> <min_core_client_upgrade_deadline> 1207022400 </min_core_client_upgrade_deadline>
This announces your intention to require BOINC 5.12.0 or better by Unix date 1207022400, which is 1 April 2008. A message to that effect will be shown in the messages on client computers.
Excluding specific versions
There are, unfortunately, some bogus versions of the BOINC client in circulation which claim more credit than they should. Right now they report their BOINC version as either 5.5.0 or 5.9.0. You can block access to your scheduler to these particular versions by modifying the scheduler code. Edit the file sched/handle_request.cpp and find the definition of the function wrong_core_client_version(). This is the function which implements the restrictions mentioned above based on version number. You can insert at the beginning of this function a more specific test of the version number. An example which excludes versions 5.5.0 and 5.9.0 is:
bool wrong_core_client_version(
SCHEDULER_REQUEST& sreq, SCHEDULER_REPLY& reply
) {
char msg[256];
bool wrong_version = false;
int major, minor, release;
// change this to implement your own blocking policy
minor = sreq.core_client_minor_version;
major = sreq.core_client_major_version;
release = sreq.core_client_release;
if( (major==5) && ( (minor==5)||(minor==9) ) && (release==0) ){
wrong_version = true;
sprintf(msg, "Your version of the BOINC core client (%d.%d.%d) is disallowed.",
major, minor, release);
log_messages.printf(SCHED_MSG_LOG::MSG_NORMAL,
"[HOST#%d] [cpid %s] Disallowed BOINC %d.%d.%d\n",
sreq.hostid, sreq.cross_project_id,
major, minor, release);
}
if (config.min_core_client_version) {...
The people who build these bogus versions can easily respond to this by changing the version number to be something which is accepted as valid. Still, there are people who use the bogus versions without knowing they are bogus, and they will willingly switch when they know there is a problem. That is why it is a good idea to provide an informative error message, as is done in this example.
As of BOINC 6.3.6 there is a generic example of this in the scheduler code, so you need only adjust the condition(s) you apply to the client version information. But this does not appear to be in the server_stable branch yet.
To really block the use of clients which claim too much credit requires that your validator look carefully at the output returned from each Workunit and the credit claims.
That is outside the scope of this article.
Requiring a verified e-mail address
Be default BOINC projects will happily hand out work to any client host, provided it can prove it is associated with a registered user. It may be desirable to require that participants provide a valid, verified e-mail address. If so, one can easily add that requirement to the scheduler.
This will soon be tested on Pirates@Home. It may not yet be the correct prescription, and it may not be the only way or the best way to do this.
One way to do this is again to edit the file sched/handle_request.cpp. This time find the definition of the function authenticate_user(). In that function, just after the section which checks the authenticator, and just before the check to see if a new host record needs to be created, you will find the line
reply.user = user;
This is where the host authentication has been accepted. Just before that, insert this little test, or something similar:
// New auth requirement: must have verified e-mail address.
//
if( user.email_validated == 0 ) {
log_messages.printf(MSG_CRITICAL,
"[HOST#%d] [USER#%d] Unverified e-mail address '%s'\n",
host.id, user.id, user.email_addr
);
return ERR_BAD_EMAIL_ADDR;
}
Right now the email_validated field is either 1 or 0, but in the future I would like to see it changed to a timestamp, so that one can require not only that the e-mail address has been verified, but that it's been verified recently (where projects can decide the meaning of "recent").
