Update umami dns

.gitignore

@@ -119,3 +119,5 @@ dist
 # End of https://www.toptal.com/developers/gitignore/api/hugo,node
 
 public/
+
+.obsidian/

content/_index.md

@@ -18,7 +18,6 @@ If you would like to connect with me:
 - [Mastodon](https://mastodon.social/@davegallant)
 - [GitHub](https://github.com/davegallant)
 - [RSS Feed](https://davegallant.ca/index.xml)
-- [gitea.snake-cloud.ts.net](https://gitea.snake-cloud.ts.net/explore/repos)
 
 ## Credits
 

content/blog/replicating-truenas-datasets-to-sftpgo-over-tailscale/index.md

@@ -21,8 +21,10 @@ The only app I've needed to install has been Tailscale which has enabled me to a
 
 More recently, to reduce cloud costs, I've setup some a small node at another physical location and installed both Tailscale and [sftpgo](https://github.com/drakkan/sftpgo) on it to facilitate offsite backups. After setting up the infrastructure and adding a Cloud Sync Task in TrueNAS SCALE to replicate these backups offsite to sftpgo, I noticed that Tailscale's Magic DNS was not working, nor was the Tailscale IPv4 address.
 
-After reading the [Tailscale docs](https://tailscale.com/kb/1483/truenas#route-non-tailnet-traffic-through-truenas) , it became clear that the **Userspace** box had to be unchecked in the Tailscale app settings. This is because the Tailscale app is running within a docker container on the TrueNAS SCALE VM. After unchecking the **Userspace** box, I was able to verify that the Backup Credentials created for sftpgo worked when specifying the host as a Tailscale IPv4 address. This was probably good enough since the IP won't change unless the node is re-registered, but I figured setting up MagicDNS would make the setup more portable.
+After reading the [Tailscale docs](https://tailscale.com/kb/1483/truenas#route-non-tailnet-traffic-through-truenas) , it became clear that the **Userspace** box had to be unchecked in the Tailscale app settings. This is because the Tailscale app is running within a docker container on the TrueNAS SCALE VM. After unchecking the **Userspace** box, I was able to verify that the Backup Credentials created for sftpgo worked when specifying the host as a Tailscale IPv4 address. This was probably good enough since the IP won't change unless the node is re-registered.
 
-To get MagicDNS working, I went to Network > Global Configuration and set "Nameserver 1" to **100.100.100.100**. After this, I was able to specify the FQDN in the Backup Credentials and the Cloud Sync Tasks started.
+~~To get MagicDNS working, I went to Network > Global Configuration and set "Nameserver 1" to **100.100.100.100**. After this, I was able to specify the FQDN in the Backup Credentials and the Cloud Sync Tasks started.~~ 
+
+This method of adding MagicDNS can lead to issues with DNS when updating the tailscale application in TrueNAS, so I ended using the Tailscale IP directly.
 
 

content/blog/setting-up-gitea-actions-with-tailscale/index.md

@@ -50,11 +50,9 @@ services:
   gitea:
     image: gitea/gitea:1.21.1
     container_name: gitea
-    network_mode: service:ts-gitea
     environment:
       - USER_UID=1000
       - USER_GID=1000
-
       - GITEA__server__DOMAIN=gitea.my-tailnet-name.ts.net
       - GITEA__server__ROOT_URL=https://gitea.my-tailnet-name.ts.net
       - GITEA__server__HTTP_ADDR=0.0.0.0
@@ -64,57 +62,18 @@ services:
       - ./data:/data
       - /etc/timezone:/etc/timezone:ro
       - /etc/localtime:/etc/localtime:ro
-  ts-gitea:
-    image: tailscale/tailscale:v1.58
-    container_name: ts-gitea
-    hostname: gitea
-    environment:
-      - TS_AUTHKEY=<FILL THIS IN>
-      - TS_SERVE_CONFIG=/config/gitea.json
-      - TS_STATE_DIR=/var/lib/tailscale
-    volumes:
-      - ${PWD}/state:/var/lib/tailscale
-      - ${PWD}/config:/config
-      - /dev/net/tun:/dev/net/tun
-    cap_add:
-      - net_admin
-      - sys_module
-    restart: unless-stopped
 ```
 
-Note that you must specify a `TS_AUTHKEY` in the `ts-gitea` service. You can generate an auth key [here](https://login.tailscale.com/admin/settings/keys).
+After adding the above configuration, running `docker compose up -d` should be enough to get an instance up and running.
 
-`config/gitea.json`:
+To make it accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within the tailnet, install tailscale cli and run:
 
-```yaml
-{
-  "TCP": { "443": { "HTTPS": true } },
-  "Web":
-    {
-      "${TS_CERT_DOMAIN}:443":
-        { "Handlers": { "/": { "Proxy": "http://127.0.0.1:3000" } } },
-    },
-  "AllowFunnel": { "${TS_CERT_DOMAIN}:443": false }
-}
+```sh
+tailscale serve -bg 3000
 ```
 
-After adding the above configuration, running `docker compose up -d` should be enough to get an instance up and running. It will be accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within the tailnet.
-
 Something to consider is whether or not you want to use ssh with git. One method to get this to work with containers is to use [ssh container passthrough](https://docs.gitea.com/installation/install-with-docker#ssh-container-passthrough). I decided to keep it simple and not use ssh, since communicating over https is perfectly fine for my use case.
 
-## Theming
-
-I discovered some themes for gitea [here](https://git.sainnhe.dev/sainnhe/gitea-themes).
-
-I added the theme by copying [theme-palenight.css](https://git.sainnhe.dev/sainnhe/gitea-themes/raw/branch/master/dist/theme-palenight.css) into `./data/gitea/public/assets/css`. I then added the following to `environment` in `docker-compose.yml`:
-
-```yaml
-- GITEA__ui__DEFAULT_THEME=palenight
-- GITEA__ui__THEMES=palenight
-```
-
-After restarting the gitea instance, the default theme was applied.
-
 ## Connecting runners
 
 I installed the runner by [following the docs](https://docs.gitea.com/usage/actions/quickstart#set-up-runner). I opted for installing it on a separate host as recommended in the docs. I used the systemd unit file to ensure that the runner comes back online after system reboots. I installed tailscale on the gitea runner as well, so that it can be part of the same tailnet as the main instance.
@@ -168,7 +127,7 @@ jobs:
             ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_number }}
 ```
 
-And voilà:
+And the end result:
 
 ![image](gitea-workflow.png)
 
@@ -182,6 +141,4 @@ One enhancement that I would like to see is the ability to send notifications on
 
 Gitea Actions are fast and the resource footprint is minimal. My gitea instance is currently using around 250mb of memory and a small fraction of a single cpu core (and the runner is using a similar amount of resources). This is impressive since many alternatives tend to require substantially more resources. It likely helps that the codebase is largely written in go.
 
-By combining gitea with the networking marvel that is tailscale, running workflows becomes simple and fun. Whether you are working on a team or working alone, this setup ensures that your workflows are securely accessible from anywhere with an internet connection.
-
-Check out my gitea instance exposed via Funnel [here](https://gitea.snake-cloud.ts.net).
+By combining gitea with tailscale, running workflows becomes simple and fun. Whether you are working on a team or working alone, this setup ensures that your workflows are securely accessible from anywhere with an internet connection.

content/blog/using-a-realtek-nic-with-opnsense/index.md

@@ -19,7 +19,7 @@ tags:
 
 For the past few years, I've been running pfSense (and more recently OPNsense) in a virtual machine within Proxmox. This has been running fine with a single onboard Intel NIC. A few months ago, I upgraded to a machine that has a CPU that supports hardware-accelerated transcoding, has more SATA ports, and has more PCI slots for future expansion. With the goal of having a dedicated NIC for WAN, I bought an inexpensive 1Gbps PCIe NIC (TG-3468) despite reading about some of the concerns around Realtek NICs (sluggish performance, driver instability, and in some cases system crashes).
 
-I've been running a Realtek NICs reliably on Linux and Windows desktops, so I figured I could make it work without too much effort, but it turns out Realtek NICs really can be problematic when it comes to FreeBSD-based routers, and some commonly documented workarounds did not solve my problems.
+I've been running a Realtek NICs reliably on Linux and Windows desktops, so I figured I could make it work without too much effort, but it turns out Realtek NICs really can be problematic when it comes to FreeBSD-based routers, and commonly documented workarounds did not solve my problems.
 
 <!--more-->
 
@@ -28,7 +28,7 @@ I've been running a Realtek NICs reliably on Linux and Windows desktops, so I fi
 My environment consists of:
 
 - Proxmox 8.4
-- OPNsense 25.1 (Virtual Machine)
+- OPNsense 25.1 (QEMU VM)
 - Ethernet controller: Intel Corporation Ethernet Connection (5) I219-LM
 - Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
 
@@ -51,7 +51,7 @@ For maximum performance and reduced hypervisor overhead, passing through a physi
 
 I added the PCI device and restarted the OPNsense VM and re-configured the WAN in OPNsense to use this device.
 
-I received the WAN IP and everything appeared to be working. I ran a few speed tests and noticed that the download speeds were a lot lower than normal on multiple devices. I checked my instance of [speedtest-tracker](https://docs.speedtest-tracker.dev) noticed that the download speeds were significantly slower than historical records:
+I received the WAN IP and everything appeared to be working. I ran a few speed tests and noticed that the download speeds were much lower than normal from all of my devices. I checked my instance of [speedtest-tracker](https://docs.speedtest-tracker.dev) noticed that the download speeds were significantly slower than historical records:
 
 ![speedtest-tracker](./speedtest-tracker.png)
 

layouts/partials/head/head_end.html

@@ -1,2 +1,2 @@
 <!-- Umami Analytics -->
-<script defer src="https://umami.snake-cloud.ts.net/script.js" data-website-id="e8adafba-b892-4dad-a139-2bd61fe5fab9"></script>
+<script defer src="https://umami.davegallant.ca/script.js" data-website-id="e8adafba-b892-4dad-a139-2bd61fe5fab9"></script>

shell.nix

@@ -1,5 +1,5 @@
 let
-  nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixos-24.11";
+  nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixos-25.11";
   pkgs = import nixpkgs { config = { }; overlays = [ ]; };
 in
 

themes/custom-theme/layouts/robots.txt

@@ -1,53 +0,0 @@
-# Dark Visitors robots.txt
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/anthropic-ai
-
-User-agent: anthropic-ai
-Disallow: /
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/ccbot
-
-User-agent: CCBot
-Disallow: /
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/facebookbot
-
-User-agent: FacebookBot
-Disallow: /
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/google-extended
-
-User-agent: Google-Extended
-Disallow: /
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/gptbot
-
-User-agent: GPTBot
-Disallow: /
-
-# AI Data Scraper
-# https://darkvisitors.com/agents/omgilibot
-
-User-agent: omgilibot
-Disallow: /
-
-User-agent: omgili
-Disallow: /
-
-# This blocks Bytespider
-https://darkvisitors.com/agents/bytespider
-User-agent: Bytespider
-Disallow: /
-
-User-agent: *
-{{ if eq (hugo.Environment) "production" -}}
-Allow: /
-{{ else -}}
-Disallow: /
-{{ end -}}
-Sitemap: {{ "sitemap.xml" | absURL -}}