Summary FlexNet Publisher 2014 (11.12.1.5) SP5 Release Notes Synopsis Below are the Table of Contents from the attached FlexNet Publisher 2014 (11.12.1.5) Release Notes. This is meant to act as a reference for KnowledgeBase Article search return results. Discussion FlexNet Publisher 2014 (11.12.1.5) Service Pack 5 Release Notes October-2014 Overview....................................................................................................................................................... 2 Resolved Issues in FlexNet Publisher (11.12.1.5) Service Pack 5........................................................... 2 General Issues .............................................................................................................................................................2 Dongle Issue................................................................................................................................................................2 Resolved Issues from FlexNet Publisher (11.12.1.4) Service Pack 4...................................................... 3 General Issues .............................................................................................................................................................3 Dongle Issue................................................................................................................................................................4 Dongle Driver updates................................................................................................................................ 5 Resolved Issues from FlexNet Publisher (11.12.1.2) Service Pack 2...................................................... 5 General Issues .............................................................................................................................................................6 lmadmin Issues ...........................................................................................................................................................7 Dongle Issue................................................................................................................................................................8 Resolved Issues from FlexNet Publisher (11.12.1.1) Service Pack 1...................................................... 8 General Issues .............................................................................................................................................................8 Dongle issues ........................................................................................................................................................... 10 Known Issues in FlexNet Publisher (11.12.1.5) Service Pack 5 ............................................................11 Supported Platforms.................................................................................................................................11 ... View more

Summary What's the FNP design rationalization behind OPTIONS=SUITE? Question What's the business value of OPTIONS=SUITE for FlexNet Publisher (FNP)? Answer Package license is linked with set of different components. Package licenses are for the consumption of Publisher and not for End User. In other words, with package licenses Publisher can organize that how components licenses to be consumed. Package with OPTIONS=SUITE, is specialized variant of package licenses. Server checkouts package licenses also with component licenses. As a result, it can introduce component license consumption conditional and can make whole package more productive. Component licenses can be consumed in different valuable permutations as per requirement. Let us consider some use cases to understand well: 1) PACKAGE pkg_lic flexera 1.0 COMPONENTS="comp1 comp2 comp3" OPTIONS=SUITE SIGN= INCREMENT pkg_lic flexera 1.0 28-mar-2019 3 SIGN= Package pkg_lic contains 3 licenses and 3 components. Publisher has provided 3 licenses for package. End user can use any 3 component licenses. It can be all 3 licenses of comp1 or 1 each license of comp1, comp2, comp3. Publisher able to diversify the usage of product as per end user need of the time. 2) PACKAGE pkg_lic flexera 1.0 COMPONENTS="comp1 comp2 comp3" OPTIONS=SUITE SIGN= INCREMENT pkg_lic flexera 1.0 28-mar-2019 2 DUP_GROUP=U SIGN= Package pkg_lic contains 2 licenses and 3 components. Publisher can make package more cost effective by enabling two components and disabling one. End user can use any 2 components. It can be either comp1,comp2 or comp2,comp3 or comp1,comp3. As it DUP_GROUP=U, end user can check out already checked out component unlimited times. Publisher can change package configuration in license file anytime by adding one more package license, if wants to enable third component also. 3) PACKAGE pkg_lic flexera 1.0 COMPONENTS="comp1 comp2 comp3" OPTIONS=SUITE SIGN= INCREMENT pkg_lic flexera 1.0 28-mar-2019 1 DUP_GROUP=U SIGN= Package pkg_lic contains 1 license and 3 components. It is a good alternative where Publisher wants comp1, comp2, comp3 should be used exclusively. End user can use any of them with exclusivity. These are some of the basic use cases which can be easily achieved with OPTION=SUITE. With this provided solution, Publisher can package the product in different permutations. Product monetization will be streamlined as per requirements. ... View more

Summary How do you limit a license server to only listen via a specific network card on a system with multiple NICs? Question Is there any way to tie a license server to a specific network card in terms of what the vendor daemon actually listens for license requests? For example, when running license servers that are multi-homed (e.g. multiple network cards) on a Linux system, you can see by running lsof -ni :port that lmgrd and the vendor daemon are both listening on all networks. Can FNP be configured to be only listening on the network card they are bound to by hostid? Answer By design, the license server is listening on IP address 0.0.0.0, meaning it listens for network traffic from all NICs. Listening on 0.0.0.0 is normal for server applications. These needs can be met by adding rules to disable traffic from specific NIC/Subnet in your firewall, or by adding some exclude IP/hostname via FNP's Options file to reject checkout request from part of your IP addresses or hostnames. There is no way in FNP to select a particular network card. I.e., it is not possible to have license server (lmgrd) to listen on a specific IP address instead of the 0.0.0.0. While you can?t bind the scope to the network card, what you're trying to do should work based on which interface the DHCP traffic is received on; as long as you have a scope defined that is correct for each interface. DHCP servers take into account the IP address of the interface on which the incoming request was received. In the case of relays the IP of the interface the relay received the request is included as part of the forward request. So if a computer receives a request on the interface 10.90.63.1/24 then it will assign an address from the 10.90.63.0/24 scope. So all you have to do is make sure the VLAN card associated with the license server has a static address assigned that is valid for that network, and then activate the scope. ... View more

