Qube! user instead of Local System account

[svad]

Has anyone tried to run the Qube! worker service (and watchdog) as a domain user (say Domain\Qube) rather than as Local System account.  I've used other render farm management products (Muster) that allow this and I was wondering if Qube! had any issues with such a setup.  I have a user created that has permission to login as a local service and access to the relevant network shares and directories.  Is there anything else I should know?

[anthony]

Hey Whcordis,

    Sorry for the late reply.  The worker service prefers being run under the local service account on the host.  This is because of permissions required to login a user.  Is there a particular reason for running the process under the DOMAIN/USER?  For the purposes of running all jobs under that user, setting the following options in the C:\WINNT\qb.conf or the C:\WINDOWS\qb.conf file will give you the same effect:

proxy_password = <encoded password>
proxy_account = "USER"
worker_host_domain = "DOMAIN"

The worker will use this account to execute all processes. 

    Thanks,
            Anthony

[svad]

Anthony,

Sorry for the lag in the conversation on my end as well.  Chalk it up to the holidays. 

The reason for wanting to run the process under DOMAIN/USER rather than LOCAL SYSTEM has to do with network aggregation of logs.  As I understand it the only way you can aggregate logs on the network when the process is running under LOCAL SYSTEM is to create a share that has read/write permissions granted to EVERYONE.  That's unnaceptable in my environment for a number of reasons so I was hoping to run the process under DOMAIN/USER to avoid that.  Then I could create a share and give DOMAIN/USER permission to the share and everything works.  I've created DOMAIN/QUBE and used GPO settings to give it the necessary permissions on the stations and server it runs on (Replace a process level token, Adjust memory quotas for a process, Act as part of the operating system).  It seems to work fine for the workers and users, but the supervisor seems to have issues writing its log files.

William

[anthony]

Hey Whocordis,

    Actually that's exactly how you would run things under a different account.  As a easy suggestion, you should also consider running the supervisor under the same proxy account.  (Use the standard, set user, password for the service)  This would allow the supervisor to login to write to the same log directories as well.  As far as the supervisor's required permissions, it actually doesn't have anything beyond file access.

   Thanks,
          Anthony

[svad]

Anthony,

I'm confused.  Is what I'm doing right or are you saying that a LOCAL SERVICE/proxy account is what I should be using?  I resisted using the proxy account because I wanted the renders to run as the individual user. 

Will

[anthony]

Hey Will,

    Actually as far as the "proxy" account, I meant using the same domain account you use to run the worker to run the supervisor.  Since the supervisor itself doesn't require any kind of "special" account to run in, it doesn't matter what account you use.

     Thanks,
            Anthony