MISSION OPERATIONS LOG

Automation Server Updated to the Latest Release and an Old Remote-Access Program Removed from the Media PC (Oct. 16, 2026)

The automation server was moved from version 2.41 to the current 2.43 after the new release was pulled first and its database was copied to a separate backup folder; downtime was about half a minute, all 47 workflows and 29 saved credentials were intact, and scheduled runs resumed within a minute with no errors. The release notes were checked first and showed nothing breaking. The next major version (3.0) is not out yet, so it will be left until it settles. Separately, the media PC’s security check showed an unused remote-access VPN program still installed from years ago; the owner uninstalled it and its network port no longer answers.

Server Updates and a Planned Main-Server Reboot Completed Cleanly (Oct. 16, 2026)

The trading-bot container host and the cloud-storage, automation, and AI servers received their pending package updates, and the main server was updated to its newest kernel and restarted in a planned window. Every container and virtual machine came back by itself in its configured order; the vault, home-automation hub, automation server, AI server (both GPUs), cloud storage, media server, radio node, and all 23 public site names were checked afterward, and the radio link and the off-box monitoring unit reported normally. The vault and some home-automation add-ons took a few extra minutes to start after the hub itself, which is normal. A fresh backup of the trading-bot container was taken first, and older kernels remain available as a fallback.

Security Review Gap-Fill: Access Tokens, Backups, DNS and Email Settings, Power Resilience, and Radio Gear Checked (Oct. 16, 2026)

What was done (read-only): the remaining gaps from the security review were checked. Stored credentials were inventoried by age (no values read). The smart-home hub was found to hold thirteen full-power access tokens, several old enough to deserve a review. Its backups were confirmed to include the password vault, but only on its own disk, and there was no full backup between June and October. The website names were mapped to see which sit behind the cloud shield and which point straight at the house; several do. The home internet address is assigned dynamically; the dynamic-DNS updater keeps the names current (owner-confirmed). Most domains have no anti-spoofing email records. The servers have no automatic shutdown on power loss (that project is on hold). The Gmail assistant was confirmed draft-only by its configuration. The lights-out management card of the main server was also checked read-only through a login-only account: it is current, powers the server back on by itself after an outage, has no failed logins, and has a few unneeded remote services switched on (listed in the private report). Not reachable without the owner or extra access: TV and access-point firmware, the Windows PCs’ update state, and the cloud-DNS dashboard.

Access Hardening: Key-Only Remote Login, AI Server Firewall, and Infrastructure Passwords Rotated (Oct. 15, 2026)

Password-based remote login was turned off on fourteen containers (verified from outside: all now accept keys only). The AI server’s raw interface now accepts connections only from the servers that use it, and the chat website for family and friends is unaffected. The web-proxy status page password and the network-switch password were replaced because the old ones had been shown on a screen, and the website admin and trading logins were reset because the only printed list was lost. The new values are in the private upload folder, not here. One server’s DNS was moved off a public resolver onto the home filter.

Cloud Storage Brought Up to Date and Backed Up for the First Time (Oct. 15, 2026)

The personal cloud-storage server (about 181 GB of files) turned out to have no backup at all, because the nightly container backups skip its data volume. All files were copied to the external backup drive (file counts matched exactly), the database was dumped, and a fresh container backup was taken before the software was updated to the newest release of its current version. Sign-in, the file list, and the integrity check were verified afterward and routine database maintenance items were cleared. A weekly job now copies new and changed files plus a fresh database dump to the drive and never deletes backed-up files. A leftover configuration backup containing secrets was moved out of the web folder.

Security Fixes Round 1: Router Access, Website Hardening, and Public Automation Endpoints Closed (Oct. 15, 2026)

Router management logins were blocked from the amateur-radio network side and every admin account was limited to the home network and the VPN; the packet-radio links were re-tested afterward and still work. Standard browser security headers were added to the self-hosted websites, and the old remote-publishing interface, the public author list, and an exposed debug log were shut off. Of twelve automation endpoints that needed no password and were open to the internet, five unused ones (including the AI chat bridge) were closed to everyone outside the home network and VPN and one status feed was restricted to home and VPN; six remain public because pages, scripts, or the phone use them, now with a rate limit. Every change has a rollback.

Whole-Lab Security Review: Read-Only Audit of the Network, Servers, and Devices (Oct. 15, 2026)

What was done: a full read-only security review in five phases. Every device on the network was found and identified, the internet-facing surface was checked site by site, and each server and container was examined for logins, updates, backups, and exposed services. Result: no sign of an intrusion. The biggest problems were administrative access reachable from the amateur-radio network side, a set of unprotected automation endpoints open to the internet, a cloud-storage volume with no backup, and a completely flat network with unpatchable cameras on it. A ranked report and a change log (every change with a rollback) were saved privately. Limits: nothing could be tested from outside the house, and a few areas were not reached (see the follow-up task).

Main Server Drive Health Baseline Taken (Read-Only): 12-Drive Storage Array and the Two System SSDs (Oct. 14, 2026)

What was done: a read-only snapshot of every drive on the main server’s storage controller: the controller, its cache and capacitor report OK; all twelve array drives and both mirrored system SSDs pass their health checks and run cool (28 to 31 °C). Eight of the array drives are about 8 years old, the rest 2.7 to 3.5 years; the SSDs are about 7 years old and about 21 to 22% worn. Watch list: one array drive has two uncorrected read errors (covered by the array’s redundancy) and a grown defect; two more drives have one grown defect each. This snapshot is the baseline for Saturday’s extended drive tests.

Packet Box Disk Health Check: Clean So Far; Long Surface Test Running (Oct. 14, 2026)

Result: the drive passes its health self-assessment, a short self-test finished without error, there are no bad, pending or reallocated sectors, no drive or kernel I/O errors, the filesystem reports clean, and the disk is 13% used. Two older counters (cable-type errors and command timeouts) sit at 32 and did not grow during the test. The drive is an older used unit with roughly 14,700 power-on hours and runs a little warm (about 46 °C). The longer full-surface self-test then finished without error (about 49 minutes): still no bad, pending or reallocated sectors and an empty drive error log. The drive reached 50 °C during the test (its recorded maximum was 48 before), so cooling and dust are worth a look when the owner opens the box on Saturday. CMOS battery: the owner measured 3.0 V, which is aging but not dead; the software cannot read the battery directly. The clock kept correct time across two recent reboots, but those were on wall power, so that is not a battery test.

Solar Dashboard Confirmed Working After Sunrise; Empty Production Curve Fixed (Oct. 14, 2026)

Check after sunrise: once the sun was up the new solar connection reported real values (about 1,380 W and 0.65 kWh at 8:52 AM) and the solar data file picked them up on its next 15-minute run. The night-time fix from earlier held: zero overnight instead of “unknown”. Problem found: the production curve stayed empty. Cause: the workflow asked Home Assistant for 30 hours of history, and because the new sensor only began recording the previous evening, a window starting before it existed made Home Assistant leave out the newest readings. Fix: the history window now starts at local midnight. The next run showed the curve filling in (0 W at 6:49 AM, 1,381 W at 8:52 AM); with the connection polled hourly to save its monthly request allowance, expect about one curve point per hour. Note: the “last update” time on the data shows the site’s own timestamp, which is only refreshed every six hours.

Two New Live Pages: the Property Overview and the Systems Cutaway, Fed by a Delayed, Rounded Public Data Feed (Oct. 14, 2026)

What was built: two public pages that copy the picture panels from the Home Assistant property dashboard: an illustrated night view of the property with live labels (internet speed, solar power, outdoor temperature, wind, radio propagation, router temperature, radio-room and air-conditioning power, and three access-point status icons) and an illustrated house cutaway with its own labels (solar today, switch and router temperatures, indoor and outdoor temperature, house load, air conditioning, garage and propagation). The entity-card grids below the pictures were deliberately not copied. Pictures are stored on the site; labels are positioned in percent so they scale; phones scroll the picture sideways so the text stays readable. Both pages are in the home-page menu and the navigation bar of ten other pages. Privacy rules set by the owner: readings are published 15 minutes late, power is rounded to the nearest 50 W, hardware models and device names are not shown (generic labels, access points are plain icons), and only the 17 approved readings are ever published. A page shows an OFFLINE badge if the data is more than 45 minutes old, and “no data yet” if the feed is missing. Security: a new dedicated Home Assistant access token is stored only on the automation host, readable by root alone, and never appears in a page, the data file or a log; it can be revoked on its own. Status: pages tested in a headless browser at desktop and phone widths, including the offline and no-data states; the first live reading was published 15 minutes after setup and both live pages were confirmed showing real numbers (Oct. 14, about 8:15 AM Eastern).

Online Bookstore Listings: Free-Sample Link Added to All 17 Book Descriptions; Two Solar Repair Notices Dismissed (Oct. 14, 2026)

Bookstore: each of the 17 book listings now opens with a line inviting readers to download a free sample first, and noting that both PDF and e-reader formats come with the purchase. Prices, published status and files were unchanged, and one public page was re-read to confirm the new line shows. The original descriptions were saved as a backup. The store profile (bio, layout) cannot be set through the store’s interface for developers, so that part stays with the owner, with the text ready in the promo kit. Home Assistant: the two leftover “unit changed” notices for the monthly and yearly solar totals were already fixed at the data level; statistics validation now reports no problem for them, so the stale notices were dismissed (reversible). Solar page: not yet confirmable because the sun was not up at the time of the check.

Book Marketing Round 1: Free Samples for All 17 Books, Related-Book Boxes, and a Promo Kit (Oct. 14, 2026)

What was done: a free sample (the first pages plus a “get the full book” page with links and a QR code) was built for each of the 17 books and put on the bookstore site, with a “read a free sample” link on every book page. A small “related book” box with a sample link now appears at the end of matching posts on the AI news site and one bookstore blog post; links are tagged so visits can be traced in analytics. A promo kit was written for the owner: Gumroad profile text and one-liners, five forum post drafts with honest AI-assistance wording, an email signature, and a printable 10-up business-card sheet with QR codes. Rules kept: nothing was posted or sent anywhere, nothing goes out over amateur radio, and the books are not linked from the radio-identity website. Not done: other sites were left alone because their topics do not match the books.

Bookstore Website: E-Reader Versions Added Next to the PDFs on 16 Books and the Page Wording Updated (Oct. 14, 2026)

What was done: the 16 books that were PDF-only on the bookstore site now also include the new e-reader file at checkout, added beside the existing PDF so past buyers keep their access. The seventeenth book already had both. The frequently-asked-questions text on each of the 16 pages (and its hidden search-engine copy) now says the book includes both formats instead of “a digital PDF download”, matching what the page already promised about getting “both files”. Prices and published status were unchanged. Checked: the file downloads from the public address, one page was re-read live, and the product still shows as downloadable with two files. The bundle (a ZIP of the PDFs) was left as it was. The new e-reader files are text-only builds without the diagrams that the PDFs include.

Online Bookstore: Why the E-Reader Versions Were Missing, and All 17 Books Now Offer Both Formats Again (Oct. 14, 2026)

Why they were missing: on Oct. 1 the AI-generated covers raised a copyright concern, so the old listings were deleted and recreated with the new covers as PDF-only; the old e-reader files still carried the old covers and were left off on purpose. New e-reader files with the new covers had been built and checked the same day, but were never put back on the store. Done: the new e-reader file was added next to the PDF on each of the 17 books (the PDFs were kept as they were; prices and published status unchanged). The store now reports 17 PDF and 17 e-reader files. Note: the new e-reader files are smaller than the 2023-era ones because they were built from text-only sources without the diagrams; the PDFs still have the diagrams. The bundle holds no files of its own, and the booksrus.biz site is still PDF-only.

Two Home Assistant “Unit Changed” Repairs Fixed for the Monthly and Yearly Solar Totals (Oct. 14, 2026)

What it said: the monthly and yearly solar production totals had been saved earlier without a unit and now report kWh, so Home Assistant offered to either relabel or delete their history. Check: the stored values (about 627 and 15,731) were already kWh-sized numbers, so nothing needed converting. Fix: the history was relabeled as kWh (no values changed or deleted); both now show as energy. The two repair notices clear the next time Home Assistant re-checks its statistics.

Online Bookstore: Why Searches Did Not Find the Books, and Categories and Tags Set on All 18 Listings (Oct. 14, 2026)

Finding: the store page itself works with all 18 products, but the marketplace’s own search returned other sellers’ products and none of ours. The marketplace only lists a product in search after the account has real sales, payout details and a passed review, so with zero sales so far the books cannot appear there yet. Done: every listing had the catch-all “Other” category and no tags. All 18 now have a fitting category (hardware, programming, cybersecurity and so on) and five tags each, set through the store’s API and read back to confirm. Prices and published status were unchanged. Next: sales and payout status are the owner’s to check in the dashboard; adding the store link to the other sites is pending.

Solar Readings Now Show Zero at Night Instead of “Unknown” (Oct. 14, 2026)

What was seen: early this morning the solar power and today’s production showed “unknown” and the web page kept showing yesterday’s totals. Cause: the new solar connection reports no value at all when the sun is down, and the small community add-on that reads it turned “no value” into “unknown” (the old connection showed zero). Fix: a one-line change for each of the two readings so that no data means zero, after backing up the original file, followed by a Home Assistant restart. Both now read zero in the dark. The month, year and lifetime figures are unchanged. Watch: an add-on update will overwrite the change, so it is noted to re-apply; the daytime curve on the page is still to be confirmed once the sun is up.

High-Temperature Alerts Added for the Server Processors and Graphics Cards, With Normal and Urgent Levels (Oct. 14, 2026)

What it does: once a minute the temperatures of both server processors (package and every core) and both graphics cards are checked. A “high” alert (normal priority) fires at 70 °C for the processors and 80 °C for the graphics cards; an “urgent” alert fires at 80 °C and 88 °C, chosen to leave a margin below the chips’ own warning, throttle and shutdown points. Alerts go to the independent notification server so they still arrive if the main server is in trouble, and urgent ones are also relayed to the phone-only critical channel. Repeat alerts are rate-limited, a short “back to normal” note follows a recovery (with a 3-degree buffer so it does not flap), and a separate alert fires if the readings go missing for 15 minutes. Tested with lowered limits: alert, quiet repeat, and recovery all behaved.

Packet Node Temperature Command Improved: Plain “Core N: nn C” Layout, Hottest-Core Line, and Graphics-Card Temperatures Added (Oct. 14, 2026)

What changed: the node’s temperature command now prints each core as “Core 0: 38 C” for both processors, followed by a “Hottest core” line, then the temperatures of the server’s two graphics cards. The cards are passed through to a separate virtual machine, so the readings are collected there once a minute and handed to the node through the hypervisor, with no new network doors or logins opened. Each reading shows a warning if it is more than five minutes old. Typical values today: cores 32 to 41 °C, graphics cards 35 to 40 °C at idle.

Packet Node CPU Temperature Command Fixed: It Now Shows All 24 Core Temperatures of the Server It Runs On, in Celsius (Oct. 14, 2026)

What was wrong: the node’s “cputemp” command printed empty lines because the node is now a virtual machine, which has no temperature sensors of its own (the old physical PC did). Fix: the host server reads its own sensors every minute and hands the readings to the node through the hypervisor’s guest channel, so no new network doors or logins were opened. The command now shows both processor packages and all 12 cores of each, in Celsius, and warns if the reading is more than five minutes old. Typical readings today: packages 39 to 46 °C, cores 32 to 41 °C. The old script is kept for rollback.

Packet Network Summary Written: Upgrades, Routing Changes, Both Raspberry Pis and the Packet Node (Oct. 14, 2026)

What was done: a professional write-up of everything changed on the amateur-radio packet network since early September, for sending to other operators. It covers the BBS box (new operating system, software upgrades, ports, forwarding fixes, crash history), the packet node rebuild and cutover, the two Raspberry Pi nodes (key-only access, intrusion protection, IPv6, corrected gateways), all routing and address-translation changes on the router, the monitoring that now catches silent failures, and a short list of still-open items. No passwords or private addresses are included. Built from the tracker history and notes, not re-verified box by box; the owner will review before sending.

Packet Node Software Upgraded to the Latest Release After Last Week’s Buffer-Exhaustion Crash (Oct. 14, 2026)

What happened: the packet node had crashed on Oct. 12 when its internal buffer pool ran out, and was restarted on the same version. The author’s newest release was downloaded to a staging folder first, then installed with a full backup of the configs, the old program and the mail state (with checksums). The node stopped cleanly in 9 seconds, the only config change on shutdown was user activity counters, and it restarted on the new version. Verified: telnet login prompt, POP3, FTP, SMTP, the web interface and WebMail, and the public sites all answer, with no fatal errors or core dumps logged. WebMail stays open; the old program is kept for a one-command rollback. Watch: if the buffer exhaustion recurs, re-apply the WebMail block and send the author the evidence already collected.

Solar Monitoring Moved to the Vendor’s New Interface Ahead of the Nov. 1 Retirement; Dashboards, Energy Page, and Automations All Switched Over (Oct. 13, 2026)

What happened: the installer had created a free-tier application on the vendor’s new developer platform, and the owner’s login was re-linked to the site on the vendor side, which fixed the “no site linked to your account” error. A community-built Home Assistant add-on for the new interface was code-reviewed first (it only talks to the vendor’s own servers, uses no shell or file access, and has no outside dependencies), then installed after a full Home Assistant backup. Two bugs in it were worked around: the vendor’s sign-in redirect leaves out a security value that the redirect page insists on (the sign-in code was handed to a fresh setup directly), and the new interface now requires UTC timestamps, which needed a one-line local patch (original saved beside it).

Result: the new sensors report live power, production today, lifetime, and peak. The new lifetime figure (about 121.5 MWh) matches the vendor app (about 122 MWh); the old interface’s lifetime number (about 94.6 MWh) was simply wrong. Month and year totals now come from two helper counters seeded with the old values. The three dashboards and the Energy page’s solar source were repointed (the Energy page’s solar graph restarts from today; history stays on the old sensor), the inverter and site-status tiles were removed, and three n8n workflows now read the Home Assistant sensors instead of calling the vendor directly (no vendor credits used; an old API key that was written into one workflow’s code was removed). The inverter health monitor workflow was retired because the new interface has no per-inverter data; consumption and grid readings stay on the energy monitor. All originals are backed up. Replaces TASK 494.

The Three Skipped Content Drafts Were Created and the Redirect Fix Is Confirmed in Practice (Oct. 13, 2026)

The three content pipelines whose Oct. 12 runs had silently produced nothing (because they posted to old addresses that redirect) were run once by hand after the fix. Each succeeded and created one new draft on its site, and its notification step also passed. This confirms the earlier fix works end to end, not just on paper. The command-line runner turned out to be unable to start these workflows, so a temporary one-time trigger was used and then removed; each workflow now also has a harmless manual-start button for future testing. The fourth pipeline, which had a different login problem, was then run the same way and also succeeded with a new draft, so all four delayed content pipelines are now verified working.

Solar Alerts Tuned After the Vendor Began Early Outage Windows on Its Old Interface (Oct. 13, 2026)

What happened: the solar vendor’s old monitoring interface began answering “scheduled deprecation window” for about an hour at a time, several times a day, ahead of its Nov. 1 retirement. One automation that depends on it failed during each window and paged the phone. The vendor’s message says it is a scheduled window and not an outage; the same key works between windows.

Two changes: that one workflow now alerts only after three hours without a success instead of after two failed runs, so routine windows no longer page. And a new check reads the solar page’s own “served from cache” and cache-age fields and sends a normal-priority heads-up if the numbers on the page are more than 90 minutes old. Both were proven (the second with a simulated stale file). Open: the new-interface access still depends on the installer and vendor support; the three skipped Oct. 12 content drafts have not been run yet (the command-line method cannot start those workflows, so nothing was created).

Silent-Failure Monitoring, Power Side: Restart Detector Added (Last-Boot Monitor); Direct UPS Monitoring Stays on Hold (Oct. 13, 2026)

What it does: the three physical machines (main server, packet-node server, monitoring Pi) report their last boot time every five minutes to the off-box watcher. An unexpected restart sends a phone alert that says when it happened and how long the machine had been up. If two or more machines restart within ten minutes of each other, the alert escalates to a critical “probable power loss” warning that is also relayed away from home. If a machine’s own report goes silent for thirty minutes, that alerts too, so a broken reporter cannot hide a restart.

Proven with simulated machines only (nothing was rebooted): no alert on first sight, a restart alert, the power-loss escalation, the silent-reporter alert and its recovery. Installing it set baselines without any alert, and it stayed quiet on the real machines afterwards. A planned restart will also send a normal-priority alert, which can be ignored. It cannot warn before power fails or show battery levels, which would need a connection to the UPS units.

Direct UPS monitoring remains on hold by the owner’s decision; nothing for it was built or installed.

Silent-Failure Monitoring, Phase 5: Websites Are Now Checked From Outside, and the Packet-Link Neighbors Are Watched for Silence (Oct. 13, 2026)

Outside website check: a small free program running on Cloudflare’s network visits twenty of the public sites every five minutes, retrying once before counting a failure. The home-side watcher pulls its results every minute and raises a critical alert after two failed checks in a row (about ten minutes), a recovery message when the site answers again, and a reminder every six hours while it stays down. If the program itself stops updating, that raises its own alert. All three paths were proven live: a deliberately unreachable test target gave a critical alert on the phone and a recovery message, and a forced stale-results test gave the “checker went silent” alert.

A design change forced by testing: the first version sent alerts straight from Cloudflare to the free public notification service, which answered every send with a daily-quota error because anonymous senders share addresses with many other users. Nothing was delivered and nothing complained. The program now only records results and serves them, behind a secret, to the home watcher, which sends the alerts over the path already proven to reach the phone.

Packet-link neighbors: every five minutes the node’s own neighbor table is read. The 44.x-network neighbor and the Wisconsin neighbor must each be heard within an hour, and at least 60 percent of all 29 neighbors within two hours. Today all 29 are heard. This is the receiving-side check that would have caught the earlier private-visibility outage. Proven with a forced failure and recovery.

Also: a false storage alarm earlier in the day was traced to cron’s minimal search path and fixed; the daily scripts were retested under the same restricted environment. The packet-node backup rerun finished cleanly (16 GB, integrity-tested). The Cloudflare token used to deploy was deleted after verification and should be revoked in the Cloudflare dashboard. Still open: Phase 6, power monitoring, which waits on the UPS monitoring computers.

Silent-Failure Monitoring, Phase 4: Storage and Backup Checks Found That the Packet-Node Server Had No Working Backup Since the Rebuild; Radar Added to the Weather Page (Oct. 13, 2026)

Storage and backup checks (hourly, from the main server, with an off-box heartbeat): disk-controller, logical-drive and every physical-drive status; per-disk health counters for all twelve data disks and the two boot disks, alerting only when an error counter grows; both USB backup drives, including whether their mounts are actually present; free-space thresholds and the thin-provisioning pool; and backup recency for every job (nightly, weekly full, host-system and packet-node backups). Proven with a deliberate failure and a recovery message. The array and every disk are healthy today.

What it found: the weekly backup of the packet-node server had been failing since the Oct. 6 rebuild: the newer archive tool on the new operating system treats options placed after the path as a fatal error, so no archive was written and nobody was told. Fixed by reordering the command, running the remote tool at low priority so it cannot disturb the live node, and starting a verification run. The check would have flagged this within the first week; before this project it went unnoticed.

Radar: the weather-station page now shows the live GRLevel3 radar image in the center column below the last graph, larger than the sidebar widget it started as, with a cache-buster so a stale cached copy can never be shown. Also: the radar-image upload password was reset, the web server now asks proxies to cache that one file for only a minute, and the freshness check reads the origin so the CDN cache cannot hide a stall. Still open: outside synthetic checks (Phase 5) and power monitoring (Phase 6).

Silent-Failure Monitoring, Phase 3: Expiry and Credential Checks Added, and They Immediately Found Two Content Pipelines That Had Been Quietly Publishing Nothing (Oct. 13, 2026)

What was added: a daily check, run from the small off-box computer, reads every public certificate (as visitors see it and as the origin proxy serves it) and every registered domain’s expiry date, and alerts 21 days ahead for certificates and 60 days ahead for domains, more urgently when much closer. A second daily check makes one cheap, authenticated call for each stored automation credential (solar, video, AI, home automation, scanners, each blog’s publishing login) and alerts if any is rejected. Soonest certificate expiry is about five weeks away and soonest domain expiry about five months away, so nothing alerts today. Both checks have their own heartbeat, so if either stops running, that raises an alert too. Both were proven with a deliberate failure and a recovery message.

