LimeLM
wyBuild
Support forum
wyDay blog
wyDay Home

TurboFloat Server

TurboFloat ServerTurboFloat Server is part of our floating license technology that doles out floating license "leases" to your app from a pool size that you specify. A customer can run the TurboFloat Server on their infrastructure (as described in this article) or they can spin up an instance on our infrastructure: How to create a TurboFloat Server instance.

Should the end-user run the TurboFloat Server on their computers?

For most customers, we would say no, don't run the TurboFloat Server on your own computers. A majority of customers should create a TurboFloat Server instance on our infrastructure. This has the following benefits:

To run the TurboFloat Server on our infrastructure read the "How to create a TurboFloat Server instance" article. If you want to run the TurboFloat Server on your own computers instead, read on:

Running TurboFloat Server on your own computers

As an alternative to running the TurboFloat Server on our infrastructure, you can run the TurboFloat Server on a computer on your network. It doesn't have to be run on "server hardware" per se; TurboFloat Server is designed and optimized to be low profile, low memory, and very fast. This means an end-customer could run TurboFloat Server on a tiny, cheap, Raspberry Pi (or similar ARM device) if they so please.

This guide covers how to activate and install the TurboFloat Server using commandline. However, if you're releasing TurboFloat Server for end users you might consider wrapping this entire process in an installer so your user only has to enter some text in and installer and then click the install button.

Also, it should be noted, that the "TurboFloat Server" can be completely rebranded. That is, your end-users never have to know about "TurboFloat". You can rename TurboFloatServer.exe to anything you want.

This article covers the following topics (click to skip to the topic):

Activating the TurboFloat Server

Before you can use TurboFloat Server it must be activated. To activate the TurboFloat Server online simply pass the product key like this:

TurboFloatServer.exe -a="ABCD-EFGH-IJKL-MNOP-QRST-UVWX"

Online activation connects to the activation servers using port 80 (HTTP) or port 443 (HTTPS). If you specify a proxy in the configuration then the TurboFloat Server instance will try to connect to the activation servers through that.

If you've already activated and you want to re-activate, then you don't need to pass a new product key. You can just call TurboFloat Server with the "-a" commandline argument:

TurboFloatServer.exe -a

Activating offline

You can also activate the TurboFloat Server offline. There are 2 steps in the offline activation: (1) generating the "activation request" and (2) using the "activation response" to actually activate the TurboFloat Server.

To generate the activation request you have to pass in the product key and the location to save the "activation request" XML file. For example:

TurboFloatServer.exe -a="ABCD-EFGH-IJKL-MNOP-QRST-UVWX" -areq="C:\Location\To\Save\ActivationRequest.xml"

After submitting the activation request to the company, and receiving the activation response, you can activate the TurboFloat Server:

TurboFloatServer.exe -a -aresp="C:\Location\To\ActivationResponse.xml"

Using different paths for "TurboActivate.dat" or "TurboFloatServer-config.xml"

When the TurboFloat Server is activating it needs to load both the "TurboActivate.dat" and "TurboFloatServer-config.xml" files. By default the TurboFloat Server looks in the directory in which it's sitting for these files. If, however, you'd like to use different paths for one or both of these files you can do so by using the "-pdets" and/or the "-config" commandline switches. For example:

TurboFloatServer.exe -a="ABCD-EFGH-IJKL-MNOP-QRST-UVWX" -pdets="YourTurboActivate.dat" -config="Config.xml"

Deactivating the TurboFloat Server

If your customers want to move the TurboFloat Server from one computer to another computer they have to deactivate from the first computer before they can activate on the second computer. To deactivate the TurboFloat Server instance you must use the "-deact" commandline switch:

TurboFloatServer.exe -deact

Or, if you wish to deactivate offline (i.e. generate an offline activation request) then you must pass a file path using the "-deact" commandline switch:

TurboFloatServer.exe -deact="C:\Location\To\OfflineReq.xml"

Installing the TurboFloat Server (Windows & macOS)

On Windows and macOS you can use a simple commandline switch "-i" to setup your TurboFloat Server. On success, "TurboFloatServer" returns 0, on failure it returns non-zero.

On Windows this "installation" does three things:

  1. It installs the TurboFloat Server instance as a Windows Service set to start with the computer and run silently in the background.

  2. It configures the TurboFloat Server to allow inbound connections in the Windows Firewall (unless the Windows Firewall service is disabled, in which case it skips this step).

  3. It starts the TurboFloat Server immediately.

On macOS this "installation" does two things:

  1. It installs the TurboFloat Server instance as a "launchd" daemon set to start with the computer and run silently in the background.

  2. It starts the TurboFloat Server immediately.

If you have any firewall software running on macOS then you'll have to set it to allow incoming connections to the TurboFloat Server instance.

