Bug 677466

Summary: [RFE] Enable native MySQL server support for net-snmp.
Product: Red Hat Enterprise Linux 6 Reporter: Travis Gummels <tgummels>
Component: net-snmpAssignee: Jan Safranek <jsafrane>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: jwest
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-16 02:31:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch to net-snmp spec file to enable native mysql support. none

Description Travis Gummels 2011-02-14 21:59:44 UTC 
1. Customer Name

LLNL

2. What is the nature and description of the request?

Enable MySQL server support for net-snmp.

3. Why does the customer need this? (List the business requirements here)

LLNL makes extensive use of net-snmp in their environment.  They desire the increased reliability direct access to MySQL could provide for their infrastructure.  Currently they are already handling traps by sending them to a MySQL table via the "traphandle" directive with a locally written external program:

http://net-snmp.sourceforge.net/docs/man/snmptrapd.conf.html

According to the above document, the snmptrapd daemon blocks while executing traphandle commands, which may result in missed traps.  Having the snmptrapd natively insert trap messages has some advantages:

1) The code responsible for getting traps to the database is maintained by the
   net-snmp developers.  This saves us developer time.

2) It's written in C as part of the daemon.  This allows for more efficient use
   of hardware resources, since an external program will not be forked and
   executed.

3) It's non-blocking, and as such, there is less of a chance that traps will
   be missed.


4. How would the customer like to achieve this? (List the functional
requirements here):

Red Hat make appropriate code updates to the spec file for net-snmp so it is built with MySQL support and any dependencies are satisfied at installation.

5. For each functional requirement listed in question 4, specify how Red
Hat and the customer can test to confirm the requirement is successfully
implemented.

Install net-snmp server package in LLNL environment (Red Hat has access to the hyperion cluster) and log snmp traps in to an MySQL database using the net-snmp MySQL interface.

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

Not that I could locate.

7. How quickly does this need resolved? (desired target release)

6.2

8. Does this request meet the RHEL Inclusion criteria (please review)

yes

9. List the affected packages

net-snmp-5.5-27.el6.1
Comment 1 Travis Gummels 2011-02-14 22:04:02 UTC 
Created attachment 478721 [details]
Patch to net-snmp spec file to enable native mysql support.
Comment 2 Jan Safranek 2011-02-15 09:56:22 UTC 
It sounds reasonable. While mysql-libs are quite huge, they won't pull large dependencies. I'll enable MySQL in Fedora and if I don't get significant complaints, I'll add it to RHEL 6 as well.
Comment 5 Jan Safranek 2011-02-17 11:44:08 UTC 
(In reply to comment #0)
> Having the snmptrapd
> natively insert trap messages has some advantages:
> 
> 1) The code responsible for getting traps to the database is maintained by the
>    net-snmp developers.  This saves us developer time.
> 
> 2) It's written in C as part of the daemon.  This allows for more efficient use
>    of hardware resources, since an external program will not be forked and
>    executed.
> 
> 3) It's non-blocking, and as such, there is less of a chance that traps will
>    be missed.

On second thought, all of above can be easily achieved in embedded perl. Open MySQL connection on snmptrapd startup and register a trap handler which stores the trap in the database. It requires the customer to write all this code, but it looks to me simple enough and few lines in perl could do it... See http://search.cpan.org/~hardaker/NetSNMP-TrapReceiver-5.0401/TrapReceiver.pm

The perl is executed internally in snmptrapd (=no forking), it can be reasonably fast (low chance of missing something), but it keeps the maintenance costs on the customer.