Two lines, one PID
The duplicate-gateway item closed in this session, and how it closed is the part worth keeping. The port listing showed two LISTEN lines, one on the IPv4 loopback and one on the IPv6 loopback, which looks like two things until you read the PID column. Both lines, one process. That is what a daemon binding both stacks is supposed to look like. The broken state would have shown two different PIDs. Read the PID column, not the line count.
The switch that was still on
Then the part I would have rushed. The user-scoped unit's enabled state already read disabled, so "disabled" was true and also not the whole fix. Linger was still on — the property that lets a user-scoped service come back on a headless box with nobody logged in. Turning linger off is what this session actually changed. The file's own summary compresses both facts into one clause, which reads like a single action; the transcript is the other way round — the unit was already disabled and the property was the remaining switch. Keep those separate. A unit that is disabled with linger on is still a service that can return.
Session hygiene, short: in a session listing a dash in the source column means the session is not a remote shell, it's a local console; the command column shows what each one is running, and the one running the listing is me. Close gently first, force only if the process ignores that — and remember that the terminate-everything-for-a-user command drops me too if I am that user. The observation worth acting on is the one underneath: every session here logs in directly as the privileged account over the remote shell. Normal for this platform, tolerable behind a home LAN, still a hardening target.
Why a drive purchase lost
Offsite backups went to Cloudflare R2 on an account I already had, not to a new drive, and the footprint decided it: a 32 GB VM holding about 6.4 GB of real data, with compressed snapshots a few GB each. The free tier covers 10 GB with no egress fees and probably covers this indefinitely. The storage shortage pushed the same way. The same account is needed later for the tunnel work that replaces the fragile reverse-SSH tunnels. And the 64 GB flash drive stays as bootable installer media, which is worth more now that there are live workloads on the box.
Two choices inside that were about workload shape rather than price. Storage class is Standard, not Infrequent Access: IA is cheaper per gigabyte but adds a retrieval fee and a 30-day minimum storage duration, so nightly rotating snapshots would pay for 30 days even when deleted after two. IA is for write-once, keep-for-years archives. And the bucket's public access is disabled with no custom domain attached, which needs no argument — backups must never be publicly reachable.
The API token is account-scoped rather than user-scoped, because account tokens stay active independently of the user, which is what an unattended job needs, while a user token breaks when membership changes. It can read and write that one bucket and nothing else, so a leaked token cannot reach anything else. The secret is shown once, kept in a password manager on the workstation, and never goes in the repository.
The uploader (rclone) sits on the hypervisor as the privileged account, for two reasons. The snapshot tool runs there because that is what can see the VM's disk image, so the backup files land there anyway. And the privileged account's own configuration directory is where a job scheduled at system level will actually look for credentials — configure it as anyone else and the scheduled job finds nothing. That is the kind of "why here and not there" note I keep needing and keep forgetting.
What I haven't proven
The verification I wrote down is a round trip, not an upload: write a test object, copy it up, list it, read it back down from the far side, delete it. An upload that returns success is not a backup. The honest part is that the to-do list still has finishing the uploader config and running the round-trip test unticked, with the restore test listed separately underneath it. So nothing here is evidence that anything offsite can be retrieved yet. An untested backup is not a backup, and the restore is still on the list.
The second thing left open is whether to wrap the remote in an encryption layer so snapshots are encrypted before they leave the LAN. Those VM snapshots will contain the agent gateway's secrets and credential directories, so this is not theoretical. Undecided is a real answer; I would rather leave it visibly undecided than find out after the first upload.
The estimates I had wrong
Earlier price estimates in these notes were based on pre-shortage figures, and they were wrong. Recorded during this session, with no citations in the file, so read them as notes rather than market data: HDD prices up roughly 46% between September 2025 and January 2026, with individual models up 23–66%; tracking since September 2025 showing HDDs up 50.8% and SSDs up 86.6%; one manufacturer's capacity sold out for all of calendar 2026, another able to fill only about 50–66% of near-term demand. Cause as recorded: AI datacenter buildout with contracts booked years out.
What it changes: the 32 GB RAM upgrade will not cost the $35–55 I wrote earlier, so it gets re-priced before it goes anywhere near a budget. "Wait until we actually hit the limit" now has a real cost attached, and that is new information rather than an opinion. Refurbished and used is the value route per terabyte, which strengthens the sourcing plan instead of weakening it. And cloud storage is untouched by the shortage, which is one more point in its favour.
Cheap drives that won't fit
Sourcing runs through ITAD — IT Asset Disposition, the companies that take decommissioned corporate and datacenter hardware, wipe and test it, and resell it. The search that works is for what companies decommission rather than what consumers buy: corporate refresh runs 3–5 years, so aim at roughly 2019–2022 gear, favour sellers who publish SMART data, stated power-on hours and photos of the actual unit, and sort by newly listed because good stock moves fast.
The trap in that channel: enterprise listings are full of SAS drives at tempting prices because consumer demand for them is nil. SAS and SATA are different interfaces and the connector is keyed, so a SAS drive will not seat in a SATA port — it works one direction only, SATA into a SAS backplane, never the reverse. The mini PC has a plain 2.5-inch SATA bay, so the filter is SATA, 2.5-inch, 7 mm; 15 mm drives do not fit.
Verify the way in before you close the way in
The hardening plan is not applied. The file says so itself, and nothing in it happened this session. What matters is the order, and this is the best rule in the notes.
The privileged account stays, because the admin surface genuinely needs it. So the goal is not removing that account — it is stopping password-based login for it over the remote shell while keeping key-based access working. The setting is PermitRootLogin prohibit-password, and explicitly not no, which breaks admin workflows.
Before any of that: set up key authentication and test it, open a second terminal and confirm passwordless login actually works from there, and do not close the working session until that is proven. That session plus the local console are the safety lines. Only then set PasswordAuthentication no, restart the remote shell service, and test again from a new terminal while the old one is still open. The next layer after that is fail2ban, which watches authentication logs and temporarily bans repeated failures.
Timing is part of the decision. Nothing here is reachable from the internet right now — behind NAT, no port forwarding — so the attack surface is small. The tunnel work is exactly the moment that changes, which is why the hardening happens before the tunnel and not after it.
Lab work isn't study, and that's the gap
Aiming at Network+ N10-009, and the plan itself is ordinary: drill subnetting until the network address, broadcast address and usable host range for a /27, /28 and /29 come out without a calculator, ten minutes a day; treat the OSI model as a troubleshooting order rather than a list to recite and work bottom-up; expect the performance-based questions to assume hands-on experience.
The honest note underneath it is the one to keep. This lab gives exposure, and exposure makes concepts land faster later, but it is not deliberate study. Much of what has been built here was done by following supplied commands — a real head start on vocabulary and context, and not the same as being able to diagnose an unfamiliar network cold. The fix is a habit, not a resource: when something breaks, state the symptom and a hypothesis first, and ask what I should be looking at instead of what to run. Slower, and it builds the reasoning the exam and the job actually test. Cheaper second habit: when lab work touches a networking topic, note which objective it maps to, so the build log doubles as a study aid.
Still on the list
Finish the uploader configuration and run the round-trip test, decide the encryption layer, schedule the snapshot job and push it to the object store, then test a restore. Hardening: key-based access for the privileged account, then the prohibit-password setting, then fail2ban. Deferred: resize the disk from 32 GB to 64 GB with a snapshot first and a 4 GB swapfile replacing the swap partition, re-price the RAM kit, and the agent-host migration — inventory the cloud host before sizing hardware to measured need, because the agent gateway asked for 24 GB and is using about 1.3 GB. Requested is not measured. Housekeeping: delete the local backup directory left over from a repair once things are stable, and work out what created an older broad-scope token I still have to identify.