Bug 67554 - Upgrade breaks ACL's for UCD-SNMP in a Random Fashion
Upgrade breaks ACL's for UCD-SNMP in a Random Fashion
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Brock Organ
No available URL
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-27 09:08 EDT by Brian E. Seppanen
Modified: 2015-03-04 20:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-01 22:36:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian E. Seppanen 2002-06-27 09:08:06 EDT
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 12:26:23 EDT
This is also a problem with redhat-7.3
Comment 2 Phil Knirsch 2002-07-17 08:30:28 EDT
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 19:07:30 EDT
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 19:14:21 EDT
ul 17 19:19:42 karelia ucd-snmp[1967]: Connection from 192.168.1.4 REFUSED
Comment 5 Darren Gamble 2002-08-01 17:17:19 EDT
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-01 22:31:35 EDT
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-01 22:36:45 EDT
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 17:43:08 EDT
OK, closing bug.

Thanks for pointing out the tcpwrapper connection, Darren!

Read ya, Phil

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