1. 13 Jul, 2015 1 commit
  2. 06 Jul, 2015 1 commit
  3. 01 Apr, 2015 1 commit
  4. 21 Aug, 2014 2 commits
  5. 01 Aug, 2014 1 commit
  6. 11 Jul, 2014 1 commit
  7. 10 Jun, 2014 1 commit
  8. 28 May, 2014 2 commits
  9. 20 May, 2014 1 commit
  10. 13 May, 2014 1 commit
  11. 08 Apr, 2014 1 commit
  12. 28 Feb, 2014 1 commit
  13. 14 Feb, 2014 1 commit
  14. 24 Jan, 2014 1 commit
    • Helga Velroyen's avatar
      Disabling client certificate usage · 45f75526
      Helga Velroyen authored
      This patch temporarily disables the usage of the client
      SSL certificates. The handling of RPC connections had a
      conceptional flaw, because the certificates lack a proper
      signature. For this, Ganeti needs to implement a CA,
      which is already designed (see design-x509-ca.rst) but
      not implemented yet. This patch keeps most of the
      client certificate infrastructure intact which was already
      created and and can be reused, but just disables the
      actual usage of the certificates in RPC calls till the CA
      is in place.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      45f75526
  15. 20 Dec, 2013 1 commit
    • 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>
      b3cc1646
  16. 17 Dec, 2013 1 commit
  17. 29 Nov, 2013 1 commit
  18. 09 Oct, 2013 1 commit
  19. 04 Oct, 2013 1 commit
  20. 02 Oct, 2013 1 commit
  21. 08 Aug, 2013 1 commit
  22. 29 Jul, 2013 2 commits
  23. 23 Jul, 2013 1 commit
  24. 15 Jul, 2013 1 commit
  25. 03 Jul, 2013 2 commits
  26. 11 Jun, 2013 1 commit
  27. 04 Jun, 2013 1 commit
  28. 28 May, 2013 1 commit
  29. 29 Apr, 2013 1 commit
  30. 26 Apr, 2013 2 commits
  31. 24 Apr, 2013 4 commits
  32. 23 Apr, 2013 1 commit