-
Notifications
You must be signed in to change notification settings - Fork 4
Boinc Server Guide
We have successfully created Boinc servers on Debian/Ubuntu and openSUSE machines, both physical and virtual. The Debian builds were typically for test or temporary servers. The openSUSE build details the necessary steps we used to get Boinc running on our publicly-facing production server. Both sets of
installation instructions advocate installing from source; we have had mixed results with the boinc-server-maker package, and it makes recompiling several boinc-related tools difficult or impossible without also downloading the source.
For all of our builds, we’ve made a user named boincadm. If using an existing server, creating a new user is probably best. Either way, create your user and add that group to the www-data group.
sudo adduser --system --group boincadm
sudo usermod -aG boincadm www-dataThe big things you need are all things related to:
- C/C++, python2
- Web server with php
- MySQL and addons for php and python
On Debian, the complete list of packages we needed is as follows:
sudo apt-get install git vim zip m4 libtool autoconf automake \
gcc pkg-config python2.7 mysql apache2 \
php5 php5-cli php5-gd php5-mysql \
libcurl4-openssl-dev openssl \
libapache2-mod-php5 python-mysqldb \
libssl-dev dh-autoreconf libmysqld-dev \
libmysql++-dev libmysql++3 mysql-server \
libmysqlclient-dev freeglut3-devWe have found that for Debian/Ubuntu (unlike for openSUSE), all of the required libraries can be installed easily via apt-get. A couple of the libmysql packages aren't necessarily needed, but we found it easier to install all of them. Ensure that the -dev versions of the openssl, GLU, and mysql packages are installed; for mysql, get the -dev packages in addition to mysql-server, etc.
Download the Boinc source from the Berkeley git repository:
git clone git://boinc.berkeley.edu/boinc-v2.git boincIn theory, you should just be able to do the following:
cd boinc
./_autosetup
./configure --disable-client --disable-manager
makeHowever, you may find you are missing packages during _autosetup and configure. The packages that have given us trouble are openssl, mysql, and GLU*. To assuage the configuration script, make sure you have the following:
openssl libssl-dev libcurl4-openssl-dev
mysql-server libmysql++-dev libmysqld-dev php5-mysql python-mysqldb
freeglut3-dev (although we didn’t need graphics, so this could be incomplete)Once you get through _autosetup and configure –disable-client –disable-manager, don’t forget to make.
First, download the source code via git, which we placed in /usr/local/src/:
cd /usr/local/src/boinc
mkdir boinc
git clone git://boinc.berkeley.edu/boinc-v2.git boincOne can get the latest source code by running git pull in the /usr/local/src/boinc directory.
To begin the server installation,
cd boinc
./_autosetupIf this complains, you’re missing something fundamental, like a compiler. The software prerequisites are listed for Server and Graphic apps.
Only the packages required for the server and graphical applications are needed (those for the client and manager are not). Everything required is available in yast, after translating package names and finding the right packages containing the missing libraries. The list of packages we had to install or verify were installed are:
git make m4 libtool autoconf automake gcc gcc-c++
pkg-config python(2.x) python-devel* python-mysql
mysql sqlite3 sqlite3-devel apache2 apache2-mod_php5
php5 php5-gd php5-fastcgi* libcurl-devel freeglut-devel
libXmu-devel libXi-devel libjpeg8-devel FastCGI-devel
* may not be needed.
For _autosetup to work, make sure you have installed the needed compilers, like gcc. Next, we run the configure script to get it ready for installation. This checks compiler flags, libraries, etc. We want to
do it for the server only, so run
./configure --disable-client --disable-managerThis will most likely complain about missing libraries or headers. Although most packages appear as stated on the Boinc website, some packages do not provide all of the necessary libraries. To find what was missing, we ran the above configure command and looked for errors in the log which mentioned what library or header file was missing. We then searched yast for the file name (without extension), and made sure that the scope of the search included the "Provides" list. This almost always resulted in a match with some *-devel package which would satisfy configure after installation.
Below is a list of notable libraries that were not easily installed:
-
X11- The libraries weren't in a package together. -
libXmu-devel, libXi-devel- These were needed to make the appropriate headers existed for theconfigurescript to ensure thatGLUTwas installed. -
php5-cli- This is in thephp5module. -
mod_ssl- This package is currently part of the standardapachepackage.
Lastly, we found that configure gave one warning concerning fastcgi:
checking if CFLAG '-include fcgi_stdio.h' works... no
configure: WARNING: fcgi-stdio.h not found.
------------------------------------------------------------
Disabling FCGI. Will not build components that require FCGI
------------------------------------------------------------You can look for where your fastcgi installation is by doing
find / -name fcgi_stdio.h -printThe solution to this error is to symlink the fcgi_.h headers (for us, located in /usr/include/fastcgi/) to /usr/include/ where configure is looking for them. This can be done with the one-liner:
pushd /usr/include && for H in `ls -1 fastcgi/*.h`;\
do HFILE=`basename $H`; ln -s $H $HFILE; done && popdTo ensure the configuration is properly set up, run the two commands again
./_autosetup
./configure --disable-client --disable-managerIf there are no warnings or errors, you can move onto make. To ensure that the distribution has been properly purged of previous make-related files, first run
make distcleanThis is especially important if you have git pulled after having run make previously. Now you can run
makeThis should hopefully compile successfully and concludes the setup of the source code.
This setup parallels much of what is available at the Debian BOINC guide. For the Debian/Ubuntu project setup, we put all of the project-specific variables in the file /.boinc.config
dbname=boinctest
dbuser=boincadm
dbpasswd=boincadmpw
dbhost=localhost
hosturl=http://a.b.c.d
projectname=boinctest
projectnicename="BoincTestProject@Home"
installroot=/home/boincadm/projectsand sourced them
source .boinc.configThen create the $installroot dir and change it’s ownership.
sudo mkdir -p \$installroot \&\& sudo chown boincadm:www-data \$installrootTo setup the mysql database, we just paste this line into the terminal.
cat <<EOMYSQL | mysql -u root -p;
DROP DATABASE IF EXISTS \$dbname;
CREATE USER '\$dbuser'@'localhost' IDENTIFIED BY '\$dbpasswd';
GRANT ALL PRIVILEGES ON \$dbname.* TO '\$dbuser'@'localhost';
EOMYSQL
fiIf you didn’t set up a root password for your build (which you need to open mysql as root), you can do
sudo mysqladmin passwordto set one.
If you are using the boinc-server-maker package, this part is tough because the package is broken in some ways as of September 2014. Read more below or skip if building from source.
I had a hard time getting this to work; the hardest part was getting make_project to find boinc_config_path.py. I tried symlinking, creating a __init__.py file. Try the following:
sudo ln -s /usr/share/python-support/boinc-server/Boinc/\
boinc_path_config.py /usr/share/pyshared/Boinc/boinc_path_config.py
PYTHONPATH=$PYTHONPATH:/usr/share/pyshared/Boinc/ \
/usr/share/boinc-server/tools/make\_project \
--url_base "$hosturl" \
--db_name "$dbname" \
--db_user "$dbuser" \
--db_passwd "$dbpasswd" \
--drop_db_first \
--project_root "$installroot"/"$projectname" \
--srcdir /usr/share/boinc-server/ \
"$projectname" "$projectnicename"If that doesn’t work, try adding
PYTHONPATH=$PYTHONPATH:/usr/share/python-support/boinc-server/Boinc/and retrying the above make_project command.
If installing from source, from the /home/boincadm/
sudo ./boinc/tools/make_project \
--url_base "$hosturl" \
--db_name "$dbname" \
--db_user "$dbuser" \
--db_passwd "$dbpasswd" \
--drop_db_first \
--db_host "$dbhost" \
--project_root "$installroot"/"$projectname" \
--srcdir "/home/boincadm/boinc" \
"$projectname" "$projectnicename"Your project should now be ready to go. Proceed to app development.
To begin the project initialization, we first made the user boincadm and the group boinc. The boinc group has the members boincadm and wwwrun (the user that runs apache on openSUSE). We set the
umask 0002 globally for all users in /etc/bash.bashrc.local, but it may be better to do this for only the two users boincadm and wwwrun instead. umask 0007 may be better in this case to prevent world
readability.
The make_project script has its own annoyances, specifically that it insists on creating the database for the project; this requires the database user for the project, boincadm, to have blanket CREATE
privileges (and blanket DROP privileges are recommended). These should be dropped immediately after the project is created. We have written the dev mailinglist asking for make_project to accept an existing
database, which may simplify things for database/server administrators.
We ran the following mysql commands:
mysql -u root -p
>CREATE USER 'boincadm'@'localhost' IDENTIFIED BY 'the_password';
>GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,REFERENCES,INDEX,
ALTER,CREATE TEMPORARY TABLES,LOCK TABLES ON `boinc_project`.*
TO 'boincadm'@'localhost';
>GRANT CREATE,DROP ON *.* TO 'boincadm'@'localhost';
>quit;where the_password and boinc_project were specified for our specific project.
Then we ran make_project with the required database options specified in the command (as user boincadm to ensure all files/directories had proper permissions):
su boincadm
./make_project
--url_base "hosturl" \
--db_name "dbname" \
--db_user "dbuser" \
--db_passwd "dbpasswd" \
--drop_db_first \
--project_root "installroot"/"projectname" \
--srcdir /usr/local/src/boinc/ \
"projectname" "projectnicename"
mysql -u root -p
>REVOKE CREATE,DROP ON *.* FROM 'boincadm'@'localhost';
>quit;Notice that the make_project script was run as the boincadm user. This was to ensure the proper ownership on everything created by make_work. The permissions on these files and directories were very
liberal (likely due to the umask 0002). The only thing we did was remove world read/execute from the project folder. Notably, we did not move the keys subdirectory off-site, though if we open the project up to the public, we likely will.
Lastly, openSUSE 13.1 ships with apache 2.4, which uses a new mod_authz_host module. However, the version on our server comes with the access_compat module compiled in. Basically, the old "Order
allow,deny" and "Allow from all" style directives are deprecated in apache 2.4, but supported by the built-in but no-way-to-disable access_compat module. So, older configurations continue to work. But,
the recommendation of changing those lines to "Require all granted" fails because there were earlier definitions for a blanket "Deny from all" applied to the root of the filesystem. The documentation for the interaction of access_compat and mod_authz_host is scarce. As a result, we left the two lines allowing access, and added the "Require all granted" line as suggested. The latter is not necessary, but is there as a reminder that the new syntax is supported.
A caveat to the configuration using .htpasswd is that one can not use php as cgi with suexec because http authentication is not supported with that setup. That would have allowed the web php and cgi to run as boincadm directly, removing any need to change any umask, and removing the need for wwwrun to be in any group.
This requires apache to run php itself with mod_php5. We did not change the php.ini file for this project.
Move to the install directory:
cd "$installroot"/"$projectname"Then you may need to do the following (I found I didn’t need sudo since boincadm was the owner...)
sudo chown boincadm:boincadm -R .
sudo chmod g+w -R .
sudo chmod 02770 -R upload html/cache html/inc html/languages \
html/languages/compiled html/user_profile
hostname=`hostname`
sudo chgrp -R www-data log_"$hostname" upload
sudo chmod o+x html/inc && sudo chmod -R o+r html/inc
sudo chmod o+x html/languages/ html/languages/compiledSet a cronjob to start the boinc server daemons (substitute Vim for your favorite editor)
sudo EDITOR=vim crontab -e
*/5 * * * * \$INSTALLROOT/PROJECTNAME/bin/start --cronMake the PROJECTNAME_ops site password protected with whatever username/password you like
sudo htpasswd -c html/ops/.htpasswd USERNAMEOn some systems, you may have to use htpasswd2 which I think requires the full path to the .htpasswd file:
sudo htpasswd2 -c ~/projects/PROJECTNAME/html/ops/.htpasswd USERNAMEConfig apache2 to host the site and make sure the appropriate mods are installed
sudo cp ${projectname}.httpd.conf /etc/apache2/sites-available/
sudo a2ensite ${projectname}.httpd.conf
sudo service apache2 reload
sudo a2enmod cgi
sudo a2enmod php5
sudo service apache2 restartLastly, in your config.xml file, under <config>, add the following to fix a bug in the status website
<uldl_pid>/var/run/apache2.pid</uldl_pid>On openSUSE, the pid is
<uldl_pid>/var/run/httpd.pid</uldl_pid>If you need to install virtualenv and do not have or want to use sudo, follow these instructions.
curl -O https://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.11.tar.gz
tar -xzf virtualenv-1.11.tar.gz
cd virtualenv-1.11
python virtualenv.py venvEdit your .bashrc file to include something like
source ~/virtualenv-1.11/venv/bin/activateIf running in a virtualbox, make sure you port-forward port 80 to the guest port 80. The easiest way to do this is to run virtualbox as root. Apparently there are some other ways to route host:80 to host:8080 to guest:80 using iptables but I could'’t get it to work. Alternatively, you could just port-forward port 8080 and access your site at http://hosturl:8080/PROJECTNAME.
To do forward ports in virtualbox, select the virtual server and open up Settings --> Network --> Advanced (under NAT) --> Port Forward.
Additionally, we found that virtualized servers became unstable when running for long periods of time with frequent communication to clients when using the NAT network settings. The solution was to obtain a separate IP address for the virtual server and using bridged networking.