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). 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 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? > 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
