<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Homelab on Ownchain Systems</title>
    <link>https://ownchain.systems/tags/homelab/</link>
    <description>Recent content in Homelab on Ownchain Systems</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 30 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ownchain.systems/tags/homelab/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CODEX-001: Decommissioning Socket-Mounted Web UIs &amp; Enforcing Terminal-Native Ops</title>
      <link>https://ownchain.systems/codex/001-socket-hardening/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/001-socket-hardening/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Ingress Hardening &amp;amp; Attack Surface Reduction&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report documents the architectural lifecycle of container management on Bastion: from initially deploying a web-based GUI (Portainer) to overcome early CLI friction, to identifying the inherent security risks of host-socket mounting, and finally decommissioning the interface in favor of key-authenticated, terminal-native tooling (&lt;code&gt;lazydocker&lt;/code&gt;).&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;phase-1-initial-deployment--context&#34;&gt;Phase 1: Initial Deployment &amp;amp; Context&lt;/h2&gt;&#xA;&lt;h3 id=&#34;why-portainer-was-introduced&#34;&gt;Why Portainer Was Introduced&lt;/h3&gt;&#xA;&lt;p&gt;When initially transitioning to Docker and container orchestration, early CLI management presented significant friction. Debugging multi-container networks, diagnosing container start failures, and managing persistent volume paths purely through raw shell commands often led to silent errors and operational overhead.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-002: Hardening the Domain Mail Perimeter (SPF, DKIM, DMARC)</title>
      <link>https://ownchain.systems/codex/002-mail-auth/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/002-mail-auth/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Perimeter Defense &amp;amp; Mail Authentication&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report covers auditing, remediating, and enforcing cryptographic and domain-level email authentication records (SPF, DKIM, and DMARC) across a multi-service custom domain. The objective was resolving silent delivery failures for automated application notifications, aligning third-party transactional mail providers, and enforcing a strict quarantine policy to protect domain reputation against spoofing and phishing attempts.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--problem-statement&#34;&gt;Threat Model &amp;amp; Problem Statement&lt;/h2&gt;&#xA;&lt;p&gt;When operating self-hosted services alongside third-party transactional email relays and professional mail routing, misaligned authentication headers lead to two major failure modes:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-003: Container Lifecycle, Layer Drift &amp; Database Migrations</title>
      <link>https://ownchain.systems/codex/003-container-lifecycle/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/003-container-lifecycle/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Operational Lifecycle &amp;amp; Database Resilience&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report documents the failure modes, triage, and safe maintenance patterns discovered while updating multi-container microservice stacks with tightly coupled database dependencies. It analyzes race conditions during parallel image layer pulls, container recreations vs. image caching, and ensuring zero data loss during automated backend schema migrations.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;the-problem-statement--failure-modes&#34;&gt;The Problem Statement &amp;amp; Failure Modes&lt;/h2&gt;&#xA;&lt;p&gt;Updating production-grade container stacks (such as Firefly III, its importer, cron sidecar, and MariaDB/MySQL backend) presents subtle operational risks if treated like simple stateless containers:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-004: Validated Backups &amp; Disaster Recovery Drills</title>
      <link>https://ownchain.systems/codex/004-disaster-recovery/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/004-disaster-recovery/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Business Continuity &amp;amp; Disaster Recovery (BC/DR)&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report details the implementation, cryptographic architecture, and verification lifecycle of Bastion&amp;rsquo;s automated disaster recovery pipeline. Moving beyond passive snapshots, the architecture enforces client-side AES-256 encryption, offsite repository replication, and regular cold-restore validation drills to guarantee deterministic recovery in the event of catastrophic storage or hardware loss.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--failure-scenarios&#34;&gt;Threat Model &amp;amp; Failure Scenarios&lt;/h2&gt;&#xA;&lt;p&gt;A backup strategy that has not been restored is merely a hypothesis. The backup architecture was designed to mitigate four specific failure modes:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
