Certain Java based probes sometimes take a long time to acquire a port
search cancel

Certain Java based probes sometimes take a long time to acquire a port

book

Article ID: 5470

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

Symptoms may include one or more of the following:

  • Probes take a long time to acquire a port.  These probes include, but are not limited to
    • ace
    • maintenance_mode
    • mon_config_service
    • nis_server
    • sla_engine
    • trellis

 

  • Exceptions in the probe's log file as follows:

Jan 17 13:02:22:478 FATAL [main, udm_manager] java.lang.RuntimeException: java.sql.SQLRecoverableException: IO Error: Connection reset

at com.nimsoft.db.ConnectionFactory.getConnection(ConnectionFactory.java:153)

at com.nimsoft.udm.schema.DbInitializer.initDatabase(DbInitializer.java:56)

...

 

  • Errors when logging into UMP as follows

An unknown error has occurred. 

Refreshing your browser may resolve the issue. 

 

Details: 

com.firehunter.ump.exceptions.DataFactoryException : null 

Info: 

 

SELECT DISTINCT aa.nimid, aa.alarmSource FROM umpAlarmAnnotations aa 

 

 

Stack Trace: 

java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist 

 

  • For probes that consume data from queues, a hub connection from that probe may not be observed in the hub->Status->subscribers/Queues tab.

 

  • Executing the following command does not return an immediate result

head -n1 /dev/random

 

  • Executing the following command consistently shows numbers in the low hundreds or lower.

cat /proc/sys/kernel/random/entropy_avail

Environment

LinuxOracle 11gNote that this issue has been observed and reproduced in the above environment, but may occur in any environment that requires encryption and uses a blocking random number generator.

Cause

The JDBC 11g needs about 40 bytes of secure random numbers, gathered from /dev/random, to encrypt its connect string.  In systems where there are no keyboard or mouse inputs, it is possible that the OS is unable to generate enough entropy noise to fulfill this encryption request.

Resolution

This fix involves forcing the JVM to utilize a non-blocking random number generator (/dev/urandom) vs the blocking random number generator (/dev/random).  To do this, perform the following steps:

  1. Edit /opt/nimsoft/jre/jre7/lib/security/java.security
  2. Scroll down to securerandom.source
  3. Edit the value to /dev/../dev/urandom
  4. Save the file
  5. Restart UIM
* In the case of 8.51 jre1.8 is deployed by default and the java.security file would be 
located in /opt/nimsoft/jre/jre8u102/lib/security

Additional Information

There are numerous topics related to the the security concerns of random vs urandom.  Testing has shown that urandom is still very secure and that in most environments, hundreds of megabytes of randomness must be generated before numbers became predictable enough to fail a FIPS-140 test.  For most environments, utilizing urandom will result in acceptable levels of cryptography and performance.

 

Please see the following page for detailed information on random vs urandom:

http://www.2uo.de/myths-about-urandom/

 

If additional levels of security are required, then there are no options within the UIM product that can resolve this issue.  It must be dealt with on the operating system level and involve creating additional sources for entropy.  Please see the following Wikipedia page for options on ways to accomplish this goal:

https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators

Powered by Wolken Software