Licensing
How does Yeti use licenses?
Yeti uses two different types of licenses, 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, multiple instances of Yeti on a single host (workstation or server) will only use a maximum of 1 interactive and 1 render license regardless of the number of users or instances on that host.
Some features of Yeti require an interactive license and others only a render license.
An easy way of differentiating is to ask yourself whether or not a graph is being evaluated to produce a result (for display or rendering) which would require a render license, or is a graph being edited, a user is grooming or graph inputs are being updated (animation and dynamics) which would require an interactive license.
The exception to this rule is if Maya is running in batch mode which will only ever use a render license, this means that scripted pipeline tasks that are distributed on servers using Maya in batch mode will only consume render licenses.
All of this should be kept in mind when designing a pipeline that uses Yeti, if published assets used by animators have live Yeti graphs then each animator will need an interactive license.
On the other had, if fur caches are written out when animation is published and lighters reference these cache files then they will only ever need a render license.
Yeti will only query the license server once a Yeti node is in use, so the Yeti plugin can be loaded even if a license isn't available. When a Yeti node is created, it will only attempt to check out an interactive license if a node is being edited, otherwise a render license will be used. If the user has a render license checked out and they start and editing process then Yeti will first check and see if an interactive license is available, if so this will be checked out and the render license returned - otherwise it will hold on to the render license and the attempt to edit will fail.
Limiting access to Interactive licenses
There may be some situations where you want to limit access to Yeti interactive licenses, maybe to avoid a specific group of users from mistakingly using them if a wrong asset is published or opened.
The YETI_INTERACTIVE_LICENSE environment variable is available and when set to 0 will cause all attempts to check out an interactive license to fail.
Setting YETI_INTERACTIVE_LICENSE to 1 will cause attempts to check out an interactive license to succeed and is exactly the same as not setting it at all.
Ideally this should be used more as a stop gap solution to errant licenses being used vs a permanent solution, ultimately your workflow should ensure this isn't needed.
Is the Yeti license permanent?
Yes - all of our Yeti licenses are permanent entitlements for the version purchased, if you bought a 5.0 license it can be used for any 5.x release or earlier.
If a new version of the product is released (6.0 etc.) then an upgrade license will need to be purchased to be able to use it.
How can licenses be transferred to another machine?
Please complete our online License Transfer Form and an updated license will be provided as soon as possible, be sure to include all of the relevant information to avoid delays.
There are a few more restrictions on the Indie license when it comes to transferring. As it's node locked we are happy to transfer the license in the instance where the initial license was incorrectly issued, or if an old workstation has died and you need to upgrade but in general the rule is one license transfer per year.
If, for some reason, it ends up you need to transfer a license more than once we will have to charge a fee equal to half a new Indie license.
With that said, we're extremely reasonable and happy to discuss if/when the time comes.
Can I use my Indie license on both my workstation and laptop?
The Indie license is node locked to a single machine and isn't able to migrate between machines, so if you've purchased a license for your workstation you won't be able to use it on a laptop.
If you would like the license to float between machines we'd recommend purchasing a Studio license and use the laptop as the license server - this way you can also render on both machines.
How are licenses consumed, per host or per job?
All of our licenses are per host, so you can have multiple jobs running on the same host and it will only consume a single license. When querying the license server it may report multiple handles (for each job) but these all point to a single license entitlement.
Can you please provide a combined license file?
When an order is placed (whether through our online store or via an invoice) a new license entitlement for each of the line items is created and assigned to individual accounts within our internal licensing database, these are then processed and a new license file with all of the new entitlements from the order will be automatically signed and issued by our system. As this is an automatic process we are unable to provide your current and new licenses merged.
If it the entitlement is for the same host as a previous license then you can there are two potential options for using them. The first and most simple is to copy the new .lic file into the same directory as your previous one and restart the license server (or force the license server to re-read the license file).
The second would be to manually combine all of the licenses into a single file. To do so you would have to ensure this combined file has a single HOST and ISV line followed by the individual LICENSE/UPGRADE lines.
For example, two licenses might be
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=...
merged together would look like
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 Multiple RLM ISV's
When you have licensed software from multiple ISVs, you have two choices for how to configure rlm and the ISV servers when running them on a single license server system.
The first choice is to keep them entirely separate, using separate installation directories and port numbers for the client and web interface. Although conceptually simple management and use becomes more complex, the number of used ports are increased and there will be multiple web interfaces to check license usage.
The second choice is to run a single instance rlm, which manages two (or more) ISV servers. This is the method recommended by ourselves and Reprise Software and is much simpler to manage, you only have a single RLM port to be managed and a unified web interface.
To do this you need to make sure you choose the latest version of the RLM license manager supplied by the vendors ( they are backwards compatible ) or better yet, download the latest version from Reprises website.
Copy over the <ISV>[.exe] or <ISV>.set files from all of the vendors.
Copy over all of the .lic ( license ) files supplied by all of the vendors.
Once all of the required files have been copied the RLM server can be started as usual, use the web interface to confirm that all relevant licenses have been accounted for.
RLM as a Service
Windows
On Microsoft Windows servers, you may want to install and run the rlm server as a Windows service process. A service process can start automatically at boot time and remain running as long as the system is up, regardless of user logins and logouts.
You can install RLM as a service either in the RLM web interface or in a command window. Once installed as a service, it remains installed until it is explicitly deleted as a service. Installing RLM as a service does not start RLM; services are started via the Windows Services control panel, and at boot time.
To install using the web interface, select Manage Windows Service from the main menu on the left. You will get a form with 3 data fields:
service name
logfile name
optional command-line arguments
All 3 fields will be filled in with default values. You can just select “Install Service”, and the “rlm” service will be installed for you. By default, the logfile is put in the directory with the rlm.exe binary, and it is named rlm.log. Also, by default, rlm will search for all license files in this directory.
If you select Remove Service, the service name specified in the form will be removed.
If the instance of rlm which you are running is actually running as a service, you will not be able to Remove the Service (since it is running). To remove the service, you will have to stop the service, and then either use the service control panel in Windows, or run rlm in a command window and use the Remove Service option in the web interface.
Optionally, you can install RLM as a service in a command window. To do this, use the rlm program itself (in a command window), with special arguments:
rlm -install_service -dlog [+]logfile [-service_name sname] <rlm runtime args>
where: logfile is the pathname for the server debug log. This parameter is required. If preceded by the ‘+' character, the logfile will be appended, rather than created.
sname is an optional name for the installed service. If not specified, sname defaults to “rlm”. If sname contains embedded whitespace, it must be enclosed in double quotes.
<rlm runtime args> are any other command line arguments to be passed to rlm when it is started. Example:
rlm -install_service -service_name rlm-xyz -dlog c:\logs\server.log -c c:\licenses\xyz.lic
This installs rlm as a service under the name “rlm-xyz”. When started via the Services control panel or at boot time, rlm will be passed the “-c c:licensesxyz.lic” args, and it will write it's debuglog information to the file c:logsserver.log
Installed RLM services are also deleted with the rlm program. Services must be stopped via the service control panel before they can be deleted. Note that deleting a service deletes it from the Windows service database; it does not delete the rlm executable or associated license file(s):
rlm -delete_service [-service_name sname]
where: sname is an optional name for the installed service. If not specified, service_name defaults to “rlm”. If service_name contains embedded whitespace, it must be enclosed in double quotes.
Linux
On most Unix systems, system services are started at boot time, usually via startup scripts located in /etc/rc.<something>. For example, the script could be located in /etc/init.d/rlm, with a link to /etc/rc5.d/S98rlm. Note that you must install this startup script as root.
The startup script should run as specific system level user so that the rlm servers are not running as root.
How can we reserve or exclude licenses for different users, groups or machines?
You can manage which users, groups or machines are able to use the floating licenses from your server by editing your “peregrinel.opt” options file on the license server.
The RESERVE and EXCLUDE keywords can be used to reserve or exclude licenses for given user(s) and/or groups of work stations. Here are some example commands:
To reserve one Yeti Render license for a user called “colin” you would add the following line to the file
RESERVE 1 yeti_r user colin
To reserve 4 Yeti Render licenses for a group of users you would use
GROUP lightingteam sara colin simon liam
RESERVE 4 yeti_r group lightingteam
To reserve 5 Yeti Render licenses for specific rendering servers
HOST_GROUP renderservers render01 render02 render03 render04 render05
RESERVE 5 yeti_r host_group renderboxes
Any reserved licences are not available for other users.
The EXCLUDE keyword will prevent the specified user(s) or workstations from using a type of license.
To prevent a group of users from taking a Yeti Render license you would use
GROUP animationteam liam gill kirsten
EXCLUDE yeti_r group animationteam
Setting Timeouts for Checked Out Licenses
In some situations it's likely that a client may hold onto a checked out license longer than the lifetime of the application - when Maya crashes for instance. The reason being is that because of the early exit from the application the code used to return the license to the license server was unable to run.
To avoid zombie licenses the TIMEOUT ISV option may be used to tell RLM to release licenses owned by instances that haven't sent a heartbeat back to the server for the specified amount of time.
You can edit the peregrinel options file by navigating to the RLM web interface and selecting the Status option. Find the peregrinel ISV server and select peregrinel in the Options column. Once editing the options file add TIMEOUT <num seconds> peregrinel - the minimum value for <num seconds> is 3600 ( one hour ).
Once you're happy with the changes use the Update Options button to save your changes and Reread the server ( to force the options to take effect ).