Custom Query (6 matches)

When you type in the command line: crypt_prog you only get the following message:

"missing command"

The output doesn't help the user giving an option to obtain help from the command. On the other side, if you type: crypt_prog -help, you get the following message:

"unrecognized command"

After checking the source code, I realized that this command lacks this option. This command line argument should be included to help users understand what this command does, and more importantly all the options that can be managed.

I have created a patch that addresses the described problems. If the patch is applied, when you run the command: crypt_prog you obtain the following message:

missing command

Try `crypt_prog -help` for more information.

If then you run crypt_prog -help you obtain the following output:

Utility program for encryption.
-genkey n private_keyfile public_keyfile
    create a key pair with n bits (512 <= n <= 1024)
    write it in hex notation
-sign file private_keyfile
    create a signature for a given file
    write it in hex notation
-sign_string string private_keyfile
    create a signature for a given string
    write it in hex notation
-verify file signature_file public_keyfile
    verify a signature
-test_crypt private_keyfile public_keyfile
    test encrypt/decrypt
-convkey o2b/b2o priv/pub input_file output_file
    convert keys between BOINC and OpenSSL format
-cert_verify file signature_file certificate_dir
    verify a signature using a directory of certificates

This information has been obtained from the beginning of the file crypt_prog.cpp. Adjoining is the patch.

DB_SCHED_RESULT_ITEM_SET and associated code has a number of algorithms that are N² in the # of results being reported. Bad if N is, say, 10000. Use std::map to avoid this

It's a surprisingly common situation: an existing cruncher decides to add a new project, and adds several new hosts dedicated to this new project. Of course, the CPID will only update for the new project if he attaches a host to one of his original projects.

But if he leaves any of his hosts orphaned, then every time they contact the scheduler, they reset the CPID to the old value. The CPID will cycle endlessly, giving unpredictable results in the exported stats.

I think that once a project has the oldest CPID, it should keep that CPID, ignoring later ones and sending the oldest CPID to those hosts that have a later CPID.

This will require a few changes: a CPID timestamp field in the database, which must be passed in the scheduler request and response, so that the server can compare the age of the provided CPID against the age of the stored CPID.

Components: Scheduler, Database, Daemon.

With workunit settings : max # of error/total/success results 2, 3, 3 minimum quorum 2 initial replication 2. If 2 users abort the WU or detach from the project, the people that have completed the WU lose their work. If it possible to: 1) Not count aborts/detached as errors? or 2) Subtract completed from errors (if 1 result is complete, 3 errors would be allowed)?

Add new fields to app_version:

1. a tab-separated list of regular expression matched against the "features" list (SSE etc.)
2. a list of regular expressions matched against the "accelerators" list (GPUs and other coprocessors)
3. a "value"

The scheduler would send the highest-value app version that for which the host matches all the reg exps

I installed a BOINC server from pretty recent code from trunk, with my source directory not being a SVN working copy. Then I made a custom change to a PHP script and ran the upgrade tool to get it installed.

The output was:

Staying in DISABLED mode
Stopping all daemons
 (No processes stopped)
Upgrading files...
Upgrading files... done
update_translations finished
Checking for DB updates...
#! /usr/bin/env php
need update update_6_16_2009
need update update_9_3_2009
need update update_3_5_2010
need update update_3_17_2010
need update update_4_21_2010
need update update_6_10_2010
Do you want to apply these updates? (y/n)

Obviously it's not possible I'm missing all those updates, since I just installed the server.

The problem is the DB updating mechanism relies on the db_revision file in the project root directory, which is only valid if make_project was run from a real SVN working copy. My source directory is not a SVN working copy (for reasons that aren't relevant here). So db_version contains "exported", and upgrade_db.php thinks I'm missing all six versioned DB updates.

Here is another situation where this could cause serious problems (hypothetical, I didn't actually try it). Suppose last week I installed a server from the server_stable branch. I'm now using r21800 of branches/server_stable (which is actually identical to r19996 in that branch). ~/projects/dbfail/db_revision contains "21800".

Then suppose today I decide to switch my server to trunk. I run svn switch to get the trunk branch, which gets me the latest code from trunk, r21867. I compile the code, and run tools/upgrade. The database update script looks at my db_revision, and sees that it's "21800". According to ops/db_update.php, the most recent DB change was in r21728, so the script thinks there are no DB updates to perform (because 21800 > 21728), and it quits without doing anything.

However, my "real" database version should have been r19453 (the revision 'trunk' had when it was copied into 'server_trunk' eight months ago). I'm now missing four database updates: made in r20807, r21021 (though marked as '20932' in db_update.php for some unknown reason), r21230, and r21728. Without those, the code in trunk won't work properly. The only way to apply them is to modify db_update.php to call the right update functions (like was necessary before the automatic stuff) and run it by hand.

We have to decouple database updates from SVN revisions.

One way would be using a "DB version number" increased monotonically on every DB update. make_project would store that version number in db_revision instead of the output of svnversion. In the stable-to-trunk situation, the version number would be 2 in stable (regardless of SVN revision), and when switching to trunk, it'd jump to 6, so the script would execute DB updates 3,4,5,6.

Another way could be to have the database update script run 'describe' queries to see what the real current schema is, and figure out what updates are necessary. But this would be quite more complex.