I'm requesting permission to run Rosetta on some corporate computers and I've got a meeting next week to put my proposal forward. It'd be helpful to have a list of how to's so I can deal with any potential show-stoppers as they arise.

The main things I assume will be:

Security
I need any info on this as I assume it will be the biggest issue. I know it will be a case of running in a sandbox account with minimal privelidges.

Roll-out and maintenance requirements
What's the deal with roll-out on imaged computers? It uses the computer name, but can registration be done by script?

Network Utilisation
I know it can be limited to connect after hours. Not sure about Proxy details.

Effects on Hardware
Think i've got this one covered - I know about leakage from thermal expansion of CPUs with temp changes etc, and the fact that the lifespan of the components (except maybe the HD) is determined by obsoletion rather than breakdown.

Disk writes can be limited to once every x seconds. There's also the option of running only when the comp's not in use.

Any help on these or any other issues would be useful!
cheers
Danny

---

I run boinc on about 300 machines in our department. We haven't had any issues other than the clients stopped working a couple months ago when the domain administrator account's pw was changed.

Security shouldn't be an issue. All communication is initiated by each workstation. . the server (or a baddie) is not able to initiate communication with your client. Plus, I believe all work units are signed to verify they're from a given project.

Roll out is very easy if you have a windows domain. You just create a domain startup script that looks for boinc.exe, if it's not there, you run the installation from a network share. I don't know the details, but all it involves is editing a text file with your account information and preferences. Another plus for this method is you don't have to spend any time installing it on new workstations, it installs itself.

Communication is minimal if you have a regular network. You can set your WU times to be high (12-24h) and reduce traffic even more.

---

Not shure if it helps, but it's VERY interesting IMO: http://www.thelazyslug.com/boinc.htm --> a very informative site dealing with roll-out and maintanance of BOINC in networks.

BTW: Your efforts are really appreciated, and I wish you the best for that meeting!

---

As for doing registration by script... there is some info on that on the BOINC site here. And on security using code signing as well.

Also, the areas of resistence you are likely to run in to and some solutions for them have been discussed in the reasons some people avoid BOINC projects thread.

Please post your experience there (good or bad), to help build that thread as a resource for others in the future.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

One of the things that occured to me in thinking about a large rollout like that was that if I set things up to use the network from 7PM through 6AM... ALL of the PCs are going to kick in right at 7:00PM and try and upload a result or update with the project.

So, I'd suggest you perhaps create multiple images, each with a different BOINC location, or perhaps a different user profile, and have some of them use the network from 7PM-2AM, others from 8PM-3AM and so on. The main burst of activity will likely be in that first hour, so leaving some room after that to recover any communications problems or in case the project happened to be down at that time etc.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

If you set the buffer large enough (i.e. 5 days or something) there probably will not be a real "queue" right at the start of the allowed time. The client might not even connect every day, let alone right at the start of the interval. Unless, off course, you set the client to return results immediately.

---

Thanks for the replies - keep them coming!

What about running through a proxy. I know network utilisation can be reduced by longer run times, but will a proxy image of a file be used over downloading a new one for each computer?

---

Thanks for the replies - keep them coming!

What about running through a proxy. I know network utilisation can be reduced by longer run times, but will a proxy image of a file be used over downloading a new one for each computer?

No proxies work fine. (see next bit)




-----

Actually that's not quite true but in reference to what you mention it does.
There are problems with proxies that need authentication (such as my universities squid proxy) and I've had great problems with it. It always seems to be on the upload though, it'll upload get to 100% then fail and then keep trying. Seems to happen mainly with the larger uploads and is not specific to Rosetta. But this doesn't effect all projects I tried it on (biggest culprits Einstien, Seti, Rosetta and CPDN). Strangly didn;t effect all computer either (though I do know it was the proxy as if I used a different conection with noe proxy it worked fine).

From reading the dev list the very newest boinc client has fixed (or so far reported) to have fixed this problem.*

You may want to think abou rolling them out and having them attach to a BOINC Manager so you have a little more control over them, depending on how you roll it out.



*(of course now I'm about to finish my University course in 1 1/2 weeks it's a little late.)

---

Team mauisun.org

Hi dcdc,
I think this can help you to solve your problem, especially [b]Part4: Deploying clients with BoincStudio[/b)
Happy crunching :-)

Hi dcdc,
I think this can help you to solve your problem, especially Part4: Deploying clients with BoincStudio
Happy crunching :-)

One of the things that occured to me in thinking about a large rollout like that was that if I set things up to use the network from 7PM through 6AM... ALL of the PCs are going to kick in right at 7:00PM and try and upload a result or update with the project.

On a group of corporate machines where I have permission to run Rosetta, I don't limit network access time, but I do limit operation times to off-hours. With this mode, I don't see any surge against the network. At "start time" the majority of machines are resuming an in-progress work unit, not sitting there with results waiting to upload.

I do have the prefs set for 12 hour preferred run times, and only connecting to the network four times per day.

I use the, "Leave applications in memory while suspended" option. Worst case (if a user has rebooted one of the machines) is picking back up at the last checkpoint.

---

True, my thoughts were based on crunching 24hrs, as I've had no problems on my own machiens doing this, and using them for my applications as well. When your machine has been crunching all day, it's generally finished something that it needs to upload. So, I guess it's all the file uploads that hit right away when "network allowed" time hits. Uploads are fairly small, so perhaps it's really a non-issue. It may also serve other advantages later to randomly (or perhaps not randomly) distribute a number of machines to each BOINC location for future configurations.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

