Skip to content

Instantly share code, notes, and snippets.

@airbreather

airbreather/plan.md

Last active December 19, 2024 14:35
Show Gist options
  • Save airbreather/7679bf59da043cd27f05a59095b3e374 to your computer and use it in GitHub Desktop.
Save airbreather/7679bf59da043cd27f05a59095b3e374 to your computer and use it in GitHub Desktop.
Download ZIP
coreos server install
Raw
plan.md

Rebuild on Fedora CoreOS

https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started

Basics

  1. Base system is immutable by default.
    • /etc is read-write, but the project strongly discourages doing the stupid crap that needs not be mentioned here.
    • /var is read-write, and the place where the magic is expected to happen.
    • /home and /srv are symlinked to locations under /var.
  2. Overall design philosophy (slightly oversimplified): the base system is only for running and managing containers, which are what provide the actually useful services that the server is there for.
  3. In an ideal world, because of the above, the central upstream team could produce just a tiny handful of fully supported and very well-tested images, allowing for a perfectly smooth installation process where updates are as simple as "download the entire new image and use that instead", and those actually useful services don't care because they live entirely inside of Container World.
    • The services don't update alongside the base system because they get their updates out-of-band: they're in Container World, remember, so their dependencies are practically completely independent of that base system with the exception of their interfaces to the outside world that are explicitly declared in their configurations.
    • Because that platonic ideal is impossible to achieve (for many reasons), the central upstream team actually spends their time working on the supporting tools that streamline and orchestrate the process for users like me to set up an operating system that functions as close to that "ideal world" as is realistically achievable.

What I need to bring

  1. A JSON-formatted "Ignition file", apparently typically generated from a YAML-formatted "Butane config" using a nice little translation tool that primarily (but not exclusively) reformats the YAML document to JSON.
  2. Since I will need ZFS, I must choose a base system image using at least one of these (or similar) to layer on top of the base.
    • See also: Adding OS extensions to the host system
    • 🤔 should I jump straight into uCore (perhaps, dare I bring it up, going as far as uCore-HCI)? There are prebuilt images with ZFS included (and more, some of which I was ABSOLUTELY going to add myself and others which I was on the fence about).
  3. Practice and experience before committing to making the switch.
    • Prove that I can take an existing zpool and import it on this new system, ideally one with multiple vdevs in RAIDZ-1.
    • I should be comfortable setting up a couple of yodawg levels in a VM.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment