JBoss Discovery

[FrankvH]

Hello,

Currently Jboss is not discovered by the Flexera agent. This caused due to the nature of the Jboss jar files. But as Jboss is installed on many servers and there is no visibility on these installations.

Does any of you found a workaround?

Thanks

Frank

[kclausen]

@FrankvH  - Make sure that you have File Scanning turned on.  Start by finding on of the servers where you know that JBOSS Server is installed.  Go to the EVIDENCE tab of the device and then go to the File Evidence. 

On Linux, search for a folder name such as "JBOSS".  You will hopefully find some folder names.

For one customer POC, we were able to create recognition rules by looking for the following patterns to identify that JBoss Enterprise Application Server was installed.  For example, we mapped the following File Evidence patterns to identify that JBoss Enterprise Application Server 7.2 was installed:

/apps/foundation/jboss-eap-7.2%

/apps/jboss-eap-7.2%

On Windows, we found the following folder and mapped an EXE file in this folder to JBoss Enterprise Application Server 6.4

D:\jboss-eap-6.4\modules\system\layers\base\native\sbin\

[bfaller]

Thank you, but:

jboss/wildfly are concerned with license issues, and agent don't see them because of JAR mecanism instead of executable mode.

On Unix, when names of directories don't contain Jboss or when there are no executable files in these directories, there is nothing in inventory...

[kclausen]

When File Scanning is enabled, the FlexNet Agent captures any file where the execute bit is set.  Even with a JAVA application like JBOSS, there should be some files in this state.

Start on 1 or 2 servers where you know that JBOSS is installed, and work with a Server Admin to identify the folder where JBOSS is installed.  Within FlexNet, you can then go to the Evidence tab of one of the servers and on the File Evidence sheet, search for that folder name and see if it is captured.  As in my earlier example, you can then create File Evidence matching patterns to identify if JBOSS is installed.

[bfaller]

Thank you, I do agree.

But we have hundreds of servers with Jboss/wildfly and no executable files in the directories.

And even if you have the directory (like /Tools/wildfly/), you don't have any information about the files Inside the directory...

[ChrisG]

A technique I've used to enable software to be identified on non-Windows operating systems which for whatever reason does not have any  unique files with an executable bit set is:

• Put some process in place which will create an stub file with a particular name on the filesystem with the executable bit set if the software you're interested in is installed. If the software is managed/deployed centrally, this could potentially be arranged through the deployment process. Or if you have a mechanism to run a shell script across devices where the software may be installed, something that behaves along the following lines may do it:
  

  mkdir -p /var/opt/managesoft/install-flags
  if [ -d /Tools/wildfly ]; then # Detect if software is installed
      touch /var/opt/managesoft/install-flags/wildfly-installed
      chmod +x /var/opt/managesoft/install-flags/wildfly-installed
  else
      rm -f /var/opt/managesoft/install-flags/wildfly-installed
  fi​

• Configure a file recognition rule in the ARL to recognize the file you have created ("wildfly-installed" in the above example).

This approach has some obvious drawbacks (including that it is requires something to be done on all computers the software may be installed on), but may be suitable in some circumstances.

[kidharb]

Thanks Chris, that will help in certain scenarios. Another tip is to name the file with the currently installed version.

Do you have a solution for the case where JBoss is installed and no-one else knows about it, thereby making it impossible to use the solution above?

Also what if the default installation directory is changed to remove the version number?

Is it in the pipeline to scan for something like "jboss-modules.jar" and use a hash to verify the installed version?

Also this jboss-modules.jar does have the executable bit set but I do not see it in the "File" discovery section in the Excel extract.

[ChrisG]

In my experience it would be somewhat unusual for a .jar file to have the executable bit set, but if it is set in your case and the FlexNet agent is configured to gather file details from the directory containing the file then you would be able to configure a file evidence matching rule to recognize installations of an application based on the file.

You can specify the file size as part of the matching rule to distinguish different files with the same name but different sizes. It isn't currently possible to specify a checksum/hash used for matching files. If you come across situations where the file size is not sufficiently disambiguating to identify a file version then you could consider writing up an idea to be able to match on checksum - go to the Product > Ideas section of Flexera Community to do that.

[FrankvH]

Hello,

I already created an jboss improvement idea. 

https://flexerasfdc.ideas.aha.io/ideas/ITAM-I-170

Feel free to vote and/or comment 🙂

Regards

Frank