Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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.
(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.