normalized, and converted all images to webp

1 files changed, 37 insertions, 37 deletions

diff --git a/post/framework-server.typ b/post/framework-server.typ
index 4e9d5b6..a8d82a3 100644
--- a/post/framework-server.typ
+++ b/post/framework-server.typ
@@ -11,12 +11,12 @@ How I re-purposed my Framework as a standalone server for my home-lab.
 
 I \#feelsbad for abusing my lowly NAS -
 
-#img("framework-server/feelsbadman.png", alt: "feelsbadman", width: "150px")
+#img("framework-server/feelsbadman.webp", alt: "feelsbadman", width: "150px")
 
 Its not it's fault that its owner expected it to run Collabora Online while
 running all his other services without instantly crashing...
 
-#fig("framework-server/error.jpg", alt: "meme of error page")
+#fig("framework-server/error.webp", alt: "meme of error page")
 
 Did I learn anything? Basically a NAS should just do NAS things like worry
 about storage. Compute should be handled by something else.
@@ -52,14 +52,14 @@ over NFS from my NAS.
 
 I'll setup a dedicated "workstation" VM for those 1%-of-the-time tasks.
 
-#fig("framework-server/physical.png", alt: "physical architecture image")
+#fig("framework-server/physical.webp", alt: "physical architecture image")
 
 = Prior to starting!
 
 To avoid making the same mistakes I made, do the following *while the mainboard
 is still in the laptop chassis!*
 
-#fig("framework-server/mistakes.jpg", alt: "mistakes meme")
+#fig("framework-server/mistakes.webp", alt: "mistakes meme")
 
 + *Update your BIOS firmware to at least 3.17.* It is *impossible* to do so
   once the battery is un-plugged from the board on older firmwares. I learned
@@ -70,7 +70,7 @@ is still in the laptop chassis!*
 + In your BIOS settings, enable "Standalone operation".
 + In your BIOS settings, under "Boot" enable the option to power-on on
   power-attach.
-  #fig("framework-server/bios.jpg", alt: "bios image")
+  #fig("framework-server/bios.webp", alt: "bios image")
 + Install Proxmox VE. Since this will require a screen, and keyboard input, you
   might as well do it now. See the #link(<hypervisor>)[hypervisor] section
   below.
@@ -85,7 +85,7 @@ I'm using my original
 #extlink("https://frame.work/ca/en/products/mainboard-11th-gen-intel-core?v=FRANFG000B")[Framework
   13] laptop.
 
-#fig("framework-server/case.jpg", alt: "case image")
+#fig("framework-server/case.webp", alt: "case image")
 
 Its an i7-1165G7 - yes a "mobile" CPU. Am I asking for trouble? We'll see. Its
 more than powerful enough for me (for now).
@@ -112,7 +112,7 @@ I opted for the 2.5G
 #extlink("https://frame.work/ca/en/products/ethernet-expansion-card")[ethernet
   expansion card] from Framework.
 
-#fig("framework-server/eth.jpg", alt: "framework eth adapter image")
+#fig("framework-server/eth.webp", alt: "framework eth adapter image")
 
 I suppose one could also use a WiFi card, but it makes more sense to go wired
 in a 24/7 "on" configuration.
@@ -127,7 +127,7 @@ So I opt for a cheap VPS from
 #extlink("https://www.racknerd.com/kvm-vps")[Racknerd]. These are about a \$1/mo
 for a public IPv4 IP, and a decent amount of network bandwidth.
 
-#fig("framework-server/vps.png", alt: "racknerd vps pricing image")
+#fig("framework-server/vps.webp", alt: "racknerd vps pricing image")
 
 == Storage
 
@@ -139,7 +139,7 @@ I used the 1TB NVME drive I had on my Framework.
 
 _You should have a storage solution (NAS) in place already!_
 
-#fig("framework-server/nas.jpg", alt: "nas image")
+#fig("framework-server/nas.webp", alt: "nas image")
 
 Setting this up is beyond the scope of this post. You can check out my DIY ZFS
 backed NAS setup
@@ -168,7 +168,7 @@ There are also many options for pre-made NAS appliances such as Synology.
 Highly recommend a UPS such as
 #extlink("https://www.amazon.ca/APC-BE600M1-Back-Uninterrupted-Electronics-Computers/dp/B01FWAZEIU/ref=sr_1_6?crid=28ZH7JP9IYXPU&keywords=ups&qid=1690928556&sprefix=ups%2Caps%2C172&sr=8-6")[this].
 
-#fig("framework-server/ups.jpg", alt: "ups image")
+#fig("framework-server/ups.webp", alt: "ups image")
 
 Even if you don't care about uptime, *you should care about data integrity*
 issues resulting from abrupt power-loss.
