From dd04ad281d9123296be1a904cf647f8e7a232d3f Mon Sep 17 00:00:00 2001
From: 53hornet <atc@53hor.net>
Date: Thu, 16 Dec 2021 22:08:00 -0500
Subject: feat: rescue post, colors, centered titles

---
 ...2-14-bypass-oil-filters-on-stepdown-hudsons.php |  23 ++++
 includes/style.css                                 |   9 +-
 pages/index.php                                    |   4 +-
 posts/2021-12-15-rescuing-freebsd-the-unix-way.php | 121 +++++++++++++++++++++
 scripts/new.php                                    |  45 ++++++++
 5 files changed, 197 insertions(+), 5 deletions(-)
 create mode 100644 drafts/2021-12-14-bypass-oil-filters-on-stepdown-hudsons.php
 create mode 100644 posts/2021-12-15-rescuing-freebsd-the-unix-way.php
 create mode 100755 scripts/new.php

diff --git a/drafts/2021-12-14-bypass-oil-filters-on-stepdown-hudsons.php b/drafts/2021-12-14-bypass-oil-filters-on-stepdown-hudsons.php
new file mode 100644
index 0000000..900a13b
--- /dev/null
+++ b/drafts/2021-12-14-bypass-oil-filters-on-stepdown-hudsons.php
@@ -0,0 +1,23 @@
+<h1>Bypass Oil Filters on StepDown Hudsons</h1>
+
+<p class="description">
+	These are my thoughts on oil filters on old-timey flatheads like my Hudson Big Six. I'll talk a little about why you might want to use one and respond to some of the back-and-forth discussion you may find on the subject.
+</p>
+
+<img src="https://nextcloud.53hor.net/index.php/s/rqJmkBTj8S63AN5/preview" alt="Hudson Fram Ad" />
+
+<p>
+	I really like to drive my car. I like to think I'm one of the youngest Hudsonites with the most miles put on his Hornet per year. That means that throughout the restoration process Dad and I were always looking for modernizations or upgrades that could extend my mileage, increase safety, and improve reliability. All while keeping the original drivetrain in tact. One of the simplest modifications was the addition of an oil filter.
+</p>
+
+I confirmed I have no additional orifice restriction on my bypass filter system. I think I have done enough reading to write up my thoughts on this. My reasons come mostly from the 1952 Mechanical Procedure Manual:
+Oil pressure is regulated by a built-in nonadjustable release valve and spring accessible through a plug at the left rear side of the engine. When starting the engine the release valve has moved to a position that closes the oil passageway to the oil filter and allows full pump flow direct through the main oil gallery extending the full length of the crankcase.
+I think over time it's possible for this release valve to wear out, and during restoration some folks may eliminate it. This release valve, when it's doing its job properly, should prevent engine oil starvation due to the filter. I do not see a good reason for arbitrarily increasing the pressure with an orifice restriction. The reason has got to do with oil pressure versus oil flow.
+
+No flow at all due to blockage results in the greatest level of pressure in a system. There are cases where a gallery or orifice blockage (a spun bearing perhaps) can cause oil starvation/low flow to a component when pressure is still good, and no oil dummy light gets lit. What's important is that oil flow is at all times adequate to lubricate the entire system. If the release valve in the block is functioning, it should allow for good flow despite the presence of a filter. Increasing pressure when flow is good may be a no-op.
+
+Oh, and the same book mentions:
+On cars equipped with oil filters the cartridge should be replaced at 5,000 mile intervals or when the oil shows evidence of becoming dirty.
+I'm not saying this is their recommended oil change interval (1000 miles, also in this book). But I do know there is some skepticism on the effectiveness of even modern filters and whether or not the original units were Hudson-endorsed or a sales gimmick. I just wanted to include this as a light indicator of Hudson's trust in a filtration system of any kind. Much of the information in this book may have or has definitely changed over time, but I still think it's a great technical resource.
+
+Whew, anyway, that's my full thought process. As always, the choice is yours!
diff --git a/includes/style.css b/includes/style.css
index e3189fd..4da7343 100644
--- a/includes/style.css
+++ b/includes/style.css
@@ -10,7 +10,7 @@
   --slate: #b9c2ca;
   --charcoal: #798d94;
   --white: white;
