fix: typos

docs/maintainers/handbook.md

@@ -17,7 +17,7 @@ You can run `abra recipe new <recipe>` to generate a new `~/.abra/recipes/<recip
     "unconfigured" healthcheck behaviour is much less strict and it's faster to
     get something up and running.
 
-If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means ou can simple hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream.
+If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means you can simply hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream.
 
 ## How is a recipe structured?
 

docs/maintainers/tutorial.md

@@ -14,7 +14,7 @@ Depending on your familiarity with recipes, it might be worth reading [how a rec
 
 ### Making a plan
 
-The idea scenario is when the upstream project provides both the packaged image and a compose configuration which we can build from. If you're in luck, you'll typically find a `Dockerfile` and a `docker-compose.yml` file in the root of the upstream Git repository for the app.
+The ideal scenario is when the upstream project provides both the packaged image and a compose configuration which we can build from. If you're in luck, you'll typically find a `Dockerfile` and a `docker-compose.yml` file in the root of the upstream Git repository for the app.
 
 - **Tired**: Write your own image and compose file from scratch
 - **Wired**: Use someone else's image (& maybe compose file)
@@ -43,9 +43,9 @@ wget https://raw.githubusercontent.com/matomo-org/docker/master/.examples/apache
 
 Open the `compose.yml` in your favourite editor and have a gander 🦢. There are a few things we're looking for, but some immediate changes could be:
 
-1. Let's bump the version to `3.8`, to make sure we can use all the latest swarm coolness
-2. We load environment variables separately via [`abra`](/abra/), so we'll strip out `env_file`
-3. The `/var/www/html` volume definition on L21 is a bit overzealous; it means a copy of Matomo will be stored separately per app instance, which is a waste of space in most cases. We'll narrow it down according to the documentation. The developers have been nice enough to suggest `logs` and `config` volumes instead, which is a decent start
+1. Let's bump the version to `3.8`, to make sure we can use all the latest swarm coolness.
+2. We load environment variables separately via [`abra`](/abra/), so we'll strip out `env_file`.
+3. The `/var/www/html` volume definition on L21 is a bit overzealous; it means a copy of Matomo will be stored separately per app instance, which is a waste of space in most cases. We'll narrow it down according to the documentation. The developers have been nice enough to suggest `logs` and `config` volumes instead, which is a decent start.
 4. The MySQL passwords are sent as variables which is fine for basic use, but if we replace them with Docker secrets we can keep them out of our env files if we want to publish those more widely.
 5. The MariaDB service doesn't need to be exposed to the internet, so we can define an `internal` network for it to communicate with Matomo.
 6. Lastly, we want to use `deploy.labels` and remove the `ports:` definition, to tell Traefik to forward requests to Matomo based on hostname and generate an SSL certificate.

docs/operators/handbook.md

@@ -163,11 +163,11 @@ So, given how [secret versions](/operators/handbook/#secret-versions) work, here
 1. Find out the current version number of the secret, e.g. by running `abra app config <domain>`, and choose a new one. Let's assume it's currently `v1`, so by convention the new secret will be `v2`
 2. Generate or insert the new secret: `abra app secret generate <domain> db_password v2` or `abra app secret insert <domain> db_password v2 "foobar"`
 3. Edit the app configuration to change which secret version the app will use: `abra app config <domain>`
-4. Re-reploy the app with the new secret version: `abra app deploy <domain>`
+4. Re-deploy the app with the new secret version: `abra app deploy <domain>`
 
 ### Storing secrets in `pass`
 
-The Co-op Cloud authors use the [UNIX `pass` tool][pass] to share sensitive data, including Co-op Cloud secrets, and `abra app secret ...` commands include a `--pass` option to automatically manage generated / inserted secrets:
+The Co-op Cloud authors use the [UNIX `pass` tool](https://www.passwordstore.org) to share sensitive data, including Co-op Cloud secrets, and `abra app secret ...` commands include a `--pass` option to automatically manage generated / inserted secrets:
 
 ```
 # Store generated secrets in `pass`:
@@ -191,19 +191,19 @@ This functionality currently relies on our specific `pass` storage conventions;
 
 ### Traefik networking
 