@@ -199,7 +199,7 @@ allowing provisioning of VMs, and LXC Containers through code. Neat!
 - Under your host (mine's `pve`), under System, Network, create a bridge
   `vmbr0` with:
 
-#fig("framework-server/net1.png", alt: "proxmox net image")
+#fig("framework-server/net1.webp", alt: "proxmox net image")
 
 This will make your Proxmox host available in your home network. *Set this to
 something else if you like.*
@@ -211,7 +211,7 @@ something else if you like.*
 
 While you're here, create another bridge `vmbr1` with `VLAN Aware` checked:
 
-#fig("framework-server/net2.png", alt: "proxmox net image")
+#fig("framework-server/net2.webp", alt: "proxmox net image")
 
 #quote(block: true)[
     We are going to create our home-lab network primarily on `vmbr1`. Think of
@@ -238,7 +238,7 @@ _selectively_ routing a segment of my network over a VPN.
 
 Here is what I would like:
 
-#fig("framework-server/network.png", alt: "network architecture")
+#fig("framework-server/network.webp", alt: "network architecture")
 
 == Goals: 1,2
 
@@ -253,7 +253,7 @@ Then I decided to try out OpenWRT, and boy am I glad I did.
 
 I gave it two networking interfaces, each `vbmrX` we created earlier:
 
-#fig("framework-server/pfnet.png", alt: "openwrt bridge image")
+#fig("framework-server/pfnet.webp", alt: "openwrt bridge image")
 
 - `vmbr0` will be used to access our router from the home-network. It will also
   be how our router gets access to the internet. Aka. *WAN*.
@@ -267,7 +267,7 @@ I gave it two networking interfaces, each `vbmrX` we created earlier:
 
 I was able to setup a network with a few VLANs:
 
-#fig("framework-server/wrtnet.png", alt: "openwrt network image")
+#fig("framework-server/wrtnet.webp", alt: "openwrt network image")
 
 #quote(block: true)[
     This means that the next time we create a new VM or LXC container, we can
@@ -280,7 +280,7 @@ Few observations:
 - The Luci web UI is much more minimal and to the point. The terminology used
   for things are more in-line with what I'm familiar with.
 - Soon I had the segregation I was looking for thanks to Firewall settings:
-  #fig("framework-server/fw1.png", alt: "firewall settings image")
+  #fig("framework-server/fw1.webp", alt: "firewall settings image")
 - DHCP, *and* DNS working as expected.
 
 == Goals: 3
@@ -295,24 +295,24 @@ Then I started working on setting up my VPN (Wireguard) remote on my VPS.
 - Then I enabled the "DMZ" setting (but *not* "Advanced DMZ" - which is
   probably the _real_ DMZ) on my home ISP router settings, and added my OpenWRT
   VM to it.
-  #fig("framework-server/dmz.png", alt: "dmz image")
+  #fig("framework-server/dmz.webp", alt: "dmz image")
 - I also setup a port-forward for the Wireguard port 51820 from my ISP router
   settings, to point to my OpenWRT VM's internal port 51820.
-  #fig("framework-server/port1.png", alt: "port forward image")
+  #fig("framework-server/port1.webp", alt: "port forward image")
 
 After all that, I started setting up Wireguard on OpenWRT.
 
 - The corresponding OpenWRT package is called `luci-app-wireguard`.
 - This will give you the ability to create a Wireguard interface on OpenWRT.
-  #fig("framework-server/wg.png", alt: "wg menu image")
+  #fig("framework-server/wg.webp", alt: "wg menu image")
 
 - I followed the following excellent tutorial for setting up the Wireguard
   interface, configured to use my VPS as its peer:
   #extlink("https://www.youtube.com/watch?v=04q41GEPvKA")[Setting up Wireguard
     on OpenWRT]
 - Created the new interface and added the firewall settings:
-  #fig("framework-server/wrtnet2.png", alt: "openwrt wg ifrace")
-  #fig("framework-server/fw2.png", alt: "firewall wg settings image")
+  #fig("framework-server/wrtnet2.webp", alt: "openwrt wg ifrace")
+  #fig("framework-server/fw2.webp", alt: "firewall wg settings image")
 
 - As is, this will mean that *only* LAB will have internet access (using the
   Wireguard interface) - which is not what I want. I still want other subnets
@@ -327,18 +327,18 @@ After all that, I started setting up Wireguard on OpenWRT.
 Luckily OpenWRT has a way to accomplish exactly this with a package called
 `luci-app-pbr`. This will add the PBR setting to your menu:
 
-#fig("framework-server/pbr.png", alt: "pbr setting image")
+#fig("framework-server/pbr.webp", alt: "pbr setting image")
 
 - I followed the following tutorial:
   #extlink("https://www.youtube.com/watch?v=FN2qfxNIs2g")[Setting up PBR on
     OpenWRT]
 
 - Set up the rule for my PBR:
-  #fig("framework-server/pbr2.png", alt: "pbr rule image")
+  #fig("framework-server/pbr2.webp", alt: "pbr rule image")
 
 - The default interface is set to `wan`, so everything else should behave as
   normal:
-  #fig("framework-server/pbr1.png", alt: "pbr global gateways image")
+  #fig("framework-server/pbr1.webp", alt: "pbr global gateways image")
 
 However, it did take many trail & error sessions (see the
 #link(<pbr-dns-leakage>)[dns leakage issues] section below) to get this working
@@ -351,14 +351,14 @@ When I create a VM/container in my _Lab_ subnet,
 - its external IP is that of my VPS
 - when it reaches out to the internet, it goes through the Wireguard tunnel
   encrypted, to the VPS, and out the VPS's ISP.
-  #fig("framework-server/lab.png", alt: "lab flow image")
+  #fig("framework-server/lab.webp", alt: "lab flow image")
 
 When I create a VM/container *not* in my Lab subnet,
 
 - its external IP is the same as my home-network's public IP
 - when it reaches out to the internet, it goes through my home ISP (NAT), just
   like all other devices on my home-network.
-  #fig("framework-server/lan.png", alt: "lan flow image")
+  #fig("framework-server/lan.webp", alt: "lan flow image")
 
 PBR provides quite granular control over this, for example, if you run a Plex
 server, it frequently needs to access the `plex.tv` domain. You can choose to
@@ -385,12 +385,12 @@ PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to
 Then we also need to setup port-forwards for 80,443 on OpenWRT going to our
 Reverse Proxy VM/Container.
 
-#fig("framework-server/port2.png", alt: "port forwards image")
+#fig("framework-server/port2.webp", alt: "port forwards image")
 
 I just setup a temporary Caddy container in reverse-proxy mode to test this
 out.
 
-#fig("framework-server/rproxy.png", alt: "reverse-proxy setup image")
+#fig("framework-server/rproxy.webp", alt: "reverse-proxy setup image")
 
 Once this works, we can move on to building out our services :)
 
@@ -435,7 +435,7 @@ lxc.mount.entry: /dev/dri/renderD128 dev/renderD128 none bind,optional,create=fi
 Then inside your LXC container do `ls -al /dev/dri/` and you should see some
 devices.
 
-#fig("framework-server/dri.png", alt: "gpu devices image")
+#fig("framework-server/dri.webp", alt: "gpu devices image")
 
 = Issues <issues>
 
@@ -456,7 +456,7 @@ BIOS update.
 
 So I proceeded to give that a shot from within Proxmox using `fwupmgr`:
 
-#fig("framework-server/fail.png", alt: "bios up fail image")
+#fig("framework-server/fail.webp", alt: "bios up fail image")
 
 And to my surprise it was complaining about _battery level_? Its not even
 connected to the battery...
@@ -471,7 +471,7 @@ being connected.
 - So I went ahead and pretty much attached the whole thing back into the laptop
   chassis
 - Updated to 3.17, and applied "Standalone operation"
-  #fig("framework-server/bios2.png", alt: "bios update image")
+  #fig("framework-server/bios2.webp", alt: "bios update image")
 
 - Thankfully, all my connectivity issues have gone away now.
 - Framework support service is excellent!
@@ -483,7 +483,7 @@ This one kept me up for many nights. To summarize:
 - in a host in the Lab network, doing an `apt update` the first time would
   hang, mid-way through
 - running it a few times again, would eventually succeed the operation
-  #fig("framework-server/wtf.jpg", alt: "wtf meme")
+  #fig("framework-server/wtf.webp", alt: "wtf meme")
 
 Could it be DNS? Could it be PBR? Could it be Wireguard?
 
@@ -509,20 +509,20 @@ Although my external IP would correctly report to being my VPS one, tests like
 #extlink("https://github.com/macvk/dnsleaktest")[this] would show that DNS was
 still being sent to my home ISP.
 
-#fig("framework-server/dns.jpg", alt: "dns meme image")
+#fig("framework-server/dns.webp", alt: "dns meme image")
 
 To fix this, I had to:
 
 - *Un-check* setting default route on the Lab interface.
-  #fig("framework-server/fix1.png", alt: "dns fix 1 image")
+  #fig("framework-server/fix1.webp", alt: "dns fix 1 image")
 
 - Explicitly set DHCP DNS settings for my Lab gateway interface to use my VPS's
   `wg0` interface IP.
-  #fig("framework-server/fix2.png", alt: "dns fix 2 image")
+  #fig("framework-server/fix2.webp", alt: "dns fix 2 image")
 
 - Needed a static route defied for the `wg0` interface targeting the VPN
   network via the OpenWRT local IP for `wg0` as a gateway.
-  #fig("framework-server/fix3.png", alt: "dns fix 3 image")
+  #fig("framework-server/fix3.webp", alt: "dns fix 3 image")
 
 == pfSense <pfsense>
 
@@ -551,7 +551,7 @@ so is my NAS as a storage server.
 Since switching to this setup, I've observed a dramatic improvement in
 responsiveness for all of my services.
 
-#fig("framework-server/imp.png", alt: "improvement meme image")
+#fig("framework-server/imp.webp", alt: "improvement meme image")
 
 Overall I'm quite pleased with how everything turned out once the appropriate
 BIOS was running on the Framework.