Chapter 1. Introduction to FLEXlm

FLEXlm is a network-wide floating licensing package that allows a software application to be licensed on a concurrent-usage, as well as on a per-computer, basis.

Features of FLEXlm

With FLEXlm, you, the application developer, can restrict the use of your software packages to:

  • A single specified computer.

  • A specified number of users on a single computer.

  • A specified number of users in a network containing one or more computer systems.

FLEXlm is available on UNIX, VMS, Windows (clients only), and Windows NT systems. FLEXlm features include:

  • Restriction of software packages to specified computers and users.

  • Operation in a heterogeneous network of supported computer systems.

  • License management on redundant server hosts for improved license availability due to hardware failure.

  • Optional license expiration dates.

  • Counted and uncounted license usage.

  • Support for demo software.

  • Independent features from one or multiple vendors with independent vendor security codes.

  • A vendor-definable field for each application feature.

  • Transparent reconnection of applications when their daemon process becomes unavailable, including conditions of license server node failure.

  • Ease of configuration with a single license file per network.

  • Configuration controls for System Administrators.

  • Administration tools for System Administrators.

FLEXlm Terms and Definitions

The following terms are used as defined to describe FLEXlm concepts and software components.

feature 

Any functionality that needs to be licensed. The meaning of a feature will depend entirely on the way that an application developer uses it. For example, a feature could be any of the following:

  • An application software system consisting of hundreds of programs.

  • A single program (regardless of version).

  • A specific version of a program.

  • A part of a program.

  • A piece of data (restricted via the routines that access it).

license 

The right to use a feature. FLEXlm can restrict licenses for features by counting the number of licenses already in use for a feature when new requests are made by the application software (client). FLEXlm can also restrict usage of software to particular nodes or user names.

client 

An application program requesting or receiving a license.

daemon 

A process that “serves” clients. Sometimes referred to as a server.

 

vendor daemon The daemon that dispenses licenses for the requested features. This daemon is built by an application's vendor (from libraries supplied by Globetrotter Software) and contains the vendor's unique encryption seeds.

lmgrd 

The daemon process, or license daemon, that sends client processes to the correct vendor daemon on the correct machine. The same license daemon process can be used by all applications from all vendors, as this daemon neither performs encryption nor dispenses licenses. lmgrd is analogous to inetd in 4.2bsd systems: i.e., it processes no user requests on its own, but forwards these requests to other daemons (the vendor daemons).

server node  

A computer system that is running both the license and vendor daemon software. The server node will contain all the site-specific information regarding the usage of all the features. Multiple server nodes used for redundancy can logically be considered the server node.

license file 

An site-specific file that contains descriptions of the server nodes that can run the license daemons, the various vendor daemons, and the licenses (features) for all supported products.

Software Components

The four main components in FLEXlm are:

  • The client library (embedded in the license-managed application)

  • lmgrd, the license daemon

  • The vendor daemon(s)

  • Vendor and end-user license administration tools

A single license file supports all components.

Typical Configurations

The components of a typical configuration of FLEXlm will consist of:

  • The license file

  • lmgrd

  • A single vendor daemon

  • An application program

Location of the License File

The license file default is /usr/local/flexlm/licenses/license.dat (or C:\FLEXLM\LICENSE.DAT for Windows and Windows NT systems, SYS$COMMON:[SYSMGR]flexlm.dat for VMS systems). This default can be overridden by the developer via calling lc_set_attr(), or by the end-user setting the environment variable LM_LICENSE_FILE (logical name LM_LICENSE_FILE on VMS) to the pathname of the file. If at all possible, Globetrotter Software recommends keeping the license file in the standard location and allowing the end-user to move it by setting the LM_LICENSE_FILE environment variable.

Overview of Installation Process

The end-user installs lmgrd and the vendor daemon. If no redundancy is required, then these daemons run on one server node. If the network has only a single file server which contains all user files, then there is no advantage in having redundant daemons. If redundancy is desired, then the daemon would be installed on three server nodes. FLEXlm supports three server nodes operating as a single “logical” server node on UNIX and Windows/NT systems.

Once the license file and the daemons are in place, all that is required is to start the daemon when the machine boots. The daemon can be most conveniently started in
/etc/rc.boot, /etc/rc.local, /etc/rc, /sbin/rc3.d or /etc/rc3.d, depending on the operating system.

