Licensing

How does Yeti use licenses?

Yeti uses two types of license: an interactive license (yeti_i in the license file) and a render license (yeti_r in the license file).

Yeti licenses are shared per host: however many users or instances of Yeti are running on one host (a workstation or server), they use at most one interactive and one render license between them.

Some features of Yeti need an interactive license, and others only need a render license:

• A render license covers evaluating graphs, whether for display in the viewport, caching, simulation or rendering, as well as scripted commands such as pgYetiCommand -writeCache.
• An interactive license is needed to edit: to brush grooms in the Grooming context, to use the Graph Editor, and to create nodes or change the Graph Editor's selection with pgYetiGraph.

When Maya runs in batch mode, the Graph Editor and grooming tools aren't available, so scripted pipeline tasks that run Maya in batch mode on servers only use render licenses.

Keep this in mind when you design a pipeline that uses Yeti. For example, animators who only display live Yeti graphs need only a render license, but anyone who opens the Graph Editor or grooms needs an interactive license.

Lighters who reference fur caches written when the animation was published only ever need a render license.

Yeti only contacts the license server once a Yeti node is used, so you can load the Yeti plug-in even if no license is available. When you start editing, Yeti checks whether an interactive license is available. If it is, Yeti checks it out and returns any render license it holds, as the interactive license also covers evaluation. If it isn't, Yeti keeps its render license and the edit fails.

Limiting Access to Interactive Licenses

Sometimes you may want to limit access to Yeti interactive licenses, for example to stop a group of users from using them by mistake if the wrong asset is published or opened.

When the YETI_INTERACTIVE_LICENSE environment variable is set to 0, every attempt to check out an interactive license fails. Setting it to 1 lets attempts to check out an interactive license succeed, exactly as if it weren't set at all.

This is best used as a stopgap to prevent mistakes, rather than as a permanent solution: ultimately, your workflow should make it unnecessary.

Is the Yeti license permanent?

Yes. All Yeti licenses are permanent entitlements for the version you bought: if you bought a 5.0 license, you can use it with any 5.x release or earlier.

When a new major version is released (6.0, for example), you'll need to buy an upgrade license to use it.

How can licenses be transferred to another machine?

Fill in our online License Transfer Form, and we'll send you an updated license as soon as possible. Be sure to include all of the relevant information to avoid delays.

There are a few more restrictions on transferring Indie licenses. Because they're node-locked, we're happy to transfer one if the original license was issued incorrectly, or if an old workstation has died and you need to replace it, but in general the rule is one license transfer per year.

If you need to transfer a license more than once in a year, we'll have to charge a fee equal to half the price of a new Indie license.

That said, we're very reasonable and happy to talk it through if and when the time comes.

Can I use my Indie license on both my workstation and my laptop?

An Indie license is node-locked to a single machine and can't move between machines, so if you bought a license for your workstation, you won't be able to use it on a laptop.

If you'd like a license that floats between machines, we recommend buying a Studio license and using the laptop as the license server. That way, you can also render on both machines.

Are licenses consumed per host or per job?

All of our licenses are per host, so you can run several jobs on the same host and they only use a single license. The license server may report several handles (one for each job), but they all point to a single license entitlement.

Can you provide a combined license file?

When you place an order (through our online store or with an invoice), our licensing system creates a new entitlement for each line item and assigns it to your account. It then automatically signs and issues a new license file with all of the new entitlements from the order. Because this process is automatic, we can't merge your current and new licenses for you.

If the new entitlement is for the same host as a previous license, there are two ways to use them together. The first, and simplest, is to copy the new .lic file into the same folder as your previous one and restart the license server (or make the license server read the license files again).

The second is to combine all of the licenses into a single file by hand. The combined file must have a single HOST line and a single ISV line, followed by each of the LICENSE and UPGRADE lines.

For example, these two licenses:

HOST localhost 90b12c9c5223 5053
ISV peregrinel
LICENSE peregrinel yeti_i 2.0 permanent 2 share=h min_timeout=30
        issued=5-jan-2018 _ck=... sig=...
LICENSE peregrinel yeti_r 2.0 permanent 10 share=h min_timeout=30
        issued=5-jan-2018 _ck=... sig=...

and

HOST localhost 90b12c9c5223 5053
ISV peregrinel
UPGRADE peregrinel yeti_i 2.0 3.0 permanent 2 share=h min_timeout=30
        issued=5-jan-2019 _ck=... sig=...
UPGRADE peregrinel yeti_r 2.0 3.0 permanent 10 share=h min_timeout=30
        issued=5-jan-2019 _ck=... sig=...

combine like this:

HOST localhost 90b12c9c5223 5053
ISV peregrinel
LICENSE peregrinel yeti_i 2.0 permanent 2 share=h min_timeout=30
        issued=5-jan-2018 _ck=... sig=...
LICENSE peregrinel yeti_r 2.0 permanent 10 share=h min_timeout=30
        issued=5-jan-2018 _ck=... sig=...
UPGRADE peregrinel yeti_i 2.0 3.0 permanent 2 share=h min_timeout=30
        issued=5-jan-2019 _ck=... sig=...
