Frequently Asked Questions (FAQ) about the Flexible License Manager
(FLEXlm) from Highland Software.
This document answers questions frequently asked about the FLEXlm
product and applications which incorporate FLEXlm licensing. It is
divided into the following sections:
I) FAQ on License Files
II) FAQ on Redundant Servers
II) FAQ on VMS
IV) Miscellaneous FAQ
======================================================================
I) FAQ on License Files
----------------------------------------------------------------------
1) The license server keeps reporting "lost lock" errors in the log
file
and exits.
A) Each daemon running on a machine creates a lock file, usually in
/usr/tmp. This lock file ensures that only one daemon from a specific
vendor can run on a machine at one time. This error can arise from:
a) More than one daemon from a vendor running on the machine at the
same
time. Make sure that the vendor daemon is listed on a `DAEMON' line in
one and only one license file used by each `lmgrd' running on the
machine. Restart the licensing system by taking it down with `lmdown',
`kill -9', or `sigp -b' and then starting `lmgrd' normally.
b) The file was deleted by someone with the correct permissions. Talk
with the users of the system, and make sure that they aren't doing
things like "rm -f /usr/tmp/*".
c) The file was deleted by a `cron' job. Verify that a cron job is not
deleting the file out of `/usr/tmp'.
d) The directory /usr/tmp is remotely mounted. This can cause problems
with the `flock()' and `lockf()' calls, depending on the machine type.
The application vendor can override the default location for the
lockfile for a daemon by using the `-X' option to `CONFIG_DAEMON' or by
modifying the string pointer `user_lockfile' in `machind/ls_vendor.c'.
----------------------------------------------------------------------
2) Which port number should be used for `lmgrd'?
A) System command `netstat -a' is used to find out the port numbers in
use. Do not use the port numbers in use which are reserved. Generally,
port numbers can be selected from the user defined range, usually 1700
to 8000. The port number that `lmgrd' will use to communicate with
client applications is specified on the `SERVER' line of the license
file, and can be changed by an end user without effecting any of the
encryption codes for features in the license file.
----------------------------------------------------------------------
3) Can more than one `lmgrd' be run on a single machine at the same
time?
A) Yes, more than one `lmgrd' can be run on a single machine at the
same
time. The port number on the `SERVER' line in their license files must
be different from one another. Also, not more than one `lmgrd' can run
a particular vendor daemon at a time.
----------------------------------------------------------------------
4) Can an end user combine license files from more than one vendor?
A) Yes, two or more license files can be combined if the following two
criteria are met. Each license file must have the same number of
`SERVER' lines in it. Each of these `SERVER' lines must have the same
`hostid' numbers on a machine by machine basis. It is never a
requirement that license files be combined, but doing so will use less
resources on the license server machine.
Some possible reasons why license files may not be compatible are:
a) The license files are set up to run on different server nodes, so
the
hostids of each `SERVER' line in the license files are different.
b) Even though the license files are set up to run on the same
machine(s), the `hostid' field is different. This can be the case on
Hewlett Packard machines where either the ethernet hardware address or
an HP ID module can be used as the hostid. Vendors can also define
their
own meaning for the `hostid' field.
c) The number of `SERVER' lines in the license files are not the same.
In this case, the license files are set up to run in different
redundant
server configurations, so the license files cannot be combined. If the
license files are not compatible, you should keep the license files
separate and run a separate `lmgrd' for each license file. See below
for
accessing multiple license files and license servers from a single
session.
To combine multiple license files into one file, first make sure that
it
is possible using the rules above. Then, use a text editor to put all
of
the `DAEMON' and `FEATURE' lines from all of the files into one, and
the
`SERVER' line(s) from one of the files. `SERVER' line(s) should not be
duplicated within 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:
a) Always use the newest version of `lmgrd' available.
b) Use the newest version of each vendor daemon available.
c) Use `lmutil' from the v2.4 release of FLEXlm. If this is not
available, use the utilities which came with the oldest vendor daemon
you are going to use.
d) The application must be built with a version of FLEXlm that is the
same as or older than its associated vendor daemon and lmgrd.
You can find out the version of each piece of your system with the
following method: "strings | grep Highland | grep -i flex".
Substitute the name of a program, such as `lmgrd' or a FLEXlm licensed
application, for `'.
----------------------------------------------------------------------
5) How do you access more than one license manager from a single
interactive shell, such as `/bin/csh'?
A) When running client programs, you can set the LM_LICENSE_FILE
environment variable to point to multiple license files. This variable
is a colon (:) separated path very much like the `PATH' variable. An
application which requests a license from a FLEXlm license server will
search along the path specified by LM_LICENSE_FILE until it finds one
which it can use. For example, you have a license file from vendor ABC
and a license file from vendor XYZ with incompatible servers. You can
use "setenv LM_LICENSE_FILE /usr/flexlm/abc.dat:/usr/flexlm/xyz.dat" to
point to multiple license files.
----------------------------------------------------------------------
6) How does FLEXlm gets the hostname of the machines which lmgrd and
the
licensed applications are running on?
A) FLEXlm uses the gethostname() call to get the host machine name.
----------------------------------------------------------------------
7) lmgrd prints out the error message "retrying socket bind".
A) The port number specified on the `SERVER' line of the license file
is
either blocked or in use by another process. Use the unix command
`netstat -a' to find out the status of the port which `lmgrd' is trying
to use. It may be that a different port number will be needed on the
`SERVER' line of the license file.
----------------------------------------------------------------------
8) The hostid returns 0 if an application is run on HP platforms.
A) There is a problem with the device /dev/lan0.
a) The permissions Read/write are not set for /dev/lan0.
b) If lan0 device is logically connected to another device.
If you get either of the above errors, please contact FLEXlm support at
flexsupport@hisoft.com.
----------------------------------------------------------------------
9) Error message "Inconsistent encryption code at the server".
A) The code in the license file line does not match the other data in
the license file. This is usually the result of not building all the
software components with the same encryption code. Check
create_license.c, ls_vendor.c, and your application code carefully to
ensure that they are all built with the same vendor code, contained in
`machind/lm_code.h'.
----------------------------------------------------------------------
10) Error message "Bad Platform"
A) The vendor code has not been enabled for the particular platform for
which error has occurred. New vendor codes have to be acquired from
Highland Software.
----------------------------------------------------------------------
11) Problems regarding the usage of multiple feature lines.
A) If one wants to use multiple feature line functionality, run the
CONFIG_DAEMON with -x option and enable the ls_use_all_feature_line
flag in `machind/ls_vendor.c'.
======================================================================
FAQ on Redundant Servers:
----------------------------------------------------------------------
1. What is a `Redundant Server'?
A. The `redundant server' feature gives FLEXlm fault tolerance in a
network. Three or five servers acting together logically operate as a
single license server. If one (or two, in the case of the five machine
configuration) of the servers is not available on the network,
applications can still receive licenses from the remaining license
servers. This feature is activated by having three or five `SERVER'
lines in a license file. Nothing special needs to be done to either
licensed applications or vendor daemons for this feature.
----------------------------------------------------------------------
2. How do you configure a redundant server network?
A) Since the license file activates the redundant server feature, it is
important that each of the three (or five) servers has a license file
that is appropriate for that machine. All of the `SERVER' lines should
be the same and in the same order in each file. The `FEATURE' lines
should also the same, though they do not need to be in the same order.
The `DAEMON' lines should name the same vendor daemons, and should name
the same options files, if they are used. On `DAEMON' lines, the path
to
the vendor daemon may be different from machine to machine, especially
if the machines are different architectures.
----------------------------------------------------------------------
3. What if I have different versions of the vendor daemons and lmgrd
running on different platforms?
A. Make sure that the latest version of lmgrd is running on every
platform. As the newest lmgrd can communicate with older vendor
daemons, there won't be any compatibility problems.
======================================================================
FAQ on VMS:
----------------------------------------------------------------------
1. The vendor daemon is printing the error "socket bind: bad address".
A. There exists an error on some releases of the Open VMS version of
FLEXlm v2.4 that requires the Decnet Known Object to be `0' for
licensing communication. This has been fixed, and a patch is available.
----------------------------------------------------------------------
2. lmstat, lmdown, lmremove, isvaliddate are not working.
A. It is a known error that these utilities are not working. The next
release of FLEXlm will fix these problems.
======================================================================
Misc. FAQ:
----------------------------------------------------------------------
1. Is FLEXlm available on PC's?.
A. Only the client side of the FLEXlm is available on PC's. But we are
coming up with our new release v3.0 at the end of the first quarter 94
in which NT platform will be supported on both client and server side.
The client side on PC requires either the Wollongong TCP/IP libraries
or
Sun PC/NFS libraries, depending on the release.
----------------------------------------------------------------------
2. Problems regarding diskless servers and ls_checkroot().
A. Running FLEXlm servers on a diskless node creates a security
problem.
It is possible for a user to run more than one given vendor daemon on a
node if does certain `tricks' to the file system. This has the effect
of
multiplying the number of available licenses for that vendor daemon.
Therefore, Highland Software does not recommend the use of diskless
nodes as license servers.
With the introduction of FLEXlm v2.4, vendor daemons are prohibited, by
default, from running on diskless nodes. Prior to v2.4, it was an
option
using the `ls_checkroot()' function. To disable this check, set the
variable `ls_do_checkroot' to `0' in the file `machind/ls_vendor.c'.
This will allow the vendor daemon to run on a diskless node. Again, due
to security considerations, Highland Software strongly recommends that
`ls_checkroot()' be allowed to run normally by keeping the variable
`ls_do_checkroot' set to `1'.