summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2024-03-30 22:27:31 +0200
committerPaul Buetow <paul@buetow.org>2024-03-30 22:27:31 +0200
commit6d2267804d02930a4e39e545def3e4356535e27c (patch)
treebec3dee3872c148be965a791f6e38b84e6d1d513
parent5bf5026119feb76283b11ffd3f841d94ff7ead44 (diff)
Update content for gemtext
-rw-r--r--gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi2
-rw-r--r--gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl2
-rw-r--r--gemfeed/atom.xml4
-rw-r--r--index.gmi2
-rw-r--r--uptime-stats.gmi2
5 files changed, 6 insertions, 6 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 c0c741e5..d1ea54a5 100644
--- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
+++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
@@ -186,7 +186,7 @@ return 1
A non-zero return code (here, 3 when a rollback and 1 when a DNS failover was performed) will cause CRON to send an E-Mail with the whole script output.
-The nameserver is running on both VMs, and both are configured to be "master" DNS servers so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn't work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that's fine in my use case.
+The authorative nameserver for my domains runs on both VMs, and both are configured to be a "master" DNS server so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn't work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that's fine in my use case.
Check out the whole script here:
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 943d5797..afe45086 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
@@ -186,7 +186,7 @@ return 1
A non-zero return code (here, 3 when a rollback and 1 when a DNS failover was performed) will cause CRON to send an E-Mail with the whole script output.
-The nameserver is running on both VMs, and both are configured to be "master" DNS servers so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn't work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that's fine in my use case.
+The authorative nameserver for my domains runs on both VMs, and both are configured to be a "master" DNS server so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn't work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that's fine in my use case.
Check out the whole script here:
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml
index 54b8621a..0ae3ceba 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:25:58+02:00</updated>
+ <updated>2024-03-30T22:27:18+02:00</updated>
<title>foo.zone feed</title>
<subtitle>To be in the .zone!</subtitle>
<link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" />
@@ -219,7 +219,7 @@ echo <font color="#FF0000">"Failover of zone $zone to $MASTER completed"</font>
<br />
<span>A non-zero return code (here, 3 when a rollback and 1 when a DNS failover was performed) will cause CRON to send an E-Mail with the whole script output.</span><br />
<br />
-<span>The nameserver is running on both VMs, and both are configured to be "master" DNS servers so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn&#39;t work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that&#39;s fine in my use case.</span><br />
+<span>The authorative nameserver for my domains runs on both VMs, and both are configured to be a "master" DNS server so that they have their own individual zone files, which can be changed independently. Otherwise, my setup wouldn&#39;t work. The side effect is that under a split-brain scenario (both VMs cannot see each other), both would promote themselves to master via their local DNS entries. More about that later, but that&#39;s fine in my use case.</span><br />
<br />
<span>Check out the whole script here:</span><br />
<br />
diff --git a/index.gmi b/index.gmi
index 2887d7ea..eb8d2c16 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
# foo.zone
-> This site was generated at 2024-03-30T22:25:58+02:00 by `Gemtexter`
+> This site was generated at 2024-03-30T22:27:18+02:00 by `Gemtexter`
```
|\---/|
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index 722376c4..3a3453f5 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:25:58+02:00
+> This site was last updated at 2024-03-30T22:27:18+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.