From 0b9acc87801f5b9937c235b0475d5abbbdf6d2b5 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 30 Mar 2024 22:48:15 +0200 Subject: Update content for gemtext --- gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi | 6 +++--- gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl | 6 +++--- gemfeed/atom.xml | 8 ++++---- index.gmi | 2 +- uptime-stats.gmi | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi index 58fdfbf7..0f15de27 100644 --- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi +++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi @@ -38,14 +38,14 @@ It would be fine if my personal website wasn't highly available, but the geek in ## My auto-failover requirements * Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. -* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already). +* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already!). * It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers. * It should be geo-redundant. * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server. * Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available. * Let's Encrypt TLS certificates should always work (before and after a failover). -* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. -* Don't configure everything manually. The configuration should be automated and reproducible. +* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go) +* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base syste, but I didn't need to install any external package on OpenBSD either) ## My HA solution diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl index 0f882866..40a41e7b 100644 --- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl +++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl @@ -38,14 +38,14 @@ It would be fine if my personal website wasn't highly available, but the geek in ## My auto-failover requirements * Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. -* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already). +* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already!). * It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers. * It should be geo-redundant. * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server. * Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available. * Let's Encrypt TLS certificates should always work (before and after a failover). -* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. -* Don't configure everything manually. The configuration should be automated and reproducible. +* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go) +* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base syste, but I didn't need to install any external package on OpenBSD either) ## My HA solution diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 23527403..fe2206f8 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2024-03-30T22:42:12+02:00 + 2024-03-30T22:47:35+02:00 foo.zone feed To be in the .zone! @@ -59,14 +59,14 @@ _____|_:_:_| (o)-(o) |_:_:_|--'`-. ,--. ksh under-water (((\'/

My HA solution



diff --git a/index.gmi b/index.gmi index 489f8519..43bf810a 100644 --- a/index.gmi +++ b/index.gmi @@ -1,6 +1,6 @@ # foo.zone -> This site was generated at 2024-03-30T22:42:12+02:00 by `Gemtexter` +> This site was generated at 2024-03-30T22:48:01+02:00 by `Gemtexter` ``` |\---/| diff --git a/uptime-stats.gmi b/uptime-stats.gmi index e7e1d3f4..e0b4467d 100644 --- a/uptime-stats.gmi +++ b/uptime-stats.gmi @@ -1,6 +1,6 @@ # My machine uptime stats -> This site was last updated at 2024-03-30T22:42:12+02:00 +> This site was last updated at 2024-03-30T22:48:01+02:00 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine. -- cgit v1.2.3