Frequently Asked Questions

You don’t have to combine license files. Each license file that has any counted lines (the license count 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.0+ lmgrd/lmdown/lmreread, you can restart/stop/reread a single vendor daemon (of any FLEXlm version). This makes combining licenses more attractive than previously. Also, if the application is v6.0+, using dir/*.lic for license file management behaves like combining licenses without physically combining them.

E.1.2 When is it recommended to combine license files?

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.

E.2 FLEXlm Versions

E.2.1 I have products from several companies at various FLEXlm version levels. Do I have to worry about how these versions work together?

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 always supports 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 two vendors, you must use the latest version of lmgrd.

If you’ve received two 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 FLEXlm-licensed application causes communication errors.

Please ignore letters appended to FLEXlm versions, for example, the “d” in 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 v2.4 lmgrd works successfully with a v2.4b vendor daemon. See also Section I.1, “Version Compatibility and Components.”

E.2.2 I’ve received a new copy of a product from a vendor, and it uses a new version of FLEXlm. Is my old license file still valid?

E.2.3 I’ve received a new license file, and the format is different from the old one I had from the same vendor? Why? Are they compatible?

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) are not be able to use the new license file. See also Appendix B, “License File Format.”

E.3 Using FLEXlm

E.3.1 Does FLEXlm work across the Internet?

Yes. A server on the Internet serves licenses to anyone else on the Internet with access to those ports on that machine. 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 options file to allow (or deny) access to clients running on a range of Internet addresses.

E.3.2 Does FLEXlm work with Internet firewalls?

Many firewalls require that TCP/IP port numbers be specified to the firewall. FLEXlm v5 lmgrd and vendor daemons supports this.

E.3.3 If my FLEXlm-licensed application dies, does the server free the license?

Yes, unless the FLEXlm-licensed application’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 is assumed. If the whole system crashes, then the license is not freed; use lmremove to free the license.

E.3.4 What happens when the license server dies?

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:

Continue periodic attempts to re-checkout the license when the server comes back up.

Attempt to re-checkout a license a few times, and then, presumably with some warning, exit.

In the case of GUI applications, present pop-ups to the user periodically letting them know the server is down and needs to be restarted.

E.3.5 How do you tell if a TCP/IP port is already in use?

99.44% of the time, if it’s in use, it’s because lmgrd is already running on the TCP/IP 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.

E.3.6 Does FLEXlm require root permissions?

No. There is no part of FLEXlm, lmgrd, vendor daemon, or application, that requires root permissions. In fact, it is 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), it is recommended that you use the su command to run lmgrd as a non-privileged user:

where username is a non-privileged user, and the paths are the correct paths to lmgrd, the license file, and the debug log file. You must ensure that the vendor daemons listed in the license file have execute permissions for username. The paths to all the vendor daemons in the license file are listed on each VENDOR line.

E.3.7 Is it OK to run lmgrd as “root” (UNIX only)?

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, it is recommended that lmgrd be run as a non-privileged user (not “root”). For example, if you are starting lmgrd from a boot script, use:

E.3.8 Does FLEXlm licensing impose a heavy load on the network?

No, but partly this depends on the application, and end user’s use. A typical checkout request requires five messages and responses between the FLEXlm-licensed application and server, and each message is <150 bytes.

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 downloaded from the server to the system running the FLEXlm-licensed application. For pre-v5 FLEXlm, it is recommended that port@host be limited to small license files (say, <50 features). In v5+, port@host actually improves performance.

E.3.9 Does FLEXlm work with NFS?

Yes. FLEXlm has no direct interaction with NFS. FLEXlm uses an NFS-mounted file like any other application.

E.3.10 Does FLEXlm work with ATM, ISDN, Token-Ring, etc.

In general, these have no impact on FLEXlm. FLEXlm requires TCP/IP. So long as TCP/IP works, FLEXlm works.

E.3.11 Does FLEXlm work with subnets, fully qualified names, multiple domains, etc.?

When a license server and a FLEXlm-licensed application are located in different domains, fully qualified host names have to be used. A “fully qualified host name” is of the form machine.domain, where machine is the local host name (usually returned by the hostname command or uname -n) and domain is the Internet domain name, e.g., “globes.com.”

Make the sure the fully qualified host name is the name on the SERVER line of the license file.

Make sure ALL FLEXlm-licensed application machines, as well as the server machine, are able to telnet to that fully qualified host name. For example, if the host is locally called “speedy,” and the domain name is “corp.com,” local systems are able to logon to “speedy” via telnet speedy. But very often the fully qualified host name, telnet speedy.corp.com, fails locally. Note that this telnet command always succeeds on hosts in other domains (assuming everything is configured correctly), since the network resolves “speedy.corp.com” automatically.

Finally, there must be an alias for “speedy” so it’s also known locally as “speedy.corp.com.” This alias is added to the /etc/hosts file, or if NIS/Yellow Pages are being used, then it has to be added to the NIS database. This requirement goes away in version 3.0 of FLEXlm.

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 host name on the SERVER, or as a host name in the LM_LICENSE_FILE environment variable (port@host or @host).

E.3.12 Does FLEXlm work with NIS and DNS?

Yes. However, some sites have broken NIS or DNS, which causes 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 currently available (e.g., a dial-up connection from a Windows system). Again, if DNS is configured, but the server is not available, FLEXlm fails.

On Windows, if a checkout seems to take three 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, host names must not have periods in the name. These are not legal host names, and they do not work with DNS; although, Windows systems allow you to define them.

E.3.13 We are using FLEXlm over a wide-area network. What can we do to improve performance?

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:

lmstat -a

Use sparingly. Network traffic increases as the amount of concurrent users and features increases. As a rule of thumb, avoid using this command when there are more than 20 concurrent users or features.

Prior to FLEXlm v5, the port@host mode of the LM_LICENSE_FILE environment variable should be avoided, especially when the license file has many features, or there are a lot of license files included in LM_LICENSE_FILE. The license file information is sent via the network, and can place a heavy load. Failures due to port@host generate the error LM_SERVNOREADLIC (-61).

Appendix E