update docs and help text to include 'operator' (#4712)

command/operator_generate_root.go

@@ -367,7 +367,7 @@ func (c *OperatorGenerateRootCommand) provide(client *api.Client, key string, dr
 	if !status.Started {
 		c.UI.Error(wrapAtLength(
 			"No root generation is in progress. Start a root generation by " +
-				"running \"vault generate-root -init\"."))
+				"running \"vault operator generate-root -init\"."))
 		return 1
 	}
 

command/operator_init.go

@@ -408,7 +408,7 @@ func (c *OperatorInitCommand) consulAuto(client *api.Client, req *api.InitReques
 		c.UI.Output(wrapAtLength(fmt.Sprintf(
 			"Discovered %d uninitialized Vault servers with Consul service name "+
 				"%q. To initialize these Vaults, set any one of the following "+
-				"environment variables and run \"vault init\":",
+				"environment variables and run \"vault operator init\":",
 			len(uninitedVaults), c.flagConsulService)))
 		c.UI.Output("")
 
@@ -481,8 +481,8 @@ func (c *OperatorInitCommand) init(client *api.Client, req *api.InitRequest) int
 		c.UI.Output("")
 		c.UI.Output(wrapAtLength(
 			"It is possible to generate new unseal keys, provided you have a quorum " +
-				"of existing unseal keys shares. See \"vault rekey\" for more " +
-				"information."))
+				"of existing unseal keys shares. See \"vault operator rekey\" for " +
+				"more information."))
 	} else {
 		c.UI.Output("")
 		c.UI.Output("Success! Vault is initialized")

command/operator_rekey.go

@@ -52,7 +52,7 @@ func (c *OperatorRekeyCommand) Synopsis() string {
 
 func (c *OperatorRekeyCommand) Help() string {
 	helpText := `
-Usage: vault rekey [options] [KEY]
+Usage: vault operator rekey [options] [KEY]
 
   Generates a new set of unseal keys. This can optionally change the total
   number of key shares or the required threshold of those key shares to
@@ -491,7 +491,7 @@ func (c *OperatorRekeyCommand) provide(client *api.Client, key string) int {
 	if !started {
 		c.UI.Error(wrapAtLength(
 			"No rekey is in progress. Start a rekey process by running " +
-				"\"vault rekey -init\"."))
+				"\"vault operator rekey -init\"."))
 		return 1
 	}
 
@@ -758,8 +758,8 @@ func (c *OperatorRekeyCommand) printUnsealKeys(client *api.Client, status *api.R
 		c.UI.Output(wrapAtLength(fmt.Sprintf(
 			"The encrypted unseal keys are backed up to \"core/unseal-keys-backup\"" +
 				"in the storage backend. Remove these keys at any time using " +
-				"\"vault rekey -delete-backup\". Vault does not automatically remove " +
-				"these keys.",
+				"\"vault operator rekey -delete-backup\". Vault does not automatically " +
+				"remove these keys.",
 		)))
 	}
 

command/operator_seal.go

@@ -21,7 +21,7 @@ func (c *OperatorSealCommand) Synopsis() string {
 
 func (c *OperatorSealCommand) Help() string {
 	helpText := `
-Usage: vault seal [options]
+Usage: vault operator seal [options]
 
   Seals the Vault server. Sealing tells the Vault server to stop responding
   to any operations until it is unsealed. When sealed, the Vault server

command/rotate.go

@@ -21,7 +21,7 @@ func (c *OperatorRotateCommand) Synopsis() string {
 
 func (c *OperatorRotateCommand) Help() string {
 	helpText := `
-Usage: vault rotate [options]
+Usage: vault operator rotate [options]
 
   Rotates the underlying encryption key which is used to secure data written
   to the storage backend. This installs a new key in the key ring. This new
@@ -34,7 +34,7 @@ Usage: vault rotate [options]
 
   Rotate Vault's encryption key:
 
-      $ vault rotate
+      $ vault operator rotate
 
   For a full list of examples, please see the documentation.
 

command/server.go

@@ -108,9 +108,9 @@ Usage: vault server [options]
 
   This command starts a Vault server that responds to API requests. By default,
   Vault will start in a "sealed" state. The Vault cluster must be initialized
-  before use, usually by the "vault init" command. Each Vault server must also
-  be unsealed using the "vault unseal" command or the API before the server can
-  respond to requests.
+  before use, usually by the "vault operator init" command. Each Vault server must
+  also be unsealed using the "vault operator unseal" command or the API before the
+  server can respond to requests.
 
   Start a server with a configuration file:
 

website/source/docs/concepts/dev-server.html.md

@@ -24,8 +24,8 @@ in-memory). It is only made for development or experimentation.
 The properties of the dev server:
 
   * **Initialized and unsealed** - The server will be automatically initialized
-    and unsealed. You don't need to use `vault unseal`. It is ready for use
-    immediately.
+    and unsealed. You don't need to use `vault operator unseal`. It is ready
+    for use immediately.
 
   * **In-memory storage** - All data is stored (encrypted) in-memory. Vault
     server doesn't require any file permissions.

website/source/docs/concepts/pgp-gpg-keybase.html.md

@@ -51,7 +51,7 @@ To generate unseal keys for Keybase users, Vault accepts the `keybase:` prefix
 to the `-pgp-keys` argument:
 
 ```
-$ vault init -key-shares=3 -key-threshold=2 \
+$ vault operator init -key-shares=3 -key-threshold=2 \
     -pgp-keys="keybase:jefferai,keybase:vishalnayak,keybase:sethvargo"
 ```
 
@@ -100,7 +100,7 @@ This is your unseal key in plain-text and should be guarded the same way you
 guard a password. Now you can enter your key to the `unseal` command:
 
 ```
-$ vault unseal
+$ vault operator unseal
 Key (will be hidden): ...
 ```
 
@@ -135,7 +135,7 @@ without ASCII armoring) or binary. Once saved to disk, the path to these files
 can be specified as an argument to the `-pgp-keys` flag.
 
 ```
-$ vault init -key-shares=3 -key-threshold=2 \
+$ vault operator init -key-shares=3 -key-threshold=2 \
     -pgp-keys="jeff.asc,vishal.asc,seth.asc"
 ```
 
@@ -180,6 +180,6 @@ This is your unseal key in plain-text and should be guarded the same way you
 guard a password. Now you can enter your key to the `unseal` command:
 
 ```
-$ vault unseal
+$ vault operator unseal
 Key (will be hidden): ...
 ```

website/source/docs/concepts/seal.html.md

@@ -43,7 +43,7 @@ decrypt the data.
 
 ## Unsealing
 
-The unseal process is done by running `vault unseal` or via the API.
+The unseal process is done by running `vault operator unseal` or via the API.
 This process is stateful: each key can be entered via multiple mechanisms
 on multiple computers and it will work. This allows each shard of the master
 key to be on a distinct machine for better security.

website/source/docs/concepts/tokens.html.md

@@ -13,7 +13,7 @@ can be used directly or [auth methods](/docs/concepts/auth.html)
 can be used to dynamically generate tokens based on external identities.
 
 If you've gone through the getting started guide, you probably noticed that
-`vault server -dev` (or `vault init` for a non-dev server) outputs an
+`vault server -dev` (or `vault operator init` for a non-dev server) outputs an
 initial "root token." This is the first method of authentication for Vault.
 It is also the only auth method that cannot be disabled.
 
@@ -50,7 +50,7 @@ type of token within Vault that can be set to never expire without any renewal
 needed. As a result, it is purposefully hard to create root tokens; in fact, as
 of version 0.6.1, there are only three ways to create root tokens:
 
-1. The initial root token generated at `vault init` time -- this token has no
+1. The initial root token generated at `vault operator init` time -- this token has no
    expiration
 2. By using another root token; a root token with an expiration cannot create a
    root token that never expires

website/source/intro/getting-started/deploy.html.md

@@ -191,17 +191,17 @@ nature of the algorithm, Vault doesn't know if it has the _correct_ key until
 the threshold is reached.
 
 Also notice that the unseal process is stateful. You can go to another computer,
-use `vault unseal`, and as long as it's pointing to the same server, that other
-computer can continue the unseal process. This is incredibly important to the
-design of the unseal process: multiple people with multiple keys are required to
-unseal the Vault. The Vault can be unsealed from multiple computers and the keys
-should never be together. A single malicious operator does not have enough keys
-to be malicious.
+use `vault operator unseal`, and as long as it's pointing to the same server,
+that other computer can continue the unseal process. This is incredibly
+important to the design of the unseal process: multiple people with multiple
+keys are required to unseal the Vault. The Vault can be unsealed from multiple
+computers and the keys should never be together. A single malicious operator
+does not have enough keys to be malicious.
 
-Continue with `vault unseal` to complete unsealing the Vault. To unseal the
-vault you must use three _different_ keys, the same key repeated will not work.
-As you use keys, as long as they are correct, you should soon see output like
-this:
+Continue with `vault operator unseal` to complete unsealing the Vault. To unseal
+the vault you must use three _different_ keys, the same key repeated will not
+work. As you use keys, as long as they are correct, you should soon see output
+like this:
 
 ```text
 $ vault operator unseal
@@ -249,9 +249,9 @@ token_renewable    false
 token_policies     [root]
 ```
 
-As a root user, you can reseal the Vault with `vault seal`. A single operator is
-allowed to do this. This lets a single operator lock down the Vault in an
-emergency without consulting other operators.
+As a root user, you can reseal the Vault with `vault operator seal`. A single
+operator is allowed to do this. This lets a single operator lock down the
+Vault in an emergency without consulting other operators.
 
 When the Vault is sealed again, it clears all of its state (including the
 encryption key) from memory. The Vault is secure and locked down from access.