I have a thought on another method of doing this: Write a shim executable
that does the standard RPC communications between a local manager and the
BOINC Daemon. Since this is local, it can get to the configuration files.
This executable would phone home to the web site occasionally (when is yet
to be determined) and report status to and get instructions from the web
site. If you make this executable a separately installable item, and have
it run in the users context rather than having BOINC download it as a
science application, this would work.
There are still some things that you may not be able to do as the daemon
does not allow the manager to control some things. Some of these things
may be fixable, and some may not.
jm7
Mark Pottorff
<[email protected]
m> To
Sent by: David Anderson
<boinc_dev-bounce <[email protected]>
[email protected] cc
u> BOINC dev
<[email protected]>
Subject
02/23/2010 04:34 Re: [boinc_dev] How to locate
PM boinccmd on client
Please respond to
[email protected]
Thank you David for your interest. I've described in some detail what I
have in mind in my prior post here:
http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2010-February/016384.html
I really didn't ask to read client_state, nor the gui_rpc_auth. I simply
wanted to invoke boinccmd and utilize all of it's documented functions. I
certainly planned to expand functionality later, and anticipated using
information in client_state to do that. But only because there is no other
interface by which to access some of the details found there.
The net of all of this discussion is that the BOINC runtime user does not,
will not, or may not have authority to the gui_rpc_auth.cfg file and
therefore there are at least many use cases where the BOINC client user
will be unable to run boinccmd. Am I correct that even WITH the
gui password specified, boinccmd will be unable to open the file to verify
it when invoked from the BOINC runtime user account, and therefore fail to
run? I believe that's what folks have been trying to drive into my head.
And the net of what I wish to achieve is to allow a web-based UI to have
the ability to perform all boinccmd functions on any client machines which
the user has appropriate credentials for. Define appropriate credentials as
you wish. I'm not trying to control someone else's machine. To do so
withOUT the need for an open TCP port on the client machine, and withOUT
the need for direct internet access in to the machine, and with as little
hassle as possible to set it up.
Beyond that, I also wanted to capture, modify and replace cc_config and
global_prefs_override files. And since there is no UI to do so, I felt a
web-based approach would be a great way to eliminate user errors in making
such changes, and afford detailed descriptions of
the purpose of each setting (I correct my self, local preferences changes
made in BOINC Manager are modifying the global preference overrides, I just
wanted a centralized means to do so for all of a user's hosts. When a new
preference is supported that you wish to use, you don't have to run around
to each and every host to modify a file).
The whole idea was to provide the control as though you were AT the
machine, even though it is 100s of miles away in your grandmother's den, or
across campus in a lab, or on the other side of the school district.
...once that is achieved... version 2 let's you build rules for when to do
things and to define how you like your environment to run. An "auto-pilot"
if you will. And with collaberative knowledge about what is heuristically
out of the norm for a given project application, the system could begin to
flag problem areas in your install base, thus making it easy to locate any
problems and keep things
running smoothly.
Do that, and then user requests like "designate a true primary project" and
"never run two tasks from project X at the same time" and any number of
other "micromanagment" things people wish to do for reasons very specific
to their own usage of BOINC can be supported simply by allowing the user to
establish more complex rules in the control system.
That's it. And if boinccmd cannot be used, I don't see how one gets there
on their own. Now I become dependant upon functionality of AMs that does
not presently exist and I cannot achieve the goal autonomously. Then I have
to try and get everyone to agree on how new AM functions should work, and
that they work for every situation (not just the ones of concern to me),
and assume some day my changes will be checked in. Then I wait for everyone
to get an updated client (but there's no automated way to install it on a
fleet of machines), or they can't use any of my work.
I
felt autonomy from all the rest of what is going on with BOINC would be a
great asset to making progress. Shoot it down, don't use it, fine. On the
other hand, if people like it and want more of it, it could later be
incorporated in some way. The autonomy sort of gives one a sandbox where
the ballon can float, and not impact the rest of the BOINC infrastructure.
A skunkworks if you will.
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 Tue, 2/23/10, David Anderson <[email protected]> wrote:
From: David Anderson <[email protected]>
Subject: Re: [boinc_dev] How to locate boinccmd on client
To: [email protected]
Cc: "BOINC dev" <[email protected]>
Date: Tuesday, February 23, 2010, 2:01 PM
Mark:
I have absolutely no problem with people trying new and
creative approaches with BOINC.
I'm sorry that your ideas were shouted down on this list;
that's not my doing, or the official position of BOINC.
Our goal has always been to enable, not discourage, 3rd-party development.
Having said that: BOINC's account-based sandboxing, if it's enabled,
won't let applications read files like client_state.xml and
gui_rpc_auth.cfg.
The
goal is that apps should have access only to files
in their slot directory or in their project's directory
(in practice, since we don't create a separate account for each
project or each job, they have access to all slot dirs and all project
dirs).
So the idea of controlling the client from an app probably won't work.
However, maybe there's some other way of doing what you want.
Why don't you describe the functionality you envision,
and we can think about how it might be achieved.
-- David
_______________________________________________
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.
_______________________________________________
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.
