Working with IBM internal Guardium customers one of our most time consuming aspects of keeping Guardium up and operational is tracking of inactive instances of TCP and shared memory db traffic on Linux. We have alerts setup to monitor and alert on TCP-Shared memory but this only shows traffic pairs and has no ability to repair or try and heal itself. Quite often the issue is the customer updated the Linux kernel without first notifying support, which results in a new KTAP having to be built.
It would be beneficial if we could try and find a better solution for this process.
Here's an idea I have been thinking about.
Create KTAP on demand (KTAP automated build processor).
I understand Flex loading can possible aid in the KTAP process but in some cases may cause issues in itself due to version not being an exact kernel match. What I am proposing is the following. If an exact KTAP build match does not exist in Flex loading then build a new one automatically (on demand) for the customer and add it to FLEX loading. This set of tasks to accomplish this may be complex to try and manage but if we could shave off some of the time it takes to get a new KTAP out to the customer and it's not too costly to do the initial coding and maintenance, maybe it's worth a review to see if this or some else like it might help.
Here's how I envision this (at a high level) and obviously there's more steps to this process..
1) Create a Guardiun function that constantly monitors/detects if KTAP no longer matches kernel, alert on this and automatically verify FLEX loading is enabled
2) Create KTAP on demand function and make it part of the standard Guardium build offering. When step 1 is alerted on automatically start process to verify if a new KTAP needs to be built based on customer system details and what's currently in FLEX loading list
a) Create and maintain master list of all known KTAP versions by distro and make it available to all Guardium boarded systems
b) If Guardium detects KTAP down level initiate, KTAP build on demand pre-process steps to prep for possible build of new KTAP, extract uname -a from target system and any other required details for KTAP compile steps
c) With kernel version from step B Guardium parses master KTAP FLEX load list to determine if exact version already exists. If exact version exists automatically initiate all Guardium process(s) to make it available for use and inform end user system KTAP exists and is available for use
d) If no KTAP exact match exists in FLEX loading list send results from step B to start KTAP on demand process to automatically build new KTAP based on system and compiler details. After KTAP build completion automatically run tests on new KTAP using virtual test system and add new KTAP to FLEX loading list and inform end user system new KTAP exists. If new KTP build fails send notice to end user system with instructions to open PMR due to build failure.
Other options are brainstorm alternative ways for Guardium to monitor TCP, shared memory and local traffic outside of the kernel to avoid dependencies on kernel versions
1) Would LKM (loadable kernel module) work?
2) Would virtual-device, event mechanism or system call strategy allow parsing of db traffic?
3) Are there any other alternative hooks or bootstraps outside the kernel that could possible work?
Are other strategies being investigated to help manage this issue? Can cognitive features of Watson help with this process?
Do not place IBM confidential, company confidential, or personal information into any field.