mirror of https://github.com/BOINC/boinc.git
*** empty log message ***
svn path=/trunk/boinc/; revision=10329
This commit is contained in:
David Anderson
parent
84ec096e79
commit
4811c240b3
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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<active_tasks.size();j++) {
|
||||
|
|
|
|||
26
doc/app.php
26
doc/app.php
|
|
@ -3,8 +3,8 @@ require_once("docutil.php");
|
|||
page_head("Applications and versions");
|
||||
echo "
|
||||
<p>
|
||||
An <b>application</b> represents a collection of related computation.
|
||||
It consists of a program (perhaps with versions for different platforms)
|
||||
An <b>application</b>
|
||||
consists of a program (perhaps with versions for different platforms)
|
||||
and a set of <a href=work.php>workunits</a> and <a href=result.php>results</a>.
|
||||
A project can operate many applications.
|
||||
Applications are maintained in the <b>application</b> 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.
|
||||
|
||||
<p>
|
||||
Application versions are maintained in the <b>app_version</b> table
|
||||
in the BOINC DB.
|
||||
Each entry includes an XML document describing the
|
||||
files that make up the application version:
|
||||
".html_text("
|
||||
<file_info>
|
||||
...
|
||||
</file_info>
|
||||
[ ... ]
|
||||
<app_version>
|
||||
<app_name>foobar</app_name>
|
||||
<version_num>4</version_num>
|
||||
<file_ref>
|
||||
<file_name>program_1</file_name>
|
||||
<main_program/>
|
||||
</file_ref>
|
||||
<file_ref>
|
||||
<file_name>library_12</file_name>
|
||||
</file_ref>
|
||||
</app_version>")."
|
||||
Application versions can be created using
|
||||
<a href=tool_update_versions.php>update_versions</a>.
|
||||
Descriptions of application versions are stored in the <b>app_version</b>
|
||||
table in the BOINC DB.
|
||||
";
|
||||
page_tail();
|
||||
?>
|
||||
|
|
|
|||
|
|
@ -39,15 +39,6 @@ as well as the minimum checkpoint period.
|
|||
<p>
|
||||
<b>Files created by the API implementation, read by the core client:</b>
|
||||
<ul>
|
||||
<li>
|
||||
<b>fraction_done.xml</b>:
|
||||
contains the WU fraction done and the current CPU time from start of WU.
|
||||
Written by the timer routine as needed.
|
||||
|
||||
<li>
|
||||
<b>checkpoint_cpu.xml</b>
|
||||
CPU time (from start of WU) at last checkpoint.
|
||||
Written by checkpoint_completed.
|
||||
|
||||
</ul>
|
||||
<p>
|
||||
|
|
|
|||
130
doc/files.php
130
doc/files.php
|
|
@ -14,141 +14,11 @@ Examples of files:
|
|||
The BOINC core client transfers files to and from project-operated
|
||||
<b>data servers</b> using HTTP.
|
||||
<p>
|
||||
A file is described by an XML element of the form
|
||||
".html_text("
|
||||
<file_info>
|
||||
<name>foobar</name>
|
||||
<url>http://a.b.c/foobar</url>
|
||||
<url>http://x.y.z/foobar</url>
|
||||
...
|
||||
<md5_cksum>123123123123</md5_cksum>
|
||||
<nbytes>134423</nbytes>
|
||||
<max_nbytes>200000</max_nbytes>
|
||||
<status>1</status>
|
||||
[ <generated_locally/> ]
|
||||
[ <executable/> ]
|
||||
[ <upload_when_present/> ]
|
||||
[ <sticky/> ]
|
||||
[ <signature_required/> ]
|
||||
[ <no_delete/> ]
|
||||
[ <report_on_rpc/> ]
|
||||
</file_info>
|
||||
")."
|
||||
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
|
||||
<a href=int_upload.php>uploading files prior to
|
||||
finishing computation</a>.
|
||||
");
|
||||
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.
|
||||
<p>
|
||||
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 <a href=sched_locality.php>locality scheduling</a>."
|
||||
);
|
||||
list_end();
|
||||
echo "
|
||||
<p>
|
||||
Once a file is created (on a data server or a participant host) it
|
||||
is <b>immutable</b>.
|
||||
This means that all replicas of that file are assumed to be identical.
|
||||
|
||||
<a name=file_ref></a>
|
||||
<h3>File references</h3>
|
||||
<p>
|
||||
Files may be associated with <a href=work.php>workunits</a>,
|
||||
<a href=result.php>results</a> and
|
||||
<a href=app.php>application versions</a>.
|
||||
Each such association is represented by an XML element of the form
|
||||
".html_text("
|
||||
<file_ref>
|
||||
<file_name>foobar</file_name>
|
||||
[ <open_name>input</open_name> ]
|
||||
[ <main_program/> ]
|
||||
</file_ref>
|
||||
")."
|
||||
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
|
||||
<a href=api.php>the following functions</a>:
|
||||
<pre>
|
||||
char physical_name[256];
|
||||
boinc_resolve_filename(\"input\", physical_name, 256);
|
||||
fopen(physical_name, \"r\")
|
||||
</pre>
|
||||
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 "
|
||||
<h3>File management</h3>
|
||||
<p>
|
||||
BOINC's default behavior is to delete files around
|
||||
|
|
|
|||
143
doc/sandbox.php
143
doc/sandbox.php
|
|
@ -1,4 +1,19 @@
|
|||
<?php
|
||||
require_once("docutil.php");
|
||||
page_head("Sandbox design");
|
||||
|
||||
echo "
|
||||
This document describes a proposed modification to the Unix
|
||||
(including Linux and Mac OS X) versions of BOINC.
|
||||
The goal of this change is to 'sandbox' BOINC applications,
|
||||
i.e. to limit the amount of damage that a malicious
|
||||
or malfunctioning application can cause.
|
||||
<p>
|
||||
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 = "
|
||||
<table cellpadding=6 cellspacing=0 border=1 width=100%>
|
||||
<table bgcolor=$color cellpadding=6 cellspacing=0 border=1 width=100%>
|
||||
<tr>
|
||||
<td valign=top><b>$name</b> <font size=-2>$prot</font></td><td valign=top>
|
||||
<td valign=top><b>$name</b> <font size=-1>$prot</font></td><td valign=top>
|
||||
";
|
||||
for ($i=0; $i<sizeof($contents); $i++) {
|
||||
if ($i) $x .= '<br>';
|
||||
|
|
@ -40,51 +59,59 @@ function show_dir($name, $prot, $contents) {
|
|||
|
||||
function show_file($name, $prot) {
|
||||
return "
|
||||
$name <font size=-2>$prot</font><br>
|
||||
$name <font size=-1>$prot</font><br>
|
||||
";
|
||||
}
|
||||
|
||||
echo "
|
||||
|
||||
<p>The BOINC installer creates two users and two groups:
|
||||
<p>
|
||||
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.
|
||||
<ul>
|
||||
<li>Group: <b>boinc_master</b>
|
||||
<li>Group: <b>boinc_project</b>
|
||||
<li>User: <b>boinc_master</b>
|
||||
<ul>
|
||||
<li>Primary Group: <b>boinc_master</b>
|
||||
<li>Supplementary Groups: <b>boinc_project</b>
|
||||
<li>Primary group: <b>boinc_master</b>
|
||||
<li>Supplementary groups: <b>boinc_project</b>
|
||||
</ul>
|
||||
<li>User: <b>boinc_project</b>
|
||||
<ul>
|
||||
<li>Primary Group: <b>boinc_project</b>
|
||||
<li>Supplementary Groups: none
|
||||
<li>Primary group: <b>boinc_project</b>
|
||||
<li>Supplementary groups: none
|
||||
</ul>
|
||||
</ul>
|
||||
Both groups <b>boinc_project</b> and <b>boinc_master</b> are added to the Supplementary Groups Lists of those other users who are members of group <b>admin</b>. This gives admin users full access to all BOINC and project files.
|
||||
</p>
|
||||
<p>The following diagram shows user, group and permissions for the BOINC file and directory tree:</p>
|
||||
On Mac OS X, <b>boinc_project</b> and <b>boinc_master</b>
|
||||
are added to the Supplementary Groups Lists of those other users
|
||||
who are members of group <b>admin</b>.
|
||||
This gives admin users full access to all BOINC and project files.
|
||||
<p>
|
||||
The following diagram shows user, group and permissions
|
||||
for the BOINC file and directory tree:
|
||||
<p>
|
||||
";
|
||||
|
||||
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 "<br><br>";
|
||||
|
||||
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 "
|
|||
|
||||
<ul>
|
||||
<li>BOINC Client runs setuid and setgid to <b>boinc_master:boinc_master</b>.
|
||||
<li>Because user <b>boinc_master</b> is a member of both groups <b>boinc_master</b> and <b>boinc_project</b>,
|
||||
BOINC Client can set files and directories it creates to either group and has full access to files and
|
||||
directories in both groups.
|
||||
<li>BOINC Client does not directly execute project applications. It runs the helper application <i>switcher</i>,
|
||||
passing the request in the argument list. <i>switcher</i> runs setuid <b>boinc_project</b> and setgid
|
||||
<b>boinc_project</b>, so all project applications inherit user and group <b>boinc_project</b>.
|
||||
<li>Because user <b>boinc_master</b> is a member of both groups
|
||||
<b>boinc_master</b> and <b>boinc_project</b>,
|
||||
BOINC Client can set files and directories it creates to either group
|
||||
and has full access to files and directories in both groups.
|
||||
<li>BOINC Client does not directly execute project applications.
|
||||
It runs the helper application <i>switcher</i>,
|
||||
passing the request in the argument list.
|
||||
<i>switcher</i> runs setuid <b>boinc_project</b> and setgid
|
||||
<b>boinc_project</b>,
|
||||
so all project applications inherit user and group <b>boinc_project</b>.
|
||||
This blocks project applications from accessing unauthorized files.
|
||||
<li>BOINC Manager runs setgid to group <b>boinc_master</b>. It can access all files in group <b>boinc_master</b>.
|
||||
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.
|
||||
<li>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.
|
||||
<li>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.
|
||||
<li>The <i>switcher</i> application is inside the <i>switcher</i> directory. This directory is accessible only
|
||||
by user and group <b>boinc_master</b>, so that project applications cannot modify the <i>switcher</i>
|
||||
<li>BOINC Manager runs setgid to group <b>boinc_master</b>.
|
||||
It can access all files in group <b>boinc_master</b>.
|
||||
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.
|
||||
<li>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.
|
||||
<li>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.
|
||||
<li>The <i>switcher</i> application is inside the <i>switcher</i> directory.
|
||||
This directory is accessible only by user and group <b>boinc_master</b>,
|
||||
so that project applications cannot modify the <i>switcher</i>
|
||||
application's permissions or code.
|
||||
<li>Users with admin access are members of groups <b>boinc_master</b> and <b>boinc_project</b> so that they do have
|
||||
direct access to all BOINC and project files to simplify maintenance and administration.
|
||||
<li>The RPC password file <i>gui_rpc_auth.cfg</i> is accessible only by user and group <b>boinc_master</b>. In other
|
||||
words, only BOINC Manager, BOINC Client and authorized administrative users can read or modify it, limiting access to
|
||||
most BOINC RPC functions.
|
||||
<li>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.
|
||||
<li>On Macintosh computers, the actual directory structure of the BOINC Manager application bundle is more complex
|
||||
than implied by the box <i>BOINC executables</i> in the BOINC tree diagram shown above.
|
||||
<li>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 <b>/Applications</b> directory into a directory with restricted access.
|
||||
<li>Users with admin access are members of groups <b>boinc_master</b>
|
||||
and <b>boinc_project</b> so that they do have
|
||||
direct access to all BOINC and project files
|
||||
to simplify maintenance and administration.
|
||||
<li>The RPC password file <i>gui_rpc_auth.cfg</i>
|
||||
is accessible only by user and group <b>boinc_master</b>.
|
||||
In other words, only BOINC Manager, BOINC Client and
|
||||
authorized administrative users can read or modify it,
|
||||
limiting access to most BOINC RPC functions.
|
||||
<li>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.
|
||||
<li>On Macintosh computers, the actual directory structure
|
||||
of the BOINC Manager application bundle is more complex
|
||||
than implied by the box <i>BOINC executables</i> in the BOINC
|
||||
tree diagram shown above.
|
||||
<li>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
|
||||
<b>/Applications</b> directory into a directory with restricted access.
|
||||
</ul>
|
||||
</p>
|
||||
";
|
||||
|
||||
page_tail();
|
||||
?>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,171 @@
|
|||
<?php
|
||||
require_once("docutil.php");
|
||||
page_head("XML formats");
|
||||
echo "
|
||||
BOINC uses XML to describe various entities.
|
||||
These XML elements appear in:
|
||||
<ul>
|
||||
<li> The BOINC DB
|
||||
<li> Scheduler request and reply messages
|
||||
<li> The client state file
|
||||
<li> GUI RPCs
|
||||
</ul>
|
||||
Some of these XML elements are described here
|
||||
(not all fields are present in all contexts).
|
||||
<a name=file></a>
|
||||
<h3>Files</h3>
|
||||
<p>
|
||||
A file is described by an XML element of the form
|
||||
".html_text("
|
||||
<file_info>
|
||||
<name>foobar</name>
|
||||
<url>http://a.b.c/foobar</url>
|
||||
<url>http://x.y.z/foobar</url>
|
||||
...
|
||||
<md5_cksum>123123123123</md5_cksum>
|
||||
<nbytes>134423</nbytes>
|
||||
<max_nbytes>200000</max_nbytes>
|
||||
<status>1</status>
|
||||
[ <generated_locally/> ]
|
||||
[ <executable/> ]
|
||||
[ <upload_when_present/> ]
|
||||
[ <sticky/> ]
|
||||
[ <signature_required/> ]
|
||||
[ <no_delete/> ]
|
||||
[ <report_on_rpc/> ]
|
||||
</file_info>
|
||||
")."
|
||||
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
|
||||
<a href=int_upload.php>uploading files prior to
|
||||
finishing computation</a>.
|
||||
");
|
||||
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.
|
||||
<p>
|
||||
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 <a href=sched_locality.php>locality scheduling</a>."
|
||||
);
|
||||
list_end();
|
||||
echo "
|
||||
<a name=file_ref></a>
|
||||
<h3>File references</h3>
|
||||
<p>
|
||||
Files may be associated with <a href=work.php>workunits</a>,
|
||||
<a href=result.php>results</a> and
|
||||
<a href=app.php>application versions</a>.
|
||||
Each such association is represented by an XML element of the form
|
||||
".html_text("
|
||||
<file_ref>
|
||||
<file_name>foobar</file_name>
|
||||
[ <open_name>input</open_name> ]
|
||||
[ <main_program/> ]
|
||||
</file_ref>
|
||||
")."
|
||||
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
|
||||
<a href=api.php>the following functions</a>:
|
||||
<pre>
|
||||
char physical_name[256];
|
||||
boinc_resolve_filename(\"input\", physical_name, 256);
|
||||
fopen(physical_name, \"r\")
|
||||
</pre>
|
||||
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 "
|
||||
<a name=app_version></a>
|
||||
<h3>App versions</h3>
|
||||
|
||||
Each entry in the app version table includes an XML document describing the
|
||||
files that make up the application version:
|
||||
".html_text("
|
||||
<file_info>
|
||||
...
|
||||
</file_info>
|
||||
[ ... ]
|
||||
<app_version>
|
||||
<app_name>foobar</app_name>
|
||||
<version_num>4</version_num>
|
||||
<file_ref>
|
||||
<file_name>program_1</file_name>
|
||||
<main_program/>
|
||||
</file_ref>
|
||||
<file_ref>
|
||||
<file_name>library_12</file_name>
|
||||
</file_ref>
|
||||
</app_version>")."
|
||||
";
|
||||
page_tail();
|
||||
?>
|
||||
BIN
doc/yeti.jpg
BIN
doc/yeti.jpg
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
19
lib/parse.C
19
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
|
||||
// <foo>X</foo>
|
||||
// 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, "<!--")) {
|
||||
while (1) {
|
||||
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);
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
Loading…
Reference in New Issue