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.
