I'm trying to create a mass deployment version of boinc to Server 2008 - using the MSI is not an option because of my department policy.

As such I've created a stripped down bastardized version I've been launching with a task scheduler.

I installed Boinc to my workstation, then copied the boinc program files directory to c:\boinc , then moved the projects and slots folder to c:\boinc . Copied the projects list and account_*.xml files, along with the gui_rpc_auth.cfg and remote_hosts.cfg .

This gives me a single folder that I can rapidly deploy to my systems. They launch when handled through my task scheduler, but other people are able to interrupt the job and are booting it off. I need to create it as a service that starts automatically, and suspends when other apps start using the CPU. I think I have the suspend portion down in the global prefs override, but creating the service is not working as I expected.

I'm right now running the following:

C:\>sc create BoincSetiTest binpath= "c:\boinc\boinc.exe -redirectio" type= share
[SC] CreateService SUCCESS

C:\>sc create BoincSetiTest2 binpath= "c:\boinc\boinc.exe" type= share
[SC] CreateService SUCCESS

(i'm creating two to test each option, redirection and not). Neither are working. When I go to start the service it just stalls and says it didn't start in a timely fashion. I've tried allowing it to interact with the desktop, i've tried having it launch under my credentials, I've tried having it launch as a local admin, but it does not take. Each time it tries to start it just sits and then borks.

What am I missing?

Cheers -

Edit w/ q: Could I be running into this issue (despite the servers not being DCs) because the user accounts don't get created? http://boinc.berkeley.edu/dev/forum_thread.php?id=5731

Edit w/ update: I found the -daemon flag and created two more services - one with "c:\boinc\boinc.exe -daemon" and one with "c:\boinc\boinc.exe -daemon -redirectio" . The service starts now (either one, one at a time of course), but is not launching processing, nor is it controllable with boincview, and I'm getting this error:

System error 1083 has occurred.

The executable program that this service is configured to run in does not implement the service.

Task failed during execution with exit code 2. Please check task's output for error detail

It's also not outputting to stderrdae.txt or stdoutdae.txt . Any thoughts? Thanks -

What happens if you start boinc.exe manually from a command window?

Gruß,
Gundolf

What you're missing? A lot.
Not just the limited user accounts that the BOINC service requires, but more.
So please see http://boinc.berkeley.edu/trac/wiki/ClientSetupWinSix and http://boinc.berkeley.edu/trac/wiki/ClientSetupLogicWinSix for lots of information.

Also, if that Server 2008 system is a domain controller, you cannot use BOINC 6 on it. It won't allow the making of local accounts, only global ones. BOINC uses local accounts only.

---

What happens if you start boinc.exe manually from a command window?

Works fine. Does everything it's supposed to. Boincview sees it, it will start processing, it's fine and dandy.

Also, if that Server 2008 system is a domain controller, you cannot use BOINC 6 on it.

They're not. I'm trying to run boinc without running under a manually created local account, it's trying to launch from Local System, the default for service accts. If the data is manually copied over, and the program is most certainly executable, and the local system account can read/write to that directory, what would cause the service to fail to run?

What I've seen before, though I don't remember how I got it to do this, is the cmd window launches and it just sits there. It never gets beyond the first few lines of the startup sequence - it never gets to reading the pref files, it never runs a system check, and it never starts the processing application. I think that's what's happening here, but I can't tell for certain because it's not showing the window.

Why would boinc, if executed in a local service, require dedicated user accounts? This is very odd to me, as I run dozens of different apps along these lines, that are predominantly self contained, that don't require special or specific local user accounts. A special app like Sharepoint, SCOM, SCCM, sure - service accounts are used all over the place. But those typically require heavy network access and read/write to AD. Boinc does neither. If I'm able to launch it manually in a cmd window (cd c:\boinc, boinc.exe - presto.) why would I need a service/user account for it?

Thanks -

How about you read the links I gave you? They'll answer your questions.
E.g. Limited user accounts, sand-boxing, limiting damage done by possible malicious applications, limiting damage due to bugs or network security vulnerabilities, keyboard/mouse detection works with multiple users.

---

Your other problem is, you copied the directories with all the files from a system you installed BOINC on. I doubt you thought about the permissions on the files and folders.

Also, BOINC runs a lot of things from the registry. Things like whether or not it is a service installation, where the program and data directory reside, how BOINC Manager shows things.

And then there are the user rights assignments. These are difficult to replicate without the installer. You could try to reverse engineer http://boinc.berkeley.edu/trac/wiki/ClientSetupLogicWinSixCleanup, but you best look in the registry of a system that has BOINC installed as a service what keys are set there. Without those you'll run into problems forever.

---

How about you read the links I gave you? They'll answer your questions.
E.g. Limited user accounts, sand-boxing, limiting damage done by possible malicious applications, limiting damage due to bugs or network security vulnerabilities, keyboard/mouse detection works with multiple users.

I did, thank you very much, and they didn't. http://boinc.berkeley.edu/trac/wiki/ClientSetupWinSix addresses the options to be checked while running the installer, which I'm not using.

http://boinc.berkeley.edu/trac/wiki/ClientSetupLogicWinSix describes all kinds of stuff that I'm not utilizing, mostly having to do with the installer. Please show me what you're referring to that I'm not seeing.

Per my original post, this deployment is created based on copying the program directory so that it can be deployed in bulk via xcopy.

Those links tell me all about the setup app, the different modes it installs in, etc etc. Unless there is something I'm missing about how the program itself actually executes, they don't cover the issue I'm encountering.

And as far as permissions go, the local system account has full rights over the c:\boinc directory, and my account that I can run it under successfully is a local admin. (The system is part of a domain, but is not a domain controller, and I'm logged in as a domain admin, and the domain admins group is added to the local admins group. Ergo, I log in as a local admin.)

Again - this works. This method works just fine. When I execute it locally, opening a cmd window and running c:\boinc\boinc.exe , it runs fine. When I execute it remotely through a job manager, executing c:\boinc\boinc.exe -redirectio works just fine. I've got several identical servers (server 2008 r2) that crunch away using this method predominantly 24/7. But when someone else needs a job run they boot boinc offline and it doesn't come back automatically. I'm trying to work around this by creating a service that runs whenever the system is started.

Why does it not work when started as a local service, but runs fine as a cmd line? This is the question that confounds me at the moment.

[/quote]

On my service installation, created by the installer under Windows XP on a non-domain home computer, the service executable line is

"C:\Program Files\BOINC\boinc.exe" -daemon

It also has a dependency on the Remote Procedure Call (RPC) service, it's running under account .\boinc_master, and I know it has to find necessary data files from registry settings. Your best bet would be to run the installer on your workstation so you can examine all of those, and then run setup with the traditional /a administrator's switch (it's implemented) to get a clean folder layout on a network share for your xcopy.

But before you do, I'm worried that you appear to want to hide the fact that you're running BOINC from your work colleagues, and your work colleagues don't appear to want to run it. Doesn't sound like a happy ship to me. Are you sure you've cleared the "owner's permission" hurdle before starting out?

Your other problem is, you copied the directories with all the files from a system you installed BOINC on. I doubt you thought about the permissions on the files and folders.

This has been taken care of. Local system has been granted full control over the boinc dir and all subfolders.

Also, BOINC runs a lot of things from the registry. Things like whether or not it is a service installation, where the program and data directory reside, how BOINC Manager shows things.

This is obviously true, but I've also worked around it. I can xcopy my boinc dir to 5, 10, 20 machines and execute just fine without a single registry key being written.

And then there are the user rights assignments. These are difficult to replicate without the installer. You could try to reverse engineer http://boinc.berkeley.edu/trac/wiki/ClientSetupLogicWinSixCleanup, but you best look in the registry of a system that has BOINC installed as a service what keys are set there. Without those you'll run into problems forever.

User Rights Assignments - But where do these come in to play? A boinc user has not been set up since the installer has not been run, and it obviously doesn't /need/ a user, since my local admin account can execute it locally just fine, and those registry keys are not required as it runs just fine without them.

So yes, thanks, but there's something else at play here that doesn't make sense.

On my service installation, created by the installer under Windows XP on a non-domain home computer, the service executable line is

"C:\Program Files\BOINC\boinc.exe" -daemon

It also has a dependency on the Remote Procedure Call (RPC) service, it's running under account .\boinc_master, and I know it has to find necessary data files from registry settings. Your best bet would be to run the installer on your workstation so you can examine all of those, and then run setup with the traditional /a administrator's switch (it's implemented) to get a clean folder layout on a network share for your xcopy.

But before you do, I'm worried that you appear to want to hide the fact that you're running BOINC from your work colleagues, and your work colleagues don't appear to want to run it. Doesn't sound like a happy ship to me. Are you sure you've cleared the "owner's permission" hurdle before starting out?

That dependency is good to know. I've discovered that boinc will search its own subdirectories for the project dir and account info. If it's not specified in the registry, it seems to look within itself. I'll give that /a a shot.

As for your concerns, they're appreciated, but it's all good. These servers are a lab that I run as a test environment. Code is written then tested out on these servers. They spend a lot of time sitting idle, but when they're needed they're needed. They know what I'm doing with this (as do managers and co workers), and since it's used only within our small group it's not impacting any prod systems. So, it's in the clear. It's also possible that this could be expanded to other systems, so I want to make sure that a) i get the rapid deployment/load/unload thing taken care of to make it quick and easy, and b) that it has a very light and tiny footprint (no installers, no registry keys, etc.) to keep it quick and easy.

It's all gravy, just a situational goal to make life much much easier.

Cheers. [/quote]