The following describes configuration guidelines in terms of how many daemons to run and how to keep your software secure.
When your installation procedure installs the FLEXlm software at your end-user site, there are some things you should keep in mind:
All license server executables (lmgrd and vendor daemons) should be LOCAL on the system(s) which will run them. A corollary of this is that you should not run license servers on diskless nodes. (See “ls_do_checkroot” for more information on diskless license server nodes.)
There should be a local copy of the license file on each server node. It is fine to NFS-mount the license file for client access, but each server node should have a local copy. An even better approach is to set the LM_LICENSE_FILE environment variable to port@host for all clients, unless the license file is particularly large (larger than 5K), in which case having a local copy of the license file be provide improved network performance. (See “Locating the License File” for more information.
It is poor policy to configure redundant servers and then keep only one copy of either the daemons or license file—in this case you still have a single point of failure. Put a copy of lmgrd, your vendor daemon, and the license file on the disk of each license server node.
You will have to help your end-user decide how many server nodes to run, as the license keys are partially derived from the list of server node hostids.
One server node is recommended, unless the network and/or server machines on the network regularly go down. In this case use three server nodes, so that any one can go down and still allow the software to run. Note that the server nodes do not have to be of the same machine architecture; all FLEXlm platforms (except VMS) can operate in a heterogeneous manner.
No software is completely secure. FLEXlm is no exception. While Globetrotter Software has made every effort to ensure the integrity of FLEXlm, all points of attack can never be anticipated. The following lists known points of vulnerability in FLEXlm in increasing order of difficulty to break.
Writing a new daemon that emulates your vendor daemon. FLEXlm encrypts the traffic between client and vendor daemon to make this point of attack much more difficult.
Running the debugger on stripped executables. This would require someone to find the FLEXlm calls without any symbol table knowledge.
Killing the daemons, since a majority of daemons must be up in order for anything to run, and a dead daemon is detected within the timer interval in a client. If, however, you do not use one of the built-in timers and you do not call lc_timer, then your software protection could be bypassed by someone who kills the daemons each time that the application reaches the maximum license limit, as the applications would never detect that the daemon went down.
To reduce the potential for theft by killing and starting daemons:
call lc_timer() at least every 120 seconds (but not more often than every 30 seconds)
Once reconnection is being attempted, exit after less than 5 minutes, and at least 3 reconnection attempts.
FLEXlm's standard encryption algorithm takes the user-visible data fields (number of licenses, expiration date, feature version number, vendor-defined string, feature name, host IDs of all servers, plus any optional encrypted fields) and combines them with the vendor's private encryption seeds and the start date to produce a 20 hex-character license key. The algorithm used is a proprietary one-way block chaining encypherment of all the input data.
FLEXlm provides the capability for you to create time-expired demo software with no source code changes. This is accomplished via appropriate selections when creating the customer license file. In order to create a license file that supports demo mode, simply select 0 as the number of licenses, and use “DEMO” as the node ID of the feature. Any such feature will run on any node until the feature's expiration date is reached. In addition, the application can detect that the enabling FEATURE line has a DEMO hostid, and can limit functionality appropriately. Some applications may then prefer to issue non-expiring DEMO licenses.
In the case where multiple software vendors install FLEXlm-based products at a single end-user site, the potential for license file location conflicts arises. This section summarizes strategies that allow for a minimum of end-user inconvenience.
There are basically two cases involved at an end-user site when more than one software vendor installs products.
All products use the same license server node(s).
In this case, there are two solutions:
The end-user can keep both license files separate, running two lmgrds, one for each license file. There's no drawback in this approach, since each lmgrd requires few system resources, and take almost no CPU time.
You can combine license files by taking the set of SERVER lines from any one license file, and add all the other lines (DAEMON, FEATURE, INCREMENT, PACKAGE, UPGRADE, and FEATURESET lines) from all the license files. The combined license file can be located in the default location (/usr/local/flexlm/licenses/license.dat on UNIX platforms and C:\FLEXLM\LICENSE.DAT on Windows and Windows NT) or in any convenient location (with the end-user using the LM_LICENSE_FILE environment variable or license finder), or multiple copies can be located at fixed locations as required by the various software vendors. The user should leave a symbolic link to the “real” license file in the locations where each software package expects to find its license file.
In practice, sites that have experienced system administrators often prefer to combine license files. However, sites with relatively inexperienced users, and no system administrator, usually do better leaving the files separate.
The products use different license server node(s).
In this case, separate license files will be required, one for each distinct set of license servers (where multiple software vendors use the same set of license server nodes, the technique described in case 1 above can be used to combine their license files).The resulting (multiple) license files can then be installed in convenient locations, and the user's LM_LICENSE_FILE environment variable would be set as follows.
% setenv LM_LICENSE_FILE lfpath1:lfpath2:....:lfpathN" |
| where: | is the: | |
| lfpath1 | is the path to the first license file | |
| lfpath2 | is the path to the second license file | |
| . |
| |
| . |
| |
| lfpathN | is the path to the last (Nth) license file |
When products from different vendors use different versions of FLEXlm, always use the latest versions of lmgrd and the lmutil utilities.
The latest version of lmgrd will always support any FLEXlm license. The end-user has to find out which lmgrd at their site is the latest version. This can be done using lmgrd -v to get the version. If an earlier version of lmgrd is used than the vendor daemon, then various errors may occur, especially “Vendor daemon can't talk to lmgrd (invalid returned data from license server).”
When an end-user has licensed products that incorporate various versions of FLEXlm, care must be taken to insure that the correct versions of lmgrd and the FLEXlm utilities are used. The basic rule is that the most recent (highest version number) lmgrd should be used. If the utility programs are FLEXlm v2.4 or later, then the newest utility programs should be used as well. If the utility programs are older than v2.4, then the oldest (lowest version number) utility programs should be used. This is due to the fact that the newest lmgrd knows how to support all versions of the vendor daemons, whereas utilities prior to FLEXlm v2.4 did not know how to communicate with the older vendor daemons. After FLEXlm v2.4, the utility programs automatically back off their communications version to enable them to work with all versions of the FLEXlm daemons.
To determine the version of any FLEXlm-based product, use the following command:
% lmver program_name |
Once you have determined the versions of all the software you want to use, do the following:
Use the highest-numbered lmgrd that you have.
Use the FLEXlm utilities that correspond to the oldest client or vendor daemon that you have in use., OR, use the newest utilities if they are FLEXlm v2.4 or newer.