Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rekey on sealed/uninitialized vault fails with 'not configured for highly-available mode' #4873

Closed
thomasmitchell opened this issue Jul 6, 2018 · 0 comments

Comments

@thomasmitchell
Copy link

Describe the bug
Commit 3c1d57d reintroduced issue #2334
Namely, that attempting to rekey a sealed or uninitialized vault results in a 500 and a complaint about not being in HA mode instead of a 503.

To Reproduce
Steps to reproduce the behavior:

  1. Start vault in server mode.
  2. Attempt to start a rekey operation.

Expected behavior
I expected a 503 to be returned.

Environment:

  • Vault Server Version (retrieve with vault status): 0.10.3
  • Vault CLI Version (retrieve with vault version): 0.10.3
  • Server Operating System/Architecture: darwin/amd64

Vault server configuration file(s):

backend "inmem" {}

disable_mlock = true

listener "tcp" {
  address = "127.0.0.1:8208"
  tls_cert_file = "/var/folders/k5/0b3rp3sd2xx17p2rls0cvjz40000gn/T/vaultkv-test-cert627700549"
  tls_key_file = "/var/folders/k5/0b3rp3sd2xx17p2rls0cvjz40000gn/T/vaultkv-test-key295533024"
}

Additional context
Add any other context about the problem here.

jefferai added a commit that referenced this issue Jul 6, 2018
If we get to respondStandby but we're actually not in an HA cluster, we
should instead indicate the correct status to the user. Although it
might be better to change any such behavior upstream, if any upstream
code manages this state we should still handle it correctly.

Fixes #4873
jefferai added a commit that referenced this issue Jul 6, 2018
If we get to respondStandby but we're actually not in an HA cluster, we
should instead indicate the correct status to the user. Although it
might be better to change any such behavior upstream, if any upstream
code manages this state we should still handle it correctly.

Fixes #4873
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant