Thank you Bill for your response. When you said that I have configured two separate features, can you explain? How else can we get a logmatch trap by just one directive?
For b), which part of the code has the actual string that is matched? I can probably use it to raise a trap if needed. I have raised a request as suggested by you https://github.com/net-snmp/net-snmp/issues/19 On Fri, Sep 27, 2019 at 11:22 PM Bill Fenner <fen...@gmail.com> wrote: > Hi Gowtham, > > Please file your request at https://github.com/net-snmp/net-snmp/issues . > The reason the info is not present in the trap is because you have > configured two separate features: > > 1. count log file matches in the logMatch table - note that there is no > place in this table for a list of matches - > http://www.net-snmp.org/docs/mibs/ucdavis.html#logMatchTable > 2. report via DISMAN (monitor) when the count goes up > > In order to provide the actual match, the code would have to be changed to > either > a) send the trap from inside the logMatch code, and/or > b) maintain a list of matches in a new table > > so it's not as straightforward as it may sound. > > Bill > > On Tue, Sep 24, 2019 at 2:26 AM Thommandra Gowtham <trgowtham...@gmail.com> > wrote: > >> Hi Jeff, >> >> Can I get a response for the request? >> >> Thanks, >> Gowtham >> >> On Sat, Sep 7, 2019 at 9:23 AM Thommandra Gowtham <trgowtham...@gmail.com> >> wrote: >> >>> Jeff, >>> >>> Thanks for your reply. >>> >>> It was a deliberate mail to net-snmp-coders. Because, I knew about the >>> pattern matching but that would not suffice because we get a trap like >>> below when we give a '.*' in pattern >>> >>> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22 >>> SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired >>> DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match >>> DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: >>> DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: >>> DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1 >>> DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 = >>> STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING: >>> /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9 >>> UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .* >>> >>> For the following config, >>> logmatch loginFailure /var/log/auth.log 30 Failed password for .* >>> and line in log fine as below >>> Sep 5 19:51:43 sshd[23557]: Failed password for root from xx.xx.xx.xx >>> port 41569 ssh2 >>> >>> It will match the string but it will not print the username in the trap >>> data. So, I was looking for any code changes that an be done to make it >>> expand the pattern and then send that data in trap. >>> >>> REgards, >>> Gowtham >>> >>> On Sat, Sep 7, 2019 at 2:26 AM Jeff Gehlbach <je...@opennms.com> wrote: >>> >>>> On 9/5/19 10:58 PM, Thommandra Gowtham wrote: >>>> >>>> > - How can we get more information in a logmatch trap other than the >>>> > pattern matched? >>>> >>>> Making your pattern match more text should do the trick. For example: >>>> >>>> logmatch loginFailure /var/log/auth.log 30 Failed password for .* >>>> >>>> BTW, this kind of question isn't really what the net-snmp-coders list is >>>> for. The net-snmp-users list is a better fit: >>>> >>>> https://sourceforge.net/projects/net-snmp/lists/net-snmp-users >>>> >>>> -jeff >>>> >>>> >>>> _______________________________________________ >>>> Net-snmp-coders mailing list >>>> Net-snmp-coders@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders >>>> >>> _______________________________________________ >> Net-snmp-coders mailing list >> Net-snmp-coders@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders >> >
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