What it found: the content workflow for one site had been failing with an authorization error since its first run; the stored login had never matched a live one. A new application password was issued and saved, and verified against the site. Separately, three other sites’ content workflows were still posting to old addresses that now redirect to the new domains. A redirect turns a POST into a GET, so each run reported success while creating nothing; the newest drafts on those sites were from Sep. 14 even though the Oct. 12 runs showed green. The publish address in each of the three workflows now points at the live site and the active published version was verified. The checker now tests each login against the exact address its workflow uses and treats a redirect as a failure.

Also done: local system mail (disk-health warnings and similar) now goes to the phone instead of an undeliverable address, and the duplicate dead mail target was turned off. The backup drive’s logged error was examined: one interface (cable or dock) error and zero media errors, so the drive itself is healthy. The radio-image upload password was reset after the server swap. Still open: catch-up content run for the three sites, clearing the old undelivered mail, storage-health and backup-recency checks, outside checks, and power (Phases 4-6).

Silent-Failure Monitoring, Phase 2: Backup Failures Now Reach the Phone, Stale Data Is Detected, and Three Real Problems Were Found (Oct. 13, 2026)

Backup alerts: backup status mail was being sent to an address whose mail host rejects the server (blocklisted address), so success and failure notices had been piling up undelivered for days, including a disk-error warning from the backup drive that nobody saw. Both backup jobs now report through the server’s notification system; any error pages the phone through the off-box notification server. Verified with a real, harmless failing backup run. The old mail path is untouched and the queued messages were left alone.

Freshness checks (off-box evaluator, one-minute cycle): solar data file age, radar image age, a per-workflow “last real success” check for every scheduled automation workflow (its own record, because the automation tool prunes history), packet-node restart counting (alert at three or more in 24 hours), and the weather-to-Home-Assistant push. The weather script now times out, counts failed pushes, refuses to claim success when pushes fail or the source file is older than fifteen minutes, and only sends its heartbeat when everything worked; verified with a deliberate failure and a normal run. Each alert fires on change, repeats every twelve hours, and sends a recovery message.

Found by the new checks: (1) the radar image has not changed since Sep. 15, nearly four weeks, and no radar upload has reached the web server since; (2) the biweekly content workflow for one site failed on Oct. 11 with an authorization error and has never succeeded, which would not have been noticed for weeks; (3) the dead-man’s switch from Phase 1 gave two false alarms because the small computer’s notification database was locking under load; fixed by switching it to write-ahead logging, making the checker require two empty polls and tolerate failed polls, and adding sender retries. Still open: expiry checks, storage health, outside checks and power (Phases 3-6), plus the owner decisions on the items above.

Silent-Failure Monitoring, Phase 1: An Alert Path That Does Not Depend on the Server Being Watched, Plus a Dead-Man’s Switch for the Monitor Itself (Oct. 13, 2026)

Why: the failures that hurt here are the quiet ones (a job runs but its output goes stale, a credential expires, a script logs success on failure), and the alert path itself lived on the same server as the things it watched. Inventory: no log-search stack or enterprise monitor exists after all; the uptime monitor had 19 checks, nine of which alerted nobody; backup-failure mail has no relay and probably never leaves the host; seventeen automation workflows send their alerts through the mailbox sign-in that has already expired once.

Built: a notification server on a spare single-board computer that is not on the main server, with login required and an unguessable topic. Only top-priority alerts are re-posted to a public relay topic with generic text (no host names or addresses) so they reach the phone away from home; everything else stays on the home network. The uptime monitor now alerts through it on every check, alongside the old channel, which was kept. Dead-man’s switch: the monitor pings the small computer every minute only if it has really recorded fresh results; three minutes of silence raises a critical alert and a recovery message follows. A separate check watches the small computer through the old channel.

Verified by induced failure: a deliberately failing check produced Down and Up pushes on the phone; the heartbeat was switched off for four and a half minutes and produced the critical “monitor went quiet” alert plus its recovery. Login details are stored in the password vault. Still open: freshness checks, expiry checks, storage health, outside checks and power (Phases 2-6).

Solar Monitoring Login Still Fails After the Installer Updated the App; Installer and Vendor Support Contacted, and a Mail Watcher Now Alerts the Phone When Either Replies (Oct. 13, 2026)

State: the installer confirmed the redirect change was made and a screenshot showed both the website and home-automation addresses saved in the app. The owner retested the sign-in and it still reports that no site is linked to the account. A retest shortcut and a ready-to-send e-mail were prepared; the owner e-mailed the installer, and a support ticket sent the day before is still unanswered. Per vendor documentation the installer, not the owner, controls which sites an app can see.

Watcher: an automation workflow checks the owner’s mailbox every ten minutes for new mail from the installer or the vendor and sends a phone alert through the off-box notification server (home-network priority). Home automation was not touched. The old interface still stops working on Nov. 3; if sign-in is not working by then the integration will be removed, per the owner’s decision.

Overnight Network Alerts Traced: a Saved Network Setting Was Not Applied After the Reboot, and the Packet Node Program Exited Twice; Crash Capture Added (Oct. 13, 2026)

Alerts: the overnight “too few tunnel flows” messages came from a connection-tracking timeout. The saved setting (180 seconds) had not been applied after the early-morning reboot, so the live value was back at the old 120 and idle tunnel flows expired between packets. It was applied live and a module-load file was added so the setting should survive the next boot (not yet proven by a reboot).

Node exits: the packet node program itself quit and was restarted automatically twice (the evening before and shortly after midnight), before any of the day’s changes. The cause is not yet known. A post-mortem hook now saves a report whenever the service stops. A trial that ran the program under a system-call tracer was reverted within minutes because it used a noticeable share of the processor and could disturb timing just before the storm; the saved copy is kept for a later quiet day.

Also: the internal loopback port number was changed to keep the port list tidy after the modem renumbering.

Pre-Storm Backup Pass: Packet Node, Virtualization Host and Every Running Guest Backed Up One at a Time and Verified (Oct. 13, 2026)

Why: severe weather was forecast for the next day, so the owner asked for fresh backups first, run one at a time so nothing was stressed.

Done: (1) a full file-level archive of the packet-node computer was written to the external backup drive, test-read end to end and checked against its checksum list. (2) The virtualization host’s own system disk was archived and verified the same way. (3) Every running container and virtual machine is being backed up in turn with snapshots so nothing has to be stopped; at the time of writing 19 of 21 had finished with no failures and the backup dock had not reset once, with about half the drive still free. Stopped guests were skipped on purpose, since the Monday weekly job already covers them.

Note: the dock has reset under heavy load before, so nothing was plugged into the host while the backups ran.

The Packet Node Update Script Wiped the Web Pages and Program File When Its Downloads Failed; Node Restored in Minutes and the Script Rebuilt So It Cannot Do That Again (Oct. 13, 2026)

What happened: the owner ran the node’s update script while checking why an old digital mode was still being touched. The script renames or deletes the old files first and downloads second, and the download tool it relies on (wget) was no longer installed after the operating-system swap, so every download failed. It left the node without its program file (the service failed to start), the web-pages folder empty and the Winlink-forms folder empty.

Recovery: the program file was restored from the saved previous copy (the identical build the vendor still publishes) and the node was back with all modems reconnected within minutes. The two folders were refilled with fresh downloads, the helper programs for the unused mode were renamed back and refreshed (they are kept in the script on purpose so that mode can return), and the old folders were kept beside the new ones.

Fix: the script now uses curl, downloads to a temporary file first, swaps a file in only when the download succeeded, skips any folder it cannot enter, and restarts the node only when the program actually changed. The original is saved beside it.

Packet Announcements Written, Held, Corrected and Released: Dropped Mode, Local FM Service, Partner Request (Oct. 13, 2026)

What was done: four bulletins were drafted as held messages for owner review: a notice that the mode is no longer supported, an announcement that the FM digital mode is available to local users, a request for HF forwarding partners, and a correction notice. The region address on the draft partner request was wrong (it came from the public map page, which differed from what the node and the network actually use). One copy had already been offered to a single partner before it was caught; a corrected copy marked CORRECTED was issued, and the map and station-list data were fixed. The wrong-address drafts were killed before reaching anyone else.

State at the end: the dropped-mode notice and the local FM bulletin were released; a log check showed the FM bulletin had not yet been offered to any partner (partners are polled roughly hourly). The corrected partner request was still held at the time of writing.

Review-First Bulletin Pipeline: The Monthly Newsletter and a New Weekly Forwarding Summary Now Post to the Node as Held Messages, and the Weather-Bulletin Poster Was Repaired (Oct. 13, 2026)

What was built: a dedicated poster login that uses the club call sign. The node is set to hold anything from that login, so the owner reads each message and releases it (or deletes it) by hand. The monthly newsletter workflow gained a last step that posts the formatted text this way; a failure there cannot block the review e-mail or the saved copy. A weekly timer runs a script that counts, for each enabled forwarding partner, connects and messages in and out for the last seven days and posts the table held. Both end with an “AI Assisted” line.

Found while testing: the older poster used by the weather-alert workflows was broken (the telnet client had been removed from the node and the login prompt had changed). It was rewritten to talk to the node directly, keeping the same command and file name so the workflows needed no change; the login and prompt handling was verified but a real weather post has not yet been seen. Test messages were killed before they could forward, and the node’s message index file proved to lag real state, so only the sysop view was trusted for held/released status.

Packet Node: Modem Laptop Recovered, an Unused Digital Mode Removed, and the Remaining Modem Ports Renumbered (Oct. 13, 2026)

What happened: on the sound-modem laptop one of the HF modems was repeatedly dropping and reconnecting while the other would not start at all. The laptop needed a hard power-off. After it came back and the node was restarted, all three modems (two HF, one FM) connected and stayed stable; the node ran with zero resets for hours afterward.

Change made: the owner decided to drop one digital mode (ARDOP). Its two ports were removed from the node configuration and from the Winlink gateway listings, and the three remaining modem ports were renumbered. Every forwarding script that referred to the old numbers was updated (the one partner that used the dropped mode as a fallback lost only that fallback). The public map and directory pages were corrected, and the automation server, home automation and status pages were checked for old port numbers (none found). Every file was backed up first.

Findings worth keeping: the dropped mode’s windows had never been started by the node, which only auto-starts the VARA programs. A loose USB cable at the FM radio’s sound interface caused receive-only silence (transmit still worked) and came back once later; a spare cable cured it both times. The gateway listing for the FM port also advertised the wrong frequency and was corrected.

Packet Node Hung After a Buffer Exhaustion and Was Restarted Safely; Cause Documented and a Report Written for the Software Author (Oct. 12, 2026)

What happened: an automatic monitor alert reported that the packet-radio node and its web page were down. The node’s program was still running but had stopped answering on every service (telnet, mail, FTP and the web port). The cause was inside the node software itself: while handling a forward from a neighboring station, its packet buffer pool filled up completely within about a minute, the program logged a fatal error, tried to exit, and then hung in its own shutdown while writing a flood of memory dumps.

What was done: before touching anything, the configuration, the mail data and the crash evidence were backed up. The service was then stopped (it needed the system’s forced stop after 90 seconds) and started again. A checksum comparison showed no configuration file had changed. Afterward every service answered, the web page and the public site returned normally, the monitor recovered within a minute, and the interrupted forward resumed. The outage lasted about 19 minutes. A related automatic health alert about the radio links (Task 472) fired during the outage because the links had dropped; after the restart they returned to the normal range.

Findings worth keeping: all 999 buffers were in use at the moment of failure, almost all filled with copies of the node’s welcome text, which looks like a runaway loop rather than a slow leak. Separately, one radio-modem port was found to hold on to about 200 buffers until it was reset. A detailed report with the evidence was written for the node software’s author. WebMail was suspected but is unproven, so it was left enabled on purpose, to see whether the problem recurs; the plan is to block it again and send the evidence if it does.

Quantum Computing Learning Kit: a User Manual and an Eight-Lesson Study Guide With Self-Checking Exercises (Oct. 11, 2026)

What was done: two printable PDFs were written for the new quantum workstation: a four-page user manual (logging in, using notebooks, running on real hardware, caring for the machine, troubleshooting, glossary) and a thirteen-page study guide with eight lessons, an answer key and a glossary.

Live work: each lesson also exists as a notebook with exercises where the learner replaces a marked line and runs the cell; it answers with a green check or a red cross and a hint. Finished versions sit in a separate folder. Tested: with the answers filled in every check passed, and the blank versions ran without errors and showed the red cross until the work was done.

Quantum Computing Workstation Built: Local Simulator Plus a Real IBM Quantum Computer Run (94.5% Correct) (Oct. 11, 2026)

What was done: a new virtual machine was created on the virtualization host with the Qiskit toolkit, a local quantum simulator and a JupyterLab notebook server that is reachable only from the home network (login-protected, starts by itself at boot). A dedicated SSH key was made for it, and it is covered by the weekly full backup.

Checks: a two-qubit entangled (Bell) circuit on the simulator, 1,000 runs, split 522 / 478 between the two expected results with nothing else. Six demo notebooks (superposition, entanglement, measurement, Grover search, random numbers, teleportation) all run clean.

Real hardware: a free IBM Quantum account was set up (the free plan asks for a card on file but does not charge; the account needed a short activation wait). The same circuit was sent to a 156-qubit IBM machine, 200 runs: 94.5% gave the correct answers and the rest was hardware noise, against 100% on the simulator. The free plan allows about 10 minutes of hardware time per 28 days, and this used a few seconds. The API key lives only in a private file on the machine.

Plex Library Naming Cleanup: About 2,800 Movie and TV Files Renamed Safely, Wrong Matches Fixed, Unmatched Episodes Roughly Halved (Oct. 10-11, 2026)

What was done: the main media-server library was audited (24,000 files) and a rename plan built so Plex could recognize titles it had failed to match. Applied in batches after the owner approved each one: 956 high-confidence movies, 173 reviewed medium-confidence movies, then TV in four rounds (1,000 + 87 + 437 + 127 episodes) plus 41 behind-the-scenes clips moved into an Extras folder. Nothing was ever deleted.

Safety: each batch ran only when nothing was recording or streaming, did a check-only pass first (it refuses to run if a single file has a problem), backed up the Plex database, kept a rollback list on the desktop, then restarted Plex and rescanned. Every batch finished with zero failures. A locked-down remote login to that PC was used for the work and removed by the owner at the end; the Plex token file was deleted.

Root causes found: series whose files use series-wide or production-code numbers instead of season numbers (Three's Company, Hogan's Heroes, Farscape and others) were matched to episodes by title instead of number; one folder mixed two different Outer Limits series and was split in two; CHiPs and Battlestar Galactica were matched to the wrong show and re-matched; seven movies were identified by comparing running times.

Result: unmatched TV episodes dropped from about 1,420 to about 730, and movie unmatches from 206 to under 60. The two duplicate-looking Flintstones/Jetsons folders were kept at the owner's decision. About 13 leftover titles are for the owner to research, and many turned out not to be in the library or to be TV episodes or an album.

Whole-Site Scan for Old Content: Every Page Checked, Stale Facts Fixed, Workstation Roles Corrected (Oct. 9, 2026)

What was done: all 35 pages on the site were scanned for outdated content (old versions, finished events still described as upcoming, retired gear, and private machine numbers). Fixed: the home page's network-map label, the usage page's leaked machine numbers, the dossier's retirement line (now retired), the homelab page's workstation details (the main PC runs Windows 11; the second desktop also runs a media server and the GPU-pool worker; a radio/radar laptop was added) and an outdated solar-feed note.

Private copies: the detailed network-map device cards were refreshed (AI and automation machines are VMs, media server is a container, storage use, new devices) and the monitor count was set to the live number. Left alone on purpose: pages driven by live data (all feeds checked fresh), the themed retirement countdown, and a few items only the owner can confirm.

Homelab and Network Map Pages Refreshed With Today's Changes, Public and Private Versions (Oct. 9, 2026)

What was done: both pages were brought up to date and kept in the same safe split as before: public versions with no real addresses or machine numbers, and gated detailed copies behind the admin login. New on both: the website-hosting container, the self-hosted git server, the push-alert service, the paper trading bot, the build-check runner, the AI memory machine and the coding assistant, with corrected memory sizes (the AI machine and Home Assistant were far out of date). New devices: the Eufy camera, the two TV tuners, the Roku streamers, the smart washer and dryer, the thermostat gateway, the Bluetooth proxies and the printer.

Corrections: the processor generation was wrong, three machine types were mislabeled, the retirement banner now says retired, and a note about the solar company's old interface ending Nov. 3 was added. The network map is now version 2.6. The private copies also list the router and both switches on their newest release, and the old firewall-rule problem is marked fixed. Before and after: the old files are backed up on the web server.

Free Tablet 4G Data Researched: a Rugged Laptop Already Has a Working Modem and Its Eligibility Check Passed (Oct. 9, 2026)

