Your code already does not work because of the sandbox. It is not that we
are proposing to make it not work all of a sudden.
jm7
Mark Pottorff
<[email protected]
m> To
Sent by: Charlie Fenton
<boinc_dev-bounce <[email protected]>, Rom
[email protected] Walton <[email protected]>
u> cc
BOINC dev
<[email protected]>
02/23/2010 10:55 Subject
AM Re: [boinc_dev] How to locate
boinccmd on client
Please respond to
[email protected]
I would further elaborate on your statement...
Allowing one project to abort another project's tasks should only be
allowed with the user's consent.
In other words, the monitoring and control project should be
"well-behaved". I fail to see how AMs are any more well-behaved then the
method I describe. As I've described it, I received the user's consent when
they attached to the project, and again when they authenticated on the
project website to define the directives they wish to perform. But you are
correct that a robust system would authenticate that concent was given to
perform the operation.
So, if you are going to make changes, they should assure that all activity
on the client is well-behaved. This means that BOINC is not the only code
that should be insulated from any tampering by the applications. The
applications need insulation from each-other as well. Essentially you
should have a unique user per project. Otherwise one slot directory can
clobber another. One application to go up to another's project directory
and trash all of the stored files, etc. etc.
Any and all activity via boinccmd should require some form of
authentication. Otherwise how do you know the request isn't coming from a
melicious student in a campus computer lab, rather then the admin that is
responsible for what is going on in that computer lab, and installed BOINC
there?
Since there are no monitoring and control projects that are not
well-behaved, and no user's have been impacted by what you now seem to feel
is a flaw rather then a feature, I don't see the immediate need to make any
change and add features to the AM system.
I've been operating under the assumption that we're all working to make
BOINC easier to use. But my experience with this simple exchange has led me
to believe otherwise. It deeply sadens me to see that the folks responsible
for the ongoing features of BOINC are so unaware of basic application
design principles. And that it requires me pointing out how things actually
work for such "flaws" to be discovered and remedied. To my way of thinking,
it was glaringly obvious that the system was supposed to work in the mannar
I was planning to use it. This was validated by careful review of the
available documentation which explicitly indicates my planned usage does
not require a gui password. If folks can't depend on the documented
description of BOINC, then how are they supposed to take the leap of faith
to allow themselves to grow dependant upon it and use it to do their DC?
I would point out that any and all changes you do make should still
support me doing what I've described. You are just making it more
difficult for the user to get it set up, because they'd have to run
around and get all of their rpc passwords to configure their hosts for
remote monitoring and control. Similar to the way that they may have to
define for the system where to find the boinccmd executable on every
single host machine they wish to monitor. But I would assert that any
system that does NOT allow and enable monitoring and control is a
greater threat to BOINC survival then anything else that has been
described in this exchange.
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, 10:39 PM
One project should not be able to interfere with another. Allowing
one project to abort another projects tasks should not be allowed.
I could see adding these features to the account manager mechanism.
----- Rom
From: Mark Pottorff
[mailto:[email protected]]
Sent: Monday, February 22, 2010 5:51 PM
To: Charlie Fenton; Rom Walton
Cc: BOINC dev
Subject: RE: [boinc_dev] How to locate boinccmd on client
I wasn't aware account managers had the ability to
establish "shoot on sight" rules for WUs, or the ability to prompt
you through establishing checkpoint debug in your cc_config on 5 of our
machines. And how many AMs allow you to configure frequency of scheduler
contact? I haven't seen any that allow you to download updates for your
deployed non-BOINC applications or perform any non-BOINC activities on a
machine.
I believe the only reason one would say that is that it's the closest
thing
BOINC presently has to anything like what I'm talking about. But it
really is
like saying that apples and oranges are both spherical, so why not just
use
these oranges that I've got on-hand for your carmel dunking?
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, 3:29 PM
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/
--- 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
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.
_______________________________________________
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.
