simple-evcorr-users — Simple Event Correlator users

Re: [Simple-evcorr-users] PairWithWindow and Multiple Contexts ?

[Risto V. <ris...@ey...>]

On Sat, 9 Feb 2002, Brown, James wrote:

> 
> Hi-

hi James,

as I understand, you would like the PWW rule to handle events
'LEFT a b' and 'RIGHT a b' pairwise, 'LEFT a c' and 'RIGHT a c' pairwise, 
and 'LEFT a d' and 'RIGHT a d' pairwise?

If so, then sec has to be configured to start a separate PWW event 
correlation operation for EACH of these pairs.
With the current configuration, sec will start just ONE operation for all 
these pairs. This is because correlation operations are distinguished by 
keys which include the value of 'desc' parameter.
Currently, the desc parameter is constant (SINGLETONEVENT), and its value 
does not depend on the regexp match. Therefore, 'LEFT a b', 'LEFT a c' and 
'LEFT a d' will ALL be correlated by the same PWW event correlation 
operation. To be more precise, 'LEFT a b' will start the correlation 
operation, and other two LEFT events will be correlated by the same rule.

I sent SIGUSR1 to sec after feeding those three LEFT events, and sec dump 
file (/tmp/sec.dump) looks as follows:

List of active event correlation operations:
============================================================
Key:				sec.conf | 3 | SINGLETONEVENT
Start of correlation operation:	Sun Feb 10 02:40:04 2002
Configuration file:		sec.conf
Rule number:			4
Rule internal ID:		3
Type:				PairWithWindow
Behaviour after 1st match:	don't continue
1st Pattern:			regexp for 1 line(s): 
(?-xism:ONE_OF_TWO:(\S+) (\S+))
Context:			PairOf_a_b
1st Event:			SINGLETONEVENT
1st Action:			shellcmd /bin/echo %s; delete PairOf_a_b; 
Behaviour after 2nd match:	don't continue
2nd Pattern:			regexp for 1 line(s): 
(?-xism:TWO_OF_TWO:(\S+) (\S+))
2nd Context:			PairOf_a_b
2nd Event:			TUPLEEVENT
2nd Action:			shellcmd /bin/echo %s; 
Window:				10 seconds

------------------------------------------------------------
Total: 1 elements

To start a separate PWW operation for every pair, you have to change the 
'desc' parameter to SINGLETONEVENT $1 $2. This yields three separate keys 
when LEFT* events are seen:
sec.conf | 3 | SINGLETONEVENT a b
sec.conf | 3 | SINGLETONEVENT a c 
sec.conf | 3 | SINGLETONEVENT a d

You can use SIGUSR1 signal to see what sec is doing at every timepoint 
you like, this will give you exact picture what event correlation 
operations exist, what contexts are active, etc.

Once there are 3 PWW operations running, another interesting issue arises.
Since they have been generated by the same rule, and have identical 
pattern2 parameter, they will ALL be terminated when matching pattern 
occurs. In your current configuration you have 'context2' parameter which 
could prevent this (if at most one context exists at every timepoint). But 
it would be more convenient to use $1, $2 variables to get the 
backreference values from the first regexp match:

ptype2=regexp
pattern2=TWO_OF_TWO:($1) ($2)

After first regexp match sec will evaluate pattern2, and pattern2 will 
turn into TWO_OF_TWO:(a) (b) (you can see that in /tmp/sec.dump file after you 
have used SIGUSR1 on sec)

Since pattern2 does not contain any regular expression specific symbols, 
the best way of writing this could be

ptype2=substr
pattern2=TWO_OF_TWO:$1 $2

(i.e., use more effective substring search instead of more expensive 
regexp match).

Hope that this information helps, and that I was able to convey the basic 
idea. The difference between rules and event correlation operations is 
also explained in the FAQ (with some examples). FAQ also gives some 
examples how event correlation operations are distinguished from each 
other, and how their keys are calculated.

best regards,
risto

