Multi-user projects

This document describes a set of BOINC server features that support projects with multiple job submitters, or users. A user may represent a single scientist, a research group, or some other organizational entity. (A "user" should not be confused with a "volunteer", which is a person who runs the BOINC client on their computer.) An example of a multi-user project is a science portal such as ​nanoHUB.org.

Such projects are typically structured so that users interact with the project through a web-based interface, and only project admins have login access to the BOINC server.

BOINC's design supports the following goals:

• The set of users may be large (1000s) and dynamic.
• The project's resources are shared fairly among users, based on quotas.
• Privacy: users cannot in general see the computational results of other users.
• Flexible access control.

User identity

Users are identified by BOINC project accounts (same as volunteers). Users may also be volunteers; i.e. they may supply computing resources to the project. (this may affect their quota; see below).

Access control

The following operations are subject to access control:

• Submitting jobs
• Creating and deprecating apps
• Creating and deprecating app versions
• Aborting jobs (possibly those submitted by other users)
• Changing access privileges

For each user, the BOINC access control system defines a set of global privileges and optionally a set of per-app privileges for each app.

The global privileges include

• submit_all_apps. If this flag is set, the user can submit jobs to any application, included those added in the future.
• manage_all_apps. If this flag is set, the user
  • has manage privileges (see below) for all apps, including those added in the future.
  • can grant and revoke the privileges of any user, except manage privileges.
  • can create and deprecate apps
  • can set user quotas (see below)

The per-app privileges include

• the ability to submit jobs to the app
• manage: if this flag is set, the user can
  • create and deprecate versions of the app
  • grant and revoke per-app permissions for this app (except manage permissions).
  • abort any job of this app
  • view the output files of any job of this app

Management privileges are controlled using a script (bin/manage_privileges) on the server; they can be granted and revoked only by project admins.

Other permissions are controlled via the manage_project.php page on the project web site.

User quotas

Each user has a quota which determines how much computing resource they get if there is contention. Roughly speaking, if a set of users are contending for resources, the amount that each one gets is proportional to their resource share.

The way in which quotas are determined is up to the project. Some possibilities:

• Each user attaches their own PCs to the BOINC project, and their quota is the recent average credit of these hosts.
• Volunteers attached to the project can assign shares of their resource to scientists, and a scientist's quota is the sum of these, weighted by the volunteer average credit.
• A user's share is increased if they contribute to the portal, e.g. by participating in the message boards.

Quotas can be manually set by users with the admin_all_apps privilege, via a web interface.

To enforce quotas, you must either:

• submit job using remote job submission, and include the allocation_priority flag in your request objects.
• otherwise, use allocation-based prioritization as part of your job-submission process.

You must run the feeder with the --priority_order option. Currently this can't be used in combination with the --all_apps option, or with homogeneous redundancy.

Resetting priorities

you can reset user priorities by running

html/ops/submit_init_priority.php

This will also assign new priorities to queued jobs.