I've got a group of computers I'm running a concept on.

I'm trying to install Boinc as a service (protected mode I think it's called now?), and attach it to my account under Seti@Home. (I'm also attempting to use Boincview to manage them.)

I can remotely execute commands to them all at once, including copying files, and any other commands I can run from the command line.

I've found options for the downloaded .exe (with /help), and one that wasn't mentioned - /a . I've also found a ton of threads and wiki entries for significantly older versions of Boinc, about mass deployments, none of which seem to make a whole lot of sense, and all of which seem to involve way... way too much work (rewriting the installers? seriously?)

My question is: Can you install as a service (protected mode) from a command line? My thinking is thus:

1) Copy the installer and/or install files from a shared directory to each computer.
2) Run the installer on the remote systems with the /silent switch (or whatever it is).
3) Issue a cmd to stop the service.
4) Copy all the required account files and .cfg files (remote_hosts.cfg, gui_rpc_auth.cfg, and the .xml files) from a shared directory to the ProgramData directory on each client.
5) Issue a cmd to start the service.
6) Connect from BoincView, serve at room temperature.

If you can't *install* as a service, can you tell it to run after the fact as a service? I've run boinc by just copying the program files directory from an existing computer to a new system (a domain controller, thus it didn't want to create the protected account) and run from there. Is that possible, then tell boinc or boincmgr to run as a service? All through the cmd line.

The boinc wiki (boinc-wiki.info) seems to be pretty outdated, so I question it's reliability. Anyone have any suggestions?

Thanks in advance -

Ok, I'm writing this update for two reasons - one, so anyone can see how this may work (or not work) and suggest corrections, and two so I can remember where I left off after I go home tonight.

So far, here's how I get it to work:

- copy the c:\program files\boinc directory from an existing install to a directory in a share (c:\shared\boinc, for instance).
- Copy the global_prefs.xml and global_prefs_override.xml FROM the boinc Data directory (c:\programdata\boinc) to c:\shared\boinc (wherever boinc.exe is).
- Copy the shared boinc directory to the workstation you're deploying to (from \\computer\shared\boinc to c:\boinc , for me). Leave the data directory be.

Here's the work in progress part (i need to script this):

- From the workstation you're deploying to, open the program directory (c:\boinc) and right click on boinc.exe and hit Run As Administrator (in Vista/7/Svr 2008, otherwise hold down shift, right click, pick Run As, and enter a local admin). A command window should open with boinc readouts, you should see

"21-Jan-2010 19:47:45 [---] Reading preferences override file" and
"21-Jan-2010 19:21:42 [---] This computer is not attached to any projects"

- Open another command prompt as administrator. cd to your boinc program directory. run:

boinccmd --project_attach (projecturl) (projectkey)

ie.
boinccmd --project_attach http://setiathome.berkeley.edu abcd1234myweakkey5678

Next i need to:
- Write the remote_hosts.cfg file, and find how to incorporate a password. My computers are isolated, so i'm not that worried about it right now, but i may be in the future.
- Create the service. (http://support.microsoft.com/kb/251192)
- Script this all.

What i'm seeing:
- with no c:\programdata directory, boinc is using it's program directory (c:\boinc\projects) for the project data. Kind of cool.
- When you exit (ctrl+c) from the boinc.exe window and start it up again, it seems to download your work file all over again. Wtf?

These computers run a lot of remotely executed CPU heavy programs, and then they sit idle a lot (workyourtailoff, then sitforages, then workyourtailoff, then sitforages). My end goal is to set up boinc to suspend work when another app takes over the CPU. I'd rather not limit CPU usage, and i can't say "suspend when in use" because users never log into the machines.

Next question, is there a way to abort work in progress? If I need to delete and reinstall boinc, can I gracefully tell it to abort what jobs it's been assigned?

Cheers.

- Open another command prompt as administrator. cd to your boinc program directory. run:

boinccmd --project_attach (projecturl) (projectkey)

ie.
boinccmd --project_attach http://setiathome.berkeley.edu abcd1234myweakkey5678

That wouldn't be necessary if you'd copy the account*.xml file(s) too from the data directory.

Next i need to:
- Write the remote_hosts.cfg file, and find how to incorporate a password. My computers are isolated, so i'm not that worried about it right now, but i may be in the future.

The password is in the gui_rpc_auth.cfg file

What i'm seeing:
- with no c:\programdata directory, boinc is using it's program directory (c:\boinc\projects) for the project data. Kind of cool.
- When you exit (ctrl+c) from the boinc.exe window and start it up again, it seems to download your work file all over again. Wtf?

These two might be interdependent. The data directory is stored in the registry ([HKEY_LOCAL_MACHINE\SOFTWARE\Space Sciences Laboratory, U.C. Berkeley\BOINC Setup]).

These computers run a lot of remotely executed CPU heavy programs, and then they sit idle a lot (workyourtailoff, then sitforages, then workyourtailoff, then sitforages). My end goal is to set up boinc to suspend work when another app takes over the CPU. I'd rather not limit CPU usage, and i can't say "suspend when in use" because users never log into the machines.

Would the <exclusive_app> option in the cc_config.xml meet your expectations?

Next question, is there a way to abort work in progress? If I need to delete and reinstall boinc, can I gracefully tell it to abort what jobs it's been assigned?

If you detach the host from SETI before the uninstall and re-attach afterwards all tasks get flagged as "Client detached" and sent to other hosts. However, if you backup the data directory and restore it before the reinstall (pointing the installer or the registry there), the work should be continued from where it left off.

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

Thanks for the very helpful response... saved me a few hours more research there.

That wouldn't be necessary if you'd copy the account*.xml file(s) too from the data directory.

I tried that, and it didn't seem to care. I'll give it another go during a rework.

The password is in the gui_rpc_auth.cfg file

I read somewhere that the hash in that cfg changes every time boinc.exe is started. Is that not the case?

What i'm seeing:
- with no c:\programdata directory, boinc is using it's program directory (c:\boinc\projects) for the project data. Kind of cool.
- When you exit (ctrl+c) from the boinc.exe window and start it up again, it seems to download your work file all over again. Wtf?

These two might be interdependent. The data directory is stored in the registry ([HKEY_LOCAL_MACHINE\SOFTWARE\Space Sciences Laboratory, U.C. Berkeley\BOINC Setup]).

Without running the installer, registry keys aren't being created (i just checked). I'm hoping to avoid using the registry, unless I can find silent & service-mode switches for the installer. I'm shooting for either full blown install, or light and fluffy. Do you know of these switches for the installer (either the .exe or the .msi)? I found and tried LazySlug's MSP creater .hta file, but it didn't seem to like either Server 2008 or the msi I pointed it to.

And I'm still not sure why just exiting boinc.exe would force it to redownload the workunits in progress. The data directory wasn't touched from exit to re-running. Maybe this is standard behavior and it really did resume rather than start over?

Looking at the log, it's also possible it downloaded a work unit to last it through a day, which is what my prefs file was set to. I'd asked it to hold on to at least 24 hours worth of work. I'll fix that, see if the problem goes away.

Would the <exclusive_app> option in the cc_config.xml meet your expectations?

Ordinarily yes, but these computers get varying apps and tasks executed on them. The actual exe is generally the same, but not always, and I can't predict all the .exe's to be used. Otherwise, yeah - it'd be perfect. Just not for me. :( There's a scheduler that runs that kicks off the applications. There may be a way I can script it to send a suspend cmd to seti before each job, and a resume cmd afterwards. I'm looking into it.

If you detach the host from SETI before the uninstall and re-attach afterwards all tasks get flagged as "Client detached" and sent to other hosts. However, if you backup the data directory and restore it before the reinstall (pointing the installer or the registry there), the work should be continued from where it left off.

Once they're installed I'm hoping to leave them running, it's just during this trial process that they're getting installed, running, and aborted that I'd rather not lose a night's work.

Thanks again.

That wouldn't be necessary if you'd copy the account*.xml file(s) too from the data directory.

I tried that, and it didn't seem to care. I'll give it another go during a rework.

It worked for me. I'm still running BOINC 5.10.45 (and 5.8.16), though. Since the version-5 BOINC doesn't depend so much on the registry, wouldn't it be easier for you to use that version? Since your computers are hidden, I can't tell which version you are currently running.

The password is in the gui_rpc_auth.cfg file

I read somewhere that the hash in that cfg changes every time boinc.exe is started. Is that not the case?

That is not the case. It's only generated if the file is missing at startup. You can enter a password of your liking.

And I'm still not sure why just exiting boinc.exe would force it to redownload the workunits in progress. The data directory wasn't touched from exit to re-running. Maybe this is standard behavior and it really did resume rather than start over?

Resuming is standard behaviour, but not re-downloading.

Looking at the log, it's also possible it downloaded a work unit to last it through a day, which is what my prefs file was set to. I'd asked it to hold on to at least 24 hours worth of work. I'll fix that, see if the problem goes away.

That sounds more plausible.

Would the <exclusive_app> option in the cc_config.xml meet your expectations?

Ordinarily yes, but these computers get varying apps and tasks executed on them. The actual exe is generally the same, but not always, and I can't predict all the .exe's to be used.

The list for the <exclusive_app> option can be quite long :-)

Gruß,
Gundolf

It worked for me. I'm still running BOINC 5.10.45 (and 5.8.16), though. Since the version-5 BOINC doesn't depend so much on the registry, wouldn't it be easier for you to use that version? Since your computers are hidden, I can't tell which version you are currently running.

The latest, all freshly downloaded. Yeah, gotta keep them hidden unfortunately. Privacy concerns. I can see that boincmgr is 6.10.18, but I can't pull the version numbers from the boinc clients. Whatever was available yesterday.

That is not the case. It's only generated if the file is missing at startup. You can enter a password of your liking.

You're absolutely right. Remote commands through BoincView and BoincManager are working perfectly now. Thanks!

Looking at the log, it's also possible it downloaded a work unit to last it through a day, which is what my prefs file was set to. I'd asked it to hold on to at least 24 hours worth of work. I'll fix that, see if the problem goes away.

That sounds more plausible.

Yep. that was the case. It's resuming where it left off each time. I shrunk the buffer down to 0 so that it didn't bring in any more. It's a bit retentive of me, but I'd rather not allocate jobs to myself that i know may get aborted/dumped inadvertently.

Ordinarily yes, but these computers get varying apps and tasks executed on them. The actual exe is generally the same, but not always, and I can't predict all the .exe's to be used.

The list for the <exclusive_app> option can be quite long :-)