-  --box-radius: 0.25em;
+  --box-radius: 0.15em;
   --box-border: 0.5em solid var(--white);
 }
 
@@ -57,7 +57,6 @@ nav svg rect {
 
 a:link {
   color: var(--slate);
-  background-color: var(--balboa);
   border-radius: var(--box-radius);
 }
 
@@ -83,6 +82,11 @@ nav a:active {
   text-decoration: none;
 }
 
+p code {
+  background-color: var(--charcoal);
+  border-radius: var(--box-radius);
+}
+
 pre {
   white-space: pre-wrap;
   display: block;
@@ -107,6 +111,7 @@ blockquote {
   font-style: oblique;
 }
 
+h1,
 header {
   text-align: center;
 }
diff --git a/pages/index.php b/pages/index.php
index 18476bc..6bc999f 100644
--- a/pages/index.php
+++ b/pages/index.php
@@ -1,6 +1,4 @@
-<h1 style="text-align: center">
-	The World Wide Web pages of Adam Carpenter (53hornet)
-</h1>
+<h1> The World Wide Web pages of Adam Carpenter (53hornet) </h1>
 
 <ul>
 	<?php
diff --git a/posts/2021-12-15-rescuing-freebsd-the-unix-way.php b/posts/2021-12-15-rescuing-freebsd-the-unix-way.php
new file mode 100644
index 0000000..0ffa9c5
--- /dev/null
+++ b/posts/2021-12-15-rescuing-freebsd-the-unix-way.php
@@ -0,0 +1,121 @@
+<h1>Rescuing FreeBSD, the UNIX Way!</h1>
+
+<div class="description">
+	<p>
+		I did it, I finally effed up my FreeBSD install.
+	</p>
+
+	<p>
+		It all started with trying to build a custom kernel. <a href="https://docs.freebsd.org/en/books/handbook/mirrors/#git">I used Git to checkout the latest stable source code</a>, but realized I used the wrong branch name. So, I figured I'd interrupt the clone and just remove the <code>/usr/src</code> directory (the standard place to put FreeBSD's source code) and start over. So I changed into <code>/usr/src</code> and ran <code>rm -r *</code>. Only I wasn't in <code>/usr/src</code>, I was in <code>/usr</code>.
+	</p>
+</div>
+
+<p>
+	By the time I realized what was happening and cancelled the operation, I had already wiped out all of <code>/usr/bin</code> and an unknown number of other files and directories. My window manager (i3) fell on its face, and the status bar threw the "I can't run any of these commands" message. Turns out there's a lot of useful stuff I expected to live in <code>/bin</code> that actually lives in <code>/usr/bin</code>! <code>ssh(1)</code> was gone, <code>tar(1)</code> was gone. Even <code>doas(1)</code>! I really, truly, thoroughly effed up my install.
+</p>
+
+<p>
+	Oh God, what about my home directory? Turns out it was still there, along with most (if not all of my files). I'm not enough of an idiot to not have a home snapshot, so I log in as root (<code>doas</code> is gone), and <code>zfs rollback</code> to the rescue. Now my primary concern is getting that home directory out of there, because I didn't feel like restoring it from my cloud backup if the rest of my recovery went bad. But I didn't have <code>ssh(1)</code> or <code>scp(1)</code> to clone it to my server. I did have ZFS' send and receive functionality but I figured I'd take the easy way out and use my unscathed <code>rclone</code> to SCP it to freedom. Pretty sure my data shamed and gloated at me as it reached its lifeboat.
+</p>
+
+<p>
+	So now I could start to fearlessly think about un-effing my install. This is where most people (previously including myself) would suck it up, start from scratch with a USB installer, try to remember all of the customization steps they took to bring the system back to its current working state, and restore user data. But I'm not the man I once was. I've been playing this game long enough. I don't go crawling back to the dusty install media when something as trivial as critical system files go missing or corrupt. I know what I did wrong and I can think of several creative ways to fix it. Say it with me:
+	<img src="https://nextcloud.53hor.net/index.php/s/Gj8GZxLdegkJgG5/preview" />
+</p>
+
+First of all, my entire system (sans <code>/usr/bin</code> is still somewhat operational. I have access to a root shell (and my X session with a browser) so I'm in pretty good shape. I am lacking some very basic core utilities but I might be able to get them back without even rebooting.
+
+I don't have any system-wide snapshots to restore from (believe me I do now). I do have another running FreeBSD 13.0-RELEASE system on my network though: my server. <code>rclone</code> worked to move data over there in an emergency, so I'll use that to copy my coreutils back where they belong. And it worked. Restarting i3 was like that scene in Jurassic Park: "we're back in business!". Now came the hard part. Un-effing everything I <em>didn't</em> know was missing or broken.
+
+I can reinstall my entire package tree pretty easily, so I'm not that worried about anything missing from <code>/usr/local</code>. I'm a <code>pkg leaf | xargs pkg install -f</code> away from completely restoring those. Maybe I have one or two config files in <code>/usr/local/etc</code> that I can live without. I know <code>/usr/home</code> is safe and restored. So all that's left is stuff like <code>lib, sbin, include, lib32, share</code> and a few others that aren't very unique to my system (packages notwithstanding).
+
+Here's where the YOLO part begins. I was already in the middle of building my system from source to track FreeBSD 13.0-STABLE, instead of RELEASE. So instead of using a rescue CD to copy just the right files back or completely reinstalling my system, I'll just <code>make buildworld</code> and upgrade/replace my system in-place to track STABLE. The install/upgrade/switching process is well-documented, and there are already difftools/mergetools responsible for making sure that all of the new artifacts go exactly where they're supposed to (overtop of your old or broken existing ones).
+
+https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
+
+So let's follow the Handbook shall we? I'll start where I left off when everything imploded. Clean out <code>/usr/src</code> and clone the source tree.
+
+<pre>
+<code>
+# rm -r /usr/src/*
+# git clone -b stable/13 https://git.FreeBSD.org/src.git /usr/src
+</code>
+</pre>
+
+And then start by compiling the world (userland) and the kernel. I'm going to use the GENERIC kernel for now so I can just get back up and running.
+
+<pre>
+<code>
+# make -j 4 buildworld buildkernel
+</code>
+</pre>
+
+It took literally hours. Poor little dual-core i5. It was already well on its way to completing when I realized I could have done this on my 8-core/16-thread server. "Oh, so you're reckless <em>and</em> stupid." Don't worry, I redeem myself later. Now I can actually install the new kernel and reboot into it. This is required before installing the world (userland).
+
+<pre>
+<code>
+# make installkernel
+...
+# reboot
+</code>
+</pre>
+
+After rebooting I can check out my new version.
+
+<pre>
+<code>
+# freebsd-version
+13.0-RELEASE
+</code>
+</pre>
+
+Hmm, probably can't use <code>freebsd-version</code> because it's tied to the userland and <code>freebsd-update</code>. Let's try <code>uname</code>:
+
+<pre>
+<code>
+# uname -r
+13.0-STABLE
+</code>
+</pre>
+
+Success. Kernel is rebuilt, reinstalled, and tracking STABLE. Now it's time to install/upgrade everything else. Side note: this is one of the cool things about FreeBSD. It's a complete operating system, not just a kernel or a userland. All of the pieces were made to fit together instead of being glued together into a distro.
+
+<pre>
+<code>
+# make installworld
+</code>
+</pre>
+
+This took a little bit longer, but from the output I could see that all of my important, potentially-missing binaries were being installed. Libraries, core utilities, applications, daemons, and man pages all got put back in their proper place. My system is totally back to life nad I'm confident that I'm running an un-maimed FreeBSD 13.0-STABLE.
+
+Now comes the sanity checking part of this job. I'm actually running a newer system now than I was before the upgrade. One of the components that was upgraded was ZFS, and with every major ZFS upgrade, I'm going to reinstall my ZROOT bootloader:
+
+<pre>
+<code>
+# gpart bootcode -p /boot/gptzfsboot -i 1 ada0
+...
+# reboot
+</code>
+</pre>
+
+This may be unecessary, but it ensures that my root-on-ZFS will load correctly after a reboot with the new ZFS. And to be fair, it is mentioned in the <a href="https://cgit.freebsd.org/src/tree/UPDATING?h=stable/13"><code>UPDATING</code></a> guide in the source.
+
+After a reboot, I've got one more sanity check. FreeBSD comes with <code>etcupdate(8)</code>, which you can use to manage merging upgrades with local changes to your <code>/etc /usr/local/etc</code> system config. If you run <code>etcupdate diff</code> you can see a diff of all of your customized system config. This is so good, I can't believe something like this doesn't exist on your typical Linux distro. Maybe it does and I just never realized it, but I'm betting they're all just different enough to not be able to share something like this. Anyway, after reviewing the diff, I applied any changes/merges by running <code>etcupdate</code>.
+
+Now for one last bit of housekeeping, and this comes straight from the handbook. After an upgrade, the world installation leaves behind old libraries and files that the new system doesn't need but old applications or ports built against an older target might still require. To get rid of them, you can use the <code>Makefile</code> directives in <code>/usr/src</code>
+
+<pre>
+<code>
+# make check-old check-old-libs
+</code>
+</pre>
+
+After reviewing the list and ensuring you don't need those files, you can clean them up with
+
+<pre>
+<code>
+# make BATCH_DELETE_OLD_FILES=yes delete-old delete-old-libs
+</code>
+</pre>
+
+Redemption. I went from attempting to customize my kernel to annihilating <code>/usr</code> to restoring my entire system by building from FreeBSD's source tree via <code>git</code> and <code>make</code>. And I got an upgrade in the process too! Moving forward, I'm running slightly frequent automatic full-system snapshots. It should make it a lot easier to rescue accidental deletions of system files. I'm also going to take the time to learn more about the rescue disk process using the FreeBSD installer image. All told, not too bad for something that could have gone a lot worse.
diff --git a/scripts/new.php b/scripts/new.php
new file mode 100755
index 0000000..f272a8a
--- /dev/null
+++ b/scripts/new.php
@@ -0,0 +1,45 @@
+#!/usr/bin/env php
+<?php
+if (empty($argv[1])) {
+	exit;
+}
+
+const exceptions = [
+	"vs", "above", "across", "against", "at", "between", "by", "along", "among", "down", "in",
+	"once", "around", "of", "off", "on", "to", "with", "before", "behind", "below", "beneath",
+	"down", "from", "near", "toward", "upon", "within", "a", "an", "the", "and", "but", "for",
+	"or", "nor", "so", "till", "when", "yet", "that", "than", "in", "into", "like", "onto", "over",
+	"past", "as", "if"
+];
+
+// Gather arguments and join into title-cased string.
+$title_words = array_slice($argv, 1);
+$title_words = array_map(
+	fn (string $word) => in_array($word, exceptions) ? lcfirst($word) : ucfirst($word),
+	$title_words
+);
+$title_words[0] = ucfirst($title_words[0]);
+end($title_words);
+$key = key($title_words);
+$title_words[$key] = ucfirst($title_words[$key]);
+
+// Generate HTML title.
+$title = implode(' ', $title_words);
+$title = "<h1>$title</h1>\n\n";
+
+// Generate post filename/URL.
+$filename = strtolower(implode('-', $title_words));
+$date = date('Y-m-d');
+$filename = "$date-$filename.php";
+
+if (!$handle = fopen("./drafts/$filename", 'a')) {
+	fwrite(STDERR, "Cannot append to file: $filename\n");
+	exit;
+}
+
+if (fwrite($handle, $title) === false) {
+	fwrite(STDERR, "Cannot write contents to file: $filename\n");
+	exit;
+}
+
+printf("Created post %s\n", $filename);
-- 
cgit v1.2.3