Table of Contents * Index * Previous Chapter * Next Chapter
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 (especially lmgrd) 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 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.
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 10.
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. 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, 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.
Yes, lmgrd runs in it's own window. If available, NT systems are preferred, since it can be run as an NT `service'. Special software to emulate NT services is available from your software vendor.
Table of Contents * Index * Previous Chapter * Next Chapter