Summary Why would you get a network lc_checkout fljobenabled error -5,414 when the license exists? Question Some license-enabled products do not appear to be working consistently. They sometimes get error -5,414. The license checkout is performed for an existing license, but fails. That same license can be checked in the same process/program at other times successfully, but then all of a sudden returns -5,414. The application also checks for other existing and not existing licenses. The not existing licenses return error code -5,412. The -5,414 error does not result in an error message in the server log file. If you introduce a retry mechanism when the lc_checkout returns other errors (different from LM_NOFEATURE), this solves the problem. Why is the error code for the existing license different (-5,414 compared to -5,412), and why does a retry solve the problem? Answer If a license file does not have USE_SERVER line and we have read the feature in this license for this vendor but we are not able to connect to the server for checkout, we may report this error (-5, 414). For example, this situation can be duplicated with the following steps (note that both the server and client were tested on the same machine). 1. Start the license server with a valid license file that has valid feature lines and corrected hostname on SERVER line. 2. Set the license path pointing to the following license file that does not have USE_SERVER line and it does not have valid hostname on SERVER line. SERVER invalid ANY VENDOR demo FEATURE f1 demo 1.0 permanent 4 SIGN="003D B062 54D1 47E3 1FF6 145F \ 59CE 0200 8002 FE69 0FBC F4FF AA10 FFB3 6EB3" 3. Ensure client checkout filter is enabled on the client application. 4. When trying to checkout feature "f1", we will be able to find the valid license for this feature, however we do not have the valid hostname for server connection. As a result, it returns -5,414 error. ... View more

Summary Three server redundancy (triad) failures. Question We're having problems with the stability of redundant servers. The problem has been intermittent for years. There is no specific error we're seeing or other deterministic data available. We're currently collecting: Number of tcp open requests/sec to the lmgrd daemon are measured Service time in microseconds (from accept on port to the shutdown) of every request to the lmgrd daemon The socket receive backlog (set to 500 by lmgrd) and socket drops and socket overflows on port is measured every 10 seconds File descriptor counts are sampled every 10 seconds for each of the three servers (lmgrd and two vendor daemons) The only thing that correlates is the socket receive backlog increases/maxes out and usually they see the socket overflows increments when they see the failures to maintain quorum on the redundant servers. Increase in socket backlog leads to partial failures to verify a host. Any ideas as to why this may be happening? Answer This is a case of one of the many symptoms that can occur when license servers are overloaded beyond their capacity. Symptoms can range from clients timing out to - in this case - quorum being lost in a triad. This is not something with which engineering would practically be able to engage unless a deterministic error behavior is reproduced or enhancement request designed to mitigate the high-load behavior is raised (again, requiring determinism). The kinds of things that you could experiment with today to alleviate lost-quorum are: 1. Reduce licenses served per triad. 2. Increase hardware resources on primary and secondary nodes (high CPU count more important than number cores or threads). 3. Consider upgrading the vendor daemon to the latest version - there may be some benefit from our recent select->poll changes (such as FNP-17708: "Remove the OS select() call from the FNP code-base for all non-Windows platforms" implemented with FNP 11.15.1). 4. Set a value for LM_SERVER_HIGHEST_FD (see docs) to something in the low 100's, down from the default of 1024. This will have the effect lowering the accepted client connections/second to the lmgrd, which may help in mitigating lost-quorum situations. In general, an approach to mitigate lost-quorum is to control client load. Enhancement FNP-18732: "Have a graceful and predictable error just before VD hits its producer-tested limits" is under consideration to help mitigate this type of situation. ... View more

Summary tsactdiags tool and flxActDiagTrustedStorageHealthCheck API replace tsview utility Question Regarding the tsview utility, we have the 11.14.1.0 version of the tool. We want to know if there's an 11.16.0 version available, as we're running into some temporary binding changes and are wondering if that's normal behavior (or if we're just using too old of a version of TS view to test). Answer The new tsactdiags tool and healthCheck API (flxActDiagTrustedStorageHealthCheck, demonstrable via appcomptranutil -healthCheck) were intended to be a customer-usable replacement for tsview. These were introduced with FNP 11.16.0. Also, please note, any binding changes that don't cause a binding break should be ignored. ... View more

