Turn a Repurposed PC into Dependable Local Infrastructure
A useful local server does not need to begin as purpose-built server hardware. This seven-part guide follows a completed Fedora build from first installation through a stable, remotely administered baseline with virtualization, private networking, and encrypted storage.
The goal is not to reproduce a troubleshooting transcript. It is to preserve the decisions and procedures that mattered: keep the host recoverable, keep security boundaries intact, validate every layer before depending on it, and treat convenience features as explicit architectural choices.
The finished baseline looks like this:
Admin workstation
│
│ OpenSSH over LAN or Tailscale
▼
Fedora host
├── optional LUKS-encrypted system disk
├── firewalld + SELinux
├── sshd
├── tailscaled
├── KVM/libvirt
│ └── Fedora Server VM
│ ├── sshd
│ └── tailscaled
└── LUKS secondary SSD
└── /srv/storage
Example-value convention: Hostnames, usernames, interface names, device paths, IP addresses, CIDR ranges, UUIDs, fingerprints, hashes, mapper names, and other identifiers in this series are examples unless explicitly identified as software defaults. Derive the corresponding values from your own machine before running commands.
Follow the Series in Order
1. Architecture, Hardware, and Fedora Installation
Build a Fedora Local Server: Architecture, Hardware, and Installation
Define the target architecture, review hardware and firmware, decide whether to encrypt the system disk, install Fedora, and capture the first known-good host baseline.
2. Hardened Local Administration
Hardened Local Administration with OpenSSH and firewalld
Build a LAN-only administrative path with dedicated SSH keys, public-key-only authentication, root-login denial, and a source-restricted firewalld policy.
3. KVM, libvirt, and the First VM
KVM, libvirt, and the First Fedora Server VM
Enable KVM/libvirt, validate NAT networking and storage, create a Fedora Server guest, harden guest SSH, and make the VM part of the host baseline.
4. Private Remote Administration with Tailscale
Private Remote Administration with Tailscale
Give the workstation, host, and VM stable private identities without replacing OpenSSH, then add least-privilege Tailnet policy and recovery-minded hardening.
5. Encrypted Server Storage
Convert an Encrypted Secondary SSD into Server Storage
Move an existing LUKS + ext4 disk from desktop-style mounting into system-managed /srv/storage with crypttab, fstab, and optional-boot behavior.
6. Maintenance, Validation, and the Known-Good Baseline
Maintenance, Validation, and the Known-Good Fedora Server Baseline
Verify service health, reboot persistence, firewall and SELinux boundaries, Tailscale policy, libvirt state, storage behavior, and the final host/VM baseline.
7. Troubleshooting and Deferred Work
Fedora Local Server Troubleshooting Notes and Deferred Work
Keep recurring diagnostics and intentionally deferred work out of the main path: libvirt edge cases, ProxyJump, SELinux, macOS Tailscale clients, host keys, optional storage, recovery, and future network work.
What This Collection Deliberately Does Not Cover
The collection stops at the local-server boundary. Final router and firewall design, VLANs, managed switching, Wi-Fi access points, ISP migration, and broader network observability belong to a separate network guide.
Secrets management and recovery architecture also deserve their own treatment. This series explains why independent recovery credentials matter, but it does not turn a server setup guide into the canonical place to store or distribute secret material.
The Security Model Is Layered
The completed administration path is intentionally made of independent controls:
Identity provider / MFA
↓
Tailnet Lock
↓
least-privilege Tailscale Grants
↓
Tailscale encrypted transport
↓
OpenSSH public-key authentication
↓
firewalld + SELinux
↓
Fedora host and guests
Tailscale is the private network path, not a replacement for OpenSSH authentication. Full-disk encryption is likewise a deliberate trade-off: it protects data at rest, but a passphrase-protected root volume creates a boot-time unlock dependency that must be accounted for if unattended reboot matters.
The implementation history behind this series came from one real machine. Upstream Fedora, Linux, libvirt, OpenSSH, firewalld, systemd, cryptsetup, GNOME, Cockpit, fwupd, and Tailscale documentation remains authoritative for version-dependent behavior.