Fix template issue in IPv6 host header.
ipvs_syncd_cmd uses memset() to zero the daemonrule buffer before
populating it and sending it up. daemonrule is malloc()ed by
ipvs_start(). ipvs_start() can bail early if it can't communicate with
ipvs. Neither place which call ipvs_start() check the return value,
allowing them to walk straight into a NULL pointer deref.
Without inhibit_on_failure on a real_server, when the server is marked
down existing TCP connections to it are simply blackholed. Hence
inhibit_on_failure: by setting the weight to zero no new connections
are sent to that server, but because the server isn't completely
removed from the table existing connections are allowed to continue.

The same problem exists with sorry_server. When a real_server comes
back up the sorry_server is removed from the pool and existing
connections are blackholed. Instead of continued service, which may
usually be a fast response indicating overload, the client must engage
in a lengthy wait for the connection to time out. It would be better
in many cases to allow the sorry_server connections to complete
naturally.

Luckily the code is structured well enough that all is required to get
this behaviour is to set the inhibit member of the sorry_server
structure, which is mostly just a change to the config file parser.
unify logging of RS and VS

This fixes the bug of displaying a FWM service as [x.x.x.x]:0,
where x.x.x.x is the first RS of that service
unify connection options among checkers

All the remote checkers (TCP, HTTP/SSL, SMTP) now have the same set of connection options:
 * connect_ip (new to TCP, HTTP)
 * connect_port
 * bindto
 * bind_port  (new)
 * connect_timeout (new to SMTP)

All of them are optional with reasonable defaults.
The patch is designed for simplicity in adding a new option.

Since the connect_ip could be inequal to the RS address and, worse, the same for all RSes,
the endpoint is now logged as [RS]:rport, not the [connect_ip]:connect_port.
fwmark connection option
make SO_MARK a compile-time option
documentation for generic connection opts
vrrp: Fix sync of interface status flag when using VMAC interface

There is a chance that the VMAC interface status flags (up/down) could be
different from the base interface flags.
This patch will only change the VMAC interface status flags when the base
interface is changed.

Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
random delay before doing the first check

every RS check is registered with a random delay
between 0 and vs->delay_loop seconds. It helps
avoiding multiple simultaneous checks to the same RS server.
Merge pull request #78 from jonasj76/vmac-reflect

VMAC and base interface status flags can be out of sync
Merge pull request #76 from jsgh/master

fix segfault if ipvs can't be started
vrrp: Fix initial interface status flag value for VMAC interface

In commit a05a503, "vrrp: Fix sync of interface status flag when using VMAC
interface", no inital value for the VMAC interface status flag was set. Due
to that the VMAC interface flags shall follow the base interface, the base
interface status flags value shall be copied to the VMAC interface status
flags after the VMAC interface has been created.

Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
Merge pull request #79 from jonasj76/vmac-reflect-2

Fix initial interface status flag value for VMAC interface
Revert "Honor preempt_delay setting on startup."

This reverts commit c7a985db4136b374dbee25caa39aa121bc16fb7d, and
fixes #80.

This commit resulted in two individual bugs:

1) A keepalived instance coming on-line would not transition to MASTER
state until the preempt_delay duration had passed, even though there was
no already existing VRRP speaker in MASTER state on the link. In other
words, it changed the semantics of preempt_delay from a delay that only
took place before *preemption* of another VRRP speaker, to a delay that
unconditionally took place after Keepalived came online. The
keepalived.conf manual page has always documented the former meaning,
which is also IMHO the only one that you would intuitively expect.

2) The preempt_delay was applied when a Keepalived process was reloading
its configuration following the recipt of SIGHUP. If the Keepalived
instance was in MASTER state before the reload, it would cease
transmitting VRRP hellos for the duration of preempt_delay, but *not*
actually remove the virtual addresses from the network interfaces. This
in turn resulted in any backup VRRP speakers on the links transition to
the MASTER state while preempt_delay was still in effect on the original
MASTER that was reloaded, thus creating a service-impacting split-brain
scenario where the virtual addresses are present and active on multiple
VRRP speakers simultaneously.

If the functionality that c7a985d aimed to implement really is needed in
Keepalived, it should instead be implemented using a separate
configuration setting independent from preempt_delay. An appropriate
name for this new setting could be for example "startup_delay" or
"initial_delay". However, it could also be implemented in the init
script, by starting keepalived with e.g. "sleep N && keepalived" where N
would be the desired duration of the initial/startup delay.
Merge pull request #82 from toreanderson/fix-preempt_delay

Revert "Honor preempt_delay setting on startup."
vrrp: Proper restore of VMAC interface properties on SIGHUP

On SIGHUP the VMAC flag and base ifindex for a VMAC interface was lost.

Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
Merge pull request #84 from jonasj76/vmac-sighup

Proper restore of VMAC interface properties on SIGHUP
vrrp: Let only base interface change the VMAC interface status flags

The interface status flags for a VMAC interface shall only be changed by the
base interface, never by reading the actual VMAC interface flags.

Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
Merge pull request #85 from jonasj76/vmac-startup

vrrp: Let only base interface change the VMAC interface status flags