Summary Why does the Windows Task Manager show 2 lmgrd processes running at the same time on the same system? Question Why does the Windows Task Manager show 2 lmgrd processes running at the same time on the same system? Answer This is expected behavior when lmgrd is installed as a service. On running 'lmgrd' as service, two 'lmgrd' processes can be seen in Task Manager. One of which represents the 'lmgrd' service and the other represents the 'lmgrd' process created by the service. If lmgrd is not installed as a service, only 1 lmgrd process will be observed in the Task Manager on Windows. ... View more

Summary How do the lmgrd and lmdown processes work to start and stop vendors on Windows? Question It appears that our license server has an lmgrd process for each vendor daemon. We have our XXX vendor and there's a second YYY vendor. The Windows Task Manager shows 2 lmgrd processes running. When we attempt an lmdown process, it's killing both those lmgrd processes. How do we go about just shutting down our lmgrd and vendor so we only stop the stuff we started with our license server without interrupting the other one? Answer There's some confusion here regarding how it works. Please note, there is *NOT* 1 lmgrd process per vendor daemon (see KB 000027955). On running 'lmgrd' as service, two 'lmgrd' processes can be seen in Task Manager. One of which represents the 'lmgrd' service and the other represents the 'lmgrd' process created by the service. If lmgrd is not installed as a service, only 1 lmgrd process will be observed in the Task Manager on Windows, and that single (1) license manager (lmgrd) process runs/manages all vendor daemons on the system in question. Additional Information The 'lmdown' utility can be used to shut-down either 'lmgrd' (which in-turn shuts-down the vendor daemon/daemons) or only 'vendor daemon' (lmgrd continues running). The point here is that without the use of '-vendor', the 'lmdown' request is sent to 'lmgrd' (irrespective of whichever vendor daemon is running). So 'lmdown' switches need to be carefully used. For Ex: 1. To shutdown a specific 'lmgrd': $lmdown -c <lmgrd port>@<lmgrd server ip address/hostname> or Use specific port for each 'lmgrd' by mentioning in the license file and use that license file in 'lmdown'. SERVER this_host 27010 ANY 2. To shutdown a specific 'vendor daemon': $lmdown -c <vendor license file> -vendor <vendor name> ... View more

Summary Is there any way to increse or decrese the lmgrd and vendor daemon's log verbosity? Question Can you increase / decrease the license server's log file verbosity? The available documentation only refers to the FLEXLM_DIAGNOSTICS envrionment variable, which affects the client side only. Answer You can increase the vendor log verbosity by adding any needed API calls, but you can't decrease the verbosity (the default output is hardcoded by design to enable predictive readability). The FLEXLM_DIAGNOSTICS environment variable actually turns on client logging on a per-job basis (so you wouldn't want to enable that unless you were actually debugging a problem, as it'll create a lot of junk on your client rather quickly otherwise). ... View more

Summary How do you quietly shut down multiple vendor daemons using lmdown? Question How do you quietly shut down multiple vendor daemons using lmdown? Answer Use the lmdown -all option. If multiple servers are specified, it automatically shuts down all of them. -q is implied with -all. Its documented in fnp_LicAdmin.pdf under Chapter 12 Using License Administration Tools. Additional Information Using the -q options, lmdown is still interactive. This is triggered by having two VDs running at the same with license files that do not have a port number in them, then trying to shut down either using -q -c <license file>: C:\Test>lmgrd -local -c VD1.lic -l SLM.log C:\Test>lmgrd -local -c demo.lic -l demo.log C:\Test>lmutil lmdown -q -c VD1.lic lmutil - Copyright (c) 1989-2018 Flexera. All Rights Reserved. [Detecting lmgrd processes...] Port@Host Vendors 1) 27000@or-rgering-w216 merant 2) 27001@or-rgering-w216 demo Server # [a=all, q=quit]? q No server selected, exiting C:\Test>lmutil lmdown -q -c demo.lic lmutil - Copyright (c) 1989-2018 Flexera. All Rights Reserved. [Detecting lmgrd processes...] Port@Host Vendors 1) 27000@or-rgering-w216 merant 2) 27001@or-rgering-w216 demo Server # [a=all, q=quit]? q No server selected, exiting C:\Test> If there's only one server running, -q works fine. The -c <license file> comman fails to identify the VD from a license file if it has no port number. Because lmgrd fails to select the VD, it is forced to become interactive to ask for help on what to shutdown. If it had used the VENDOR directive in the license file, it could have avoided this. ... View more

