Bug 677466 - [RFE] Enable native MySQL server support for net-snmp.
Summary: [RFE] Enable native MySQL server support for net-snmp.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: net-snmp
Version: 6.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-14 21:59 UTC by Travis Gummels
Modified: 2018-11-14 14:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-16 02:31:45 UTC
Target Upstream Version:


Attachments (Terms of Use)
Patch to net-snmp spec file to enable native mysql support. (918 bytes, application/octet-stream)
2011-02-14 22:04 UTC, Travis Gummels
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.