Bug 477768
Summary: | incorrect parsing of options to /usr/sbin/snmpd | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | adam winberg <adam.winberg> |
Component: | net-snmp | Assignee: | Jan Safranek <jsafrane> |
Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | andrebug, bugzilla, cward, jnansi, juanino, ksrot, ohudlick, pb, ross, rvokal, sputhenp, syeghiay, tao, voetelink |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-02 11:42:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
adam winberg
2008-12-23 15:04:29 UTC
You are right, the parsing of -LS options is different now. It's caused by upstream patch at https://sourceforge.net/tracker/index.php?func=detail&aid=1806336&group_id=12694&atid=312694. This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP. Looks like this bug is not solved in final 5.3 My setup: OPTIONS="-LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid" Worked with 5.2, broken in 5.3 net-snmp-5.3.2.2-5.el5 That's really bad and very unexpected. Yeah, I know... The report came too late to catch 5.3 update, sorry. Do you know how to replace my config string with a working one? I played a litte bit around, but did not find a solution.... '0-4' in '-LS 0-4 d' is IMHO a bit useless, 0 is the default -> you can use '-LS 4d' to get LOG_WARNING and above to syslog. oops, wrong bug, clearing NEEDINFO. I noticed another thing. I had changed some settings in /etc/snmpd/snmpd.options: OPTIONS="-LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a" This seemed to work for me, (the file in the /etc/snmpd and the options for snmpd) with 5.3, the location /etc/snmpd is no longer recognized, although it seems the rpm has moved my file from /etc/snmpd to /etc/sysconfig I have now modified the options file in /etc/sysconfig to: OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a" and it now starts.... Can someone clarify what the "d" stands for in this line? OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a" I'm assuming thats the "debug" facility? Can someone help me out here. I have modified /etc/sysconfig/snmpd.options to OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a" I see snmpd running: root 762 0.1 0.3 27484 6628 ? Sl 21:00 0:00 /usr/sbin/snmpd -Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a But I'm still getting messages in /var/log/messages about polling: Feb 18 21:14:18 <hostname> snmpd[762]: Connection from UDP: [<ip>]:1104 Originally we just had the following line in /etc/snmp/snmpd.options: OPTIONS="-LS 4 d -Lf /dev/null -p /var/run/snmpd -a" > But I'm still getting messages in /var/log/messages about polling:
> Feb 18 21:14:18 <hostname> snmpd[762]: Connection from UDP: [<ip>]:1104
"Connection from UDP:" can be suppressed by adding "dontLogTCPWrappersConnects 1" to your snmpd.conf file. And by removing '-a' from command line, you get less messages too.
What if I want to only log improperly authenticated connections? This appears to stop logging for everything... (In reply to comment #15) > What if I want to only log improperly authenticated connections? This appears > to stop logging for everything... OPTIONS="-LS 4d -Lf /dev/null -p /var/run/snmpd -a" Unfortunately, those options do not work in the 5.2 version of snmpd (5.3.1). As stated in the original description by Adam, "Although this works with the 5.3.2.2-4 version it does not work with previous versions, where the log options must be stated separately. This makes for an unnecessary difficult upgrade of a large environment. " # /usr/sbin/snmpd -LS 4d -Lf /dev/null -p /var/run/snmpd.pid -a invalid syslog facility: - Usage: /usr/sbin/snmpd [OPTIONS] [LISTENING ADDRESSES] Version: 5.3.1 Web: http://www.net-snmp.org/ Email: net-snmp-coders.net We still a set of options that will work in both 5.3.1 and 5.3.2 which reduce logging to only improperly authenticated connections. From what I've read, this is only possible with a patch that accepts the old style '-LS 4 d' option. Jan, Can we get a test package incorporating this fix? Fujitsu would like to verify the same. ~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative. Event posted on 07-13-2009 12:20pm EST by aimamura
Mr.Furuta
> Could you please verify the fix on RHEL5.4 Beta?
We confirmed that this problem was corrected in RHEL5.4 Beta.
The Snmpd operated correctly by below options.
OPTIONS="-LS 5 d -Lf /dev/null -p /var/run/snmpd.pid -a"
OPTIONS="-LS 5d -Lf /dev/null -p /var/run/snmpd.pid -a"
Regards,
Yosuke Hori
Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech
This event sent from IssueTracker by jnansi
issue 255609
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1372.html |