Seeing one thread of willingness to improve BOINC here I'll point you to the documentation that describes none of the limitations discussed and decline the invitation to continue the bantering.
"If you run boinccmd in the same directory as the BOINC client, you don't need to supply either a host name or a password." Reference: http://boinc.berkeley.edu/wiki/Boinccmd_tool It is very clear. 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, Nicolás Alvarez <[email protected]> wrote: From: Nicolás Alvarez <[email protected]> Subject: Re: [boinc_dev] How to locate boinccmd on client To: [email protected] Cc: "Charlie Fenton" <[email protected]>, "Rom Walton" <[email protected]>, "BOINC dev" <[email protected]> Date: Tuesday, February 23, 2010, 12:00 PM On 2/23/10, Mark Pottorff <[email protected]> wrote: > Allowing one project to abort another project's tasks should only be allowed > with the user's consent. Allowing one project to do anything with the core client, be it abort other project's tasks, or even detach *itself*, should never be allowed at all. > 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. Yes, it would be ideal for the sandbox to be strict enough to prevent all that. It currently doesn't, but leaving those "holes" open is not a design decision; just that it wasn't restricted enough *yet*. > 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? Any non-read-only activity via boinccmd already needs authentication. > 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. What kind of "basic application design principles" are the developers unaware of? I'm not saying BOINC (or its developers) are perfect, just wondering what *you* mean with that. > 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. It was obvious that connecting to the core client from a running science app and altering the client's state is supposed to work...? > This was validated by careful review of the > available documentation which explicitly indicates my planned usage does not > require a gui password. The documentation says aborting tasks doesn't require a password? Please give a link so I can fix it. > 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. A project science app has no business doing anything of what you said you want to do. If you want an app that eg. aborts workunits by telling the client to do so over GUI RPC, make it a separate app that the user installs. Don't abuse BOINC as an easy way to get your code running on the machine. A science app is supposed to do *processing*. I believe it would be a good idea to *add* new features to the client's sandbox to ensure "monitoring and control" of the BOINC client is impossible to do from a science app. -- Nicolas _______________________________________________ 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.
