Bug 477768

Summary: incorrect parsing of options to /usr/sbin/snmpd
Product: Red Hat Enterprise Linux 5 Reporter: adam winberg <adam.winberg>
Component: net-snmpAssignee: Jan Safranek <jsafrane>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: andrebug, bugzilla, cward, jnansi, juanino, ksrot, ohudlick, pb, ross, rvokal, sputhenp, syeghiay, tao, voetelink
Target Milestone: rcKeywords: 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
Description of problem:
In our environment we have used to following options to /usr/sbin/snmpd: ' -LS n d -Lf /dev/null -p /var/run/snmpd.pid -a' to get snmpd to use syslog and log from notice priority level. With version net-snmp-5.3.2.2-4.el5 this generates an error, 'invalid syslog facility:', and snmpd fails. The separate 'n' and 'd' in the log (-L) option must be specified like 'nd' to make it work. 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. 

Version-Release number of selected component (if applicable):
net-snmp-5.3.2.2-4.el5

How reproducible:
Always

Steps to Reproduce:
1. install net-snmp-5.3.2.2-4.el5
2. try to start snmpd with '/usr/sbin/snmpd -LS n d -Lf /dev/null -p /var/run/snmpd.pid'
3. 
  
Actual results:
Start of snmpd fails. 

Expected results:
Start of snmpd succeeds.

Additional info:

Comment 1 Jan Safranek 2009-01-07 12:22:31 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.

Comment 2 RHEL Program Management 2009-01-07 12:52:37 UTC
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.

Comment 3 Jan Safranek 2009-01-08 10:54:18 UTC
Fixed upstream: http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=17350

Comment 4 Peter Bieringer 2009-01-22 11:57:16 UTC
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.

Comment 5 Jan Safranek 2009-01-22 12:11:05 UTC
Yeah, I know... The report came too late to catch 5.3 update, sorry.

Comment 6 Peter Bieringer 2009-01-22 13:47:16 UTC
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....

Comment 7 Jan Safranek 2009-01-22 14:27:12 UTC
'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.

Comment 8 Jan Safranek 2009-01-22 14:43:50 UTC
oops, wrong bug, clearing NEEDINFO.

Comment 9 andrebug 2009-01-26 23:12:48 UTC
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....

Comment 12 Jerry Uanino 2009-02-14 18:24:40 UTC
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?

Comment 13 Ross 2009-02-18 21:16:15 UTC
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"

Comment 14 Jan Safranek 2009-02-20 13:47:01 UTC
> 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.

Comment 15 Ross 2009-03-03 20:16:31 UTC
What if I want to only log improperly authenticated connections? This appears to stop logging for everything...

Comment 16 Jan Safranek 2009-03-10 12:17:39 UTC
(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"

Comment 17 Jason 2009-03-17 12:27:46 UTC
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.

Comment 18 Jatin Nansi 2009-03-31 00:53:54 UTC
Jan,
Can we get a test package incorporating this fix? Fujitsu would like to verify the same.

Comment 20 Chris Ward 2009-07-03 18:19:03 UTC
~~ 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.

Comment 21 Issue Tracker 2009-07-16 02:17:07 UTC
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

Comment 24 errata-xmlrpc 2009-09-02 11:42:06 UTC
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