don hammer wrote:
Hi again,
On Tue, 12 Oct 2004 13:33:20 -0400, Users Robert Story <[EMAIL PROTECTED]> wrote:
Either way, you should be able to find the difference. I seem to recall one release/pre-release not properly setting the default port for traps. That might be the problem...
Ah. Okay, that's a good place for me to start looking. Thanks!
Not presently, but there are two interesting idea there. One (sending to multiple ip addresses from the command line) has been brought up before. The other, using a conf file, is new. I'm not sure that reading snmpd.conf would be a good idea, but reading a snmptrap.conf that specifies trap destinations is an interesting idea. You might wnat to submit those as feature requests (or code them up and submit a patch).
Hmm. I had thought that snmpd.conf would be a good file to read, since that already specifies trap destinations for traps sent out using library calls from the agent/subagent. Is there any functionality to be gained by repeating these definitions in a different configuration file (snmptrap.conf)? It seems a likely point of confusion for future users - potentially requiring the setting of essentially the same information in multiple locations (well, if there's any chance that they'll be using an agent and the snmptrap executable on the same machine, anyway).
What about moving it up a level into snmp.conf, or if we are spwaning more config files then maybe snmptools.conf. The applications should be capable of ignoring config lines that they are not interested in, and there are the module specific tags that have become a topic of discussion lately to keep things organized. Either adding tag seperated sections to snmp.conf or doing the same with app specific sectons in a new conf file sounds reasonable at least to me.
Given the current 'all or nothing' approach to traps (using the library calls, a trap is sent to all destinations configured in the snmpd.conf file, with filters as the only way to select a subset of destinations, correct?), it seems a logical extension to say that the destinations configured in the configuration file used by the agent for sending traps are necessarily the same as those used for sending traps using snmptrap. Or maybe that's an unnecessary restriction? Perhaps a new snmptrap.conf, which is somehow 'included' or read by the agent, so the information can be removed from snmpd.conf directly?
I think that making such an assumption would sqash some flexability. The system(s) you are testing might not be the regular production trap recievers, no? I like the idea of a new config file, but I think it could be shared amongst the applications, opinions?
I might well be missing something obvious here, though. My current use of snmptrap is really a workaround to simplify the code and communications between processes in our software architecture; it might be somewhat unusual to be running an agent _and_ using the other net-snmp tools/binaries (like snmptrap) on the same system, so two configuration files might end up being simpler and more understandable. What do you think?
Bingo! I don't think in a practical situation that using a box with the agent running on it to test another system is all that uncommon. I know that I do it quite often.
Regards, Andy
If you have the current values, you can specify them on the command line. If you are asking if it can query the agent for the values, it doesn't do that (and it wouldn't be a good idea anyway).
Yeah, you're probably right. I came up with a big, convoluted example of why one might want to do it, with watchdog-style processes and the like, then decided that it would be easier to simply have a channel of communication open with the agent and let it send them itself, rather than using the snmptrap executable. In our case, it was simpler to just get them from our 'back end' directly and pass them on the command line, which is what I've now done, and they seem to be working, mostly (thanks again!).
Donovan Winch.
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
