Brown, James wrote:
> Hi Tim,
>
> What I've done in the past is to set up two SEC units (reading syslog)
> and have one unit periodically (via. calendar rule) send the other unit a
> message
> through syslog (like a heartbeat message) that created a context on the
> receiving system.
>
I believe I would eventually do something with snmp traps since I am
dealing with an NMS. So how would something like below work?
#
# Set variable on SEC startup or restart
#
type=single
desc=set variable for peer host on startup
ptype=regexp
pattern=SEC_(STARTUP|RESTART|SOFTRESTART)
context=[ SEC_INTERNAL_EVENT ]
eval=%HeartbeatPeer (\
$myhost=`/bin/hostname`; \
chomp($myhost); \
if ($myhost =~ /^ego/) { \
return "alterego" ; \
} else { \
return "ego"; \
} \
)
# Rule 1: If you receive notice of SEC_MASTER, then delete context to
make sure only one
# SEC is running as MASTER
type=Single
ptype=RegExp
pattern=SEC_MASTER
action=delete I_am_Master ; create Peer_is_Master 300
# Rule 2: Send out a regular heartbeat
# Action can be a syslog message that only goes to your partner. If
you are the receiver, the context
# I_am_master blocked.
#
# rlogger.pl -h remotehost -facility daemon.notice -tag SEC_MASTER
#
type=calendar
time=0,5,10,15,20,25,30,35,40,45,50,55 * * * *
context=!Peer_is_Master
desc=send heartbeat to peer
action=spawn rlogger.pl -h %HeartbeatPeer -f facility daemon.notice -tag
SEC_MASTER ;\
create I_am_Master 300
# Rule 3: If the context I_am_Master is set, then you as master must act
type=Pair
ptype=RegExp
pattern=NODE (\S+) IF (\S+) DOWN
desc=Interface $2 is down at node $1
context=I_am_Master
action=shellcmd notify.sh "%s"
ptype2=SubStr
pattern2=node $1 interface $2 up
desc2=Interface $2 is up at node $1
action2=shellcmd notify.sh "%s"
window=86400
Regards,
Tim Peiffer
Network Support Engineer
Office of Information Technology
University of Minnesota/NorthernLights GigaPOP
>
> A calendar rule on the receiving system checked every two minutes for the
> existence of the context created by the rule for the heartbeat.
>
> If the context expired, that means the sender (may have) died and it took
> appropriate action.
>
> I did this same thing on both systems, so they were both sending heartbeats
> and checking on each other.
>
> I don't have access to those systems anymore, so I can't give you a
> set of rules, but it was fairly easy to set up.
>
> You can use a set up like this to enable only the 'master' syslog to
> access a database or perform system activities.
>
> Hope this helps,
> Jim B.
>
>
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED] on behalf of Tim Peiffer
> Sent: Tue 8/12/2008 2:07 AM
> To: [email protected]
> Subject: [Simple-evcorr-users] duelling correlators?
>
>
>
> I am in a position where I have redundant NMS operations, redundant DNS
> servers, redundant ... well you get the picture.. Anyway, in order to
> have redundant log and event handlers, I would either need to accept
> dual actions, or look for a way of building in master/slave,
> active/active or active/passive members. This brings me to the point.
> I am getting twice as many notification actions as I need and I am
> interested in cutting down further and still have redundant operations.
> Is there a 'best practice' involving redundant SEC hosts, and
> signalling between them? Does anyone have of a working model that I
> could use?
>
> Thanks in advance,
> Tim Peiffer
> Network Support Engineer
> Office of Information Technology
> University of Minnesota/NorthernLights GigaPOP
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
>
>
>
> 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.
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
