diff --git a/checkin_notes b/checkin_notes index cacf2bb3fd..d416ed2334 100755 --- a/checkin_notes +++ b/checkin_notes @@ -5896,3 +5896,16 @@ Charlie 13 June 2006 mac_build/ boinc.xcodeproj/ project.pbxproj + +David 13 June 2006 + - core client: don't check app disk usage more often than + every 5 min (used to be 5*disk interval) + - scheduler XML parsing code: handle XML comments + (you can now have comments in config.xml) + + client/ + app_control.C + lib/ + parse.C + sched/ + sched_config.C diff --git a/client/app_control.C b/client/app_control.C index d31fe28da4..cb23b69710 100644 --- a/client/app_control.C +++ b/client/app_control.C @@ -520,11 +520,12 @@ bool ACTIVE_TASK_SET::check_rsc_limits_exceeded() { bool do_disk_check = false; bool did_anything = false; - // disk_interval is typically 60 sec, - // and some slot dirs have lots of files. - // So only check every 5*disk_interval + // Some slot dirs have lots of files, + // so only check every min(disk_interval, 300) secs // - if (gstate.now > last_disk_check_time + 5*gstate.global_prefs.disk_interval) { + double min_interval = gstate.global_prefs.disk_interval; + if (min_interval < 300) min_interval = 300; + if (gstate.now > last_disk_check_time + min_interval) { do_disk_check = true; } for (j=0;j -An application represents a collection of related computation. -It consists of a program (perhaps with versions for different platforms) +An application +consists of a program (perhaps with versions for different platforms) and a set of workunits and results. A project can operate many applications. Applications are maintained in the application table in the BOINC DB, @@ -31,28 +31,10 @@ it is also sent the latest application version for its platform. It is sent work only if this version is the minimum or greater.

-Application versions are maintained in the app_version table -in the BOINC DB. -Each entry includes an XML document describing the -files that make up the application version: -".html_text(" - - ... - -[ ... ] - - foobar - 4 - - program_1 - - - - library_12 - -")." Application versions can be created using update_versions. +Descriptions of application versions are stored in the app_version +table in the BOINC DB. "; page_tail(); ?> diff --git a/doc/client_app.php b/doc/client_app.php index b59c294eea..5c485e2c96 100644 --- a/doc/client_app.php +++ b/doc/client_app.php @@ -39,15 +39,6 @@ as well as the minimum checkpoint period.

Files created by the API implementation, read by the core client:

diff --git a/doc/files.php b/doc/files.php index 9c0893bba7..609bbbb5bf 100644 --- a/doc/files.php +++ b/doc/files.php @@ -14,141 +14,11 @@ Examples of files: The BOINC core client transfers files to and from project-operated data servers using HTTP.

-A file is described by an XML element of the form -".html_text(" - - foobar - http://a.b.c/foobar - http://x.y.z/foobar - ... - 123123123123 - 134423 - 200000 - 1 - [ ] - [ ] - [ ] - [ ] - [ ] - [ ] - [ ] - -")." -The elements are as follows: -"; -list_start(); -list_item( - "name", - "The file's name, which must be unique within the project. - If you want to use participant hosts on which - filenames are case-insensitive (e.g. Windows) - this uniqueness is case-insensitive." -); -list_item("url", - "a URL where the file is (or will be) located on a data server." -); -list_item("md5_cksum", "The MD5 checksum of the file." -); -list_item("nbytes", - "the size of the file in bytes." -); -list_item("max_nbytes", - "The maximum allowable size of the file in bytes (may be greater than 2^32). - This is used to prevent flooding data servers with bogus data." -); -list_item("status", - "0 if the file is not present, - 1 if the file is present, or a negative error code if there was a - problem in downloading or generating the file." -); -list_item("generated_locally", - "If present, indicates that the file will be generated by an application on - the client, as opposed to being downloaded." -); -list_item("executable", - "If present, indicates that the file protections should be set to allow - execution." -); -list_item("upload_when_present", - "If present, indicates that the file should be uploaded - when the application finishes. - The file is uploaded even if the application doesn't - finish successfully. - API functions are available for - uploading files prior to - finishing computation. -"); -list_item("sticky", - "If present, indicates that the file should be retained - on the client after its initial use." -); -list_item("signature_required", - "If present, indicates that the file should be verified with an - RSA signature. - This generally only applies to executable files." -); -list_item("no_delete", - "If present for an input (workunit) file, - indicates that the file should NOT be removed from the data server's - download directory when the workunit is completed. - Use this if a particular input file or files are used by more than one - workunit, or will be used by future workunits. -

