Account management systems

To create an account with BOINC projects, a participant must:

  • Locate BOINC project web sites, e.g. using Google.
  • Read the web sites, and decide which to join;
  • Download and install the BOINC client software.

and then for each selected project:

  • Go through the Attach to Project wizard.

If the participant chooses N projects, there are N web sites to visit and N Wizards to complete. This is tedious if there are lots of projects.

This document describes BOINC's support for 'account management systems', which streamline the process of finding and joining BOINC projects. The account manager concept was conceived and developed jointly by GridRepublic and BOINC. A typical account management system is implemented as a web site. The participant experience is:

  • Visit the account manager site, set up a 'meta-account' (name, email, password), browse a list of projects, and click checkboxes to select projects.
  • Download and install the BOINC client software from the account manager.
  • Enter the meta-account name and password in a BOINC client dialog.

This requires many fewer interactions than the manual approach.


An account management system works as follows:

  1. The participant sets up his meta-account and selects projects.
  2. The account manager issues a create account RPC to each selected project.
  3. the participant downloads and installs the BOINC client software from the account manager. The install package includes a file (specific to the account manager) containing the URL of the account manager.
  4. The BOINC client runs, and asks the participant to enter the name and password of his meta-account.
  5. The BOINC client does an RPC to the account manager, obtaining a list of accounts. It then attaches to these accounts and proceeds.

There are web RPCs to create, look up, and modify accounts.


If hackers break into an account manager server, they could potentially cause the account manager to instruct all its clients to attach to malicious a BOINC project that runs a malicious application. To prevent this type of attack, the URLs distributed by an account manager are digitally signed. Each AM has its own signing key pair. The public key is distributed with the AM's configuration file and in all RPC replies. The private key should be stored only on a physically secure, non-connected host that is used to sign URLs.

To sign URLs, compile crypt_prog, BOINC's encryption utility program. Generate a key pair and generate signatures for your URLs. At some point you'll need to commit to a permanent key pair, at which point you should move the private key to the signing machine (disconnected). Make a copy or two on CD-ROM also, and/or print it out on paper; keep these in a safe place. Delete all other copies of the private key.

Farm managers

The AM mechanism can be used to implement systems for configuring and controlling BOINC on large clusters. We call such systems 'farm managers'. Farm managers may want to provide fine-grained control over clients, e.g. the ability to suspend/resume results. This can be done using GUI RPCs (assuming that the farm manager able to contact clients via HTTP on the GUI RPC port). However, the farm manager must learn the GUI RPC port and password for each client. To support this, the AM configuration file (see below) can specify that the GUI RPC port and password are to be included in each AM RPC request.

If a farm manager uses GUI RPC to attach/detach projects, it should not use the AM mechanism for this purpose. I.e., its AM RPC replies should not list any projects. The function of the AM mechanism, in this case, is to allow sysadmins to set up new clients by copying files. The AM mechanism takes care of registering new clients centrally.

Keyword-based project assignment

The AM can be used to make systems that dynamically assign volunteers to projects based on keywords. Such a system provides an interface that lets users browse keywords and tag them with either Yes or No. It then attaches the user's computers to projects based on these keywords, and exports them to the client so that they can be used in scheduling.

Account manager RPCs

An account manager must provide a get_project_config.php file containing its name and minimum password length, and containing a <account_manager/> tag.

In addition, an account manager must provide the following RPC, which uses an HTTP POST request. In PHP, the input is available as

BASE_URL/rpc.php, where BASE_URL is the URL of the account manager web site.
   ... [ global preferences ]
        ... [ global preferences ]
    [ ... other projects ]
    [ <gui_rpc_port>N</gui_rpc_port> ]
    [ <gui_rpc_password>xxxx</gui_rpc_password> ]
    [ <opaque>
         ... arbitrary XML
    </opaque> ]