meeting scheduled for thursday next week. I'll be away for the weekend but I'll put together a doc that I'll take with me with the proposal etc.

Has anyone got any firm details on the AD install and connection process? I assume that the sensible way to run it would be to run it under it's own specific account with minimal priveledges? What read-only and write access to other folders would BOINC need - e.g. Windows folder or just its own? I might be going overboard but I'd rather be able to lay any fears to rest on the spot!

Network utilisation I think i'm on top of - need to check that info about proxies in the latest versions - thanks FC.

---

If you go to the reasons some people avoid BOINC projects thread and search on the word "sandbox", you will see more about setting up a Windows user with little privilages, and run BOINC under that user.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

I've been trying to run BOINC as a limited user for a while, and for the most part it's quite straightforward to do. But I kept hitting one rather annoying problem - everytime the BOINC service stopped, it trashed its client_state.xml file (and client_state_prev.xml too), so the next time it was started it wasn't attached to any projects.

In the end I put things back to how they were and I keep meaning to revist this and try to work out what was going wrong.

If you're going to change the user account that BOINC runs under, take a backup of everything first - just in case!

---

meeting scheduled for thursday next week. I'll be away for the weekend but I'll put together a doc that I'll take with me with the proposal etc.

Has anyone got any firm details on the AD install and connection process? I assume that the sensible way to run it would be to run it under it's own specific account with minimal priveledges? What read-only and write access to other folders would BOINC need - e.g. Windows folder or just its own? I might be going overboard but I'd rather be able to lay any fears to rest on the spot!

Network utilisation I think i'm on top of - need to check that info about proxies in the latest versions - thanks FC.

Create a special BOINC account. Run as a service.

The special BOINC account needs read/write access to the BOINC directory (where ever you put it) and about nothing else. It needs to read the location where the windows core executables reside, but it does not need write access here.

BOINC installs fairly neatly as an image. The only gotcha is that if you install as a service, you have to take the registry along as well. Joining a project during install is as simple as copying the correct account_*.xml file into the BOINC directory, stopping BOINC (if already started) and restarting. The way I would create the image is to install BOINC as a service, stop BOINC, copy the account_*.xml files needed. This is the image. You will also need some portion of the registry so that it is registered as a service (I have not looked into that).

Good luck.

---

BOINC WIKI

Setting it up as a service is probably quite important, it means it'll run while at the waiting for a login stage without many problems. i.e. at the time you really want it to be running.

---

Team mauisun.org

Just my 2 cents worth - hope it's helpful.

I'm requesting permission to run Rosetta on some corporate computers and I've got a meeting next week to put my proposal forward. It'd be helpful to have a list of how to's so I can deal with any potential show-stoppers as they arise.

The main things I assume will be:

Security
I need any info on this as I assume it will be the biggest issue. I know it will be a case of running in a sandbox account with minimal privelidges.

There's two parts to this - trust in the application itself, and then the security concerns of hitting the Internet from time to time. My rebuttal to both of these would be to point out that if BOINC posed any sort of "active" security risk, Slashdot would have cut BOINC to shreds. That said, running in a "sandbox" account is a smart move, which can't do anything but help. I'm not THAT familiar with the vagaries of setting up such a thing, but in essence I'd imagine that it degenerates to limiting the sandbox account to just the bare minimum needed for running an application in a command prompt.

It occurs to me that in your setup, remote admin using something in the league of BoincView is almost a necessity, therefore you'll need an "admin" system on the same "subnet" as the farm, because remote admin is the one thing that requires a "farm" machine to maintain a listening socket. Again, a firewall should be considered essential to ensure that access to these open ports is limited.

Roll-out and maintenance requirements
What's the deal with roll-out on imaged computers? It uses the computer name, but can registration be done by script?

I can say for absolute certain that simply copying a working BOINC folder from one machine to another (with all registration and project attach functions completed) does do the "right thing". It may be slightly quirky until each system has reported in a few times, but in the long term it's a completely viable system. Simply because this is how I installed on a couple of systems when I had my farm running. The caveat then being that you'll need to run round and grab the remote admin passwords from these boxes if you plan on doing the BoincView thing. That's a one time operation though.

Network Utilisation
I know it can be limited to connect after hours. Not sure about Proxy details.

BOINC has always worked with HTTP proxies, but up to at least 5.2.x it did not function correctly with Socks 5 proxies. I am 99.999% certain that the Socks 5 issue was fixed with the release of 5.4.x, but since I (a) still run 5.2.11 and (b) don't need proxy services to get out anyway, I'm not going to give that the last 0.001%

Effects on Hardware
Think i've got this one covered - I know about leakage from thermal expansion of CPUs with temp changes etc, and the fact that the lifespan of the components (except maybe the HD) is determined by obsoletion rather than breakdown.

Pass - looks like you have that one covered.

Disk writes can be limited to once every x seconds. There's also the option of running only when the comp's not in use.

Any help on these or any other issues would be useful!
cheers
Danny

Good luck. The more horsepower we bring to the show, the better.

---

...
BOINC has always worked with HTTP proxies, but up to at least 5.2.x it did not function correctly with Socks 5 proxies. I am 99.999% certain that the Socks 5 issue was fixed with the release of 5.4.x, but since I (a) still run 5.2.11 and (b) don't need proxy services to get out anyway, I'm not going to give that the last 0.001%
...

HTTP in 5.4.x does not always work (I am proof, so are others), though in 5.6.x it should be fixed. I'm yet to try it in the newer boinc though.

---

Team mauisun.org