> 
> I'm trying to create several contexts and then
> have a PairWithWindow rule deal with them one
> at a time.  However, after the first PWW rule match,
> the remaining matches don't do anything- and I'm
> left watching the contexts expire one by one.
> 
> Here is the config- apologies for word wrap if any...
> -------------------8<--------------------------------
> 
> # Simulate a true LEFT and create context PairOF_x_y
> type=Single
> ptype=RegExp
> pattern=^LEFT (\S+) (\S+)
> desc=ONE_OF_TWO:$1 $2
> action=shellcmd /bin/echo %s; create PairOf_$1_$2 15 (shellcmd /bin/echo
> Deleting Context PairOf_$1_$2); event %s
> 
> 
> # Simulate a true RIGHT - context already exists.
> type=Single
> ptype=RegExp
> pattern=^RIGHT (\S+) (\S+)
> desc=TWO_OF_TWO:$1 $2
> action=shellcmd /bin/echo %s; event %s
> 
> 
> 
> 
> # Context MUST EXIST when Pattern is seen, otherwise nothing is done.
> type=PairWithWindow
> ptype=regexp
> pattern=ONE_OF_TWO:(\S+) (\S+)
> context=PairOf_$1_$2
> desc=SINGLETONEVENT
> action=shellcmd /bin/echo %s; delete PairOf_$1_$2
> ptype2=regexp
> pattern2=TWO_OF_TWO:(\S+) (\S+)
> desc2=TUPLEEVENT
> action2=shellcmd /bin/echo %s;
> window=10
> -------------------------8<----------------------------------------
> 
> The input stream looks like this:
> 
> LEFT a b
> LEFT a c
> LEFT a d
> RIGHT a b
> RIGHT a c
> RIGHT a d
> ...
> 
> I'd like the LEFT and RIGHT pairs to be handled
> by the PWW rule- but only the first RIGHT pair 
> (RIGHT a b) prints out anything (TUPLEEVENT).  
> The remaining 'RIGHT a c' and 'RIGHT a d'
> don't produce any actions.  The only other activity
> is that the contexts expire.
> 
> Is PWW capable of handling multiple contexts?
> 
> If so- what am I doing wrong?
> 
> 
> Any help appreciated-
> 
> jpb
> ===
> 
> SEC RULES!!!!
> 
> Note:  The information contained in this message may be privileged and
> confidential and protected from disclosure.  If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify us immediately by replying to the message and deleting it from
> your computer. Thank you.  ThruPoint, Inc.
> 

[Simple-evcorr-users] PairWithWindow and Multiple Contexts ?

[Brown, J. <JB...@th...>]

Hi-

I'm trying to create several contexts and then
have a PairWithWindow rule deal with them one
at a time.  However, after the first PWW rule match,
the remaining matches don't do anything- and I'm
left watching the contexts expire one by one.

Here is the config- apologies for word wrap if any...
-------------------8<--------------------------------

# Simulate a true LEFT and create context PairOF_x_y
type=Single
ptype=RegExp
pattern=^LEFT (\S+) (\S+)
desc=ONE_OF_TWO:$1 $2
action=shellcmd /bin/echo %s; create PairOf_$1_$2 15 (shellcmd /bin/echo
Deleting Context PairOf_$1_$2); event %s


# Simulate a true RIGHT - context already exists.
type=Single
ptype=RegExp
pattern=^RIGHT (\S+) (\S+)
desc=TWO_OF_TWO:$1 $2
action=shellcmd /bin/echo %s; event %s




# Context MUST EXIST when Pattern is seen, otherwise nothing is done.
type=PairWithWindow
ptype=regexp
pattern=ONE_OF_TWO:(\S+) (\S+)
context=PairOf_$1_$2
desc=SINGLETONEVENT
action=shellcmd /bin/echo %s; delete PairOf_$1_$2
ptype2=regexp
pattern2=TWO_OF_TWO:(\S+) (\S+)
context2=PairOf_%1_%2
desc2=TUPLEEVENT
action2=shellcmd /bin/echo %s;
window=10
-------------------------8<----------------------------------------

The input stream looks like this:

LEFT a b
LEFT a c
LEFT a d
RIGHT a b
RIGHT a c
RIGHT a d
...

I'd like the LEFT and RIGHT pairs to be handled
by the PWW rule- but only the first RIGHT pair 
(RIGHT a b) prints out anything (TUPLEEVENT).  
The remaining 'RIGHT a c' and 'RIGHT a d'
don't produce any actions.  The only other activity
is that the contexts expire.

Is PWW capable of handling multiple contexts?

If so- what am I doing wrong?


Any help appreciated-

jpb
===

SEC RULES!!!!

Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.