For Windows NT systems, lmgrd can be installed as a system service and started automatically when the system boots.


Note: FLEXlm does not require the use of privileged sockets, therefore any user can start the FLEXlm daemons.

If the license file is in the standard location (or the end-user has LM_LICENSE_FILE set properly) FLEXlm use is transparent to the end-user once the administrator has started the FLEXlm daemons.

Configuration Trade-offs

Configurable parameters in FLEXlm include:

  • Number of server nodes, or server-less (uncounted) licenses.

  • License file location.

  • Type and frequency of checking for daemon failures in the client software.

  • Reconnection parameters (in the event of daemon failure).

The following sections describe daemon and client configuration trade-offs.

Selecting Server Nodes

If all the end-user data is on a single file server, then there is no need for redundant servers, and Globetrotter Software recommends the use of a single server node for the FLEXlm daemons. If the end-user's data is split among two or more server nodes and work is still possible when one of these nodes goes down or off the network, then multiple server nodes can be employed. In all cases, an effort should be made to select stable systems as server nodes; in other words, do not pick systems that are frequently rebooted or shut down for one reason or another.

Client Considerations

The major trade-off in the client configuration options is the decision to terminate the application or let it continue running when it loses its connection to the daemon, which can indicate attempted theft. This policy decision must be made by each application vendor; FLEXlm can adapt to the required strategy.

The parameters available to implement the required policy are:

  • Number of retries before connection is determined to be down.

  • Retry interval.

  • Action when retry fails.

  • Automatic (via SIGALRM on UNIX and via SetTimer on Windows/NT) or vendor supplied reconnection to a restarted daemon.

To implement a lenient policy, the number of retries can be set high, and the result of retry failure can be the display of a warning message with further retries at fixed intervals.

If a stricter policy is required, then the number of retries can be set low, with a relatively short retry interval, and termination of the application can be enforced. Other alternatives could include: limiting the functionality (disable printing for example) or slowing the performance of the product.

In both cases, the time while FLEXlm is retrying to connect to a daemon could be used to save files and checkpoint the application. If checkpointing were done and no new daemon connection were possible at the end of the interval, the application would be ready to exit.

Other client trade-offs concern the location of the license file and the appropriate selection of licensable features. In general, Globetrotter Software recommends that you leave the license file location at /usr/local/flexlm/licenses/license.dat (or C:\FLEXLM\LICENSE.DAT for Windows and Windows NT systems, and SYS$MANGER:FLEXLM.DAT for VMS systems), and let the end-user override this path, if necessary, as described in Chapter 12, “End-User License Administration.”


Note: Globetrotter Software recommends that you do not override the use of the LM_LICENSE_FILE environment variable within your code.


Developer's Interface

The application program interfaces to FLEXlm via a set of routines that checkout and checkin copies of the licensed feature(s). Two primary routines perform checkout and checkin respectively. Additional routines are provided to set defaults, provide a list of users of the feature and provide other miscellaneous functions.

Client Library Routines

The application program is a client of FLEXlm. The routines to manage licenses are all contained in the FLEXlm client library liblmgr.a (lmgr.dll for Windows or lmgr32.dll for Windows NT and Win32s).

lc_auth_data 

Gets the license file line for a checked-out feature.

lc_baddate 

Verify the date has not been set back on the running system.

lc_checkin 

Restores a license of a feature to the license pool.

lc_checkout 

Requests a license of a feature.

lc_ck_feats 

Checks FEATURESET line.

lc_disconn 

Disconnect from a license daemon.

lc_display 

Returns the display the process is running on.

lc_errstring 

Returns an explanatory error string for the most recent error.

lc_feat_list 

List all features in the license file.

lc_feat_set 

Computes FEATURESET code.

lc_first_job 

Walks list of FLEXlm jobs.

lc_free_job 

Frees a job allocated with lc_init.

lc_flush_config 

Rereads the cached license file.

lc_get_attr 

Retrieves a FLEXlm client attribute.

lc_get_dlist 

Gets a list of all vendor daemons.

lc_get_config 

Gets the first occurrence of the FEATURE line in the cached license file.

lc_get_feats 

Returns a FEATURESET line.

lc_gethostid 

Gets the hostid of the local machine.

lc_hostname 

Returns the current hostname.

lc_hosttype 

Provides information about the current host.

lc_idle 