- If present for an output (result) file, - indicates that the file should NOT be removed from the data server's upload - directory when the corresponding workunit is completed. - Use with caution - this may cause your upload directory to overflow." -); -list_item("report_on_rpc", - "Include a description of this file in scheduler RPC requests, - so that the scheduler may send appropriate work - using locality scheduling." -); -list_end(); -echo " -

Once a file is created (on a data server or a participant host) it is immutable. This means that all replicas of that file are assumed to be identical. -

File references

-

-Files may be associated with workunits, -results and -application versions. -Each such association is represented by an XML element of the form -".html_text(" - - foobar - [ input ] - [ ] - -")." -The elements are as follows: -"; -list_start(); -list_item("file_name", "Specifies a file."); -list_item("open_name", - "The name by which the application will refer to the file. - Applications access files using - the following functions: - 

-        char physical_name[256];
-        boinc_resolve_filename(\"input\", physical_name, 256);
-        fopen(physical_name, \"r\")
-
- In this example, open_name is 'input'. - It is mapped, at runtime, to a path that includes - the filename ('foobar' in the example above). -"); -list_item("main_program", - "Relevant only for files associated with application versions. - It indicates that this file is the application's main program. -"); -list_end(); - -echo "

File management

BOINC's default behavior is to delete files around diff --git a/doc/sandbox.php b/doc/sandbox.php index 568bce5d73..846ebdbaba 100644 --- a/doc/sandbox.php +++ b/doc/sandbox.php @@ -1,4 +1,19 @@ +In our design, BOINC applications run under a specially-created account +having a minimal set of privileges. +Previously, the applications typically ran as the user who installed BOINC, +and had the full privileges of that account. +"; function prot($user, $group, $perm) { return " @@ -20,11 +35,15 @@ $mm6555 = prot('boinc_master', 'boinc_master', '0555+setuid+setgid'); $mm6770 = prot('boinc_master', 'boinc_master', '0770+setuid+setgid'); $mm0775 = prot('(installing user)', 'admin', '0775'); -function show_dir($name, $prot, $contents) { +$colors = array('ddddff', 'ccccff', 'bbbbff'); + +function show_dir($level, $name, $prot, $contents) { + global $colors; + $color = $colors[$level]; $x = " - +
-
$name $prot + $name $prot "; for ($i=0; $i$prot
+ $name $prot
"; } echo " -

The BOINC installer creates two users and two groups: +

+Our design uses two users and two groups, +both specially created for use by BOINC. +These users and groups are created by the installation process.

  • Group: boinc_master
  • Group: boinc_project
  • User: boinc_master
      -
    • Primary Group: boinc_master -
    • Supplementary Groups: boinc_project +
    • Primary group: boinc_master +
    • Supplementary groups: boinc_project
  • User: boinc_project
      -
    • Primary Group: boinc_project -
    • Supplementary Groups: none +
    • Primary group: boinc_project +
    • Supplementary groups: none
-Both groups boinc_project and boinc_master are added to the Supplementary Groups Lists of those other users who are members of group admin. This gives admin users full access to all BOINC and project files. -

-

The following diagram shows user, group and permissions for the BOINC file and directory tree:

+On Mac OS X, boinc_project and boinc_master +are added to the Supplementary Groups Lists of those other users +who are members of group admin. +This gives admin users full access to all BOINC and project files. +

+The following diagram shows user, group and permissions +for the BOINC file and directory tree: +

"; echo - show_dir('BOINC data', $mp0750, array( - show_dir('projects', $mp0750, array( - show_dir('setiathome.berkeley.edu', $mp0770, array( + show_dir(0, 'BOINC data', $mp0750, array( + show_dir(1, 'projects', $mp0750, array( + show_dir(2, 'setiathome.berkeley.edu', $mp0770, array( show_file('files created by BOINC Client', $mp0770), show_file('files created by project apps', $pp0770) )) )), - show_dir('slots', $mp0750, array( - show_dir('0', $mp0770, array( + show_dir(1, 'slots', $mp0750, array( + show_dir(2, '0', $mp0770, array( show_file('files created by BOINC Client', $mp0770), show_file('files created by project apps', $pp0770) )) )), - show_dir('switcher (directory)', $mm0770, array( + show_dir(1, 'switcher (directory)', $mm0770, array( show_file('switcher (executable)', $pp6550) )), - show_dir('locale', $mm0770, array( - show_dir('de', $mm0770, array( + show_dir(1, 'locale', $mm0770, array( + show_dir(2, 'de', $mm0770, array( show_file('BOINC Manager.mo', $mm0770), show_file('wxstd.mo', $mm0770) )) @@ -100,7 +127,7 @@ echo echo "

"; echo - show_dir('BOINC executables', $mm0775, array( + show_dir(0, 'BOINC executables', $mm0775, array( show_file('BOINC Manager', $mm2555), show_file('BOINC Client', $mm6555), )); @@ -111,37 +138,57 @@ echo "

  • BOINC Client runs setuid and setgid to boinc_master:boinc_master. -
  • Because user boinc_master is a member of both groups boinc_master and boinc_project, -BOINC Client can set files and directories it creates to either group and has full access to files and -directories in both groups. -
  • BOINC Client does not directly execute project applications. It runs the helper application switcher, -passing the request in the argument list. switcher runs setuid boinc_project and setgid -boinc_project, so all project applications inherit user and group boinc_project. +
  • Because user boinc_master is a member of both groups +boinc_master and boinc_project, +BOINC Client can set files and directories it creates to either group +and has full access to files and directories in both groups. +
  • BOINC Client does not directly execute project applications. +It runs the helper application switcher, +passing the request in the argument list. +switcher runs setuid boinc_project and setgid +boinc_project, +so all project applications inherit user and group boinc_project. This blocks project applications from accessing unauthorized files. -
  • BOINC Manager runs setgid to group boinc_master. It can access all files in group boinc_master. -It runs as the user who launched it, which is necessary for a number of GUI features to work correctly. -Although this means that BOINC Manager cannot directly access files created by project applications, there is no -need for it to do so. -
  • BOINC Manager and BOINC Client set their umasks to 007, which is inherited by all child applications. The -default permissions for all files and directories they create prevent access outside the user and group. -
  • Non-admin users have no direct access to BOINC or project files. They can access these files only by running -the BOINC Manager and Client. -
  • The switcher application is inside the switcher directory. This directory is accessible only -by user and group boinc_master, so that project applications cannot modify the switcher +
  • BOINC Manager runs setgid to group boinc_master. +It can access all files in group boinc_master. +It runs as the user who launched it, +which is necessary for a number of GUI features to work correctly. +Although this means that BOINC Manager cannot directly access files +created by project applications, there is no need for it to do so. +
  • BOINC Manager and BOINC Client set their umasks to 007, +which is inherited by all child applications. +The default permissions for all files and directories they create prevent +access outside the user and group. +
  • Non-admin users have no direct access to BOINC or project files. +They can access these files only by running the BOINC Manager and Client. +
  • The switcher application is inside the switcher directory. +This directory is accessible only by user and group boinc_master, +so that project applications cannot modify the switcher application's permissions or code. -
  • Users with admin access are members of groups boinc_master and boinc_project so that they do have -direct access to all BOINC and project files to simplify maintenance and administration. -
  • The RPC password file gui_rpc_auth.cfg is accessible only by user and group boinc_master. In other -words, only BOINC Manager, BOINC Client and authorized administrative users can read or modify it, limiting access to -most BOINC RPC functions. -
  • BOINC Manager restricts certain functions to authorized users: Attach to Project, Detach from Project, Reset Project. -If an unauthorized user requests these functions, the Manager requires password authentication. -
  • On Macintosh computers, the actual directory structure of the BOINC Manager application bundle is more complex -than implied by the box BOINC executables in the BOINC tree diagram shown above. -
  • Some Macintosh system administrators may wish to limit which users can perform BOINC Manager functions (Activity Menu, -etc.). This can be done by moving BOINC Manager out of the /Applications directory into a directory with restricted access. +
  • Users with admin access are members of groups boinc_master +and boinc_project so that they do have +direct access to all BOINC and project files +to simplify maintenance and administration. +
  • The RPC password file gui_rpc_auth.cfg +is accessible only by user and group boinc_master. +In other words, only BOINC Manager, BOINC Client and +authorized administrative users can read or modify it, +limiting access to most BOINC RPC functions. +
  • BOINC Manager restricts certain functions to authorized users: +Attach to Project, Detach from Project, Reset Project. +If an unauthorized user requests these functions, +the Manager requires password authentication. +
  • On Macintosh computers, the actual directory structure +of the BOINC Manager application bundle is more complex +than implied by the box BOINC executables in the BOINC +tree diagram shown above. +
  • Some Macintosh system administrators may wish to limit which users +can perform BOINC Manager functions (Activity Menu, etc.). +This can be done by moving BOINC Manager out of the +/Applications directory into a directory with restricted access.

"; +page_tail(); ?> diff --git a/doc/xml.php b/doc/xml.php new file mode 100644 index 0000000000..fe55d9fc27 --- /dev/null +++ b/doc/xml.php @@ -0,0 +1,171 @@ + +
  • The BOINC DB +
  • Scheduler request and reply messages +
  • The client state file +
  • GUI RPCs + +Some of these XML elements are described here +(not all fields are present in all contexts). + +

    Files

    +

    +A file is described by an XML element of the form +".html_text(" + + foobar + http://a.b.c/foobar + http://x.y.z/foobar + ... + 123123123123 + 134423 + 200000 + 1 + [ ] + [ ] + [ ] + [ ] + [ ] + [ ] + [ ] + +")." +The elements are as follows: +"; +list_start(); +list_item( + "name", + "The file's name, which must be unique within the project. + If you want to use participant hosts on which + filenames are case-insensitive (e.g. Windows) + this uniqueness is case-insensitive." +); +list_item("url", + "a URL where the file is (or will be) located on a data server." +); +list_item("md5_cksum", "The MD5 checksum of the file." +); +list_item("nbytes", + "the size of the file in bytes." +); +list_item("max_nbytes", + "The maximum allowable size of the file in bytes (may be greater than 2^32). + This is used to prevent flooding data servers with bogus data." +); +list_item("status", + "0 if the file is not present, + 1 if the file is present, or a negative error code if there was a + problem in downloading or generating the file." +); +list_item("generated_locally", + "If present, indicates that the file will be generated by an application on + the client, as opposed to being downloaded." +); +list_item("executable", + "If present, indicates that the file protections should be set to allow + execution." +); +list_item("upload_when_present", + "If present, indicates that the file should be uploaded + when the application finishes. + The file is uploaded even if the application doesn't + finish successfully. + API functions are available for + uploading files prior to + finishing computation. +"); +list_item("sticky", + "If present, indicates that the file should be retained + on the client after its initial use." +); +list_item("signature_required", + "If present, indicates that the file should be verified with an + RSA signature. + This generally only applies to executable files." +); +list_item("no_delete", + "If present for an input (workunit) file, + indicates that the file should NOT be removed from the data server's + download directory when the workunit is completed. + Use this if a particular input file or files are used by more than one + workunit, or will be used by future workunits. +

    + If present for an output (result) file, + indicates that the file should NOT be removed from the data server's upload + directory when the corresponding workunit is completed. + Use with caution - this may cause your upload directory to overflow." +); +list_item("report_on_rpc", + "Include a description of this file in scheduler RPC requests, + so that the scheduler may send appropriate work + using locality scheduling." +); +list_end(); +echo " + +

    File references

    +

    +Files may be associated with workunits, +results and +application versions. +Each such association is represented by an XML element of the form +".html_text(" + + foobar + [ input ] + [ ] + +")." +The elements are as follows: +"; +list_start(); +list_item("file_name", "Specifies a file."); +list_item("open_name", + "The name by which the application will refer to the file. + Applications access files using + the following functions: + 

    +        char physical_name[256];
+        boinc_resolve_filename(\"input\", physical_name, 256);
+        fopen(physical_name, \"r\")
+
    + In this example, open_name is 'input'. + It is mapped, at runtime, to a path that includes + the filename ('foobar' in the example above). +"); +list_item("main_program", + "Relevant only for files associated with application versions. + It indicates that this file is the application's main program. +"); +list_end(); + +echo " + +

    App versions

    + +Each entry in the app version table includes an XML document describing the +files that make up the application version: +".html_text(" + + ... + +[ ... ] + + foobar + 4 + + program_1 + + + + library_12 + +")." +"; +page_tail(); +?> diff --git a/doc/yeti.jpg b/doc/yeti.jpg deleted file mode 100644 index 392340cb5e..0000000000 Binary files a/doc/yeti.jpg and /dev/null differ diff --git a/lib/parse.C b/lib/parse.C index 2cbed14515..558dd70b9d 100644 --- a/lib/parse.C +++ b/lib/parse.C @@ -409,7 +409,13 @@ int skip_unrecognized(char* buf, FILE* in) { // Get next XML element or tag. // If it's a close tag, or the contents pointer is NULL, just return the tag. -// Otherwise return the contents. +// Otherwise return the contents also. +// +// Skips comments, single- or multi-line () +// +// Returns false if text was found that wasn't a tag. +// (can just call again in this case). +// // Note: this is not a general XML parser, but it can parse both // X // and @@ -422,7 +428,14 @@ bool get_tag(FILE* f, char* tag, char* contents) { if (contents) *contents = 0; while (1) { - fgets(buf, 1024, f); + if (!fgets(buf, 1024, f)) return false; + if (strstr(buf, "")) break; + if (!fgets(buf, 1024, f)) return false; + } + continue; + } p = strchr(buf, '<'); if (p) break; } @@ -465,7 +478,7 @@ bool get_tag(FILE* f, char* tag, char* contents) { // Copy contents until find close tag // while (1) { - fgets(buf, 1024, f); + if (!fgets(buf, 1024, f)) return false; if (strchr(buf, '<')) return true; strip_whitespace(buf); strcat(contents, buf); diff --git a/sched/sched_config.C b/sched/sched_config.C index d724fed3f0..5ac8632ba0 100644 --- a/sched/sched_config.C +++ b/sched/sched_config.C @@ -130,14 +130,6 @@ int SCHED_CONFIG::parse_file(const char* dir) { int retval; sprintf(path, "%s/%s", dir, CONFIG_FILE); -#if 0 - char* p; - retval = read_file_malloc(path, p); - if (retval) return retval; - retval = parse(p); - free(p); - return retval; -#endif FILE* f = fopen(path, "r"); if (!f) return ERR_FOPEN; retval = parse(f);