Running inside Docker Container

My software is run from inside docker containers, including the LimeLM licensing agent (as a custom program, using the C API).

Everything works as expected: specifying license file directory, activating license on first time execution, etc. But when I run the container the second time, if I call either TA_isActivated() or TA_isGenuineEx(), I get error code TA_FAIL and TA_E_ACTIVATE respectively.

I have also confirmed that when I run the licensing agent outside the docker container, saving the license files to the local harddrive, each subsequent execution returns TA_OK for the above calls.

Information:1. I am running the latest version of TurboActivate, linking with the linux static library - downloaded again today to be certain.2. My licenses allow activations inside a VM

So I am confused why running the license agent from inside a docker container results in TA thinking the license is not activated.

Is this there something special I can do to get around this? Since, obviously, my clients cannot be asked to re-enter the license on each subsequent start-up of the program.

Please let me know if there is any additional information I can / should provide to help diagnose what could be going on here.

regards,

richard

A docker container is just a VM. (A VM without the security benefits of a VM).

Use TurboFloat in VMs. Here's why: https://wyday.com/limelm/help/vm-hypervisor-licensing/

turbofloat is not an option, which i've gone into several times in emails in the past. i am fully aware of all the issues where VM's and containers are concerned.

allowing to run in a VM is an option that is provided, so it should work. i am trying to figure out why it is not working to make it work the way i need to make it work.

what can i do to figure out why this is not working when it should?

richard

In the upcoming version of the LimeLM interface we're going to make it explicitly clear the downside to checking the "Allow activations in VMs" radio box.

Short answer: don't do it.

Longer answer: if you do it, understand the risks: https://wyday.com/limelm/help/vm-hypervisor-licensing/

Note the part of that article that actually applies to you -- besides all of it:

"Another reason why you should disallow VM activations is that on certain "cloud VM providers" like Azure and Amazon Web Services, whenever you reboot the machine the VM instance is started on a different underlying physical machine, and thus the "computer fingerprint" changes. This means that a customer that is activated on one of these machines, reboots the machine, they suddenly become deactivated."

The solution is to disallow activations inside VMs and to use TurboFloat. TurboFloat can be used inside VMs. It solves your problem.

If you're reluctant to use TurboFloat because it requires installing a TurboFloat Server on a real machine, then we'll have a solution to that very shortly -- namely, we'll hosted TurboFloat Server instances on our infrastructure.

wyatt,

i guess i didn't make it clear enough: i already have a deep understanding of the risks, the issues, the everything, please stop trying to convince me i'm doing something wrong. i am fully capable of making my own decisions, not only in this regard but in all ways.

the question is: are you going to help me with my problem? your licensing scheme allows for activations in a VM, so to continue to insist i'm doing it the wrong way baffles me to no end.

i need this to work, i have described my problem in full, i have indicated that i have the latest software running, and now i am asking WHAT CAN I DO to help deepen the understanding of what is going wrong so that i / we can find a solution. because something in the LimeLM library is going wrong that is preventing the software from working properly, in an environment that is advertised to work.

for the record, i write software for thousands of users all over the world and am also in a position of providing support on an almost daily basis, i.e., i have the same job as you, as i'm sure most of your end-users do.

please help me with my problem so that i don't have to go elsewhere to solve the problem of licensing my software.

thanks in advance,richard

>> " i am fully capable of making my own decisions, not only in this regard but in all ways."

You are. The decision you've made (to always use TurboActivate even in cases where TurboFloat is the correct solution) has downsides. Namely, VMs "fingerprint" changes on reboot. This is not mysterious behavior. We've had documentation on this for about a decade. And we've had a solution to this for just as long (use TurboFloat).

>> "in the LimeLM library is going wrong that is preventing the software from working properly, in an environment that is advertised to work."

Well, you're using the wrong LimeLM library. TurboActivate is for node-locked licensing, TurboFloat is for floating licensing. They provide similar functionality. But they're different tools to solve different problems.

It's like a nail and a screw. You can can hammer both in, but the screw will likely shatter (or at the very least bend) when you try to hammer it. And good luck screwing in a nail.

But they look similar. And they provide roughly equivalent solutions to a problem. But there are some cases where the nail is the appropriate solution and some cases where the screw is the appropriate solution. And some cases where you can use either successfully.

TurboActivate and TurboFloat are a nail and a screw. Similar solutions to a problem, but each has its benefits and downsides.

TurboActivate is node-locked licensing for *any* real machine, and only *some* VMs (really, we recommend *never* using TurboActivate on VMs, but it's possible on some VMs). Docker images and Amazon / Google / Azure VM instances are not among the supported VMs that TurboActivate can be used on. Yes, they'll work briefly. For the life of a user session. But once you restart, TurboActivate will "see" a different machine (because the machine itself is configured to be different).

TurboFloat is floating licensing. You can use this on *any* real machine and *any* virtual machine / hypervisor / docker image / cloud VM, etc., etc., etc.

So, yes, you have a few options:

1. Use a broken licensing solution that doesn't actually lock to the machine (there are plenty of these out there -- and they're usually dirt-cheap too). This will "solve" your problem. But at that point you're just using serial-only licensing: https://wyday.com/limelm/features/why/#serial-only

2. Use the correct solution (in this case, for VMs that has a "changing fingerprint upon reboots", use TurboFloat). Covered extensively in this forum and our help documentation:

https://wyday.com/limelm/help/vm-hypervisor-licensing/

https://wyday.com/limelm/help/licensing-types/#floating

3. If you're determined to nail-in a screw, then at least make your life easier. In this case, if you're determined to use TurboActivate on a VM ignoring all of our advice not to, then before the customer shuts down your app call the TA_Deactivate() function before your app shuts down and the TA_Activate() function when your app starts up. But at that point you're using TurboActivate as a janky-floating licensing solution (so, why not use TurboFloat?)

4. Tell the customer to fix their docker configuration so that none of the "hardware details" change on reboot. Search google for guides and documentation on the specifics.

hi wyatt,

thanks for the info, i have everything i need now to proceed.

regarding your suggestion #3: there is a huge hole in that particular construct that makes it totally unusable. but there is a nice way around it.

still confused why you just didn't provide this answer as the first one. personally, i don't like marketing campaigns within a tech support environment. when i indicated there were reasons turbofloat doesn't work for me, do i really have to somehow convince you of this before you're willing to provide technical help? i do give you money, every month, after all.

thanks again, i'm sorted,

richard

Reply
Discard post