diff options
| author | Paul Buetow <paul@buetow.org> | 2024-03-30 22:48:15 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2024-03-30 22:48:15 +0200 |
| commit | 3ad4a3576172bfd951c6a1e954fb6168b4bf2d1f (patch) | |
| tree | ccba41d78105cc0bc4e795bc7cb402ae348e7d34 | |
| parent | b5e0cf471976f95aae88309e08b3389bd3b88296 (diff) | |
Update content for md
| -rw-r--r-- | gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.md | 6 | ||||
| -rw-r--r-- | index.md | 2 | ||||
| -rw-r--r-- | uptime-stats.md | 2 |
3 files changed, 5 insertions, 5 deletions
diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.md b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.md index 4fa285be..f1668995 100644 --- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.md +++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.md @@ -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 @@ -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.md b/uptime-stats.md index aed0b3f8..4ad16b21 100644 --- a/uptime-stats.md +++ b/uptime-stats.md @@ -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. |