Versions Compared

    Old Version 4

    changes.mady.by.user Unknown User (czerouni)

    Saved on

    compared with

    New Version 5

    changes.mady.by.user Unknown User (czerouni)

    Saved on

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Migrated to Confluence 5.3

    Table of Contents

     

    Firewalls

    It is necessary to have certain ports open for the Qube Supervisor, Worker, and Client machines to communicate. One should either disable the firewall completely on the local machine, or open specific ports for Qube to communicate via TCP/IP and UDP.

    • 50001 TCP/IP and UDP
    • 50002 TCP/IP and UDP
    • 50011 TCP/IP and UDP
    • 50012 TCP/IP and UDP

    Setting Command line variables

    Having the Qube commands available in the path from the commandline can be useful. Here is what is needed to set this up:

    • Linux (~/.cshrc/ or ~/,tcshrc):
            1. setenv QBDIR /usr/local/pfx/qube
            2. set path = ($path $QBDIR/bin $QBDIR/sbin)
    • Linux (~/.bashrc):
            1. export QBDIR=/usr/local/pfx/qube
            2. export PATH=$PATH:$QBDIR/bin:$QBDIR/sbin
    • OS X (~/.bashrc):
            1. export QBDIR=/Applications/pfx/qube
            2. export PATH=$PATH:$QBDIR/bin:$QBDIR/sbin

    • Windows:   The .msi automatically adds the C:\Program Files\qube\bin to the PATH.


    User Authentication for Workers

    In order for jobs to run correctly on the farm, some form of authentication is necessary, typically using a network server such as a Active Directory for Windows servers or NIS/LDAP for Linux & OS X. It is recommended that your farm operate within some system so that all render farm machines can authenticate properly. If local user accounts are used, it is recommended to use the "proxy mode" for Qube Worker authentication.

    If you have established a network-based authentication mechanism, it should be used for both desktop clients and render farm hosts. Therefore, all hosts in your farm should bind to the same authentication scheme so that authentication occurs consistently.

    Specifying user-defined proxy user (Central Configuration)

    If you prefer to use another proxy user instead of qubeproxy, you will need to configure the Worker to use a different proxy account and password.

    1. Login to an administrator account on the Supervisor and launch the QubeGUI, and click on the Workers Tab.
    2. Select the Workers to change, right-click, and specify the Configure menu item. This will bring up a Configuration dialog.
    3. Scroll down to the "Worker (User)" section, and set the proxy_account and proxy_password parameters.
    4. Optional (for Windows workers only): set the worker_host_domain parameter.
    Note
    titleQube Admin permission required

    In order to configure workers on the supervisor, you must be logged in as a local/domain machine admin to modify the config file, but you must also be logged in as a Qube administrator, which has no relation to the local or domain admin account(s). See User Permissions for more info.

     

    Specifying User Mode (Central Configuration)

    If your preference is to have the submitting user execute jobs, you will need to reconfigure the Workers to run in User mode.

    1. Login to an administrator account on the Supervisor and launch the QubeGUI, and click on the Host Layout Tab.
    2. Select the Workers to change, right-click, and specify the Configure menu item. This will bring up a Configuration dialog.
    3. Scroll down to the "Worker (User)" section, and set the proxy_execution_mode parameter to "user".
    Note
    titleWindows Users

    On Windows, it will also require that each submitting user register their password with Qube via the QubeGUI:Administration->Register Windows Password, or the qblogin commandline tool. If this is not done, a badlogin error will result for the job when run on that Worker.

     

    User Proxy mode Considerations

    By default, each Qube Worker is configured to run in what we call "proxy" mode. This means the Worker will attempt to execute the job as a proxy user, rather than the user that submitted the job ("user" mode).
    When Qube is installed, a local user called "qubeproxy" is installed, and the Worker is pre-configured to run in proxy mode, and to designate qubeproxy as the proxy user.
    In order for each job running as qubeproxy to execute correctly, it must have read and write access to any file servers that potentially contain job input and output files. In many cases, this will require modifying your server configuration to add qubeproxy to the list of users authorized to access the file server.
    After adding the appropriate permissions to your servers, we recommend to login to a Worker host as qubeproxy and attempt to read and write a file, create a folder, etc.
    The default local qubeproxy account is:
    Username: qubeproxy
    Password: Pip3lin3P@$$wd