Before the First Boot: The Rocky Linux Decisions That Shape Everything After
Rocky Linux is chosen. The architecture case has been made — RHEL compatibility, career skill alignment, a community-governed distribution on solid footing. That decision is behind you. What's ahead is a thirty-minute installer conversation with Anaconda that will determine the shape of this machine for as long as it runs.
The decisions that matter here are not steps. They're posture calls — choices about what kind of machine this will be, what access model it operates under, what security profile fits its actual exposure. Most of them are reversible in theory. In practice, the ones made at install time tend to stay, because changing them later costs more than the pain of living with them. Which is why they deserve more attention than most installer walkthroughs give them.
What This Machine Is Actually Doing
This is not a technical question. It's the question that makes every technical question answerable. A machine running a local DNS resolver and Plex in a closed homelab network has a different answer to almost every installer decision than a machine running a publicly accessible VPN endpoint or a web application.
Before you boot the ISO, name the role. Not "a server" — something specific. "Internal service host, never directly reachable from outside my network" is a posture. "Reverse proxy target behind Nginx on a VPS" is a different posture. "Lab machine for learning and experimentation, rebuilt frequently" is a third. The posture question matters because every installer decision that follows is only answerable relative to it. If you can't name what this machine is doing and what it's exposed to, you're making the rest of these decisions in the dark.
In a homelab, you have the latitude to make the posture call loosely and rebuild when it's wrong. In an enterprise context, the machine role is usually defined before provisioning starts — the installation decisions are consequences of a document, not a real-time judgment call. The homelab is where you practice making the posture call before reaching for the installer, which is exactly the habit that carries forward.
How Much Disk You Actually Need
Anaconda in Rocky 9 defaults to automatic LVM partitioning. On a disk with adequate space — 100GB or more — the automatic layout is usually workable. On smaller disks, it frequently produces a root partition that fills within weeks of real use. The automatic sizing algorithm doesn't know what you're going to run, so it distributes conservatively and prioritises /home, which on a server is irrelevant.
The explicit decision: automatic partitioning or manual layout? For a lab machine that gets rebuilt every few months, automatic is fine — the cost of getting it wrong is a rebuild you were planning anyway. For a machine intended to run a year or more without reinstallation, take the manual partition screen. The layout that works for most server roles: a dedicated /boot partition (500MB to 1GB), a root partition sized generously for the workload (50GB minimum for anything running containers or accumulating logs), and swap sized to your RAM with a ceiling around 8GB.
The enterprise version of this decision doesn't happen in the installer — it happens in a capacity planning document before the machine is provisioned. The homelab version happens here, live, with whatever disk you handed the VM. Getting into the habit of making this call explicitly — rather than accepting defaults — is the skill worth building, regardless of which disk size you have in front of you.
Minimal Install or Something Heavier
Rocky Linux's installer offers several package group options. Minimal Install is what it says: a bootable system with dnf, systemd, networking, and not much else. No text editor beyond vi. No diagnostic tools you haven't explicitly installed. The lightest possible footprint.
Server and Server with GUI add progressively more. Server with GUI on a headless machine you're SSHing into is pointless overhead. The jump between Minimal and Server is worth examining — Server includes a set of commonly useful packages that most server workloads will eventually want, at the cost of a larger attack surface and more packages to keep patched.
The homelab case for Minimal: you're building from scratch anyway, you learn what you actually need by installing it explicitly, and the base is clean. The enterprise case for Minimal is even stronger — smallest attack surface, cleanest audit baseline, and any package added to a production server should be a deliberate choice with a documented reason. The temptation to grab Server with GUI "just in case" on a homelab machine is understandable and worth resisting. The diagnostic work you avoid by having a GUI pre-installed is substantially less than the habit it breaks: knowing exactly what's on your machine and why.
SELinux: The Decision With the Longest Tail
SELinux is the most consequential installer decision on this list, and the one most likely to be made for the wrong reason. The default in Rocky 9 is enforcing. Most people who flip it to permissive or disabled do so because something broke and SELinux produced a denial they didn't understand. That's an understandable response to an opaque error. It's also the response that leaves you with a machine where the security substrate is switched off.
Enforcing mode catches real things — it blocks a process from accessing a path it shouldn't, stops a service from binding to a port outside its policy, and generates audit log entries that are actually useful during an investigation. It also produces denials for things you legitimately want to do, especially when building something non-standard. The friction is real. The friction is also the signal: a SELinux denial is the system telling you something is happening outside expected parameters.
Permissive mode logs denials without enforcing them. It's useful as a diagnostic tool when you're building something new and want to understand what a policy change would affect before committing. It is not a security posture — it's SELinux with training wheels on.
Disabled mode is the wrong answer for any machine with a network connection to anything you care about. It's also structurally irreversible without a filesystem relabel — switching from disabled to enforcing on a running system requires a reboot and a full relabel pass, which takes time and sometimes produces surprises.
For a homelab machine that's purely internal and where you're the only user: enforcing is still the right default. Learn to read the audit log. Learn to use audit2allow and ausearch. The friction is tuition on skills that transfer directly to enterprise environments where SELinux is enforced and non-negotiable. For an internet-exposed machine: enforcing isn't a preference, it's the floor. Any instance where you're considering disabling SELinux on an externally reachable host is an instance where you need to understand the denial, not remove the system generating it.
Root SSH: The Access Model You'll Carry Forward
Rocky 9 ships with root SSH disabled by default in sshd_config. The default is correct. The question is whether to change it at install time, and the answer depends entirely on your operating model.
For a closed homelab machine — behind NAT, no external access, you're the only user — root SSH is a convenience call. The security surface is the same as your network boundary, and if that boundary is your home router, you're already trusting that. Enabling root SSH on an internal-only machine is a reasonable tradeoff for the access simplicity it buys.
For any machine with a path to the internet — even through a VPN, even behind a firewall with narrow rules — root SSH is a posture you should be able to justify in writing. The failure mode: your firewall rule has a misconfiguration, root is directly reachable, and the only thing between an attacker and full compromise is your password. The enterprise answer is always no, without exception. The homelab answer should be: what is this machine's actual exposure, and am I willing to accept that consequence?
The pattern worth building regardless of context: create a named user during installation, add it to the wheel group for sudo access, disable direct root SSH. This is one extra step and it's the access model that carries forward into every professional environment. Practicing it in the homelab means you don't have to learn it under pressure later.
IPv6: A Configuration Call, Not a Philosophy
IPv6 is enabled by default in Rocky 9. In an enterprise environment with IPv6 infrastructure, leave it alone — disabling a protocol your network actively uses will create problems, and that decision belongs in a change request, not a personal installer preference. In a homelab environment without an IPv6 router configured, it creates noise: dual-stack networking with link-local addresses, occasional routing confusion, and service binding behavior that surprises people who aren't expecting it.
The homelab case for disabling IPv6 is simple: if you're not running IPv6, disable it explicitly so your network configuration is deterministic. The correct method in Rocky 9 is through NetworkManager — either via nmcli post-install or by adding a configuration file to /etc/NetworkManager/conf.d/. The old approach of adding kernel parameters to GRUB and editing sysctl.conf still works but routes around NetworkManager's network state management, which can produce unexpected behavior when connection profiles are modified later.
This decision doesn't split on homelab vs. enterprise in a clean ideological way — it splits on whether your environment has IPv6 infrastructure. Name your environment and answer accordingly. Disabling IPv6 in an environment that needs it is worse than leaving it enabled in an environment that doesn't.
What to Carry Forward
These decisions don't stand alone. They form a posture — a coherent position about what this machine is, what access model it operates under, and what security profile fits its actual exposure. The value in making each decision explicitly isn't that you'll always get it right. It's that when something breaks or needs to change, you know what posture you set and what changing it will cost.
The homelab is where you practice making posture calls under low stakes. The enterprise is where you execute posture calls that someone else already defined, under high stakes, with documentation. The skill that transfers between them isn't the specific answers — it's the habit of asking the question before reaching for the default.
Rocky Linux doesn't care how you install it. The decisions are yours. The baseline you start with is the one you'll carry forward — in practice, in habit, and in everything you build on top of it.