The process of installing the TurboFloat Server is the same on macOS & Windows. First put the TurboFloatServer.exe, TurboActivate.dat, and TurboFloatServer-config.xml files in their final locations. Then simply use the -i commandline switch. On Windows, start an "Elevated" command prompt (right click "cmd" in the start menue, then click "Run as Admin"). Then, in the elevate command prompt run the following:

TurboFloatServer.exe -i

Or, on macOS:

sudo ./TurboFloatServer -i

If you want to specify alternate locations for the "TurboActivate.dat" and "TurboFloatServer-config.xml" then use the "-pdets" and/or "-config" commandline switches in tandem with the "-i" switch:

TurboFloatServer.exe -i -pdets="YourTurboActivate.dat" -config="Config.xml"

If you want to install the TurboFloat Server, but don't want it to start immediately, then use the "-delaystart" commandline switch:

TurboFloatServer.exe -i -delaystart

This installs the TurboFloat Server instance but it doesn't start the service. The service will be started on the next restart of the computer. You, or the end-user, can programmatically or manually start the service in the meantime.

Uninstalling the TurboFloat Server (Windows & macOS)

To uninstall the TurboFloat Server simply use the "-u" commandline switch. Again, you'll need to run the command from an elevated command prompt:

TurboFloatServer.exe -u

On success, TurboFloatServer.exe returns 0, on failure it returns non-zero.

On Windows this "uninstallation" does three things:

  1. It stops the TurboFloat Server immediately.

  2. It removes the Windows Firewall configuration settings for the TurboFloat Server instance if both of the following conditions are met:

    1. The Windows Firewall settings were setup during the installation.

    2. The Windows Firewall service is running at the time the uninstallation is taking place.

    If either one of those conditions isn't true, then the uninstallation process simply skips this step.

  3. It removes the TurboFloat Server instance from the Windows Services.

On macOS this "uninstallation" does two things:

  1. It stops the TurboFloat Server immediately.

  2. It removes the TurboFloat Server instance from the "launchd" daemons list.

For both Windows & macOS this uninstallation process leaves the files intact (TurboFloatServer.exe, TurboFloatServer-config.xml, and TurboActivate.dat). If you want the files removed you'll have to remove them after using the "-u" commandline switch.

Note for macOS: If, during the installation, you used the "-pdets" commandline switch, then you'll have to use that switch again during the uninstallation. For example:

sudo ./TurboFloatServer -u -pdets="/Path/To/TurboActivate.dat"

If you didn't use the "-pdets" commandline switch during the installation then you can just uninstall with the "-u" commandline switch.

You don't have to worry about this on Windows due to design differences. The Windows version of the TurboFloat Server "remembers" arguments you passed in.

Installing the TurboFloat Server (Linux)

Since Linux installations vary wildly in how they run "daemons" or "startup services" we don't offer the "-i" commandline switch for Linux. However, you can build the init script yourself (for systemd, System V init, upstart, or any other init system) to launch the TurboFloat Server instance upon the computer's start.

When you're running the TurboFloat Server instance from your init script there are 2 commandline options you'll want to use:

/path/to/turbofloatserver -x -silent

That will tell the TurboFloat Server instance to run and to run silently (not outputting to "stderr").

Configuring the TurboFloat Server

The configuration file for the TurboFloat Server is a simple XML file with UTF-8 encoding. Included in the TurboFloat Server package is an example configuration file. For most end-users almost all of the configuration settings will be good out of the box. And because the configuration file is an XML file, some characters can't be used because they have a special meaning in XML files. The appropriate "XML entities" must be used in their place:

Use this...    ...in place of this
&          &
&lt;           <
&gt;           >
&quot;         "
&apos;         '

The configuration file is only loaded at the start of TurboFloat Server. If you make any changes to the configuration file while the TurboFloat Server is running they'll be ignored until the next time the TurboFloat Server is started.

<log .../> (Required)

This element configures the log file to write errors, warnings, and any information. For example:

<log file="tfs-log.txt" level="warning"/>

"file" attribute

Where the log file will be written / appended to. The floating license server must have access to this file and the directory must exist.

You can use either absolute path or a relative path. If you use a relative path then the log file will be written relative to the TurboFloat Server executable file.

"level" attribute

The amount of information you want TurboFloat Server to output to the log file. These are the possible level settings:

<bind .../> (Required)

Setup the port you want the TurboFloat Server to bind to. For example:

<bind port="13"/>

The TurboFloat Server instance will listen for TCP connections on this port for both IPv4 and IPv6. If the system doesn't support IPv6, then the TurboFloat Server instance will only listen on IPv4.

<cpu .../> (Required)

Setup how many worker threads you want the server to use. We recommend setting this to 1 thread per CPU "core". If you set this value to "0" then TurboFloat Server will automatically detect how many cores the computer has and use that value. For example:

