Seti@Home / BOINC 7.14.2 with Debian Buster

I just recalled that I used to contribute some processing power to the seti@home project. I’ve been able to get my login information and installed BOINC in two virtual machines on my hosts which are pretty much idle nowadays. Turns out that’s not working out-of-the-box.

In fact I never really forgot about seti@home it was one of the first projects I contributed something to. I just didn’t find time to set it up again. If I remember correct I had an older account which I was unable to login and/or merge with the newer one of 2003. I believe my first account was back in 2000/2001 not sure anymore. Anyway:

SETI@home member since	6 Nov 2003
Total credit	98,333
Recent average credit	0.06
SETI@home classic workunits	13
SETI@home classic CPU time	165 hours

By the way a really nice article about seti@home is located at the ringer E.T.’s Home Phone and definately worth reading.

Getting BOINC/seti@home working in Debian Buster

First of all I wasn’t able to easily find information on how to setup a server variant of BOINC to run seti@home. The steps for that are pretty simple, though. Don’t do that now – continue reading first!

apt-get install boinc-client
boinccmd --host localhost --passwd xxx --project_attach setiathome.berkeley.edu xxx_xxxxxx

I’m using the weak_key (xxx_xxxxxx) which you’ll find in your seti@home login interface below account keys. If you start and attach now, you’ll notice that all of your work units will fail. Keep in mind that BOINC/seti@home seems to limit work units in case you’re failing often. Hence the worst thing in such a situation one may do is to retry/reset/update all the time. You’ll end up with:

Jun 16 17:12:08 setiathome1 boinc[885]: 16-Jun-2019 17:12:08 [SETI@home] This computer has finished a daily quota of 1 tasks

Sigh. According to a thread in the message boards about daily quota of 1 task? this seems to happen in case of errors. Hence I told you above: Don’t do that now.

vsyscall

It seems the seti binary still uses vsyscalls. These have been removed in modern kernels hence your Kernel will tell you about that:

/var/log/syslog:Jun 16 16:44:52 setiathome1 kernel: [ 3222.011810] setiathome_8.00[4666] vsyscall attempted with vsyscall=none 
ip:ffffffffff600000 cs:33 sp:7fffa2344dc8 ax:ffffffffff600000 si:0 di:7fffa2344de0

Due to that the processing of your work unit will result in an error. Because the machine I am using is a virtual one specifically for seti@home I just enable vsyscall emulation by editing my /etc/default/grub and adding:

GRUB_CMDLINE_LINUX="vsyscall=emulate"

I believe it should be sufficient to run

update-grub

followed by a simple reboot to make that work. Probably (not sure – I did that anyway) update-initramfs -k all -u to update all initramfs images)

missing directories

Apart of the vsyscall thingy you might need to create two directories yourself. If you don’t your logs will moan about:

Jun 16 16:06:38 setiathome1 boinc[2643]: dir_open: Could not open directory 'slots' from '/var/lib/boinc-client'.
Jun 16 16:43:12 setiathome1 boinc[4246]: dir_open: Could not open directory 'locale' from '/var/lib/boinc-client'.

So just create them:

mkdir -p /var/lib/boinc-client/{locale,slots}

And just to make sure since a few files/folders are root-owned (not sure if that has security implications – so you might try without this, chown slots and locale then, though)

chown boinc:boinc /var/lib/boinc -R
chown boinc:boinc /var/lib/boinc-client -R

gui rpc auth

Lastly it would be nice if I am able to connect with BOINC manager from my notebook to both systems. For that to work you have to enable gui_rpc_auth. It isn’t enough to uncomment:

#BOINC_OPTS="--allow_remote_gui_rpc"

in /etc/default/boinc-client. Actually I do believe that setting does nothing (at least it didn’t work here). To make it work I had to:

# set a secure password
echo "xxx" > /etc/boinc-client/gui_rpc_auth.cfg 
# remove remote_hosts.cfg (yeah.. either I'm confused or it didn't work with those files in-place. 
# Everything in that file is commented, still... once I removed them it started to work)
# Alternatively you might try adding allowed IPs there if you're using e.g. a VPN
rm /etc/boinc-client/remote_hosts.cfg 
rm /var/lib/boinc-client/remote_hosts.cfg

And finally I had to modify /etc/boinc-client/cc_config.xml so that it does contain allow_remote_gui_rpc. The whole file looks like this:

<!--
This is a minimal configuration file cc_config.xml of the BOINC core client.
For a complete list of all available options and logging flags and their
meaning see: https://boinc.berkeley.edu/wiki/client_configuration
-->
<cc_config>
  <log_flags>
    <task>1</task>
    <file_xfer>1</file_xfer>
    <sched_ops>1</sched_ops>
  </log_flags>
  <options>
    <allow_remote_gui_rpc>1</allow_remote_gui_rpc>
  </options>
</cc_config>

Finally run BOINC

Additionally you might want to enable the service so that it gets started on boot:

systemctl enable boinc-client
systemctl start boinc-client

Verify that everything is working as expected by closely monitoring /var/log/syslog. That’s it. You may connect to it from your workstation/notebook by issuing:

boincmgr -n so.me.ip.addr -p xxx

Obviously replace so.me.ip.addr with the IP address of your boinc-client-instance.

No Comments

Post a Comment