Re: [Simple-evcorr-users] using two Pair rules together

[Risto V. <ris...@ey...>]

Rick Casey wrote:
> 

hi Rick,

> Have enjoyed using Sec up to now on our syslog file; but I'm getting
> into constructing some more complex rules. Here's a question: if I
> have two pairs of events that are related, and I want to count all 4
> events as one because they are all coming from one machine with a
> mutual cause; see syslog messages below.
> 
> I assume this could do one this using a Pair rule, putting the
> hostname in as the context, and using TakeNext action. But what should
> I put in the Action field on the first Pair rule that just acts like a
> null, i.e. no action? Does "logonly" work here? Sec didn't complain
> when I tried that (though it's not documented).

I can see from your rule syntax that you are using sec-1.1 configuration
file format; sec-1.1.2 which is the last release of sec-1.1 supports
"none" as action type if you want to use an empty action. You can, of
course, also use "logonly", because all it does is logging an extra line
to sec's logfile.

> 
> Here's a sample of the four lines I'm trying to condense into one
> taken from my Sec logfile:

[...]

> 
> Notice that the same host, scb4-10c-u2392.int.Colorado.EDU, is the
> source of all four events.
> Also that the two pairs happen within a close time to each other.
> The basic pattern are two pairs:
> First Pair:
> ($hostname) ... LINK-...-UPDOWN ... Interface x/x...changed state to
> down
> ($hostname) ... LINK-...-UPDOWN ... Interface x/x...changed state to
> up
> Second Pair:
> ($hostname) ... LINEPROTO-...-UPDOWN... Interface x/x...changed state
> to down
> ($hostname) ... LINEPROTO-...-UPDOWN... Interface x/x...changed state
> to up
> 
> I basically want to count all four as a single event, while capturing
> the hostname and the interface name into backexpressions to feed to a
> script. Here are my rules (which aren't working correctly, by the way;
> they're my latest attempt...:)):

OK, I see that you want to detect a composite event that is made up of 4
primitive events. Since those 4 primitive events are organized into 2
pairs, there are actually two levels of composite events.

Is timing between paired events important? If so, I would suggest
PairWithWindow rule to be used; e.g., you can set up a window of 60
seconds between "LINK-...-UPDOWN...changed state to DOWN" and
"LINK-...-UPDOWN...changed state to UP", and a window of 30 seconds
between two LINEPROTO-...-UPDOWN events.

If timing is not important, just use Pair rule.

In both cases, I would suggest generating an event (using "event"
action) from both Pair* rules. In that way, you will have two events
(one for the first of the Pair* rules and the other for the second one);
logically, these events will correspond to the first level of composite
events.
For instance, you could create LINK-BOUNCE from the first Pair* rule and
LINEPROTO-BOUNCE from the second Pair* rule.

Once you have created these events, you can use another Pair* rule to
associate them. Btw, would LINK-BOUNCE and LINEPROTO-BOUNCE be ordered
in time in a certain way? If there is no guaranteed ordering between
them, you need two Pair rules - one for the case where LINK-BOUNCE
happens to be first, and another one where LINEPROTO-BOUNCE happens to
be first.

Another, slightly shorter way would be to use just 3 rules combined with
contexts:
1) create the same event (e.g., LINE-X-BOUNCE) from both Pair* rules,
but also create a context that distinguishes one rule from another (the
contexts could have names LINK-BOUNCE-CONTEXT and
LINEPROTO-BOUNCE-CONTEXT)
2) the third rule will match event LINE-X-BOUNCE, provided that both
contexts LINK-BOUNCE-CONTEXT and LINEPROTO-BOUNCE-CONTEXT exist (e.g.,
LINK-BOUNCE-CONTEXT && LINEPROTO-BOUNCE-CONTEXT) is true.

The sample rule base could be as follows (haven't tested it, wrote it
down just to convey the basic idea):

type=pairwithwindow
ptype=regexp
pattern=/pattern for ($hostname) LINK-UPDOWN changed state to down/
desc=$1 linkdown
action=none
ptype2=regexp
pattern2=/pattern for ($hostname) LINK-UPDOWN changed state to up/
desc2=$1 linkup
action2=event $1_LINE-X-BOUNCE; create $1_LINK-BOUNCE-CONTEXT
window=300