I'll keep that in my back pocket, i'm sure it will come in handy at some point.

I've managed to get mass deployments working almost flawlessly. It's all self contained (no installer, no registry entries, only a service created), and your tip about the accounts*.xml file simplified things immensely. I can run a single xcopy of a source directory on a network share, then kickoff boinc.exe on each computer, and use a remote commander (boincview) to monitor/view/start/stop etc each system, or send bulk commands.

I've got two final issues right now.

- I can't get boinc.exe to send stdout to a text file. Since it will be running as a service, and the console window will be hidden, I'd like it to write to a log file so I can track/debug as necessary.

- The boinc service I create (sc create boinc start= auto binpath= "c:\boinc\boinc.exe --daemon") will start, and boinc.exe runs in the background, but only uses about 2mb memory, and never starts the seti exe. It's not kicking off the work, and I can't see why, because I can't get it to write to a log file. There was also a -- flag to set, --redirectio i think? (cut off in the wiki) but it doesn't seem to work. Should it be --redirection?

I've tried running the service as localsystem, and verifying permissions to all the files, they all look good. I've also tried running it as my admin account, both do the same thing - boinc.exe, but no seti*.exe's.


BoincView, now that it's working, seems to be an excellent concept. A little clunky in places, but the general idea is fantastic. I'm a little surprised the boinc devs didn't incorporate the functionality into boincmgr. The ability to run a subnet of systems from one manager/scheduler would be heaven to a system like this one.

