diff --git a/website/content/docs/api-clients/api.mdx b/website/content/docs/api-clients/api.mdx index d8d79fc27e..14e918faee 100644 --- a/website/content/docs/api-clients/api.mdx +++ b/website/content/docs/api-clients/api.mdx @@ -7,7 +7,7 @@ description: |- # API -Boundary's API is a a JSON-based HTTP API that adheres to a set of standards that are rigidly followed. At its core, it is a standards-compliant JSON API for both input and output. +Boundary's API is a JSON-based HTTP API that adheres to a set of standards that are rigidly followed. At its core, it is a standards-compliant JSON API for both input and output. Before reading this page, it is useful to understand Boundary's [domain model](/docs/concepts/domain-model) to be aware of the terminology used here. @@ -64,7 +64,7 @@ The following method conventions are used within Boundary's API: ### POST -`POST` is used for creating a resource or performing custom actions against a resoruce. When creating a resource, `POST` is used against a collection (`/roles`). When performing a custom action, `POST` is used against a particular resource (`/roles/r_1234567890:set-principals`). +`POST` is used for creating a resource or performing custom actions against a resource. When creating a resource, `POST` is used against a collection (`/roles`). When performing a custom action, `POST` is used against a particular resource (`/roles/r_1234567890:set-principals`). ### PATCH diff --git a/website/content/docs/api-clients/cli.mdx b/website/content/docs/api-clients/cli.mdx index ee22b71eb1..8edb639a02 100644 --- a/website/content/docs/api-clients/cli.mdx +++ b/website/content/docs/api-clients/cli.mdx @@ -8,7 +8,7 @@ description: |- # CLI Boundary's CLI has predictable behavior throughout its various commands. This -page details the common patterns in used in order to help users make better use +page details the common patterns used in order to help users make better use of the CLI. ## Completion diff --git a/website/content/docs/common-workflows/manage-users-groups.mdx b/website/content/docs/common-workflows/manage-users-groups.mdx index 987aaae61d..4785e2d3ce 100644 --- a/website/content/docs/common-workflows/manage-users-groups.mdx +++ b/website/content/docs/common-workflows/manage-users-groups.mdx @@ -35,7 +35,7 @@ steps below.) successful authentication against an account, if there is no user already linked with that account, a user will be automatically created. This may be a nice time-saver, but in other situations (such as when you want Terraform to fully -describe the Boundary resoruces) this may be undesirable, so the steps below +describe the Boundary resources) this may be undesirable, so the steps below walk you through manually making these resources and linking them. A future Boundary update will allow turning off auto-vivification on a per-auth-method basis. diff --git a/website/content/docs/concepts/security/connections-tls.mdx b/website/content/docs/concepts/security/connections-tls.mdx index d2c45a1c47..6f772038d5 100644 --- a/website/content/docs/concepts/security/connections-tls.mdx +++ b/website/content/docs/concepts/security/connections-tls.mdx @@ -31,7 +31,7 @@ It is possible to require client certificates; see the configuration for ## Worker-to-Controller TLS -The service exposed by the a Controller to handle Worker requests takes +The service exposed by the Controller to handle Worker requests takes advantage of the [KMS](/docs/concepts/security/data-encryption) key designated for `worker-auth` within Boundary's configuration file, which must point to the same key on the KMS for both the Controller and the Worker. Security of the diff --git a/website/content/docs/getting-started/connect-to-target.mdx b/website/content/docs/getting-started/connect-to-target.mdx index 63b89c5e1a..45937c8e36 100644 --- a/website/content/docs/getting-started/connect-to-target.mdx +++ b/website/content/docs/getting-started/connect-to-target.mdx @@ -180,5 +180,5 @@ details. ## Next Steps -See our [common workflows](/docs/common-workflows) for in depth discussion on managing scopes, targets, +See our [common workflows](https://learn.hashicorp.com/collections/boundary/common-workflows) for in depth discussion on managing scopes, targets, identities, and sessions. diff --git a/website/content/docs/getting-started/installing/production.mdx b/website/content/docs/getting-started/installing/production.mdx index 4453725360..a663ae0159 100644 --- a/website/content/docs/getting-started/installing/production.mdx +++ b/website/content/docs/getting-started/installing/production.mdx @@ -217,7 +217,7 @@ sudo chown boundary:boundary /etc/${NAME}-${TYPE}.hcl sudo chown boundary:boundary /usr/local/bin/boundary # Make sure to initialize the DB before starting the service. This will result in -# a database already initizalized warning if another controller or worker has done this +# a database already initialized warning if another controller or worker has done this # already, making it a lazy, best effort initialization if [ "${TYPE}" = "controller" ]; then sudo /usr/local/bin/boundary database init -config /etc/${NAME}-${TYPE}.hcl || true diff --git a/website/content/docs/getting-started/run-and-login.mdx b/website/content/docs/getting-started/run-and-login.mdx index e46980168f..f3a517fbb0 100644 --- a/website/content/docs/getting-started/run-and-login.mdx +++ b/website/content/docs/getting-started/run-and-login.mdx @@ -34,7 +34,7 @@ an error indicating that the token could not be stored, as the freedesktop.org Secret Service implementation is not always available. On these systems, you can work around this by installing `dbus-x11` and `gnome-keyring` using your package manager, then creating and unlocking the default keyring with the following, -substituting in a password of your choice for "foorbar" (but ending with `\n`). +substituting in a password of your choice for "foobar" (but ending with `\n`). You can also avoid putting the password on the command line by running the `gnome-keyring-daemon` commands directly and entering in the password, followed by a newline (return) and an EOF (`Ctrl+D`). diff --git a/website/content/docs/installing/high-availability.mdx b/website/content/docs/installing/high-availability.mdx index 7a31ccfdd8..d686554917 100644 --- a/website/content/docs/installing/high-availability.mdx +++ b/website/content/docs/installing/high-availability.mdx @@ -30,7 +30,7 @@ needs: ![](/img/production.png) As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in -3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate [availability zones](), with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independant [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity. +3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate [availability zones](), with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independent [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity. The workers must be able to establish a connection to the hosts with which they interact. In the architecture above, we place them in the public subnet so our remote client can establish a session between them and the target VM. diff --git a/website/content/docs/installing/no-gen-resources.mdx b/website/content/docs/installing/no-gen-resources.mdx index 59dbef54ae..99f1d97971 100644 --- a/website/content/docs/installing/no-gen-resources.mdx +++ b/website/content/docs/installing/no-gen-resources.mdx @@ -11,7 +11,7 @@ What are generated resources? When you run `boundary dev` or `boundary database generates a number of resources to make getting started easier. Default scopes, auth methods, user, account, and targets are just some of the resources Boundary will generate unless you tell it not to. -In a production or long-running environment, these resoures are not neccessary, but without them, managing +In a production or long-running environment, these resources are not necessary, but without them, managing Boundary from scratch isn't straight forward. How do you create your first user and login to administer a Boundary deployment that has no authentication methods, users, accounts, etc? This section describes how to get your freshly deployed Boundary installation off the ground for non-dev environments. diff --git a/website/content/docs/installing/systemd.mdx b/website/content/docs/installing/systemd.mdx index 1d1d9668db..e7911510aa 100644 --- a/website/content/docs/installing/systemd.mdx +++ b/website/content/docs/installing/systemd.mdx @@ -79,7 +79,7 @@ sudo chown boundary:boundary /etc/${NAME}-${TYPE}.hcl sudo chown boundary:boundary /usr/local/bin/boundary # Make sure to initialize the DB before starting the service. This will result in -# a database already initizalized warning if another controller or worker has done this +# a database already initialized warning if another controller or worker has done this # already, making it a lazy, best effort initialization if [ "${TYPE}" = "controller" ]; then sudo /usr/local/bin/boundary database init -config /etc/${NAME}-${TYPE}.hcl || true