type=pairwithwindow
ptype=regexp
pattern=/pattern for ($hostname) LINEPROTO-UPDOWN changed state to down/
desc=$1 lineproto down
action=none
ptype2=regexp
pattern2=/pattern for ($hostname) LINEPROTO-UPDOWN changed state to up/
desc2=$1 lineproto up
action2=event $1_LINE-X-BOUNCE; create $1_LINEPROTO-BOUNCE-CONTEXT
window=300

type=single
ptype=regexp
pattern=(\S+)_LINE-X-BOUNCE
context=$1_LINK-BOUNCE-CONTEXT && $1_LINEPROTO-BOUNCE-CONTEXT
desc=$1 composite event
action=shellcmd counter.pl "interfaceup" "%s"

Hope that this helps. There could be several other ways of doing this,
these were just first thoughts that came into my mind.

best regards,
risto

> 
> # Rule 6. Link-UpDown Rule:
> # This rule works in conjunction with Rule 7.
> # When a machine sends a link-updown message, register the machine by
> # using the node name as the context by which to connect the two
> rules.
> # Wait up to 5 minutes for the second event.
> Pair | TakeNext | regexp | \
> (([\w\-]+\.)+([\w\-]{2,3})\.[cC]olorado\.(edu|EDU)).*%(LINK-.*-UPDOWN.*$)
> | \
> $1 $5 | \
> logonly | \
> regexp | \
> ($1).*(LINEPROTO.*UPDOWN.*changed state to up.*$) | \
> $1 $2 | \
> logonly | 300 \
> ($1)
> 
> # Rule 7. Interface Updown Rule:
> # This rule is a follow-on rule to Rule 6.
> # When a machine sends an interface-updown message, register the
> machine and
> # keep a running total of the interface-updown messages received from
> this machine.
> # This rule uses a pair rule, where the pair of interface up and down
> messages
> # count as a single instance; but it is also a consequence of a
> LINK...UPDOWN
> # event that occurred shortly before.
> # First action is null; only if second action happens is a message
> written.
> Pair | DontCont | regexp | \
> (([\w\-]+\.)+([\w\-]{2,3})\.[cC]olorado\.(edu|EDU)).*%(LINEPROTO.*UPDOWN.*changed
> state to down*$) | \
> $1 $5 | \
> logonly | \
> regexp | \
> ($1).*(LINEPROTO.*UPDOWN.*changed state to up.*$) | \
> $1 $2 | \
> shellcmd counter.pl "interfaceup" "%s" | 300
> 
> I hope what I'm trying to do is fairly simple, in concept; any
> suggestions on how to make this work?
> 
> Thanks!
> --rick casey
> +----------------------------------------------+
> | Rick Casey, grad student, Telecommunications |
> | Univ. of Colorado at Boulder                 |
> | homepage: rtt.colorado.edu/~caseyh           |
> | email: ca...@co...                   |
> | home: 303.499.8852        cell: 303.829.6288 |
> | work: 303.735.3670                           |
> +----------------------------------------------+
> 
> _______________________________________________
> Simple-evcorr-users mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

[Simple-evcorr-users] using two Pair rules together

[Rick C. <ca...@co...>]

Have enjoyed using Sec up to now on our syslog file; but I'm getting
into constructing some more complex rules. Here's a question: if I
have two pairs of events that are related, and I want to count all 4
events as one because they are all coming from one machine with a
mutual cause; see syslog messages below. 

