<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Technet Engineering Blog</title><link>https://technetguy.site/blog/posts/</link><description>Recent content in Posts on Technet Engineering Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 16 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://technetguy.site/blog/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Disk Pressure Is the Boring Way Home Labs Actually Die</title><link>https://technetguy.site/blog/posts/disk-pressure-home-lab/</link><pubDate>Wed, 16 Sep 2026 00:00:00 +0000</pubDate><guid>https://technetguy.site/blog/posts/disk-pressure-home-lab/</guid><description>&lt;p&gt;Our &lt;a href="https://technetguy.site/blog/engineering/home-lab.html"&gt;home lab case study&lt;/a&gt; mentions, almost in passing, that the lab runs a fixed policy: keep every volume under 80% disk utilization. That line does a lot of work, and it&amp;rsquo;s worth unpacking, because &amp;ldquo;disk fills up&amp;rdquo; is a genuinely unglamorous failure mode compared to the things people usually worry about — a misconfigured firewall rule, a leaked credential, an unpatched CVE. But in practice, disk pressure is the failure that actually takes a home lab down, and it does it quietly, at the worst possible time.&lt;/p&gt;</description></item><item><title>Verify Before You Call It Fixed: A WireGuard Habit That Caught a Silent Bug</title><link>https://technetguy.site/blog/posts/verify-dont-assume-wireguard/</link><pubDate>Sun, 13 Sep 2026 00:00:00 +0000</pubDate><guid>https://technetguy.site/blog/posts/verify-dont-assume-wireguard/</guid><description>&lt;p&gt;Our &lt;a href="https://technetguy.site/blog/engineering/open-source-networking.html"&gt;Open-Source Enterprise Networking case study&lt;/a&gt; covers replacing a legacy commercial VPN concentrator with a WireGuard road-warrior mesh for a distributed workforce with no central office to fall back on. The architecture is the headline, but two small operational habits that came out of that rollout are worth a post of their own, because both are the kind of lesson that only shows up after something has already gone quietly wrong.&lt;/p&gt;</description></item><item><title>Investigate Before You Fix: A Field Guide to Hardening Exposed Services</title><link>https://technetguy.site/blog/posts/investigate-before-you-fix/</link><pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate><guid>https://technetguy.site/blog/posts/investigate-before-you-fix/</guid><description>&lt;p&gt;Our &lt;a href="https://technetguy.site/blog/engineering/network-security.html"&gt;network security case study&lt;/a&gt; states the principle in one line: don&amp;rsquo;t patch an exposure until you know exactly who&amp;rsquo;s been using it and how. That&amp;rsquo;s easy to agree with in the abstract and easy to skip under pressure, because a security finding creates an instinct to close it &lt;em&gt;immediately&lt;/em&gt; — and that instinct is usually wrong. Here&amp;rsquo;s the actual pattern, with more of the reasoning behind each step than the case study page has room for.&lt;/p&gt;</description></item></channel></rss>