Thanks & Cheers -

(this one's not quite as important, but i'm definitely curious)

However, if you backup the data directory and restore it before the reinstall (pointing the installer or the registry there), the work should be continued from where it left off.

Tried that on one of the systems - uninstalled the complete installation, scanned the registry and pulled out all boinc keys, the log (through boincview) now says it's using c:\boinc as the data directory. Under that I restored the projects directory, and the setiathome folder under that with all the work units that were in progress.

Restarting boinc now gives me
Host Project Date Message
Seti1 SETI@home 1/22/2010 1:36:32 PM Message from server: (Project has no jobs available)
Seti1 SETI@home 1/22/2010 1:36:32 PM Message from server: (reached daily quota of 64 tasks)
Seti1 SETI@home 1/22/2010 1:36:32 PM Message from server: No work is available for Astropulse v5
Seti1 SETI@home 1/22/2010 1:36:32 PM Message from server: No work is available for SETI@home Enhanced
Seti1 SETI@home 1/22/2010 1:36:32 PM Message from server: No work sent

I saw it try and download new files, and it found that the banner images were already there so it skipped them. Any idea why it's not picking up the work that was in progress?

Cheers.

Update: I pulled the client_state.xml out of the trash and put it into c:\boinc (overwriting what was there). It found 2 of 6 tasks, the rest it's saying can't be found - though I've verified the files are there. Closer...

