Bug 67554

Summary:	Upgrade breaks ACL's for UCD-SNMP in a Random Fashion
Product:	[Retired] Red Hat Linux	Reporter:	Brian E. Seppanen <seppanen>
Component:	ucd-snmp	Assignee:	Phil Knirsch <pknirsch>
Status:	CLOSED NOTABUG	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	rvokal
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
URL:	No available URL
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-08-02 02:36:49 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 Brian E. Seppanen 2002-06-27 13:08:06 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-31 i686)

Description of problem:
Upgraded to ucd-snmp-4.2.5-7.72.0 from ucd-snmp-4.2.3-1.7.2.3 on 8 boxes, and on
3 of the boxes, the exact identical ACLS which worked previously no longer
work.   I've standardized my ACL's for UCD-SNMP and distribute a common config
to all boxes.    After upgrading, what used to work no longer does.   I see a
ton of messages in /var/log/messages of ucd-snmp connection refused from <IP
ADDRESS WITH PROPER PERMISSION>.   I resolved the issue on the three broken
boxes by putting the old release back on.    There is no commonality to the
three that I can tell.   One is an SMP box, the other two are not.   They are
all running redhat linux 7.2, although I have experienced a similar problem on
redhat-7.3.   

Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1.  Reinstall ucd-snmp-4.2.5-7.72.0 on the impacted boxes	
2.  run an snmpwalk 
3.   
	

Actual Results:  Cannot take the time to perform these steps on multiple
production boxes.

Additional info:

I have received some reports of unexpected output from snmp output gathered from
php-snmp.

Comment 1 Brian E. Seppanen 2002-07-14 16:26:23 UTC

This is also a problem with redhat-7.3

Comment 2 Phil Knirsch 2002-07-17 12:30:28 UTC

Could you give more information, e.g. attache the ACLs' so that i might be able
to reproduce it?

Otherwise it's nearly impossible for me to even try to fix the problem.

Read ya, Phil

Comment 3 Brian E. Seppanen 2002-07-17 23:07:30 UTC

com2sec local   localhost       community
com2sec net     192.168.1.0/24  community
####
# Second, map the security name into a group name:

#       groupName      securityModel securityName
#group   notConfigGroup v1           notConfigUser
#group   notConfigGroup v2c           notConfigUser

group   MyROGroup       v1      local
group   MyROGroup       usm     local
group   MyROGroup       v2c     local

group   MyROGroup       v1      net
group   MyROGroup       usm     net
group   MyROGroup       v2c     net

group   MyROGroup       v2c     local
group   MyROGroup       v2c     net
####
# Third, create a view for us to let the group have rights to:

#       name           incl/excl     subtree         mask(optional)
view    all            included      .1              80
view    mib2           included      .iso.org.dod.internet.mgmt.mib-2   fc

#       group          context sec.model sec.level prefix read   write  notif

access  MyROGroup       ""      v1        noauth    exact  all  none     all
access  MyROGroup       ""      usm       noauth    exact  all  none     all
access  MyROGroup       ""      v2c       noauth    exact  all  none     all

Comment 4 Brian E. Seppanen 2002-07-17 23:14:21 UTC

ul 17 19:19:42 karelia ucd-snmp[1967]: Connection from 192.168.1.4 REFUSED

Comment 5 Darren Gamble 2002-08-01 21:17:19 UTC

This version of the agent has tcpwrapper support.  From your error message that 
almost certainly appears to be the problem.

Check your hosts.allow and hosts.deny files and make sure you're allowing 
snmpd/snmptrapd connections there as well.  Post a message with your results.

Comment 6 Brian E. Seppanen 2002-08-02 02:31:35 UTC

Previously I had the following 
/etc/hosts.allow entry for snmpd

snmpd: LOCAL 192.168.1.5

LOCAL unfortunately did not satisfy the criteria I thought it would (assume
127.0.0.1 would satisfy LOCAL).   It does work once I explicitly add 127.0.0.1,
etc...

Thanks.   Feel free to Close.

Comment 7 Brian E. Seppanen 2002-08-02 02:36:45 UTC

Previously I had the following 
/etc/hosts.allow entry for snmpd

snmpd: LOCAL 192.168.1.5

LOCAL unfortunately did not satisfy the criteria I thought it would (assume
127.0.0.1 would satisfy LOCAL).   It does work once I explicitly add 127.0.0.1,
etc...

Thanks.   Feel free to Close.

Comment 8 Phil Knirsch 2002-08-04 21:43:08 UTC

OK, closing bug.

Thanks for pointing out the tcpwrapper connection, Darren!

Read ya, Phil