UPGRADE peregrinel yeti_r 2.0 3.0 permanent 10 share=h min_timeout=30
        issued=5-jan-2019 _ck=... sig=...

Serving Licenses for Several RLM ISVs

When you have software licensed from several ISVs (independent software vendors), there are two ways to set up rlm and the ISV servers on a single license server.

The first is to keep them entirely separate, with separate installation folders and separate ports for the clients and the web interface. This is simple in principle, but harder to manage and use: it needs more ports, and you have several web interfaces to check license usage.

The second is to run a single instance of rlm that manages two (or more) ISV servers. Both we and Reprise Software recommend this method, as it's much simpler to manage: you only have a single RLM port to manage, and one web interface.

To do this, use the latest version of the RLM license manager supplied by your vendors (it's backwards compatible), or better still, download the latest version from Reprise's website.

Copy the <ISV>[.exe] or <ISV>.set files from all of the vendors into the RLM folder.

Copy all of the .lic (license) files from all of the vendors into the same folder.

Once you've copied all of the files, start the RLM server as usual, and use the web interface to check that all of your licenses are there.

RLM as a Service

Windows

On Windows servers, you may want to install and run the rlm server as a Windows service. A service can start automatically when the computer starts, and keeps running as long as the system is up, whoever logs in or out.

You can install RLM as a service from the RLM web interface or from a command window. Once it's installed as a service, it stays installed until you delete the service. Installing RLM as a service doesn't start RLM: services are started from the Windows Services control panel, and when the computer starts.

To install it from the web interface, choose Manage Windows Service from the main menu on the left. A form appears with three fields:

• service name
• logfile name
• optional command-line arguments

All three fields are filled in with default values. Just click Install Service, and the rlm service is installed. By default, the log file is in the same folder as rlm.exe and is called rlm.log, and rlm looks for license files in that folder.

Remove Service removes the service named in the form.

note

You can't remove the service while the instance of rlm you're using is running as that service. To remove it, stop the service, then either use the Windows Services control panel, or run rlm in a command window and use the Remove Service option in the web interface.

You can also install RLM as a service from a command window, by running rlm with these arguments:

rlm -install_service -dlog [+]logfile [-service_name sname] <rlm runtime args>

where:

• logfile is the path of the server's debug log. This argument is required. If it starts with +, the log file is appended to instead of being created.
• sname is an optional name for the service. If you don't give one, it's called rlm. If the name contains spaces, enclose it in double quotes.
• <rlm runtime args> are any other command-line arguments to pass to rlm when it starts.

For example:

rlm -install_service -service_name rlm-xyz -dlog c:\logs\server.log -c c:\licenses\xyz.lic

This installs rlm as a service called rlm-xyz. When it's started from the Services control panel or when the computer starts, rlm is given the arguments -c c:\licenses\xyz.lic, and writes its debug log to c:\logs\server.log.

You can also delete RLM services with the rlm program. Stop the service in the Services control panel before you delete it. Deleting a service removes it from the Windows service database; it doesn't delete the rlm program or its license files:

rlm -delete_service [-service_name sname]

where sname is the optional name of the service. If you don't give one, it's rlm. If the name contains spaces, enclose it in double quotes.

Linux

On most Linux systems, services are started when the computer starts, usually with a systemd service unit or a startup script (for example, /etc/init.d/rlm linked to /etc/rc5.d/S98rlm). You need to be root to install the service.

Run the service as a dedicated system user, so the rlm servers don't run as root.

How can we reserve or exclude licenses for different users, groups or machines?

You can control which users, groups or machines can use the floating licenses on your server by editing the peregrinel.opt options file on the license server.

Use the RESERVE and EXCLUDE keywords to reserve or exclude licenses for users or groups of workstations. Here are some examples.

To reserve one Yeti render license for a user called colin, add this line to the file:

RESERVE 1 yeti_r user colin

To reserve 4 Yeti render licenses for a group of users:

GROUP lightingteam sara colin simon liam
RESERVE 4 yeti_r group lightingteam

To reserve 5 Yeti render licenses for particular render servers:

HOST_GROUP renderservers render01 render02 render03 render04 render05
RESERVE 5 yeti_r host_group renderservers

warning

Reserved licenses aren't available to anyone else.

The EXCLUDE keyword stops the given users or workstations from using a type of license.

To stop a group of users from taking a Yeti render license:

GROUP animationteam liam gill kirsten
EXCLUDE yeti_r group animationteam

Setting Timeouts for Checked-Out Licenses

Sometimes a client can hold on to a checked-out license after the application has stopped, for example when Maya crashes. Because the application exits early, the code that returns the license to the license server never runs.

To avoid these "zombie" licenses, use the TIMEOUT ISV option to make RLM release licenses held by instances that haven't sent the server a heartbeat for a given time.

To edit the peregrinel options file, open the RLM web interface and choose Status. Find the peregrinel ISV server and click peregrinel in the Options column. In the options file, add TIMEOUT <num seconds> peregrinel. The minimum value for <num seconds> is 3600 (one hour).

When you're happy with your changes, click Update Options to save them, then Reread the server to apply them.