What was done: the phone carrier offers free 4G data for tablets for as long as the phones stay active (the owner confirmed it by phone). Research covered what to ask the carrier, what a modem card for the older rugged tablet must support (LTE with the carrier's main band, not a 3G-only card, the right slot size, antennas present) and what to avoid. One rugged laptop already contains a working cellular modem and its ID was accepted by the carrier's bring-your-own-device check, so it needs no purchase.

Next: get a physical SIM and the network settings, then test. Notes, the test steps and a source list were saved.

Solar Data API Change Researched: the Old Key Stops Working Nov. 3, Plan Written, Redirect Mistake Caught (Oct. 9, 2026)

What was done: the installer sent a new-style login (a client ID and secret) for SolarEdge's new developer platform. Research found that SolarEdge's old single-key interface stops working on Nov. 3, 2026, that Home Assistant's built-in solar integration does not support the new login yet, and that a community add-on does. Everything that depends on the old interface was mapped: the energy dashboard, three dashboards and three automations. The free plan allows about 2,000 calls a month, so only one thing may poll.

Caught a mistake: the redirect address given to the installer would not work with Home Assistant. A thank-you email asking him to add the right one was drafted for the owner to send. Nothing was changed yet; the move itself is listed under Pending.

Email Assistant's Hourly Failures Found and Fixed (Oct. 9, 2026)

What was done: the Gmail assistant failed once an hour and sent an alert each time. The Gmail login was fine. Root cause: another automation (crypto sentiment) starts at the top of every hour and keeps the single AI machine busy for about a minute and forty seconds; the email classifier queued behind it and gave up at its 60-second limit. Fix: the classifier's wait was raised to four minutes. The first check showed the email run now succeeded, but it moved the hourly timeout onto the crypto job (its own two-minute limit was always close, and the two jobs now share the AI machine), so the crypto job's wait was raised to four minutes too. The next top-of-hour run is the real test and is listed under Watch.

Virtualization Host Upgraded to the Next Major Version, With Backups, Remote-Console Test and a Restore Test First (Oct. 9, 2026)

What was done: the main server's operating system was upgraded to the next major release, because the old release lost vendor support on Aug. 31. Before starting: the vendor's checker showed no failures, the owner tested the remote management console, one real backup was restored to prove backups work, and two full backup sets were taken on a separate drive and tested. The upgrade ran as a background service so it could not be interrupted, with the old system kernels kept as a fallback.

Result: after the restart every container and virtual machine came back by itself, both graphics cards still reach the AI machine (the biggest risk), and the websites, DNS, shared drive, home automation, media, monitoring and RAID health all answered. Two follow-ups: a subscription-only software source was switched off because it broke update checks, and the assistant's container got the same nesting option the other containers already had. A full backup of the whole server was then re-run and every archive tested.

Free Ubuntu Pro Added to Five Ubuntu Systems and Their Updates Installed, Graphics Software Left Untouched (Oct. 9, 2026)

What was done: the free personal Ubuntu Pro plan, which covers five machines, was attached to the five Ubuntu systems that matter most: the web front door, the media server, the AI/graphics machine, the automation server and the assistant's own container. Each gains extra security patches, and the two full virtual machines also get live kernel patching. The pending updates were then installed on all five, one at a time, with a check after each.

Careful part: on the AI machine only twelve non-graphics packages were updated. The graphics-card software stays frozen on purpose (the owner's rule), so the cards keep working. Three other Ubuntu systems are left out until slots free up. Notes and a how-to for removing old devices from the plan were saved.

Lottery Pages Password-Protected (Oct. 9, 2026)

What was done: on a friend's advice, the lottery tracker, the original number-selection page and the helper behind them now ask for a password, the same login as the private admin area. Checked from the outside: every lottery address answers "login required", the public pages still load, and script and backup files stay blocked. The nightly results update and the helper service were not affected. A separate login for family can be added if wanted. The owner confirmed his login works.

Shared Media Drive Locked Down With a Login and the File-Sharing Name Service Fixed, Both Windows PCs Reconnected (Oct. 9, 2026)

What was done: the main server shared its 37 TB media drive with anyone on the home network, with no password and with write access. A dedicated share-only login was created, guest access was switched off, and a double-click reconnect script was written for the Windows PCs. Checked from the outside: anonymous and wrong-password attempts are refused and the right login can list and write. The media, file-sync and shared-drive containers read the drive directly, so they were not affected.

Also fixed: the server's name-announcement service had failed at every boot because its settings listed a network port that is not in use. One line was corrected, which also removes a 90-second boot delay. Both Windows PCs reconnected; the tablets are next.

Home Assistant Rolled Back to Yesterday's Backup, Assistant Link and Access Tokens Rebuilt, Phone Addresses Trusted (Oct. 9, 2026)

What was done: after trouble with the solar integration, the owner restored Home Assistant to the previous day's backup. The restore wiped the AI-assistant control link and its safety limits, so both were rebuilt: the link was switched back on, the 74 network-gear switches were hidden again from the assistant, and only the washer, dryer and thermostat emergency-heat switches stay exposed. The access token was replaced twice at the owner's request, the old ones were deleted and confirmed dead, and the new one was saved in the password manager.

Also: the solar integration needed no repair (it kept reporting after the rollback). Two new network addresses for one phone were added to the trusted-device list so it stops triggering critical unknown-device alerts; the phone was then locked to its real address.

Smart-Device Security Sweep: Every Network Device Checked for the Realtek Chip Flaw, Stale Internet Forward Disabled, Remaining Fixes Parked (Oct. 8, 2026)

What was done: a read-only sweep of every device on the home network, prompted by a warning about a flaw in Realtek chips used in cheap cameras, repeaters and smart-home gear. Each device was identified by its hardware address and a light scan of its open services. No device carries a Realtek address, and the three wireless access points use other chip families (two Atheros, one Broadcom), so the flaw does not apply to them. None of the smart devices or access points is reachable from the internet.

Fixed: an old internet-facing forward on the router that pointed at the main server, where nothing was listening, was switched off (not deleted, so it can be turned back on). Found: remote-login (telnet) is open on one access point and on the printer, the printer also has file transfer open, a Wi-Fi repeater runs an old web server, and two unidentified energy-type gateways speak an unauthenticated industrial protocol on the home network only.

Parked: the telnet changes and a repeater firmware update wait on an admin password the owner is looking for. Firmware on the two Buffalo access points is deliberately left alone because one of them breaks on newer builds. A full report with the device list was saved.

Switch Hardening: Unused Management Services Turned Off and Remaining Ones Limited to the Home Network on Both Switches, Verified Against Home Assistant (Oct. 8, 2026)

What was done: a read-only check of the router and both network switches, then a hardening change on the two switches. File transfer, telnet and the encrypted API service were turned off, and remote login, the Winbox management tool and the API were limited to the home network only. The web interface was left on deliberately so the Home Assistant integration and the status page keep working. No firmware was changed. The router was not changed.

Verified: the settings were read back on both switches, Home Assistant kept recording fresh readings from all three network devices, and a brand-new connection from Home Assistant to each switch succeeded, so it will reconnect cleanly after a restart. The outbound block on the suspicious server address was confirmed in place on the router with no hits and no open connections. A duplicate-looking management entry on one switch turned out to be a live session from the owner’s phone over the home VPN, not a configuration problem.

Safeguards: the home-network range was checked first (a commonly pasted example range would have locked the owner out), no firmware update was run, and the undo is a single command per switch. The audit report was updated with the change.

Credential Cleanup: Nine Login and Key Files Secured and Deleted, Backup Coverage Widened, Admin File Permissions Fixed and the Publishing Token Rotated (Oct. 8, 2026)

What was done: a credential cleanup. Nine files holding logins, private SSH keys and a router settings backup were gathered into one folder, the owner saved them in the password manager, and the folder was then securely deleted (contents overwritten before removal). Four older access-point settings backups were deleted at the owner’s request; two short rollback notes were kept.

Other fixes: the admin password file is now readable only by the administrator and the web server; the nightly backup now also covers the automation server, the memory server and the trading bot (a test backup of the latter two succeeded); and the push token used to publish the trackers was rotated. The old tokens were verified to be rejected and the new one verified to work. Rotating it also exposed two things that had been failing silently because they used a stale token: the admin push page and the health-alert workflow’s automatic tracker update. Both work again.

Safeguards: backups of every changed file and workflow were taken first, and the new token is stored in a locked file rather than in notes or page source.

Read-Only Health Check of the Trading Dashboard Login, AI Memory, Backups, Trading Bot and Packet Services: All Healthy, Three Gaps Found and Fixed (Oct. 8, 2026)

What was done: a read-only health check of the main systems, with nothing changed. Everything checked was healthy: the private trading status page and its data file refuse access without a login (a wrong password, a URL trick and the temporary data file were all refused, and the password files are hidden); the local AI memory has every passage indexed and its nightly backup ran; the nightly and weekly Proxmox backups ran, including the USB dock; the trading bot is running with its kill switch off; and the packet services are up (the radio node and mail ports are listening, the URONode and both Raspberry Pis answer, and the fragile AXIP route is present and active, with no crashes in 24 hours).

Gaps found: the automation server, the memory server and the trading bot were not in the nightly backup; the admin password file was readable by every account on the web server; and an old push token was written in plain text inside admin files. A search for leftover credential files also found nine that were still in the shared upload folder. These were handled in the cleanup task.

Also: my own backup-disk write test expanded to two folders by mistake; it changed only a timestamp and deleted nothing (verified).

Home Network: Stamps.com Slowness and a Trading-Bot Connection Block Both Traced to the DNS Filter and Fixed With Narrow Allow Rules; Footer Placeholder Corrected (Oct. 8, 2026)

Stamps.com printing: envelope printing that normally takes seconds was taking minutes on the owner’s desktop. The network itself was healthy (about 337 Mbit/s, no packet loss, router lightly loaded). The home DNS filter was blocking three helper services the Stamps.com pages depend on (a device-identity check and two page scripts), so pages waited for them to time out. They were allowed for that one computer only; every other device keeps full protection. The owner confirmed Stamps.com works normally again.

Trading bot connection: a later DNS-filter restart loaded a blocklist rule that blocks the whole .markets domain ending, which cut the paper-trading bot off from its broker and sent a failed-pass alert. One scoped allow rule for the broker restored it within minutes, and the bot’s next pass ran normally. No trades were missed. Lesson recorded: after any filter restart, re-check that the broker and the lottery data hosts still resolve.

Also: the footer on this page still held a leftover placeholder (‘retirement T-minus about 3 weeks’). Its script already replaced it with the correct count of days since retirement; the placeholder under it now reads correctly too.

Lottery Tracker Expanded to Nine Games: Hoosier Lotto, +PLUS, CA$H 5, Millionaire for Life, Daily 3, Daily 4 and Quick Draw, With Digit-Game Support and an Updated AI Helper (Oct. 8, 2026)

What was done: the lottery tracker page now covers nine games instead of two. Added from the Hoosier Lottery (Indiana): Hoosier Lotto and its +PLUS draw, CA$H 5, Millionaire for Life, Daily 3, Daily 4 and Quick Draw. Powerball and Mega Millions are unchanged. Each game has its latest draw, how often each number or digit came up, past draws, a play generator (except Quick Draw, which has nothing to play) and saved plays checked against later draws.

Two new kinds of game were needed: games with no bonus ball (Hoosier Lotto, CA$H 5), and digit games (Daily 3 and Daily 4), where the order of digits matters, digits repeat, and there are two draws a day. Saved Daily plays are checked as a straight match (exact order) or a box match (right digits in any order). The AI helper understands all of these games, and its answers were checked against independent counts.

Data: the Hoosier results come from the lottery’s own past-results page, which keeps only about 17 months, so the first load has history back to April 2025 and the page’s own record grows every morning (it never deletes old draws). Not added: Cash POP and Powerball Xs & Os.

Trading Bot Status Page Added to the Protected Admin Area With Separate Logins for Three People (Oct. 8, 2026)

What was done: a status page for the paper-trading bot was added to the protected admin area of the home website. It shows the account value, today’s change, each position with its profit or loss, the watch list (holdings highlighted), the spending limits, recent orders, the bot’s latest log lines, and a value chart that fills in as the bot runs. Red banners appear if the broker rejects the bot’s keys, the stop switch is on, the bot is down, or the data goes stale. It follows the site’s style and works on a phone.

Access: the page lives in its own folder with its own list of logins, so each person can be given access to this page alone. Three logins were created: the owner, a family member, and a fellow radio amateur. Tests confirmed that a trading login does not open any other admin page, that a wrong password and a missing login are both refused, and that the password files are not downloadable. A link was added to the admin Command Center. Sensitive internal commands were left off the page because non-household users can see it.

How it works: a job on the Claude Code machine refreshes a data file every 5 minutes (no passwords or keys are in it) and the page reads that file. The same status can be seen from the command line with a one-word command. The broker’s own value history was empty for the new account, so the job keeps its own record of the account value.

Trading Bot Crypto Cap Raised to $1,000 and Dogecoin and Shiba Inu Added to the Positions, Paper Mode (Oct. 8, 2026)

What was asked: the owner wanted Dogecoin and Shiba Inu in the trading bot, among the other coins from the list that had been added to its watch list. They were on the list but could not buy, because the crypto spending cap ($500 total) was already used up by Bitcoin and Ether.

What was changed: the total crypto cap was raised from $500 to $1,000 (still $250 per coin), and Dogecoin and Shiba Inu were moved to the front of the watch list right after Bitcoin and Ether. All seven extra coins were in an uptrend, so the bot immediately bought $250 of each of Dogecoin and Shiba Inu. It now holds four coins worth about $979 in simulated money; the other five on the list (XRP, SOL, ADA, PEPE, BONK) still wait because no room is left.

Still true: the bot is in paper (simulated-money) mode only, the stop-file kill switch and the daily loss limit still apply, and phone alerts report every trade. Each buy loses roughly 2% to fees and the buy/sell price gap, and meme coins can swing sharply, so these are experiments. The previous settings were backed up before the change.

Trading Bot Installed in Paper-Money Mode With Bitcoin and Ether Support, Backtest Results and Phone Alerts; Memory Alert Channel Fixed (Oct. 8, 2026)

What was done: a small automated stock-and-crypto trading bot was installed on its own new small server on the home hypervisor. It runs in simulated-money (paper) mode only: real-money trading needs two separate deliberate settings changes and was not enabled. It follows a simple trend rule (hold while the 20-day average price is above the 50-day average, otherwise stay in cash), with hard limits checked before every order: a maximum per position, a maximum total, a daily-loss limit that halts the bot, and a stop-file kill switch.

Crypto support was added and tested: Bitcoin and Ether trade around the clock using only completed daily prices, with smaller crypto limits ($250 per coin, $500 total). A backtest over 12 years of Bitcoin and 9 years of Ether history gave a mixed result: after fees the rule did not beat simply holding Bitcoin, but it did beat holding Ether (mostly by avoiding the 2018 crash) while still suffering large drops. The first real paper trades showed a much higher cost per trade than assumed (about 2% in and out), which weakens the case for Bitcoin; the bot is being kept as a small experiment. Seven more coins (XRP, SOL, ADA, DOGE, SHIB, PEPE, BONK) are on the watch list but cannot buy until the cap is raised; about 27 of the owner’s other coins are not tradable through this broker.

Phone alerts: the bot now sends a message to the owner’s phone for every trade, error and halt (urgent for halts) through the self-hosted notification service, and both alert channels were confirmed received. While setting this up, a related fault was found and fixed: the notification server was silently refusing messages from the AI-memory system, so its alerts had never been delivered.

Verified: 23 automated tests pass (9 original, 14 new), the broker accepted the keys, orders and positions matched, and a second pass correctly did not buy twice. The previous code and settings were backed up before each change.

Lottery Tracker Page Live With a Local AI Helper and Per-Visitor Limits; Trading Bot Still Waiting on Paper Keys (Oct. 8, 2026)

What was done: the lottery tracker page (history of Powerball and Mega Millions draws, number statistics, a play generator and saved plays checked against later draws) was put on the home website in the site’s own style, with a link from the home page. The existing “Number Selection Matrix” lottery page was left exactly as it was. Draw history (about 2,000 Powerball and 2,500 Mega Millions draws) updates itself every morning from New York’s public open-data service.

AI helper: an “Ask the helper” box explains the statistics in plain words, checks saved plays, and answers questions such as how often a number came up this year. The page’s own code does every calculation and a local AI model only writes the wording, so it cannot invent counts; in tests its answers matched an independent count. It never predicts: questions asking for predictions or lucky numbers get a fixed honest answer without using the model, off-topic requests are refused, and a trick instruction inside a question was ignored. Limits: 10 questions an hour and 30 a day per visitor, 300 a day in total, one at a time, and short answers. If the helper is down the rest of the page works normally, and one file switches it off.

Two network changes were needed: the home DNS filter was blocking the draw-data source, so that one name was allowed (the allow list went from 231 to 232 rules, nothing else changed); and the web front door was not passing each visitor’s address to the site, so one setting was added so the per-visitor limit works. Backups were taken before both, the front door’s own configuration check passed, and other sites were confirmed still up.

Still open: the stock trading bot that came with this package is not installed. It needs the owner’s free paper-trading account keys and a choice of machine to run on; it will start in simulated-money mode only. The per-visitor limit could not be tested from a real outside address and will be confirmed from the first real visitors.

Task Tracker Pages Fixed on Desktop: Two Misplaced Cards Moved and the Page Grid Repaired, Phone View Unchanged (Oct. 7, 2026)

What was wrong: on a desktop screen the task list was squeezed into a narrow column. Rendering the pages showed the cause was structural rather than missing styling: two task cards (251 and 252) sat directly inside the page grid instead of in the Done list, and on the public page the “summary view” notice also sat in the grid, taking the second column and pushing the whole list into the narrow side rail. (The stats row was already five across and the navigation already wrapped.)

What was changed: the two cards were moved into the Done list in their proper place (all 430 cards are still present, once each), and a block of styling was added for tablets and desktops only: the side rail sits in the left column, the notice and the list stack in the right column, navigation becomes an even grid (two columns on tablets, six across by two rows on desktops), stats are three across on tablets and five across on desktops, and the cards flow three across on a 1440-pixel screen using the full width.

Verified: pages were rendered in a headless browser at phone, two tablet, desktop and wide-screen sizes. On a phone the styling change alone produced zero differing pixels on both pages; the only phone difference is that the two moved cards no longer sit above the colored rail at the top. The live addresses were rendered after publishing and match. The originals and before/after screenshots are saved so the change can be rolled back.

Claude Code Working Sessions Added to the AI Memory, and the Credential Cleaner Strengthened (Oct. 7, 2026)

What was done: 26 of the 27 saved working sessions with the AI coding assistant (September 11 to October 7, about 214 MB) were added to the private AI memory (TASK 435), bringing it to about 60,700 searchable passages. The 27th is the session being written at the time, so it was left out on purpose and can be added later. The originals were copied read-only with checksums first.

What is kept: everything that was said, the 435 messages typed while the assistant was busy working, and every command that was run with its output (trimmed to the start and end). The assistant’s hidden reasoning, repeated system boilerplate and duplicate messages across sessions are dropped.

Safety: command history is the most credential-heavy data in the whole archive, so these sessions get a stricter cleaning mode (passwords on command lines, login options, secrets in environment variables). While checking, a gap was found that affected all the data: credentials written in JSON form (a quoted “password” label with a quoted value) slipped past the old rules. The cleaner was fixed and the whole archive re-scanned; only 21 of 60,739 passages needed changing, and the leak check reports zero. A short common word was removed from the protected-secrets list because in older notes it is also a user account name, and the password it matched no longer works.

Result: questions such as “which exact commands did we run” now bring up the stored commands and their output, with message numbers for citations. The full set of tests (62) passes.

How-To Guide for Friends: How the Private Local AI Memory Was Built, With a Cleaned Copy of the Code (Oct. 7, 2026)

What it is: a plain-language, shareable guide that explains how the private AI memory (TASK 435) was built, written so friends in the hobby can build their own. It is a 13-page PDF (with an editable Word copy and a plain-text copy) of about 4,800 words: what the system is and why, what hardware and software are needed, the eight design rules, 16 build steps from the empty machine to a password-protected search page, the 12 tests that proved it worked, and the mistakes made along the way so others can skip them.

Also included: a “weekend version” that needs only a notes folder, a text search file and a local model, a short method for recovering a damaged download, and advice on building the whole thing with an AI coding assistant by writing the plan and acceptance tests first.

Safe to share: the guide ships with a cleaned copy of the working code. Every personal name, address, hostname, project name, password and token was removed, the code was re-tested after cleaning (all 43 tests pass), and a final scan of the guide and the code found nothing personal. The file properties were checked too (no author or computer name). The package has a one-page note on what to hand over and what never to share: the original chat exports, the archive, the backups, the list of known secrets and the web login.

Local AI Memory Built: Claude and ChatGPT History, Task Tracker and Notes Searchable by the Local AI, With Cited Answers (Oct. 7, 2026)

What it is: a private, searchable memory of the owner’s whole working history, so the local AI can answer questions about past work with sources instead of guessing. It holds 1,604 Claude conversations and 115 ChatGPT conversations (March to October 2026), all 426 task-tracker entries, the assistant’s working notes, and 118 project reports and decisions: about 2,450 documents, cut into roughly 34,500 searchable passages.

How it works: a new virtual machine on the home server holds the originals (locked read-only and checksummed), a search database, and a small web page reachable only from the home network behind a password. A question first finds the best passages by meaning and by exact identifiers (task numbers, addresses, callsigns), prefers newer, higher-authority sources for “now” questions and uses only the right time window for “back in July” questions, then hands those passages to the existing local AI model. Every answer cites its sources, and when the archive has no answer it says “Insufficient evidence.” A short, verified current-state file outranks everything else.

Safety: credentials are stripped before anything is stored or searched (pattern detection plus a protected list of known secrets); the old chats do contain real keys and tokens, so the locked originals must stay private. Imported text is treated as evidence, never as instructions. Archives are unpacked with traversal, symlink and size checks, and a damaged export is recovered and flagged rather than silently accepted.

Verified: 43 automated tests; a full re-import creates no duplicates; originals unchanged; a restore from backup gives identical results and a rebuild from the originals reproduces identical content; every service returns by itself after a reboot; a planted “attack” document was not obeyed and a planted password was never revealed. Five bugs found during the build (including a secret that briefly slipped into the index) were fixed before finishing. Details and what is still pending are in the status report saved with the other build notes.

17-Book Collection Uploaded to Draft2Digital at $89.99 — Not Offered on Apple Books or Everand (Oct. 7, 2026)

What was done (Oct. 7, owner): the 17-book collection (TASK 433) was uploaded by hand to Draft2Digital at $89.99, with the collection box set to Yes and no series number, as planned. The price was chosen low on purpose to encourage sales, matching the owner’s own bookstore and Gumroad.

Where it will not appear: Apple Books would not accept a price above $39.99, so the collection is not offered there, and Everand (formerly Scribd) did not take it either. Both stores still carry the 17 books individually, so readers there are not left out; the owner judged both exceptions acceptable.

Housekeeping: a listing added by mistake during the upload was delisted and deleted from the dashboard. The collection kit (manuscript, cover, paste sheet, descriptions, search terms) stays on file in case a store needs it re-entered.

Combined 17-Book Ebook Collection Built for Draft2Digital: One EPUB, Validated, Upload Kit Ready (Oct. 7, 2026)

What was done: the 17 Second Edition ebooks (the 16 titles plus the Termux guide) were merged into one EPUB so the collection can be sold as a single title on Draft2Digital, which has no bundle builder of its own: a collection goes up as its own book flagged “Is this a collection?” The 17 manuscripts used are byte-for-byte the ones already uploaded to D2D.

What is in it: a new collection cover (a grid of all 17 current covers), a title page, a copyright page, an “About This Collection” page, and a master table of contents listing Books 1–17, each expandable to its own chapters (about 1,100 entries). Every book keeps its own cover, title page and chapters. The ebook-industry validator reports zero errors and zero warnings.

Price and caveat: the collection price is $89.99 on every store, the same as Gumroad and the owner’s own bookstore, against $135.83 for the 17 books separately (a 34% saving). Amazon generally pays its higher royalty rate only for ebooks priced roughly $2.99–$9.99, so the per-sale cut there will be smaller. A ready-to-use upload kit matches the layout of the single-book kits and holds five files: the manuscript, the cover, a paste sheet of every form value, the two descriptions, and a short sheet of the seven search terms and three subject categories; the one real difference is the “collection” box set to Yes and no series number (see TASK 434).

Automation Server 3.0: Not Released Yet — Readiness Scan of All Workflows Done (Oct. 7, 2026)

Question: is automation-server version 3.0 out yet, and are the owner’s workflows ready for it?

Release status (Oct. 7): not released. The vendor plans it for October 2026 with no exact day; the newest stable is 2.42.4 (the server runs 2.41.6, two small patches behind) and the newest test build is still in the 2.x line. The plan is unchanged: wait for the first patch release, back up first, and test on a copy.

What the scan of all 46 workflows found (read-only): none of the nodes 3.0 removes that were checked (the legacy Function nodes, old Cron and Interval triggers, HTML Extract, Read PDF, Compression) are used; there are no Execute Command nodes; and the server already runs in Docker, which 3.0 requires.

Things to check before upgrading: (1) 3.0 turns on stronger protection against web requests to private addresses, and 41 of the 80 web-request steps in 22 workflows call devices on the home network or the server itself, so the exact setting and its allow-list must be read and tested first. (2) The Code-step time limit drops from five minutes to one; two workflows ran longer than a minute in the last 30 days (the monthly newsletter at about 3 minutes and the solar-data refresh at about a minute, twice in 511 runs), though a single Code step is normally much shorter. (3) One third-party search node is used, and unverified community nodes will be off by default. (4) No binary-data mode is set today and the in-memory mode is removed. Not checked: a few AI nodes 3.0 removes are not named in the docs.

Packet-Node Pis: Decision Made — No Inbound IPv6 Doors, Operating System Left As Is (Oct. 7, 2026)

Question: should any inbound IPv6 doors be opened to the two small packet-node Raspberry Pis, and should they be rebuilt on a newer operating system?

Decision (Oct. 7, owner): open nothing for now, and leave the operating system as it is. The router keeps dropping all new inbound IPv6 to both Pis (only the BBS box has doors: mail, node login and ping), and their DNS records stay as they are. Nobody needs these Pis over IPv6 today; the radio and IPv4 paths all work.

Why it is safe enough: the Pis run an older, unsupported system, so the protections that matter are in place: SSH accepts keys only, fail2ban watches SSH, the connection rate limiter skips trusted sources, the old firewall package is retired, and no IPv6 door is open.

If it comes back up: ping-only is the low-risk first step; a node-login door on one Pi should wait until that Pi has its own IPv6 firewall and a connection-flood ban rule. SSH and the BBS admin port stay closed either way. Decision file saved with the other upgrade notes.

Packet-Network Health Alerts Repeating: Cause Found in the Connection-Tracking Timer, Fixed (Oct. 7, 2026)

What happened: the packet-network health check sent an alert and a phone push several times a morning (03:40, 05:40, 08:10, 08:55, 09:25 and 09:55 UTC on Oct. 7), each lasting exactly one five-minute check and then recovering on its own. Each said only three or four confirmed two-way links were seen, against a minimum of five. A write-up from an outside assistant guessed at a repeating 40-minute crash cycle; checking the real system showed neither: the service had been up for almost a day without a restart, and the alerts are not on a 40-minute pattern.

Cause: the check counts two-way packet links that have been active recently. The new operating system on the BBS box forgets an idle connection after 120 seconds, where the old one waited 180 seconds, which is the window the check was tuned for. With the shorter memory the count was lower and jumpier (about 10–13 instead of 13–16) and it briefly dipped below the minimum during quiet stretches.

Fix: the memory time was set back to 180 seconds, applied live and saved so it survives a reboot. It is a one-line setting and easy to undo. Nothing else on the box was touched, and the packet service stayed up. If alerts still appear, the next suspects are a real partner dropping off or a minimum that is simply too tight (see TASK 430).

Two Packet-Node Raspberry Pis Brought Up to Standard: Access, Firewall Tool, IPv6, Key-Only Login, and a Gateway Through the VM (Oct. 6, 2026)

Access: one Pi had a loose power connector and was off; both were rebooted. They accept SSH keys only, so the owner’s own keys (and one for this assistant) were installed, and an unknown key from 2022 that nobody held was removed. Login by password is off again.

Firewall tool: an old firewall package was installed on both but had been failing at every boot; it was retired (archived, not run, since its off-switch would have wiped the real firewall rules) and fail2ban installed in its place and tested.

Compared with the VM: the Pis are small air-link digipeater, node and BBS machines, never copies of the VM. They were running on an unsupported operating system, a number-crunching volunteer-computing program was using their memory (stopped), and cron still called the dead firewall tool (moved aside).

IPv6: both already had the right addresses for their DNS records but the wrong mask and an old gateway; fixed and verified. Gateway: the Pis were built to reach the wider network through the VM, but the VM’s routes pointed at stale addresses, one of them the camera access point. Corrected and tested: both Pis reach the outside amateur network through the VM and each other. A route to a retired device was removed at the owner’s request. A connection rate limiter now skips trusted sources.

fail2ban Installed on the Packet BBS Box (Oct. 6, 2026)

Why: the box’s old firewall tool did not carry over to the new system, and mail and the node are now reachable from the IPv6 internet as well as IPv4.

What it does: temporarily blocks an outside address after repeated failures: SSH, mail and FTP logins, and a flood of connections to the node. Repeat offenders get longer bans, up to a week. LAN, the whole amateur-radio network range, the VPN and the old partner allow-list are never banned.

Tested: the node-connection filter initially matched none of the real log lines because the log timestamp is stripped before matching; fixed to match 11,589 of 11,648 lines. A fake ban and unban of a documentation-range address on both IPv4 and IPv6 created and removed exactly the right rules without touching the box’s main firewall. A one-page cheat sheet is saved for the owner.

IPv6 Restored: Routed Address Block Re-enabled, Mail and Node Reachable Over IPv6, Tunnel-Broker Allow Rule (Oct. 6, 2026)

What was done: the two IPv6 DNS records were kept and made correct. The routed address block from the free tunnel provider was re-enabled on the router, the BBS box got a fixed address in it, and the router now allows exactly three kinds of inbound traffic to that one address: mail, the packet-node login and ping. Everything else from the internet is still dropped.

Verified from the outside: the provider’s own port scan sees mail and node login open and 998 other ports filtered, and a phone on cellular data can ping the box. (The scanner’s own ping step is unreliable and alternates between up and down; use its skip-ping option.)

Also: a permanent allow rule for the tunnel provider’s website was added to the network ad-blocker, which had been blocking its login page. The router’s IPv6 rules were backed up before the change.

After the Swap: Mail to the Node, Rate-Limiter Lockouts, Missing Telnet, MSYS Link and the Midnight Restart Explained (Oct. 6, 2026)

Fixed: mail from the BBS box to the packet node; the node’s repeating up/down alerts and the owner’s own SSH timeouts, caused by a global connection rate limiter that was throttling trusted machines (a short, specific trusted list was added after a broader one was declined); the node’s telnet command, missing on the new operating system; and the MSYS and FlexNet links, which had started while the BBS box was still booting.

Midnight restart explained: the packet BBS software had restarted itself just after midnight. The log shows it exited on purpose after detecting a corrupted internal queue, triggered by one AXIP partner sending repeated, out-of-order frames. It is a bug in that software release, a one-off in 11 days of logs, and the service came back in nine seconds on its own. A report for the author is drafted.

Partner links: two FlexNet partner links are still down. The portal lease expiry was checked and ruled out; a note to one partner was drafted and sent, and the other has been silent for about a week (see TASK 426).

Packet BBS Box Upgraded to a Current Debian: New Disk Built Offline, Swapped In, Weather and APRS Verified (Oct. 5–6, 2026)

How: a new 250 GB disk was built on a spare VM, then physically swapped into the box on the morning of Oct. 6. The old disk was removed untouched and is the rollback (kept at least two weeks). The new system has the same users, web sites, mail, FTP, packet software and firewall (translated to nftables), swap added, and a clean reboot rehearsal with no failed services.

Weather: the old weather software was replaced by WeeWX with the old history imported and the old pages kept; the last 419 readings were merged at cutover so no gap appears.

Found on the real hardware: USB port numbering changed in the new kernel, so the radio TNC rule that matched by port matched the serial adapter instead; it now matches the device’s identity. The GPS service grabbed the wrong adapters and, after the swap, put the GPS receiver into binary mode, so the weather packets went out with a zero position. Fix: the GPS daemon now only listens and never reconfigures the device; after a USB power-cycle of the receiver the position returned and the weather packet showed correctly on the APRS map.

Packet BBS Box: Backups Verified Three Ways Before Touching Anything, Plus a Rehearsal Copy (Oct. 4–5, 2026)

What was done: before any upgrade work, the BBS box was backed up three independent ways: a file-level archive, a raw database archive, and a full live disk image to the 4 TB drive. A rehearsal VM was then built from the backups and the whole upgrade was practiced on it, producing a written list of what differs on the new system.

Hardware warning found: the USB dock holding the 2 TB and 4 TB backup drives dropped off the bus and came back at least three times in an hour (when a drive was plugged in, and twice under copy load). Each time both drives lost their mounts or went stale. After each event the filesystem checks were clean and the backup checksums verified, but a scheduled backup could hit an unmounted path. The cause (cable, port or dock power) is not proven; a different port, cable or a powered dock is recommended. A retry-with-remount copy script was used to finish the work safely.

Packet Node Rebuilt on a New Modern VM and Cut Over the Same Evening (Oct. 4, 2026)

Why: the packet node ran on a decade-old, end-of-life operating system with no security updates and no package repositories.

How: a six-phase plan with a go/no-go gate and a rollback at each phase. The new VM was built in quarantine (all outbound traffic blocked), so test traffic could never reach partner nodes or the live node. Each service was proven there before cutover: the AX.25 and NetRom stack, both link types (IP-encapsulated and UDP), the cluster, the BBS, mail with the forward, the web pages, the DOS-emulated FlexNet node, the MSYS link, JNOS and the route feed. The radio TNC attached to the BBS box is reached over the network through a small serial bridge, so the node no longer needs the hardware nearby.

Found along the way: the stock cloud kernel has no AX.25 support and was swapped for the standard one; the old node’s weekly cluster job flushed the firewall every Monday (removed from the new copy); the antivirus is now report-only, scans nightly and pushes an alert on a find (tested with the EICAR test file).

Cutover: the old VM was stopped, kept intact and backed up as the rollback; the new one took over its address, MAC and services. Follow-up fixes are in TASK 420.

Packet Node Mail: Mail Server Had Been Off Since May, 13,000 Stuck Messages Archived, Relay, Gmail Forward and Phone Alerts Set Up (Oct. 4, 2026)

What happened: the owner could not always send or receive mail on the packet node. The mail server had not been running or enabled at boot since May, so everything submitted since then (alerts, cron output, packet mail) piled up unsent: more than 13,000 messages, about 240 MB, most of them old alert mail and texts to a dead carrier gateway.

Fix: the queue was backed up, the 13,349 stale messages were moved (not deleted) to an archive and the 32 real ones kept; the mail server was started and enabled at boot. Outbound mail now goes through the container host’s mail relay to the bulk-mail provider, and only packet-network destinations are sent directly. Mail from the packet network still arrives. A security check caught that the relay trusted every packet-network address; that was narrowed to the local network and the node’s own range.

Forward to Gmail: a plain forward failed for outside senders (the provider drops mail whose From domain is not verified), so incoming mail is re-sent as a new message from the node with Reply-To set to the original sender and the original attached, with a loop guard. Tested end to end and confirmed in the inbox.

Alerts: the firewall-alert flood (88% was “excessive resource usage”) was turned down, cron output now goes to Gmail instead of the owner’s texts, and a watcher checks every five minutes for the mail server down, a large mail queue, restarts and a full disk, pushing to the owner’s phone. Verified by stopping the mail server and watching it restart and alert.

Home-Automation Memory Watchdog Had Never Worked — Fixed, Now Alerts by Phone Push (Oct. 4, 2026)

What happened: the script meant to reboot the home-automation VM before it ran out of memory failed on every run (288 times a day) because two of its settings were never defined, so it never protected anything.

Fix: the VM number and a 28 GB threshold (of 32 GB) are now built in, a phone push alert fires when it triggers or when it cannot read the VM (six-hour cooldown), and a dry-run mode logs what it would do without rebooting. A real scheduled run read 23.4 GB correctly. The VM was at about 23.4 of 32 GB with an unknown growth rate, so the watchdog can now actually act if it climbs.

Homelab Security Audit: Read-Only Review, Updates Applied, Internet-Facing Doors Closed (Oct. 4, 2026)

What was done: a read-only review of the whole lab at the owner’s request, covering exposed services, pending updates, end-of-life systems, backups and monitoring. It found the camera recorder, two media servers, an old mail-retrieval service and two leftover mail/remote-login forwards reachable from the internet; well over 100 pending security updates (the first count was too low because package lists were stale); two end-of-life packet systems; a memory watchdog that had never worked (TASK 415); and a weekly access-point reboot that caused a 3 AM burst of network reconnects.

Healthy: the storage array, daily and weekly backups of every guest, 18 of 18 uptime monitors and certificates. Not audited: the wireless access points (password unknown), the Windows PCs, the home-automation internals, the camera system itself and workflow health.

Fixes, each at the owner’s go-ahead: security-only updates on the host and every container, all verified healthy afterward; the camera recorder, the media-server forwards, the mail-retrieval forward and the two leftover forwards were disabled (reversible, each verified closed from the internet); remote access now goes through the VPN. The doors left open on purpose are the web servers, the source-hosting service, the packet node and one media server. Also at the owner’s request: the Sunday 3 AM access-point reboot job was removed and the temporary block on the packet box’s webmail path was lifted (watch for restarts).

Still open from the audit: two guests need a reboot for a kernel update, the end-of-life packet systems are being rebuilt (TASKs 417 and 419), and one router admin account is still enabled.

Automation Server: Gmail Connection Kept Dying Every Few Days — Recovered, Moved to a New Google Project, All Workflows Re-pointed (Oct. 3, 2026)

What happened: the daily digest and other mail workflows failed three days in a row with “refresh token expired.” The owner reconnected the Google login, then re-created the connection under a new Google project. That project had the Gmail interface switched off, which Google’s own error message named; once the owner enabled it, the triage workflow ran successfully within minutes.

Fix: 23 Gmail steps across 17 workflows still pointed at the deleted connection (the automation server was quietly matching them by name, which is fragile). Each one was exported, patched, re-imported, re-published and the server restarted, after a backup of all 18 Gmail-using workflows was saved. One obsolete one-shot check was deliberately left alone. The owner confirmed the project’s consent screen is set to “In production.”

Also: the daily credential health check alerts by phone push rather than email, so a dead token is noticed the day it dies. A support-ticket draft with the full timeline is saved in case the weekly expiry returns (see TASK 413).

Security-Camera Access Point Dropped Off the Network — Recovered by Power Cycle, Reachability Log Started (Oct. 3, 2026)

What happened: the cameras vanished from the screen. The camera access point was not answering at all, while the other radio-room unit and the switch were healthy. A power cycle brought it back, which also wiped its in-memory log, so the cause of this lockup is unknown.

Found along the way: the admin logins for both access points rejected every known password (an earlier password rotation apparently did not stick). Only one attempt was made, to avoid locking the units out.

Now running: a once-a-minute reachability log for both units, so the next freeze is timestamped exactly and shows whether the two fail together or alone. A factory reset of the camera unit is deferred (see TASK 412).

Backup Stress Test: Every Scheduled Backup Run at Once (Oct. 3, 2026)

What was done: each distinct scheduled job was started together: the nightly job, the weekly full-fleet backup (to a 4 TB drive), the host-root backup and the packet-node backup (both to a 2 TB drive). The normal schedule was not touched and runs again as usual afterward.

Findings: the host handled it easily — load never went above about 8 on a 48-core machine and there were no errors. The host-root backup (about 9 GB) took 2 minutes, the packet-node backup (about 11 GB) 26 minutes, and the largest virtual machine (a 768 GB disk) 29 minutes, the same as a normal week.

Also learned: the hypervisor allows only one backup job at a time, so the nightly job queued behind the full-fleet job; the two small jobs ran alongside.

Final result (Oct. 7): everything passed. The full-fleet job finished successfully in about 1 hour 55 minutes and the queued nightly job finished right behind it; every guest backed up, the backup notification email arrived, and the only log notices were the routine informational note that some container disks cannot be snapshotted. The owner confirmed the test went well.

Router Alert Traced to Last Week’s Upgrade; Radio Node Found Down for Five Days and Recovered (Oct. 3, 2026)

Router: a red alert on the phone showed an old “down” from Oct. 1. It was the planned firmware upgrade of the router and both switches (the whole house is offline for several minutes during that). The monitor recorded recovery within minutes; nothing was wrong now, and no action was needed.

Radio node: while checking, the packet-radio node VM turned out to have been reported down since Sep. 28 (about 2:47 AM Eastern). The VM was running with 21 days of uptime, but the guest was frozen: no network services answered and its guest agent was dead. Both this and an earlier outage began shortly after the Monday weekly full backup; noted, not proven as the cause.

Fix: the owner approved a reset. Within two minutes it answered again and all services came up: the packet node, the DOS-based nodes, the AX.25 stack, the BBS and cluster, and the routing daemon.

Monitoring: Phone Alerts Through the Self-Hosted ntfy Server and 6-Hour Repeat Reminders on Eight Key Monitors (Oct. 3, 2026)

Why: the radio node outage went unnoticed for five days because a down alert fired only once.

What changed: the self-hosted ntfy channel (test message confirmed by the owner) and a 6-hour repeat while down were added to the router, hypervisor, packet node, packet BBS, Home Assistant, DNS filter, automation server and reverse proxy monitors. A backup of the monitor database was saved first and the monitor was restarted briefly. Website monitors that blip often were left out on purpose and can be added.

Automation Server Disk Doubled and Upgraded to the Latest Stable Release with All 46 Workflows Intact (Oct. 2, 2026)

Request: the owner asked to move the automation server to version 3. There is no stable version 3 yet — only daily test builds — so the owner chose to grow the disk and take the newest stable release now, and wait for the real version 3.

Safety: a fresh full backup of the machine (tested), the disk grown from 35 to 64 GB with no reboot, an export of every workflow and credential to files, and a rehearsal on a copy of the database with every workflow switched off and no network access, so nothing could post or send anything.

Result: the real upgrade took about 37 seconds of downtime. Afterward all 46 workflows were present, the same 44 were active, and the two meant to stay manual were still inactive. Scheduled workflows kept running and succeeding on the new version.

Rollback: the old database copy, settings and previous release are kept on the server, with written steps.

Host Upgrade Prep: Boot, Security and Update Fixes Done Safely Ahead of the Move to Proxmox 9 (Oct. 2, 2026)

What was done: before any change, backups of the boot partition, system configuration, cluster database, disk layout and an inventory on two different drives, plus a fresh full backup of the host. Then the one failing upgrade-checker item was fixed (an unused boot package removed), the backup boot files refreshed without touching the main boot entry, one setting moved to its new location, CPU security microcode installed, and twelve ordinary security updates applied.

Result: the vendor’s own checker went from one failure to none (47 checks). Nothing was rebooted and every guest stayed up throughout.

Also learned: the RAID controller and all fourteen drives are healthy (recorded as a baseline), and the hardware vendor publishes tools for the new Debian release. The newest Proxmox is 9.2; the earlier note about a 9.3 was wrong.

Ad Accounts: Old AdSense Account Removed from the Sites and the Current One Installed and Verified (Oct. 2, 2026)

Why: a hand-off note said to add one ad script to every site. Checking first showed six sites already carried the current ad account in their themes (adding it again would have loaded it twice), two shops carried none, and one site ran ads under a different, older account the owner can no longer sign in to.

Removed: the older account’s code everywhere it was found — a live header ad box and a Google-plugin snippet on one site, plus leftover ad widgets and an old plugin’s stored ad code on two others that were never displayed. Everything removed was backed up to files first.

Installed: the current account’s ad script on the site that had the old one, and on the pet-products shop, which the owner chose; the book shop deliberately stays ad-free because it sells the owner’s own books.

Verified: a fresh fetch of every site: only the current ad account appears, no duplicate scripts, no old accounts, the analytics and cookie banner still in place, no errors. The owner then added all eight sites in the ad console, got them verified, switched Auto ads on, and linked the ad account to Analytics.

Revenue Tracking Added to All Nine Sites: Affiliate, Book-Store, Signup, Contact-Form and Shop-Purchase Events (Oct. 2, 2026)

What it does: the cookie-banner file on every site now also records, only after a visitor accepts: clicks to book stores, clicks on affiliate or sponsored links, clicks to shop pages, newsletter signups, contact-form submissions, scrolling halfway, two minutes on a page, and on the three shops product views, add-to-cart, checkout start and completed purchases. Visitors who decline, and logged-in administrators, are never tracked.

Why: a second AI suggested a large log-analytics stack; the owner chose the simpler path of tracking the events that actually earn money inside the analytics account already running.

Testing: thirty simulated-browser checks (including what must not fire), eleven server-side checks with a deliberately hostile product name, and a real past order run through the live purchase code, which produced the correct order, price and book. Every home page, inner page and shop page was fetched live afterward: normal pages, one banner, no errors.

Limits: a screenshot of the analytics screens and marking events as key events need the owner signed in to the analytics account, so those are written up as an owner step.

Monetization Plan: What Each Site Earns Today and a Tiered List of Everything We Can Do (Oct. 2, 2026)

Audit of the live pages: Google ads are on seven of the nine sites; two are shops without ads; one site has product-affiliate links; the affiliate-content site has heavy affiliate wording but no ads or shop; the two travel sites have no travel-affiliate network yet. About 25,500 page requests across all sites today, much of it bots, so traffic is the main limit.

Result: a tiered list written for the owner: first the owner’s own books and an email list on every site, then affiliate links where there are none, then click and sales tracking, then print editions, digital products, courses, services, sponsorships, and finally traffic growth. It also says what not to do.

Decision: the large log-analytics dashboard stack was declined as overkill for this traffic and unable to measure scroll or time on page.

Site Analytics Consolidated onto One Account with an Opt-In Cookie Banner on All Nine Sites (Oct. 2, 2026)

Request: a hand-off note asked for one Google Analytics tag to be added to eight sites. Checking first showed seven already had their own separate tags, so adding another would have double-counted; the owner chose to replace them all with the single new account and to add a cookie banner, and to include a ninth site that also had a tag.

What visitors get: a small banner with Accept and Decline; nothing from Google loads unless they accept; a “Cookie settings” button to change their mind; browser Do-Not-Track and Global Privacy Control signals are honored; logged-in administrators see neither the banner nor the tag.

How: one small must-use plugin file per site (delete it to undo), with each old tag backed up first. Two sites had the old tag somewhere else — one hardcoded in its theme, one from a Google plugin — and those were removed too.

Verified: a fresh fetch of all nine home pages and 27 inner pages: normal pages, exactly one banner, the new tag present, no old tags, no errors. The banner logic and the server code were each tested in isolation first.

Honest note: the first version blanked one site’s home page for a few minutes because one page template never calls the footer hook and my fallback broke PHP’s output rules there. It was taken off that site immediately, rewritten without the problem, tested on that exact case, and redeployed everywhere.

Gumroad: All 17 Books and the 17-Book Bundle Listed with the New Covers (Oct. 2, 2026)

Result: the remaining six books and the terminal-guide listing were created and each checked against the store’s own records (price, file size, cover, published). The store limits new listings to ten per day, so these waited until the next morning.

Bundle: created as a draft, then the owner added the 17 books and published it, since the store’s API cannot set a bundle’s contents; afterward all 17 were confirmed. The book pages on the main site now link to every listing, and the temporary cover images were removed.

Ebook Series: AI-Generated Cover Art Replaced with Original Covers Everywhere (Oct. 1, 2026)

Why: the AI-generated cover art on all 17 titles was a copyright and terms-of-service risk for the online stores, so every cover was replaced with an original, text-and-color design in one consistent series style.

What changed: new covers on all 17 books; the store pages were updated in place (so addresses, search listings and order history were kept), the old electronic-book files and AI images were removed from the public web folder (archived privately first), and the store text was corrected so it no longer claims AI cover imagery. The 17-book bundle was rebuilt at a lower price than the sum of the parts.

Two defects found and fixed along the way: the delivered PDFs mixed a small cover page with larger pages inside, so all covers were rebuilt at the full page size; and three books still had an older author spelling inside, which was corrected in place rather than rebuilding from text-only sources that would have dropped every diagram.

Verified: every public page, cover and download file was fetched from outside and matched byte for byte; the e-reader (EPUB) files all passed the standard validator with zero errors.

Ebook Distribution: Aggregator Account Opened, First Book Live in One Store and Submitted to Twelve More (Oct. 1, 2026)

What was built: one upload kit for the Kindle store and one for a multi-store distributor, each with a folder per book (the book file, the right-sized cover, a plain-text description file) plus a single list of every form value, category and price. All 17 files were checked against the stores’ published rules first.

Result: the distributor account was opened and the first title went out; within about an hour one store had it live and twelve more, plus four library lending services, had it submitted.

Still open: direct publishing on the largest retailer is on hold because of an account-verification issue; an appeal message was drafted for the owner to send. The other 16 titles are queued.

Home DNS Filter: Two Narrow Allow-Rules Added So the Publishing Site Loads (Oct. 1, 2026)

Symptom: the distributor’s site timed out on the owner’s computer, then froze on load once past that.

Root cause: the DNS filter’s blocklists were sinkholing the site itself, and later the web-fonts address its pages load, so the browser waited on a stylesheet that could never arrive.

Fix: one allow-rule for the site, and a font-address rule limited to two named devices so the household-wide Google block stays in force. Each change was backed up first, the config check passed, and the block was re-tested afterward.

Honest note: one restart ran without the edit after a script file failed to save, causing a second brief DNS interruption of about half a minute.

Network Switches and Router Brought to the Same Latest Stable Release — Update Button Found Working Again (Oct. 1, 2026)

Problem: the built-in update button on the two rack switches returned “bad HTTP response” and left an empty download file behind, the same message the router showed in August.

Method that worked: download the release file directly onto each switch to the top-level file list (a copy in the downloads folder is silently ignored), save a backup to permanent storage first, then reboot one at a time. Reboots took four to six minutes, not the one or two first estimated, and the one nearest the router takes the whole house offline while it installs.

Investigation: after the upgrade the update check works on both switches and the router, including when a newer version exists (tested read-only against the beta channel, then switched back). DNS and connectivity were fine throughout, so it was not DNS; it only failed on the older release. The exact cause is unproven.

Result: all three devices run the same release, with firmware matched; findings are filed in the owner’s upload folder.

Radio Sound-Card Modems Cycling Again — Mutual-Restart Loop Traced and Cleared (Oct. 1, 2026)

Symptom: the packet-node software reconnected to its two modem programs about every ten seconds.

Findings: the node itself had run for days without a crash and the network link was clean; the log showed each reconnect triggering a restart request for the other modem, so the two programs, which share one executable name, kept stopping each other. My own two switch reboots earlier that afternoon are the likely trigger.

Fix and proof: rebooting the modem laptop and restarting the node cleared it. Afterward the log showed zero reconnects and zero restart requests over several minutes, and a connect test keyed the transmitter on the first port.

Lesson: each modem accepts only one connection, so checking its port from another machine can report “closed” and can disturb the link. Read the node’s log instead.

Backup System Verified After the Weekly Run, and the Full Schedule Written Down (Oct. 1, 2026)

Result: the weekly full backup finished cleanly in about two hours with every guest saved on the external drive, and eleven of the smaller archives were fully test-read with no failures. The host’s own backup and the radio PC’s weekly backup also ran, each to the second drive in the same dock.

Schedule: nightly for the busiest guests, a Sunday-morning host backup, a Monday-morning full backup, and a Tuesday-night radio-PC backup. A plain chart of all four was saved to the owner’s upload folder.

Desktop GPU Worker: Auto-Start and Pinned Driver Confirmed Complete by the Owner (Sept. 30, 2026)

What this was: a follow-up check that the remote GPU worker on the desktop starts by itself after a reboot and that its graphics driver is still deliberately pinned.

Outcome: closed on the owner’s confirmation — both were already verified when they were set up, so the extra re-check was not run. A read-only check script was prepared and is kept on file if it is ever wanted.

Independent evidence this week: from the server side, the pooled-GPU link was tested and all three cards, including the desktop’s, were detected and healthy; no changes were made to the desktop.

Password Login Turned Off on the Home Automation Server’s Remote-Access App — Key-Only Access Verified (Sept. 30, 2026)

Why: during the dashboard work a password for the remote-access app was accidentally shown in a diagnostics printout, so it had to be treated as exposed.

Before changing anything: checked whether anything depended on that password. The automation server’s SSH steps were audited across every workflow — none touch the home-automation host — and the desktop agents connect through the message broker, not SSH, so nothing needed it.

Fix: rather than rotating to a new password, the password setting was cleared so only key-based login remains.

Verified: before, the server offered key and password login; after, it offers key only. The existing key still logs in. The old password was never used in the test.

Cameras: The Older DVR Cannot Feed Frigate, the Battery Camera Is Parked for Later (Sept. 29, 2026)

The question: could Frigate (already installed but running only its placeholder setup) use the 2017 camera DVR, and could the newer battery-powered outdoor camera be added to Home Assistant?

DVR result: a read-only probe showed a generic embedded recorder with an old web interface, eight camera channels, and no standard video-stream (RTSP) or ONVIF service — and the recorder’s own menu has no setting for either. That rules Frigate out for it. One login attempt through its web gateway was rejected with the lockout counter already at zero, so it was deliberately not retried; nothing on the recorder was changed.

Battery camera: this type has no stream option and sleeps between events, so Frigate is the wrong tool. The workable path is Home Assistant’s cloud integration, which needs a second manufacturer account with the camera shared to it. Decision: keep the camera pins on the dashboard as static artwork now and do the live integration later (see the Down the Road item).

Housekeeping: the temporary credential files were deleted afterward, and a note was made to mask secrets when checking file formats.

Interactive Property Overview Dashboard Built in Home Assistant, With Live Readings Over Illustrated Renders (Sept. 29, 2026)

What was asked for: a visual dashboard where live readings sit on top of illustrated renders of the property and the house cutaway — solar, weather, radio conditions, power and network health — instead of another page of tiles.

How it was done: first a strictly read-only inventory of roughly 800 Home Assistant entities (what exists, what updates reliably, what is missing), then a placement map pairing each spot on the renders with the right readings. The result is a new, separate dashboard with two views (an overview and a systems cutaway) carrying 21 live overlays: solar output, outdoor and indoor temperature, wind, ham-radio band conditions, whole-home and per-area power, internet speed, and network-equipment temperatures. Three new ping monitors were added for the wireless access points so their reachability shows on the picture. The existing dashboards were backed up first and verified byte-identical afterward.

What went wrong and how it was fixed: on a phone the first version looked wrong — labels overlapped and one clipped at the edge. Root cause: Home Assistant’s label element carries a fixed inner padding that ordinary style settings cannot reach, so boxes stayed tall no matter what. Fix: scale each box, reposition by percentages, and add a normal-size readout card under each picture. Verified by rendering the real live page in a headless browser at three phone widths and measuring every box — no overlaps and at least 8 px clear of the edge on all of them (a very narrow 320 px screen is the one known limit, covered by the readout card).

Honest limits: the solar figures are whole-site totals, not per-roof; camera shapes, the water tank and the garden are artwork only; there is still no battery, UPS or server-host telemetry in Home Assistant to display.

A “Stale Feed” Alert Turned Out to Be a Mislabeled Page, Not a Broken Feed (Sept. 29, 2026)

What the alert said: the new watchdog from two days ago flagged the Indiana packet-radio station map as not having updated in over a day.

What was actually true: that page was wrongly marked “live” in the first place. The map draws from a manually maintained reference list (the owner is the actual coordinator for it) that gets updated by hand occasionally, not by any automatic process — it hadn’t changed since mid-July, completely normally. The page had a technical detail that looked like a live-feed signal but wasn’t one, which is what caused the original mislabeling.

Fixed: the page now carries the correct, calmer “maintained” badge instead of the flashing “live” one, and it was removed from the automatic watchdog entirely so it won’t send another false alarm. The lesson from this mix-up was written down so the same mistake isn’t repeated on any future page.

Gmail Assistant’s First Real Email Exposed a Critical Bug — Found and Fixed the Same Hour It Went Live (Sept. 28, 2026)

Daily digest added: at the owner’s follow-up request, a once-a-day summary email was added covering the last 24 hours — how much mail was sorted, and a checklist of anything that needed a reply along with whether a draft actually got made for it.

Building the digest surfaced a serious problem no test had caught: the reply-drafting step had never actually worked, for any email, ever. A step meant to decide “does this need a drafted reply” was silently reading blank information instead of the real answer, so it always said no — even when the sorting step upstream had correctly said yes. The very first real email that should have gotten a draft proved it: correctly filed as needing a reply, but no draft appeared. Found within the hour and fixed by pointing that step at the right data. Re-verified with a direct test that it now correctly reaches the drafting step when it should.

Same email also exposed a real sorting mistake: a newsletter written under an individual’s personal name (not a company name) fooled the sorter into treating it as a personal message needing a reply. Fixed by teaching it to look at the actual shape of the writing — a general-audience article versus a specific question meant for the owner — instead of just guessing from the sender’s name. Re-tested against that exact email afterward: correctly sorted now. The one email affected was manually relabeled correctly; no reply was ever actually owed to it, so nothing else needed fixing.

Owner’s manual updated to describe the new digest and stays the reference for what to do if anything looks off going forward.

Gmail AI Assistant Turned On, With Two Real Fixes and Its Own Watchdog (Sept. 28, 2026)

Fixed first, then switched on: before turning it live, a real duplicate-draft glitch found during testing was closed for good — the system now checks for an existing draft on a conversation before ever writing a new one, so a repeat draft is no longer possible no matter what causes a re-run. The sorting logic was also sharpened so a mailing-list-style newsletter is checked for and caught before it can fall into the more generic “just FYI” bucket.

Now live: switched on the same day it was approved. Every new email now gets sorted automatically, and anything that genuinely needs a personal reply gets a drafted response waiting — never sent automatically.

Its own watchdog: a second, small automation now checks twice an hour that the assistant is still switched on and hasn’t hit repeated errors, and sends the same kind of alert as any other homelab problem if either happens. Building this caught its own real bug — a script-quoting mistake that would have made the watchdog falsely cry wolf — found and fixed before it ever sent a false alarm.

Self-Hosted Gmail Triage + Draft Assistant Built and Tested — Not Yet Turned On (Sept. 28, 2026)

Why: the spec for a self-hosted replacement for a $30–50/mo email-triage SaaS was locked back in early September; today it actually got built.

What it does: new mail gets automatically sorted into one of five folders (needs a reply, FYI, automated notification, newsletter, or needs an outside action) using a free local AI model, at zero per-email cost. Only the “needs a reply” ones get a drafted response written in the owner’s own voice by a stronger paid AI model — saved as a Gmail draft only, never sent automatically. Every message processed gets logged.

No new logins needed: both the Gmail and AI-drafting connections already existed from other automations and already had the right permissions — confirmed live rather than assumed, so no interactive sign-in step was needed on any device.

Tested for real before trusting it: ran it against real unread mail (an automated notification and a real newsletter, both sorted correctly into two different folders… well, one landed in the more general folder rather than the more specific one — a fair, minor mistake, not a crash). The actual drafting step was tested with a safe made-up question rather than digging through real personal mail, and the resulting draft read naturally and matched the owner’s style well. A real bug was caught and fixed along the way: some steps were silently losing track of which email they were even working on, fixed by being explicit about where each piece of data comes from.

Deliberately left off: the system is fully wired up but not yet switched on for real incoming mail — that switch happens only when the owner says so, consistent with how anything touching his real inbox gets handled here.

“LIVE” Badge Turned Into a Real Health Check, Not Just a Decoration (Sept. 28, 2026)

Why: yesterday’s flashing LIVE badges were honest about classification but not about current health — a page would keep flashing LIVE forever even if its data feed silently died. Fixed that gap.

Built: a new automated check that runs every 5 minutes, looks at whether each live page’s underlying data has actually changed recently (not just whether the page loads), and writes a small shared status file the pages themselves read. If a feed goes more than 2 hours without a real update, its badge automatically turns from flashing green to a muted amber “STALE” label — and the owner gets a notification the same way any other homelab alert reaches him.

Tested both directions before trusting it: forced every feed stale on purpose first, confirmed the badges flipped and a real alert actually fired end-to-end, then confirmed everything correctly flipped back to healthy afterward with no false alarm on the recovery.

Rolled out to 11 of the 18 live pages — the ones with a data file this side of the site actually generates and controls. The remaining 7 (things like the earthquake feed, flight tracker, and an interactive testing tool) pull from outside sources or don’t have a single clear freshness signal, so they keep the original always-on badge for now rather than a health check that couldn’t honestly tell healthy from broken.

AI-Answer Optimization (AEO) Completed Across All 8 Self-Hosted Sites — Encoding Bug Found and Fixed Along the Way (Sept. 28, 2026)

Why: this had sat “queued” on the tracker, but checking the actual data first showed most of the fleet was already far along from an earlier pass — the tracker label was stale, not the real state.

Real gaps found and closed: one post each on four sites (the AI/tech explainer site, the crypto site, the travel/hotel site, and the pet site) had been published after the earlier AEO pass and never got the FAQ treatment — fixed. The travel site had two more older posts missing it too. The small-business/WordPress-tips site was the furthest behind, missing it on all but two posts; the two recent, clearly original ones got it, while five much older posts were left alone after a quick look raised a real question about their originality — owner’s call, skip those five.

A real bug found while checking: one post each on two sites had garbled punctuation inside their structured-data markup (a classic text-encoding mistake) — degrading how search engines could read that page’s data even though the visible page looked fine. Found by comparing actual byte content, not by eye, and fixed precisely without touching anything else on either page.

One big pile deliberately left alone: the online bookstore’s product catalog turned out to include a large batch of old, generic resold ebook titles bulk-imported in past years — not the owner’s own writing, and nothing like the technical-guide catalog the owner actually authors. Putting “this page authoritatively answers your question” markup on that pile would have been the wrong call. Flagged to the owner before touching any of it; owner confirmed: skip entirely, same decision already made once before about similar imported content on another site.

Left over: the bookstore’s homepage still only has generic structured data, found during the same check — a small separate item, not tackled today.

Two-Tier “Live”/“Maintained by Claude” Status Badges Rolled Out Across All 34 Site Pages (Sept. 27, 2026)

Why: the owner wanted every page to visibly show it’s watched over and kept current — a flashing green LIVE dot like a couple of pages already had, as a bit of an earned brag: this site is monitored and updated by Claude, with the owner’s approval before anything ships.

One correction before rolling it out everywhere: putting the same flashing “LIVE” claim on every page, including pages with no real data feed behind them, would have been misleading and would have undercut the pages where it’s actually true. Proposed and agreed on a two-tier system instead.

Classification was measured, not guessed: every page’s actual JavaScript was checked for real live-data signals — a periodic auto-refresh timer, or a data fetch that explicitly bypasses caching so every page load pulls fresh numbers. A lone one-off fetch() that just loads an audio file, for example, did not count as “live.”

Result: 18 pages get the flashing badge (network status, the Home Assistant tracker/devices/energy/automations pages, the homelab and network-map pages, Garmin telemetry, solar production, the crypto/YouTube intel page, earthquake feed, position tracking, radar loops, the packet map, the live infrastructure tester, and the retirement countdown) — each pulls genuinely fresh data on every visit. 16 pages get a quiet, non-flashing “Maintained by Claude” credit instead (the task tracker itself, static write-ups, the 3D solar-system visualization, forms, and reference pages) — honest about being kept current rather than claiming real-time data they don’t have.

How it was built: both badges are a small self-contained overlay (fixed corner position, own inline styles) injected right after each page’s opening <body> tag, so none of the 34 pages’ own layouts or color schemes needed to be touched or matched individually. Full site backup taken first, plus an individual backup of every file changed.

Honest limitation, flagged by the owner’s own follow-up question: as built, the badge is a static label, not a live health check — a page keeps showing “LIVE” even if its underlying data feed silently goes stale. Turning it into a real, self-correcting monitor (only shows LIVE when the data is actually fresh, alerts if one goes stale) is the natural next step and would reuse the same automation-server pattern already running the rest of the house’s health checks.

Morning Power-Glitch Follow-Up — Radio Node, Its Neighbor, and the Long-Distance Relay Link All Checked Clean (Sept. 27, 2026)

Why: the owner had a power glitch overnight and asked for a health check on the radio node, its sibling node, and the long-distance packet-radio relay link, since all three have had real trouble before.

Checked: neither machine had rebooted — both had been running for many days straight, well before the glitch. The weather station kept reporting fresh readings the whole time. The radio node’s neighbor links were active and current, and the relay route to the distant station was still in place (this exact route has quietly vanished on its own twice before, so it’s the first thing checked whenever this link is questioned).

Outcome: nothing needed fixing. One side effect: this prompted a look at whether the house’s battery backups are being watched at all — see the next item.

Battery-Backup (UPS) Network-Monitoring Project Scoped Across Three Rooms; Two Wrong Approaches Ruled Out Before Spending Anything (Sept. 27, 2026)

Why: after the power-glitch check above, the owner realized the house’s several battery backups have never been watched by software — nothing would alert if one ever failed or ran dry during an outage.

Plan, phased by room: start with two units in the bedroom, then two more next to the main virtualization host, then four in the radio room. The bedroom and host-room units connect over USB to a computer that’s already there; free software then reports each one’s status (on-battery, load, runtime, last event) out over the network automatically — no new hardware needed for those two rooms.

Radio room needs real hardware, and two wrong turns were caught first: those four units specifically need to land on network-switch ports rather than a nearby computer. The first idea — a plug-in USB-to-network adapter, the same kind already used successfully on an unrelated laptop — would not have worked: that adapter only works because a full computer’s operating system drives it, and a battery backup has no operating system of its own to do that. The second idea — adding an expansion card to a small radio-room computer to get more USB ports — also would not have worked: that computer turned out to be a compact model with no expansion slot at all, confirmed by checking its hardware directly rather than guessing.

Where it landed: two real options remain for the radio room — reusing small dedicated computers already sitting in both target rooms with reportedly spare USB ports (cheapest, and already using proven, compatible software), or a purpose-built USB-to-network relay box (pricier, with an unconfirmed software-compatibility question against this all-Linux house that would need checking before buying).

Status: planning only. The owner is tracking down login details for the existing room computers before the next step; nothing purchased or wired up yet.

A Website File-Transfer Login Was Reset After Being Lost; Works Everywhere Except One Laptop, Paused There (Sept. 27, 2026)

Why: the owner needed into an old file-transfer account and had no record of its password anywhere retrievable.

Fix: the account’s password was reset directly on the server and confirmed working immediately from another client.

One laptop still can’t use it: a laptop that runs the station’s radio-modem and radar software kept failing with confusing, unrelated-looking errors. Root cause: that laptop’s built-in file-transfer client is old and partly broken on modern Windows — typing the address directly failed, and even the recommended workaround ended up handing the request off to the default web browser instead, which doesn’t support this file-transfer protocol either anymore. Nothing wrong on the server side; a different third-party client had also given this laptop trouble previously. Paused at the owner’s request for a day or two while a dedicated client gets installed instead.

Virtualization-Host Upgrade Assessed and Runbook Written; System Disk Freed From 96% Full to 42% (Installer Images Moved to the Big Drive) (Sept. 24, 2026)

Assessment (advice only): the owner asked how feasible and risky it is to upgrade the virtualization host to the newest major version. It is possible and the supported path applies, but not urgent. The vendor’s own pre-upgrade checker found one blocking issue and several warnings, including a nearly full system disk. Specific risks: a whole-lab outage of one to two hours, no in-place way back, a need for a remote console in case networking changes, and the graphics cards passed through to one virtual machine, which newer kernels may affect.

Runbook written: a step-by-step runbook and backup checklist was left in the owner’s file drop, covering preparation, the upgrade window, verification, rollback and a go/no-go gate. It relies on backup drives that already exist.

Cleanup 1: an unneeded scratch folder from an earlier Windows session was removed at the owner’s request. It contained one Raspberry Pi disk image the owner afterward remembered wanting. No copy existed on the server or any backup drive, but the original is very likely still on the owner’s PC and the image can be downloaded again.

Cleanup 2: about 16 GB of operating-system installer images and container templates were moved from the host’s system disk to the large storage drive. They were copied, checksum-verified against the originals, the four virtual machines that used them were re-pointed, and only then were the originals deleted. The running machine stayed up throughout. The system disk went from 96% full to 42% full, which meets the upgrade guide’s space requirement.

Left: moving one more folder to the big drive once its location is chosen, the rest of the preparation steps, and a maintenance window. The upgrade itself has not been started.

Radio-Node Software Update Baselined, Health-Snapshot Tool Built, and a Mail-Page Re-Enable Test Planned (Sept. 24, 2026)

The update: at the software author’s suggestion, the owner updated the radio node to the newest release and will report the results back to the author in a few days. It came up healthy: normal thread count, the status page answering in milliseconds, and the station links re-forming within minutes. Older versions were kept alongside for an easy rollback.

Baseline for the report: the previous release crashed seven times on the prior day and had logged hundreds of crash entries in total. There are two known crash bugs: one in the mail page, which currently cannot trigger because that page is blocked, and one in general web handling that cannot be blocked. A web-server pile-up the same morning was mitigated at the front-end proxy.

Tool built: a read-only health snapshot that reports the version, new crashes since the update, real restarts, thread count, page speed, station links and whether the mail-page block is in place. The first run was clean, with zero new crashes.

The owner’s Monday plan: confirm it’s still healthy, then try turning the mail page back on if there are no issues, watch it for a week or until it first misbehaves, and decide whether to keep it on. If it misbehaves, putting the block back is one edit and one command. One thing to weigh: that page is the public face of one of the owner’s sites once it’s enabled again.

Honest notes: it isn’t yet known whether the new release fixes either bug, and only the web-handling bug can be tested while the mail page stays blocked. Nothing else was changed today; the results go to the software author after Monday.

Addendum — first 13 hours on the new release (Sept. 25, 2026): the health snapshot shows no new crashes, no restarts, a steady thread count, fast status-page responses and healthy station links, with the mail-page block still in place. The Monday plan is unchanged.

Camera 5 GHz Bridge Closed Out — Soak Passed, Safety Watchdog Removed, Temporary Remote Access Turned Off (Sept. 24, 2026)

Soak: the owner chose to finish rather than wait out the full one-to-two-day soak. After about 80 minutes the wireless connection had never once broken, with no drops, delays averaging 1.5 ms, a steady strong signal and essentially no failed transmissions. One alarming-looking counter turned out to be a harmless quirk of how that radio counts. About 40% of transmissions need a retry, which is steady and doesn’t affect performance, so it’s only noted for later.

Cleanup: after one more health check, the self-triggering rollback watchdog was fully removed from the far-end radio and confirmed gone. The temporary remote access on the near-end radio was turned off and confirmed closed. Fresh backups of both radios were saved after the change and confirm the final settings, with no leftover safety-net pieces.

Left to do: the owner records the new network name and passphrase in the password manager. Going back to the old band is now a manual procedure, with the original settings and backups kept in a private folder. One last read-only check is scheduled for this evening.

Addendum — admin password rotated (Sept. 24, 2026): the owner asked for the shared admin password of the two access points, received it through a private file rather than chat, and then asked for it to be changed because it had been typed into a chat. It was changed on both devices using a deliberately minimal request that sends only the password fields (leaving out settings that could have switched off the web interface), with the new password saved privately first. The far device was done first and checked three ways — the new password works, the old one is rejected, and remote-shell login accepts the new one; the near device accepted the new password too (the old one was deliberately not tested, to avoid tripping its failed-login lockout). The camera link was unaffected. Old copies were scrubbed from the assistant’s notes and scheduled jobs, and nothing else in the homelab used that login. Left for the owner: record the new password in the password manager, then have the private file deleted.

Addendum — post-switch checks (Sept. 24–25, 2026): four read-only checks after the switch, all clean, the last one about 15 hours in: no drops at all since the switch, availability over 24 hours 99.8%, delays averaging under 2 ms with the worst single reply about 10 ms, and the camera recorder answering normally. The other health checks stayed green with no alerts. The radio-level counters were skipped after the password change, since the assistant no longer holds the login. The bridge project stays closed.

Camera Bridge Moved Off a Crowded Wireless Band onto a Hidden 5 GHz Link — Three Phases Done, Soak Under Way (Sept. 24, 2026)

Why: no cable can be run to the camera bridge, and its original wireless band had become badly crowded (more than a dozen neighbouring networks on the same channel). Delays crept up from 3 ms to over 150 ms and spiked to 100–260 ms. Turning on logging on both radios showed the real mechanism: the far radio was resetting roughly every six minutes, kicking every device on it off and back on at the same instant. A reboot only helped for a while.

Prep: full settings backups of all three radios; a survey of neighbouring channels showed the house’s own access point occupies both quiet 5 GHz blocks, so the bridge uses the one remaining clean, radar-free channel. A new hidden network name and passphrase were generated and delivered privately. A plan-breaking finding: on these units, settings changed “without saving” are saved anyway by a reboot, so the original undo plan would have failed — it was replaced by a self-triggering rollback watchdog that was tested on a harmless setting first.

Near-end radio: two short reboots (about a minute each) to start a remote shell and then apply the new 5 GHz settings. Along the way the assistant’s safety layer blocked a shortcut that would have created a remote-command feature on the radio (not retried), and one of my own verification scripts printed blanks because of a scripting mistake — caught and re-checked properly before anything was trusted.

Far-end radio: with the watchdog armed first, the far radio was switched over. It was down 47 seconds and came back connected on 5 GHz with a strong signal and no failed transmissions. Measured result: delays now average about 1.7 ms with no spikes (before: 12–35 ms, spiking to 100–260 ms). The camera recorder answers instantly, and the two smart-home devices moved to the nearer radio on their own.

Still to do: a one-to-two-day soak with the safety watchdog armed, then cleanup: disarm the watchdog, turn the temporary remote shell back off, take fresh backups, and record the new network in the password manager.

Radio-Link Alerts Root-Caused Again — a Web Crawler Starved the Radio Node’s Status Page; Monitor Rebuilt, Proxy Fixed, Node Restarted (and One Self-Inflicted Outage) (Sept. 24, 2026)

Symptom: after the previous day’s fix there were no false alerts for 7.5 hours, then the radio-link monitor started again — 17 alert/recovery pairs in about five hours, several reading “0 links” even after retrying. The owner asked whether this was the main radio node or the second one: it’s only the main node.

Diagnosis: the radio links themselves were healthy — real disconnects were normal and one at a time, and about twenty links showed when the status page rendered. The page was the problem: it took 4–10 seconds to answer and usually came back empty, because roughly thirty connections were being held open against the node’s small built-in web server.

A wrong turn, corrected by the owner: the first guess blamed visitors to one of the owner’s sites. The owner pointed out that site had been deliberately disabled the day before, so that guess was checked properly against the proxy’s live session list. The connections were nearly all from a large social-media company’s web crawler, endlessly retrying a page that no longer worked. Blocking it just shifted the load to other automated sources.

Fix 1: the monitor no longer reads that web page. It now counts confirmed two-way radio-network flows straight from the server’s own connection tracking — steady, independent of the web server, and still able to spot a genuine collapse within about three minutes. It also now reports directly when the node restarts, which the old page count only caught by accident. Tested both the healthy and the failing case, then run live.

Fix 2: the shared front-end proxy now blocks that crawler for that one site and caps how many connections can reach the node’s web server. At the owner’s request the site was brought back afterward, with those protections kept. Everything else on the proxy is unchanged.

A self-inflicted outage: while making that change I reloaded the proxy twice in a row. The second reload stalled and the service was restarted by the system, so every self-hosted site was down for roughly 6–25 seconds. It recovered on its own, and the lesson is recorded: one reload per change, after checking nothing is still draining.

Restart: the node’s web server was stuck outright, not just slow, so with the owner’s approval the node was restarted. Its shutdown hung and had to be force-killed, then it came back cleanly: the page answers in about 10 ms, the station links rebuilt within minutes, and its mail-forwarding settings were checked and are intact. The restart also produced one expected alert and recovery, proving the new restart detection works.

Honest caveats: the underlying bug in the node’s web-server code is not fixed (the monitor no longer depends on it), and another crawler could pile up again. The camera bridge looked healthy the same morning and is being rechecked this evening.

Radio-Link Health Alerts Traced to an Unreliable Status Page — Monitor Made Robust, Stale Monitor Retired (Sept. 23, 2026)

Symptom: the owner kept receiving health-alert emails. Every one came from a single packet-radio link monitor — about 22 alert/recover pairs in 24 hours — reporting that far fewer radio links were connected than normal.

What it was not: only a few alerts lined up with real software restarts of the radio node, and the node had stayed up for about seven hours while alerts kept coming. An earlier firewall change did cut restarts sharply. One wrong turn along the way: the node’s debug log is stamped in UTC, which briefly sent the investigation to the wrong time window before it was caught.

Root cause: the monitor counts connected links by reading one status page once every five minutes. Sampling that page every couple of seconds showed the count swinging between the normal number and zero within moments — the table was sometimes momentarily empty — with no matching disconnect events in the node’s own log. The page itself is unreliable, and a single reading occasionally lands in one of those gaps.

Fix: the alert floor was deliberately not lowered. Instead, if the first reading looks low, the monitor now re-reads several times over about ten seconds and keeps the best one; a real outage stays low for all of them and still alerts. Backed up first, syntax-checked, and run live once. Honest caveat: the test window happened to contain no dips, so the fix is not yet proven — the real test is whether alerts drop tomorrow.

Stale monitor retired: a second, abandoned monitor for a decommissioned virtual machine had been reporting “fail” nonstop. Because alerts only fire on a change of state it was silent, but it also could never have caught a real problem. Its files were moved aside (reversible), not deleted.

Old virtual machine removed: the owner asked for the abandoned VM to be removed. It was inspected first: stopped, its disk not shared with anything, set to start automatically (turned off so it could not return on a reboot). The assistant’s safety layer blocked the deletion, since irreversible actions need an explicit go-ahead, so it stopped and asked; the owner then deleted it themselves. Verified afterward: the VM, its disk and its backup-job references are gone, and two full backups remain on the external drive.

Coverage gap closed: the owner asked whether the file-transfer service on the radio box was still being monitored. It was not — the only check that ever covered it was the abandoned monitor that never could have alerted. A small replacement now runs every five minutes, checking that the radio software is running and that the file-transfer service is running and actually answering, with a single retry so a momentary blip does not send an email. Both the healthy and failure cases were tested without sending a false alert, then run live and confirmed registered.

Garage Camera Repeater Project Scoped, and a Router Revival Guide Written (Sept. 23, 2026)

Scope confirmed: three cameras in the garage need to reach an existing wireless network, and no cable can be run there — so it is a wireless-range problem. The plan is to use a spare router as a repeater on that same network, so the cameras join a closer, stronger signal without reconfiguration. This is a separate project from the existing camera-bridge work.

Hardware reality: of four identical spare routers, three were recycled; the one kept has locked, vendor-customized firmware with an unknown login that a factory reset did not clear. A mode switch on the back also had to be moved to get it to hand out addresses.

Deliverable: a step-by-step revival guide was written and left in the user’s file drop, covering the verified recovery method, what (if anything) to buy, and troubleshooting. One honest gap: the firmware vendor’s sites block automated downloads, so the exact firmware file is left for the user to look up rather than guessed. The project is on hold; an old already-flashed router may turn out to be the easier route.

Bookstore — AI-Answer Optimization Applied to Every Book Page, the FAQ Page and the Bundle; Announcement Fixed and a Dead Link Repaired (Sept. 23, 2026)

All 17 book pages now have a visible FAQ section and matching structured data, with answers built only from each book’s own description — what it covers, the file formats (checked against the real downloads), what the Second Edition includes, and who it is for where stated.

FAQ page rewritten: it still said PayPal was the only payment method after credit-card checkout went live, and listed file types the books do not use; it now has accurate payment, format and refund answers plus structured data. The bundle got its own FAQ, with the contents of both download files and the savings figure verified rather than assumed.

Fixes found along the way: the launch announcement still said 16 titles (now 17), and its link to the complete bundle had never worked — it pointed at an address that does not exist. Both fixed and checked live. Verified all 17 pages afterward: valid markup, one FAQ block each, original product data intact.

Affiliate Site — AI-Answer Optimization Applied: 1 Post Rebuilt and 4 New Original Posts Published (Sept. 23, 2026)

Why: the AI-answer optimization pass done on the other sites had been deferred for this one and never redone after the domain move. Only 2 of 93 posts had the question-and-answer markup.

One existing original post was rebuilt using only its own text: answer-first opening, question-style headings, a visible FAQ section and matching structured data. Four new original posts were written under the owner’s byline on affiliate-marketing basics (how affiliates get paid, disclosure basics, affiliate vs. dropshipping, startup costs) — evergreen, no invented statistics, the disclosure post explicitly not legal advice. Drafted first, published on the owner’s go-ahead, and all four verified live.

Affiliate Site Cleanup — 21 Very Old Posts Removed, and Most of the Rest Found to Be Scraped Feed Content (Sept. 23, 2026)

Request: the user asked to remove the very old posts, anything before 2024 — 21 posts, all from a single 2016 import.

Done safely: a full backup first, then the posts were moved to the trash (recoverable for 30 days, not permanently deleted). Menus were checked first, caches were cleared, and the old address now returns a proper “not found”.

Important finding: of the posts left, only a handful are the user’s own writing; most are auto-imported feed content, including one that is a scraped excerpt from another publication. Rather than stamp the user’s byline and question-and-answer markup on other people’s articles, those were left alone. Whether to remove them is still the user’s call.

Admin Logins Reset on Two Self-Hosted Sites — Stored Password Was Stale (Sept. 23, 2026)

Problem: the saved admin password no longer worked on either of two self-hosted sites. Each has only one administrator, so there was no ambiguity about which account to reset.

Fix: reset both from the command line (no dependence on email delivery), delivered the new passwords through the user’s private file drop, and confirmed each with a real login attempt that redirected into the dashboard. After the user copied them and updated their password manager, the delivery files were deleted.

Camera Bridge — Logging Turned On for Both Radios, Logins Unified, and a Built-In Lockout Found and Cleared (Sept. 23, 2026)

Stability review: the camera bridge dropped eight times in 24 hours (97.7% availability) — seven brief blips of under a minute, plus one real 17.5-minute outage. Neither radio rebooted during any drop, pointing to a wireless-layer dropout rather than a device fault. By evening it had been stable for ~10 hours, though jitter had crept up and is worth watching.

Logging: logging was switched off on both bridge radios, so there was never any radio-side history. Turned it on for both. The router’s web form needed a browser-style referrer header to accept the change and requires every field to be resubmitted, so the change was made carefully and then verified by re-reading the page.

Logins: the password-manager entry for the two radios matched neither device; the two were unified onto one account and re-verified.

The lockout: after several failed logins, one radio stopped answering web requests from this machine altogether (connection reset right after connecting), even for pages that normally need no login. It was not a configured rule — it is built-in behaviour of that firmware. A reboot cleared it and the bridge recovered on its own within seconds.

Guardrail note: the assistant’s own safety layer blocked it from guessing passwords, which was the right call.

Radio-Link Flapping and Camera-Bridge Drops — Shared Network Equipment Ruled Out With Real Log Evidence (Sept. 23, 2026)

Question: two separate problems kept recurring — a radio link flapping, and a wireless camera bridge dropping for 20–58 seconds at a time. Could one shared piece of network equipment (the router, either switch, or the wireless access point) be the common cause? Confirmed the two issues never happen at the same moment, then checked every device’s own log.

What the logs showed: the router’s log is flooded by an unrelated block rule and only reaches back a couple of hours, so it could not help retroactively. The switch port feeding the radio box has not flapped once in six days. The port feeding the camera-bridge radios flapped once, at a time that matched nothing. The access point’s log covered all five flap times that day and contained zero wireless events.

Conclusion: no shared equipment is the cause. The radio-link flapping lives in the radio software’s own crash bugs, and the camera-bridge drops live in the bridge radios themselves.

Honest note: part of this “discovery” was already documented in an older note that was missed — the two notes were merged so there is one source of truth.

17th N9LYA Ebook Added — Termux Guide Built, Corrected, and Published to Both Stores (Sept. 23, 2026)

What: took a draft ebook (uploaded as a Third Edition) and turned it into the 17th title in the N9LYA Technical Guides series — corrected every edition reference to match the series convention, proofed the content, built a proper e-reader file and a printable file from scratch, and published it alongside an updated bundle on both storefronts.

Real problems found and fixed along the way, not just plumbing: the draft literally could not be found until checking the right server — two computers here have separate upload folders and only one is reachable from outside. The printable file's page size didn't match the rest of the series (was built to a different standard entirely). The very first version of the two listing images had the wrong picture composition on both stores — not the wrong size, the wrong crop — found by lining them up side by side, not just checking dimensions. A file-tagging mistake while filing the new title under the shared bookshelf briefly hid it from every shelf and homepage listing that show shelf; fixed and confirmed showing everywhere.

Confirmed live on both stores: new title page, updated 17-book bundle (new file set, new price, new description, new cover), and the two listing images now visually match the other sixteen exactly — verified by placing them side by side, not just by matching file sizes.

Honest note: one piece of this (linking the new title into the bundle's actual contents on one of the two stores) has no automated path at all on that platform — confirmed again this session with a fully-authorized key, not a permissions problem, a genuine gap on their end. That step was done by hand.

N2NOV Notified the AXIP Fix Is Live — A Stuck-Login Bug in the AI Assistant Along the Way (Sept. 22, 2026)

What: sent Charles a full write-up confirming the earlier router-route fix and that the link is active and reciprocally confirmed from his own station’s status page.

Hiccup along the way: the assistant’s own email tool lost its login partway through the session and would not accept repeated sign-ins — seven attempts, all seemingly accepted on the login screen, none of them reaching this particular conversation. Turned out the conversation itself was stuck reusing its very first, now-broken connection and never tried a new one, no matter how many times the login step itself succeeded. A brand-new conversation opened a fresh connection immediately and the very next attempt worked.

Also confirmed along the way: this was purely an assistant-side hiccup — the separate automated alert emails (the ones used for site/router health monitoring) kept working the entire time, unaffected.

Also: reported the underlying bug back to the tool’s maker, since retrying the same stuck conversation could never have fixed it on its own.

N9LYA-8 AXIP Link to N2NOV Broke Again — A Router Route Had Vanished, Restored and Confirmed Live From Both Ends (Sept. 22, 2026)

Symptom: N2NOV reported the direct radio-over-internet link down again — his traceroute could not reach our block at all, and only an indirect path through two other partner stations still worked.

Diagnosis: traced live rather than trusting his own guess about the cause. A live capture showed our outgoing traffic reaching him cleanly, and the router’s own connection log showed real two-way traffic — but the node’s own link table showed no active session, and the router’s routing table was missing the exact route that carried this traffic during the original fix two weeks ago. In its place was a narrower, unexplained route with no record of who added it or when.

Fix: restored the missing route. Minutes later, after a live connect attempt, the link showed active on our side, and his own link-status page listed both of our stations as established too.

Also added: automatic monitoring so this exact route disappearing again — or a broader drop in the number of active radio-IP links generally — triggers an alert and a tracker entry on its own next time, instead of waiting for a station operator to notice and report it.

Honest note: this is the second time in two weeks this specific router route has silently vanished with no record of the change. Restoring it fixed the symptom; what keeps removing it is still unknown.

Five More Mail-Forwarding Partners Had the Same Name Mismatch — Scripts Corrected, One Already Working Again (Sept. 21, 2026)

Why: the fix that revived forwarding to N9PMO (dial the exact name the node is mapped under, then ask for the BBS) applies to any partner whose script used a shorter or different name. Reviewing five days of logs, five partners failed every single attempt while their script dialed a name that differed from a real map entry and a mapped name existed to switch to. Partners that work today through an already-open link, or that already dial the exact name, were deliberately left alone.

Changed (one line each, backup first, node stopped while editing because it saves its in-memory copy on shutdown): GM3YEW, KC9AKP, W9ECG, VE3BWM and NC8Q now dial their mapped name and then the BBS. NC8Q had failed 92 of 92 attempts over five days; the very next attempt connected and completed a full exchange. KC9AKP now sends its connect requests and gets no answer (that station is not being heard at all and looks offline). GM3YEW’s dynamic hostname no longer resolves, so that station is probably gone. W9ECG and VE3BWM then ran and failed too: their dynamic hostnames no longer resolve, so those stations look gone as well. A short separate notice was prepared for each of the four stations asking whether they are still active.

Left alone on purpose: partners that work through persistent links (N8FWD, K3CLM, PY2BIL, N3FUD, WW6Q); partners already dialing the exact name that still fail for another reason, likely offline (KC8KPM, VK7AX); and three with no map entry at all (W9GM, KM9G, KD8FTR), which cannot work over this port until someone supplies their address.

Blog Automation for All Seven Sites Upgraded and Made Safer — Answer-Engine Formatting Now Actually Running Everywhere (Sept. 21, 2026)

What was wrong: six of the seven sites’ weekly-style blog writers were still running the old version. The improved version (a direct answer up front, question-style headings, a three-question FAQ with matching search-engine markup) had been saved on Sept. 5 but never published, so only one site had it. Even there, one post lost its search markup because the AI skipped an extra data line, and a stray script tag inside an answer could in theory have broken the page.

Fix: the markup is now built from the FAQ that is actually visible in the article, so it always matches what readers see and no longer depends on the AI adding a data line; the text is escaped so nothing an answer says can break out of its tag; and the length limit was raised so the FAQ has room. Nine offline tests passed first, including a deliberately hostile answer and a missing-data-line case. All seven were then published, the automation server restarted, and each was checked: new version live, schedule unchanged, and the record of when each site last posted preserved (so nobody posts early). Posts still arrive as drafts for your review, on the same two-week schedule (next due the week of Sept. 28).

Honest notes: the safety checks stopped the first publish attempt until you gave a specific go-ahead. The restart happened to land exactly on a scheduled radio-mail monitor run, which failed once for that reason; the next run confirms it recovered. Not yet done: a small broken WordPress plugin on one site.

URONode Restarted After It Stopped Answering the Network; Its Full Log Disk Cleaned Up (Sept. 21, 2026)

Symptom: the URONode virtual machine showed as running but did not answer pings or logins, although it still logged radio traffic. A hard reset brought it back: FlexNet started before MSYS as required, the node services came up, and it is again hearing stations on its radio ports.

Cause not found, but there is a clear lead: the machine’s own logs show that at about 2:45 a.m. its system logging stopped completely and every service that needs a network connection (such as the mail polling) stopped being answered, about 14 hours before the reset, while the radio-over-internet side and scheduled jobs kept running. The disk was not full and nothing in the logs explains the change. Separately, I found a disk-hygiene problem: its logs had grown to about 5.5 GB and the log partition was 88% full. Log rotation had quietly stopped in April when that disk filled, and two chatty sources were producing about 11,000 lines an hour (a harmless repeating error from the monitoring service, more than 3 million times since May, plus per-packet lines from the radio-over-internet daemons). This housekeeping is good practice but is not shown to have caused the outage, since the disk was never full.

Fix: deleted four five-month-old rotated logs (about 1.5 GB), forced rotation, compressed the rotated files, and added a filter that drops the two noise sources. The log partition went from 88% to 21% and the log rate dropped sharply; nothing that carries mail or radio traffic was touched. One trade-off: the filter also hides those two daemons’ own messages, so if the radio-over-internet link ever misbehaves, remove the filter to see them again.

Packet Radio Mail Forwarding to N9PMO Fixed — The Forward Script Dialed a Name the Node Would Not Start a Link For (Sept. 21, 2026)

Symptom: N9PMO could connect in and mail flowed that way, but every attempt to connect out and forward to him timed out after about 16 seconds. Over five days 73 of 86 attempts failed, while other partners with similar setups (N8FWD, K3CLM, N2NOV) had none.

Cause (found by watching the radio traffic on the wire and the node’s live link table while you fired forwards): the forward script told the node to connect to n9pmo, but the node is mapped as n9pmo-2. With no link already open, the node sent nothing at all for the shorter name. When his node happened to have opened a link to us, the shorter name rode that link and worked, which is why forwards succeeded on some days. Your own test proved it: connecting to n9pmo-2 worked immediately, and connecting to n9pmo worked once a link to n9pmo-2 existed. No separate map entry was needed.

Fix: the script now dials n9pmo-2 and then the BBS. The next forward connected, sent the waiting message, his BBS accepted it, and the session closed cleanly in about three seconds. Other partners with the same name mismatch and constant failures (two others) may need the same one-line change.

Earlier finding, real but not the cause: a router rule from Sept. 7 stamped the node’s 44Net identity on outgoing traffic to all destinations, not just 44Net ones. It was restricted and the stale router entries cleared; his packets now return on the outgoing path. But the forwards still failed afterwards, so my first write-up naming it as the cause was wrong. It probably did affect other internet peers.

Honest notes: I first blamed a station-name mismatch, you said a separate map is never needed (right about the map; the script mismatch was the answer). I later called the router rule the root cause and said mail transfer was confirmed before I had verified it. The forward script for N9PMO was also blanked in the BBS configuration at 22:30 UTC. You found the trigger: it happens when the Forward button in that partner’s block is clicked (it happened again to another partner at 23:03 UTC, and was restored the same way); it was restored, my restart briefly re-blanked it (the node saves its in-memory copy on shutdown, so edit the file only while it is stopped), and it was set right. Open question: you used the shorter name for years, so something changed. A full report for N9PMO and G8BPQ is in the uploads folder.

HARDS Newsletter Repaired and Greatly Expanded — Indiana, National and World Ham News, Events and Exam Sessions (Sept. 21, 2026)

It was broken. The monthly newsletter workflow would have failed on Oct. 1 (and probably already failed on Sept. 1): its file-handling step pointed at “this machine,” which stopped meaning anything once the automation server moved into Docker, and its four small helper scripts had lived on the old container that no longer exists. The scripts were recovered from the Sept. 9 backup of that container, the conversion tools (Word and PDF) were installed on the automation server, and the workflow was pointed at the working login. Its research step was also silently broken: the AI agent was calling its web-search tool with an empty query, so nothing was ever searched.

Expanded, as requested: a new automatic collection stage (no AI involved) now gathers real, dated material every issue — a statewide Indiana ham radio site’s events and news feeds (upcoming hamfests and operating events with venues, hosts and hours; club, emergency-communications and section news) and its license-exam session list; ARRL and Amateur Radio Newsline; RSGB and IARU; DX World; AMSAT; the WA7BNM contest calendar; and NOAA’s live solar and geomagnetic numbers — plus fourteen targeted web searches (Indiana, Midwest, FCC, and the technical topics). Every fact reaches the writer with its source link. A test issue came out at about 1,850 words with 12 Indiana events, 10 exam sessions, 7 Indiana stories, national, world, DX and contest sections and live propagation numbers, every claim cited. Where nothing real was found the issue says so rather than inventing.

Design choices that mattered: the AI provider allows 8,000 tokens per minute, so the writing is split into three focused writers (Indiana; technical topics; national/world/DX and the editor’s note) with 45-second pauses. The Word/PDF and packet-radio versions had formatting defects that were fixed: every section and all of its events had merged into a single Word paragraph; the packet file contained 243 non-ASCII characters and lines up to 356 characters. Now the packet version is pure ASCII wrapped at 72 columns (only lone URLs run longer), and the Word file has real headings and paragraphs. The Gmail login used for the review emails had expired; the owner reconnected it, and the workflow now still saves the files if that step ever fails.

Testing: four full test issues were run (each emails two “Review Needed” drafts, so several test emails are in the inbox — ignore them); the issue counter was reset each time so October’s real issue is number 13. A sample of the final test issue (PDF, Word and packet text) is in the handoff folder. Not yet done: the first real scheduled run (Oct. 1); HARDS club news must still be added by hand, since no automated source exists for it.

Home DNS Server Was Silently Dropping Lookups — One Rate Limit Shared by the Whole Network, Now Raised (Sept. 21, 2026)

Random “temporary failure in name resolution” errors were hitting the automation server (weather and crypto lookups) about 200 times in six days, in bursts. The obvious fix I first proposed — pointing the automation container straight at the home DNS server — tested worse, which led to the real cause: the DNS server (AdGuard) allowed only 20 queries per second for the entire home network combined, and silently dropped everything above that. A burst test of 80 parallel lookups got only 20 answered and 60 dropped, so any moment when devices collectively asked for more than 20 names in a second, some lookups simply timed out.

Fixed by raising the limit to 300 queries per second per device. Because this affects DNS for the whole home, it was done carefully: config backed up, the ad-blocking allowlist counted before and after (222 allow rules and 361 rule lines, unchanged), the file edited only while the service was stopped so it could not overwrite the change, and only two lines differ. Verified afterward: the same 80-query burst now gets all 80 answered in under a second, ad blocking still works, and internal names still resolve. A separate brief internet blip that stalled all upstream resolvers for about 20 seconds was also found in the logs; that one is an outside-connectivity event, not a setting.

Automation Server Diagnosed: Five Workflows Were Running Outdated Published Copies — Crypto Page, Weather Alerts and More Fixed (Sept. 21, 2026)

Asked to diagnose errors on the automation server before fixing anything, so the first deliverable was a read-only report. Overall it was healthy (about 10,500 successful runs against 14 errors in a week); the errors traced to two causes plus one memory crash. Main cause: the scheduler runs each workflow’s published copy, not the copy you edit and save. When password logins were switched off on the packet-radio server on Sept. 9, the saved copies were corrected to key-based login, but the published copies were never re-published, so scheduled runs kept trying passwords and failing. That silently broke the every-4-hours crypto price refresh and the Monday 6 AM crypto page (which is why it did not update Monday morning and had to be run by hand), and left the two storm-alert workflows latently broken. The same lesson as earlier n8n work: an edit does not reach the scheduler until it is published and the server restarted.

Fix, done carefully: full database and workflow backups first; reviewed the exact differences for each workflow, which caught a trap — the saved weather drafts had lost their “every 5 minutes” setting, so publishing as-is could have changed their behavior; put the explicit 5 back; imported, published and restarted. Verified with real scheduled runs: both weather workflows succeeded on their normal schedule, and the 4-hourly crypto refresh succeeded at its 20:00 UTC scheduled time and rewrote its data file. Also done: execution history raised from about 30 hours to roughly 5–6 days so future failures can actually be investigated; a stuck test run cleared; and a slow memory leak (about 15 MB an hour, crashing the server every 3–4 days at its 2 GB limit) is now handled by a logged, automatic restart every day at 3:47 AM local time, proven by running it once.

Honest notes: I could not identify which workflow leaks memory; the daily restart is a mitigation, not a cure. Two of my own command slips during the work (a self-matching process kill and a folder-permission mistake) were caught by chaining steps so nothing ran after a failure; no data was affected.

Ebook Series on Gumroad: All 17 Listings Verified Live, Covers Added to Every One, and the Ebook Store Now Cross-Links to Them (Sept. 21, 2026)

Started from a simple question — “how do I find my books on Gumroad?” — because none had been seen there. Investigation showed all 16 books plus the bundle were published: the store page’s own data reported 17 products with 16 EPUB and 16 PDF files, the seller dashboard listed all 17 as Published, and every one of the 17 public product pages loaded. The books only looked missing because the store page draws the first nine and loads the rest as you scroll. (My first pass wrongly concluded eight were missing after reading only that first batch, and briefly mis-read prices because the data is in cents; both were caught and corrected.) The real gap was that no listing had a cover image — each page showed text only, a gap left over from the original rollout.

Covers. Upload-ready versions of every cover were prepared — a wide image for each product page and a square thumbnail for the store grid, over a blurred backdrop of the cover art, plus one preview sheet showing all 17 together. Gumroad’s public documentation lists no way to attach covers, but probing showed the API does have cover and thumbnail routes. The method was tested on a single book first, comparing the product before and after (only the cover fields changed; price, files, description and published status were identical), then applied to the other 16 with the same before-and-after check on each, stopping at the first problem. Every public page now serves a Gumroad-hosted cover that loads, the store grid shows thumbnails, and the owner confirmed they look right. The images were hosted temporarily on the ebook store’s server so Gumroad could fetch them once; that folder was removed afterward.

Cross-linking the ebook store. A small custom plugin now adds an “Also available on Gumroad” link under the Add to Cart button on each of the 17 book pages (each linking to that book’s own Gumroad page), and a small “our books are also on Gumroad” line at the bottom of every page. It was syntax-checked before installing, verified on all 17 book pages plus the homepage and shop page with no server errors, and is undone by deleting one file. Cleanup: the temporary API token was kept in a private file only while working, then securely deleted, and the owner was asked to regenerate it.

Ebook Series Moved Into a Private Source Repository With Automatic Checks — Second Runner Added, All 16 Books Pass (Sept. 21, 2026)

Followed the first self-hosted runner setup (TASK 347) with a second private GitHub repository for the 16-book ebook series. It holds the Markdown sources, the checker, and the PDF-bookmark script; the built EPUB and PDF files (the sellable products) and the cover artwork are deliberately kept out. A workflow on the homelab runner checks every push: chapters must run 1 to N with no gaps or duplicates (the exact defect class that once left three books missing a chapter each), plus per-book word counts, empty headings, and high-confidence secret patterns such as private-key blocks and access tokens. Missing images are only warnings, since the artwork lives elsewhere. The checker was tested first on deliberately broken copies — a removed chapter, a duplicate chapter, an empty heading and a fake token were each caught — and then run for real on the runner: all 16 books passed with zero errors (about 495,000 words, every chapter present and in order).

Because a runner registered to one repository only serves that repository, a second runner was added on the same container, unpacked and run as the unprivileged runner user, with its download checked against GitHub’s published checksum; both runners are enabled at boot. A broader content scan of all 16 books (emails, domains, hardware addresses, keys, phone numbers, host names) found nothing that needed changing. One correction along the way: an earlier version of that scan gave a false “zero hits” because of a counting mistake, which was caught and redone properly. Decisions recorded: no cover images in the repository, and the books stay as published. The GitHub login used for setup was removed from the automation side afterwards.

Self-Hosted GitHub Actions Runner Live — Private CI on the Homelab, Verified With Real Workflows (Sept. 21, 2026)

Turned the dedicated runner container (built earlier, working Docker, but left unregistered because no repository had been chosen) into a live self-hosted GitHub Actions runner, so checks triggered by code changes run on the homelab instead of on GitHub’s servers. Created the GitHub account (two-factor authentication on, backup codes kept out of any repository), a private repository for version-controlled, sanitized homelab configs, and a lint workflow that checks shell scripts, YAML and JSON, fails on committed secrets, and only warns on real internal addresses. The runner was registered, installed as a boot-persistent service, and GitHub shows it online; a manual test workflow and the lint workflow both ran successfully, and their logs confirm they executed on the homelab machine, not GitHub’s. Before trusting the lint workflow it was tested against a throwaway repository: clean input passed every step, and deliberately injected faults (an unsafe shell command, broken YAML, invalid JSON, a fake password, an internal address) were each caught by the right check.

Friction and fixes. The operator’s interface cannot copy text out of the chat, so setup files were delivered as downloads instead of code blocks. GitHub’s web uploader silently drops files with dot-prefixed names, so the files were uploaded under plain names and renamed on the site. Instead of pasting a long registration token, authentication used a short one-time device code typed by hand, and the stored login on the automation side was removed afterwards. Two self-inflicted slips were caught and fixed: an early diagnostic run as root left a root-owned log folder that broke registration, and a permissions change during testing briefly made the temp folder non-writable (restored immediately). A staged upload list briefly contained the GitHub backup-codes file; it was removed before committing and the repository file list verified clean.

Ground rules going forward: private repositories only (a public repository would let strangers run code on a machine on the home network), no secrets or real internal addresses in repositories, no workflows for fork pull requests. Cost note: GitHub has announced and postponed changes to self-hosted runner billing, so pricing should be re-checked before assuming this stays free.

3rd Tesla P4 → Plex Consolidation — Cancelled, Both Plex Servers Stay

Decided Sept. 21, 2026 (EDT) not to pursue the plan to consolidate Plex onto the virtualization host and retire the Windows desktop. Plex stays on the desktop, and the virtualization host keeps its own separate Plex; the two run independently and are both active. The desktop also now serves as the remote graphics-card worker for the GPU pool (see TASK 346), so retiring it would have removed that as well. Moved out of “On Your Bench” since nothing is waiting on this anymore.

Three-GPU llama.cpp Pool Restored, Made Cold-Boot-Proof, and Proven With a Real 500-Token Inference — Completed Sept. 21, 2026 (EDT)

Finished the project of pooling three graphics cards across two machines — two in the AI server VM on the virtualization host, one in the Windows desktop’s Linux (WSL2) environment — using llama.cpp’s RPC backend, so a 27-billion-parameter model that will not fit on two cards can run entirely on GPUs. The machines talk to each other across the homelab fiber network. The pool had stopped working because the two halves were built from different llama.cpp source versions: the connection opened, so a simple “is the port open?” test passed, but the protocol handshake silently failed. Fixed by building a separate, exactly matching copy on the AI server (the original was left untouched).

Windows cold-boot automation. The desktop’s worker used to depend on a terminal window staying open, and Windows’ WSL2 networking hands the Linux side a different internal address on every restart, which silently breaks the port forward that carries the traffic. A scheduled task now runs at Windows boot with no interactive login: it starts and holds WSL open, waits for systemd, verifies (and restarts if needed) the worker service, reads the current internal address, recreates the port forward, and keeps monitoring — re-pointing it if the address ever changes — with a persistent startup log. The worker service restarts itself on failure, and the firewall opening is limited to the home LAN. The installer was generated here, but run by the owner directly on the Windows machine.

On-demand by design. The AI-server side deliberately does not start at boot, because it would hold both of its local cards and starve the everyday Ollama / Open WebUI service. Three commands control it: start, stop, and status. Start refuses to interrupt Ollama when a model is loaded unless deliberately forced; stop releases both cards straight back to Ollama. The Windows worker can stay running and idle in the meantime.

Verified for real, not just “port tested.” (1) A true cold reboot of the Windows machine with nobody logged in; the startup log showed systemd running, the worker active and enabled, the port forward rebuilt, and both Windows-side and direct Linux-side connections succeeding, ending in a SUCCESS result. (2) Working connectivity from the AI server. (3) A real chat request generating 500 tokens at about 6.0 tokens/second in roughly 1 minute 30 seconds — versus about 3.25 for the old two-card setup (earlier runs measured 5.8–6.3). (4) Memory and process activity confirmed on all three cards: about 5.7–6.1 GiB on each of the two local cards, and about 5.5 GiB on the remote card at roughly 27 W with the worker process visible. (5) A clean shutdown: service inactive, both local cards back at 0 MiB, no Ollama model loaded, so Ollama and Open WebUI reclaim the cards normally.

Related cleanup. An Open WebUI automation set to run every five minutes had been quietly keeping Ollama busy and creating hundreds of unnecessary chats — which also made the pool refuse to start — and has been paused. A login credential that was exposed and reused during this work was rotated after testing. No credentials are recorded here.

Local-AI Server Disk Expanded From 96% Full to 48% — and a Redundant GPU-Clustering Plan Dropped Before Anything Was Built

Started from a hand-off brief to stand up a second GPU-clustering framework across the graphics cards in the virtualization host and a desktop PC. Checked the live environment before building anything and found two problems with the brief. First, the cards were already attached exclusively to the local-AI server VM through hardware passthrough, and a card can only belong to one VM or container at a time, so building the container the brief described would have meant taking the live model server (which backs the family chat interface) offline. Second, the llama.cpp RPC pooling approach chosen and benchmarked on 2026-09-17 already does exactly what the brief wanted: three cards pooled into one inference cluster at 5.6 tokens/sec versus a 3.25 baseline. Stopped and asked instead of proceeding; the first answer was to install the second framework inside the existing VM, and then the user pointed out that once llama.cpp was chosen there was no reason for it at all. Correct call, and nothing was installed or changed for that part.

The one real change was the disk. The server’s root filesystem was 96% full, which would have limited how many models it could keep. The virtual disk was already 768GB but the partition on it was only 256GB, with the rest unallocated, so no change was needed on the hypervisor at all. Backed up the partition table, ran a dry run first, then grew the partition to 512GB (same start sector, so no data moved) and resized the filesystem while it was mounted and in use — no reboot. Verified afterward that the model server was still running and both graphics cards were still visible. Result: 230GB used of about 504GB (48%), with another 256GB still unallocated if more is ever wanted. Follow-up: the RPC worker’s auto-start and cold-boot recovery were completed in TASK 346.

Ebook Store’s Category List Was Invisible on Phones — Present in the Page, Just Rendered at Zero Size

User reported a specific category wasn’t showing up in the phone version of the shop, even though it was right there on desktop. Turned out the entire category list (not just that one entry) was genuinely present in the page’s underlying content on mobile, but a responsive-visibility setting on the sidebar module was collapsing it to zero width and height — invisible, not missing. Took some real digging to actually fix rather than just diagnose: the site’s design tool caches its generated styling in several different files that don’t reliably rebuild themselves just from changing the underlying setting, and the specific rule doing the hiding used a much more specific style selector than a first attempt at overriding it, so the override kept silently losing. Traced it down to the exact competing rule, matched its specificity precisely, and confirmed with real browser screenshots (not just style inspection) that the full category list, including the one originally reported missing, now displays properly on mobile on both the shop page and individual category pages, matching what desktop visitors have always seen. 2026.09.18.

Home VPN Was Missing General Internet Access — Fixed a Router Gap From Setup, Ruled Out a Wrong IPv6 Lead First

Phone couldn’t reach any of the self-hosted sites while connected to the personal back-to-home VPN, even though the exact same sites loaded fine on desktop and on the phone with the VPN turned off entirely — that last comparison was the key piece of evidence that pinned the problem specifically to the VPN tunnel rather than the sites themselves. First pursued a real but ultimately wrong lead: the phone’s tunnel profile was missing an IPv6 address that sibling devices on the same VPN already had, which lined up suspiciously well with the specific sites failing (the ones with modern CDN/IPv6 support) versus one that worked fine (an older, IPv4-only site) — added the missing address on both the router and the phone’s own app, but it made no difference, and further checking confirmed why: that address family was only ever meant for local addressing within the VPN, never capable of reaching the public internet regardless of configuration, so it was a dead end from the start. Went back to basics and found the real gap: the router had a working internet-access rule for one of its two VPN setups, but the personal back-to-home VPN was simply never given the equivalent rule when it was first configured, so its clients had a path into the home network but no path onward to the wider internet at all. Added the missing rule and confirmed it live, watching traffic counters move as the exact connection succeeded in real time. Also broadened a separate router rule (the one letting VPN clients reach the home network’s own public-facing address without a routing loop) to cover this VPN’s address range, which it had been quietly missing too. 2026.09.18.

Ebook Store’s Mobile Header Had Overlapping Text — Root Cause Was Different Than First Suspected

A hand-off spec described the likely cause as two separate title elements stacked on top of each other on the shop’s category pages. Investigation on a real device viewport (installed an actual browser engine in this environment specifically to see the rendered page, since reasoning from raw page markup alone wasn’t going to catch this) showed something more specific: it was one single element, a category-name label styled at a very large size for the page banner, wrapping onto three lines on narrow screens with far too little space between those lines — fine on desktop where it fit on one line, broken wherever it had to wrap. Fixed with a mobile-specific style rule sized correctly for the wrapped state, added through the site design tool’s own custom-styling panel rather than hardcoded into theme files, so it survives future theme updates and stays editable. Verified against multiple different category pages to confirm the fix applies sitewide through the shared page template, not just the one page originally reported. 2026.09.18.

booksrus.biz’s SEO Plugin Was Silently Failing on Every Post Save — Two Missing Database Tables, Now Fixed

Spotted a wall of database errors firing every time a product or post got saved on the ebook store — the SEO plugin’s internal link-counting feature was trying to write to two database tables that had never actually been created on this site, most likely because a step in the plugin’s original setup never ran. The failures were silent from a visitor’s standpoint and nothing was corrupted — the writes simply failed and got skipped — but they’d evidently been happening in the background on every save for a while, including several done earlier in today’s session without ever being noticed until a screenshot caught the raw error output directly. Rather than hand-write the missing tables, called the plugin’s own built-in table-creation routine, which checks for already-existing tables before creating anything so nothing already in place was touched. Verified by re-saving a real product afterward and confirming the errors are gone. 2026.09.18.

Dropped a Long-Unsolved Automation Bug Instead of Continuing to Chase It

The reputation-monitoring automation built after the earlier registrar-hold incident checks two different blocklist services on a schedule and only emails an alert if a domain ever gets flagged; one of the two checks had never actually worked correctly since it was built, for reasons that resisted real debugging effort both at the time and again today. Rather than keep spending time chasing an unsolved bug in a secondary check, when the primary check already works fine on its own, decided to just remove the broken half entirely and keep the automation running with the half that works. Cleaned up thoroughly rather than just disabling it in place: removed the broken logic from the automation itself, deleted two now-unused stored credentials plus one leftover test artifact from the original investigation that had never been cleaned up, and updated notes accordingly so a future session doesn’t rediscover the same dead end. Confirmed nothing else in the wider automation setup depended on any of what was removed before finishing. 2026.09.15.

All Five Old Domains Now Redirect Properly — Plus a Self-Correction on One That Never Actually Worked

Closing follow-up on today’s domain migrations: converted every retired old domain to a server-level redirect straight to its new home, rather than relying on the WordPress software itself to notice and redirect — a server-level redirect works even if the site behind it is ever offline, slow, or reconfigured, so it’s the more durable choice for a domain that’s meant to just forward people onward forever. Two of the five old domains turned out to already be redirecting correctly on their own; the other two were serving up a full, live, identical copy of the new site under the old name instead of sending visitors onward, which is exactly the kind of duplicate-content situation search engines penalize — fixed both the same way. Caught and corrected a real mistake of my own while doing this: one of the two domains still stuck in the registrar hold from the earlier incident had genuinely never redirected at all, despite it looking that way earlier today — that earlier check had bypassed real public DNS entirely without realizing it, testing the server directly instead of the way an actual visitor would reach it. Once caught, verified honestly this time and confirmed that domain simply cannot be reached by anyone right now, hold or no hold, which also settles a separate question about whether the registrar’s nameserver settings could somehow interfere with anything — they can’t, and for the domain still on hold, it doesn’t matter what they’re set to either way. Set up the matching redirect for the second held domain anyway, inert for now but ready instantly if that hold is ever lifted. Confirmed the plain and “www.” version of every domain redirects correctly, with the original page path preserved on the way through (a deep link still lands on the equivalent page at the new address, not just the new homepage). 2026.09.15.

Rebranded Travel Site’s Header Banner and a Real Layout Bug, Plus a Live Multi-Edge Caching Lesson

Follow-up on one of the same-day site migrations: a reported leftover old-domain banner on the rebranded travel site turned out to be real, but invisible to every method used so far — it was baked into a theme-bundled background image referenced only from CSS, not a normal uploaded media file or page image, so no database check or image inventory ever turned it up. Got a real headless browser running in this environment specifically to see the actual rendered page rather than reasoning about raw HTML, which is what finally located it and also confirmed a second, genuine problem: the site’s navigation menu had grown long enough to wrap onto a second row, but the header box around it was never sized to expect that, so the wrapped row was landing right on top of the banner behind it. Fixed the banner text and redesigned it to match the site’s nav-bar color instead of clashing with it, then restructured the header layout so the navigation and the banner sit in their own separate, properly-sized spaces and can never overlap again regardless of how many rows the menu needs. Along the way, ran into a real lesson about the content delivery network in front of these sites: different geographic edge locations were independently caching different versions of the same file, so a fix confirmed live from one location could still show as broken from another — worked around it by publishing each fix under a brand-new file reference every edge would have to fetch fresh, rather than trusting a single spot-check. 2026.09.15.

Three More Sites Migrated to New Domains, Including a Full Rebrand and a Freshly Designed Logo

Same-day follow-up migrating three more self-hosted sites to new domains, one of them a genuine rebrand rather than just a domain swap — consolidating an older site under a new name entirely. Repeated the full chain for all three (DNS, certificate, reverse-proxy routing, web server entry, database domain swap) and, learning from earlier in the day, checked every logo and header graphic on each site directly rather than trusting a text search-and-replace to have caught everything — found and fixed the old domain baked into one site’s logo image, and a support-contact email hardcoded straight into another site’s live privacy-policy page (not stored as data, so invisible to any database-level fix). Since the rebranded site needed a new identity outright, designed a new logo for it from nothing — a circular badge in the site’s existing colors with a paw-print mark and the new name curved around the ring — then iterated on it twice more against live visual feedback once it was up (breathing room around the curved text, then again around the corner accents) until it looked right on the real page. Also hit the same newly-registered-domain block from the home network’s own ad-filtering DNS service that had already been solved once earlier the same day, on two of the three new domains this time — recognized immediately and fixed the same way. Full checkout flow verified on the rebranded site’s live storefront afterward. 2026.09.15.

Packet Radio Node Crash-Looping — Real Root Cause Found, Earlier Theory Corrected

The packet-radio BBS node had been restarting several times a day with no usable diagnostic output. Turned on a crash-logging wrapper that had been sitting available but unused, and the very next crash produced a full, symbolized crash report for the first time. It traced to a genuine bug in the node software itself — a memory-handling error inside its built-in webmail feature, triggered by an incoming web request, not a configuration problem on this end. That also corrected an earlier working theory (from a prior session) that had pointed at the remote sound-modem link as the likely trigger: checking the full crash-history log showed the modem-reconnect storm previously blamed was actually a downstream symptom — the abrupt crash leaves a stale connection behind, which then has to churn itself out on the next restart — not the cause. A plain restart cleared the immediate looping; the software was then rolled back one version to the last known-stable release (the newer one kept on hand for easy restoration) so it can be watched for a stretch before deciding whether to reapply the update. The crash detail has been packaged up to report back to the software’s developer. 2026.09.15.

Two Sites Escaped a Registrar Dead-End — Full Self-Hosted Migration to Fresh Domains

Two of the self-hosted sites had been stuck for two weeks on a registrar-side hold tied to an old security incident, with the registrar going nowhere; the call was made to give up on that path entirely and move both sites to brand-new domains instead. The handoff assumed DNS was already pointed at the home network — it wasn’t, so that had to be built from scratch first: DNS records, a real certificate, reverse-proxy routing, and a web server entry, the same four-layer chain every self-hosted site depends on. Migrated the database references for both sites, catching a class of leftover the usual text search-and-replace can never reach — one site had the old domain literally drawn into its logo image as pixels, and a leftover script from an earlier build had it hardcoded directly into page code rather than stored as data. Along the way, a raw database edit meant to fix one small reference instead corrupted a much larger block of one site’s saved theme settings (242 settings down to 10, including the logo reference itself) — caught immediately, the exact original value was recovered from earlier session output and restored intact, confirmed setting-by-setting. Also found and fixed two broken site-icon references left over from a much older build (one pointed at a deleted file, the other at an unrelated outside website). Both sites verified fully live over the real public path, checkout flow included, with the two abandoned domains now safe to let lapse. 2026.09.15.

Second False-Alert Gap Found via Alert-History Review — Solar Inverter Added to Known-Devices List

Went back through the presence monitor’s full available alert history (since its last reset) rather than just checking the present moment, to see if anything else had ever tripped a false unknown-device alert besides the smart TV from the previous tasks. Found exactly one more: a single overnight alert for a device sharing the same hostname and hardware-vendor signature as an already-trusted solar equipment entry on the list, but under a different hardware address — connected for a few hours, then went quiet and never reappeared. Rather than guess or silently add it, brought the specifics back to the user, who confirmed it immediately: a second inverter that reaches the network indirectly, bridged in over Ethernet through a WiFi extender rather than connecting to the main network directly — which is exactly why it shows up under its own separate hardware address instead of matching the already-known one. Added it to the known-devices list under a clearer name, and relabeled the original entry to match, since both had been sitting under a generic placeholder name from before either was fully identified. Deployed following the same safe procedure as before (export, edit, re-import, republish, restart) and confirmed the workflow came back up healthy and kept executing normally afterward; full alert-suppression behavior for this specific device will get its final live confirmation the next time it reconnects, since it wasn’t actively on the network at deploy time. 2026.09.14.

Known-Devices List Audited Fleet-Wide — No Further Gaps Found

After fixing the false alert in the previous task, went back and checked whether any other already-known hardware had the same gap. Cross-checked every device on the router’s internet-block list for smart TVs/players against the presence monitor’s own known-devices list directly — live, not from memory — and confirmed all of them are now covered, the TV from the previous task having been the only gap. Went further and checked every other statically-addressed device on the network too, in case something else was missing. Turned up a handful of internal automation/infrastructure services that also aren’t on the presence monitor’s list, but checked their actual real-world behavior rather than assuming a problem: confirmed none of them has ever actually registered as an active network client in the way the monitor checks for, so none of them can trigger the same false alert — no changes needed there. 2026.09.14.

WiFi Presence Monitor False Alert — Smart TV Added to Known-Devices List

The WiFi presence-monitoring automation fired a false critical “unknown device” alert for the smart TV that was identified and network-blocked under Task 329 — it had already been added to the router’s own device tracking, but was still missing from the separate known-devices list the presence monitor checks against, so it kept getting flagged as an unrecognized intruder every time it showed up on the network. Added it to that list, matching the format of the other trusted entries already there. Rather than trusting the edit alone — this automation has a known history of changes not reliably reaching the running workflow — exported, re-imported, republished, and restarted it, then verified against a real scheduled run afterward: confirmed the very next automated check saw the TV, matched it against the known-devices list, and raised no alert. 2026.09.14.

LinBPQ Weekly Backup — Root-Caused a 23-Hour Runtime, Added a Real Schedule, Cleaned Up a Stale Copy

A one-off manual backup of the LinBPQ box had taken nearly 24 hours to finish, and it turned out to have no standing schedule at all — it was never on any recurring job in the first place. Traced the slowness to its root cause rather than guessing: the backup was a full, block-by-block image of the entire drive, reading every byte of a large mostly-empty disk (under 2% actually used) instead of just the real data on it. A used-space-only imaging tool was tried first and looked like the obvious fix, but its build on this box’s old operating system turned out to be genuinely broken against a live, in-use drive. Switched approaches instead: back up the actual files directly, the same proven method already used successfully for the main server’s own backup, which only has to read the real data instead of the whole disk. Verified with a live test run against the real machine rather than trusting it on paper — watched it complete in roughly an hour instead of a full day. Put it on a standing weekly schedule going forward, timed to land the day after the existing full-fleet backup so the two don’t compete for the same shared drive. Also found and removed one leftover stale backup copy sitting outside its proper retention, after confirming a current, correctly-scheduled copy already existed elsewhere. 2026.09.13.

Smart TVs & Blu-ray Players Cut Off From the Internet — Network-Level Block Added as Defense-in-Depth

Added a hard network-layer block so every smart TV and Blu-ray player on the network loses direct internet access entirely, layered on top of the existing DNS-level ad/telemetry filtering and the per-TV tracking settings already turned off — a second, independent layer for the telemetry that ignores DNS filtering by calling hardcoded addresses directly. Identified every device carefully before touching anything: cross-checked ambiguous device names against their hardware manufacturer codes rather than guessing, which correctly ruled out a couple of look-alike devices that turned out to be unrelated smart-home gear, and confirmed every streaming-stick device by the same method to guarantee none of them could ever end up on the block list. Final list came together in stages as more devices were powered on and identified live, including one device whose reported identity changed partway through and had to be re-confirmed directly from its own on-screen network settings rather than trusted secondhand. Converted every device to a fixed address, built a dedicated address list for them, and added one new rule ahead of everything else already in place, touching nothing existing. Verified the rule was actually live, not just present, by watching it silently drop real outbound attempts in the router’s own log within a minute of going in, then had the household confirm normal casting/remote-control behavior between devices still worked normally afterward. 2026.09.13.

Home Assistant Router Integration — Firewall Trap Found and Fixed, New Network Dashboard Section

Investigated why a newly-added router-monitoring integration in Home Assistant kept losing its connection to the main router. Found an undocumented brute-force-style trap on the router’s remote-management ports — structurally identical to a known one already found on the SSH port months earlier: any first connection attempt from a new source gets silently flagged, and any second attempt within 24 hours is dropped. That meant the very integration meant to monitor the router was locking itself out on its own first try. Confirmed directly that the monitoring source was already sitting on the router’s internal block list at the time of investigation, not just inferred from the symptom. Fixed with one narrow, additive rule — nothing existing was touched, moved, or disabled — that lets the monitoring connection through before it ever reaches the trap, then proved it end to end with a real, live, established connection and rising traffic counters, not just a green status light in the app. The two network switches needed no fix at all: confirmed they had no firewall rules blocking anything in the first place, rather than assuming so. Finished by adding a new section to the rebuilt Home Assistant dashboard’s Network tab showing live health (processor load, temperature, memory, uptime, connected-device count) for the router and both switches, then reordered it higher on the page per request. 2026.09.12.

Homelab Status Dashboard Fixed for Real — Traced Generic Labels to a Genuine Dead Dependency, Not a Display Bug

Asked to make the public automations-health dashboard stop showing several entries as warnings, and to restore the real automation names that had deliberately been withheld. Investigated before changing anything: the generic labels and the “never run” flags turned out to be reporting real, accurate data the whole time — the dashboard was working correctly, just under-explained. Restored the real names per explicit request, and added a third, calmer status for the automations that are genuinely supposed to sit idle most of the time (things that only fire on a real event, a one-time future date, or a monthly/weekly schedule) so they no longer look like failures next to the ones that run constantly. One case turned out to be a real, ongoing failure hiding in plain sight: a fitness-data automation had failed on every single run since early that morning. Traced it back to an old internal dependency that had been quietly powered off, migrated the whole thing onto current infrastructure so that dependency is gone for good, and finished with a live re-authentication of the fitness account’s connection, verified against real data. Also cleared out one leftover diagnostic automation from an earlier troubleshooting session that no longer serves any purpose. 2026.09.11.

n8n Moved to Docker on Its VM — and Why a “Simple Point Upgrade” Wasn’t

The automation server (n8n on its dedicated VM) had been sitting a few versions behind, with a long-standing plan to containerize it “once n8n 3.0 ships.” Started as a routine point upgrade to the latest current-line release and it turned into a real project: the upgrade failed twice on the plain install — first because the VM was missing a compiler toolchain a new dependency needs, then because every n8n release past a certain point now requires a newer Node.js runtime than the VM had. Rather than chase that (upgrading the runtime rebuilds every native component and just resets the same clock for next time), pivoted to the Docker move that was always the endgame — the container ships its own runtime, so the host’s version stops mattering. Also grew the VM’s disk (it was down to under 5 GB free) and cleared ~3 GB of stale database backups out of the live data folder first. Cut over on the exact same n8n version as before (prove the data, mounts, and public routing all survive), verified end to end: all 42 workflows present, 40 active, a real live webhook round-trip through the full public path, credentials still decrypting. One self-inflicted snag along the way (a container path setting that made n8n briefly write to a throwaway database instead of the real one — caught immediately, real data never touched, fixed by running the container the way the image expects). Old plain install left disabled-but-intact as a one-command rollback. Net result: n8n is current-architecture now, and actually getting onto a newer version is a one-line change instead of a runtime migration. Total real downtime for the cutover itself was about 4 minutes. 2026.09.10.

Home v2 — Rooms View Added, Plus a Real Area-Model Cleanup

Added a “Rooms” view to the new Home Assistant dashboard: a section per physical room with the TVs, Blu-ray, and PCs in that room as playback/volume control cards. Building it surfaced two things wrong in the underlying room model that the user corrected: two separate areas (“Bedroom” and “Bedroom East”) were actually the same physical room, and a desktop PC was filed under the bedroom when it’s really in the radio room. Consolidated the duplicate area down to one (moved its five devices over, then deleted the now-empty area — 11 rooms down to 10) and relocated the PC to the radio room. Final Rooms view: Living Room, Bedroom, Bedroom West, Radio Room. 2026.09.10.

Home v2 Follow-up Pass — Weather Station, Grid Flow, Energy-Dashboard Bug Fix, Default Swap, Lightning Range

A round of tweaks to the new Home Assistant dashboard after the user lived with it a bit: added the outdoor weather-station readings (temp, humidity, barometric pressure, wind, rain) and a 48-hour pressure/temperature trend onto the same page as the lightning detector, so approaching-weather signals are all in one place; added a “grid flow” block (power drawn from vs. sent back to the utility, today and month-to-date, with running cost/credit) to the energy page. Found and fixed a real bug in Home Assistant’s built-in Energy dashboard: its “energy from the grid” source was wired to the solar array’s lifetime-production total instead of the actual grid-import meter, which would massively inflate the consumption figures — repointed it to the correct meters and consolidated a redundant duplicate source. Renamed the original dashboard to “Home V1” (kept fully intact, still one click away) and set the new one as the default landing page. Finally, widened the lightning detector’s alert radius from 20 miles to 120 — a direct strike can reach the antenna farm from a storm still well outside a 20-mile ring, so the wider radius buys real time to disconnect. 2026.09.10.

Home Assistant Dashboard Rebuilt From Scratch — “Home v2”

Reviewed the existing Home Assistant dashboard end-to-end and rebuilt it as a clean, separate dashboard (the old one left fully intact for side-by-side comparison). The old dashboard was 12 loosely-organized views on the legacy layout — a mix of per-room, per-person, per-device and per-system with no consistent scheme, a “junk drawer” view mixing a printer, reset buttons and ~150 fitness sensors dumped into one card, two mislabeled views, and a 24-card wall of near-identical energy cards. The new one is 8 focused views on the modern sections layout: Home overview, Energy, Climate, Storms/lightning, Propagation, Network, Media, and a curated Health view. Along the way: installed three well-known dashboard card add-ons, fixed the room assignments for three TVs, and cleaned up a computer that had accidentally been registered twice. Also determined that the pile of “ghost” media players wasn’t deletable clutter — it’s two audio integrations legitimately re-exposing the same real devices — so the new Media view just auto-hides whatever’s offline instead. 2026.09.10.

Accidental Home Assistant Restore — Full Recovery + Garmin / Appliance Re-auth

Mid-project, a two-day-old Home Assistant backup was restored by mistake, rolling back everything from TASK 322 plus the access token, and Home Assistant then took an unusually long time to come back (the restore rebuilds the database and add-ons; it needed a manual core start and a look at the logs to confirm it wasn’t crash-looping). Once it was back: re-issued the access token, then re-applied the whole dashboard rebuild from saved copies — the three card add-ons, the 8-view dashboard, the TV room assignments, the duplicate-computer cleanup — and re-validated every entity reference against the restored system. The restore also broke two integrations that needed re-authentication: the smart washer/dryer recovered on its own (its earlier fix lived on a separate box the restore didn’t touch), and Garmin Connect needed a manual re-login, which required clearing a security checkpoint on Garmin’s side first before the two-factor code would take. Confirmed both fully working afterward (live fitness data flowing again). The Garmin password had been shared in chat during troubleshooting, so it was rotated as a precaution. Also added a proper lightning map to the new dashboard while in there — the old map card could never show strikes because it wasn’t wired to the lightning data source. 2026.09.10.

Full Proxmox Backup Pipeline Built From Scratch — Fleet, Host OS, and a Standing Weekly Schedule

No backup of the Proxmox host or anything running on it existed before this project. Built a complete external-drive backup pipeline from the ground up across two dedicated USB drives, surviving several real infrastructure problems along the way rather than hiding them: an incompatible filesystem was initially used as a staging area for container backups and had to be swapped out after it silently refused to preserve file ownership; two different drives offered up for the second half of the project turned out to still hold real personal files and were left untouched rather than wiped on assumption; and a live VM backup aborted partway through when a second drive was inserted into the same dock and briefly disrupted the USB bus — confirmed, not guessed, when the exact same disruption happened again to an unrelated file transfer minutes later. Also found and cleaned up a leftover runaway process from that aborted attempt that had been quietly sitting idle for over an hour holding open a large stale partial file. End result: every virtual machine and container backed up successfully, plus a separate, verified backup of the host’s own operating system drive via a live filesystem snapshot (no downtime, no reboot). Both pieces are now on a standing weekly schedule going forward — no more manual runs needed — staggered so they don’t collide with each other on the shared drive dock, with automatic pruning of old backups and a built-in integrity check on the host OS backup so a corrupted week gets caught and discarded rather than silently kept. 2026.09.09.

Concurrent SSH Connection Collisions — Root-Caused and Fixed via Staggered Automation Schedules

Even after every affected automation workflow (see TASK 319) had its dead credential swapped to a working one, several kept intermittently failing with the exact same authentication error — a genuine puzzle since the credential itself was proven working elsewhere. Pulled every relevant workflow’s actual trigger schedule directly rather than guessing, and found the real cause: several ran on identical, unaligned intervals (multiple every-15-minutes workflows all firing at the literal same wall-clock second, one every-single-minute, one every 30 seconds, one every 20 minutes) — a structural collision, not a fluke, confirmed by watching a live failure repeat at the very next shared tick. Fixed by converting each affected trigger from a plain interval to an explicit offset schedule, spreading them across different minutes (and one across different seconds) of the hour so their connections no longer land simultaneously. Confirmed properly this time rather than assumed: watched multiple real firing cycles complete clean across all of them before calling it done, and caught one more (the Garmin pipeline) that looked fixed on an earlier spot-check but was still colliding on its own unstaggered cycle — found via a fail/success/fail pattern across its last three natural runs, not assumed fine from one lucky success. 2026.09.09.

SSH-Hardening Collateral, Round 2 — 9 More Automations Fixed, One Real New Exposure Found

The credential-lockout pattern from TASK 317 turned out to be far wider than first caught — a full audit of every automation workflow turned up 9 more still pointing at the same dead password credential, some already failing outright, some on borrowed time since their SSH step simply hadn’t been exercised yet. All 9 fixed with the same credential swap, verified individually against the database rather than assumed from the UI alone. Separately, a second independent security re-review of the whole site came back with a long list of alarming-sounding claims — verified every one directly rather than trusting the report, and nearly all of it didn’t hold up (no exposed data found on re-check, no errors reproduced on the flagged pages) likely from catching this same session’s own restart activity mid-window. One genuine, previously-unaddressed finding did survive: the live network-status dashboard was showing real internal addresses for two access points in its bridge-status card — unlike the pages sanitized in TASK 313–316, this one was never in scope since it’s a functional live tool, not a static reference page. Fixed by swapping to generic role labels; confirmed clean on the live page afterward. 2026.09.09.

Public Page Exposure — Second Independent Review, One Real Finding, Most Claims Didn’t Reproduce

A second AI-driven security pass over the whole site surfaced a lot of alarming-sounding claims about the previous sanitization work — stale cached sensitive content still reaching visitors, gateway errors on cache-miss requests, several broken linked pages. Verified each directly with cache-busting rather than trusting the report at face value: essentially none of it reproduced, almost certainly a snapshot caught during this same session’s own heavy overnight infrastructure work rather than a persistent bug. Two narrower, real findings did survive verification and got fixed: an interactive webhook test console was hardcoding a real internal service address as its default field value for zero functional benefit (a real user’s own browser already remembers whatever they type in once) — fixed by blanking the default and gating the page itself behind the same admin login already used elsewhere, without changing its URL or touching site-wide navigation; and a leftover version-number mismatch between a page’s title tag and its own body text. Everything else in that review (missing meta descriptions, image alt text, canonical tags) was logged as legitimate but lower-priority polish, not acted on. 2026.09.09.

Live Status Dashboard Feed Restored — Same SSH-Hardening Collateral, Fixed a Different Way

The homelab’s live network-status dashboard started showing a persistent stale-feed indicator despite the underlying links themselves being healthy. Traced through execution logs to the same SSH password-auth lockdown from earlier in the session breaking two more automation workflows that update the dashboard’s data files — identical failure signature, different consumer. A working key-based credential already existed, unused, ready to swap in — but the automation platform’s usual CLI-based workflow-update path turned out to silently preserve a node’s existing credential assignment on import rather than apply an edited one, confirmed directly against the database three separate ways rather than assumed. Raw database editing was ruled out on principle; fixed properly instead through the platform’s own UI credential picker, which writes through its real update path. Also caught and fixed a real self-inflicted gap along the way: stopped the whole automation platform mid-diagnosis to safely inspect its database state, then moved on without restarting it — took every workflow on the platform offline for several minutes until the resulting outage was reported and traced back to that missed step. 2026.09.09.

SSH Password-Auth Lockdown — Proxmox, URONode, LinBPQ Moved to Key-Only

BLE/BTHome Temperature-Humidity Sensors — 8 Devices Diagnosed, 4 Confirmed Dead Hardware and Removed

Dead-Entity Cleanup — 47 Orphaned Registrations Removed via New HA WebSocket Tooling

HA System Audit — LG ThinQ Washer/Dryer Root-Caused to an AdGuard Blocklist Collateral Block

WinBox Saved-Credentials Bug Diagnosed — It Was Never Actually Saving

Network Switch Device Docs Overhaul — Room Swap, RouterOS Version, and a Real Off-By-One Port Numbering Bug

U-Blox GPS Enabled in LinBPQ — Real Lat/Lon Feed for the Node

wview Startup Race Fixed — Caught and Fixed a Real Hang Bug in My Own First Attempt

wview Outage, Round 2 — Edgeport Dropped Off the USB Bus Entirely, Root Cause Traced to the Shared Hub Itself

New Page: The History of Data Centers — Built, Illustrated, and Wired Into Site-Wide Nav

Live Speed Test Widget Restored on the Homelab Page — Real Evidence It Existed Before, Rebuilt From Scratch

Ollama n8n Test Console — Base URL Now Persists Instead of Resetting Blank Every Load

wview Watchdog Rewrite — Real Undercounting Bug Found, USB-Reset Escalation Added, Live Edgeport Outage Fixed

N9LYA-8 AXIP to N2NOV, Session 4 — Root NAT Rule Was Redirecting ALL Protocol-93 Traffic to the Wrong Box

SSH Key Rollout — 5 Devices × 4 Boxes, Passwordless, Plus Three Real Bugs Caught Along the Way

WireGuard Fleet Re-Key — Root-Caused a Shared-Identity Collision, Issued 5 Individual Keys

claude-code VM Remote-Access Security Audit — No Public Exposure Found

AEO Rollout Completed — petworld, adsubmission, takemethere, tripza

N9LYA-8 AXIP Link to N2NOV — 7 Stacked Bugs, Real Root Cause Was an Expired ARDC Portal Registration

URONode Health Monitoring Added to n8n — Full Offline + Services-Down-While-Up Detection

URONode VM Hard-Lock Recovered + FlexNet/ax25-restart Duplicate-Launch Race Fixed at the Source

N9LYA-8 AXIP Link to N2NOV — Seven-Bug Root-Cause Chain Found and Fixed, Traced to an ARDC Portal Setting

Power Outage Recovery — Edgeport, wview, LinBPQ Restored After 2026-09-05 Outage

Home Alert System — WiFi Presence Detection, Dual-Channel Critical Alerts (HA + Self-Hosted ntfy), Manual Panic Buttons

ASUS RT-AC5300 Wi-Fi Optimized + Switch Port Map Recovered and Documented On-Device

Sec-Cam WDS Bridge (Buffalo Access Points) — Recurring Drops Diagnosed, 30-Second Monitor Shipped, Link Rebuilt on Downgraded Firmware

affiliatepathways.us.com & booksrus.us.com — Registry Suspension Investigated, Remediated, Unsuspend Request Submitted

Open WebUI (Ollama VM) — Two Kid Accounts Created + Non-Admin Permissions Locked Down

XPS Bare-Metal Migration — Final Cleanup Pass: RIGCONTROL, Leftover Bridge Services, and a Real USB Fault Mid-Verification

XPS Radio Bridge Migrated Bare-Metal — Root-Caused the P4dragon TNC's Chronic Disconnect Bug

URONode VM Hard-Reset After Full Lockup + Weather Station Outage Root-Caused

AdGuard Custom Allowlist Silently Wiped — Root-Caused and Restored

Crypto Intel Page Moved to Open n9lya.com + YouTube Feed Rebuilt Keyless (RSS)

n8n Workflow — Hourly SolarEdge Inverter Health Monitor with Phone Alerts

"Dark Side of the Moon LLC" — 3 More Live Instances Found on Contact Pages, Different Wording Than the Original Sweep

Outbound Mail Fully Fixed — Real End-to-End Delivery Confirmed, 4 Separate Bugs Found Along the Way

n9lya.com — Root Domain's Fragile CNAME Replaced, SPF Record Added

Remote SSH Access to Home Assistant via WireGuard — No Port Ever Exposed to the Internet

LG ThinQ Integration Fixed — Expired PAT Was the Root Cause, Washer/Dryer Live Again

Home Assistant — Real SSH Access Finally Working, solaredge_local Dead Config Removed

Home Assistant Security Audit — Full 6-Item Review, LG ThinQ Setup Failure & Local-Only Backups Found

HA Automation — NWS Alerts Rewired from Stale Butler County OH to Lawrence County IN, 3 Dead Entities Fixed

Contact-Form & Site Email Failures Root-Caused — Home IP on Spamhaus SBL, Stale MX Records

cryptonews.us.com — 4 Dead Presale-Coin Promo Articles Deleted

AdGuard DNS Blocklist False Positives Found & Fixed — unite.ai, CoinTelegraph's Image CDN

"Dark Side of the Moon LLC" Branding Removed — 4 Sites, Text and Baked-In Logo Images

RSS Content-Import Feeds Overhauled — 3 Sites, Majority of cryptonews's Sources Were Dead

SSH for Kari's 8 Hosted Sites — Closed, Overtaken by Self-Hosting Migration

Network HUD Wired Into Site Navigation

Network HUD Built — Router/Switches/Wi-Fi APs, Person-of-Interest Style, Live on the Site

URONode FlexNet (N9LYA-1) — Root-Caused a Deep DOS-Emulation/Networking Bug, Fixed, Watchdog Added

MikroTik/LinBPQ/URONode Security Remediation — CSF Root-Caused, LinBPQ Hardened, the router Telnet Closed

Kari's Legacy Admin Accounts Locked and Demoted on affiliatepathways.us.com and tripza.us.com

N9LYA Ebook Bundle Now Cross-Sold on takemethere.us.com and tripza.us.com

takemethere.us.com's "No Working Payment Method" Wasn't the Real Problem — Confirmed It's a Pure Affiliate Site, Not a Store

WordPress Admin Credentials Rotated Across All 8 Self-Hosted Sites

Third Site-Wide Outage — Root-Caused for Real This Time: DNS Blackhole + Plugin IP-Lookup Loop, Fixed at the Network Layer

Astrometrics (solar-system.html) — Mobile Centering Bug Root-Caused to Webfont Load Timing

POI-Tracker Built — Live APRS Map on n9lya.com, Sourced From Own Packet Infra; PACKET Nav Dropdown Rolled Out

booksrus.us.com — Homepage Load 2.0s → 0.4s via nginx FastCGI Cache; Homepage Schema Added

Second Site-Wide Outage (UpdraftPlus-Correlated) + takemethere.us.com's Real wp_head Bug Found

GA4 Analytics Rolled Out — All 8 Migrated Sites Plus All 32 Pages of n9lya.com

Google Search Console + Bing Webmaster Tools — All 8 Sites Verified

First Site-Wide Outage During SEO Work — wp-cron Pileup, Fixed and Guarded Against Recurrence

Full SEO Audit + RankMath Rollout Across All 8 Sites — Two Real Bugs Found, 13 Products Get Real Metadata

8-Site Affiliate/Payment Audit — Bogus AdSense Account Found and Replaced, Real CJ Affiliate Wired to tripza.us.com

home.kutche.net Cloudflare Proxying — Re-Tested and Settled on DNS-Only for Real This Time

Garmin Fenix 8 → Home Assistant — Integration Already Live, ECG Confirmed Not Available

booksrus.us.com ERR_TOO_MANY_REDIRECTS — Two Real Stacked Bugs Found and Fixed on All 8 Sites

n8n — Garmin Telemetry Broken Since Yesterday's VM Migration, Crypto Price Refresh Hardened

Cloudflare — All 8 Self-Hosted Sites Cut Over, Two Real Redirect-Loop Bugs Found and Fixed

N9LYA Ebook Series — Cover Art Resized for All 5 Publishing Platforms

N9LYA Ebook Series — All 12 EPUBs Pass epubcheck 5.1.0 With Zero Issues

N9LYA Ebook Store — Real Descriptions Applied, Bundle Finalized, Downloads Confirmed End-to-End

N9LYA Ebook Series — Full WooCommerce Store Live on booksrus.us.com (12 Books + Bundle)

booksrus.us.com — Migrated to Self-Hosted a container, Verified Live (8th and Final Kari Site)

A container HAProxy — Real Production Outage Root-Caused to OOM Kills, Memory Doubled

affiliatepathways.us.com — Migrated to a container; TASK 208 Backdoor Confirmed Gone From Live Site

takemethere.us.com — Migrated to a container, 2 Dead Plugins Actually Fixed (Not Just Disabled)

adsubmission.net — Migrated to Self-Hosted a container, Verified Live

petworld.us.com — Migrated to Self-Hosted a container, Verified Live

P4 Dragon TNC — Dead on the Radio Bridge (XPS), Fixed by Rebooting the Bridge Box

A VM (linbpq) — Full Boot/Network Crisis, Root-Caused and Recovered

The automation platform Moved From a Container to a Dedicated VM

The automation platform Upgraded — Was Many Versions Behind, Approaching End-of-Life

mitchellbpq.com — WebSocket Terminal Fixed (Root Cause Was Never TLS)

A container (MariaDB) Consolidation — n8n Move Not Possible, Vaultwarden Deferred

homelab-status.html — Data-Shape Mismatch Between n8n Webhook and Page Render Logic

petworld.us.com & adsubmission.net — No Split-Upload Gap

Split-Upload Backfill Sweep — cryptonews.us.com & ainews.us.com Now Complete

booksrus.us.com — Backup Archived to a container (4 of 4, Now Complete)

affiliatepathways.us.com — uploads.zip Retrieved Despite McAfee Block

petworld.us.com — Backup Archived to a container (3 of 4)

takemethere.us.com — Backup Archived to a container (2 of 4)

adsubmission.net — Backup Archived to a container (1 of 4)

ainews.us.com — Migrated to Self-Hosted a container (DB/Files Verified, HTTPS Pending)

cryptonews.us.com — Migrated to Self-Hosted a container, Verified Live

Monthly Plugin Update Check — n8n Automation Built and Activated

Self-Hosted WordPress Infrastructure Built on Proxmox (a container + a container + HAProxy)

AdGuard Home — Preemptive Allowlist for All 8 Hosting Sites (+www variants)

"Can't Reach ainews.us.com" — Root-Caused to AdGuard Home DNS Block

cryptonews.us.com — Same Critical Plugin Vulnerability Found and Contained (Not Yet Exploited)

ainews.us.com — Confirmed Compromise Cleaned Up: 4 Rogue Admin Accounts Removed, Vulnerable Plugin Contained

Pi-Star/WPSD Hotspot — Status Reviewed, IC-7100 D-STAR Programming Provided

adsubmission.net / takemethere.us.com / tripza.us.com — Shared Default Password Found, Plugins/WooCommerce/Stripe Updated

affiliatepathways.us.com — Live Unpatched Plugin Vulnerability Contained, Core Upgraded to Current

petworld.us.com — WooCommerce Upgraded Several Major Versions, Broken WP-Cron Diagnosed, 9 Plugins Updated

Website Hosting Audit — Two cPanel Accounts, Eight Sites Discovered

ainews.us.com & cryptonews.us.com — Broken Article Images Root-Caused to a wp-automatic Filename Bug, 841 Files Fixed

petworld.us.com — Discontinued App Promo Section Removed

Identity Leak Fixed — Public Byline Now Used Instead of a Personal Handle on 2 Sites

AdSense — ads.txt Gaps Fixed on 3 Sites, myretireyears.com Connected and Verified

Content-Marketing Posts Were Misattributed to the Wrong WordPress User — 12 Posts Across 6 Sites

myretireyears.com — Full Production DNS/SSL Path Debugged and Fixed (4-Layer Root Cause)

myretireyears.com — New Site Built and Launched (9th Self-Hosted Site)

Ryan's SSH Keys — Fully Set Up, Closes TASK 132

Content Marketing Round 2 — One New Post Published Live on All 8 Self-Hosted Sites

mitchellwx.com — Missing SEO Metadata Fixed, Full Modern Redesign Shipped

Site-Wide robots.txt Block Found and Fixed — 6 Sites Were Invisible to Every Search Engine

kutche.net — Exposed Internal Placeholder Notes Removed From Two Live Public Pages

Sound-Modem PC (Win10) — VARAFM Not Hearing 2m Radio, Root-Caused to a Bad USB Port

LinBPQ ↔ URONode — Real AXIP/AXUDP Cross-Node Connection Root-Caused and Fixed

Radio Bridge (XPS) — Edgeport Loose-Connector Fault Found; Full Automated Health-Check + Alerting Built

vsftpd (a VM) — Double-Managed by Both systemd and Legacy SysV, Causing a Boot-Time Crash Loop

Radio Bridge — SYMEK TNC + RPC3 Power Controller Wired Onto the Network Bridge, URONode Routing Built

LinBPQ — SCS Tracker Driver Segfault Root-Caused to an Exact Source Line via strace

URONode — MSYS and JNOS Fixed to Actually Survive a Reboot

URONode "wx" Command — AMPRNet Routing Gap Between URONode and LinBPQ Fixed

LinBPQ Web UI — Found and Reported a WebSocket-over-HTTPS Bug to G8BPQ

The packet radio node Box Migration — Formally Cut Over to a VM

Weather Station — Wrong Edgeport Channel Found and Fixed

P4dragon Pactor Modem — Found and Fixed a Non-Standard Baud Rate Requirement

XPS Radio Bridge — Recurring "Lockups" Root-Caused as GNOME Auto-Suspend, Not Hardware

LinBPQ Radio Bridge — Found and Fixed a Startup Timing Bug Affecting All 10 Ports

LinBPQ Radio Bridge (XPS) — Rebuilt Fresh on Debian 13

URONode — Migrated Off Physical PC to a Proxmox VM

Redis Actually Put to Work — Cache + Last-Known-Good Wired Into 4 Pipelines

HA Login-Failure Spam — Dead Hardcoded Token in Retirement Sensors Refresh

Old KFRAWI Fire Tablets — Removed from Home Assistant

Weather Alerts — Now Also on the Garmin Watch

Weather Alerts — Notification Text & Gating Verified

Weather Alert Delivery — Migrated Off Dead Amazon Tablet

Ops Log — Stale "80 Complete" Count Corrected

Task Tracker Header — EARTHDATE & Retirement Line Made Dynamic

Garmin Telemetry — Added to Homelab Nav Too

Garmin Telemetry — Added to Nav

Garmin Telemetry Dashboard — Built via Unofficial python-garminconnect

Crypto Portfolio Page — Rebuilt Matrix-Themed, CoinGecko IDs Verified

Anthropic API Key Cleanup — Self-Report/Crypto Intel Consolidated

Home Assistant Credential — Restored After Accidental Overwrite

A container → a container SSH Access — Provisioned

Self-Report Consistency Experiment (Ollama) — Recovered From Archive

"Save Results to Disk" Node — Confirmed Working

Automations Page — All N8N Workflows Now Listed

A container Credential Cleanup — Orphaned JWTs & Unused API Keys

Vaultwarden Redirect Loop — Root Cause Confirmed & Fixed

Energy/Devices Workflows — Confirmed Published

Aug 1 Security Alert — Confirmed Own Activity

Fidelity Pension → IRA Rollover

EIN Deactivation Letters

Anthropic Personal Statement

Net44 IPIP Mesh Boot Persistence

FlexNet P3 / P4 Links

The automation platform — Fresh Rebuild on a New Container

Crypto Intel Pipeline — Live

n9lya.com Auto-Push Workflow

Vaultwarden Login

radar-scope-1.html — Live ADS-B

n9lya.com Top Nav

Voice Add-ons → Proxmox LXC

HA AMPRNet Route on Start

Xiaomi BLE Sensors Dropping

Wyoming / HA Core Memory Leak — Root Cause Resolved

CRS Switch Documentation — Homelab & Netmap

Uptime Kuma — Service Monitoring Dashboard

WireGuard Road Warrior VPN (the router)

Uptime Kuma False-Alert Root Cause

n9lya.com Visitor Counter

Uptime Kuma — URONode Monitor + Gmail SMTP

Homelab Page — Ryan (KB8PMY) Location Fix

"Built With Claude" Banner + Usage Log Rebuild

Industrial AI History Section — Homelab Page

WireGuard Road Warrior Reference Doc

PDF Guides for Jason

mitchellwx.com NEXRAD Radar Fix

LCARS Radar Scope Page (radar.html)

Site Nav — Radar Scope Links

MikroTik HA Integration — Resolved

Solar Energy Page — LCARS (solar-energy.html)

SolarEdge n8n Data Pipeline

SolarEdge Workflow v2 — HA Grid Data Integration

LinBPQ Forwarding Monitor — Gmail Alert Credential Fix

HA Command Hub — New LCARS Subsystem Pages

n8n Workflows for HA Command (Devices/Automations/Energy)

n8n Publish vs Save — Silent Revert Bug

ha-watchdog.sh Token Rotation

wview → HA Weather Push

Retirement Terminal — HA Token Configured

Public Site Security Remediation

Home Assistant CORS Fix

Retirement Countdown Page

Continuum — Homelab Status Dashboard

Continuum Nav Links

Live Radar Page — n9lya.com

LinBPQ Forwarding Monitor — Repeat Alerts, Root Cause Found

Crypto Intel Pipeline — YouTube Node Failing, Resolved

The router Login Failures — Real Root Cause Found (Not HAProxy Creds)

Vaultwarden Master Password Recovery + 2FA + Backup

SSH Key-Only Auth — a container & Proxmox Host

Fleet-Wide Password Rotation

Full 9-Phase Homelab Optimization Audit

MikroTik Topology — Fully Confirmed & Corrected

n8n API Key — Workflow Visibility Restored

K9BBS Newsletter Workflow — Security Review + Pipeline Repair

K9BBS Newsletter Workflow — First Live Test Run Successful

Sparklight Speedtest Monitor — Native Timer + Accuracy Fix

K9BBS Newsletter Workflow — Publish Blocker Fixed, Now Live

A container — Nvidia Driver Branch Swap, Complete

AdGuard Custom Rules File — Audit & Cleanup

Crypto Portfolio Tracker — Built & Deployed

Security Audit Round 2 — Credential Rotation + Publish-Bug Sweep

Kutche Family Genealogy — Offline HTML

Kutche AI LLC — Two Ebooks Published

Indiana LLC Setup Checklist

Uptime Kuma — n9lya.com Monitoring Live

Gmail MCP Re-Authentication (a container)

Open WebUI (ai.kutche.net) — Missing Models Restored

Four-Layer Weather Automation Stack — Complete