Supports Administrator defined TIMEOUT option via options.dat files.

lc_init 

Initializes FLEXlm, and creates a license job.

lc_isadmin 

Returns true if user is in the lmadmin group.

lc_lic_where 

Returns the location of the license file.

lc_log 

Logs a message to the daemon log file.

lc_master_list 

Returns the list of servers in the license file.

lc_next_conf 

Gets the license file line for a feature.

lc_next_job 

Walks list of FLEXlm jobs.

lc_perror 

Prints an error message to stderr.

lc_remove 

Remove a user of a specified feature.

lc_set_attr 

Sets a FLEXlm client attribute.

lc_shutdown 

Shuts down FLEXlm servers.

lc_status 

Returns the current status of a feature.

lc_timer 

Sends heartbeat from client to server.

lc_vsend 

Sends and receives messages from server.

lc_userlist 

Gets a list of the users of a feature.

lc_username 

Returns current user's login name.

The include file lm_client.h contains all the symbolic definitions required for most calls. lm_code.h contains the vendor's encryption seeds and FLEXlm vendor key values. lm_attr.h contains the definitions used in the lc_set_attr() and lc_get_attr() calls.

Software License Working Group Compatibility Calls

FLEXlm supports the Software License Working Group API. See “Software License Working Group” for more information.

ls_init  

Initialize licensing system (same as lc_init).

ls_terminate  

Terminate licensing system operations.

ls_log_message  

Log a message.

lb_request  

Request license.

lb_check_wait  

Check status of a queued license.

lb_wait_remove  

Remove process from license wait queue.

lb_confirm  

Inform license system license is still in use.

lb_release 

Release license.

lb_get_cur_users 

List all current users of a license.

um_put_record 


Not implemented.

um_get_record 


Not implemented.

um_delete_records 


Not implemented.

um_purge_records 


Not implemented.

um_undelete_records 


Not implemented.

LSAPI Calls

FLEXlm supports License Service Application Programming Interface (LSAPI). See “LSAPI v1.1”.

LSEnumProviders 


List providers of licensing service

LSGetMessage 

Get message text from licensing system

LSQuery 

Query License information

LSRelease 

Release license

LSRequest 

Request license

LSUpdate 

Update license status for details.

Example Application

The following is an example of an application with calls to FLEXlm. The essential macros and functions are: LM_CODE(), lc_init(), lc_checkout(), lc_checkin().

#include "lm_client.h"
#include "lm_code.h"
/*
 *	ENCRYPTION_CODE_n are made up by vendor
 *	VENDOR_KEYn are provided by Globetrotter Software
 */
LM_CODE(code, ENCRYPTION_CODE_1, ENCRYPTION_CODE_2,
			VENDOR_KEY1, VENDOR_KEY2, VENDOR_KEY3, 
			VENDOR_KEY4, VENDOR_KEY5);
LM_HANDLE *lm_job = (LM_HANDLE *)0; /* first arg to all lc_xxx calls */
	/*...*/
	rc = lc_init(lm_job, VENDOR_NAME, &code, &lm_job);
	if (rc)
	{
		lc_perror(lm_job, "FLEXlm initialization failed");
		exit(rc);
	}
/*
 *	Check out feature
 */
	rc = lc_checkout (lm_job, "myfeature", "1.0", 1, LM_CO_NOWAIT, 
					&code, LM_DUP_NONE);
	if (rc)
	{
		lc_perror(lm_job, "Checkout failed");
		exit(rc);
	}
/*
 *	Checkout succeeded. Actual application code here
 */
	/*...*/
/*	
 *	Done with "feature", check it back in.
 */
	lc_checkin(lm_job, feature, 0);
	/*...*/

FLEXlm Kits

All FLEXlm kits are the same; a set of software “keys” distributed by Globetrotter Software determines if the kit is either a full-function or a demo kit. All demo kits have expiration dates and they also have a number of features disabled.

Specifically, FLEXlm demo kits have the following features disabled:

  • Redundant server host support

  • Client-Daemon clock checking

  • Logfile switch support

  • lc_hosttype() function

  • lc_auth_data() function

  • Vendor-specified daemon initialization routine support

  • INCLUDE/EXCLUDE/RESERVE and TIMEOUT support for end-user configuration

  • lmreread support

  • Feature start date support

  • Duplicate grouping support

  • FEATURESET support