Wpb 26240 corrections

mkdocs.yml

@@ -48,7 +48,7 @@ nav:
           - Wire Server 5.28: how-to/upgrade/config-references/wire-server-5.28.0.md
           - Wire Server 5.29: how-to/upgrade/config-references/wire-server-5.29.0.md
           - Wire Server 5.30: how-to/upgrade/config-references/wire-server-5.30.0.md
-          - Wire Server 5.30: how-to/upgrade/config-references/wire-server-5.32.0.md
+          - Wire Server 5.32: how-to/upgrade/config-references/wire-server-5.32.0.md
   - Administration:
       - Overview: how-to/administrate/README.md
       - kubernetes: how-to/administrate/kubernetes/README.md

src/how-to/upgrade/05-config-reference.md

@@ -39,8 +39,8 @@ Apply each configuration change to your templates as applicable to your model.
 - [Wire Server 5.27.0](config-references/wire-server-5.27.0.md)
 - [Wire Server 5.28.0](config-references/wire-server-5.28.0.md)
 - [Wire Server 5.29.0](config-references/wire-server-5.29.0.md)
-- [Wire Server 5.29.0](config-references/wire-server-5.30.0.md)
-- [Wire Server 5.29.0](config-references/wire-server-5.32.0.md)
+- [Wire Server 5.30.0](config-references/wire-server-5.30.0.md)
+- [Wire Server 5.32.0](config-references/wire-server-5.32.0.md)
 
 ## Contributing
 

src/how-to/upgrade/config-references/wire-server-5.32.0.md

@@ -26,7 +26,7 @@ The duplicates to drop:
 
 ## For users of the full wire-server-deploy-static deployment package
 
-1NOTE: Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+NOTE: Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
 
 When that happens, SSH into the **assethost** (not the adminhost) and clear it:
 

src/understand/overview.md

@@ -175,7 +175,7 @@ Placing calling in your main kubernetes cluster is heavily discouraged by Wire.
 ### Calling in your DMZ:
 ![image](img/calling-DMZ.svg)
 
-In the above diagram, we have routed and labeled the calling traffic into a non-federated Wire calling cluster. A Wire Calling Cluster is typically placed in an DMZ, where the users can reach it, but the Mire Messaging Cluster cannot. Wire As you can see, placing calling in it's own kubernetes cluster is much safer, as the cluster does not have access to any of the Wire databases. For most configurations, the calling cluster and the Wire backend do not need to speak at all.
+In the above diagram, we have routed and labeled the calling traffic into a non-federated Wire calling cluster. A Wire Calling Cluster is typically placed in an DMZ, where the users can reach it, but the Wire Messaging Cluster cannot. Wire As you can see, placing calling in it's own kubernetes cluster is much safer, as the cluster does not have access to any of the Wire databases. For most configurations, the calling cluster and the Wire backend do not need to speak at all.
 
 ### Federated Calling
 ![image](img/federated_calling.svg)