Downloads  |  Buy

TurboFloat Server on VMs (don't do it) [Solved]

TurboFloat Server on VMs (don't do it) [Solved]

Postby richardd » October 15th, 2019, 8:01 am

I'm seeing a definite trend in new users needing to install TurboFloat on virtual servers (would be the same for my office too - we got a new main file server this year and it's virtualised). So far I've been happy to enable this on request, but wondered exactly what the security implications are? Could customers easily run cloned license servers and connect clients to both at the same time?

Is there anything that can be done, or is it an inevitable consequence of the way the fingerprinting works?

[as an aside, I tried searching for similar topics, but the filtering and sorting options didn't seem to work so I got lost in too many other results!]
richardd
 
Posts: 3
Joined: May 24th, 2018, 2:58 am

Re: TurboFloat on VMs

Postby Wyatt » October 15th, 2019, 1:12 pm

>> " So far I've been happy to enable this on request, but wondered exactly what the security implications are?"

Never ever enable VM activations for TFS keys. The TurboFloat library can run on VMs or real machines. The TFS should *always* run on real machines.

Security implications are here: https://wyday.com/limelm/help/vm-hypervisor-licensing/

Short answer: if you enable VM activations the customer gets infinite licenses. Don't do it.

We're going to make the warnings more explicit very shortly.


>> "Could customers easily run cloned license servers and connect clients to both at the same time?"

Yes. Described at length in the article.



For end-users that need to use VMs (and complain loudly about installing the TFS on real hardware) we're releasing TFS instances hosted on our infrastructure soon.



>> "[as an aside, I tried searching for similar topics, but the filtering and sorting options didn't seem to work so I got lost in too many other results!]"

Yeah, the forum software we currently use is a dumpster fire. We're replacing it soonish.
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TurboFloat on VMs

Postby richardd » October 15th, 2019, 3:02 pm

Sounds like there's a solution coming, which is great. Our software is low-volume, (relatively) high value, so refunding the customers who only found out after purchasing that they couldn't use it would really hurt our bottom line. I've run into quite a few now who simply don't have any physical servers, so it's not just them "complaining loudly" to be awkward...

As an aside, does TFS have an equivalent of the re-checking and grace periods that are in TurboActivate? i.e. can I "turn off" those TFS already running in VMs after the hosted TFS goes live?
richardd
 
Posts: 3
Joined: May 24th, 2018, 2:58 am

Re: TurboFloat on VMs

Postby Wyatt » October 15th, 2019, 3:41 pm

>> "As an aside, does TFS have an equivalent of the re-checking and grace periods that are in TurboActivate? i.e. can I "turn off" those TFS already running in VMs after the hosted TFS goes live?"


Yes: https://wyday.com/limelm/help/turbofloat-server/#config-isgenuine


Revoke the key and/or disallow VM activations on the key. Or both.
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TurboFloat Server on VMs (don't do it) [Solved]

Postby dr_calculus » November 12th, 2019, 6:01 am

Apologies for jumping on this thread but we have the same problem as the original poster with clients increasingly moving to systems where they have no physical machines capable of running TFS.

I have a couple of additional questions:

1. On your upcoming system where you host the TFS remotely, will it be possible to recover a licence quickly in the event of a crash without generating frequent outbound lease requests? With TFS we currently set a lease time of 60 seconds for this reason and this results in lease requests roughly every 30 seconds. From past experience I know that many clients would not be happy with traffic at that frequency through their external firewall, no matter how small the packets.

2. Regarding the resons for not running TFS on a VM, I understand that doing so could allow a client to make a copy and pass it on to someone else, but if we start from the basis that our clients are unlikely to do that, the problem is just preventing duplicates on the same network and any image that they add to the network is going to have at least a different local IP address which could be analysed as part of the finger print process. Now I imagine that you wouldn't want to use a change of IP on it's own as a trigger that something was amiss, but if you had a repeated pattern of contact from TFS from alternate IP addresses, would it not be possible to detect that pattern and eventually refuse authorisation to the latter copy? There must also be other information on each VM that will differ and could possibly be used for finger printing.

Unfortunately, VMs are the future and we all have to spend a lot of effort making sure our software runs effortlessly on them, and that extends to the licensing system we use.

Thanks.
dr_calculus
 

Re: TurboFloat Server on VMs (don't do it) [Solved]

Postby Wyatt » November 12th, 2019, 4:00 pm

#1. "Zombie lease" prevention is covered here:

https://wyday.com/limelm/help/licensing-types/#turbofloat-is-the-best


#2. Fingerprinting "IP addresses": short answer, no IP addresses aren't a valuable indicator of anything useful. They're at best moderately interesting. They're worthless as an indicator for the computer a piece of software is running on.

More information (including addressing why IP addresses are *not* used as part of the fingerprint in any halfway-decent licensing) here: https://wyday.com/limelm/features/why/#wrong-id

So, TFS instances should always be installed on real machines. Or on our infrastructure. Or on your infrastructure. Never on a VM owned by a customer.
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire


Return to LimeLM, TurboActivate, & TurboFloat Support