A new Revenera Community experience is coming on November 25th, click here for more information. The community will be place in read-only mode from Nov 22nd-Nov 25th.
This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Question
How to change the flexnetlsw.wrapper.log location of LLS which currently defaults to the location <LLS_INSTALLATION_DIRECTORY>\server\logs?
Answer
Wrapper logs come from default tomcat of LLS which is in embedded mode and there isn't a direct way to change it as the logfile is under the control of flexnetls.bat (flexnetlsw.exe). However one can workaround this by modifying the logpath i.e "<logpath>%BASE%\logs</logpath> " present in flexnetlsw.xml file located in the server directory.
The server install process generates this flexnetlsw.xml file. So, while doing the above change make sure you do not change anything else in this file. CAUTION:
1)After doing uninstall/reinstall, you need to make sure that the changes are made again as reinstallation may reset this config file.
2) If you remove the line <logpath>%BASE%\logs</logpath>, the log flexnetlsw.wrapper.log, will stop writing.
... View more
Summary
Start/Stop of FlexNet Operation(FNO) is not working using FlexNet setup when FNO is installed in Service mode In Linux systems.
This BUG is applicable only to Linux build of FNO and on any version later than 2018R1 SP1 until 2023R1.
Symptoms
Up on the installation of FNO and after doing configuration using FlexNet Setup (i.e http://localhost:4321/flexnetsetup), when the user tries to click the "Start Server" button present under "System Status", the server doesn't start.
Steps to Reproduce
Install the FlexNet Operation on any Linux system using Linux build.
Launch FlexNet Setup i.e http://localhost:4321/flexnetsetup
Make the configuration present under General and Database tab and make sure to select "Install as a Service" in General tab.
Click "Start Server" from System status in order to start the server
Workaround
Following are few workarounds for the BUG, which can be followed:
Uncheck the config "install as a service" and then use FlexNet Setup to start/stop the FNO services. (OR)
Start the services using standalone.sh located in <FNO_HOME>/components/wildfly/bin folder.
Fix Version and Resolution
BUG will be fixed in future releases and most likely in 2024R1 onwards.
... View more
Here is the high level difference between XT, SDK and Porting kit.
1)CXT is extended kit with predefined methods/APIs to extract information from the platform it's intended for.
2)SDK is a device level code where those methods/APIs are not predefined so that you can determine your own process of collecting information needed during licensing )e.g. host name, time etc.
3)CXT and SDK kits comes as obfuscated source code meaning you do not have visibility to the code of the pre-defined parts of the libraries.
4)Porting Kit is pure source code (nothing obfuscated) and so you can amend this toolkit to build on any platform as long as it follows a 32-bit or a 64-but architecture.
5) CXT = Traditional desktop applications running on mainstream OS.
SDK = IoT devices where there not 'traditional' OS
Porting Kit = Exotic/Propertary OS/Firmware/Kernal
Considering your requirement, I think you can use the .NET XT kit.
... View more
Question
What are the best practices for the CLS instances which are no longer in use by any client but still present in FlexNet Operations (FNO).
Answer
One can follow either of below for the redundant CLS instances:
1) Obsolete the CLS instance can be done through webservices (ManageDeviceService, obsoleteHostRequest call) or UI
The server id will be renamed with suffix to original ID(ex: WS2UFY6GDXXX-OBSOLETE-20230618213543).
This will remove the licenses mapped and return the count back to the line item pool
You can still see the history of the server in FNO UI.
Details of the linked served devices in FNO UI until it makes call to new CLS.
Cannot call CLS APIs for the obsoleted server as it gets deleted from the CLS database.
2) Deleting the Server(CLS) has to be done using webservices. (ManageDeviceService, deleteDeviceRequest call)
This will remove the licenses mapped and return the count back to the line item pool.
You cannot see the previous transaction history nor the served device details. The CLS and its related records are deleted from FNO and CLS database.
Unless there is a need to retain the unused CLS instances details and it's history, we recommend to delete the instance which keeps the database less bulky.
... View more
Summary
Updating the feature overrides say "Vendor String" to current linked feature to CLS doesn't get reflected at CLS /feature endpoint.
Symptoms
After the feature override update, trying to get the feature details from CLS /feature endpoint doesn't reflect the updated value of feature overrides on the feature.
Steps to Reproduce
Create a License Model or use an existing License Model where you do not specify Vendor String, Notice or Serial Number .
Create a feature F1 with No Feature Override.
Create a product P1 linked to the License Model created in Step1 and feature F1 created in step 2.
Create an Entitlement using product P1 to an account say "TEST".
Create a CLS to account "TEST" and link the entitlement to it.
Using the /features endpoint of CLS to query the CLS to observe there is no Feature Override present.
Now go the feature F1 created in Step 2 and update feature Overrides say "Vendor String"
Now up on firing the /feature endpoint one can observe that, the update feature override i.e Vendor String is still not listing as shown in below screenshot.
Workaround
To workaround one can decrement or increment of any add-ons mapped to CLS that will push the feature override updates made to CLS or alternatively one can follow below:
Remove any add-ons or line item mapped to the CLS instances that are affected by the feature override updates and remap.
Once the status changes to License Generated, the update done in feature override reflects on the CLS as highlighted in following screenshot.
Fix Version and Resolution
This will be fixed in upcoming releases for which release version is yet not confirmed. Once the fix version is confirmed, it will be updated here.
... View more
Hi @sanatupadhyay ,
Attachment is missing in the KB. But please have a look of substitution variable here "https://docs.revenera.com/fno_CURRENT/producer/Content/helplibrary/opsSubstVars.htm?Highlight=variable".
Once the License model is created using the desired vendor string, you can associate it to product and then create an entitlement using the same product. Then after you can map the entitlement to device and generate the license. Now this license will have the vendor string information which you need.
I hope this helps.
... View more
Hi @GudelAG_NS,
Can you please open a support ticket for the issue? We may need the Licensing URL and account details to check further, which you can share on the ticket.
Licensing URL can be found from system-->config-->Licensing
Caution: License URL should not be shared here.
... View more
Hi @GudelAG_NS ,
Are you using our Cloud solution or On-Prem Solution? If on-prem, did you also deploy the CLS module?
Apart from this, do you have valid CLS license purchased to be able to use them?
... View more
Hi @GudelAG_NS,
You need to select BOTH for the config "Server deployment choice " which is present in system-->config-->FlexNet Operations-->Embedded Devices-->Server deployment choice to be able to create both LLS as well as CLS in FNO.
... View more
Hi @rwik_2022 and @kweinert ,
You need to delete the Trusted storage files as well, in order to make the FNE enabled .NET client to have the new machine type information stored. The TS files will look like some random characters like "amjgufjswnphbbfjbpujuxaDAADQW2S1S1". You have to delete all such files. The default location of this file is the user (the one who is running the application) home folder or if it is customized, you can check in your capability request for exact path.
In addition to above:
1) If you have already checked out license using LLS, make sure, you delete the old client records from LLS TS, so that client and LLS will have same machine type information to be able to grant license checkouts.
2) If you are using FNO to checkout license, make sure old client is obsoleted/deleted in FNO so that client and FNO will have same machine type information to be able to grant license checkouts.
If this also doesn't help, please create a support ticket, so that we can assist you further.
... View more
Introduction
This article covers the steps to change the Local License Server (LLS) default windows "Service name" and "Display name" partially without impacting other functionalities of LLS. Using these steps customer can change the service name of LLS as per their company policy.
The default LLS "Service name" is "FNLS-<publisher_name>" and default "Display name" is "FlexNet License Server - <publisher_name>.
This article is applicable to LLS versions earlier than 2023.07.
Instructions
To rename the LLS Windows Service name and Display name, the two files pre-install.vbs and flexnetls.bat present in server folder of LLS package needs to be modified as mentioned in following steps before doing installation:
Open the file pre-install.vbs and update the value of "idNode.text" as desired Service name and nameNode.text value as desired Service Display name. In this use case default Service name will be modified to "ReveneraTest-<publisher_name>" and Display Name to "Test LicenseServer Modified_DispName - <publisher_name>" by updating values of idNode.text and nameNode.text respectively as shown in below screenshot.
Open the file flexnetls.bat and update the value of tag "SET SERVICE_NAME=" to the same name which was set in Step 1 for iNode.text. For example, see below screenshot.
After performing above two steps, now one can use flexnetls.bat to install the LLS service with modified Service name and Display name and then can verify the changes from Windows services.
More Information
The <publisher_name> gets replaced with the publisher value present in producer-settings.xml using substitution variables and it is not recommended to modify the publisher name as impacts are unknown.
This is not documented officially in LLS help guide as of 2023.06 release as this name change is not tested end to end at our end. And if customer choses to modify the service, an end to end test is needed at customer end with the their own use cases.
For service name change later to 2023.07 release of LLS please see LLS help guide section "Editing the Local License Server Service Name and Description (Windows Only)"
... View more
Hi Santosh,
The error is because of the mismatch in machine type noted at server than what is set at client. Please check the same in case if FNO has already any entry for the client on which you are trying to activate license and see the machine type for it.
Also see the KB if it helpful "https://community.flexera.com/t5/FlexNet-Embedded-Knowledge-Base/System-machine-type-does-not-match-expected-machine-type-1-4-5-0/ta-p/1037"
... View more
Title: Enable the access logs for FlexNet Operations Introduction: This article shows how a user having admin access to FNO (FlexNet Operations) deployment/machine can enable the WildFly access logs in addition to existing FNO logs to print all the incoming traffic. Instructions: 1) Open the standalone-full.xml located at <INSTALL_DIRECTORY>\FlexNet Operations\components\wildfly\standalone\configuration
2) Look for <host> tag and add a new tag <access-log\> between host tags as shown in attached screenshot below.
3. Restart the WildFly (FNO).
4. Look for logs under <INSTALL_DIRECTORY>\FlexNet Operations\components\wildfly\standalone\log\access-log.log
NOTE: Please enable this as per need basis as we don't provide this feature out of the box and if you enable this, you need to take care of archiving and purging of access logs.
... View more
Question
When we do system restart to load license module, following error occurs:
Licensing exception: Internal error: Error in FNE protocol: PosixMutexImpl::PosixMutexImpl: Could not verify lockfile directory access rights: No such file or directory.
What is causing this error and how to avoid it?
Answer
The error "Could not verify lockfile directory access rights" indicates that your application do not have read/write access to /tmp directory to read the mutex of FNE application. Under the temp directory you will see files starting from "fne.*". These files are needed by FNE application to run. If you think your application have read/write permission under /tmp then its possible that due to some other reason those files are somehow not being loaded. So to fix the issue, please delete those mutex files and restart the application. Doing so will create new mutex files.
... View more
