-
Notifications
You must be signed in to change notification settings - Fork 465
Going public
Suppose you've created a BOINC server and have your apps ported to BOINC. A few more steps are required before you can do large-scale computing.
The steps depend on the type of your project:
- In-house project: you're going to use only in-house resources, like the desktop computers in a company. In this case, install the BOINC client on your worker nodes and you're done. This is detailed here.
- Semi-public project: you're going to use volunteered resources, but you're not going to publicize your project. Instead, you're going to use Science United to get resources.
- Public project: you're going to publicize your project to get volunteers (as well as possibly using Science United).
Your project's master URL should use a domain name, not an IP address.
If you change your project's master URL, all your volunteers will have to manually detach from the old URL and attach to the new one. You don't want this to happen. So pick a URL that will last. For example, if you're based at a university but there's a chance that your project will someday move elsewhere, don't use the university's domain.
The BOINC server software evolves over time. It's important to use the latest released version, since many of the changes are security fixes.
Subscribe to the boinc_projects email list to learn of new releases.
To upgrade server software, check out the latest version from github, stop the project, then
cd ~/boinc/tools
upgrade <project-name>
The BOINC server generates lots of log files
(in ~/projects/<project-name>/log_<host-name>.
Configure logrotate to rotate and purge these logs.
Back up the server. To ensure that the MySQL files are in a consistent state, stop the project while backups are happening. Or use a separate mechanism for backing up the DB.
Use e.g. Let's Encrypt. You'll then need to update your Apache config file, and change a couple of BOINC config files. Details are here.
This is important because - for example - scheduler request messages contain authentication information.
If hackers break into your server, and your code-signing private key is there, they could in theory use your project to distribute malware all your volunteers. That would be the end of your project, and a PR disaster for volunteer computing.
You can prevent this by code-signing your executables on a secure, disconnected machine, as described here.
- Contact us and ask to have your project listed by BOINC. You'll be asked to demonstrate that a) your project is doing what you claim it is, and b) you're following a set of security practices. Your project will then a) be announced on the BOINC web site news column, b) be listed on the BOINC web site, and c) appear in the list of projects shown in the BOINC client GUI.
- Contact us and ask to have your project included in Science United, a framework in which volunteers sign up for science areas instead of projects. You'll need to tell us what types of research your project is doing, and then you'll automatically get computing power from volunteers who have registered an interest in those areas. This has the advantage that you don't have to create a public-facing web site or do any publicity. In addition, you can ask to be included in Science United even before you've created your project. At that point we can tell you roughly how much computer power you'll get, and you can decide whether this justifies the investment in creating a project.
content
forums
spam control