#
#	There are lots of options in this file.  All you have to have is a set
#	of nodes listed {"node ...}
#	and one of {serial, bcast, mcast, or ucast}
#
#	ATTENTION: As the configuration file is read line by line,
#		   THE ORDER OF DIRECTIVE MATTERS!
#
#		   In particular, make sure that the timings and udpport
#		   et al are set before the heartbeat media are defined!
#		   All will be fine if you keep them ordered as in this
#		   example.
#
#
#       Note on logging:
#       If any of debugfile, logfile and logfacility are defined then they
#       will be used. If debugfile and/or logfile are not defined and
#       logfacility is defined then the respective logging and debug
#       messages will be loged to syslog. If logfacility is not defined
#       then debugfile and logfile will be used to log messges. If
#       logfacility is not defined and debugfile and/or logfile are not
#       defined then defaults will be used for debugfile and logfile as
#       required and messages will be sent there.
#
#	File to write debug messages to
#debugfile /var/log/ha-debug
#
#
# 	File to write other messages to
#
#logfile	/var/log/ha-log
#
#
#	Facility to use for syslog()/logger 
#
logfacility	local0
#
#
#	A note on specifying "how long" times below...
#
#	The default time unit is seconds
#		10 means ten seconds
#
#	You can also specify them in milliseconds
#		1500ms means 1.5 seconds
#
#
#	keepalive: how long between heartbeats?
#
#keepalive 2
keepalive 2
#
#	deadtime: how long-to-declare-host-dead?
#
#deadtime 30
deadtime 10
#
#	warntime: how long before issuing "late heartbeat" warning?
#	See the FAQ for how to use warntime to tune deadtime.
#
#warntime 10
#
#
#	Very first dead time (initdead)
#
#	On some machines/OSes, etc. the network takes a while to come up
#	and start working right after you've been rebooted.  As a result
#	we have a separate dead time for when things first come up.
#	It should be at least twice the normal dead time.
#
#initdead 120
initdead 120
#
#
#	nice_failback:  determines whether a resource will
#	automatically fail back to its "primary" node, or remain
#	on whatever node is serving it until that node fails.
#
#	The default is "off", which means that it WILL fail
#	back to the node which is declared as primary in haresources
#
#	"on" means that resources only move to new nodes when
#	the nodes they are served on die.  This is deemed as a
#	"nice" behavior (unless you want to do active-active).
#
#nice_failback on
#
#	hopfudge maximum hop count minus number of nodes in config
#hopfudge 1
#	
#
#	Baud rate for serial ports...
#	(must precede "serial" directives)
#
#baud	19200
#
#	serial	serialportname ...
#serial	/dev/ttyS0	# Linux
#serial	/dev/cuaa0	# FreeBSD
#serial	/dev/cua/a	# Solaris
#
#	What UDP port to use for communication?
#		[used by bcast and ucast]
#
#udpport	694
udpport	694

#
#	What interfaces to broadcast heartbeats over?
#
bcast	eth0		# Linux
#bcast	eth1 eth2	# Linux
#bcast	le0		# Solaris
#bcast	le1 le2		# Solaris
#
#	Set up a multicast heartbeat medium
#	mcast [dev] [mcast group] [port] [ttl] [loop]
#
#	[dev]		device to send/rcv heartbeats on
#	[mcast group]	multicast group to join (class D multicast address
#			224.0.0.0 - 239.255.255.255)
#	[port]		udp port to sendto/rcvfrom (no reason to differ
#			from the port used for broadcast heartbeats)
#	[ttl]		the ttl value for outbound heartbeats.  This affects
#			how far the multicast packet will propagate.  (1-255)
#	[loop]		toggles loopback for outbound multicast heartbeats.
#			if enabled, an outbound packet will be looped back and
#			received by the interface it was sent on. (0 or 1)
#			This field should always be set to 0.
#		
#
#mcast eth0 225.0.0.1 694 1 0
#
#	Set up a unicast / udp heartbeat medium
#	ucast [dev] [peer-ip-addr]
#
#	[dev]		device to send/rcv heartbeats on
#	[peer-ip-addr]	IP address of peer to send packets to
#
#ucast eth0 192.168.1.2
#
#
#	Watchdog is the watchdog timer.  If our own heart doesn't beat for
#	a minute, then our machine will reboot.
#
#watchdog /dev/watchdog
#
#       "Legacy" STONITH support
#       Using this directive assumes that there is one stonith 
#       device in the cluster.  Parameters to this device are 
#       read from a configuration file. The format of this line is:
#
#         stonith <stonith_type> <configfile>
#
#       NOTE: it is up to you to maintain this file on each node in the
#       cluster!
#
#stonith baytech /etc/ha.d/conf/stonith.baytech
#
#       STONITH support
#       You can configure multiple stonith devices using this directive.
#       The format of the line is:
#         stonith_host <hostfrom> <stonith_type> <params...>
#         <hostfrom> is the machine the stonith device is attached
#              to or * to mean it is accessible from any host. 
#         <stonith_type> is the type of stonith device (a list of
#              supported drives is in /usr/lib/stonith.)
#         <params...> are driver specific parameters.  To see the
#              format for a particular device, run:
#           stonith -l -t <stonith_type> 
#
#
#	Note that if you put your stonith device access information in
#	here, and you make this file publically readable, you're asking
#	for a denial of service attack ;-)
#
#
#stonith_host *     baytech 10.0.0.3 mylogin mysecretpassword
#stonith_host ken3  rps10 /dev/ttyS1 kathy 0 
#stonith_host kathy rps10 /dev/ttyS1 ken3 0 
#       
#	Tell what machines are in the cluster
#	node	nodename ...	-- must match uname -n
#node	ken3
#node	kathy
node	sysclus.intersolutions.stpn.soft.net
node	sysclus-2.intersolutions.stpn.soft.net
#
#	Less common options...
#
#	Treats 10.10.10.254 as a psuedo-cluster-member
#
#ping 10.10.10.254
#
#	Started and stopped with heartbeat.  Restarted unless it exits
#				with rc=100
#
#respawn userid /path/name/to/run