Author: Matt Christiano

RLM Backwards Compatibility

RLM Backwards Compatibility: Is RLM v10 backward compatible with RLM v8.0?

This question  often comes up.  The general question is, how is backward compatibility handled in RLM?

On the license server side, the rules we have always followed (and we expect to always follow in the future), are these:

  • You can always use a newer version of rlm with an older ISV server
  • You can always use a newer version of license server (both rlm and the ISV server) with an older client (application)
  • You can, of course, always use the same version of application and license server.

So, for example, let’s say you have an application that is built with RLM v7.0.  This application will work with any of these combinations of servers:

  • rlm v10.0 and ISV server v7.0 thru v10.0
  • rlm v9.0 and ISV server v7.0 thru v9.0
  • rlm v8.0 and ISV server v7.0 thru v8.0
  • rlm v7.0 and ISV server v7.0

There is one caveat to this general rule, and it applies to ISVs who ship server settings files rather than server binaries.  A server settings file allows the ISV to specify the newest and/or oldest version of RLM with which it will operate.  By default, they operate within the rules outlined above, but the individual ISV can override this. So the instructions from your ISV (if they use settings files) will always override these general rules.

What this means, in practice, is that if you have a multiple-ISV RLM installation, you can always take the newer copy of rlm and ISV server from one of your ISVs and use it with the older ISV server from your other ISV(s).   However, if you use the command-line RLM utilities (instead of the preferred web interface), we only guarantee that the version of the RLM utilities corresponding to the oldest ISV server will work.

RLM Roaming Failures on Windows

Sometimes RLM Roaming won’t work on a Windows system.

When this happens, you see something like the popup displayed here:
RLM Roaming: roam data write error
This often happens when for some reason the client is unable to write the roam data file associated with a roaming license. The file is created in ProgramData\Reprise (Docs and Settings\All Users\App Data\Reprise on older systems). The most likely possibility is that the Reprise directory was created with insufficient privilege for the account you’re using to create files in it.This would happen if the first user account on the system to run an RLM license server, roam a license, or create a rehostable hostid was an admin account AND the RLM version was pre-v9.4. So you should check the permissions on that directory (and files), and set them so that the user is able to write the file.

Windows ISV server fails to start or shuts down after starting

On Windows, RLM sometimes fails to start the ISV server with a select(), getsockname() or “communications (socket) problems” error.  This is a very uncommon problem, but the simple fix described below will correct it.

Reprise has had reports on a very limited number of systems that RLM fails to start the ISV server, with errors similar to the following written to the debug log (note: the ISV name will be your ISV name, not “demo”):

03/16 04:12 (demo) select() failure: Unknown error
03/16 04:12 (demo) Out of file descriptors: Cannot clone communications handle: Unknown error0
3/16 04:12 (demo) Too many errors on main socket, exiting

This error sometimes results in debug log output similar to the following:

01/06 10:11 (rlm) Starting ISV demo
01/06 10:11 (rlm) Error in getsockname() call 13
01/06 10:11 (rlm) … demo on port 57809
01/06 10:11 (rlm) New thread created to watch ISV demo
01/06 10:11 (rlm) demo initialization error: 1, not restarting

Or the following:

01/05 12:50 (rlm) Starting ISV servers:
01/05 12:50 (rlm) … demo on port 1088
01/05 12:50 (rlm) New thread created to watch ISV demo
01/05 12:50 (rlm) demo – communication (socket) problems

This problem is caused by a registry corruption (not induced by RLM) that affects some network operations. The fix is to open a command window and type the command:

$ netsh winsock reset

Should the above “netsh” command not solve the problem, Microsoft has published the following article on how to correct the registry when this occurs. Note that the error message indicating the problem is different in the article than the RLM error message indicating the problem, but the underlying cause is the same.

https://support.microsoft.com/default.aspx?scid=kb;en-us;817571

Using RLM across a Firewall

Sometimes it is desirable for the RLM server to be behind a firewall.  RLM supports this, but there is a small amount of configuration that you will have to do to use RLM across a firewall.

If  you have a firewall installed on the server node which is not allowing your application to access either the rlm port, or the port of the ISV server you must first configure your firewall to allow access to both the main rlm port, as well as the ISV server port.  To do this, perform the following steps:

  • In your license file, look at the SERVER (or HOST) and ISV lines:
    • SERVER   server-hostname   server-hostid   main-rlm-server-port#  (Note: the keyword HOST is equivalent to SERVER)
    • ISV isvname
  • Add the desired port # to the ISV line as follows:

ISV   isvname   port=isv-port#     (if you have RLM v9.0 or later), or