Summary If TIMEOUT or TIMEOUTALL isn't specified in the options file, is the returned timeout value always 0? Question If TIMEOUT or TIMEOUTALL isn't specified in the options file, is the returned timeout value always 0? Answer If TIMEOUT and TIMEOUTALL value is not specified in the options file, the default value will be zero. ... View more

Summary How do you setup lm_code.h and counted.lic to allow both 11.15.1 and 10.1 FNP clients to checkout the same feature? Question Is there a way to generate a license file that will supply licenses usable by both newer TRL-enabled cliense and older non-TRL enabled clients that were compiled with LM_STRENGTH_DEFAULT? Answer Per p121 of the FNP 11.15.1 Programming Reference of License File-Based Licensing guide: "If you previously used (non-TRL) licenses with the keyword LM_STRENGTH_DEFAULT, a partial migration to TRL is not possible. Instead, you would need to perform a full migration and re-issue new licenses for all clients. For more information, see Migrating to Tamper-Resistant Licensing." ... View more

Summary Why is remaining linger time in lmstat showing wrong whenever license server restarted? Question We noticed the borrow timestamp (linger countdown value) will reset on the server side when the license server restarts. The count restarts, but the license returns at the right time (so it appears to be a problem with lmstat/lmtools reporting of the linger time). Here are the simple reproduction steps (tested FNP 11.15.1 on Windows 64bit). 1) Launch the license server 2) Launch the toolkit client lmborrow to setup the borrow period 3) Launch the toolkit lmflex to borrow the license 4) Check the LMTools?Perform Status enquiry or lmstat 5) Stop the network license server OR restart the OS then start the server 6) Check the Perform Status enquiry or lmstat again 7) Linger count starts over with each restart, but server log checks license in at appropriate time, regardless of linger count Is this expected behavior? Answer This issue was introduced with FNP 11.13.1, where linger time began showing with lmstat, per those release notes. Here is the relevant blurb: ... lmstat and linger time lmstat now displays the remaining linger time for each borrowed license. Syntax: linger (<remaining linger time >/<total linger time >) Example: lmstat.exe ?a ?c counted.lic Output: lmstat - Copyright (c) 1989-2014 Flexera Software LLC. All Rights Reserved. Flexible License Manager status on Tue 4/14/2015 18:36 License server status: 27000@blrfnpdev01 License file(s) on blrfnpdev01: /data/home2/ishan/i_linux_main/FNP/_output/_debug/ 11.13.1.0/main/i86_lsb/counted.lic: blrfnpdev01: license server UP (MASTER) v11.13.1 Vendor daemon status (on blrfnpdev01): demo: UP v11.13.1 Feature usage info: Users of f1: (Total of 4 licenses issued; Total of 1 license in use) "f1" v1.0, vendor: demo, expiry: 1-jan-0 floating license ishan blrfnpdev01 /dev/pts/25 (v1.0) (blrfnpdev01/27000 202), start Tue 4/14 18:36 (linger: 468 / 480) Where total linger time is 480 seconds and remaining time is 468 seconds. (FNP-1951) ... What wasn't mentioned in that documentation (but is mentioned in the related issue FNP-1951) is that there is a limitation: linger time is not preserved across vendor daemon restart and vendor daemon running on machines with different time zones. Per comments on related issue FNP-10681, in general, data that is held 'volatile' (held in vendor daemon memory) will not survive across a vendor daemon restart. The request to modify this behavior was declined as will not fix. ... View more

