Share This:

A customer of mine is interested in discovering not only Software Instances that represent running database software, but also the actual Databases within. You wil often see a core pattern that handles the SI, and then an extended one that handles the deeper Database discovery. For example:

  • Microsoft.SQLServer.SQLServer creates the SI nodes
  • Microsoft.SQLServer_Extended.DatabasesAndTables creates the Database nodes

 

For maximum information, credentials are required to login to the database directly over JDBC. However, for SQL Server, the list of Databases can usually be obtained via WMI:

 

 

Now, my customer was interested in Sybase a while back. There is an option in the Sybase.SybaseASE_Extended module "Use log files for deep discovery if direct query of the database fails" which used to be True by default:

 

 

This interrogates the database software logs for entries that reference database names as they are created. This is good, as again you don't need database credentials for this to work. Unfortunately, we found that Sybase doesn't log when a database is removed, so we were accumulating a list of Databases that existed at some point, but that we couldn't guarentee actually existed at any given scan. Hence, we changed the option to default to False; this was way back in TKU 2016-09.

 

Thus we had to live with no Sybase Database discovery until recently, when the customer wanted to test Sybase credentials. The DBA added some for a test server, and they got... nothing. We were able to get Databases created by providing a default port in the credential, like this:

 

 

but in general we shouldn't have had to do this. The Sybase pattern should have populated fields on the SI:

  • bind_address
  • port

that can then be used by the Extended Sybase pattern. This information is obtained from the interfaces file, such as "/opt/sybase/sydb01/interfaces". In order to get this file path, we need to know the installation root path, "install_root" which should be visible on the process command line. In turn, this was missing because the OS was Solaris 10, and we were suffering from truncated command lines. This was solved by adding "sudo" to the PRIV_PS command in the platform init script, in order to gain elevated permissions. This problem is actually highlighted in the UI with a Discovery Condition:

 

https://bmcapps--c.na117.content.force.com/servlet/servlet.FileDownload?file=00P3n00001ZLnqkEAD

So with this change were we getting very close. Some databases appeared, and versioning started to appear on the Software Instances. Now, it is worth noting that in general (not just Sybase) different databases can be configured to listen on different IPs. And this was the case here, so while we scanned on 192.168.50.66, we could not see some databases on that server that only listened on another IP. We allowed Discovery to contact a different IP than scanned (Discovery Configuration):

 

 

and ensured firewall rules to the server were open for all IPs. On rescan, we could observe under the Integrations section of the 192.168.50.66 Discovery Access, that SQL Results were returned for both that IP and 192.168.50.68:

and, all Sybase Databases were created, fully versioned, on all Sybase Software Instances. Phew - time for a sit down and a nice cup of tea.

 

(IP addresses and database names have been changed to protect the innocent)