diff options
| -rw-r--r-- | gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html | 6 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 8 | ||||
| -rw-r--r-- | index.html | 2 | ||||
| -rw-r--r-- | uptime-stats.html | 2 |
4 files changed, 9 insertions, 9 deletions
diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html index f405311c..b024ed8b 100644 --- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html +++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html @@ -49,14 +49,14 @@ _____|_:_:_| (o)-(o) |_:_:_|--'`-. ,--. ksh under-water (((\'/ <br /> <ul> <li>Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. </li> -<li>Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already).</li> +<li>Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already!).</li> <li>It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.</li> <li>It should be geo-redundant. </li> <li>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.</li> <li>Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.</li> <li>Let's Encrypt TLS certificates should always work (before and after a failover).</li> -<li>Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover.</li> -<li>Don't configure everything manually. The configuration should be automated and reproducible.</li> +<li>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)</li> +<li>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)</li> </ul><br /> <h2 style='display: inline'>My HA solution</h2><br /> <br /> diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 5e74adcf..3760e740 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> - <updated>2024-03-30T22:42:12+02:00</updated> + <updated>2024-03-30T22:47:35+02:00</updated> <title>foo.zone feed</title> <subtitle>To be in the .zone!</subtitle> <link href="https://foo.zone/gemfeed/atom.xml" rel="self" /> @@ -59,14 +59,14 @@ _____|_:_:_| (o)-(o) |_:_:_|--'`-. ,--. ksh under-water (((\'/ <br /> <ul> <li>Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. </li> -<li>Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already).</li> +<li>Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already!).</li> <li>It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.</li> <li>It should be geo-redundant. </li> <li>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.</li> <li>Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.</li> <li>Let's Encrypt TLS certificates should always work (before and after a failover).</li> -<li>Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover.</li> -<li>Don't configure everything manually. The configuration should be automated and reproducible.</li> +<li>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)</li> +<li>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)</li> </ul><br /> <h2 style='display: inline'>My HA solution</h2><br /> <br /> @@ -10,7 +10,7 @@ <body> <h1 style='display: inline'>foo.zone</h1><br /> <br /> -<span class='quote'>This site was generated at 2024-03-30T22:42:12+02:00 by <span class='inlinecode'>Gemtexter</span></span><br /> +<span class='quote'>This site was generated at 2024-03-30T22:48:01+02:00 by <span class='inlinecode'>Gemtexter</span></span><br /> <br /> <pre> |\---/| diff --git a/uptime-stats.html b/uptime-stats.html index 3576d293..4337cf91 100644 --- a/uptime-stats.html +++ b/uptime-stats.html @@ -10,7 +10,7 @@ <body> <h1 style='display: inline'>My machine uptime stats</h1><br /> <br /> -<span class='quote'>This site was last updated at 2024-03-30T22:42:12+02:00</span><br /> +<span class='quote'>This site was last updated at 2024-03-30T22:48:01+02:00</span><br /> <br /> <span>The following stats were collected via <span class='inlinecode'>uptimed</span> on all of my personal computers over many years and the output was generated by <span class='inlinecode'>guprecords</span>, the global uptime records stats analyser of mine.</span><br /> <br /> |