diff --git a/manuscript/kubernetes/loadbalancer/metallb/pfsense.md b/manuscript/kubernetes/loadbalancer/metallb/pfsense.md
index eec4917..2e1b89f 100644
--- a/manuscript/kubernetes/loadbalancer/metallb/pfsense.md
+++ b/manuscript/kubernetes/loadbalancer/metallb/pfsense.md
@@ -22,23 +22,23 @@ Install the FRR package in pfsense, under **System -> Package Manager -> Availab
Under **Services -> FRR Global/Zebra**, enable FRR, set your router ID (*this will be your router's peer IP in MetalLB config*), and set a master password (*because apparently you have to, even though we don't use it*):
-
+
### Configure FRR BGP
Under **Services -> FRR BGP**, globally enable BGP, and set your local AS and router ID:
-
+
### Configure FRR BGP Advanced
Use the tabs at the top of the FRR configuration to navigate to "**Advanced**"...
-
+
... and scroll down to **eBGP**. Check the checkbox titled "**Disable eBGP Require Policy**:
-
+
!!! question "Isn't disabling a policy check a Bad Idea(tm)?"
If you're an ISP, sure. If you're only using eBGP to share routes between MetalLB and pfsense, then applying policy is an unnecessary complication.[^1]
@@ -58,13 +58,13 @@ It's useful to bundle our configurations within a "peer group" (*a collection of
Now add each node running MetalLB, as a BGP neighbor. Pick the peer-group you created above, and configure each neighbor's ASN:
-
+
## Serving
Once you've added your neighbors, you should be able to use the FRR tab navigation (*it's weird, I know!*) to get to Status / BGP, and identify your neighbors, and all the routes learned from them. In the screenshot below, you'll note that **most** routes are learned from all the neighbors - that'll be service backed by a daemonset, running on all nodes. The `192.168.32.3/32` route, however, is only received from `192.168.33.22`, meaning only one node is running the pods backing this service, so only those pods are advertising the route to pfSense:
-
+
### Troubleshooting
diff --git a/manuscript/kubernetes/sealed-secrets.md b/manuscript/kubernetes/sealed-secrets.md
index 84e2ac9..bbd8347 100644
--- a/manuscript/kubernetes/sealed-secrets.md
+++ b/manuscript/kubernetes/sealed-secrets.md
@@ -14,7 +14,7 @@ They're still not very secret though, and you certainly wouldn't want to be stor
An elegant solution to this problem is Bitnami Labs' Sealed Secrets.
-
+
A "[SealedSecret](https://github.com/bitnami-labs/sealed-secrets)" can only be decrypted (*and turned back into a regular Secret*) by the controller in the target cluster. (*or by a controller in another cluster which has been primed with your own private/public pair)* This means the SealedSecret is safe to store and expose anywhere.
diff --git a/manuscript/kubernetes/ssl-certificates/cert-manager.md b/manuscript/kubernetes/ssl-certificates/cert-manager.md
index 3823750..d9d4d5d 100644
--- a/manuscript/kubernetes/ssl-certificates/cert-manager.md
+++ b/manuscript/kubernetes/ssl-certificates/cert-manager.md
@@ -7,7 +7,7 @@ To interact with your cluster externally, you'll almost certainly be using a web
Cert Manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.
-
+
It can issue certificates from a variety of supported sources, including Let’s Encrypt, HashiCorp Vault, and Venafi as well as private PKI.
diff --git a/overrides/main.html b/overrides/main.html
index 3fabc07..6289d4f 100644
--- a/overrides/main.html
+++ b/overrides/main.html
@@ -25,3 +25,14 @@
{% endblock %}
+
+
+{% block htmltitle %}
+ {% if page.meta and page.meta.title %}
+ {{ page.meta.title }} |・∀・
+ {% elif page.title and not page.is_homepage %}
+ {{ page.title | striptags }} |・∀・
+ {% else %}
+ {{ config.site_name }}
+ {% endif %}
+{% endblock %}
\ No newline at end of file