Over the last few years in the Enarx project, we have been struggling with iPXE. Enarx needs a bare-metal infrastructure so that we can have access to the underlying confendial computing hardware. We also have to boot a custom kernel on this hardware. We also want the environment to be reproducable.
Early on we tried using NixOS to get these properties. But this also implied that we had to build our custom kernel on each device. Some of the devices are very slow. So this proved not to be workable. Mostly we settled on a Fedora installation with a kickstart to automate installs. This had… problems.
First, there was the state management. We tried to have a declarative infrastructure by rebooting to install via a kickstart. But since this took ~30 minutes of downtime to reboot the machine, users were incentivized to make local changes. And so the local changes would drift from our declarative install. We needed something faster.
Second, there was the iPXE cipher suites problem. You see, iPXE wants to download the OS for installs over the network. This, of course, means you need TLS encryption for any hope of security. But iPXE only supports ancient cipher suites. You know, the ones modern servers are disabling. We needed something more secure.
What we wanted was the container experience, but on bare-metal. We should always reboot to get the latest OS changes. But the reboots should be fast, not a full re-install. We also didn’t want to bring up infrastructure to manage state. Sure, products exist to solve this problem. But I don’t want more infrastructure to manage my infrastructure. Container registries already exist and don’t require any infrastructure to download and run them. And they are completely declarative.
I just wanted to boot a container.
Wyrcan is a bootloader that boots into a container. That’s all it does.
But of course, that’s not the only thing that Wyrcan implies. Using Wyrcan to boot a container also means that you can use a tried and trusted software packaging ecosystem to have a bare-metal OS that is:
Stateless: Booting a container with Wyrcan means that nothing is installed on the disk. There is no state to manage except the state you put into your container. You never have to worry about whether packages are updated: you can schedule reboots to make sure you always have the latest OS. And if all your mounts of local storage are
noexec, you can just reboot when compromised.
Memory-Resident: The full operating system is resident in RAM. That means it is fast. However, you can also set up swap in your container so that unused pages are written to disk, saving memory for your application.
Declarative: Your bare-metal operating system is developed using the same delarative tooling that you have come to expect from the container development pipeline. But your OS config in git. Host it in your favorite git forge (GitHub, GitLab, Bitbucket, etc). Build the images automatically. Host them in your favorite container repo.
Wyrcan supports three modes of operation:
- Direct Boot
- ISO Boot
- Chained Boot
Using the direct boot mode of operation, you just point your VM or (i)PXE-enabled system at the Wyrcan kernel and initrd. You can see more details at the project website.
Download the ISO. Write it to a CD, DVD or USB storage device. Boot it.
On the first boot, you can associate Wyrcan with a kernel image and store this association in an EFI variable for automated boot. Then walk away. Your system that formally couldn’t netboot, now can.
Wyrcan is itself a bootable container. So you can chain from one Wyrcan instance to another. This allows you to upgrade to the latest version of Wyrcan without physically managing a machine.
Check out Wyrcan’s website. We have many more examples, including numerous bootable containers to try from all the distributions you love. If you need a feature or find a bug, we’d love to hear from you.