Two sets of global preferences are included. The one enclosed in <working_global_preferences> is the one currently in effect on the client; it includes local modifications (overrides) to the web-based preferences.


    <name>Account Manager Name</name>
    [ <message>this is a message</message> ]
    [ ... ]
    [ <error>MSG</error> ]
    [ <repeat_sec>xxx</repeat_sec> ]
    [ <no_project_notices>0|1</no_project_notices> ]
        [ <source_project>http://a.b.c</source_project> ]
        [ <source_scheduler>http://a.b.c</source_scheduler> ]
        ... [ global preferences ]
    [ <host_venue>venue</host_venue> ]
    [ <opaque>
         ... arbitrary XML
    </opaque> ]
       [ <update>0|1</update> ]
       [ <detach>0|1</detach> ]
       [ <suspend>0|1</suspend> ]
       [ <abort_not_started>0|1</abort_not_started> ]
       [ <dont_request_more_work>0|1</dont_request_more_work> ]
       [ <detach_when_done>0|1</detach_when_done> ]
       [ <resource_share>X</resource_share> ]
       [ <no_cpu>0|1</no_cpu> ]
       [ <no_cuda>0|1</no_cuda> ]
       [ <no_ati>0|1</no_ati> ]
       [ <no_rsc>RSC_NAME</no_rsc> ]
Returns a list of the accounts associated with this meta-account. The arguments are:
  • password_hash: the account password, hashed as MD5(password_lowercase(name)).
  • host_cpid: Identifies the host.
  • previous_host_cpid: The host identifier passed in the previous RPC. Host identifiers can change occasionally. This lets the account manager maintain host identity.
  • domain_name: The host's domain name.
  • run mode: The current mode (always/auto/never).
  • gui_rpc_port, gui_rpc_password: GUI RPC information. Included only if the <send_gui_rpc_info> element is included in the AM URL file (see above).
  • global_preferences: The current global preferences.
  • host_info: A description of the host's hardware and software (6.12.7+)
  • venue: The host venue
  • opaque: Opaque data received from the AMS in the previous RPC.
  • no_project_notices: If nonzero, suppress the display of notices from projects (but still display notices from the account manager). 7.0.65+.
  • projects: A list of currently attached projects. For each project:
    • url: the project's master URL
    • name: the project's name
    • account_key: the user's account key on this project
    • hostid: the host's database ID with this project
    • not_started_dur: Estimated duration (elapsed time) of unstarted jobs (6.12.7+)
    • in_progress_dur: Estimated duration (elapsed time) of jobs in progress (6.12.7+)
    • suspended_via_gui: whether project is suspended (via GUI or by the AM)
    • attached_via_acct_mgr: whether this project is attached via account manager (6.12.7+)
    • dont_request_more_work: whether work fetch is suspended for this project (6.12.7+)
    • detach_when_done: whether project is set to be detached when done (6.12.7+)
    • ended: whether project has ended (6.12.7+)

The return values are:

  • repeat_sec: A time interval after which another RPC should be done.
  • signing_key: The public key used to sign URLs, in an encoded notation. Use the BOINC crypt_prog program to generate this.
  • message: A message to be displayed to the user.
  • global_preferences: New global preferences. Included only if these are newer than those in the request message.
  • opaque: Arbitrary XML. Will be included in the next request message from the client. Use this e.g. to store a host ID.
  • rss_feeds: A list of RSS feeds to be displayed as Notices by the BOINC Manager. Typically this is a feed of news items from the account manager.
  • account: An account to which the client should attach. For each account, the following items are returned:
    • url: The project URL
    • url_signature: A signature for the URL. Use the BOINC crypt_prog program to generate this.
    • authenticator: The account's authenticator. This may be a strong or weak authenticator. NOTE: don't send weak authenticators to pre-6.13 clients; if the user changes their password, the weak authenticator changes, and pre-6.13 clients are not able to handle this. It's OK to send weak authenticators to 6.13+.
    • detach: If nonzero, the client should detach this project.
    • update: If nonzero, the client should contact this project to get new global preferences.
    • dont_request_more_work: If nonzero, don't request any more work from this project.
    • detach_when_done: If nonzero, detach from this project when all work is completed
    • suspend: suspend this project (6.12.7+)
    • abort_not_started: abort unstarted jobs for this project (6.12.7+)
    • resource_share: Specifies a resource share for this project. If present, this overrides the resource share reported by the project. Thus, account managers can provide per-host control of resource share.
    • no_cpu, no_cuda, no_ati: If set, don't fetch CPU/NVIDIA/ATI jobs from this project. Send these to 6.12.8+ client. For 7.0+ clients, these elements are deprecated, and have been replaced by
    • <no_rsc>RSC_NAME</no_rsc>: RSC_NAME is CPU, NVIDIA, ATI, or intel_gpu.
  • user_keywords: lists of keywords for which user preferences are Yes or No.

NOTE: the XML must be as above, with the <url> and <authenticator> elements on a single line, and the <account> and </account> tags on separate lines.

Host identification

BOINC uses two ID spaces for hosts:

  • Cross-project ID (CPID). This is used in the statistics data exported by projects. The 'authoritative' CPID is stored on the host itself. A host's CPID changes whenever it attaches to a new project. CPID is propagated to projects in scheduler RPCs. If a host is attached to several projects, its CPID (as reported by those projects) may be inconsistent for several days. Because of these properties, CPID is not useful as a primary host identifier.
  • Project database ID (DBID). This is a project-specific integer identifier. On a given host, it changes only in the rare case where a user copies state files from one computer to another; in that case, one of the two computers is assigned a new ID after its next scheduler RPC.

An account manager RPC request includes the host's CPID, and its DBID on all projects to which it's attached (see above).

A suggested method of maintaining a user's hosts is as follows:

  • Maintain a host table with columns
    • user ID
    • project ID
    • DBID
    • CPID
  • On each account manager RPC, for each reported project, look up (user ID, project ID, DBID) in the host table (where 'DBID' is the one passed in the RPC request). If no record is found, create one. In any case, update the record with the CPID from the RPC request.
  • To show the user a list of their hosts, with current per-project credit: do a show_user.php RPC to each project to get a list of hosts. Update the corresponding records in the host table, based on the DBIDs returned by show_user.php. Delete any host table entries for this user/project that don't appear in the RPC reply. Ignore the CPIDs returned by the show_user RPC (they may not be consistent). Then do a query on the host table, grouping by CPID.

Client Initialization

By including appropriate initialization files in the client installer, you can cause the client to attach to a particular meta-account, or to prompt the user to create a meta-account.

Last modified 13 months ago Last modified on 07/31/17 15:59:50