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.
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>
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