communities and traps in sub-agents
I am configuring AdventNet SNMP agents to be statically invoked
sub-agents by the Master Agent under Solaris 2.6/2.7. One question that has come up with some of the developers working with me on this regarding
access control lists & communities is this:
We already have communities and ACLs configured for use with the
sub-agents. Is it necessary to also configure the Master Agent with the
same ACLs, or will they just forward PDUs to the sub-agents and let
them handle the access control, if the Master Agent has no communties configured in their ACL?
Also related is trap forwarding -- we currently have the agents sending traps directly to hosts. Will this interfere with the Master Agents and its way of handling trap forwarding, or can we just bypass that altogether? We're hoping to have to avoid doing any reinstrumenting of the sub-agents here.
Thanks.
-- Brett
[936 byte] By [
bmccoy] at [2007-11-26 5:52:18]
# 1
Brett,
I would ensure that the subagent.rsrc file would contain, "security=/etc/snmp/conf/subagent.acl" line for redirecting the subagent security to this file.
Also please start /usr/lib/snmpdx with a -d 4 or mibiisa with -d 4 and subagent with -d 4 to debug the agents that you have built and the master agent to figure out the exact flow of traps, security etc.
Ensure you have all the patches etc. loaded for thr sepcific version of SEA that you have.
Thanks
Sujeet (Sun DTS)
# 2
Ok, more questions:
1) Does the referenced sub-agent ACL need to be in the same format as the Master Agent ACL, as specified on page 4-6 of the SEA User's Manual?
2) Regarding the trap configuration syntax in the Master Agent's ACL, where do the trap-nums come from? We have nothing in our MIBs that correspond to those
# 6
Hi!
It appears to me that Solstice enterprise agent does not verify the the relation between the manager and the community name. It it true, or is it false?
In my subagent acl file I specified acl as :
acl = {
{
communities = comm1
access = read-only
managers = *
}
{
communities = comm2
access = read-write
managers = *
}
}
I wrote another acl file to specify against the "security" variable in the subagent resource file.
Here I specified acl as :
acl = {
{
communities = comm1
access = read-only
managers = mac1
}
{
communities = comm2
access = read-write
managers = mac2
}
}
I specified this acl file in the security variable in the subagent resource file as :
security = "/etc/snmp/conf/myagnt1.acl"
I had a manager installed in host "mac1". However in the manager, I specified the read as well as write community as comm2 instead of comm1. You would see that comm2 has read-write access while comm1 has read-only. When I tried to perform a SET operation from my manager at "mac1", it was successful.
I could see from the debug prints of the master agent and the subagent that the community was received as comm2. The master agent passed the message to the subagent (it did not verify that the manager does not belongs to the community which it is claming to be). At the subagent of course this validation is not possible since all requests are received from localhost and the operation was successful.
Anybody has any ideas?
Thanks
Arijit
asen5 at 2007-7-6 13:02:43 >
