From f7b583fc6125c84f8889c1cccfe22bac474fb8f5 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 30 Mar 2024 22:49:04 +0200 Subject: Update content for gemtext --- gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi | 4 ++-- gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl | 4 ++-- gemfeed/atom.xml | 6 +++--- index.gmi | 2 +- uptime-stats.gmi | 2 +- 5 files changed, 9 insertions(+), 9 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 0f15de27..3d0bc299 100644 --- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi +++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi @@ -44,8 +44,8 @@ It would be fine if my personal website wasn't highly available, but the geek in * 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. (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) +* 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 system, 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 40a41e7b..473a9d66 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 @@ -44,8 +44,8 @@ It would be fine if my personal website wasn't highly available, but the geek in * 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. (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) +* 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 system, 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 fe2206f8..171fc305 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2024-03-30T22:47:35+02:00 + 2024-03-30T22:48:57+02:00 foo.zone feed To be in the .zone! @@ -65,8 +65,8 @@ _____|_:_:_| (o)-(o) |_:_:_|--'`-. ,--. ksh under-water (((\'/
  • 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. (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)
  • +
  • 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 system, but I didn't need to install any external package on OpenBSD either.)

  • My HA solution



    diff --git a/index.gmi b/index.gmi index 43bf810a..36432ae6 100644 --- a/index.gmi +++ b/index.gmi @@ -1,6 +1,6 @@ # foo.zone -> This site was generated at 2024-03-30T22:48:01+02:00 by `Gemtexter` +> This site was generated at 2024-03-30T22:48:57+02:00 by `Gemtexter` ``` |\---/| diff --git a/uptime-stats.gmi b/uptime-stats.gmi index e0b4467d..d1af372a 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:48:01+02:00 +> This site was last updated at 2024-03-30T22:48:57+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