Provided by: corosync_2.3.5-3ubuntu2.3_amd64 bug


       corosync_overview - Corosync overview


       The  corosync  project's  purpose is to implement and support a production quality Revised
       BSD  licensed  implementation  of  a  high  performance  low  overhead  high  availability
       development toolkit.

       Faults occur for various reasons:

       * Application Faults

       * Middleware Faults

       * Operating System Faults

       * Hardware Faults

       The  major focus of high availability in the past has been to mask hardware faults. Faults
       in other components of the system have gone unsolved until Corosync.  Corosync is designed
       for  applications  to  replicate  their  state to up to 16 processors.  The processors all
       contain a replica of the application state.

       The corosync project provides a group message API  called  CPG.   The  project  developers
       recommend  CPG  be  used for most applications.  The CPG service implements a closed group
       messaging model presenting extended virtual synchrony guarantees.

       To manage conditions where the process executing the CPG application  exchange  fails,  we
       provide the Simple Availability Manager (sam) to provide simple application restart.


       The  corosync  executive  must  be  configured.   In  the  directory  conf  in  the source
       distribution are several files that must be copied to  the  /etc/corosync  directory.   If
       corosync is packaged by a distro, this may be complete.

       The  directory contains the file corosync.conf.  Please read the corosync.conf(5) man page
       for details on the configuration options.  The corosync project will work out of  the  box
       with  the  default  configuration options, although the administrator may desire different

       The corosync executive uses cryptographic techniques to ensure authenticity and privacy of
       the  messages.   In  order  for  corosync  to be secure and operate, a private key must be
       generated and shared to all processors.

       First generate the key on one of the nodes:

       unix# corosync-keygen
       Corosync Cluster Engine Authentication key generator.
       Gathering 1024 bits for key from /dev/random.
       Press keys on your keyboard to generate entropy.
       Writing corosync key to /etc/corosync/authkey.

       After this operation, a private key will  be  in  the  file  /etc/corosync/authkey.   This
       private  key  must  be copied to every processor in the cluster.  If the private key isn't
       the same for every node, those nodes with nonmatching private keys will  not  be  able  to
       join the same configuration.

       Copy  the  key  to some security transportable storage or use ssh to transmit the key from
       node to node.  Then install the key with the command:

       unix#:   install   -D    --group=0    --owner=0    --mode=0400    /path_to_authkey/authkey

       If  a  message  "Invalid  digest"  appears  from  the corosync executive, the keys are not
       consistent between processors.

       Finally run the corosync executive.  If corosync is packaged from a distro, it may be  set
       to  start  on  system  start.  It may also be turned off by default in which case the init
       script for corosync must be enabled.


       The corosync libraries have header  files  which  must  be  included  in  the  developer's
       application.   Once  the header file is included, the developer can reference the corosync

       The   corosync   project   recommends   to   distros   to   place   include    files    in


       The  corosync  project  supports both IPv4 and IPv6 network addresses.  The entire cluster
       must use either IPv4 or IPv6 for the cluster communication mechanism.   In  order  to  use
       IPv6,  IPv6  addresses  must  be  specified in the bindnetaddr and mcastaddr fields in the
       configuration file.  The nodeid field must also be set.

       An example of this is: nodeid: 2 bindnetaddr: fec0::1:a800:4ff:fe00:20 mcastaddr: ff05::1

       To configure a host for IPv6, use the ifconfig program to add interfaces: box20:  ifconfig
       eth0 add fec0::1:a800:4ff:fe00:20/64 box30: ifconfig eth0 add fec0::1:a800:4ff:fe00:30/64

       If  the  /64  is  not specified, a route for the IPv6 network will not be configured which
       will cause significant problems.  Make sure a route is available for IPv6 traffic.


       The corosync libraries are a thin IPC interface to the corosync executive.   The  corosync
       executive implements the functionality of the corosync APIs for distributed coming.

       The  corosync executive uses the Totem extended virtual synchrony protocol.  The advantage
       to the end user is excellent  performance  characteristics  and  a  proven  protocol  with
       excellent  reliability.  This protocol connects the processors in a configuration together
       so they may communicate.


       The corosync executive process uses four environment variables during startup.   If  these
       environment variables are not set, defaults will be used.

              This specifies the fully qualified path to the corosync configuration file.

              The default is /etc/corosync/corosync.conf.

              This  specifies the fully qualified path to the shared key used to authenticate and
              encrypt data used within the Totem protocol.

              The default is /etc/corosync/authkey.


       The corosync executive optionally encrypts all messages sent over the  network  using  the
       AES-128  cipher.   The corosync executive uses HMAC and SHA1 to authenticate all messages.
       The corosync executive library uses NSS as a pseudo random number generator.

       If membership messages can be captured by intruders, it is possible to execute a denial of
       service  attack  on  the  cluster.   In  this  scenario,  the  cluster  is  likely already
       compromised and a DOS attack is the least of the administration's worries.

       The security in corosync does not offer perfect  forward  secrecy  because  the  keys  are
       reused.   It  may be possible for an intruder by capturing packets in an automated fashion
       to determine the shared key.  No such automated attack has been published as of  yet.   In
       this scenario, the cluster is likely already compromised to allow the long-term capture of
       transmitted data.

       For security reasons, the corosync executive binary should NEVER be setuid  or  setgid  in
       the filesystem.


       None that are known.


       corosync.conf(5), corosync-keygen(8), cpg_overview(8), sam_overview(8)