<cpu threads="0"/>

<lease .../> (Required)

Setup how long a license lease should last. The time is in seconds. We recommend 30 minutes (i.e. 1800 seconds):

<lease length="1800"/>

The shorter you make this time the more often the "client" programs will have to contact this server, and thus the more load on the server and the more traffic on the network. The only time "long" leases will be a problem is if the client programs end abruptly without first telling the server that the lease is no longer needed. Thus a "zombie" lease will take up one of the lease slots until it expires.

The absolute minimum time you can use is 30 seconds.

<isgenuine .../> (Required)

Set how often to recheck this TurboFloat Server's activation. This TurboFloat Server instance will contact the activation servers through wyday.com on port 443. (So, https://wyday.com must be whitelisted for this process so that it can contact those sites).

"days_between" attribute

How many days between check. Minimum 1. Maximum 90. We recommend 90.

"grace" attribute

The number of grace period days on an internet failure. Maximum 14.

<isgenuine days_between="90" grace="14"/>

<proxy .../> (Optional)

The proxy that this TurboFloat Server instance will need to use when it needs to contact LimeLM to activate, re-activate, and verify with the LimeLM servers.

<proxy url="http://user:pass@127.0.0.1:8080/"/>

Configuring TurboFloat Server for HTTPS communication

In the TurboFloat Server 4.1 and newer we've added support for HTTPS communication. Meaning in addition to (or in place of) the default "raw" binary communication over the port you specified in the "bind" element, you can configure the TurboFloat Server to communicate over HTTPS. You can do this by "binding" the TurboFloat Server to an address and port for SCGI communication with an existing web server (e.g. Apache, NGINX, etc.).

This guide covers the very basics of the HTTPS server configuration. We assume you have experience running an HTTPS server. If not, use our hosted version of TurboFloat Server (no configuration is needed -- we handle all the details).

Configure SCGI address and port

In the example "TurboFloatServer-config.xml" file you'll see an XML element like this:

<scgi just_scgi="false">
    <bind address="127.0.0.1" port="42"/>
</scgi>

There are 3 options to configure:

  1. The "just_scgi" attribute: Set this to "false" and raw, unencrypted connections, will still be allowed. Set this to "true" and only connections over SCGI (via an HTTPS server) will be accepted and the global bind element will be ignored.

  2. The "address" attribute in the "bind" element : Set this to the address you want the HTTPS server that sits in front of the TurboFloat Server to connect to.

    If the address is not present, the server accepts TCP / IP connections on all server host IPv6 and IPv4 interfaces if the server host supports IPv6, or accepts TCP / IP connections on all IPv4 addresses otherwise. Use this address to permit both IPv4 and IPv6 connections on all server interfaces. This value is the default.

    If the address is ::, the server accepts TCP/IP connections on all server host IPv4 and IPv6 interfaces.

    If the address is 0.0.0.0, the server accepts TCP/IP connections on all server host IPv4 interfaces.

    If the address is a "regular" IPv4 or IPv6 address (such as 127.0.0.1 or ::1), the server accepts TCP/IP connections only for that IPv4 or IPv6 address.

  3. The "port" attribute in the "bind" element : Set this to the port you want the HTTPS server that sits in front of the TurboFloat Server to connect to.

For security sake, we recommend always bind to a local address (like "127.0.0.1") so that all data that touches the TurboFloat Server must first go through an HTTPS server.

Configure the HTTPS server (Apache)

If you're using the Apache HTTPS server, modify your "httpd.conf" file to enable the "scgi" module (so Apache can communicate with the TurboFloat Server instance):

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
LoadModule ssl_module modules/mod_ssl.so

Next add a "VirtualHost" element that will accept HTTP connections and pass them along to the TurboFloat Server:

<VirtualHost yourhostaddress:443>
    # Pass *everything* to the TurboFloat Server via SCGI
    SetEnvIf Request_URI .* proxy-scgi-pathinfo
    ProxyPass / scgi://127.0.0.1:42/

    # ServerName gives the name and port that the server
    # uses to identify itself. This can often be determined
    # automatically, but we recommend you specify it
    # explicitly to prevent problems during startup.
    ServerName yourhostaddress:443

    # Turn SSL on
    SSLEngine on
</VirtualHost>

Replace "yourhostaddress" with the address name that the TurboFloat Server instance will be accessed from (i.e. the "public" address -- even if that "public" address is local network specific). Also, if you changed the SCGI "address" or "port" in the "TurboFloatServer-config.xml" file you'll also need to change the "ProxyPass" directive to use the address and port you changed them to.

Configure the HTTPS server (Nginx)

If you're using the NGINX HTTPS server, first make sure your NGINX has been compiled with the SCGI module. You can do this by running "nginx -V" via commandline and you should see something like this:

nginx version: nginx/1.15.7
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
built with OpenSSL 1.1.1a  20 Nov 2018
TLS SNI support enabled
configure arguments: --sbin-path=/usr/local/sbin --with-http_ssl_module --with-http_v2_module --without-http_uwsgi_module --with-pcre-jit --with-threads

If you don't see "--without-http_scgi_module" in the "configure arguments", then you know the NGINX instance was compiled with the SCGI module. It's compiled by default, so it should be available in every vanilla distribution of NGINX.

Next, modify your "nginx.conf" file to pass all communication to the address / port of your choosing to the TurboFloat Server instance via SCGI:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name  yourhostaddress;

    # Maximum "request" size (i.e. max size the client sends us)
    client_max_body_size 10m;

    # pass every connection to the Hosted TFS on this machine.
    location / {
        scgi_param  SCGI               1;
        scgi_param  HTTPS              $https if_not_empty;
        scgi_param  REQUEST_METHOD     $request_method;
        scgi_param  CONTENT_LENGTH     $content_length;
        scgi_param  REMOTE_ADDR        $remote_addr;
        scgi_pass   127.0.0.1:42;
    }
}

Replace "yourhostaddress" with the address name that the TurboFloat Server instance will be accessed from (i.e. the "public" address -- even if that "public" address is local network specific). Also, if you changed the SCGI "address" or "port" in the "TurboFloatServer-config.xml" file you'll also need to change the "scgi_pass" directive to use the address and port you changed them to.

Test and fix access to the TFS over HTTPS

After configuring the TurboFloat Server, then configuring the HTTPS server, start both of them up. If either one fails to start, read the error log and fix whatever problems are described. Once both are successfully started, you're ready to test if the TurboFloat Server is accessible via HTTPS. You can do this by opening a browser on your computer and typing the host address you've configured in your HTTPS server configuration.

So, in this example, "yourhostaddress" is the address that the HTTPS server is accessible from. Type, "https://yourhostaddress" into your browser, and if you've configured everything correctly (and both the TFS and your HTTPS server are running) then this page should show:

Extra activation data

If you see a certificate error page, then make sure you're using SSL certificates signed by a Certificate Authority. There are multiple options available, but the best certificate authority (CA) is free (Let's Encrypt).

Running TurboFloat Server from commandline

If you would rather just run the TurboFloat Server from the commandline, rather than installing it, you can do that using the "-x" command switch:

TurboFloatServer.exe -x

In that example the TurboFloat Server instance will run from the commandline and the "TurboActivate.dat" and "TurboFloatServer-config.xml" files will be loaded from the same directory as the "TurboFloatServer.exe" file. If you want to load either (or both) the "TurboActivate.dat" or the "TurboFloatServer-config.xml" files from separate locations then use the "-pdets" and/or "-config" commandline switches in tandem with the "-x" switch:

TurboFloatServer.exe -x -pdets="C:\location\to\TurboActivate.dat" -config="C:\Location\To\Config.xml"

View the TurboFloat Server Commandline options article for all other commandline options.

Upgrading the TurboFloat Server instance

We're continually improving TurboFloat & the TurboFloat Server (fixing bugs, improving performance, and adding features). You can always get the latest and greatest version of TurboFloat / TurboFloat Server on your API page.

Upgrading the TurboFloat Server instance is simple:

  1. Stop the running old instance of the TurboFloat Server.

  2. Replace the old TurboFloatServer.exe (or whatever you've renamed it as) with the new version.

  3. Start the TurboFloat Server instance again.

Windows & macOS

If you want to make this easier for the end-user you might consider automating this process. To start / stop the TurboFloat Server Windows Service instance you must use the "service name" of "TurboFloatServer-[VERSIONID]". Or, on macOS, the "launchd daemon label" will be "com.turbofloatserver.[VERSIONID]".

The "[VERSIONID]" value is the id of the version where the product key is from. You can get the version ID by examining the URL in your browser. For instance, from the URL https://wyday.com/limelm/version/100/ you can see the version ID is 100. (Note: The Version ID is not the Version GUID).

So if your version id is "100" then the service name for your TurboFloat Server instance is "TurboFloatServer-100" on Windows. Here's how you would stop the service from commandline:

sc stop TurboFloatServer-100

And to start the service again:

sc start TurboFloatServer-100

Similarly, on macOS, if your version id is "100" then the "launchd daemon label" will be "com.turbofloatserver.100". Here's how you would stop the daemon from commandline:

sudo launchctl stop com.turbofloatserver.100

And to start the service again:

sudo launchctl start com.turbofloatserver.100
About  ·  Careers  ·  Contact us  ·  Privacy  ·  Site Map
© 2023 wyDay