I've got two final issues right now.

- I can't get boinc.exe to send stdout to a text file. Since it will be running as a service, and the console window will be hidden, I'd like it to write to a log file so I can track/debug as necessary.

The standard output of boinc.exe normally goes to stdoutdae.txt

- The boinc service I create (sc create boinc start= auto binpath= "c:\boinc\boinc.exe --daemon") will start, and boinc.exe runs in the background, but only uses about 2mb memory, and never starts the seti exe. It's not kicking off the work, and I can't see why, because I can't get it to write to a log file. There was also a -- flag to set, --redirectio i think? (cut off in the wiki) but it doesn't seem to work. Should it be --redirection?

boinc.exe (and boinccmd.exe) have a --help commandline option :-)

I've tried running the service as localsystem, and verifying permissions to all the files, they all look good. I've also tried running it as my admin account, both do the same thing - boinc.exe, but no seti*.exe's.

Can't help you with that, since I used the installer to set up the service install (Protected Application Execution mode).

BoincView, now that it's working, seems to be an excellent concept. A little clunky in places, but the general idea is fantastic. I'm a little surprised the boinc devs didn't incorporate the functionality into boincmgr. The ability to run a subnet of systems from one manager/scheduler would be heaven to a system like this one.

You can. Try the Advanced/Select computer... menu of BOINC manager. You can even start several instances of the manager.

BoincView isn't maintained any longer, as far as I know. But there are (at least) two other tools out there, written by BOINC users, namely Boinc.NET (BDN) and BoincTasks.

On a more general note, did you already see the BOINC Wiki and the BOINC FAQ Service?

Gruß,
Gundolf

Update: I pulled the client_state.xml out of the trash and put it into c:\boinc (overwriting what was there). It found 2 of 6 tasks, the rest it's saying can't be found - though I've verified the files are there. Closer...

That's the trick. The tasks files are nothing without the client_state.xml. That's why you are always told to save the complete data directory, not just some files.

Gruß,
Gundolf

boinc.exe (and boinccmd.exe) have a --help commandline option :-)

Murphy visited. He said "you're going to try everything you did before, except this time because someone else suggested it, it will work." It's still not properly outputting to the text files, but boincview seems to be capturing most everything I need.

You can. Try the Advanced/Select computer... menu of BOINC manager. You can even start several instances of the manager.

