Fix spelling errors found in the documentation (#1073)
This commit is contained in:
1 parent
d3146992f1
commit
c096157cf9
10 files changed
+11
-11
No files matched your search
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
@@ -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
|
||||
|
||||
@@ -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`).
|
||||
|
||||
@@ -30,7 +30,7 @@ needs:
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in new issue
Block a user