Headscale is not capitalized

README.md

@@ -14,14 +14,14 @@ Everything in Tailscale is Open Source, except the GUI clients for proprietary O
 
 The control server works as an exchange point of Wireguard public keys for the nodes in the Tailscale network. It also assigns the IP addresses of the clients, creates the boundaries between each user, enables sharing machines between users, and exposes the advertised routes of your nodes.
 
-Headscale implements this coordination server.
+headscale implements this coordination server.
 
 ## Status
 
 - [x] Base functionality (nodes can communicate with each other)
 - [x] Node registration through the web flow
 - [x] Network changes are relayed to the nodes
-- [x] Multiple namespaces support (~tailnets in Tailscale.com naming)
+- [x] Namespaces support (~tailnets in Tailscale.com naming)
 - [x] Routing (advertise & accept, including exit nodes)
 - [x] Node registration via pre-auth keys (including reusable keys, and ephemeral node support)
 - [x] JSON-formatted output

docs/DNS.md

@@ -1,12 +1,12 @@
-# DNS in Headscale
+# DNS in headscale
 
-Headscale supports Tailscale's DNS configuration and MagicDNS. Please have a look to their KB to better understand what this means:
+headscale supports Tailscale's DNS configuration and MagicDNS. Please have a look to their KB to better understand what this means:
 
 - https://tailscale.com/kb/1054/dns/
 - https://tailscale.com/kb/1081/magicdns/
 - https://tailscale.com/blog/2021-09-private-dns-with-magicdns/
 
-Long story short, you can define the DNS servers you want to use in your tailnets, activate MagicDNS (so you don't have to remember the IP addresses of your nodes), define search domains, as well as predefined hosts. Headscale will inject that settings into your nodes.
+Long story short, you can define the DNS servers you want to use in your tailnets, activate MagicDNS (so you don't have to remember the IP addresses of your nodes), define search domains, as well as predefined hosts. headscale will inject that settings into your nodes.
 
 
 ## Configuration reference

docs/TLS.md

@@ -8,7 +8,7 @@ tls_letsencrypt_cache_dir: ".cache"
 tls_letsencrypt_challenge_type: HTTP-01
 ```
 
-To get a certificate automatically via [Let's Encrypt](https://letsencrypt.org/), set `tls_letsencrypt_hostname` to the desired certificate hostname. This name must resolve to the IP address(es) Headscale is reachable on (i.e., it must correspond to the `server_url` configuration parameter). The certificate and Let's Encrypt account credentials will be stored in the directory configured in `tls_letsencrypt_cache_dir`. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from. The certificate will automatically be renewed as needed.
+To get a certificate automatically via [Let's Encrypt](https://letsencrypt.org/), set `tls_letsencrypt_hostname` to the desired certificate hostname. This name must resolve to the IP address(es) headscale is reachable on (i.e., it must correspond to the `server_url` configuration parameter). The certificate and Let's Encrypt account credentials will be stored in the directory configured in `tls_letsencrypt_cache_dir`. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from. The certificate will automatically be renewed as needed.
 
 
 ```yaml
@@ -16,16 +16,16 @@ tls_cert_path: ''
 tls_key_path: ''
 ```
 
-Headscale can also be configured to expose its web service via TLS. To configure the certificate and key file manually, set the `tls_cert_path` and `tls_cert_path` configuration parameters. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from.
+headscale can also be configured to expose its web service via TLS. To configure the certificate and key file manually, set the `tls_cert_path` and `tls_cert_path` configuration parameters. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from.
 
 
 ## Challenge type HTTP-01
 
-The default challenge type `HTTP-01` requires that Headscale is reachable on port 80 for the Let's Encrypt automated validation, in addition to whatever port is configured in `listen_addr`. By default, Headscale listens on port 80 on all local IPs for Let's Encrypt automated validation.
+The default challenge type `HTTP-01` requires that headscale is reachable on port 80 for the Let's Encrypt automated validation, in addition to whatever port is configured in `listen_addr`. By default, headscale listens on port 80 on all local IPs for Let's Encrypt automated validation.
 
-If you need to change the ip and/or port used by Headscale for the Let's Encrypt validation process, set `tls_letsencrypt_listen` to the appropriate value. This can be handy if you are running Headscale as a non-root user (or can't run `setcap`). Keep in mind, however, that Let's Encrypt will _only_ connect to port 80 for the validation callback, so if you change `tls_letsencrypt_listen` you will also need to configure something else (e.g. a firewall rule) to forward the traffic from port 80 to the ip:port combination specified in `tls_letsencrypt_listen`.
+If you need to change the ip and/or port used by headscale for the Let's Encrypt validation process, set `tls_letsencrypt_listen` to the appropriate value. This can be handy if you are running headscale as a non-root user (or can't run `setcap`). Keep in mind, however, that Let's Encrypt will _only_ connect to port 80 for the validation callback, so if you change `tls_letsencrypt_listen` you will also need to configure something else (e.g. a firewall rule) to forward the traffic from port 80 to the ip:port combination specified in `tls_letsencrypt_listen`.
 
 ## Challenge type TLS-ALPN-01
 
-Alternatively, `tls_letsencrypt_challenge_type` can be set to `TLS-ALPN-01`. In this configuration, Headscale listens on the ip:port combination defined in `listen_addr`. Let's Encrypt will _only_ connect to port 443 for the validation callback, so if `listen_addr` is not set to port 443, something else (e.g. a firewall rule) will be required to forward the traffic from port 443 to the ip:port combination specified in `listen_addr`.
+Alternatively, `tls_letsencrypt_challenge_type` can be set to `TLS-ALPN-01`. In this configuration, headscale listens on the ip:port combination defined in `listen_addr`. Let's Encrypt will _only_ connect to port 443 for the validation callback, so if `listen_addr` is not set to port 443, something else (e.g. a firewall rule) will be required to forward the traffic from port 443 to the ip:port combination specified in `listen_addr`.
 

k8s/README.md

@@ -1,7 +1,7 @@
-# Deploying Headscale on Kubernetes
+# Deploying headscale on Kubernetes
 
 This directory contains [Kustomize](https://kustomize.io) templates that deploy
-Headscale in various configurations.
+headscale in various configurations.
 
 These templates currently support Rancher k3s. Other clusters may require
 adaptation, especially around volume claims and ingress.
@@ -72,10 +72,10 @@ Usage:
 
 Available Commands:
   help        Help about any command
-  namespace   Manage the namespaces of Headscale
+  namespace   Manage the namespaces of headscale
-  node        Manage the nodes of Headscale
+  node        Manage the nodes of headscale
-  preauthkey  Handle the preauthkeys in Headscale
+  preauthkey  Handle the preauthkeys in headscale
-  routes      Manage the routes of Headscale
+  routes      Manage the routes of headscale
   serve       Launches the headscale server
   version     Print the version.