This sounds more like it ought to be an account manager and not a project.

 

----- Rom

 

From: Mark Pottorff [mailto:[email protected]] 
Sent: Monday, February 22, 2010 4:06 PM
To: Charlie Fenton; Rom Walton
Cc: BOINC dev
Subject: RE: [boinc_dev] How to locate boinccmd on client

 

Any number of interesting statistics could be gathered. Things that individual 
projects do not know, or at least do not track. Such as their actual resource 
share, number of hours per day machines are on. With information from many 
projects and many host environments, anonomolus tasks can be identified 
quickly, and rules created to help users purge such tasks from their machines. 
Work requests could be deferred from projects that are recovering from an 
outage to help it get back on it's feet.

David Anderson wrote a paper and says you need 2.8 BOINC CPUs to get the 
equivalant of 1 dedicated CPU (such as comparing with a cloud or in-house 
cluster). But this is only true if you assume your project has the same average 
resource share, and the same crunching hours per day as the projects that were 
sited in the paper. If either of these varies, then the 2.8 estimation is of no 
value. But noone can really tell you if there is variation across BOINC 
projects because noone has the data. Do users tend to devote 70% share to SETI, 
but only 40% to Rosetta? You could try and infer data from the stats, but you 
have to assume things like the user has not changed their configuration over a 
period of time, and their machine was active for it's typical duration during 
the period studied, and all their debts were under control and all the client 
was able to get work from all of their configured projects.

I certainly agree that a project controlling a client machine SOUNDS like it 
COULD be something to discourage. But keep in mind all of the participants that 
have been looking for new features and been told they cannot be implemented. 
Such as orchestrating one WU from a low memory usage project running along side 
one from a high memory usage project, rather then trying to run two at once 
from the high memory project. Yes, you can achieve some of that with the 
available extensive preference settings, but you can't easily see it is working 
as desired, and you still end up starting work that ultimately will grow to 
exceed the configured memory bound. Thus leaving uncheckpointed work hanging 
until memory is available. In some cases, the client firing up a string of 
tasks only to ultimately find each grows to exceed the memory configuration can 
actually make the situation worse by filling the swap space.

Keep in mind that the only machines this project would be installed upon would 
be those that the participant WANTS it installed upon. So the only directives 
sent are based upon the participant's request. So it is a tool, not a virus. If 
the participant wants to shutdown everything but one project, this just gives 
them a means to do so that does not require opening up a firewall, driving 50 
miles, or trying to direct their parent through how to use a mouse. And having 
such a tool exist in the world doesn't create any new exposures to network or 
security. In fact, it might actually be used to detect, report, and repair 
holes in security that users want to be aware of.

It will enable a corporate environment to observe and control machines in a 
mannar that is currently only available to them if they have an open TCP port 
on every BOINC client machine. At present, this lack of control is one serious 
obstacle to getting BOINC installed in corporate and campus environments. The 
answers to the "what if..." questions such as "what if we decide we don't want 
SETI running on every PC in the school system?" are not pretty. What if a BOINC 
project is found to be rogue, can we control which projects the machines are 
allowed to attached to? Account managers, right, can we insure all our machines 
are running through the account manager? What if a task consumes 3 days of CPU 
time before finally ending in error, is there a way to purge it from our 
systems? 

Think of your own (BOINC project server lab) environments. Where the machines 
are all in your own lab?? Can we suspend production work on our machines, and 
have them immediately pick up test WUs from our internal alpha test project? 
...well uh... not exactly. But they will TEND to do so once they hit a 
checkpoint, and update to the test project scheduler... but wait there's been 
no work there for days so the backoff is long... you want those machines to 
begin the testing within the hour. Isn't suspending your production project, 
and doing an update on the test project the ideal way to get the alpha work 
running?

Such a mechanism could also be used to deploy software (in addition to BOINC 
updates), and better track and manage a fleet of machines. Thus offering an aid 
to that corporate IT director. It just depends upon how they have set up the 
BOINC environment and how they wish to utilize it.

Such a mechanism could help manage a cluster of cloud resources and shut them 
down when they are not in use. If you fire up 50 machines in a cloud, running 
Linux, Windows and various BOINC versions, point them to a test project and 
have them run, wouldn't you want some kind of console to observe and control 
everything from? ...or would you rather jot down 50 IP addresses and manage 
each one directly?

There are a lot of possibilities for such a thing once people can see how it 
works. Possibilities that promote BOINC, aid BOINC projects, and offer 
flexibility to BOINC users.

Running Microsoft's "System Idle Process" will never help cure cancer,
AIDS nor Alzheimer's. But running rose...@home just might!
http://boinc.bakerlab.org/rosetta/

--- On Mon, 2/22/10, Rom Walton <[email protected]> wrote:


From: Rom Walton <[email protected]>
Subject: RE: [boinc_dev] How to locate boinccmd on client
To: [email protected], "Charlie Fenton" <[email protected]>
Cc: "BOINC dev" <[email protected]>
Date: Monday, February 22, 2010, 12:20 PM

Well the separation of the executable directory and data directory is the 
default for Windows and Mac.

 

What you are attempting to do is discouraged to some extent.  For instance, you 
don’t want a project to be able to suspend all other projects on the machine so 
it can have sole use of the machine.

 

What is your project attempting to discover?

 

----- Rom

 

From: Mark Pottorff [mailto:[email protected]] 
Sent: Monday, February 22, 2010 12:53 PM
To: Charlie Fenton; Rom Walton
Cc: BOINC dev
Subject: RE: [boinc_dev] How to locate boinccmd on client

 

When I say "BOINC App" I am referring to a BOINC project that sends WUs 
comprised of simple script files that do things like:
boinccmd --get_state >out1.txt
and send their "results" back to the project (which hosts a website that allows 
you to review the data and initiate control operations, which in-turn creates 
WUs customized for your host machine).

So everything I (attempt to) do is running as the BOINC user, on the local 
machine, from within the sandbox. I can see that the BOINC user may be limited 
so far as snooping around the machine. That's what the sandbox is for. That is 
why I cannot count on snooping around to locate the boinccmd. And there could 
be more then one installed.

I don't typically install as a Windows service, so perhaps I'm missing 
something. But sandboxes are made to keep things in, not out. Everything 
required should already be in the same sandbox as my WU's "application" script 
file from the slot directory.

So, if I hit the right boinccmd, it will change to the data directory that I am 
running within, and not require a host name and password. Heck, I could 
actually open the ..\..\gui_rpc_auth.cfg file if I use file seperator 
appropriate for the host. But I still wouldn't know for certain where boinccmd 
is if the user seperates the data directory from the BOINC client code.

Running Microsoft's "System Idle Process" will never help cure cancer,
AIDS nor Alzheimer's. But running rose...@home just might!
http://boinc.bakerlab.org/rosetta/

--- On Mon, 2/22/10, Rom Walton <[email protected]> wrote:


From: Rom Walton <[email protected]>
Subject: RE: [boinc_dev] How to locate boinccmd on client
To: [email protected], "Charlie Fenton" <[email protected]>
Cc: "BOINC dev" <[email protected]>
Date: Monday, February 22, 2010, 11:28 AM

I'm afraid that isn't how it works.

Boinccmd attempts to lookup the password by opening up the gui_rpc_auth.cfg 
file in the current directory ( On Windows, boinccmd changes the working 
directory to the data directory before looking ).  If gui_rpc_auth.cfg cannot 
be opened it looks at the command line argument.

If BOINC is installed as a service on Windows, or in a sandbox configuration on 
the Mac, then there are several permission issues to contend with depending on 
how your application is to be executed.

When you say "BOINC App" are you referring to an application that the volunteer 
launches to control BOINC, or are you referring to an application that is 
launched by BOINC as a project application?

----- Rom

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Mark Pottorff
Sent: Monday, February 22, 2010 12:06 PM
To: Charlie Fenton
Cc: BOINC dev
Subject: Re: [boinc_dev] How to locate boinccmd on client

According to the doc, the requirement for GUI RPC password only applies when 
you run boinccmd from some other subdirectory or machine. If I can locate the 
boinccmd from the same directory as the active core client, and contact the 
client via boinccmd rather then GUI RPC over the network, then I'm expecting 
boinccmd to be fully functional without the password. 

Are there other undocumented limitations on functionality? I see no mention of 
any reduced level of functionality. Either you're allowed, or you're not. Nor 
do I see any mention that Mac clients may not have boinccmd available. So 
please advise.

I am tinkering with a "BOINC app" that allows monitoring and control of the 
client via browser rather then a direct network connection. All interaction to 
the client machine is done via BOINC scheduler and "application", so no direct 
network connectivity is required (beyond the normal BOINC client-pull scheduler 
protocol). How would you like to be able to abort a bad task on your alpha 
cluster, or set the debug flags on one of your alpha machines without having to 
actually locate the physical machine and run down there to modify cc_config? 
...or detach all of the machines in a school system from a project, perhaps 
even uninstall BOINC, all from a website?

I'm looking at installing BOINC client version upgrades as well, but need to 
locate command line arguments to suppress GUI. I seem to recall there are some, 
but haven't had a chance to track them down, so if anyone knows off-hand, I 
need to get that in my notebook.

I still have a number of dots to connect before I am ready to launch an alpha, 
but by all means contact me directly if you have interest in using such a 
monitor and control system.

Running Microsoft's "System Idle Process" will never help cure cancer,

AIDS nor Alzheimer's. But running rose...@home just might!

http://boinc.bakerlab.org/rosetta/ <http://boinc.bakerlab.org/rosetta/> 

--- On Sun, 2/21/10, Charlie Fenton <[email protected]> wrote:

From: Charlie Fenton <[email protected]>
Subject: Re: [boinc_dev] How to locate boinccmd on client
To: [email protected]
Cc: "BOINC dev" <[email protected]>
Date: Sunday, February 21, 2010, 4:55 PM

On 2/20/10, Mark Pottorff <[email protected]> wrote:
>  I would like to find a reliable means of locating (on all supported
>  platforms) the full path to the boinccmd executable from an application
>  running in a slots directory.

At 9:29 PM -0300 2/20/10, Nicolás Alvarez wrote:
> On Mac, I think boinccmd isn't installed at all in the default package.

On the Mac, the user has the option of downloading the command-line version of 
teh client which includes boinccmd.  They normally would install it in the 
standard BOINC Data directory at "/Library/Application Support/ BOINC Data/".

But even if boinccmd _is_ installed, project applications do not have access to 
the gui rpc password under sandbox security, so they can only perform limited 
functions using boinccmd.  I don't know if this is also true on Windows.

What do you want your project application to do with boinccmd?  In other words, 
for what do you want your application to use boinccmd?



      
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev 
<http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev> 
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

 

_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to