BoincView isn't maintained any longer, as far as I know. But there are (at least) two other tools out there, written by BOINC users, namely Boinc.NET (BDN) and BoincTasks.

Yeah, i saw that. Managing these systems one at a time is a bit of a pain. BoincView is letting me view all systems, all projects, all tasks, and control each one or all of them simultaneously. Rather ingenious. It's taken on the scheduler/manager role across a whole network, rather than just the local pc. Those boinc guys would make a killing incorporating even half the functionality of group management... I looked at boinc.net as well, but found it to be clunky, slow, and visually unappealing (too much pizazz). That's just me though. BoincTasks doesn't seem to work under Server 2008. The app loads, but I can't add hosts. C'est la vie.

On a more general note, did you already see the BOINC Wiki and the BOINC FAQ Service?

I return to my earlier statement about Murphy. He said to send his best...


So i think I've managed to accomplish what I set out to do. It didn't look quite how I anticipated it, but here's a quick wrapup:

1) Install boinc on a throwaway system, or know that it will be uninstalled.
2) copy c:\program files\boinc to c:\shared\boinc
3) Copy accounts*.xml, and global_prefs_override.xml from c:\programdata\boinc to c:\shared\boinc . Write the gui_rpc_auth.cfg and remote_hosts.cfg files according to your wiki. Stick them in c:\shared\boinc . Make sure the firewall allows the boincmgr port to be open (or is off, in secure environments), on all the systems to be deployed to.
4) from the workstations to be deployed to:
xcopy /s \\sourcepc\shared\boinc\*.* c:\boinc\
I did this through a remote management tool that lets me execute commands on systems in batches. One button and 1 to a few thousand systems (in my dream network, right now it's 8.) run the command.
5) From the controlling system, send the command: "c:\boinc\boinc.exe" . I'm using a task scheduler, so I can have it run as long as i want, and globally or independantly kill it when I need to. Other results will vary. First time it runs it will run the benchmarks, then if your accounts*.xml files are properly configged, it will go fetch some work.
6) While boinc.exe is running, connect with boincview or other like app. That's now your global project manager.
7) End boinc either by killing boinc.exe, or send "c:\boinc\boinccmd --project (url) suspend" .

It's working swiftly and well for me right now. Boinc is putting all its data under c:\boinc\projects . No registry keys, no services (i gave up on that), no extraneous crap. It's little more than a glorified dos app right now, actually, which is perfect - very lightweight.

The deployment itself could be scripted with little trouble (that xcopy line should do it). You could really quite easily deploy this to a huge network through Active Directory GPOs, SCCM, Altiris, or some other workstation management system - just send the xcopy line to the systems you're deploying to. Configure the prefs xml file to only run when the system is idle before deploying, and presto - noninvasive workstation grid computing en masse.

On another note, I got a message from another forum member (i dunno if they want to stay anonymous) who advised me that running boinc without the user accounts and groups the installer creates, and all under one directory (c:\boinc, and c:\boinc\projects) has the likelihood of blowing up eventually. He may have been referring to my trying to run it as a manually created service, but I'm not positive. Any experiences along these lines? What i'm seeing right now looks pretty good, but obviously if there's something I don't know i'd like to correct for it.

Thanks again, & Cheers -

It's still not properly outputting to the text files, but boincview seems to be capturing most everything I need.

My boinc.exe is started with

C:\Programme\BOINC\boinc.exe -daemon

and I find the output in stdoutdae.txt and in the Messages tab of BOINC manager, but the manager only keeps about the last 2000 lines.

7) End boinc either by killing boinc.exe, or send "c:\boinc\boinccmd --project (url) suspend" .

I would never kill boinc.exe but use "boinccmd --quit" [edit]or Advanced/Shut down connected client... in BOINC manager.[/edit]

...
So i think I've managed to accomplish what I set out to do. It didn't look quite how I anticipated it, but...

Congratz for an accomplished challenge :-)

Gruß,
Gundolf