1. 14 May, 2014 3 commits
  2. 05 May, 2014 1 commit
  3. 28 Apr, 2014 1 commit
  4. 08 Apr, 2014 1 commit
  5. 02 Apr, 2014 1 commit
  6. 17 Mar, 2014 1 commit
  7. 14 Mar, 2014 3 commits
  8. 11 Mar, 2014 4 commits
  9. 07 Mar, 2014 1 commit
  10. 04 Mar, 2014 1 commit
  11. 28 Feb, 2014 1 commit
  12. 27 Feb, 2014 1 commit
  13. 20 Feb, 2014 1 commit
  14. 14 Feb, 2014 1 commit
    • Helga Velroyen's avatar
      Use node UUID as client certificate serial number · ab4b1cf2
      Helga Velroyen authored
      It turns out, that some implementations of OpenSSL are more
      pedantic in checking the certficates than others. In this
      particular case, the SSL connection could not be
      established when the serial number of the certificates
      was not unique.
      To avoid this problem, this patch extends Ganeti's X509
      infrastructure to set the certificate's serial
      number. In case of client certificates, we now use the
      node's UUID as serial number, because the UUIDs are
      assumed to be unique in a cluster. This is however still
      not complying to how SSL was designed to be used, but at
      least it is a lot better than setting every serial number
      to 1, which was used before and is still used for other
      certificates than the client certificate.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
  15. 07 Feb, 2014 2 commits
  16. 15 Jan, 2014 1 commit
    • Jose A. Lopes's avatar
      Simplify 'GetMasterInfo' RPC · cb8028f3
      Jose A. Lopes authored
      RPC 'GetMasterInfo' returns several fields, namely, 'master_netdev',
      'master_ip', 'master_netmask', 'master_node', and 'primary_ip_family',
      of which only the 'master_node' is actually used.
      In this patch:
      * remove all the other fields and keep only the 'master_node' field.
      * rename RPCs, helper functions (e.g., 'master_info' to 'master_node_name')
      * simplify the the voting algorithm code
      Signed-off-by: default avatarJose A. Lopes <jabolopes@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  17. 20 Dec, 2013 4 commits
    • Helga Velroyen's avatar
      Verify client certificates · a6c43c02
      Helga Velroyen authored
      This patch adds a step to 'gnt-cluster verify' to verify
      the existence and validity of the nodes' client
      certificates. Since this is a crucial point of the
      security concept, the verification is very detailed with
      expressive error messages and well tested by unit tests.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarHrvoje Ribicic <riba@google.com>
    • Helga Velroyen's avatar
      Verify incoming RPCs against candidate map · b3cc1646
      Helga Velroyen authored
      From this patch on, incoming RPC calls are checked against
      the map of valid master candidate certificates. If no map
      is present, the cluster is assumed to be in
      bootstrap/upgrade mode and compares the incoming call
      against the server certificate. This is necessary, because
      neither at cluster initialization nor at upgrades from
      pre-2.11 versions a candidate map is established yet.
      After an upgrade, the cluster RPC communication continues
      to use the server certificate until the client certificates
      are created and the candidate map is populated using
      'gnt-cluster renew-crypto --new-node-certificates'.
      Note that for updating the master's certificate, a trick
      was necessary. The new certificate is first created under
      a temporary name, then it's digest is updated and
      distributed using the old certificate, because otherwise
      distribution will fail since the nodes don't know the
      new digest yet. Then the certificate is moved to its
      proper location.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarHrvoje Ribicic <riba@google.com>
    • Helga Velroyen's avatar
      Extend RPC call to create SSL certificates · d722af8b
      Helga Velroyen authored
      So far the RPC call 'node_crypto_tokens' did only retrieve
      the certificate digest of an existing certificate. This
      call is now enhanced to also create a new certificate and
      return the respective digest. This will be used in various
      operations, among those cluster init and renew-crypto.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarHrvoje Ribicic <riba@google.com>
    • Helga Velroyen's avatar
      Retrieve a node's certificate digest · b544a3c2
      Helga Velroyen authored
      In various cluster operations, the master node needs to
      retrieve the digest of a node's SSL certificate. For this
      purpose, we add an RPC call to retrieve the digest. The
      function is designed in a general way to make it possible
      to retrieve other (public) cryptographic tokens of a node
      in the future as well (for example an SSH key).
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarHrvoje Ribicic <riba@google.com>
  18. 17 Dec, 2013 1 commit
  19. 29 Nov, 2013 1 commit
  20. 14 Nov, 2013 3 commits
  21. 11 Nov, 2013 1 commit
  22. 06 Nov, 2013 1 commit
    • Apollon Oikonomopoulos's avatar
      DRBD: ensure peers are UpToDate for dual-primary · 73e15b5e
      Apollon Oikonomopoulos authored
      DrbdAttachNet supports both, normal primary/secondary node operation, and
      (during live migration) dual-primary operation. When resources are newly
      attached, we poll until we find all of them in connected or syncing operation.
      Although aggressive, this is enough for primary/secondary operation, because
      the primary/secondary role is not changed from within DrbdAttachNet. However,
      in the dual-primary ("multimaster") case, both peers are subsequently upgraded
      to the primary role.  If - for unspecified reasons - both disks are not
      UpToDate, then a resync may be triggered after both peers have switched to
      primary, causing the resource to disconnect:
        kernel: [1465514.164009] block drbd2: I shall become SyncTarget, but I am
        kernel: [1465514.171562] block drbd2: ASSERT( os.conn == C_WF_REPORT_PARAMS )
          in /build/linux-rrsxby/linux-3.2.51/drivers/block/drbd/drbd_receiver.c:3245
      This seems to be extremely racey and is possibly triggered by some underlying
      network issues (e.g. high latency), but it has been observed in the wild. By
      logging the DRBD resource state in the old secondary, we managed to see a
      resource getting promoted to primary while it was:
        WFSyncUUID Secondary/Primary Outdated/UpToDate
      We fix this by explicitly waiting for "Connected" cstate and
      "UpToDate/UpToDate" disks, as advised in [1]:
        "For this purpose and scenario,
         you only want to promote once you are Connected UpToDate/UpToDate."
      [1] http://lists.linbit.com/pipermail/drbd-user/2013-July/020173.html
      Signed-off-by: default avatarApollon Oikonomopoulos <apoikos@gmail.com>
      Signed-off-by: default avatarMichele Tartara <mtartara@google.com>
      Reviewed-by: default avatarMichele Tartara <mtartara@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
  23. 31 Oct, 2013 1 commit
  24. 30 Oct, 2013 2 commits
  25. 29 Oct, 2013 2 commits