Please edit this page with topics you want to see addressed in this section. And/or help with transforming this collection of sniplets to some readable text. SM
Configuration - summary
Above, a series of environment variables was specified to separate the invariant instructions from those bits that are project specific. Truly, each BOINC project needs its very own set of configuration variables. It is needed as long the project lives to allow for updates and routine maintenance. To avoid expensive typos, project-specific configurations are suggested, like ~/.boinc_projectname.conf.
For our test project, the configuration file is ~/.boinc_test.conf and this will look like,
# password for write access to your project database pw=MYSQLPASSWORDFORBOINCUSER # name of the MySQL database dbprojectname=boinctest # address of host (via DNS or IP number) at which project server shall be reached hosturl=http://a.b.c.d # name of folder in which data shall be stored, also becomes part of project URL fileprojectname=$dbprojectname # more human-compatible way to read the project name niceprojectname="BoincTestProject@Home" # location at which sources shall be kept installroot=/var/tmp/boinc
So while maintaining the project all we have to do is
source ~/.boinc_test.conf
and execute the commands using the standard variables.
A one go script for all steps mentioned here is availabe here
Add your own application
The only thing that counts to have is the application that helps your very personal task at hand. There are two ways to achieve that:
- a newly designed or modified app that knows how to speak the BOINC API
- a wrapper to execute the working application through the regular UNIX command line
The creation of native BOINC-speaking applications is nothing a distribution can help much with, except for providing the boinc-dev package. Please raise your hand if you are inclined to prepare a similar tutorial for that. We continue with using the wrapper to bring your (or someone else's) legacy applications to BOINC:
Preparations for using the wrapper for legacy (read: regular) applications
Previously |
Now |
Compiling sources oneselfHave the BOINC source code untarred to ~/boinc, the libraries compiled, and then cd ~/boinc/samples/wrapper make This process needs to be repeated for every Linux architecture you plan to support. This is why typically only the most mainstreamish Linux flavours are supported, i.e. amd64 and i386. |
Starting from the Debian packageall done |
Getting the wrapper and binaries into your server's setup
Please follow BOINC/ServerGuide/WrapperApp for detailed instructions on how to get your application wrapped. You then have a complete environment for getting arbitrary compute jobs performed by volunteers.
Example project: Docking with AutoDock
Numerous projects with BOINC can be imagined. We have chosen to address AutoDock as an examples since
one of the BOINC maintainers at Debian also maintains the packages for AutoDock and the MGLTools
- there is prior art, so quite a number of individuals can immediately understand the problem
FightAids@home of the ?WorldCommunityGrid
- many groups around the globe are likely to profit from these instructions while working on many different biological questions
If your background is not biochemistry you can still understand it all from the technical side. But you will barely come up with your own docking project. If you are interested to help out some drug researchers local to you, just find your nearest university and ask around. Even if you are still going to high school, you may run into someone to mentally feed you or even to offer some real collaboration.
The steps for creating the example project, is described at BOINC/ServerGuide/AutoDockApp.
Back to BOINC/ServerGuide.