ISV   isvname   isv-binary   isv-options-file   isv-port#    (if you have pre-v9 RLM)

  • Next, configure your firewall to allow access to both isv-port# and main-rlm-server-port#
  • Make sure that the license file is updated on the server node, and that the client nodes know how to find rlm – either with a license file with the SERVER line above, or by setting the RLM_LICENSE environment variable  to  main-rlm-server-port#@server-hostname
  • Re-start rlm – you must restart RLM in order for any port changes to take effect.  Restarting the ISV server via the web interface or rlmreread does not restart RLM.

Note: you can find this information in the RLM License Administration Manual on the Reprise Website.

 

Activation of a Rehostable license fails with a -148 (NO_REHOST_TOP_DIR) error

On Windows, RLM stores persistent data in the “system_drive:”\Documents & Settings\All Users\Reprise directory.

If your system is set up such that permission to this directory is denied for non-admin users, then non-admin users will not be able to create (or use) rehostable licenses.

If this is the case, login to the system as an administrator and set the permissions so that all users can read and write to this directory.

Note that you might see a similar error when using a roaming license or when attempting to start the license server.

Also note that deleting, copying, or otherwise modifying this directory will lead to problems later.

Recommended RLM Installation Steps

Reprise Software’s Recommended RLM Installation Steps

[Note: This information is in the RLM Reference manual, in the “End-User Installation” chapter, but we felt it was important enough to repeat here.]

Installing your product with RLM should be very straightforward, and should require no configuration of environment variables, etc.

Overview:

On the client side, ie, on the machines where your application is going to run, place the license file in your product hierarchy. For nodelocked licenses, this should be the actual, signed license file, and nothing needs to be done to this license file. For floating, this license file will be used only to locate the license server host.

If you ship floating licenses, install the server binaries and license file on the server node. The server license file doesn’t need to be modified.

Nothing in this set of recommendations requires the use of environment variables, and the install-time editing of license files is kept to a minimum (No editing of license files for nodelocked licenses, and only the server hostname needs to be set on the client side for floating licenses).

Details:

During development:

  • establish a directory in your installed product tree for license file(s). This could be the same directory where your product is installed.
  • Pass the directory from the step above as the first argument to rlm_init().

When you ship a nodelocked license:

  • If you are shipping uncounted or single node-locked licenses, put the actual licenses into the license file. Install in the default directory. You’re done.

When you ship a floating license:

  • If you are shipping floating licenses, use a single HOST line in the license file for the client side. Use the default RLM port (5053) – which means you do not need a port number in this license file, and fill in the hostname with the name of the server computer at installation time. This license file should look like this:

HOST server-hostname

  • On the server node, place the rlm binary, your ISVsettings file (or ISV server binary), and the license file in a directory. This license file should have the real, signed licenses. The server hostname in this file can be “localhost”, meaning that it doesn’t have to be edited by the end-user. The server license file’s first two lines should look like this:
    • HOST localhost hostid
      ISV your-isvname

By configuring the license file this way, it does not need to be edited by your customer. These lines tell RLM to:

  • use the default port (5053)
  • use the ISV server settings or binary from the same directory as the rlm binary

Of course, you would include all your signed LICENSE lines in this file as well.

  • Start the rlm server from the directory in the step above

If your customer already has another RLM server running:

  • Install your ISV settings or server binary and the license file in the same directory as the other product’s copy of the server binaries and license files, and do a “reread” operation on the running rlm. That’s it, however:
  • If your version of RLM is newer than the installed version, update the installed version to your version, then shut down the running rlm and start the new one.

If you ship new, additional licenses to your customer:

  • Put the new license file in the same directory as the old one. If they are nodelocked licenses, put them on the client system. If they are floating licenses, put them into the directory with your other licenses and do an rlmreread on the license server.

Failover Servers – why can’t I have 3?

The question often comes up – “I am used to failover servers configured in a triad (3).  Why can’t RLM support this?”

Whenever this happens, it is because someone is used to the way that FLEXlm configures redundant servers.

The reality is this – RLM and FLEXlm work differently with respect to server failover,  and the RLM method is easier for the end-user to configure, while providing the same amount of server redundancy.  In a FLEXlm redundant-server configuration, a little-known fact is this:

the third server can never serve licenses

This is because, in FLEXlm, 2 of the 3 servers must be running to have the system operate.  So, either servers 1 and 2, 2 and 3, or 1 and 3 must be running.  And FLEXlm (at least until version 10.?) always picks the server whose name is first in an alphabetical sort (we know, we wrote the code).   So the server with the last name, alphabetically, will never serve licenses.

By contrast, with RLM, you pick a primary license server, and a failover server.  If the primary goes down, the failover takes over. There is no 3rd server to configure.  There is no situation where 3 FLEXlm servers would serve licenses that RLM will not serve licenses (assuming RLM is configured on 2 of the 3 FLEXlm servers).  In other words:

