FNP

• How to define License Servers via Environment Variables instead of License File(s)
• Installation Questions
• What is the process for returning equipment and FNP licenses from a customer to a leasing company?

How to define License Servers via Environment Variables instead of License File(s)

There are two environment variables available for the definition of FNP license servers instead of using license files:

• SOCBU_LICENSE_FILE
• LM_LICENSE_FILE

You can define the environment variable in user configuration files like .profile, .bash-profile which can be found in the home directory of the user. This means that the setup is user specific. If another user logs in and uses SmarTest, then this setup is not available. 
If the definition should be independent from the user you need to use a system wide configuration file like /etc/profile.

There are some rules you need to know for the configuration of the variables:

• If you want to define several license servers, they are separated by colons ‘:’.
  Example: you have two license servers, the first one - named licserv - is the license server which provides the normal licenses and the second license server provides bridging or emergency licenses - named licservbridge, then you need to separate them via colons:
  SOCBU_LICENSE_FILE=@licserv:@licservbridge
  
  
• If you do not use the standard ports 27000 - 27009, then you need to configure the used ports like
  SOCBU_LICENSE_FILE=27010@licserv:27011@licservbridge
  
  
• Three-redundancy-licenser server are separated by comma ",".
  Example: you have a three-redundancy-license server with the server names licserv1, licserv2, licserv3 and an standby emergency license server named licservbridge, then the definition will look like
  
  SOCBU_LICENSE_FILE=27000@licserv1,27000@licserv2,27000@licserv3:licservbridge
  
  

  Note: a three-redundancy-license server must have fix ports for each server (this also needs to be defined in the license file on each SERVER line). Therefore you need to configure the port for the three-redundancy-license server also with using the environment variable.

• SOCBU_LICENSE_FILE has precedence before LM_LICENSE_FILE.
  If both environment variables are defined, for example one on a system wide level and the other on the user level, then the definition of SOCBU_LICENSE_FILE will be used by SmarTest.
  
  SOCBU_LICENSE_FILE and LM_LICENSE_FILE have precedence before license files existing in /opt/flexlm/license.
  So if there are license files in /opt/flexlm/license and e.g. SOCBU_LICENSE_FILE is defined then the license server definition of SOCBU_LICENSE_FILE will be used for the license server connection.

Installation Questions

Can I install FNP on a dual boot workstation

Definition dual boot workstation

A dual boot workstation is currently the set-up of two boot instances on the workstation with

• Hypervisor and VM setup for the one instance
• Bare metal setup for the other instance

This setup is available for the following workstations:

• Z640
• Z4G4
• Z4G5

Question: Can I install FNP on a dual boot workstation?

Short answer:

• answer for Z640 and Z4G4: Yes
• answer for Z4G5: No

Reason for the denial for Z4G5: the FNP license server software is not supported on RHEL9, neither on the hypervisor nor on the bare metal operating system. The only possibility is to install the license server on the VM. With PDB 703.0 officially the installation on the VM is allowed. PDB 703.0 the hypervisor will provide a static MAC address for the VM, so if it needs to be re-installed, the same static MAC address will be used for the newly installed VM. A rehosting of the licenses is then not necessary.

Three use cases for Z4G5: 

• If the licenses are needed on both instances (first instance with hypervisor / VM, second instance with RHEL9 bare metal), a central license server needs to be used. Here it is recommended to use FNE or FNX for installation. Advantage for FNE / FNX is that customer can do the rehosting himself/herself.
• If the licenses are only needed on the hypervisor / VM instance only , an FNE or an FNX license server can be installed on the VM. With PDB 703.0 the host ID of the VM will not change with a VM re-installation. Advantage for FNE / FNX is that customer can do the rehosting himself/herself. Installation of an FNP server is also possible, but then a rehosting might be charged.
• If the licenses are needed on the bare metal instance only , you can install an FNE license server on the bare metal system (FNX is also possible, but probably not needed - if SmarTest can use FNE client, it is good to install a native FNE server instead of an FNX server).

For FNX / FNE installation on a dual boot workstation: see Can I install FNE or FNX on a dual boot workstation

What is the process for returning equipment and FNP licenses from a customer to a leasing company?

If a customer plans to return equipment together with licenses to a leasing company, multiple courses of action may apply, depending on the leasing company’s current requirements. The license status will vary based on the specific scenario.

As it is not a FNP-to-FNP rehosting, we suggest opening a LIST ticket for the request

1. The leasing company wants to have the licenses on the FNE server

Here we would recommend adapting the organization to the organization of the leasing company and then to do a migration of the FNP licenses to the FNE server registered/owned by the leasing company. The status of the FNE licenses would be active/deployed.

2. The leasing company currently does not need the licenses 

In this case we would recommend adapting the organization to the organization of the leasing company and then to return the FNP licenses. The status of the FNP licenses would be active/deployed and with the next renewal, the expiration date would be prolonged to 31-Mar-2028. But for sure before this expiration or at the time of expiration, the licenses need to be converted to FNE.

3. You do not know what the leasing company prefers, you just know that the licenses shall be returned to the leasing company 

Then we would recommend the same action as in case 2.