This chapter explains the basics of floating (network) licensing, and gives a quick overview of the components of FLEXlm. It explains where license administrators have control and where end-users have control. A section called `Getting Started Checklist' on page 6 tells both license administrators and end-users how to start managing FLEXlm.
FLEXlm is the most popular license manager used in the software industry. FLEXlm is best known for its ability to allow software licenses to be available (or float) anywhere on a network, instead of being tied to specific machines. Floating licensing benefits both users and license administrators. Users can make more efficient use of fewer licenses by sharing them on the network. License administrators can control who uses the licensed application, and the node(s) where the licenses will be available. See Section 2.4, `Types of License Files,' on page 21 for details about the different licensing models supported by FLEXlm.
The four main components of FLEXlm are:
The license manager daemon (lmgrd) handles the initial contact with the client application programs, passing the connection on to the appropriate vendor daemon. It also starts and restarts the vendor daemons. FLEXlm permits multiple redundant license manager daemons on three server nodes, allowing you to make your license available if any two out of the three server nodes is running. Redundancy can be achieved with 3-server redundant servers, or by using a license file list with any number of servers.
lmgrd is not present on VMS or Netware systems.
In FLEXlm, licenses are granted by running processes (unless they're node locked, uncounted, in which case they need only read the license file to run). There is one process for each vendor who has a FLEXlm-licensed product on the network. This process is called the vendor daemon. The vendor daemon keeps track of how many licenses are checked out, and who has them. If the vendor daemon terminates for any reason, all users lose their licenses (though this does not mean the applications suddenly stop running). Users normally regain their license automatically when lmgrd restarts the vendor daemon, though they may exit if the vendor daemon remains unavailable.
Client programs communicate with the vendor daemon, usually through TCP/IP network communications. The client application and the daemon processes (the license server) can run on separate nodes on your network, across any size wide-area network. Also, the format of the traffic between the client and the vendor daemon is machine-independent, allowing for heterogeneous networks. This means the license server and the computer running an application can be either different hardware platforms or even different operating systems (Windows and Unix, for example).
Licensing data is stored in a text file called the license file. The license file is created by the software vendor, and edited and installed by the license administrator. It contains information about the server nodes and vendor daemons, and at least one line of data (called FEATURE or INCREMENT lines) for each licensed product. Each FEATURE line contains a license key based on the data in that line, the hostids specified in the SERVER lines, and other vendor-specific data.
In some environments, the licensing information for several vendors may be combined into a single license file.
Most applications have an expected location for the license file, documented by that application. End-users can usually override this location by setting the environment variable LM_LICENSE_FILE to point elsewhere, or by following instructions supplied with the licensed application. If your site has software from multiple vendors with incompatible license files (due to different sets of servers), you can keep the data in separate files and set the LM_LICENSE_FILE variable to reference multiple files.
Flexlm provides a default location for license files, which is used only if no other location is provided by the application or user, and this is considered rare. The default location is:
/usr/local/flexlm/licenses/license.dat (Unix)
C:\flexlm\license.dat (Windows, Windows/NT, OS/2)
SYS$COMMON:[SYSMGR]flexlm.dat (VMS)
SYS:\SYSTEM\flexlm\license.dat (Netware)
The default location should be used with caution: setting LM_LICENSE_FILE may actually cause applications to fail if their license is located in the default location, but that location is not included in LM_LICENSE_FILE. This is because setting LM_LICENSE_FILE removes the default location from the license file list.
It's strongly recommended that you keep a copy or link (on Unix) of the license file in the vendor's expected license location, so that users will not need to set LM_LICENSE_FILE to run their applications. If the licenses are counted (floating) this license should have a `USE_SERVER' line directly after the SERVER line. For details, see Chapter 2, `The License File' on page 9. See also Appendix C, `How to set environment variables' on page 65.
The application program using FLEXlm is linked with the program module (called the FLEXlm client library) that provides the communication with the license server. On Windows, this module is called LMGRxxx.DLL, where xxx indicates the FLEXlm version. During execution, the application program communicates with the vendor daemon to request a license.
When you run a `counted' FLEXlm-licensed application the following occurs:
`Uncounted' features (where the number of licenses is '0') do not require a server, and the FLEXlm client library routines in the application grant or deny usage based solely upon the license contents.
Most of the parameters of FLEXlm are configurable by the license administrator. The license administrator can set:
In addition, the license administrator can reserve licenses for specific users, nodes, or groups, and control other license-related options. Changing parameters is discussed in Chapter 5, `The Options File' on page 35.
Refer to your vendor's documentation before attempting to change file names, locations, or contents.
The following sections provide a quick overview of how to set up and use licensing for FLEXlm-licensed products. By scanning the list, you should be able to quickly find the areas of interest. Cross-references point to more details in other parts of this manual.
As a license administrator you are responsible for setting up licensing on your system or network. This section tells you how to do that. If you are an end-user of the application and you will not be involved in installing it, then go to Section 1.2.2, `Notes for End-Users,' on page 7.
Remember that the installation guide for your application software is the final word on installing and configuring FLEXlm.Generally, however, installing FLEXlm licensing requires the following steps:
These steps are discussed briefly below, with cross-references to the appropriate locations for more detail.
Before running any FLEXlm-licensed program using floating licenses, you will need to set up your license server node (or nodes). You must select which node or nodes to run your license servers on, and provide the hostid of those machines to your software vendor. For pointers on selecting your server machine, see Chapter 4, `Selecting Server Nodes' on page 29.
You can get the hostid of the server machine by running FLEXlm's lmhostid utility on that machine. If you don't have lmhostid, you can get the hostid of your machine by using the appropriate command as described in A.1, `Hostids for FLEXlm-Supported Machines'.
Using the hostid of your server machines your vendor will send you a license file that enables their application software.
Once you have received a license file from your vendor, you must install it on your system and start up the license manager daemon, lmgrd.
GLOBEtrotter Software supplies administration tools to your software vendor. The vendor usually includes them with their product. The recommended location for the tools is /usr/local/bin (Unix), C:\flexlm (Windows), or SYS$COMMON:[SYSMGR] (VMS), but you can install them in a different location (or not at all). See Chapter 6, `License Administration Tools' on page 45 for more information.
The options file controls various options such as reservations and timeouts of licenses. Most users run without an options file, but you may decide you want to use some options. For example, many administrators use an option to limit the quantity and content of logged messages. To set up an options file, see Chapter 5, `The Options File' on page 35.
As a user of a FLEXlm-licensed application, you may need to know a few things to use the system effectively. The main things you need to know are:
The license file determines what features are available to a program. It also contains information telling the application how to connect to the license server.
For information about the standard way of specifying a license file for an application, see Chapter 2, `The License File' on page 9.
To find out who is using a license run lmstat, described in Chapter 6, `License Administration Tools' on page 45.
The license file contains all site-specific information required by FLEXlm. This information includes:
In general, the license file, or a copy of it, must be accessible to every machine that runs a FLEXlm-licensed application, and each machine designated as a license server. If the license file contains counted (also called `floating') licenses, before you can use the application you have to start the license manager daemon (lmgrd) using the following syntax:
lmgrd [-c license_file_path]
On VMS and Netware systems there is no lmgrd and the vendor daemon is run directly.
Most software vendor recommend a specific location for your license file. If you are running the application on multiple nodes, you have these options for making your license available on all the machines:
Since the vendor daemon keeps track of license usage, and since the license file contains encrypted data to protect it against modification, you may move and copy the license file as much as necessary.
For counted licenses, no matter which option you choose, you must first install lmgrd and the vendor daemon.
With a FLEXlm v6+ vendor daemon and lmgrd, the license path can be a list of files, separated by colons on Unix, or semi-colons on Windows. If there is a directory in this list, all files named *.lic in that directory are used.
You can only start lmgrd on the server node specified in the license file.
If you are running redundant servers, you should have separate copies of the license file (as well as the binaries for lmgrd and the vendor daemons) on each server node. If you do not do this, you lose all the advantages of having redundant servers, since the file server holding these files becomes a single point of failure.
If any licenses in the license file are counted (count > 0), then the license server must be started before the product can be used.
To start the license manager daemon (lmgrd) execute a command similar to the following.
% lmgrd_path -c license_file_path >& log_path &
$ nohup lmgrd_path -c license_file_path > log_path 2>&1 &
On Unix, edit the appropriate boot script, which may be /etc/rc.boot, /etc/rc.local, /etc/rc2.d/Sxxx, /sbin/rc2.d/Sxxxx, etc. Remember that these scripts are run in /bin/sh, so do not use the csh `>&' redirection syntax.
Each Unix operating system can have some quirks in doing this, but the following script has been successfully tested for HP700 systems. See the notes following for a full explanation.
/bin/su daniel -c 'echo starting lmgrd > \ /home/flexlm/v5.12/hp700_u9/boot.log' /bin/nohup /bin/su daniel -c 'umask 022; \ /home/flexlm/v5.12/hp700_u9/lmgrd -c \ /home/flexlm/v5.12/hp700_u9/license.dat >> \ /home/flexlm/v5.12/hp700_u9/boot.log' /bin/su daniel -c 'echo sleep 5 >> \ /home/flexlm/v5.12/hp700_u9/boot.log' /bin/sleep 5
/bin/su daniel -c 'echo lmdiag >>\ /home/flexlm/v5.12/hp700_u9/boot.log' /bin/su daniel -c '/home/flexlm/v5.12/hp700_u9/lmdiag -n -c\ /home/flexlm/v5.12/hp700_u9/license.dat >> \ /home/flexlm/v5.12/hp700_u9/boot.log' /bin/su daniel -c 'echo exiting >>\ /home/flexlm/v5.12/hp700_u9/boot.log'
Please note the following about how this script was written:
On IBM RS6000 systems, /etc/rc cannot be used, because TCP/IP is not installed when this script is run. Instead, /etc/inittab must be used. Add a line like this to /etc/inittab after the lines which start networking: rclocal:2:wait:/etc/rc.local > /dev/console 2>&1
This will not start the daemon until you reboot your license server machine.
From the Control Panel, use the FLEXlm License Manager to start lmgrd as a service. You can optionally indicate that this should be started at system startup.
Services are not supported on this platform. However, you can start v7+ lmgrd in the autoexec.bat. Be sure to start to give the full path to the lmgrd.exe, the vendor daemons must be in the path, and you must include -l logfile argument - otherwise, lmgrd attempts to put up console windows.
Most applications specify a location where they expect to find the license file. Many will automatically install the license. You should rarely, if ever, be required to specify where the license file is located with an environment variable. However, you can change the license location with $LM_LICENSE_FILE, or if a location is not provided by the location, you can set one.
Use the environment variable LM_LICENSE_FILE to set the location of the license file. For example in the C shell:
% setenv LM_LICENSE_FILE license_file_path
In the Korn and Bourne shells:
# LM_LICENSE_FILE=license_file_path # export LM_LICENSE_FILE
On Windows 3.1 and 95, add the following line to C:\autoexec.bat:
SET LM_LICENSE_FILE=license_file_path
On Windows NT, use the System Control Panel to change the global environment, adding LM_LICENSE_FILE to license_file_path,
In FLEXlm v6+, applications will accept an environment variable (or Windows Registry) named `VENDOR_LICENSE_FILE', where VENDOR is the vendor-daemon name, e.g., GSI_LICENSE_FILE.
With lmgrd and lmutil (lmstat, lmdown, etc.), the `-c' option overrides the setting of the LM_LICENSE_FILE environment variable for. See Section 3.1.3, `Using Separate License Files on the Same Server Node,' on page 27 for more information about LM_LICENSE_FILE.
Some applications do not recognize the LM_LICENSE_FILE environment variable.
See Also: Appendix C, `How to set environment variables' on page 65.
License files usually begin with a SERVER line (or three lines for redundant servers) followed by one or more DAEMON lines, followed by one or more FEATURE or INCREMENT lines. In some cases the license file requires no SERVER line and no DAEMON line. See Section 4.4, `Counted vs. Uncounted Licenses,' on page 33, for more information. Since FLEXlm v6.0, the DAEMON line can be called VENDOR. Wherever DAEMON appears, VENDOR can be used, if the lmgrd and vendor-daemon are both >= FLEXlm v6.0.
You can modify these data items in the license file:
Long lines normally use the `\' line continuation character to break up long lines (though this is not required with version 7 applications). FLEXlm version 2 did not support the line continuation character, although this rarely matters since optional attributes weren't support then either.
Everything else is used to compute the license key, and should be entered exactly as supplied by your software vendor. All data in the license file is case sensitive, unless otherwise indicated.
In the following sections, options modifiable by the license administrator are italicized.
The SERVER line specifies the node name and hostid of the license server, and the port number of the license manager daemon (lmgrd). Normally a license file has one SERVER line. Three SERVER lines mean that you are using redundant servers. The absence of a SERVER line means every FEATURE or INCREMENT line in the license file is uncounted. For more information about uncounted features, see Section 2.2.4, `FEATURE or INCREMENT Lines,' on page 15. License administrators do not have the option of deleting SERVER lines from a license file because the hostids from the SERVER lines are computed into the license keys on every FEATURE and INCREMENT line. For more information about redundant servers, see Chapter 4, `Selecting Server Nodes' on page 29.
The format of the SERVER line is:
SERVER nodename id port-number
Example:
SERVER enterprise 0122345 21987
The DAEMON line specifies the daemon name and path. lmgrd uses this line to start the vendor daemons, and the vendor daemon reads it to find the options file. The format of the DAEMON line is shown below.
Since FLEXlm v6.0, the DAEMON line can be called VENDOR. VENDOR can be used if the lmgrd and vendor-daemon are both at least FLEXlm v6.0.
{DAEMON|VENDOR} daemon_name [daemon_path] [[options=]options_path]\
[[port=]portnum]
Examples:
v6.0:
VENDOR sampled
pre-v6.0:
DAEMON sampled /usr/local/sampled /usr/local/flexlm/licenses/sampled.opt
USE_SERVER takes no arguments, and has no impact on the server. When the application sees USE_SERVER, it ignores everything in the license file except preceding SERVER lines, and the checkout validation occurs at the vendor daemon. USE_SERVER is recommended since it improves performance when a license server is used. For uncounted features, USE_SERVER can be used to force logging of usage by the daemons.
A FEATURE line describes the license to use a product. An INCREMENT line can be used in place of a FEATURE line, as well as to `incrementally' add licenses to a prior FEATURE or INCREMENT line in the license file.
Only the first FEATURE line for a given feature will be processed by the vendor daemon. If you want to have additional copies of the same feature (for example, to have multiple node locked counted features), then you must use multiple INCREMENT lines. INCREMENT lines form license groups based on the feature name, version, and node lock hostid. If the feature name, version, and node lock hostid (and optionally, the vendor string, if the vendor specified this) match a prior INCREMENT or FEATURE line, the new number of licenses is added to the old number. If any of the three do not match, a new group of licenses is created in the vendor daemon, and this group is counted independently from others with the same feature name (called a `license pool'). INCREMENT is not available for pre-v2.61 FLEXlm clients or servers. A FEATURE line does not give an additional number of licenses, whereas an INCREMENT line ALWAYS gives an additional number of licenses.
There is a rarely used option in FLEXlm which causes FEATURE lines to function as INCREMENT lines. This option is called ls_use_all_feature_lines. You will have to ask your vendor if they use this option. If they do, then all FEATURE lines behave exactly as INCREMENT lines.
A FEATURE line placed after another FEATURE or INCREMENT line will be ignored (unless ls_use_all_feature_lines is set).
The format for the FEATURE line changed in FLEXlm v3.0 and FLEXlm v6.0. The older formats are understood by new clients and servers, but the new formats are more flexible.
v2 format:
FEATURE|INCREMENT name vendor ver expdate #lic key `vendor_str' [hostid]
v3+ format:
FEATURE|INCREMENT name vendor version exp_date #lic key \
[HOSTID=hostid][VENDOR_STRING='vendor-string'] \
[vendor_info='...'] [dist_info='...'] [user_info='...'] \
[asset_info='...'] [ISSUER='...'] [NOTICE='...'] [ck=nnn] \
[OVERDRAFT=nnn] [DUP_GROUP=NONE|SITE|[UHDV]]
Nothing in a FEATURE/INCREMENT line is editable, except for values in the `name=value' pairs where name is all lowercase.
The following fields are all optional (except for vendor-string in the old format). For optional fields of the `name=value' syntax, if the name is lowercase, it can be modified and the license will remain valid.
DUP_GROUP=NONE|SITE|[UHDV]
U = DUP_USER
H = DUP_HOST
D = DUP_DISPLAY
V = DUP_VENDOR_DEF
The following attributes can be changed or deleted by end-users. This is indicated by a lowercase name.
FEATURE xyz_app xyzd 2.300 31-dec-1997 20 1234567890 `xyz'
INCREMENT f1 xyzd 1.000 1-jan-0 5 12345678901234567890 \
HOSTID=INTERNET=195.186.*.* NOTICE='Licensed to XYZ corp'
The FEATURESET line is a rarely used line to prevent FEATURE lines from being added to or removed from the license file. The format of the FEATURESET line is shown below.
FEATURESET daemon_name key
Nothing in a FEATURESET line can be edited. Use the FEATURESET line exactly as it comes from your vendor.
Example:
FEATURESET sampled 12345678
The purpose of the PACKAGE line is to support two different licensing needs:
A PACKAGE line, by itself, does not license anything - it requires a matching FEATURE/INCREMENT line to license the whole PACKAGE. A PACKAGE line can be shipped by your software vendor with a product, independent of any licenses. Later, when you purchase a license for that package, one or more corresponding FEATURE/INCREMENT licenses will enable the PACKAGE.
Example:
PACKAGE pkg_name vendor pkg_version pkg_key COMPONENTS=pkg_list \
[ OPTIONS=pkg_options ]
feature[:version[:num_lic]]
COMPONENTS='comp1 comp2 comp3 comp4'
COMPONENTS='comp1:1.5 comp2 comp3:2.0:4'
Examples
PACKAGE suite xyzd 1.0 3B24B2F508CB697641CC\
COMPONENTS='comp1 comp2' OPTIONS=SUITE
FEATURE suite xyzd 1.0 1-jan-0 5 4193E6ABCCCB1A3970B3
This is a typical SUITE example. There are 2 features: comp1 and comp2, which are each version 1.0, with 5, non-expiring licenses available. When comp1 or comp2 are checked out, `suite' will also be checked out.
PACKAGE suite xyzd 1.0 2CBF44FCB9C1E825DC5C COMPONENTS='c1:1.5:2\ c2:3.0:4'
FEATURE suite xyzd 1.0 1-jan-1999 3 321E78A17EC19AE81A43 SN=123
In this example, the component versions override the FEATURE versions, and the number of licenses available for any component is the product of the 3 licenses for suite and the number of licenses for that component. The result is equivalent to:
FEATURE c1 xyzd 1.5 1-jan-1999 6 0D3AD5F26BC868D476EC SN=123
FEATURE c2 xyzd 3.0 1-jan-1999 12 EB16C5AE4A4E0F2961F0 SN=123
With FLEXlm v6 (or later) applications only the PACKAGE lines can be stored in a separate file which need never be edited.
UPGRADE name daemon fromversion version exp_date #lic key \
`string' [hostid] ck=nnn
All the data is the same as for a FEATURE or INCREMENT line, with the addition of the fromversion field. An UPGRADE line removes up to the number of licenses specified from any old version (>= fromversion) and creates a new version with that same number of licenses.
For example, the two lines:
INCREMENT f1 xyzd 1.000 1-jan-1999 5 9BFAC03164EDB7BC0462 ``
UPGRADE f1 xyzd 1.000 2.000 1-jan-1999 2 1B9A30316207EC8CC0F7 ``
would result in 3 licenses of v1.0 of f1 and 2 licenses of v2.0 of f1.
UPGRADE will operate on the most recent FEATURE or INCREMENT line (i.e., closest preceding FEATURE or INCREMENT line) with a version number that is >= fromversion, and < version.
Note that UPGRADE does not work for node locked, uncounted licenses before version 6.
This is an example of a license file for a single vendor with two features.
SERVER excellent_server 17007ea8 1700
DAEMON xyzd /etc/xyzd
FEATURE xyz_app1 xyzd 1.000 01-jan-1999 10 1EF890030EABF324""
FEATURE xyz_app2 xyzd 1.000 01-jan-1999 10 0784561FE98BA073""
The license file above would allow the license server excellent_server with the hostid 17007ea8 to serve 10 floating licenses for xyz_app1 and xyz_app2 to any user on the network.
License files are created by the software vendor. License files can specify floating (concurrent) usage, node locked (both `counted' and `uncounted'), and any combination of floating, counted and uncounted.
A floating license means anyone on the network can use the licensed software, up to the limit specified in the license file. (Also referred to as concurrent usage or network licensing.) Floating licenses have no hostids on the individual FEATURE lines. Floating licenses requires an lmgrd and a vendor daemon to be running to count the concurrent usage of the licenses.
An example of a license file that provides floating licenses is:
SERVER lulu 17001234 1700
DAEMON xyzd /etc/xyzd
FEATURE f1 xyzd 1.00 1-jan-99 2 key1""
FEATURE f2 xyzd 1.00 1-jan-99 6 key2""
FEATURE f3 xyzd 1.00 1-jan-99 1 key3""
This license file specifies that two licenses for feature `f1', six licenses for feature `f2', and one license for feature `f3' are available anywhere on the network that can access the license server `lulu'.
Node locking means the licensed software can only be used on one node. A node locked license has a hostid on any FEATURE line that is node locked to a particular host. There are two types of node locked licenses; uncounted and counted.
If the number of licenses is set to 0, then the license is uncounted and unlimited use is permitted on the specified node. This configuration does not require an lmgrd or a vendor daemon because it is not going to count the concurrent usage of the features.
The following license file allows unlimited usage of feature `f1' on the nodes with hostids of 12001234 and 1700ab12:
FEATURE f1 xyzd 1.000 1-jan-99 0 key1"" 12001234
FEATURE f1 xyzd 1.000 1-jan-99 0 key2"" 1700ab12
Alternately, in FLEXlm v5.0 or later, these 2 FEATURE lines could have been issued by your software vendor with a hostid list:
FEATURE f1 xyzd 1.000 1-jan-99 0 key HOSTID='12001234 1700ab12'
If these were the only FEATURE lines in this license file, no lmgrd daemon would be necessary and you should not start one.
The following license file allows three licenses for feature `f1' to be run, but only on the node with hostid 1300ab43. (In this case, the daemons should be run on the same node that runs the software, since there is no reason to run the daemons on another node.)
SERVER lulu 1300ab43 1700
DAEMON xyzd /etc/xyzy
FEATURE f1 zyzd 1.00 1-jan-99 3 key"" 1300ab43
Uncounted node locked and concurrent usage licenses can be mixed in the same license file.
The following license file allows unlimited use of feature `f1' on nodes 17001111 and 17002222, while allowing two other licenses for feature `f1' to be used anywhere else on the network:
SERVER lulu 17001234 1700
DAEMON xyzd C:\flexlmyzd.exe
FEATURE f1 xyzd 1.00 1-jan-1999 0 key1"" 17001111
FEATURE f1 xyzd 1.00 1-jan-1999 0 key2"" 17002222
FEATURE f1 xyzd 1.00 1-jan-1999 2 key3""
This configuration requires an lmgrd and a vendor daemon because the concurrent usage of the two licenses on the third FEATURE line are counted.
The decimal format was introduced in v6. Users with older products can still use the decimal format, but they will require a copy of the lminstall command (which is part of lmutil). The lminstall utility allows the user to type in a decimal line, which is then converted to the readable format, and saved in the specified location. The mixed node-locked floating example above looks as follows in decimal format:
xyzd-f1-01761-55296-37046-04544-00017-06551-18072-57346-18754-136
xyzd-f1-01761-55296-37046-08896-00034-235
xyzd-f1-00481-55296-17590-2
A simple demo license in readable format
FEATURE f1 xyzd 1.00 1-jan-1999 0 key1 HOSTID=DEMO
converted to decimal:
xyzd-f1-00737-55296-1825
Note that by default lminstall converts to v6 format. It can convert to a format compatible with older versions by using lminstall -overfmt 2 (or 3, 4, 5 depending on the FLEXlm version).
In some cases, the ordering of lines in a license file can be crucial. Version 7 vendor daemons and clients automatically internally sort the lines so that in most cases the optimal result is achieved. For earlier versions of FLEXlm, note the following suggestions, which are all based on the fact the checkouts are attempted on lines in the order they appear in the license file:
Since more than 1500 vendors have chosen FLEXlm as their license manager, chances are good that you will have to administer licenses from more than one vendor or multiple products from the same vendor.
When you are running FLEXlm-licensed products from multiple vendors, you may need to take steps to prevent licensing conflicts during installation. There are three ways you can accomplish this:
Note that before version 6, each lmgrd could read only a single license file. In the first option mentioned above, you will have more license servers to monitor; in the third option you have only one server but multiple lmgrds to administer.
If all applications and vendor daemons are FLEXlm v6+, lmgrd can process multiple license files, even when the hostids are different, so long as they refer to the same node.
Your product's license file(s) define the license server(s) by hostname and hostid in the SERVER line(s) in the license file. If the license files for two or more products contain identical hostids on the SERVER line(s), then these files can be combined. If the license files for two products contain different hostids on a SERVER line, then the license servers for those products will be running on different nodes and the license files cannot be combined.
If you have two or more products whose license servers run on the same node (as specified by the SERVER lines in the license files), you may be able to combine the license files into a single license file. If the SERVER lines in those files have identical hostids, then you can combine the files into a single file. If the SERVER lines have different hostids, then you must keep the license files separate.
More precisely, you can combine two license files under the following conditions:
Some possible reasons license files may not be compatible are:
If your license files are compatible as described above, then you have the option of combining license files and running a single lmgrd, as described below in Section 3.1.1, `Combining License Files from Multiple Vendors,' on page 26. If the license files are not compatible, then you must keep the license files separate and run separate copies of lmgrd for each license file, as described in Section 3.1.3, `Using Separate License Files on the Same Server Node,' on page 27.
Note that you are not required to combine compatible license files; you always have the option of running separate lmgrds, and there is virtually no performance or system-load penalty for running separate lmgrd processes.
If your license files are compatible, you can combine them with any text editor. To combine license files, read all of the compatible license files into one file, then edit out the extra SERVER lines so that only one set of SERVER lines remains. Write out this data, and you have your combined license file. If you combine license files from multiple vendors, it is a good idea to keep a copy of the combined license file in each vendor's default license file location. This way, users can avoid having to set LM_LICENSE_FILE, because each package finds it's license information in the default place. On UNIX, you can do this with a symbolic link from each default location to the location of the combined license file.
When you combine license files for two different FLEXlm-licensed products, it may be the case that those products do not use the same version of FLEXlm. FLEXlm is designed to handle this situation. There are two basic compatibility rules for FLEXlm:
From these two compatibility rules come the simple rules for selecting which version of administration tools to use:
For specific application programs, you can use either the new or the old version (of course the vendor daemon for that application must be at least as new as the application itself).
You must run a separate copy of lmgrd for each license file. When you run multiple copies of lmgrd, there are two details to remember:
When running client programs (such as a licensed application), you can set the LM_LICENSE_FILE environment variable to point to multiple license files. For example, you may have a license file from vendor ABC and a license file from vendor XYZ with incompatible servers. You can place the license file from vendor ABC into:
/usr/flexlm/abc.dat
and the license file from vendor XYZ into:
/usr/flexlm/xyz.dat
then set the LM_LICENSE_FILE environment variable to point to both of them. Each name in LM_LICENSE_FILE should be separated by a colon (`:') on Unix systems, a semicolon (`;') on Windows and Windows/NT systems (in FLEXlm v4.1, a comma was used on Windows and NT), and a space ("") on VMS systems. In the C shell:
% setenv LM_LICENSE_FILE /usr/flexlm/abc.dat:/usr/flexlm/xyz.dat
In the Korn and Bourne shells:
# LM_LICENSE_FILE=/usr/flexlm/abc.dat:/usr/flexlm/xyz.dat # export LM_LICENSE_FILE
If products use different license server nodes, each set of license servers requires separate license files. (When multiple software vendors use the same set of license server nodes, the technique described above in Section 3.1, `Overview of Combining License Files,' on page 25 can be used to combine license files.) The resulting (multiple) license files can be installed in convenient locations. On Unix you would set the LM_LICENSE_FILE environment variable as follows:
% setenv LM_LICENSE_FILE lfpath1:lfpath2:....:lfpathN
Use a colon (":") to separate the license file names on Unix, on Windows and Windows/NT use a semicolon (";"), and on VMS use a space ("").
.
.
.
Each application queries each license file in the order it is listed in the LM_LICENSE_FILE path. If the license server serving the license file listed in lfpath1 is unreachable, the other files listed in LM_LICENSE_FILE allow a user to obtain a license from another server. lfpath can also be `port@host', using the port-number and hostname from the SERVER line in the license file.
This chapter helps you decide which nodes to use as license server nodes.
This section discusses the resources used by the license server. When you select a server node, you may need to take into account the system limits on these resources. For small numbers of licenses (under about 100), most of these items should not be a problem on any workstation.
When using TCP, a single vendor daemon can support as many users as the per-process system limit for file descriptors, which ranges from 256 on SunOS 4.x to 4000 on DEC Alpha. When no more file descriptors are available to a daemon, additional vendor daemons are spawned to allow for extra file descriptors, though this is not recommended. When using UDP, there is no limit to the number of end-users per vendor daemon process, since they can share a single socket in the vendor daemon (UDP has other drawbacks, and TCP is normally preferred). If there are more than 250 concurrent clients from a SunOS vendor daemon, it may be a good idea to move the server to a different OS, since all other OSs support more file descriptors. If there are more than 1000 concurrent clients being supported by a single vendor daemon, then it's probably good to split the license file into more than one file, from different servers, to lighten the networking traffic (which will require the ISV to agree to issue new licenses). Clients can checkout licenses from multiple servers using a license-file list via LM_LICENSE_FILE.
Each client connected to a license server uses one socket. The total number of sockets used by the license server programs is slightly larger than the total number of simultaneous clients.
On older SCO systems, the default number of sockets may be set fairly low; if you choose to run a server on such a machine, you may need to reconfigure your kernel to have more sockets.
The number of sockets available for clients is about 60. In general, NT is preferred for server systems, where there is no such limit, and the operating system is better designed for server processes.
For small numbers of clients, the license servers use very little CPU time. The servers might have only a few seconds of CPU time after many days.
For a large number of clients (who are each exchanging heartbeat messages with the server), or for high checkout/checkin activity levels (hundreds per second), the amount of CPU time consumed by the server may start to become significant although, even here, CPU usage is normally not high. In this case, you may need to ensure that the server machine you select will have enough CPU cycles to spare.
GLOBEtrotter Software has rarely encountered a situation where CPU cycles were an issue.
The only output files created by the license servers are the debug and report log files. The report log files are used to generate accurate usage reports by FLEXadmin. These log files contain one line for each checkout and one line for each checkin. If you have a lot of license activity, these log files will grow very large. You will need to consider where to put these files and how often to delete or prune them. The license administrator can opt not to log messages to the debug log file if disk space is at a premium. See Section 5.2.10, `NOLOG,' on page 39 and Section 5.2.11, `REPORTLOG,' on page 39.
Note that the log files should be local files on the server machine(s) to avoid networking dependencies.
On Unix, the debug log file output can be switched after the daemons are running. The technique to do this involves piping the stdout of lmgrd to a shell script that appends to the file for each line.
This is done as follows:
Instead of the `normal' startup:
% lmgrd> LOG
Start lmgrd this way:
% lmgrd | sh -c 'while read line; do echo"$line" >> LOG ; done'
With this startup method, the output file `LOG' can be renamed and a new log file will be created. You could even make `LOG' a symbolic link and change the value of the link to switch the log file.
This technique applies to Unix systems only.
The FLEXlm daemons use little memory. On SunOS, lmgrd uses approximately160 kB and the vendor daemons use approximately 180 kB each, although memory usage increases in the vendor daemon with the size of the license file and the number of concurrent users.
FLEXlm sends relatively small amounts of data across the network. Each transaction, such as a checkout or checkin, is typically satisfied with less than 1Kbyte of data transferred. This means that FLEXlm licensing can be effectively run over slow networks (such as dial-up SLIP lines) for small numbers of clients.
For a large number of clients (hundreds), each of which will be exchanging heartbeat messages with the vendor daemon, the network bandwidth used may start to become significant. In this case you should run client and server on the same local area network, which may require splitting licenses between 2 files for 2 servers. Users can use a license file list in LM_LICENSE_FILE to have effective access to both servers.
In high-traffic networks, with FLEXlm clients older than v5, you may also want to avoid setting LM_LICENSE_FILE to a port@host address. Instead, the license administrator should place a copy of the license file in a filesystem local to the application. See Section 2.1, `Specifying Location of the License File,' on page 9.
GLOBEtrotter Software recommends that you do not use remote mounted disks when you run the license server. In other words, we recommend that lmgrd, the vendor daemons, the license file, and the debug and report log files are all on locally mounted disks. If any of these files is on a remote mounted disk, you double the points of failure which could lead to a temporary loss of all of your licenses. When all files are mounted locally, the licenses will be available as long as the server machine is up; but when the files are on a different machine, then the loss of either the license server machine or the file server machine will cause the licenses to be unavailable.
FLEXlm supports two methods of redundancy: A set of three redundant license servers, and redundancy via a license file list in the $LM_LICENSE_FILE setting.
With three-server redundancy, if any two of the three license servers are up and running, the system is functional and hands out its total complement of licenses (Two out of three license servers is referred to as a `quorum').
With $LM_LICENSE_FILE list redundancy, each one of a group of license servers serves a subset of the total licenses. The end-user sets LM_LICENSE_FILE to a list of license files, where each license file refers to one of the license servers. The application then tries each server in the list, in order, until it succeeds or gets to the end of the list.
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. The three server nodes can be any supported server nodes - it is not required that they be the same architecture or operating system.
Three-server redundancy does not provide load-balancing. Use $LM_LICENSE_FILE list instead for this type of redundancy. This is because with three-server redundancy, only one of the three servers is `master', capable of issuing licenses. Since all clients must contact the `master', all clients must have reliable networking to a single node.
These three-server redundant servers should have excellent communications, and should be on the same subnet. Often this means that the three-servers should be located physically close to each other. This form of redundancy requires that the servers exchange heartbeats periodically, and poor communications can cause poor performance. You should never configure redundant servers with slow communications or dialup links.
This is best explained by example. If 10 licenses are desired for both f1 and f2, the ISV would issue 2 sets of licenses with a count of 5 for each of f1 and f2. The server nodes (unlike three-server redundancy) can be physically distant. The license files would look like:
SERVER chicago 17007ea8 1700
DAEMON xyzd /etc/mydaemon
FEATURE f1 xyzd 1.000 01-jan-99 5 26C7DD9CD665B8270186""
FEATURE f2 xyzd 1.000 01-jan-99 5 0739D2F78CE46C57041D""
SERVER tokyo 17007ea8 1700
DAEMON xyzd /etc/mydaemon
FEATURE f1 xyzd 1.000 01-jan-99 5 16BE40E1DAEEEDA8798D""
FEATURE f2 xyzd 1.000 01-jan-99 5 6DB6F3E40E61885712DF""
The user in Chicago could set $LM_LICENSE_FILE to
1700@chicago:1700@tokyo
the user in Tokyo could set $LM_LICENSE_FILE to
1700@tokyo:1700@chicago
The application attempts the first server in the list, and if that fails for any reason, the second server is tried.
Yes. By default, once a license job has successfully checked out a license from one host, all subsequent checkouts must be satisfied from the same host. If the application requires more than one FEATURE, this could result in a license denial when the license is available on another server. An application can bypass this restriction if it is coded with the use of multiple FLEXlm license jobs. Only your application vendor can tell you if their application is programmed in this manner.
If the application supports license queueing, all licenses are only queued from the first host on the list.
Finally, if one server becomes unavailable, some licenses will be unavailable.
The license file determines whether a license server is needed. If all the FEATURE (or INCREMENT) lines have a license-count of 0 (unlimited) or `uncounted' (FLEXlm v6 or later only), then no server is needed. This type of license is called uncounted. Alternatively, if any FEATURE lines have a non-zero license-count, then a server is required to count those licenses. If a vendor wants to use FLEXlm without a server, they must issue uncounted licenses.
With FLEXlm v5 or later, the license server can serve uncounted licenses as well. This is done so that the REPORTLOG file will include transactions for all license requests, which can then be reported on by FLEXadmin. To do this, include a SERVER line in the license file, and put the USE_SERVER line immediately after the SERVER line. The vendor daemon will service the uncounted licenses, and the USE_SERVER line indicates to applications that they will be authorized by the server.
The options file allows the license administrator to control various operating parameters of FLEXlm. Specifically the license administrator can:
Options files allow you, as the license administrator, to be as secure or open with licenses as you like.
Lines in the options file were limited to 200 characters prior to FLEXlm v3.0. In v3.0 and later, the line length is 2048 characters. FLEXlm v4.0 allows the `\' character as a continuation character in options file lines.
To create an options file:
/usr/local/flexlm/options/xyz.opt (Unix)
C:\flexlm\optionsyz.opt (Windows/NT)
DAEMON xyzd /etc/xyzd /usr/local/flexlm/options/xyz.opt
Below is an overview of the options file syntax. See Section 5.4, `Understanding Options Files,' on page 41 for examples and additional information.
Each line of the file controls one option. The options are:
You can include comments in your options file by starting each comment line with a pound sign `#'. Everything in an options file is case sensitive. Be sure that user names and feature names, for example, are entered correctly.
Starting with FLEXlm v5, you can select a particular line of a given featurename, as follows:
featurename:name=value
For example:
f1:VERSION=2.0
You can specify a feature by any of the following fields:
VERSION HOSTID EXPDATE KEY VENDOR_STRING ISSUER NOTICE dist_info user_info asset_info
In FLEXlm v5.11 or later, you can use a PACKAGE name in place of a feature name, and the option will apply to the whole package.
EXCLUDE featurename type name
Excludes a user, host, display, or group from the list of who is allowed to use the feature. Excluded users will not be allowed to use the feature.
To exclude the user `hank' from the list of users able to use feature f1:
EXCLUDE f1 USER hank
EXCLUDEALL type name
Excludes a user, host, display, or group from the list of who is allowed to use all features served by this vendor daemon.
To exclude any user on the machine `chaos' from using all features served by this vendor daemon:
EXCLUDEALL HOST chaos
GROUP groupname usernamelist
Defines a group of users for use in INCLUDE, INCLUDEALL, EXCLUDE, EXCLUDEALL, and RESERVE option lines.
To define the group Hackers consisting of bob, howard, and james:
GROUP Hackers bob howard james
In FLEXlm v3.0 multiple GROUP lines will add all the users specified into the group. Pre-v3.0 FLEXlm daemons do not allow multiple GROUP lines to concatenate. In fact, the second GROUP line would re-define the GROUP.
In FLEXlm v4.0 or later, USER_GROUP is an alias for GROUP.
HOST_GROUP groupname hostnamelist
Defines a group of hosts for use in INCLUDE, INCLUDEALL, EXCLUDE, EXCLUDEALL, and RESERVE option lines.
INCLUDE featurename type name
Includes a user, host, display, or group in the list of who is allowed to use the feature. Anyone not in an INCLUDE statement will not be allowed to use that feature.
To include user `bob' in the list of users able to use feature f1:
INCLUDE f1 USER bob
INCLUDE is required for USER_BASED or HOST_BASED features. The system administrator specifies which users are allowed to use the product, via INCLUDE, and the license limits the number of users that can be INCLUDEd.
INCLUDEALL type name
Includes a user, host, display, or group in the list of who is allowed to use all features served by this vendor daemon. Anyone not in an INCLUDEALL statement will not be allowed to use these features.
To allow the user `jane' to use all features served by this vendor daemon:
INCLUDEALL USER jane
LINGER featurename interval
Rarely used. This causes the daemon to `hold on' to the license for featurename for interval seconds after the application checks the license in or exits. This could be useful for short-duration programs which will be used many times in a row by the same user, to ensure that the user will be able to re-acquire the license repeatedly. On the other hand, other users have to wait until the first user is completely finished, plus a linger interval. This is only useful if the application uses duplicate grouping. Otherwise, LINGER will cause you to use extra licenses. Contact your software vendor for information about how they implemented duplicate grouping in their product.
(v5.11+ vendor daemon only).
MAX numlic featurename type name
Limits usage for a group or user.
MAX_OVERDRAFT featurename numlic
Limits usage below the OVERDRAFT allowed by the license file.
NOLOG what
Turns off logging of specific events by the FLEXlm daemons.
To turn off logging of checkins:
NOLOG IN
To turn off logging of checkouts and queued requests two separate NOLOG lines are required:
NOLOG DENIED
NOLOG QUEUED
License administrators might use this option to reduce the size of the lmgrd or `debug' log file.
REPORTLOG filename
REPORTLOG specifies the file which will contain the report-writer log for this vendor daemon. If filename begins with a '+' character, the file will be opened for append, otherwise the file will be overwritten each time the daemon is started. FLEXadmin', a separate product available from Globetrotter, can be used to read and report on REPORTLOG files.
This file is only useful with the FLEXadmin license administration utility.
The FLEXadmin report writer can report on `projects.' A project is set up by having all users working on a project set their LM_PROJECT environment variable (or registry on Windows) to a string that describes the project. FLEXadmin can then group usage by project, as defined by what LM_PROJECT was set to when the application was run.
RESERVE numlic featurename type name
Reserves licenses for a specific user.
To reserve one license of feature f1 for user `mel':
RESERVE 1 f1 USER mel
Any licenses reserved for a user are dedicated to that user. Even when that user is not actively using the license it will be unavailable to other users. However, a RESERVED license will not cause an overdraft to be reported by FLEXadmin if the license is not actually in use.
TIMEOUT featurename seconds
Sets the time after which an inactive license is reclaimed by the vendor daemon.
To set the timeout for feature f1 to one hour (3600 seconds):
TIMEOUT f1 3600
TIMEOUT checks in the licenses if the process has been `idle' for a period longer than the specified time period, and someone else wants the license. The daemon declares a process idle when it has not heard from the process (the client sends heartbeats). The application must explicitly declare itself idle for this to work, or (on Unix) the application must be stopped (^Z). That is, unless the application explicitly supports this feature, it will not work. Contact your software vendor for information about how they implemented this feature in their product.
The application vendor can also disable the timeout feature, in which case the TIMEOUT option has no effect. The vendor can set a minimum value for the timeout. If you specify a timeout value smaller than the minimum, the minimum is used. The default minimum value is 900 seconds (15 minutes).
If you do not specify a timeout value in your options file, then there will be no timeout for that feature. With a pre-v5 vendor daemon, licenses are only freed by TIMEOUT when a new request for a license would require a license that can be freed with TIMEOUT. With v5, licenses are freed when they time out.
(v5.11+ vendor daemon only)
TIMEOUTALL seconds
Same as TIMEOUT, but applies to all features.
The following information gives an overview of the syntax of a complete options file, and some samples intended to illustrate ways to effectively control access to your licenses.
When the vendor daemon is started by lmgrd, it is passed the location of the options file. If you modify the options file while the server is running, you must use lmreread to have the vendor daemon reread the options file (though pre-v7 vendor daemons do not support this and require that the server be stopped and restarted). There can only be one options file per vendor daemon and each vendor needs a separate options file.
Before you can use options to utilize licenses effectively you must understand the options file precedence. INCLUDE and EXCLUDE statements can be combined in the same options file and control access to the same features. When doing so, keep in mind the following:
Once you create an INCLUDE or EXCLUDE list everyone else is implicitly `outside' the group. This feature allows you, as an administrator, the ability to control licenses without having to explicitly list each user that you wish to allow or deny access to. In other words there are two approaches; you can either:
RESERVE 1 compile USER robert
RESERVE 3 compile HOST mainline
EXCLUDE compile USER lori
NOLOG QUEUED
This options file would:
The sum total of the licenses reserved must be less than or equal to the number of licenses specified in the FEATURE line. In the example above, there must be a minimum of four licenses on the `compile' FEATURE line. If fewer licenses are available, only the first set of reservations (up to the license limit) is used.
If this data were in file /usr/local/flexlm/options/local.options, then you would modify the license file DAEMON line as follows:
DAEMON xyzd /usr/local/xyzd /usr/local/flexlm/options/local.options
Each INCLUDE, INCLUDEALL, EXCLUDE, EXCLUDEALL, and RESERVE line must have a single user name (or group) listed. To affect more than one user name create a GROUP. For example to exclude `bob,' `howard,' and `james' from using the feature called `toothbrush' we could create the following options file:
EXCLUDE toothbrush USER bob
EXCLUDE toothbrush USER howard
EXCLUDE toothbrush USER james
There is an easier way though. Create a GROUP and exclude the list of users from using the feature. Like the previous example, the following options file would exclude `bob', `howard' and `james' from using the feature called `toothbrush':
# First define the group"Hackers"
GROUP Hackers bob howard james
# Then exclude the group
EXCLUDE toothbrush GROUP Hackers
Now when you want to allow or deny access to any feature to that group, you have an `alias' list to make it simple.
The GROUP function works for a list of user names prior to FLEXlm v4.0. To control access to multiple displays (and hosts in pre-v4.0 FLEXlm) you must use multiple option lines in your options file. For example, in pre-v4.0 FLEXlm to exclude all users logged in on the hosts `fred' and `barney' from using a feature called `f1' add these lines to your options file:
EXCLUDE f1 USER fred
EXCLUDE f1 USER barney
With a FLEXlm v4+ vendor daemon, you can use HOST_GROUP to allow, deny or reserve licenses for multiple hosts. For example, to exclude all users logged in on the hosts `fred' and `barney' from using a feature called `f1' add these lines to your options file:
HOST_GROUP writers fred barney
EXCLUDE f1 HOST_GROUP writers
See Section 5.2.3, `GROUP' and Section 5.2.4, `HOST_GROUP,' on page 37 for more information about defining groups.
#First Define the group"painters"
GROUP painters picasso mondrian klee
EXCLUDE spell GROUP painters
EXCLUDE spell USER bob
EXCLUDE spell INTERNET 123.123.123.*
This options file would:
Note that `bob' could have been added to the group painters. However, `painters' might be used for some other purpose in the future so the license administrator chose to handle `bob' as a special case here. In this case, the two EXCLUDE statements concatenate to create a list of four users.
INCLUDE paint USER picasso
INCLUDE paint USER mondrain
INCLUDE paint HOST bigbrush
This options file would:
FLEXlm provides utilities for the license administrator to help manage the licensing activities on the network. These utilities are:
Beginning in FLEXlm v2.4, all FLEXlm utility programs (except lmgrd) are packaged as a single executable called lmutil. lmutil can either be installed as the individual commands (either by creating links to the individual command names, or making copies of lmutil as the individual command names), or the commands can be run as `lmutil command', e.g. `lmutil lmstat', or `lmutil lmdown'. On Windows or Windows/NT systems, the `lmutil command_name' form of the commands are available. There is also a Windows version of these commands - see Section 6.12.1, `License Administration Tools - LMTOOLS for Windows,' on page 53.
The lmcksum program (FLEXlm v2.4 or later) will perform a checksum of a license file. This is useful to verify data entry errors at your location. lmcksum will print a line-by-line checksum for the file as well as an overall file checksum. lmcksum takes the `-k' switch to force the encryption key checksum to be case-sensitive.
lmcksum will ignore all fields that do not enter into the encryption key computation; thus the server node name and port number, as well as the daemon pathname and options file names are not checksummed. In addition, lmcksum will treat non-case sensitive fields correctly (in general, lmcksum is not case-sensitive).
lmcksum takes an optional daemon name; if specified, only license file lines for the selected daemon are used to compute the checksums.
For FEATURE lines that contain ck=nnn, lmcksum prints simply OK or BAD.
Usage is:
lmcksum [-c license_file]
Example output is:
lmcksum - Copyright (C) 1989, 1997 GLOBEtrotter Software, Inc. lmcksum: using license file"/usr/local/flexlm/licenses/license.dat" 189: SERVER speedy 08002b32b161 2837 166: DAEMON xyzd C:\flexlmyzd.exe 8: FEATURE f1 xyzd 1.000 01-jan-99 0 3B2BC33CE4E1B8F3A0BF"" OK: 231: FEATURE f2 xyzd 1.0 01-jan-0 1 8B1C30015351B7737F5E \ DUP_GROUP=HD ck=231 109: (overall file checksum)
lmdiag (FLEXlm v4.0 or later) allows you to diagnose problems when you cannot check out a license.
Usage is:
lmdiag [-c license_file] [-n] [feature]
If no feature is specified, lmdiag will operate on all features in the license file(s) in your path. lmdiag will first print information about the license, then attempt to check out each license. If the checkout succeeds, lmdiag will indicate this. If the checkout fails, lmdiag will give you the reason for the failure. If the checkout fails because lmdiag cannot connect to the license server, then you have the option of running `extended connection diagnostics'.
These extended diagnostics attempt to connect to each port on the license server node, and can detect if the port number in the license file is incorrect. lmdiag will indicate each port number that is listening, and if it is an lmgrd process, lmdiag will indicate this as well. If lmdiag finds the vendor daemon for the feature being tested, then it will indicate the correct port number for the license file to correct the problem.
See Also: Appendix B, `FLEXLM_DIAGNOSTICS' on page 60.
The lmdown utility allows for the graceful shutdown of all license daemons (both lmgrd and all vendor daemons) on all nodes.
Usage is:
lmdown [-c license_file] [-vendor name] [-q] [-all]
You may want to protect the execution of lmdown, since shutting down the servers causes users to lose their licenses. See the `-p' or the `-x' options in Section 6.4, `lmgrd,' on page 48 for details about securing access to lmdown.
If lmdown encounters more than one server (for example if -c specifies a directory with many *.lic files) a choice of servers to shutdown is presented.
To stop and restart a single vendor daemon, use lmdown -vendor name, then use lmreread -vendor name, which restarts the vendor daemon.
When shutting down redundant servers, there is a one-minute delay before the servers shut down. Do not use `kill -9' to shut down the license servers.
See Also: Section 6.8, `lmreread,' on page 51.
lmgrd is the main daemon program for FLEXlm. When you invoke lmgrd, it looks for the license file which contains the information about vendors and features. On Unix systems, it is strongly recommended that lmgrd be run as a non-privileged user (not root).
Usage is:
lmgrd [ -c license_file ] [ -l logfile ] [ -s timestamp_interval ] [ -2 -p ] [ -x lmdown ] [ -x lmremove ] [ -z ] [ -v ]
Pre-v6 lmgrd on Windows required `-app' argument when not run as a service.
The lmhostid utility reports the hostid of a system.
Usage is:
lmhostid [-n]
[-vsn] [-flexid] Windows
[-ether] HP
The output of this command looks as follows:
lmhostid - Copyright (c) 1989, 1997 Globetrotter Software, Inc. The FLEXlm hostid of this machine is"69021c89"
With the `-n' argument, no header is printed; only the hostid.
On Windows and HP, optional hostids are available
See A.1, `Hostids for FLEXlm-Supported Machines'.
Introduced in v6.0, lminstall is designed primarily for typing in decimal format licenses to generate a readable format license file.
Usage is:
lminstall [-i {infile | -}] [-o outfile] \
[-overfmt {2 | 3 | 4 | 5 | 5.1 | 6}] [-odecimal]
Normally, lminstall is used with no arguments; you are prompted for the name of the output license file. The default name is today's date in yyyyddmm.lic format. The file should be moved to the application's default license file directory, if specified by the software vendor. Otherwise, use LM_LICENSE_FILE or VENDOR_LICENSE_FILE to specify the directory where the *.lic files are located.
Decimal format input is verified by checksum of each line.
To finish entering, type `q' on a line by itself, or enter 2 blank lines.
If infile is a dash ('-'), it takes input from stdin.When '-i' is used, default output is stdout; otherwise if -o is not specified, lminstall prompts the user for an output file name.
lminstall can alternatively be used to convert licenses between decimal and readable format, and between different versions of FLEXlm license formats.
To convert from readable to decimal:
% lminstall -i infile -o outfile -odecimal
To convert to FLEXlm Version 2 format:
% lminstall -i infile -o outfile -verfmt 2
Conversion errors are reported as necessary. lminstall has a limit of 1000 lines of input.
The lmremove utility allows you to remove a single user's license for a specified feature. This is only needed when a client node crashes, since that's the only condition where a license is not automatically freed. If the application is active, it will re-checkout the license after it is freed by lmremove.
Usage is:
lmremove [ -c file ] feature user host display
or
lmremove [ -c file ] -h feature host port handle
The user host display port and handle information must be obtained from the output of lmstat -a.
lmremove removes all instances of user on host on display from usage of feature. If the optional `-c file' is specified, the indicated file is used as the license file.You should protect the execution of lmremove, since removing a user's license can be disruptive. See the `-p' or the `-x' options in Section 6.4, `lmgrd,' on page 48 for details about securing access to lmremove.
The -h variation uses the serverhost, port, and license handle, as reported by lmstat -a. Consider this example lmstat -a output:
joe cloud7 /dev/ttyp5 (v1.000) (cloud9/7654 102), start Fri 10/29 18:40
In this example, the serverhost is `cloud9', the port is `7654' and the license handle is 102. To remove this license, issue the following command:
lmremove -h f1 cloud9 7654 102
or
lmremove f1 joe cloud7 /dev/ttyp5
When removing by handle, if licenses are grouped as duplicates, all duplicate licenses will also be removed.
The lmreread utility causes the license daemon to reread the license file and start any new vendor daemons that have been added. In addition, all running daemons will be signaled to reread the license file for changes in feature licensing information. Version 7+ vendor daemons will also reread the options file.
Usage is:
lmreread [-c license_file] [-vendor name] [-all]
The license administrator may want to protect the execution of lmreread. See the `-p' and `-x' options in Section 6.4, `lmgrd,' on page 48 for details about securing access to lmreread.
To stop and restart a single vendor daemon, use lmdown -vendor name, then use lmreread -vendor name, which restarts the vendor daemon.
If you use the `-c' option, the license file specified will be read by lmreread, not by lmgrd; lmgrd rereads the file it read originally. Also, lmreread cannot be used to change server node names or port numbers.
Vendor daemons older than version 7 will not reread their option files as a result of lmreread.
The lmstat utility helps you monitor the status of all network licensing activities.
Usage is:
lmstat [-a] [ -A ] [-c license_file] [-f feature] [-i [feature]] [-S vendor] [-s hostname] [-t value]
The lmswitchr utility switches the report writer (REPORTLOG) log file. It will also start a new REPORTLOG file if one does not already exist.
Usage is:
lmswitchr [-c license_file] feature new-file lmswitchr [-c license_file] vendor new-file [v5.0+ vendor daemon only]
lmswitchr does not work with FLEXlm v3.0 vendor daemons. Ask your vendor for a later version of their vendor daemon.
The lmver utility reports the FLEXlm version of a library or binary file.
Usage is:
lmver filename
For example if you have an application called `spell' type:
% lmver spell
Alternatively, on Unix systems, you can use the following commands to get the FLEXlm version of a binary:
strings file | grep Copy
For the 32 Bit Windows Platforms, an LMTOOLS.EXE Windows program is provided. It has the same functionality as listed in the previous sections but is graphically-oriented. Simply run the program and choose a button for the functionality required. Refer to the previous sections for information about the options of each feature. The command line interface is replaced by pop-up dialogs that can be filled out. The central EDIT field is where the license file path is placed. This will be used for all other functions and replaces the `-c license_file' argument in lmutil.
The HOSTID button displays the hostid's for the computer on which the program is running. The TIME button prints out the system's internal time settings, intended to diagnose any time zone problems. The TCP Settings button is intended to fix a bug in the Microsoft TCP protocol stack which has a symptom of very slow connections to computers. After pressing this button, the system will need to be rebooted for the settings to become effective.
The FLEXlm control panel, FLEXLM.CPL, is an applet that installs into the Control Panel of Windows and is used to control the execution of the FLEXlm license manager. If the software you are installing includes the Control Panel, it will be installed in your Windows System Directory.
The library LMGR325B.DLL needs to be available for FLEXLM.CPL. In this example it is placed in the same directory, but it could be placed anywhere in the system search path.
lmgrd.exe can be run manually or using the Control Panel. FLEXlm for Windows comes with a Control Panel applet for controlling lmgrd.exe without using the DOS prompt.
To start the
FLEXlm Control Panel, open the Control Panel and double-click on the
FLEXlm License Manager icon.
From the Control tab you can start, stop, and check the status of your license server.
Select the Setup tab to enter information about your license server.
The Service Name of `FLEXlm License Manager' is the default (for backwards compatibility). You should change this to a name that your vendor recommends. Complete the form to configure lmgrd to serve licenses.
The information you enter is stored in the registry under the service name you created:
HKEY_LOCAL_MACHINE\SOFTWARE\FLEXlm License Manager\Service-Name\...
Select the Control tab and click the Start button to turn on your license server. lmgrd.exe will be launched as a background application with the license file and debug log file locations passed as parameters.
If you want lmgrd.exe to start automatically, select the `Use NT Services' box and lmgrd.exe will be installed as an NT service. You can then use the NT's Services control panel to adjust the start/stop behavior of lmgrd.exe. Since NT services do not have command line parameters, lmgrd.exe, when started as a service, locates its service name under `FLEXlm License Manager' in the registry and from there recovers the license file and log file locations. Multiple instances of lmgrd.exe can be run as services provided each occurrence has a different service name.
You can switch back and forth between different instances of lmgrd.exe by using the Setup tab and changing the selection in `Service Name'. This is only necessary if you have more than one product licensed with FLEXlm.
The remaining tabs in the control panel allow you a subset of control similar to the LMUTIL.EXE program. The Licenses tab provides information about the license file and the Advanced tab allows you to perform diagnostics and check versions.
The behavior of the control panel applet FLEXLM.CPL is almost identical under Windows 95 and NT. FLEXLM.CPL is located in the Windows\System directory. If you are starting lmgrd.exe manually from the Control tab, there is no difference between the two. But, since services are not available on Windows 95, the Use NT Service check box is not available. Instead a Start Server at Power-UP check box gives you the option to start the server when the system is booted.
On Windows 95, FLEXlm makes use of a registry feature that launches programs automatically. The `Microsoft\Windows\CurrentVersion\RunServices' registry is used to launch the program LMGRD95.EXE at power-on. This program scans the `FLEXlm License Manager' area of the registry and launches an instance of lmgrd.exe for each service-name it finds.
If someone switches users (i.e. selects `shutdown' and chooses `close all programs and log on as a different user') on Windows 95, all instances of lmgrd.exe will be terminated (see Microsoft documentation). This is one of the reasons we do not recommend using Windows 95 as a license server.
FLEXlm uses different machine identifications for different machine architectures. For example, all Sun Microsystems, Inc. machines have a unique hostid, whereas all DEC machines do not. For this reason, the ethernet address is used on some machine architectures as the `hostid'. An ethernet address is a 6-byte quantity, with each byte specified as two hexadecimal digits. Specify all 12 hex digits when using an ethernet address as a hostid. For example, if the ethernet address is 8:0:20:0:5:ac, you would specify `0800200005ac' as the hostid.
The program lmhostid will print the exact hostid that FLEXlm expects to use on any given machine. The following table lists alternate methods to obtain the required hostid for each machine architecture
Numeric, 32-bit hostids are normally used in hexadecimal format. On some systems, including HP and SGI, the system command returns the number in decimal format. Since v3.0 of FLEXlm, a '#' before the hostid, indicates to FLEXlm that this is a decimal number. For example, if the HP uname -i command returns `2005771344', FLEXlm will accept `#2005771344'. Or it can be converted to hexadecimal. On Unix system, you can convert to hex with the following script:
% echo 2005771344 16o p | dc
778DA450
| AIX (RS/6000, PPC) | 32-bit hostid | uname -m (returns 000276513100), then remove last 2 digits, and use remaining last 8 digits | 02765131 |
| DEC Alpha | ethernet address | netstat -i | 080020005532 |
| HP | 32-bit hostid | uname -i and convert to hex, or prepend with # | 778DA450 or #2005771344 |
| ethernet address | lanscan (station address without leading `0x') | 0000F0050185 | |
| Linux | ethernet address | /sbin/ifconfig eth0 and remove colons from HWaddr 00:40:05:16:E5:25 | 00400516E525 |
| SCO | Hostid String | uname -x (Serial is SCO00354), then prefix with `ID_STRING=' | ID_STRING=SCO00354 |
| SGI | 32-bit hostid | /etc/sysinfo -s, convert to hex, or prefix '#' | 69064C3C or #1762020412 |
| SUN | 32-bit hostid | hostid | 170a3472 |
| VAX/VMSAlpha/OpenVMS | ethernet address | ncp | 0800200055327 |
| Windows | ethernet | lmutil lmhostid | 0800200055327 |
| Disk serial number | DIR C: (look for `Volume Serial Number is', and remove `-') | DISK_SERIAL_NUM= 1CA25283 | |
| Dongle - parallel port hardware key | lmhostid -flexid | FLEXID=72850003 |
This appendix documents areas of FLEXlm that have given customers difficulty in the past. We hope it helps you debug any problems you might experience at your site.
The following are tips for debugging:
When you talk to a support person, you should be prepared to answer the following questions:
strings program | grep CopyAlternatively, lmgrd -v gives the lmgrd version, and this works with the vendor daemon also.
server xyz started for: feature1 feature2.
Available only with applications using FLEXlm v4.1 or higher for Unix, and v5.0 or higher with Windows. Also, applications may choose not to provide this functionality.
FLEXLM_DIAGNOSTICS is an environment variable that will cause the application to produce diagnostic information when a checkout is denied. The format of the diagnostic information may change over time.
To set FLEXLM_DIAGNOSTICS, on Unix:
(csh): % setenv FLEXLM_DIAGNOSTICS 1
(sh): $ FLEXLM_DIAGNOSTICS=1; export FLEXLM_DIAGNOSTICS
On Windows 3.1 and 95, add the following line to C:\autoexec.bat:
SET FLEXLM_DIAGNOSTICS=1
On NT, use the System Control Panel applet to change the global environment, adding FLEXLM_DIAGNOSTICS to 1.
On Unix, the diagnostic output goes to stderr.
On Windows, if the application is v5.11 or higher, the output is a file in the current directory called flexnnn.log, where nnn is the application's process ID. If the application is v5.0, the output file is called flex_err.log.
If FLEXLM_DIAGNOSTICS is set to 1, then the standard FLEXlm error message will be presented, plus a complete list of license files that the application tried to use. For example:
% setenv FLEXLM_DIAGNOSTICS 1 FLEXlm checkout error: Cannot find license file (-1,73:2) No such file or directory license file(s): /usr/myproduct/licenses/testing.dat license.dat
If FLEXLM_DIAGNOSTICS is set to 2, then, in addition to level 1 output, the checkout arguments are presented. For example:
% setenv FLEXLM_DIAGNOSTICS 2
FLEXlm checkout error: No such feature exists (-5,116:2) No such file or directory
license file(s): /usr/myproduct/licenses/testing.dat license.dat
lm_checkout("f1", 1.0, 1, 0x0, ..., 0x4000)
Note that the error message actually contains 2 separate problems, which both occurred during the checkout: there's no such feature in the license it did find, and it was unable to find the other license file, which is what produces the message `No such file or directory'.
Following is a description of the arguments to lm_checkout()
lm_checkout(feature_name, version, nlic, queue_flag, ..., dupgroup_mask)
If FLEXLM_DIAGNOSTICS is set to 3, then, in addition to level 1 and 2 output, if a checkout is successful, information is printed explaining how the license was granted:
% setenv FLEXLM_DIAGNOSTICS 3 % application Checkout succeeded: f0/14263EAEA8E0 License file: ./servtest.lic No server used % application2 Checkout succeeded: f1/BC64A7B120AE License file: @localhost License Server: @localhost % application3 Checkout succeeded: f1/BC64A7B120AE License file: servtest.lic License Server: @speedy
Note that the feature name and license key are printed, along with the license file location (or hostname if @host were used) and hostname of the server, where applicable.
Each problem is presented in three parts:
A description of the problem.
A discussion of what causes the problem described in the `Symptom' section.
Instructions on how to solve the problem.
You can scan through the list of problems to find any which appear to relate to your concerns. In order to solve your problem, you may have to use all or some of the solutions listed here.
When I run the license manager on my machine, it tells me it is the wrong hostid.
The vendor daemon checks the hostid listed on the SERVER line in the license file; if it does not match the hostid of the machine it is running on, this message will be printed. Possible causes include 1) you are trying to run the license server on a different machine from the machine the file was made for; 2) the hostid of the machine you are running on changed (for example, the dongle hostid was moved (Windows), or the CPU board was replaced); 3) the hostid in the license file was modified.
Verify that the hostid of the machine on which the vendor daemon (or node locked client program) is being run matches the hostid specified in the license file (on the SERVER line for the vendor, or on the FEATURE line for a node locked client). You can run the lmhostid program to see what FLEXlm thinks the hostid is. You may not modify the hostid in the license file. If the hostid of your server machine changes, you will have to get a new license file from your software vendor.
The application program (or lmstat) can't connect to the server to check out a license.
The FLEXlm routines in the application are unable to make a TCP connection to the server and port specified in the license file. Possible reasons for this are: 1) the wrong license file is being referenced by the application program; 2) the server machine specified in the license file is down; 3) the vendor daemon specified in the license file is not running; 4) the hostname in the license file is not recognized by the system; 5) the network between the client machine and the server machine is down; 6) You are mixing FLEXlm v1.5 (or earlier) and v2.1 (or later) vendor daemons in one license file, and have run lmgrd without the -b command line option; 7) TCP is not running on your machine.
The lmdiag utility is designed primarily to debug this problem, so first, try lmdiag. Verify that the application is using the proper license file. Verify that specified server machine is up and reachable by executing another command that uses TCP, such as telnet, from the client to the server. Verify that the vendor daemon is running (you can use ps on the server to look for it). Examine the license log file to see if any problems are reported, particularly messages indicating that the vendor daemon has quit. Run lmstat -a from the server machine to verify that the vendor daemon is alive. Run lmstat -a from the client machine to verify the connection from client to vendor daemon across the network. Try using telnet <hostname> <portnum> where hostname and portnum are the same as on the SERVER line in your license file.
When I run my application program (or vendor daemon), I get the error bad code or inconsistent encryption code.
Possible causes for this are 1) the license file was modified (either the hostid on a SERVER line or anything on the FEATURE line was changed); 2) the vendor used the wrong version of his license creation program to generate your license file (or there is a bug in that process).
You may not modify the license file (except for specific fields, see Chapter 2, `The License File' on page 9). If you need to change something in your license file, you must get a new license file from your software vendor.
When the second user tries to check out a license, the vendor daemon prints an error concerning Parameter mismatch in the log file and refuses the license.
The most likely cause of this problem is that you are simultaneously trying to run two different versions of the application program, and the software vendor has not specifically set up the new version for this kind of compatibility. Check the license server log file for a comm version mismatch warning message; this indicates that someone is running an older client than the license server daemon, lmgrd.
Run only the new version of the application (or only the old version).
When I run the vendor daemon on my VMS system, I get the error message socket bind: permission denied (13).
The daemon needs to bind the socket address in order to be able to listen for connections from clients. This is done in the system name table, so it requires the SYSNAM privilege.
Run the daemon in a process with the SYSNAM privilege set.
When I start up lmgrd, it says execl failed on my vendor daemon.
lmgrd uses execl to start each vendor daemon running. If there is a problem starting the vendor daemon, this message is output to the log file. This error is typically caused by one of the following: 1) there is no executable at the location referred to by the license file (and printed out in the log file); 2) the executable does not have the proper permissions to be run (the file does not have the `x' bit set, or one of the directories in the path is not readable); 3) there was an error building the executable, and it can not be run; 4) the executable is for a different machine architecture.
Verify that the path to the vendor daemon is absolute (i.e. starts with a slash character, and that it points to the executable program itself, not the containing directory (for FLEXlm v1.5). Ensure that the file exists by doing an ls -l of the vendor daemon filename(s) specified in the log file. Make sure you do this as the same user that started lmgrd. Verify that the file is executable. Note that if you are running as root and using an NFS-mounted filesystem, the relevant protection bits are the `other' bits (not the `user' bits), even if the file is owned by root. Do a whatis on the file (if your system has that program). whatis should tell you the file is an executable for the machine you are trying to run it on. Run the vendor daemon directly from the command line. If the vendor daemon is properly linked, it will tell you that it must be run from lmgrd; if it crashes or fails to execute, then it is not properly linked.
The license server keeps reporting `lost lock' errors in the log file and exiting.
The lockfile (normally placed in /usr/tmp on Unix, C:\flexlm on Windows/NT, SYS:\SYSTEM\FLEXLM on Netware) is being removed by someone else. There could be another daemon running, or the license administrator (or a script he set up) could have deleted the file.
Check to see if there is more than one copy of the daemon running. On Unix use a command like ps -aux | grep vendorname to search for it. Check for more than one lmgrd running as well, since it will restart your vendor daemon when it is killed. If more than one lmgrd is running, kill them all (using the kill command, not kill -9 on Unix or the Control Panel Services dialog on Windows/NT), then kill any remaining vendor daemons (on Unix, try a simple kill, if that fails then try kill -9 the lmgrd and all vendor daemons) and start one fresh copy of lmgrd. On Unix, check to see if there is a shell script running that cleans out /tmp (or /usr/tmp). If so, try modifying it so that it does not delete zero length files.
Environment variables should never be required to use FLEXlm licensed applications. Environment variables are normally used for debugging or for changing license default location.
FLEXlm environment variables are set in 2 different ways:
On Windows, the FLEXlm registry location is:
HKEY_LOCAL_MACHINE->SOFTWARE->FLEXlm License Manager.
On Unix, the equivalent information is stored in $HOME/.flexlmrc. In this file, the syntax is variable=value.
If the variable is $LM_LICENSE_FILE or $VENDOR_LICENSE_FILE, then both the environment and the registry are used, with the environment used first, and the registry appended to the path.
If it's a different variable, then if the environment set, only that is used, otherwise the registry is used. That is, the registry is only used if the environment is not set.
You don't have to combine license files. Each license file that has any `counted' lines (the `number of licenses' field is >0) requires a server. It's perfectly OK to have any number of separate license files, with different lmgrd server processes supporting each file. Moreover, since lmgrd is a lightweight process, for sites without system administrators, this is often the simplest (and therefore recommended) way to proceed. With v6+ lmgrd/lmdown/lmreread, you can stop/reread/restart a single vendor daemon (of any FLEXlm version). This makes combining licenses more attractive than previously. Also, if the application is v6+, using dir/*.lic for license file management behaves like combining licenses without physically combining them.
Many system administrators, especially for larger sites, prefer to combine license files to ease administration of FLEXlm licenses. It's purely a matter of preference.
Yes. The FLEXlm date format uses a 4-digit year. Dates in the 20th century (19xx) can be abbreviated to the last 2 digits of the year (xx), and use of this feature is quite widespread. Dates in the year 2000 and beyond must specify all 4 year digits.
If you're not combining license files from different vendors, the simplest thing to do is make sure you use the tools that are shipped by each vendor.
lmgrd will always correctly support older versions of vendor daemons and applications, so it's always safe to use the latest version of lmgrd and the lmutil/lmtools utilities. If you've combined license files from 2 vendors, you must use the latest version of lmgrd.
If you've received 2 versions of a product from the same vendor, you must use the latest vendor daemon they send you. An older vendor daemon with a newer client will cause communication errors.
Please ignore letters appended to FLEXlm versions, i.e., v2.4d. The appended letter indicates a patch, and does NOT indicate any compatibility differences. In particular, some elements of FLEXlm didn't require certain patches, so a 2.4 lmgrd will work successfully with a 2.4b vendor daemon. See also Appendix G, `Version compatibility and components' on page 83.
Yes. Older FLEXlm license files are always valid with newer versions of FLEXlm.
As of v3.0, FLEXlm has an optional new format for license files. FLEXlm products always understand older versions; therefore, the pre-v3.0 files are understood by every FLEXlm version. However, your old applications (pre-FLEXlm v3.0) will not be able to use the new license file. See Also: Section 2.2, `License File Format,' on page 12.
Yes. A server on the internet will serve licenses to anyone else on the internet. This can be limited with the INTERNET= attribute on the FEATURE line, which limits access to a range of internet addresses. You can also use the INCLUDE and EXCLUDE options in the daemon option file to allow (or deny) access to clients running on a range of internet addresses.
Many firewalls require that port numbers be specified to the firewall. FLEXlm v5 lmgrd supports this.
Yes, unless the client's whole system crashes, or becomes disconnected from the network. Assuming communications is TCP, the license is automatically freed immediately. If communications are UDP, then the license is freed after the UDP timeout, which is set by each vendor, but defaults to 45 minutes. UDP communications is normally only set by the end-user, so TCP should be assumed. If the whole system crashes, then the license is not freed, and you should use lmremove to free the license.
FLEXlm applications send periodic heartbeats to the server to discover if it has died. What happens when the server dies is then up to the application. Some will simply continue periodically attempting to re-checkout the license when the server comes back up. Some will attempt to re-checkout a license a few times, and then, presumably with some warning, exit. Some GUI applications will present pop-ups to the user periodically letting them know the server is down and needs to be re-started.
99.44% of the time, if it's in use, it's because lmgrd is already running on the port - or was recently killed, and the port isn't freed yet. Assuming this is not the case, then use 'telnet host port' - if it says `can't connect', it's a free port.
No. There is no part of FLEXlm, lmgrd, vendor daemon or application, that requires root permissions. In fact, it is strongly recommended that you do not run the license server (lmgrd) as root, since root processes can introduce security risks. If lmgrd must be started from the root user (for example, in a system boot script), we recommend that you use the su command to run lmgrd as a non-privileged user:
su username -c"/path/lmgrd -c /path/license.dat -l /path/log"
where username is a non-privileged user, and path is the correct paths to lmgrd, license.dat and debug log file. You will have to ensure that the vendor daemons listed in /path-to-license/license.dat have execute permissions for username. The paths to all the vendor daemons in the license file are listed on each DAEMON line.
It is not prudent to run any command, particularly a daemon, as root on Unix, as it may pose a security risk to the Operating System. Therefore, we recommend that lmgrd be run as a non-privileged user (not `root'). If you are starting lmgrd from a boot script, we recommend that you use
su username -c"umask 022; lmgrd..."
to run lmgrd as a non-privileged user.
No, but partly this depends on the application, and end-user's use. A typical checkout request requires 5 messages and responses between client and server, and each message is < 150 bytes.
When a server is not receiving requests, it requires virtually no CPU time.
When an application, or lmstat, requests the list of current users, this can significantly increase the amount of networking FLEXlm uses, depending on the number of current users.
Also, prior to FLEXlm v5, use of `port@host' can increase network load, since the license file is down-loaded from the server to the client. port@host should be, if possible, limited to small license files (say < 50 features). In v5, port@host actually improves performance.
Yes. FLEXlm has no direct interaction with NFS. FLEXlm uses an NFS-mounted file like any other application.
In general, these have no impact on FLEXlm. FLEXlm requires TCP/IP or SPX (Novell Netware). So long as TCP/IP works, FLEXlm will work.
Yes, although this behavior was improved in v3.0, and v6.0.
When a license server and a client are located in different domains, fully-qualified host names have to be used. A `fully-qualified hostname' is of the form: node.domain, where `node' is the local hostname (usually returned by the 'hostname' command or 'uname -n') `domain' is the internet domain name, e.g., `globes.com'.
To ensure success with FLEXlm across domains, do the following:
If all components (application, lmgrd and vendor daemon) are v6.0 or higher, no aliases are required; the only requirement is that the fully-qualified domain name, or ip-address, is used as a hostname on the SERVER, or as a hostname in $LM_LICENSE_FILE port@host, or @host.
Yes. However, some sites have broken NIS or DNS, which will cause FLEXlm to fail. In v5 of FLEXlm, NIS and DNS can be avoided to solve this problem. In particular, sometimes DNS is configured for a server that's not current available (e.g., a dial-up connection from a PC). Again, if DNS is configured, but the server is not available, FLEXlm will fail.
In addition, some systems, particularly Sun, SGI, HP, require that applications be linked dynamically to support NIS or DNS. If a vendor links statically, this can cause the application to fail at a site that uses NIS or DNS. In these situations, the vendor will have to relink, or recompile with v5 FLEXlm (when it becomes available in Q1 of 96). Vendors are strongly encouraged to use dynamic libraries for libc and networking libraries, since this tends to improve quality in general, as well as making NIS/DNS work.
On PCs, if a checkout seems to take 3 minutes and then fails, this is usually because the system is configured for a dial-up DNS server which is not currently available. The solution here is to turn off DNS.
Finally, hostnames must NOT have periods in the name. These are not legal hostnames, although PCs will allow you to enter them, and they will not work with DNS.
Not by default. The default FLEXlm display is what is returned by the ttyname() function call (or the 'tty' command), and is usually something like `/dev/ttyp4'. However, the application developer can change this default to the X-Display. A paper is available on this topic to FLEXlm developers from GLOBEtrotter Software.
FLEXlm network traffic should be minimized. With the most common uses of FLEXlm, traffic is negligible. In particular, checkout, checkin and heartbeats use very little networking traffic. There are two items, however, which can send considerably more data and should be avoided or used sparingly:
FLEXlm supports Windows 3.1,Windows for Workgroup 3.11, Windows 95/98, Windows NT 3.5, 3.51 and 4.0 on Intel Mips and Alpha, Netware 3.12 and 4.X, OS/2 3.0.
Networking is required on all 32-bit versions
Winsockx.dll is a DLL provided by GLOBEtrotter Software that is used by 16 bit applications to interface between FLEXlm and other networking software provided by networking ISV's. It allows node locked applications to not require networking software. It also interfaces between winsock.dll for TCP/IP, and the Novell DLLs that provide IPX/SPX on 16 bit operating systems.
This is necessary for either obtaining the Ethernet card address, or to provide connectivity with a Netware License server. Version 6.1+ applications will not require this on NT.
Yes. If available, NT systems are preferred, since it can be run as an NT `service'. A version 7+ lmgrd will run the background on Windows 95.
FLEXlm error messages presented by applications have the following components
Error messages were improved in v6. FLEXlm error explanation, and supporting information are only available in applications using v6.0+.
These error messages may occur in two formats available with FLEXlm, or may appear in a format customized by the application:
FLEXlm error text (-lm_errno, minor_num[:sys_errno]) [sys error text]
The system error information may be missing.
Example:
Can't connect to license server (-15,12:61) Connection refused
FLEXlm error text FLEXlm error explanation [Optional Supporting information] FLEXlm error: -lm_errno, minor_num[, sys_errno] [`system error text']
Example:
Cannot connect to license server The server (lmgrd) has not been started yet, or the wrong port@host or license file is being used, or the port or hostname in the license file has been changed. Feature: f1 Server name: localhost License path: @localhost:license.dat:./*.lic FLEXlm error: -15,12. System Error: 61 `Connection refused'
Errors marked with an '*' indicates errors which should not appear in shipping software. These are errors intended to help the programmer incorporate FLEXlm in their product, and should be fixed before shipping.
Errors marked with '+' indicate errors due to an operating system failure.
The daemons all generate debug log files in the following format.
hh:mm (DAEMON NAME) message
The debug log files can be used to:
The debug log file should not be used for usage reporting.
Connected to node
This daemon is connected to its peer on node `node.'
CONNECTED, master is name
The license daemons log this message when a quorum is up and everyone has selected a master.
DENIED: N feature to user
`user' was denied access to `N' licenses of `feature'.
EXITING DUE TO SIGNAL nnn
EXITING with code nnn
All daemons list the reason that the daemon has exited.
EXPIRED: feature
`feature' has passed its expiration date.
IN: feature by user (N licenses)
`user' has checked back in `N' licenses of `feature'.
License Manager server started
The license daemon was started.
Lost connection to host
A daemon can no longer communicate with its peer on node `host', which can cause the clients to have to reconnect, or cause the number of daemons to go below the minimum number, in which case clients may start exiting. If the license daemons lose the connection to the master, they will kill all the vendor daemons; vendor daemons will shut themselves down.
Lost quorum
The daemon lost quorum, so will process only connection requests from other deamons.
MULTIPLE xxx servers running.
Please kill, and restart license daemon
The license daemon has detected that multiple licenses for vendor daemon `xxx' are running. The user should kill all `xxx' daemon processes and re-start the license daemon.
OUT: feature by user (N licenses)
`user' has checked out `N' licenses of `feature'.
RESERVE feature for HOST name
RESERVE feature for USER name
A license of `feature' is reserved for either user `name' or host `name'.
REStarted xxx (internet port nnn)
Vendor daemon `xxx' was restarted at internet port `nnn'.
Retrying socket bind (address in use)
The license servers try to bind their sockets for approximately 6 minutes if they detect `address in use' errors.
Selected (EXISTING) master node.
This license daemon has selected an existing master (node) as the master.
SERVER shutdown requested.
A daemon was requested to shut down via a user-generated kill command.
[NEW] Server started for: feature-list
A new server was started for the features listed.
Shutting down xxx
The license daemon is shutting down the vendor daemon xxx.
SIGCHLD received. Killing child servers.
A vendor daemon logs this message when a shutdown was requested by the license daemon.
Started name
The license daemon logs this message whenever it starts a new vendor daemon.
Trying connection to node
The daemon is attempting a connection to `node'.
hostname: Not a valid server host, exiting
This daemon was run on an invalid hostname.
hostname: Wrong hostid, exiting
The hostid is wrong for `hostname.'
BAD CODE for feature-name
The specified feature name has a bad license key. It was probably typed in wrong, or modified by the end-user.
CANNOT OPEN options file `file'
The options file specified in the license file could not be opened.
license daemon: lost all connections
This message is logged when all the connections to a server are lost, which often indicates a network problem.
lost lock, exiting
Error closing lock file
Unable to re-open lock file
The vendor daemon has a problem with its lock file, usually because of an attempt to run more than one copy of the daemon on a single node. Locate the other daemon that is running via a ps command, and kill it with kill -9.
NO DAEMON line for daemon
The license file does not contain a `DAEMON' line for `daemon.'
No `license' service found
The TCP `license' service did not exist in /etc/services.
No features to serve!
A vendor daemon found no features to serve. This could be caused by a corrupted or incorrectly entered license file.
UNSUPPORTED FEATURE request: feature by user
The `user' has requested a feature that this vendor daemon does not support. This can happen for a number of reasons: the license file is bad, the feature has expired, or the daemon is accessing the wrong license file.
Unknown host: hostname
The hostname specified on a `SERVER' line in the license file does not exist in the network database.
NO DAEMON lines, exiting
The license daemon logs this message if there are no DAEMON lines in the license file. Since there are no vendor daemons to start, there is nothing to do.
NO DAEMON line for name
A vendor daemon logs this error if it cannot find its own DAEMON name in the license file.
No internet port number specified
A vendor daemon was started without an internet port.
read: error message
An error in a `read' system call was detected.
select: message
An error in a select system call was detected. This is usually a sign of a system networking failure.
Server exiting
The server is exiting. This is normally due to an error.
In general, always use the latest lmgrd and lmutil/lmtools.exe, which are available from www.globetrotter.com, and you'll automatically enjoy many of the enhancements available in the most recent versions. However, some enhancements require upgraded vendor daemons, and yet others require upgraded client applications. Given the following components:
the rules about compatibility can be summarized as follows:
version of lmutil must be >=
version of lmgrd, which must be >=
version of vendor daemon, which must be >=
version of client application, which must be >=
version of license file format
Except for the license file, you can use lmver to discover the version of all these components. For the vendor daemon, lmgrd, lmutil, you can also you -v argument to print the version.
The following rules apply to individual FEATURE, INCREMENT or UPGRADE lines. It's possible to have a mix of versions in a single file. Only the features that a particular application checkout determine the version of the license for that feature.
First FLEXlm Release, containing all the basic FLEXlm features.
V1.5 - February 1990
First widely-used version including DEMO.
V2.1 - March 1991