I assume this could do one this using a Pair rule, putting the
hostname in as the context, and using TakeNext action. But what should
I put in the Action field on the first Pair rule that just acts like a
null, i.e. no action? Does "logonly" work here? Sec didn't complain
when I tried that (though it's not documented).

Here's a sample of the four lines I'm trying to condense into one
taken from my Sec logfile:
    15  Tue Feb  5 19:59:15 2002: scb4-10c-u2392.int.Colorado.EDU
LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to down
    16  Tue Feb  5 19:59:15 2002: Executing shell command 'echo.sh
"log" "0%s"' for event 'Feb  5 19:59:15
scb4-10c-u2392.int.Colorado.EDU 8955: Fe
b  5 19:59:15.940 MST: %LINK-3-UPDOWN: Interface FastEthernet0/15,
changed state to down'...
    17  Tue Feb  5 19:59:15 2002: Child 29628 created for command
'echo.sh "log" "0%s"'
    18  Tue Feb  5 19:59:15 2002: Executing shell command 'counter.pl
"interfacedown" "%s"' for event 'scb4-10c-u2392.int.Colorado.EDU
LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15,
changed state to down'...
    19  Tue Feb  5 19:59:15 2002: Child 29630 created for command
'counter.pl "interfacedown" "%s"'
    20  Tue Feb  5 19:59:17 2002: scb4-10c-u2392.int.Colorado.EDU
LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up
    21  Tue Feb  5 19:59:17 2002: Executing shell command 'echo.sh
"log" "0%s"' for event 'Feb  5 19:59:17
scb4-10c-u2392.int.Colorado.EDU 8957: Fe
b  5 19:59:18.055 MST: %LINK-3-UPDOWN: Interface FastEthernet0/15,
changed state to up'...

Notice that the same host, scb4-10c-u2392.int.Colorado.EDU, is the
source of all four events.
Also that the two pairs happen within a close time to each other. 
The basic pattern are two pairs:
First Pair:
($hostname) ... LINK-...-UPDOWN ... Interface x/x...changed state to
down
($hostname) ... LINK-...-UPDOWN ... Interface x/x...changed state to
up
Second Pair:
($hostname) ... LINEPROTO-...-UPDOWN... Interface x/x...changed state
to down
($hostname) ... LINEPROTO-...-UPDOWN... Interface x/x...changed state
to up

I basically want to count all four as a single event, while capturing
the hostname and the interface name into backexpressions to feed to a
script. Here are my rules (which aren't working correctly, by the way;
they're my latest attempt...:)):

# Rule 6. Link-UpDown Rule:
# This rule works in conjunction with Rule 7.
# When a machine sends a link-updown message, register the machine by
# using the node name as the context by which to connect the two
rules.
# Wait up to 5 minutes for the second event.
Pair | TakeNext | regexp | \
(([\w\-]+\.)+([\w\-]{2,3})\.[cC]olorado\.(edu|EDU)).*%(LINK-.*-UPDOWN.*$)
| \
$1 $5 | \
logonly | \  
regexp | \
($1).*(LINEPROTO.*UPDOWN.*changed state to up.*$) | \
$1 $2 | \
logonly | 300 \
($1)


# Rule 7. Interface Updown Rule:
# This rule is a follow-on rule to Rule 6.
# When a machine sends an interface-updown message, register the
machine and 
# keep a running total of the interface-updown messages received from
this machine.
# This rule uses a pair rule, where the pair of interface up and down
messages
# count as a single instance; but it is also a consequence of a
LINK...UPDOWN 
# event that occurred shortly before.
# First action is null; only if second action happens is a message
written.
Pair | DontCont | regexp | \
(([\w\-]+\.)+([\w\-]{2,3})\.[cC]olorado\.(edu|EDU)).*%(LINEPROTO.*UPDOWN.*changed
state to down*$) | \
$1 $5 | \
logonly | \  
regexp | \
($1).*(LINEPROTO.*UPDOWN.*changed state to up.*$) | \
$1 $2 | \
shellcmd counter.pl "interfaceup" "%s" | 300 


I hope what I'm trying to do is fairly simple, in concept; any
suggestions on how to make this work?

Thanks!
--rick casey
+----------------------------------------------+
| Rick Casey, grad student, Telecommunications | 
| Univ. of Colorado at Boulder                 |
| homepage: rtt.colorado.edu/~caseyh           |
| email: ca...@co...                   |      
| home: 303.499.8852        cell: 303.829.6288 |
| work: 303.735.3670                           |
+----------------------------------------------+

[Simple-evcorr-users] sec-2.0.2 released

[Risto V. <ris...@ey...>]

hi all,

after testing sec-2.0.1, I have made some more changes and released the
new version as sec-2.0.2 publicly in the sec home page
(http://kodu.neti.ee/~risto/sec/).

Changes are the following:

* Windows fixes

* Added -fromstart and -nofromstart flags

* Improved SingleWithScript rule: added optional action2 parameter;
  an external program given with 'script' parameter is now supplied
  with the names of all existing contexts (through stdin of the program)

* added check whether dumpfile is a symbolic link

* changed input_shuffled(): fixed file decrease check; sec will now
  exit when some major errors occur (failed stat() and failed sysseek()
  on the input filehandle)


best regards,
risto

[Simple-evcorr-users] sec-2.0.1

[Risto V. <ris...@ey...>]

hi,

I have now released a next version of sec, that fixes Windows bugs 
(thanks, James, for pointing these out!). This new version has also some 
improvements:

- new flag pair -fromstart | -nofromstart. If -fromstart is specified, 
sec always processes files from the beginning. This flag is meaningful 
only when input file is a regular file and -tail option is turned on.

- SingleWithScript rule has been enchanced. You can use an 
optional action2 parameter, which is executed when the script returns 
non-zero. Also, the names of all existing contexts are fed to the standard 
input of the script, helping the script to "see" the current state of sec.

- a check has been added to check whether dumpfile is a 
symbolic link. If it is, nothing is written to a dumpfile.

This version is not directly available on sec home page yet, but at an url 
http://kodu.neti.ee/~risto/sec/sec-2.0.1.tar.gz
I am going to do some additional testing, and if all goes well, I will 
release it to wider public.

I would welcome any comments and suggestions!

best regards
risto

Re: [Simple-evcorr-users] Sec and Cisco Device Fault Manager (DFM)

[Risto V. <ris...@ey...>]

On Fri, 25 Jan 2002, Brown, James wrote:

> 
> Hi All,

hi James,

I have read your mail and I don't know whether I did get things right, but 
I think currently your way of saving the state is the simplest.

As I have understood, pair-relationships between logical network 
elements (A and B) are described in an external database, and you want to 
see the message when one of the elements (say, A) from a pair has gone 
down, and the second element (B) has gone down, too (or you haven't 
received any message from B during t seconds).

The problem with saving the state (i.e. memorizing which pairs have one of 
their elements down) is tricky, because on one hand sec should know this 
(e.g. as context), on the other hand the script that is checking the 
database (when the *other* event arrives) must know this, too!

Unfortunately, sec context will not be useful here, since it is not 
visible for scripts that are called from sec (every script is implemented 
as a separate UNIX process).

The file system is, in fact, only possible place for sharing the state, 
since files (unlike process data segments) are equally visible for all 
processes.

I don't know whether I have understood all aspects of the problem, but for 
me it looks like the file system is currently the only way to solve this 
issue.

Would it help, if I try to introduce a new concept of script that "sees" 
sec contexts (and possibly other data structures)? This concept could be 
helpful when checking network topology databases. Just a rough idea that 
popped into my mind :)

best regards
risto

> 
> My project involves correlating input from Cisco DFM
> where device pairs, such as PORT_A<->PORT_B  and/or
> Interface_C<->PORT_D are concerned.
> 
> Because I don't know the incoming text of ~_A and ~_B
> in every possible case, I have built a SingleWithScript
> rule to look up whether ~_A or ~_B is part of  a pair from 
> the DFM topology database.
> 
> However, to do this I have found I must maintain state
> in the filesystem, by creating a 'flag' file for
> ~_A or ~_B in the filesystem and checking to see
> if it's pair already exists when the *other* event
> comes in.
> 
> The script then stuffs the sec event stream with a
> 'ONE_OF_TWO:~_A' message when the first event
> comes in and 'TWO_OF_TWO:~_B when the other 
> event comes in.  These feed a PairWithWindow
> rule.
> 
> The PairWithWindow rule  waits for
> the 'other end' event.  So the PairWithWindow logic
> is:
> 
>   ~_A AND  (NOT ~_B)  -> generate Port Down announcement
>   ~_A AND  ~_B        -> generate a Pair Down announcement
> 
> 
> -------
> 
> I could not see using a context here because I don't know 
> the 'other end' when the first event comes in, so I don't
> know what to call the context.  
> 
> Is there a simpler way to do this? Or, is there any other 
> way to maintain state between events?
> 
> 
> Thanks,
> jpb
> ===
> Note:  The information contained in this message may be privileged and
> confidential and protected from disclosure.  If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify us immediately by replying to the message and deleting it from
> your computer. Thank you.  ThruPoint, Inc.
> 

[Simple-evcorr-users] Sec and Cisco Device Fault Manager (DFM)

[Brown, J. <JB...@th...>]

Hi All,

My project involves correlating input from Cisco DFM
where device pairs, such as PORT_A<->PORT_B  and/or
Interface_C<->PORT_D are concerned.

Because I don't know the incoming text of ~_A and ~_B
in every possible case, I have built a SingleWithScript
rule to look up whether ~_A or ~_B is part of  a pair from 
the DFM topology database.

However, to do this I have found I must maintain state
in the filesystem, by creating a 'flag' file for
~_A or ~_B in the filesystem and checking to see
if it's pair already exists when the *other* event
comes in.

The script then stuffs the sec event stream with a
'ONE_OF_TWO:~_A' message when the first event
comes in and 'TWO_OF_TWO:~_B when the other 
event comes in.  These feed a PairWithWindow
rule.

The PairWithWindow rule  waits for
the 'other end' event.  So the PairWithWindow logic
is:

  ~_A AND  (NOT ~_B)  -> generate Port Down announcement
  ~_A AND  ~_B        -> generate a Pair Down announcement


-------

I could not see using a context here because I don't know 
the 'other end' when the first event comes in, so I don't
know what to call the context.  

Is there a simpler way to do this? Or, is there any other 
way to maintain state between events?


Thanks,
jpb
===
Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.

Re: [Simple-evcorr-users] Does sec work on Windows NT?

[Risto V. <ris...@ey...>]

On Fri, 18 Jan 2002, Brown, James wrote:

> 
> Hi All,
> 
> Has anyone gotten sec working on NT with any perl distro?

hi James,

two guys have reported that they have used sec on NT/2000 platform. One of 
them was using it with ActivePerl on Win2000 for monitoring EventLog 
messages, and the other one with cygwin perl on NT4.0 (if I remember 
correctly). I have done some testing myself on Win2000 with ActivePerl, 
everything seemed to work fine.

I have to admit that I am using sec mostly on various types of UNIX, and 
since most of its users have applied it in UNIX-like environments, it is 
possible that there are some problem with sec on windows that no-one has 
experienced yet.

If you have problems to get it up and running, please report what perl 
distrubution you are using, and what log messages you have received. That 
would help me to fix the possible bug. I would certainly like to improve 
sec for windows environment, so that people would not be restricted to run 
it on unix only. Please accept my apologies if your first experience with 
sec has been disappointing.

best regards
risto

> 
> Thanks,
> jpb
> ===
> Note:  The information contained in this message may be privileged and
> confidential and protected from disclosure.  If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify us immediately by replying to the message and deleting it from
> your computer. Thank you.  ThruPoint, Inc.
> 

[Simple-evcorr-users] Does sec work on Windows NT?

[Brown, J. <JB...@th...>]

Hi All,

Has anyone gotten sec working on NT with any perl distro?

Thanks,
jpb
===
Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.

[Simple-evcorr-users] sec on HPOV/windows

[Risto V. <ris...@ey...>]

hi,

I have the following question to the list:

Has anyone used sec in combination with HPOV Network Node Manager on
Windows?

Recently, I have received several questions about sec and NNM/Windows
integration. According to NNM manuals it should be possible to generate
trapd.log file on Windows version of NNM (and configure sec to monitor
this file). 
This approach works well for NNM on UNIX, but since I don't have
NNM/Windows up and running, I have been unable to verify this for
Windows as well.

Has anyone used trapd.log (or any other method) for integrating sec with
NNM on Windows? I would be grateful for any feedback, I'll try to update
the FAQ with the received information.

best regards
risto

Re: [Simple-evcorr-users] changing configuration dynamically

[<ris...@ey...>]

On Sat, 29 Dec 2001, Rick Casey wrote:

> Risto,

hi Rick,

> 
>   A question for the list: how can one change sec's configuration file
> dynamically?
> 
>   I know sec has this capability, but do not understand how to do it. The
> last page of the man page discusses using signals to reload the
> configuration file, but I do not see how to make that happen.

Currently, the only way to change the rulebase is to edit the 
configuration files and send a signal to the sec process. If you want to 
do this at runtime without human intervention, you have to write a script 
that is capable of updating configuration files and sending signals. This 
script can then be called as an action from sec rules.

One handy way of making such updates would be to use wildcards for sec 
-conf flag when sec is started, like 

sec -conf=/home/risto/*.conf ...

If you create a new file with suffix .conf and send a signal to sec, 
the pattern *.conf will be re-evaluated, and sec will discover the new 
configuration file you have just created. Putting your changes into a 
separate file is often much more safe than trying to insert something to 
(or delete something from) existing configuration files.

Unfortunately, there is no special rule- or actiontype for creating and 
deleting rules dynamically; but if you know beforehand what rules you are 
likely to need, you can define them in configuration file(s) and use 
contexts to turn them on and off at runtime. Unlike rules, contexts are 
created and deleted dynamically at runtime, and since you can use context 
expressions to activate and deactivate rules, you are able to achieve the 
same effect. The only difference is that the rule definition (with 
appropriate Context parameter) must exist in the configuration file before 
sec is started.

But if you don't want to use the "context approach" and define rules 
beforehand, then the only way of doing updates at runtime is to use 
dedicated script for configuration changes that will be called from sec 
rules.

> 
>   What I'd like to do is suppress messages about an interface that's down
> if a message is received that the node for that interface is down. It will
> involve obtaining the related nodes from a topology databas. This would
> seem to be quite useful; it seems to be what Veritas' NerveCenter does
> with its "downstream alarm suppression", to judge from its white paper
> about their product.

Here a lot will depend how these messages look like.
If the interface down message you want to suppress also contains the node 
name, then you are able to match it and use it as a part of the Context 
parameter.

For instance, you could create context "node_<name>_down" when you receive 
"Node <name> down". When you later observe "Node <name> interface <if> 
down", you can check whether there exists a context for that node:

type=Suppress
ptype=RegExp
pattern=Node (\S+) interface \S+ down
context=node_$1_down

However, if the "interface down" messages do not contain node names, or if 
you want to do topology-based correlation across several nodes, then you 
must have a topology database that describes relations between nodes and 
interfaces.

Sec does not support any topology database format directly in its code, 
but it is possible to use SingleWithScript rules to link topology queries 
to the sec event flow (see also FAQ). I have been thinking about writing a 
plugin for HP OpenView NNM topology database; maybe it is time now to write 
something down :)

I hope I was able to answer your question; if some issues need further 
clarification, feel free to ask!

best regards
risto

> 
> Regards,
> --rick casey

[Simple-evcorr-users] changing configuration dynamically

[Rick C. <ca...@co...>]

Risto,

  A question for the list: how can one change sec's configuration file
dynamically?

  I know sec has this capability, but do not understand how to do it. The
last page of the man page discusses using signals to reload the
configuration file, but I do not see how to make that happen.

  What I'd like to do is suppress messages about an interface that's down
if a message is received that the node for that interface is down. It will
involve obtaining the related nodes from a topology databas. This would
seem to be quite useful; it seems to be what Veritas' NerveCenter does
with its "downstream alarm suppression", to judge from its white paper
about their product.

Regards,
--rick casey
+--------------------------------------------------+
| Rick Casey       Professional Research Assistant |
| CADSWES              http://cadswes.colorado.edu |
| University of Colorado at Boulder                |
| ca...@co...            work 303.735.3670 |
+--------------------------------------------------+

[Simple-evcorr-users] Re: sec.pl and dumpfile

[Risto V. <ris...@ey...>]

> 
> Thanks for writing sec.pl! Looks like a great script so far.
> Havent tested it yet since Im sitting in a hotel room away
> from home using the most god awful network on earth, but I
> did get a chance to review part of the code. Your script
> doesnt check to see if $dumpfile exists before it opens it
> for write. If a user were to create a symlink called
> /tmp/sec.dump and linked it to /etc/passwd or similar and
> $dumpfile wasnt defined in the config file, then files
> could be overwritten if the sec.pl script was run by root
> or the owner of the file in question. Easy fix would be
> to see if sec.dump exists or is a symlink, and bail if it
> does. $pidfile is the same, but isnt defined by default.
> 

That is a very good remark, and I will certainly implement it in the
next minor version. I would welcome any other comments you might have!
(people have not reported anything for a while, which is bad thing, of
course :))

best regards
risto

[Simple-evcorr-users] simple-evcorr-users mailing list created

[Risto V. <ris...@ey...>]

hi,

I have created this mailing list for a general discussion about the use
of Simple Event Correlator. Feel free to ask any questions about the
tool in this mailing list. Since currently there is no separate mailing
list for development issues, you can also post ideas and proposals about
the tool here.

Happy mailing!

best regards
risto

[Simple-evcorr-users] test

[Risto V. <ris...@ey...>]