Hello,

Not sure if this is a but or not but I have two Synology NAS running Boinc in a Docker container, Both host using the same Docker image, which I built myself. The Image uses a Debialn jessie base with Boinc installed via apt-get install. The image uses an external directory as the BOINC data directory, on first startup it copies the config files placed in /var/lib/boinc-client by the apt-get install to the external directory.

I connected to each host after starting the container and associated them with my BAM account manually via a remote boing-manager instance.

Operationally what I see is the host name toggling between the two in the website host-list page as I tell each to sync.

There are a number of Docker container implementations of boing available on Docker Hub; most of them do not use an external directory approach for data (so work in progress is lost on update or recreation of the container) I can only assume every container built from one these images has the same host ID (hence reporting this on the Bug forum) With a single container per BAM account I can see this would go unnoticed but I raises some questions:

If multiple accounts has identical host IDs how does that affect credit recording?

Does this duplication cause any issue in the BAM databases (I.e. with data distribution, clustering in indices, shard keys etc.)?

what is the impact within a single BAM account of duplicate host-ids?

Since I was planning to make my container publicly available, what to I need to do to ensure unique host ids? (I don't want to create a problem or worse get accused of credit stealing)

Thanks

Ray

Hi Ray,

Interesting approach to use Docker containers for running BOINC and using external BOINC-directories to prevent data loss. I'm not really familiar with Docker, but I understand the concept.

First of all: which BOINC-config files do you copy to the external directory? I am assuming you did a clean install of BOINC and did not add projects in your Docker image.

In the file client_state.xml you should find the unique host cpid. Here's an example of one of my hosts. I replaced the real values with dummy ones:

<client_state>

<host_info>

    <timezone>9999</timezone>

    <domain_name>xxxx</domain_name>

    <ip_addr>xxx.xxx.xxx.xxx</ip_addr>

    <host_cpid>unique_string</host_cpid>

This host cpid is the one creating your problem with the toggling of the hostname in BAM! after each sync.

You could try to leave this file out of the set BOINC-files you copy to the external directory. Afaik this file is recreated when BOINC is starting and it will create a new unique host cpid for the host. After that you can connect BAM! as account manager, your default projects should be installed on the host and you should see the 2 separate Synology-hosts in your host-list page.

Credits should not be affected by the current way you let BOINC run on the 2 Synology-hosts. Each host reports it's own work, the total is shown under your account.

Thanks for the help and the idea, If the files are created by boinc rather than shipping as part of the distro package I may be better to simply delete them from the source location (/var/lib/boinc_client on Debian) and let boinc create new ones on first container start.

I'll drain the work queue on one of the NASs and experiment. I'm totally new to Docker myself and this is a potentially useful self-training exercise. if it works I can build the container minus the initial config files, that way it wont matter if folks using it map an external drive or run fully in the container, they should always get a globally unique id.


Rank 179! You're giving me a bad case of "world rank envy" Mine would have been a little higher (I suppose I should say lower) but I lost a few (between 2 & 3) million credits in the switch over from the original SETI to Boinc, the account I had then was associated with an email on an ISP that went tits-up (excuse the British parlance) and there was no way to recover the credits.


Again thanks for the suggestion

Ray

ASIC credits gives a huge difference
On topic: check https://boinc.berkeley.edu/wiki/Host_identification_and_merging for some information about client_state.xml
I guess deleting of this single file could be enough instead of deleting other config files. Keep us posted of your results!