-[Traefik](https://doc.traefik.io/traefik/) is our core web proxy, all traffic on a Co-op Cloud deployment goes through a running Traefik container. When setting up a new Co-op Cloud delpyment, `abra` creates a "global" [overlay network](https://docs.docker.com/network/overlay/) which traefik is hooked up to. This is the network that other apps use to speak to traefik and get traffic routed to them. Not every service in every app is also included in this network and hence not internet-facing (by convention, we name this network `internal`, see more below).
+[Traefik](https://doc.traefik.io/traefik/) is our core web proxy, all traffic on a Co-op Cloud deployment goes through a running Traefik container. When setting up a new Co-op Cloud deployment, `abra` creates a "global" [overlay network](https://docs.docker.com/network/overlay/) which traefik is hooked up to. This is the network that other apps use to speak to traefik and get traffic routed to them. Not every service in every app is also included in this network and hence not internet-facing (by convention, we name this network `internal`, see more below).
 
 ### App networking
 
-By convention, the main `app` service is wired up to the "global" traefik overlay network. This container is the one that should be publicy reachable on the internet. The other services in the app such as the database and caches should be not be publicly reachable or visible to other apps on the same instance.
+By convention, the main `app` service is wired up to the "global" traefik overlay network. This container is the one that should be publicy reachable on the internet. The other services in the app such as the database and caches should not be publicly reachable or visible to other apps on the same instance.
 
 To deal with this, we make an additional "internal" network for each app which is namespaced to that app. So, if you deploy a Wordpress instance called `my_wordpress_blog` then there will be a network called `my_wordpress_blog_internal` created. This allows all the services in an app to speak to each other but not be reachable on the public internet.
 
 ## Multiple apps on the same domain?
 
-At time of writing (Jan 2022), we think there is a limitation in our design which doesn't support multiple apps sharing the same domain (e.g. `example.com/app1/` & `example.com/app2/`). `abra` treats each domain as unique and as the singler reference for a single app.
+At time of writing (Jan 2022), we think there is a limitation in our design which doesn't support multiple apps sharing the same domain (e.g. `example.com/app1/` & `example.com/app2/`). `abra` treats each domain as unique and as the single reference for a single app.
 
-This may be possible to overcome if someone really needs it, we encourage people to investigate. We've found that often, there are limitations in the actual software which don't support this anyway and several of the current operators simply use a new domain per app.
+This may be possible to overcome if someone really needs it, we encourage people to investigate. We've found that often there are limitations in the actual software which don't support this anyway and several of the current operators simply use a new domain per app.
 
 ## Validating `abra` binary checksums
 
@@ -264,7 +264,7 @@ systemctl restart docker containerd
 
 `abra` supports creating, listing and removing DNS entries if the 3rd party integration supports it.
 
-If you want to teach `abra` how to support your favourite server hosting provider, we'd glady accept patches.
+If you want to teach `abra` how to support your favourite DNS service provider, we'd glady accept patches.
 
 ## How do I persist container logs after they go away?
 
@@ -314,7 +314,7 @@ Also, for more system wide analysis stuff:
 
 `abra` uses plain 'ol SSH under the hood and aims to make use of your existing SSH configurations in `~/.ssh/config` and interfaces with your running `ssh-agent` for password protected secret key files.
 
-The `server add` command listed above assumes that that you make SSH connections on port 22 using your current username. If that is not he case, pass the new values as positional arguments. See `abra server add -h` for more on this.
+The `server add` command listed above assumes that that you make SSH connections on port 22 using your current username. If that is not the case, pass the new values as positional arguments. See `abra server add -h` for more on this.
 
 ```bash
 abra server add <domain> <user> <port> -p

docs/organisers/handbook.md

@@ -12,7 +12,7 @@ We still haven't worked this out. We're working on it.
 
 ## Gathering new case studies
 
-We try to gather as many "case studies" as possible, stories & concrete examples of Co-op Cloud being used For Good :tm: See [coopcloud.tech](https://coopcloud.tech) for our existing examples. These studies help people identify what the purpose of the project is for.
+We try to gather as many "case studies" as possible, stories & concrete examples of Co-op Cloud being used For Good :tm: See [coopcloud.tech](https://coopcloud.tech) for our existing examples. These studies help people identify what the purpose of the project is.
 
 ## Monthly updates
 

docs/organisers/index.md

@@ -2,7 +2,7 @@
 title: Organisers Guide
 ---
 
-Welcome to the organisers guide! Organisers are folks who focus on the social work in the project. Speaking for the project at talks, helping new tech co-ops & collectives join, keeping an eye out for funding opportunities, seeing what things up come up in the community chats, etc. It's important work.
+Welcome to the organisers guide! Organisers are folks who focus on the social work in the project. Speaking for the project at talks, helping new tech co-ops & collectives join, keeping an eye out for funding opportunities, seeing what things come up in the community chats, etc. It's important work.
 
 We're still working out what it looks like to do this kind of work in the project. If you like the idea of this kinda of work and/or are already doing it, please send patches to improve this documentation :rocket: