| 20 | | Any host for which p_vendor<tab>p_model matches the given regular expression will not be sent jobs. |
| 21 | | This is a POSIX extended regular expression. |
| 22 | | |
| 23 | | {{{ |
| 24 | | <ban_os>regexp</ban_os> |
| 25 | | }}} |
| 26 | | Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs. |
| 27 | | This is a POSIX extended regular expression. |
| 28 | | |
| 29 | | {{{ |
| 30 | | <distinct_beta_apps>0|1</distinct_beta_apps> |
| 31 | | }}} |
| 32 | | If set, [wiki:AppFiltering user application selection] applies to [wiki:BetaTest beta test applications] as well as others. |
| 33 | | |
| 34 | | {{{ |
| 35 | | <homogeneous_redundancy>N</homogeneous_redundancy> |
| 36 | | }}} |
| 37 | | If zero (default) don't use the [wiki:HomogeneousRedundancy homogeneous redundancy] mechanism. |
| 38 | | Otherwise, specifies the granularity of host classification (1=fine, 2=coarse). |
| 39 | | (Note: you may also specify this on a per-application basis). |
| 40 | | |
| 41 | | {{{ |
| 42 | | <hr_allocate_slots>0|1</hr_allocate_slots> |
| 43 | | }}} |
| 44 | | If set, allocate job-cache slots to homogeneous redundancy (HR) classes. |
| 45 | | Use this if your job cache |
| 46 | | [wiki:HomogeneousRedundancy#Schedulingconsiderations is getting clogged with jobs committed to a particular HR class]. |
| 47 | | {{{ |
| 48 | | <ignore_delay_bound/> |
| 49 | | }}} |
| 50 | | By default, results are not sent to hosts too slow to complete them within delay bound. |
| 51 | | If this flag is set, this rule is not enforced. |
| 52 | | |
| 53 | | {{{ |
| 54 | | <multiple_clients_per_host>0|1</multiple_clients_per_host> |
| 55 | | }}} |
| 56 | | Set this if some of your hosts run multiple BOINC clients simultaneously |
| 57 | | (this is the case on projects that use Condor and/or grid resources, which require each client to use only 1 CPU). |
| 58 | | If set, the scheduler will skip a check that tries to locate the host based on its IP address. |
| 59 | | |
| 60 | | {{{ |
| 61 | | <nowork_skip> 0|1 </nowork_skip> |
| 62 | | }}} |
| 63 | | If the scheduler has no work, it replies to RPCs without doing any database access (e.g., without looking up the user or host record). |
| 64 | | This reduces DB load, but it fails to update preferences when users click on Update. Use it if your server DB is overloaded. |
| 65 | | |
| 66 | | |
| 67 | | |
| 68 | | {{{ |
| 69 | | <report_grace_period>x</report_grace_period> |
| 70 | | }}} |
| 71 | | {{{ |
| 72 | | <grace_period_hours>x</grace_period_hours> |
| 73 | | }}} |
| 74 | | A "grace period" (in seconds or hours respectively) for task reporting. A task is considered time-out (and a new replica generated) |
| 75 | | if it is not reported by client_deadline + x. |
| 76 | | |
| 77 | | {{{ |
| 78 | | <user_filter>0|1</user_filter> |
| 79 | | }}} |
| 80 | | If set, use the "batch" field of workunits to select which user is allowed to process the job. |
| 81 | | If batch is nonzero, only send the job to the user with that ID. |
| 82 | | |
| 83 | | {{{ |
| 84 | | <workload_sim>0|1</workload_sim> |
| 85 | | }}} |
| 86 | | Use a more expensive, but more accurate, method to decide whether hosts can complete jobs within their delay bound. |
| | 27 | |
| | 28 | <ban_os>regexp</ban_os> :: |
| | 29 | Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs. |
| | 30 | This is a POSIX extended regular expression. |
| | 31 | |
| | 32 | <distinct_beta_apps>0|1</distinct_beta_apps> :: |
| | 33 | If set, [wiki:AppFiltering user application selection] applies to [wiki:BetaTest beta test applications] as well as others. |
| | 34 | |
| | 35 | <homogeneous_redundancy>N</homogeneous_redundancy>:: |
| | 36 | If zero (default) don't use the [wiki:HomogeneousRedundancy homogeneous redundancy] mechanism. |
| | 37 | Otherwise, specifies the granularity of host classification (1=fine, 2=coarse). |
| | 38 | (Note: you may also specify this on a per-application basis). |
| | 39 | |
| | 40 | <hr_allocate_slots>0|1</hr_allocate_slots>:: |
| | 41 | If set, allocate job-cache slots to homogeneous redundancy (HR) classes. |
| | 42 | Use this if your job cache |
| | 43 | [wiki:HomogeneousRedundancy#Schedulingconsiderations is getting clogged with jobs committed to a particular HR class]. |
| | 44 | |
| | 45 | <ignore_delay_bound/> :: |
| | 46 | By default, results are not sent to hosts too slow to complete them within delay bound. |
| | 47 | If this flag is set, this rule is not enforced. |
| | 48 | |
| | 49 | <multiple_clients_per_host>0|1</multiple_clients_per_host>:: |
| | 50 | Set this if some of your hosts run multiple BOINC clients simultaneously |
| | 51 | (this is the case on projects that use Condor and/or grid resources, which require each client to use only 1 CPU). |
| | 52 | If set, the scheduler will skip a check that tries to locate the host based on its IP address. |
| | 53 | |
| | 54 | <nowork_skip> 0|1 </nowork_skip>:: |
| | 55 | If the scheduler has no work, it replies to RPCs without doing any database access (e.g., without looking up the user or host record). |
| | 56 | This reduces DB load, but it fails to update preferences when users click on Update. Use it if your server DB is overloaded. |
| | 57 | |
| | 58 | <report_grace_period>x</report_grace_period>:: |
| | 59 | <grace_period_hours>x</grace_period_hours>:: |
| | 60 | A "grace period" (in seconds or hours respectively) for task reporting. |
| | 61 | A task is considered time-out (and a new replica generated) |
| | 62 | if it is not reported by client_deadline + x. |
| | 63 | |
| | 64 | <user_filter>0|1</user_filter>:: |
| | 65 | If set, use the "batch" field of workunits to select which user is allowed to process the job. |
| | 66 | If batch is nonzero, only send the job to the user with that ID. |
| | 67 | |
| | 68 | <workload_sim>0|1</workload_sim>:: |
| | 69 | Use a more expensive, but more accurate, method to decide whether hosts can complete jobs within their delay bound. |
| 90 | | {{{ |
| 91 | | <prefer_primary_platform> 0|1 </prefer_primary_platform> |
| 92 | | }}} |
| 93 | | Send hosts app versions for their primary platform if one exists; e.g. if a host is 64-bit, |
| 94 | | don't send it a 32-bit CPU version if a 64-bit CPU version exists. |
| 95 | | Use this option only if you're sure that your 64-bit versions are faster than the 32-bit versions. |
| 96 | | |
| 97 | | {{{ |
| 98 | | <version_select_random_factor>X</version_select_random_factor> |
| 99 | | }}} |
| 100 | | In predicting which app version will be faster for a given host, |
| 101 | | multiple the projected FLOPS by a uniform random variable |
| 102 | | with mean 1 and this standard deviation (default 0.1). |
| | 73 | <prefer_primary_platform> 0|1 </prefer_primary_platform>:: |
| | 74 | Send hosts app versions for their primary platform if one exists; e.g. if a host is 64-bit, |
| | 75 | don't send it a 32-bit CPU version if a 64-bit CPU version exists. |
| | 76 | Use this option only if you're sure that your 64-bit versions are faster than the 32-bit versions. |
| | 77 | |
| | 78 | <version_select_random_factor>X</version_select_random_factor>:: |
| | 79 | In predicting which app version will be faster for a given host, |
| | 80 | multiple the projected FLOPS by a uniform random variable |
| | 81 | with mean 1 and this standard deviation (default 0.1). |
| 105 | | {{{ |
| 106 | | <one_result_per_user_per_wu/> |
| 107 | | }}} |
| 108 | | If set, send at most one instance of a given job to a given user. |
| 109 | | This increases the effectiveness of replication-based validation by making it more difficult for hackers to get all the instances of a given job. |
| 110 | | |
| 111 | | {{{ |
| 112 | | <one_result_per_host_per_wu/> |
| 113 | | }}} |
| 114 | | If present, send at most one result of a given workunit to a given host. |
| 115 | | This is weaker than `one_result_per_user_per_wu`; |
| 116 | | it's useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user. |
| 117 | | |
| 118 | | {{{ |
| 119 | | <min_sendwork_interval> N </min_sendwork_interval> |
| 120 | | }}} |
| 121 | | Minimum number of seconds between sending jobs to a given host. You can use this to limit the impact of faulty hosts. |
| 122 | | |
| 123 | | {{{ |
| 124 | | <max_wus_in_progress> N </max_wus_in_progress> |
| 125 | | <max_wus_in_progress_gpu> M </max_wus_in_progress_gpu> |
| 126 | | }}} |
| 127 | | Limit the number of jobs in progress on a given host (and thus limit average turnaround time). |
| 128 | | Starting with 6.8, the BOINC client report the resources used by in-progress jobs; |
| 129 | | in this case, the max CPU jobs in progress is '''N*NCPUS''' and the max GPU jobs in progress is '''M*NGPUs'''. |
| 130 | | Otherwise, the overall maximum is '''N*NCPUS + M*NGPUS)'''. |
| 131 | | |
| 132 | | See the following section for a more powerful way of expressing limits on in-progress jobs. |
| 133 | | |
| 134 | | {{{ |
| 135 | | <gpu_multiplier> GM </gpu_multiplier> |
| 136 | | }}} |
| 137 | | If your project uses GPUs, set this to roughly the ratio of GPU speed to CPU speed. |
| 138 | | Used in the calculation of job limits (see next 2 items). |
| 139 | | |
| 140 | | {{{ |
| 141 | | <max_wus_to_send> N </max_wus_to_send> |
| 142 | | }}} |
| 143 | | Maximum jobs returned per scheduler RPC is '''N*(NCPUS + GM*NGPUS)'''. |
| 144 | | You can use this to limit the impact of faulty hosts. Default is 10. |
| 145 | | |
| 146 | | {{{ |
| 147 | | <max_ncpus>N</max_ncpus> |
| 148 | | }}} |
| 149 | | An upper bound on NCPUS (default: 64) |
| 150 | | |
| 151 | | {{{ |
| 152 | | <daily_result_quota> N </daily_result_quota> |
| 153 | | }}} |
| 154 | | Each host has a field MRD in the interval [1 .. daily_result_quota]; |
| 155 | | it's initially daily_result_quota, and is adjusted as the host sends good or bad results. |
| 156 | | The maximum number of jobs sent to a given host in a 24-hour period is '''MRD*(NCPUS + GM*NGPUS)'''. |
| 157 | | You can use this to limit the impact of faulty hosts. |
| | 84 | <one_result_per_user_per_wu/>:: |
| | 85 | If set, send at most one instance of a given job to a given user. |
| | 86 | This increases the effectiveness of replication-based validation by making |
| | 87 | it more difficult for hackers to get all the instances of a given job. |
| | 88 | |
| | 89 | <one_result_per_host_per_wu/>:: |
| | 90 | If present, send at most one result of a given workunit to a given host. |
| | 91 | This is weaker than `one_result_per_user_per_wu`; |
| | 92 | it's useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user. |
| | 93 | |
| | 94 | <min_sendwork_interval> N </min_sendwork_interval>:: |
| | 95 | Minimum number of seconds between sending jobs to a given host. You can use this to limit the impact of faulty hosts. |
| | 96 | |
| | 97 | <max_wus_in_progress> N </max_wus_in_progress>:: |
| | 98 | <max_wus_in_progress_gpu> M </max_wus_in_progress_gpu>:: |
| | 99 | Limit the number of jobs in progress on a given host (and thus limit average turnaround time). |
| | 100 | Starting with 6.8, the BOINC client report the resources used by in-progress jobs; |
| | 101 | in this case, the max CPU jobs in progress is '''N*NCPUS''' and the max GPU jobs in progress is '''M*NGPUs'''. |
| | 102 | Otherwise, the overall maximum is '''N*NCPUS + M*NGPUS)'''. |
| | 103 | |
| | 104 | See the following section for a more powerful way of expressing limits on in-progress jobs. |
| | 105 | |
| | 106 | <gpu_multiplier> GM </gpu_multiplier>:: |
| | 107 | If your project uses GPUs, set this to roughly the ratio of GPU speed to CPU speed. |
| | 108 | Used in the calculation of job limits (see next 2 items). |
| | 109 | |
| | 110 | <max_wus_to_send> N </max_wus_to_send>:: |
| | 111 | Maximum jobs returned per scheduler RPC is '''N*(NCPUS + GM*NGPUS)'''. |
| | 112 | You can use this to limit the impact of faulty hosts. Default is 10. |
| | 113 | |
| | 114 | <max_ncpus>N</max_ncpus>:: |
| | 115 | An upper bound on NCPUS (default: 64) |
| | 116 | |
| | 117 | <daily_result_quota> N </daily_result_quota>:: |
| | 118 | Each host has a field MRD in the interval [1 .. daily_result_quota]; |
| | 119 | it's initially daily_result_quota, and is adjusted as the host sends good or bad results. |
| | 120 | The maximum number of jobs sent to a given host in a 24-hour period is '''MRD*(NCPUS + GM*NGPUS)'''. |
| | 121 | You can use this to limit the impact of faulty hosts. |
| 213 | | {{{ |
| 214 | | <matchmaker>0|1</matchmaker> |
| 215 | | }}} |
| 216 | | If set, enable matchmaker scheduling. |
| 217 | | |
| 218 | | {{{ |
| 219 | | <mm_min_slots>N</mm_min_slots> |
| 220 | | <mm_max_slots>N</mm_max_slots> |
| 221 | | }}} |
| 222 | | Specify the min and max number of jobs to scan for a given client request. Defaults are 20 and 50. |
| 223 | | |
| 224 | | {{{ |
| 225 | | <job_size_matching>0|1</job_size_matching> |
| 226 | | }}} |
| 227 | | If set, include a term in the score function that favors sending large jobs to fast hosts. |
| 228 | | To use this, you must run the census program as a periodic task to maintain statistics on the distribution of host speeds. |
| | 173 | <matchmaker>0|1</matchmaker>:: |
| | 174 | If set, enable matchmaker scheduling. |
| | 175 | |
| | 176 | <mm_min_slots>N</mm_min_slots>:: |
| | 177 | <mm_max_slots>N</mm_max_slots>:: |
| | 178 | Specify the min and max number of jobs to scan for a given client request. Defaults are 20 and 50. |
| | 179 | |
| | 180 | <job_size_matching>0|1</job_size_matching>:: |
| | 181 | If set, include a term in the score function that favors sending large jobs to fast hosts. |
| | 182 | To use this, you must run the census program as a periodic task to maintain statistics on the distribution of host speeds. |
| 243 | | {{{ |
| 244 | | <reliable_on_priority>X</reliable_on_priority> |
| 245 | | }}} |
| 246 | | Results with priority at least '''reliable_on_priority''' are treated as "need-reliable". |
| 247 | | With matchmaker scheduling, they'll be sent preferentially to reliable hosts; with job-cache scheduling, they'll be sent ONLY to reliable hosts. |
| 248 | | |
| 249 | | {{{ |
| 250 | | <reliable_max_avg_turnaround>secs</reliable_max_avg_turnaround> |
| 251 | | <reliable_max_error_rate>X</reliable_max_error_rate> |
| 252 | | }}} |
| 253 | | Hosts whose average turnaround is at most reliable_max_avg_turnaround and whose error rate is at most reliable_max_error_rate are considered 'reliable'. |
| 254 | | Make sure you set these low enough that a significant fraction (e.g. 25%) of your hosts qualify. |
| 255 | | |
| 256 | | {{{ |
| 257 | | <reliable_reduced_delay_bound>X</reliable_reduced_delay_bound> |
| 258 | | }}} |
| 259 | | When a need-reliable result is sent to a reliable host, multiply the delay bound by '''reliable_reduced_delay_bound''' (typically 0.5 or so). |
| 260 | | |
| 261 | | {{{ |
| 262 | | <reliable_priority_on_over>X</reliable_priority_on_over> |
| 263 | | <reliable_priority_on_over_except_error>X</reliable_priority_on_over_except_error> |
| 264 | | }}} |
| 265 | | If '''reliable_priority_on_over''' is nonzero, increase the priority of duplicate jobs by that amount over the job's base priority. |
| 266 | | Otherwise, if '''reliable_priority_on_over_except_error''' is nonzero, |
| 267 | | increase the priority of duplicates caused by timeout (not error) by that amount. |
| 268 | | (Typically only one of these is nonzero, and is equal to '''reliable_on_priority'''.) |
| 269 | | |
| 270 | | NOTE: this mechanism can be used to preferentially send ANY job, not just retries, to fast/reliable hosts. |
| 271 | | To do so, set the workunit's priority to '''reliable_on_priority''' or greater. |
| | 197 | <reliable_on_priority>X</reliable_on_priority>:: |
| | 198 | Results with priority at least '''reliable_on_priority''' are treated as "need-reliable". |
| | 199 | With matchmaker scheduling, they'll be sent preferentially to reliable hosts; with job-cache scheduling, they'll be sent ONLY to reliable hosts. |
| | 200 | |
| | 201 | <reliable_max_avg_turnaround>secs</reliable_max_avg_turnaround>:: |
| | 202 | <reliable_max_error_rate>X</reliable_max_error_rate>:: |
| | 203 | Hosts whose average turnaround is at most reliable_max_avg_turnaround and whose error rate is at most reliable_max_error_rate are considered 'reliable'. |
| | 204 | Make sure you set these low enough that a significant fraction (e.g. 25%) of your hosts qualify. |
| | 205 | |
| | 206 | <reliable_reduced_delay_bound>X</reliable_reduced_delay_bound>:: |
| | 207 | When a need-reliable result is sent to a reliable host, |
| | 208 | multiply the delay bound by '''reliable_reduced_delay_bound''' (typically 0.5 or so). |
| | 209 | |
| | 210 | <reliable_priority_on_over>X</reliable_priority_on_over>:: |
| | 211 | <reliable_priority_on_over_except_error>X</reliable_priority_on_over_except_error>:: |
| | 212 | If '''reliable_priority_on_over''' is nonzero, increase the priority of duplicate jobs by that amount over the job's base priority. |
| | 213 | Otherwise, if '''reliable_priority_on_over_except_error''' is nonzero, |
| | 214 | increase the priority of duplicates caused by timeout (not error) by that amount. |
| | 215 | (Typically only one of these is nonzero, and is equal to '''reliable_on_priority'''.) |
| | 216 | |
| | 217 | NOTE: this mechanism can be used to preferentially send ANY job, not just retries, to fast/reliable hosts. |
| | 218 | To do so, set the workunit's priority to '''reliable_on_priority''' or greater. |
| 274 | | {{{ |
| 275 | | <locality_scheduling/> |
| 276 | | }}} |
| 277 | | When possible, send work that uses the same files that the host already has. |
| 278 | | This is intended for projects which have large data files, where many different workunits use the same data file. |
| 279 | | In this case, to reduce download demands on the server, it may be advantageous to retain the data files on the hosts, |
| 280 | | and send them work for the files that they already have. |
| 281 | | See [wiki:LocalityScheduling Locality Scheduling]. |
| 282 | | |
| 283 | | {{{ |
| 284 | | <locality_scheduling_wait_period> N </locality_scheduling_wait_period> |
| 285 | | }}} |
| 286 | | This element only has an effect when used in conjunction with the previous locality scheduling element. |
| 287 | | It tells the scheduler to use 'trigger files' to inform the project that more work is needed for specific files. |
| 288 | | The period is the number of seconds which the scheduler will wait to see if the project can create additional work. |
| 289 | | Together with project-specific daemons or scripts this can be used for 'just-in-time' workunit creation. |
| 290 | | See [wiki:LocalityScheduling Locality Scheduling]. |
| | 221 | <locality_scheduling/>:: |
| | 222 | When possible, send work that uses the same files that the host already has. |
| | 223 | This is intended for projects which have large data files, where many different workunits use the same data file. |
| | 224 | In this case, to reduce download demands on the server, it may be advantageous to retain the data files on the hosts, |
| | 225 | and send them work for the files that they already have. |
| | 226 | See [wiki:LocalityScheduling Locality Scheduling]. |
| | 227 | |
| | 228 | <locality_scheduling_wait_period> N </locality_scheduling_wait_period>:: |
| | 229 | This element only has an effect when used in conjunction with the previous locality scheduling element. |
| | 230 | It tells the scheduler to use 'trigger files' to inform the project that more work is needed for specific files. |
| | 231 | The period is the number of seconds which the scheduler will wait to see if the project can create additional work. |
| | 232 | Together with project-specific daemons or scripts this can be used for 'just-in-time' workunit creation. |
| | 233 | See [wiki:LocalityScheduling Locality Scheduling]. |
| 293 | | {{{ |
| 294 | | <resend_lost_results> 0|1 </resend_lost_results> |
| 295 | | }}} |
| 296 | | If set, and a <other_results> list is present in scheduler request, resend any in-progress results not in the list. |
| 297 | | This is recommended; it may increase the efficiency of your project. |
| 298 | | For reasons that are not well understood, a BOINC client sometimes fails to receive the scheduler reply. |
| 299 | | This flag addresses that issue: it causes the SAME results to be resent by the scheduler, |
| 300 | | if the client has failed to receive them. |
| 301 | | Note: this will increase the load on your DB server; you can minimize this by creating an index: |
| | 236 | <resend_lost_results> 0|1 </resend_lost_results>:: |
| | 237 | If set, and a <other_results> list is present in scheduler request, resend any in-progress results not in the list. |
| | 238 | This is recommended; it may increase the efficiency of your project. |
| | 239 | For reasons that are not well understood, a BOINC client sometimes fails to receive the scheduler reply. |
| | 240 | This flag addresses that issue: it causes the SAME results to be resent by the scheduler, |
| | 241 | if the client has failed to receive them. |
| | 242 | Note: this will increase the load on your DB server; you can minimize this by creating an index: |
| 316 | | {{{ |
| 317 | | <replace_download_url_by_timezone>URL</replace_download_url_by_timezone> |
| 318 | | }}} |
| 319 | | OUTDATED: BERND, PLEASE UPDATE. |
| 320 | | When the scheduler sends work to hosts, it replaces the download URL appearing in the data and executable file |
| 321 | | descriptions with the download URL closest to the host's timezone. |
| 322 | | The project must provide a two-column file called 'download_servers' in the project root directory. |
| 323 | | This is a list of all download servers that will be inserted when work is sent to hosts. |
| 324 | | The first column is an integer listing the server's offset in seconds from UTC. |
| 325 | | The second column is the server URL in the format such as !http://einstein.phys.uwm.edu. |
| 326 | | The download servers must have identical file hierarchies and contents, |
| 327 | | and the path to file and executables must start with '/download/...' as in '!http://X/download/123/some_file_name'. |
| 328 | | |
| 329 | | {{{ |
| 330 | | <cache_md5_info> 0|1 </cache_md5_info> |
| 331 | | }}} |
| 332 | | When creating work, keep a record (in files called foo.md5) of the file length and md5 sum of data files and executables. |
| 333 | | This can greatly reduce the time needed to create work, |
| 334 | | if (1) these files are re-used, and (2) there are many of these files, and (3) reading the files from disk is time-consuming. |
| | 256 | <replace_download_url_by_timezone>URL</replace_download_url_by_timezone>:: |
| | 257 | OUTDATED: BERND, PLEASE UPDATE. |
| | 258 | When the scheduler sends work to hosts, it replaces the download URL appearing in the data and executable file |
| | 259 | descriptions with the download URL closest to the host's timezone. |
| | 260 | The project must provide a two-column file called 'download_servers' in the project root directory. |
| | 261 | This is a list of all download servers that will be inserted when work is sent to hosts. |
| | 262 | The first column is an integer listing the server's offset in seconds from UTC. |
| | 263 | The second column is the server URL in the format such as !http://einstein.phys.uwm.edu. |
| | 264 | The download servers must have identical file hierarchies and contents, |
| | 265 | and the path to file and executables must start with '/download/...' as in '!http://X/download/123/some_file_name'. |
| | 266 | |
| | 267 | <cache_md5_info> 0|1 </cache_md5_info>:: |
| | 268 | When creating work, keep a record (in files called foo.md5) of the file length and md5 sum of data files and executables. |
| | 269 | This can greatly reduce the time needed to create work, |
| | 270 | if (1) these files are re-used, and (2) there are many of these files, and (3) reading the files from disk is time-consuming. |
| 339 | | {{{ |
| 340 | | <debug_assignment/> |
| 341 | | }}} |
| 342 | | Explain the sending of [wiki:AssignedWork assigned work]. |
| 343 | | |
| 344 | | {{{ |
| 345 | | <debug_edf_sim_detail/> |
| 346 | | }}} |
| 347 | | Show the details of EDF simulation |
| 348 | | |
| 349 | | {{{ |
| 350 | | <debug_edf_sim_workload/> |
| 351 | | }}} |
| 352 | | Show the initial conditions of EDF simulation |
| 353 | | |
| 354 | | {{{ |
| 355 | | <debug_handle_results/> |
| 356 | | }}} |
| 357 | | Show the handling of reported jobs. |
| 358 | | |
| 359 | | {{{ |
| 360 | | <debug_locality> |
| 361 | | }}} |
| 362 | | Show locality scheduling debugging info. |
| 363 | | |
| 364 | | {{{ |
| 365 | | <debug_prefs/> |
| 366 | | }}} |
| 367 | | Show the propagation of global prefs. |
| 368 | | |
| 369 | | {{{ |
| 370 | | <debug_quota/> |
| 371 | | }}} |
| 372 | | Show info related to job quotas (per RPC, max in progress, max per day) |
| 373 | | |
| 374 | | {{{ |
| 375 | | <debug_request_details/> |
| 376 | | }}} |
| 377 | | Show details of request message. |
| 378 | | |
| 379 | | {{{ |
| 380 | | <debug_request_headers/> |
| 381 | | }}} |
| 382 | | Show HTTP request headers. |
| 383 | | |
| 384 | | {{{ |
| 385 | | <debug_send/> |
| 386 | | }}} |
| 387 | | Explain the sending of jobs. |
| 388 | | |
| 389 | | {{{ |
| 390 | | <debug_user_messages/> |
| 391 | | }}} |
| 392 | | Show messages we're sending to the user. |
| 393 | | |
| 394 | | {{{ |
| 395 | | <debug_version_select/> |
| 396 | | }}} |
| 397 | | Explain app version selection. |
| | 275 | <debug_assignment/>:: |
| | 276 | Explain the sending of [wiki:AssignedWork assigned work]. |
| | 277 | |
| | 278 | <debug_edf_sim_detail/>:: |
| | 279 | Show the details of EDF simulation |
| | 280 | |
| | 281 | <debug_edf_sim_workload/>:: |
| | 282 | Show the initial conditions of EDF simulation |
| | 283 | |
| | 284 | <debug_handle_results/>:: |
| | 285 | Show the handling of reported jobs. |
| | 286 | |
| | 287 | <debug_locality>:: |
| | 288 | Show locality scheduling debugging info. |
| | 289 | |
| | 290 | <debug_prefs/>:: |
| | 291 | Show the propagation of global prefs. |
| | 292 | |
| | 293 | <debug_quota/>:: |
| | 294 | Show info related to job quotas (per RPC, max in progress, max per day) |
| | 295 | |
| | 296 | <debug_request_details/>:: |
| | 297 | Show details of request message. |
| | 298 | |
| | 299 | <debug_request_headers/>:: |
| | 300 | Show HTTP request headers. |
| | 301 | |
| | 302 | <debug_send/>:: |
| | 303 | Explain the sending of jobs. |
| | 304 | |
| | 305 | <debug_user_messages/>:: |
| | 306 | Show messages we're sending to the user. |
| | 307 | |
| | 308 | <debug_version_select/>:: |
| | 309 | Explain app version selection. |
| 408 | | {{{ |
| 409 | | <next_rpc_delay>x</next_rpc_delay> |
| 410 | | }}} |
| 411 | | In each scheduler reply, tell the clients to do another scheduler RPC after at most X seconds, |
| 412 | | regardless of whether they need work. |
| 413 | | This is useful, e.g., to ensure that in-progress jobs can be canceled in a bounded amount of time. |
| 414 | | |
| 415 | | {{{ |
| 416 | | <verify_files_on_app_start/> |
| 417 | | }}} |
| 418 | | Before starting or restarting an app, check contents of input files and app version files by either MD5 or digital signature check. |
| 419 | | Detects user tampering with file (but doesn't really increase security, since user could also change MD5s or signatures in client state file). |
| 420 | | |
| 421 | | {{{ |
| 422 | | <symstore>URL</symstore> |
| 423 | | }}} |
| 424 | | URL of your project's symbol store, used for debugging Windows applications. |
| 425 | | |
| 426 | | {{{ |
| 427 | | <min_core_client_version_announced> N </min_core_client_version_announced> |
| 428 | | }}} |
| 429 | | Announce a new version of the BOINC core client, which in the future will be the minimum required version. |
| 430 | | In conjunction with the next tag, you can warn users with version below this to upgrade by a specified deadline. |
| 431 | | The version number is encoded as 10000*major + 100*minor + release. |
| 432 | | |
| 433 | | {{{ |
| 434 | | <min_core_client_upgrade_deadline> N </min_core_client_upgrade_deadline> |
| 435 | | }}} |
| 436 | | Use in conjunction with the previous tag. |
| 437 | | The value given here is the Unix epoch returned by time(2) until which hosts can update their core client. |
| 438 | | After this time, they may be shut out of the project. Before this time, they will receive messages warning them to upgrade. |
| 439 | | |
| 440 | | {{{ |
| 441 | | <msg_to_host/> |
| 442 | | }}} |
| 443 | | If present, check the msg_to_host table on each RPC, and send the client any messages queued for it. |
| 444 | | |
| 445 | | {{{ |
| 446 | | <non_cpu_intensive> 0|1 </non_cpu_intensive> |
| 447 | | }}} |
| 448 | | If this flag is present, the project will be treated specially by the client: |
| | 319 | <next_rpc_delay>x</next_rpc_delay>:: |
| | 320 | In each scheduler reply, tell the clients to do another scheduler RPC after at most X seconds, |
| | 321 | regardless of whether they need work. |
| | 322 | This is useful, e.g., to ensure that in-progress jobs can be canceled in a bounded amount of time. |
| | 323 | |
| | 324 | <verify_files_on_app_start/>:: |
| | 325 | Before starting or restarting an app, check contents of input files and app version files by either MD5 or digital signature check. |
| | 326 | Detects user tampering with file (but doesn't really increase security, since user could also change MD5s or signatures in client state file). |
| | 327 | |
| | 328 | <symstore>URL</symstore>:: |
| | 329 | URL of your project's symbol store, used for debugging Windows applications. |
| | 330 | |
| | 331 | <min_core_client_version_announced> N </min_core_client_version_announced>:: |
| | 332 | Announce a new version of the BOINC core client, which in the future will be the minimum required version. |
| | 333 | In conjunction with the next tag, you can warn users with version below this to upgrade by a specified deadline. |
| | 334 | The version number is encoded as 10000*major + 100*minor + release. |
| | 335 | |
| | 336 | <min_core_client_upgrade_deadline> N </min_core_client_upgrade_deadline>:: |
| | 337 | Use in conjunction with the previous tag. |
| | 338 | The value given here is the Unix epoch returned by time(2) until which hosts can update their core client. |
| | 339 | After this time, they may be shut out of the project. Before this time, they will receive messages warning them to upgrade. |
| | 340 | |
| | 341 | <msg_to_host/>:: |
| | 342 | If present, check the msg_to_host table on each RPC, and send the client any messages queued for it. |
| | 343 | |
| | 344 | <non_cpu_intensive> 0|1 </non_cpu_intensive>:: |
| | 345 | If this flag is present, the project will be treated specially by the client: |
| 478 | | {{{ |
| 479 | | <default_disk_max_used_gb> X </default_disk_max_used_gb> |
| 480 | | }}} |
| 481 | | Sets the default value for the `disk_max_used_gb` preference so it's consistent between the scheduler and web pages. |
| 482 | | The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. |
| 483 | | The web page scripts use it to set the initial value when displaying or editing preferences the first time, or when the user never saved them. |
| 484 | | Default is 100. |
| 485 | | |
| 486 | | {{{ |
| 487 | | <default_disk_max_used_pct> X </default_disk_max_used_pct> |
| 488 | | }}} |
| 489 | | Sets the default value for the `disk_max_used_pct` preference so its consistent between the scheduler and web pages. |
| 490 | | The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. |
| 491 | | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| 492 | | or when the user never saved them. |
| 493 | | Default is 50. |
| 494 | | |
| 495 | | {{{ |
| 496 | | <default_disk_min_free_gb> X </default_disk_min_free_gb> |
| 497 | | }}} |
| 498 | | Sets the default value for the `disk_min_free_gb` preference so its consistent between the scheduler and web pages. |
| 499 | | The scheduler uses it when a request for work doesn't include preferences. |
| 500 | | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| 501 | | or when the user never saved them. |
| 502 | | Also, the scheduler uses this setting to override any smaller preference from the host, |
| 503 | | it enforces a 'minimum free disk space' to keep from filling up the drive. |
| 504 | | Recommend setting this no smaller than .001 (1MB or 1,000,000 bytes). |
| 505 | | Default is .001. |
| 506 | | |
| 507 | | == Credit == |
| 508 | | (See also the command-line options of the [wiki:ValidationIntro validator]). |
| 509 | | |
| 510 | | {{{ |
| 511 | | <granted_credit_weight>X</granted_credit_weight> |
| 512 | | }}} |
| 513 | | {{{ |
| 514 | | <granted_credit_ramp_up>N</granted_credit_ramp_up> |
| 515 | | }}} |
| 516 | | {{{ |
| 517 | | <fp_benchmark_weight> X </fp_benchmark_weight> |
| 518 | | }}} |
| 519 | | The weighting given to the Whetstone benchmark in the calculation of claimed credit. |
| 520 | | Must be in [0 .. 1]. |
| 521 | | Projects whose applications are floating-point intensive should use 1; pure integer applications, 0. |
| 522 | | Choosing an appropriate value will reduce the disparity in claimed credit between hosts. |
| 523 | | The script html/ops/credit_study.php, |
| 524 | | run against the database of a running project, will suggest what value to use. |
| 525 | | |
| 526 | | {{{ |
| 527 | | <granted_credit_weight>X</granted_credit_weight> |
| 528 | | }}} |
| 529 | | KEVIN - PLEASE EXPLAIN |
| | 362 | <default_disk_max_used_gb> X </default_disk_max_used_gb>:: |
| | 363 | Sets the default value for the `disk_max_used_gb` preference so it's consistent between the scheduler and web pages. |
| | 364 | The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. |
| | 365 | The web page scripts use it to set the initial value when displaying or editing preferences the first time, or when the user never saved them. |
| | 366 | Default is 100. |
| | 367 | |
| | 368 | <default_disk_max_used_pct> X </default_disk_max_used_pct>:: |
| | 369 | Sets the default value for the `disk_max_used_pct` preference so its consistent between the scheduler and web pages. |
| | 370 | The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. |
| | 371 | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| | 372 | or when the user never saved them. |
| | 373 | Default is 50. |
| | 374 | |
| | 375 | <default_disk_min_free_gb> X </default_disk_min_free_gb>:: |
| | 376 | Sets the default value for the `disk_min_free_gb` preference so its consistent between the scheduler and web pages. |
| | 377 | The scheduler uses it when a request for work doesn't include preferences. |
| | 378 | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| | 379 | or when the user never saved them. |
| | 380 | Also, the scheduler uses this setting to override any smaller preference from the host, |
| | 381 | it enforces a 'minimum free disk space' to keep from filling up the drive. |
| | 382 | Recommend setting this no smaller than .001 (1MB or 1,000,000 bytes). |
| | 383 | Default is .001. |
| 543 | | {{{ |
| 544 | | <www_host>hostname</www_host> |
| 545 | | }}} |
| 546 | | Host name of web server. |
| 547 | | |
| 548 | | {{{ |
| 549 | | <sched_host>hostname</sched_host> |
| 550 | | }}} |
| 551 | | Host name of scheduling server. |
| 552 | | |
| 553 | | {{{ |
| 554 | | <uldl_host>hostname</uldl_host> |
| 555 | | }}} |
| 556 | | Host name of upload/download server. |
| 557 | | |
| 558 | | {{{ |
| 559 | | <uldl_pid>path</uldl_pid> |
| 560 | | }}} |
| 561 | | pid file of upload/download server (default: `/etc/httpd/run/httpd.pid`). |
| 562 | | |
| 563 | | {{{ |
| 564 | | <ssh_exe>path</ssh_exe> |
| 565 | | }}} |
| 566 | | path to `ssh` (default: `/usr/bin/ssh`). |
| 567 | | |
| 568 | | {{{ |
| 569 | | <ps_exe>path</ps_exe> |
| 570 | | }}} |
| 571 | | path to `ps` (which supports "w" flag) (default: `/bin/ps`). |
| | 395 | <www_host>hostname</www_host>:: |
| | 396 | Host name of web server. |
| | 397 | |
| | 398 | <sched_host>hostname</sched_host>:: |
| | 399 | Host name of scheduling server. |
| | 400 | |
| | 401 | <uldl_host>hostname</uldl_host>:: |
| | 402 | Host name of upload/download server. |
| | 403 | |
| | 404 | <uldl_pid>path</uldl_pid>:: |
| | 405 | pid file of upload/download server (default: `/etc/httpd/run/httpd.pid`). |
| | 406 | |
| | 407 | <ssh_exe>path</ssh_exe>:: |
| | 408 | path to `ssh` (default: `/usr/bin/ssh`). |
| | 409 | |
| | 410 | <ps_exe>path</ps_exe>:: |
| | 411 | path to `ps` (which supports "w" flag) (default: `/bin/ps`). |
| 574 | | {{{ |
| 575 | | <profile_screening/> |
| 576 | | }}} |
| 577 | | If present, don't show profile pictures until they've been screened and approved by project admins. |
| 578 | | |
| 579 | | {{{ |
| 580 | | <show_results/> |
| 581 | | }}} |
| 582 | | Enable web site features that show results (per user, host, etc.). |
| 583 | | |
| 584 | | {{{ |
| 585 | | <dont_suppress_pending/> |
| 586 | | }}} |
| 587 | | Do not hide incomplete results when using adaptive replication. |
| 588 | | |
| 589 | | {{{ |
| 590 | | <no_forum_rating/> |
| 591 | | }}} |
| 592 | | Disable forum post rating. |
| 593 | | |
| 594 | | {{{ |
| 595 | | <no_web_account_creation/> |
| 596 | | }}} |
| 597 | | Don't allow account creation via the web. |
| 598 | | |
| 599 | | {{{ |
| 600 | | <akismet_key> 1234567890ab </akismet_key> |
| 601 | | }}} |
| 602 | | If set, akismet.com is used to check post contents to protect forums from spam. |
| 603 | | See [wiki:ProtectionFromSpam Protecting message boards from spam] for more information. |
| 604 | | |
| 605 | | {{{ |
| 606 | | <users_per_page>N</users_per_page> |
| 607 | | }}} |
| 608 | | Number of entries per page for top users/teams/hosts. Default is 20. |
| 609 | | |
| 610 | | {{{ |
| 611 | | <teams_per_page>N</teams_per_page> |
| 612 | | }}} |
| 613 | | {{{ |
| 614 | | <hosts_per_page>N</hosts_per_page> |
| 615 | | }}} |
| 616 | | {{{ |
| 617 | | <recaptcha_public_key>X</recaptcha_public_key> |
| 618 | | <recaptcha_private_key>X</recaptcha_private_key> |
| 619 | | }}} |
| 620 | | Enable the use of Recaptcha for profile creation/editing; |
| 621 | | see [wiki:ProtectionFromSpam Protecting message boards from spam] for more information. |
| 622 | | |
| 623 | | {{{ |
| 624 | | <profile_min_credit>X</profile_min_credit> |
| 625 | | }}} |
| 626 | | The minimum amount of credit to create or edit a profile. |
| 627 | | |
| 628 | | {{{ |
| 629 | | <team_forums_members_only>0|1</team_forums_members_only> |
| 630 | | }}} |
| 631 | | If set, team message boards are visible only to team members. |
| 632 | | |
| 633 | | {{{ |
| 634 | | <moderators_vote_to_ban>0|1</moderators_vote_to_ban> |
| 635 | | }}} |
| 636 | | If set, banishments require a majority vote among moderators. |
| 637 | | |
| 638 | | {{{ |
| 639 | | <no_computing>0|1</no_computing> |
| 640 | | }}} |
| 641 | | If set, web pages have no references to computing (tasks, credit etc.). For projects that are using Bossa or Bolt. |
| | 414 | <profile_screening/>:: |
| | 415 | If present, don't show profile pictures until they've been screened and approved by project admins. |
| | 416 | |
| | 417 | <show_results/>:: |
| | 418 | Enable web site features that show results (per user, host, etc.). |
| | 419 | |
| | 420 | <dont_suppress_pending/>:: |
| | 421 | Do not hide incomplete results when using adaptive replication. |
| | 422 | |
| | 423 | <no_forum_rating/>:: |
| | 424 | Disable forum post rating. |
| | 425 | |
| | 426 | <no_web_account_creation/>:: |
| | 427 | Don't allow account creation via the web. |
| | 428 | |
| | 429 | <akismet_key> 1234567890ab </akismet_key>:: |
| | 430 | If set, akismet.com is used to check post contents to protect forums from spam. |
| | 431 | See [wiki:ProtectionFromSpam Protecting message boards from spam] for more information. |
| | 432 | |
| | 433 | <users_per_page>N</users_per_page>:: |
| | 434 | Number of entries per page for top users/teams/hosts. Default is 20. |
| | 435 | |
| | 436 | <teams_per_page>N</teams_per_page>:: |
| | 437 | <hosts_per_page>N</hosts_per_page>:: |
| | 438 | <recaptcha_public_key>X</recaptcha_public_key>:: |
| | 439 | <recaptcha_private_key>X</recaptcha_private_key>:: |
| | 440 | Enable the use of Recaptcha for profile creation/editing; |
| | 441 | see [wiki:ProtectionFromSpam Protecting message boards from spam] for more information. |
| | 442 | |
| | 443 | <profile_min_credit>X</profile_min_credit>:: |
| | 444 | The minimum amount of credit to create or edit a profile. |
| | 445 | |
| | 446 | <team_forums_members_only>0|1</team_forums_members_only>:: |
| | 447 | If set, team message boards are visible only to team members. |
| | 448 | |
| | 449 | <moderators_vote_to_ban>0|1</moderators_vote_to_ban>:: |
| | 450 | If set, banishments require a majority vote among moderators. |
| | 451 | |
| | 452 | <no_computing>0|1</no_computing>:: |
| | 453 | If set, web pages have no references to computing (tasks, credit etc.). |
| | 454 | For projects that are using Bossa or Bolt. |
| 644 | | {{{ |
| 645 | | <min_core_client_version> N </min_core_client_version> |
| 646 | | }}} |
| 647 | | If the scheduler gets a request from a client with a version number less than this, |
| 648 | | it returns an error message and doesn't do any other processing. |
| 649 | | The version number is expressed as an integer with the encoding 10000*major + 100*minor + release. |
| 650 | | You can also specify this separately for each [wiki:AppVersion application]. |
| 651 | | |
| 652 | | {{{ |
| 653 | | <ended>0|1</ended> |
| 654 | | }}} |
| 655 | | Project has permanently ended. Tell clients so user can be notified. |
| 656 | | |
| 657 | | {{{ |
| 658 | | <disable_account_creation/> |
| 659 | | }}} |
| 660 | | If present, disallow account creation. |
| 661 | | |
| 662 | | {{{ |
| 663 | | <min_passwd_length> N </min_passwd_length> |
| 664 | | }}} |
| 665 | | Minimum length of user passwords. Default is 6. |
| 666 | | |
| 667 | | {{{ |
| 668 | | <request_time_stats_log/> |
| 669 | | }}} |
| 670 | | If present, the scheduler will tell clients (via scheduler replies) to upload (via scheduler requests) |
| 671 | | their time stats log (which contains records of when the client started and stopped running). |
| 672 | | |
| 673 | | {{{ |
| 674 | | <fuh_debug_level> N </fuh_debug_level> |
| 675 | | }}} |
| 676 | | Verbosity level for file upload handler log output. 1=minimal, 2=normal (default), 3=verbose. |
| 677 | | |
| 678 | | {{{ |
| 679 | | <dont_store_success_stderr/> |
| 680 | | }}} |
| 681 | | If present, don't store the stderr log in the database for successful workunits. |
| 682 | | May be useful to save on database size. Available since r18528. |
| | 457 | <min_core_client_version> N </min_core_client_version>:: |
| | 458 | If the scheduler gets a request from a client with a version number less than this, |
| | 459 | it returns an error message and doesn't do any other processing. |
| | 460 | The version number is expressed as an integer with the encoding 10000*major + 100*minor + release. |
| | 461 | You can also specify this separately for each [wiki:AppVersion application]. |
| | 462 | |
| | 463 | <ended>0|1</ended>:: |
| | 464 | Project has permanently ended. Tell clients so user can be notified. |
| | 465 | |
| | 466 | <disable_account_creation/>:: |
| | 467 | If present, disallow account creation. |
| | 468 | |
| | 469 | <min_passwd_length> N </min_passwd_length>:: |
| | 470 | Minimum length of user passwords. Default is 6. |
| | 471 | |
| | 472 | <request_time_stats_log/>:: |
| | 473 | If present, the scheduler will tell clients (via scheduler replies) to upload (via scheduler requests) |
| | 474 | their time stats log (which contains records of when the client started and stopped running). |
| | 475 | |
| | 476 | <fuh_debug_level> N </fuh_debug_level>:: |
| | 477 | Verbosity level for file upload handler log output. 1=minimal, 2=normal (default), 3=verbose. |
| | 478 | |
| | 479 | <dont_store_success_stderr/>:: |
| | 480 | If present, don't store the stderr log in the database for successful workunits. |
| | 481 | May be useful to save on database size. Available since r18528. |
| 685 | | {{{ |
| 686 | | <db_name>name</db_name> |
| 687 | | <db_user>database_user_name</db_user> |
| 688 | | [ <db_host>hostname</db_host> ] |
| 689 | | [ <db_passwd>database_password</db_passwd> ] |
| 690 | | }}} |
| 691 | | Database name, user name, hostname (default "localhost") and password (default none). |
| 692 | | The hostname can be of the form hostname:port. |
| 693 | | |
| 694 | | {{{ |
| 695 | | [ <replica_db_name>name</replica_db_name> ] |
| 696 | | [ <replica_db_user>database_user_name</replica_db_user> ] |
| 697 | | [ <replica_db_host>hostname</replica_db_host> ] |
| 698 | | [ <replica_db_passwd>database_password</replica_db_passwd> ] |
| 699 | | }}} |
| 700 | | Description a replica database server, which is used for read-only queries (optional). |
| 701 | | NOTE: according to Bernd Machenschalk, using a separate user account with read-only |
| 702 | | access to the replica increases the apparent consistency between main and replica. |
| | 484 | <db_name>name</db_name>:: |
| | 485 | <db_user>database_user_name</db_user>:: |
| | 486 | [ <db_host>hostname</db_host> ]:: |
| | 487 | [ <db_passwd>database_password</db_passwd> ]:: |
| | 488 | Database name, user name, hostname (default "localhost") and password (default none). |
| | 489 | The hostname can be of the form hostname:port. |
| | 490 | |
| | 491 | [ <replica_db_name>name</replica_db_name> ]:: |
| | 492 | [ <replica_db_user>database_user_name</replica_db_user> ]:: |
| | 493 | [ <replica_db_host>hostname</replica_db_host> ]:: |
| | 494 | [ <replica_db_passwd>database_password</replica_db_passwd> ]:: |
| | 495 | Description a replica database server, which is used for read-only queries (optional). |
| | 496 | NOTE: according to Bernd Machenschalk, using a separate user account with read-only |
| | 497 | access to the replica increases the apparent consistency between main and replica. |
| 707 | | {{{ |
| 708 | | <master_url>URL</master_url> |
| 709 | | }}} |
| 710 | | {{{ |
| 711 | | <long_name>name</long_name> |
| 712 | | }}} |
| 713 | | {{{ |
| 714 | | <host>hostname</host> |
| 715 | | }}} |
| 716 | | name of project's main host, as given by Python's `socket.hostname()`. |
| 717 | | Daemons and tasks run on this host by default. |
| 718 | | |
| 719 | | {{{ |
| 720 | | <shmem_key>shared_memory_key</shmem_key> |
| 721 | | }}} |
| 722 | | ID of scheduler shared memory. Must be unique on host. |
| 723 | | |
| 724 | | {{{ |
| 725 | | <download_url>URL</download_url> |
| 726 | | }}} |
| 727 | | URL of data server for download. |
| 728 | | |
| 729 | | {{{ |
| 730 | | <download_dir>path</download_dir> |
| 731 | | }}} |
| 732 | | absolute path of download directory. |
| 733 | | |
| 734 | | {{{ |
| 735 | | <uldl_dir_fanout>N</uldl_dir_fanout> |
| 736 | | }}} |
| 737 | | fan-out factor of upload and download directories (see [wiki:DirHierarchy Hierarchical upload/download directories]). |
| 738 | | |
| 739 | | {{{ |
| 740 | | <upload_url>URL</upload_url> |
| 741 | | }}} |
| 742 | | URL of file upload handler. |
| 743 | | |
| 744 | | {{{ |
| 745 | | <upload_dir>path</upload_dir> |
| 746 | | }}} |
| 747 | | absolute path of upload directory. |
| 748 | | |
| 749 | | {{{ |
| 750 | | <cgi_url>URL</cgi_url> |
| 751 | | }}} |
| 752 | | URL of scheduler. |
| 753 | | |
| 754 | | {{{ |
| 755 | | <log_dir>path</log_dir> |
| 756 | | }}} |
| 757 | | absolute path of logfile directory. |
| 758 | | |
| 759 | | {{{ |
| 760 | | <bin_dir>relative-path</bin_dir> <!-- relative to project_dir --> |
| 761 | | }}} |
| 762 | | {{{ |
| 763 | | <cgi_bin_dir>relative-path</cgi_dir> <!-- relative to project_dir --> |
| 764 | | }}} |
| 765 | | {{{ |
| 766 | | <sched_lockfile_dir>path</sched_lockfile_dir> |
| 767 | | }}} |
| 768 | | Enables scheduler locking (recommended) and specifies directory where scheduler lockfiles are stored. |
| 769 | | Must be writable to the Apache user. |
| | 502 | <master_url>URL</master_url>:: |
| | 503 | <long_name>name</long_name>:: |
| | 504 | <host>hostname</host>:: |
| | 505 | name of project's main host, as given by Python's `socket.hostname()`. |
| | 506 | Daemons and tasks run on this host by default. |
| | 507 | |
| | 508 | <shmem_key>shared_memory_key</shmem_key>:: |
| | 509 | ID of scheduler shared memory. Must be unique on host. |
| | 510 | |
| | 511 | <download_url>URL</download_url>:: |
| | 512 | URL of data server for download. |
| | 513 | |
| | 514 | <download_dir>path</download_dir>:: |
| | 515 | absolute path of download directory. |
| | 516 | |
| | 517 | <uldl_dir_fanout>N</uldl_dir_fanout>:: |
| | 518 | fan-out factor of upload and download directories (see [wiki:DirHierarchy Hierarchical upload/download directories]). |
| | 519 | |
| | 520 | <upload_url>URL</upload_url>:: |
| | 521 | URL of file upload handler. |
| | 522 | |
| | 523 | <upload_dir>path</upload_dir>:: |
| | 524 | absolute path of upload directory. |
| | 525 | |
| | 526 | <cgi_url>URL</cgi_url>:: |
| | 527 | URL of scheduler. |
| | 528 | |
| | 529 | <log_dir>path</log_dir>:: |
| | 530 | absolute path of logfile directory. |
| | 531 | |
| | 532 | <bin_dir>relative-path</bin_dir> <!-- relative to project_dir -->:: |
| | 533 | <cgi_bin_dir>relative-path</cgi_dir> <!-- relative to project_dir -->:: |
| | 534 | <sched_lockfile_dir>path</sched_lockfile_dir>:: |
| | 535 | Enables scheduler locking (recommended) and specifies directory where scheduler lockfiles are stored. |
| | 536 | Must be writable to the Apache user. |