Summary Is there a way to predictively detect inconsistent trusted storage? Question A publisher wants to add functionality that bridges the time if storage breaks so that their customers can use the system for another 5 days until it finally breaks (kind of a grace period) in order to not turn off critical client systems just because of license infrastructure problems. Is there a way to programmatically (via api) check the integrity of the trusted storage (is it broken, is it untrusted, ...)? What states can such a trusted storage (as a whole) have? or is the state always represented by the content? How can we force these states programmatically within a unit test (eg force a broken trusted storage, force untrusted content, ...)? They can provide an ASR to each customer and have their software automatically switch over to it under these use cases, but are there any methods available to gracefully detect the switchover? Or are they limited to "buffering" a failure and programmatically deciding what to do with it prior to alerting the user to a valid license checkout? Are there other options? Answer To detect inconsistent trusted storage: The API to check whether trusted storage (TS) is trusted is flxActCommonProdLicSpcTrustFlagsGet The state is either trusted or untrusted One way to cause trusted storage to become untrusted is to restore an old version. For example: ? load an ASR ? back up TS ? generate an offline request (increments anchor sequence number) ? restore backed up TS. TS should now incur a RESTORE (anchor) break Also see the attached Trusted Storage recovery best practices white paper (some info is a bit dated, but most is still relevant). Additional Information "trust" is a property of individual fulfillment records, not trusted storage as a whole. This is because FNP allows fulfillment records (FRs) to be created in different trusted sections with different binding and anchoring specifications. Typically, however, customers place FRs in one trusted section and in this case all will lose HOST and/or RESTORE trust together. TIME trust has an added factor - only expiring fulfillments lose TIME trust, not permanent ones. The activation API functions flxActCommonLicSpcPopulateAllFromTS() and flxActCommonProdLicSpcTrustFlagsGet() can be used to determine the trust of each individual fullment record. If an attempt is made to check out a feature and the checkout can only be satisfied from a fulfillment record that has lost trust, the checkout will fail LM_REPAIR_NEEDED. In general it is not possible to determine which FR that was, so best practice in your case would be to load the grace period ASR then in due course repair (or re-install) all FRs that have lost trust. Note that if the grace period ASR uses a trial anchor it can only be used once - a new one will need to be sent to the customer after the repair. If it does not use a trial anchor then exploits exist; some defence can be added by checking whether the grace FR already exists but backup/restore exploits that allow repeated use of the grace FR cannot be defended. ... View more

Summary AMZN_EIP blank on Linux Question On a RHEL 6.5 64bit system, the AMZN_EIP is blank. When using lmadmin 11.12.1 and vendor daemon that were built on the same version, the license manager is no longer working. 15:13:27 (LUMERICL) Wrong hostid on SERVER line for license file: 15:13:27 (LUMERICL) licenses/LUMERICL/LicenseFile.lic 15:13:27 (LUMERICL) SERVER line says AMZN_EIP=54.76.163.82, hostid is AMZN_EIP= 15:13:27 (LUMERICL) Invalid hostid on SERVER line 15:13:27 (LUMERICL) Disabling 1 license from feature eme_engine(0305 5387 0769 6447 ) 15:13:27 (LUMERICL) Disabling 1 license from feature fde_engine(0187 8EE1 1148 1138 ) 15:13:27 (LUMERICL) Disabling 1 license from feature FDTD_Solutions_design(027D CBD0 C79F F963 ) 15:13:27 (LUMERICL) Disabling 1 license from feature FDTD_Solutions_engine(030E 8B25 031F 83BA ) 15:13:27 (LUMERICL) Disabling 1 license from feature Lumerical_DEVICE_design(03EB F132 8F40 9D79 ) 15:13:27 (LUMERICL) Disabling 1 license from feature Lumerical_DEVICE_engine(03E9 6D91 C78B 54F5 ) 15:13:27 (LUMERICL) Disabling 1 license from feature Lumerical_INTERCONNECT_design(0064 E490 BD61 4C17 ) 15:13:27 (LUMERICL) Disabling 1 license from feature Lumerical_INTERCONNECT_engine(0008 830F 2055 CD7D ) 15:13:27 (LUMERICL) Disabling 1 license from feature MODE_Solutions_design(0046 CE5A 9444 A9C8 ) 15:13:27 (LUMERICL) Disabling 1 license from feature varfdtd_engine(038D 2457 7A28 1139 ) Answer The Amazon instance in question gave the following error in the log: 20:37:29 (demo) The HOSTID on the SERVER line needs the server to run in Amazon Cloud environment. 20:37:29 (demo) EXITING DUE TO SIGNAL 60 Exit reason 28 20:37:29 (lmgrd) demo exited with status 60 (HOSTID does not match the license server environment (Cloud|Virtual|Physical)) 20:37:29 (lmgrd) No feature will be served. This error told us the Amazon cloud detection code detected the user wasn't running on Amazon Cloud environment. This could happened when the IPv4 address mapped with the hostname isn't corrected. By default, the IPv4 address of the Amazon instance should match with the default private IP address assigned by Amazon (the hostname of the instance usually gives the hint of default private IP. For example, the default IP is 10.0.0.244 and the hostname is ip-10-0-0-244.eu-west-1.compute.internal). In the case of this Amazon instance, the assigned private IP address is 10.0.0.244. However, the IP address configured inside the /etc/hosts was 10.0.0.158. After the IP address was changed from 10.0.0.158 to 10.0.0.244 in /etc/hosts, the server was able to start with AMZN_EIP. ... View more