adding a 3rd RLM server buys you nothing, other than extra administrative overhead

Application cannot connect to license server

What do you do when you get a message saying “application cannot connect to license server”?

Sometimes, after completing the installation of your new software, the application refuses to run, giving you a “Can’t connect to server” error.  When this happens,  the error message will look similar to the following:

Usually, this means one of the following has happened:

  • The license server is not running
  • The hostname or port # on the application’s computer doesn’t match where the license server is actually running
  • The license server (rlm) is running, but the ISV server for your application isn’t running for some reason
  • A firewall is blocking access to rlm or the ISV server
  • The license server machine is down

The first step in diagnosing this problem is to find out where the application thinks the license server should be running.  The most accurate way to do this is to use rlm diagnostics with the application.  Since RLM v8.0, every application which uses RLM has built-in diagnostics.  The procedure for running diagnostics is described in this article:

https://www.reprisesoftware.com/blog/?p=1909

Once you know the hostname and port of the license server, you should log in to that host and verify if the license server is running.  You should see one process for the “rlm” generic server and a second one for your ISV server.  Depending on whether the ISV server is a binary or a settings file, the process listing will be a bit different.  On Unix systems, for an ISV server implemented as a settings file, the two process will look similar to the following (this is for the “reprise” ISV server):

For an ISV server binary, the output will look more like this:

In the windows task manager, you will see either 2 rlm processes or 1 named rlm and one with the name of your ISV server:

  • If you can find rlm running, but not your ISV server, you will need to look at the debug log from rlm to see why the ISV server isn’t running.   The simplest way to do this is to run rlm in a command window (on Windows) or from the shell on Unix.    Go to the directory where the license servers are installed, and run the command “rlm”.    If the problem is not apparent from the output of rlm, you should contatact the ISV who supplied your software – they should be able to help you get the servers running.
  • If both rlm and ISV servers are running on the server node, the problem could be that either you have a firewall installed on the server node which is not allowing your application to access either the rlm port, or the port of the ISV server.   If this is the case, configure your firewall to allow access to port “xxx”, and you can configure RLM to use a fixed port number for the ISV server by specifying the ISV server port, xxx,  on the ISV line as such:

ISV isvname port=xxx (if you have RLM v9.0 or later), or

ISV isvname isv-binary isv-options-file xxx (if you have pre-v9 RLM)

If  you see another cause of this problem, or have a different solution, please leave a comment.

My license server won’t start

One common problem we see at Reprise is the issue of license servers (especially the ISV server) not starting.  When this happens,  the debug log will look similar to the following:

When this happens, it is usually (99.999% of the time) the fact that another copy of the ISV server is running (in this case “isvabc”).  Use the task manager (on Windows) or “ps -ax” (on Unix) to find the other copy of the server that is running, and, if necessary, kill the old copy (don’t forget to kill the rlm server that started it, too, otherwise that copy of rlm will just re-start the ISV server and you’ll be back to where you started).

Note that a similar situation can occur for rlm itself, if you try to start a new copy of rlm on the same port as another copy.

If you need to run multiple ISV servers (and/or multiple copies of RLM) see the article “Managing Multiple-ISV Installations” here .

I can’t check out a license, but I can get to the admin interface on the server – what do I do?

I can’t check out a license, but I can get to the admin web interface!

In some cases, a floating license cannot be checked out from a particular computer, yet that same computer can view the admin web interface from the license server.

In very early versions of RLM (prior to RLM v3.0), the most common cause of this failure is that the “normal” hostname of the server node is unknown on the client machine.

So, for example, if you server node’s hostname is “server”, but it is more generally known as “server.mycompany.com”,  and on the client computer it is only known as “server.mycompany.com”, you will see this behavior.

In more recent RLM versions, the most likely cause is that the hostname in the local license file is not the same as what you typed into the browser.

OK, how do I fix it?

If your rlm software is newer than v3.0, the best way to figure out what is happening is to run rlm diagnostics (available in RLM v8.0 and later).

To run client-side diagnostics, set the environment variable RLM_DIAGNOSTICS to the name of a file, then run the application:

% setenv RLM_DIAGNOSTICS filename

% (run application)

The file “filename” will contain the diagnostic information.  It will look similar to the following:


Near the bottom, you will see the name of the license file that the application is using as well as the server’s hostname.  If this is different from the name you use in your browser, correct the license file and try the application again.

If you have a pre-v3 version of RLM, you might also want to put the server’s IP address into the license file on the server side.  So, instead of:

HOST server hostid port#

use a line like this:

HOST server_ip_address hostid port#

For example, instead of:

HOST  server  12345678  5053

use

HOST  192.16.7.12  12345678  5053