Maintain a set of commonly-used science applications (Autodock, Charm, LAMMPS, etc.). For each app, maintain a set of app versions for various platforms and GPUs. The app versions either
are compiled with the BOINC API (preferred)
use the BOINC wrapper
are VM-based
If the app has a checkpoint mechanism, integrate with BOINC's API.
The app versions must be "safe" in the sense that running the program with arbitrary (possibly malicious) input files and cmdline parameters will not
access files outside the slot directory (i.e. no absolute paths can be specified on the cmdline)
use resources in a way that would interfere with system performance (e.g. no fork() bombs).
do anything else bad.
Each app version can have a plan class, with a corresponding XML plan class specification.
The BOINC web site will serve all the app version files, and will export a signed XML document describing the apps, app versions, and files. This document is downloaded periodically by the BOINC client.
A BOINC project can use apps from the BOINC library, and serve the files itself. To do so:
copy the corresponding directory tree from the BOINC web site (includes app version files and signatures)
run update_versions
The project doesn't have to code-sign the files.
This sets a "from library" flag in the app XML descriptor, telling the client the app version is from the app library, in which case it:
checks that the project's app version files match the app library
authenticates the files with the BOINC signing key
rather than the project signing key.
The app XML descriptor also has a timestamp, which is the update time of the app library when app was copied. If this is later than client's copy of app library info, the client refreshes the app library info.
Notes:
If multiple projects use the same library app, the client will download and store separate copies per project. It would be possible to change things so that clients get files directly from the app library, and they're shared between projects. This would be a fairly large change; it would involve server code as well as client. Maybe later.
There will be changes to the app source code to use the BOINC API. If possible, add these changes (#ifdef'd) to the app's repo.
The text was updated successfully, but these errors were encountered:
davidpanderson commentedMay 21, 2021
Maintain a set of commonly-used science applications (Autodock, Charm, LAMMPS, etc.). For each app, maintain a set of app versions for various platforms and GPUs. The app versions either
If the app has a checkpoint mechanism, integrate with BOINC's API.
The app versions must be "safe" in the sense that running the program with arbitrary (possibly malicious) input files and cmdline parameters will not
Each app version can have a plan class, with a corresponding XML plan class specification.
The BOINC web site will serve all the app version files, and will export a signed XML document describing the apps, app versions, and files. This document is downloaded periodically by the BOINC client.
A BOINC project can use apps from the BOINC library, and serve the files itself. To do so:
The project doesn't have to code-sign the files.
This sets a "from library" flag in the app XML descriptor, telling the client the app version is from the app library, in which case it:
rather than the project signing key.
The app XML descriptor also has a timestamp, which is the update time of the app library when app was copied. If this is later than client's copy of app library info, the client refreshes the app library info.
Notes:
The text was updated successfully, but these errors were encountered: