dependabot[bot] 0779f2c545 chore(deps): bump docker/metadata-action from 4 to 5 (#73)
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2023-09-19 10:59:20 +02:00
2023-09-14 18:45:15 -05:00
2022-12-19 21:24:37 -08:00
2023-09-14 18:45:15 -05:00
2023-03-18 00:40:13 -05:00

uCore

build-ucore

What is this?

You should be familiar with Fedora CoreOS, as this is an OCI image of CoreOS with "batteries included". More specifically, it's an opinionated, custom CoreOS image, built daily with some commonly used tools added in. The idea is to make a lightweight server image including most used services or the building blocks to host them.

WARNING: This image has not been heavily tested, though the underlying components have. Please take a look at the included modifications and help test if this project interests you.

Images & Features

ucore

Suitable for running containerized workloads on either baremetal or virtual machines, this image tries to stay lightweight with not too many additions.

  • Starts with a Fedora CoreOS image
  • Adds the following:
  • Optional ZFS versions also add:
    • sanoid/syncoid dependencies - see below for details
    • ZFS
  • Enables staging of automatic system updates via rpm-ostreed
  • Enables password based SSH auth (required for locally running cockpit web interface)
  • Disables Zincati auto upgrade/reboot service
    • NOTE: currently, zincati fails to start on systems with OCI based deployments (like uCore). Upstream efforts are active to correct this.

Note: per cockpit instructions the cockpit-ws RPM is not installed, rather it is provided as a pre-defined systemd service which runs a podman container.

ucore-hci

Hyper-Coverged Infrastructure(HCI) refers to storage and virtualization in one place... So this image is suitable for use as a hypervisor, storage server(NAS), as well as running containerized workloads). Accordingingly, it will be a bit larger due to extra hardware support, storage and virtualization packages.

  • Starts with ucore to give you everything above, plus:
  • Adds the following:
    • cockpit-machines: Cockpit GUI for managing virtual machines
    • duperemove
    • intel wifi firmware - CoreOS omits this despite including atheros wifi firmware... hardware enablement FTW
    • libvirt-client: virsh command-line utility for managing virtual machines
    • libvirt-daemon-kvm: libvirt KVM hypervisor management
    • mergerfs
    • virt-install: command-line utility for installing virtual machines

Note: Fedora now uses DefaultTimeoutStop=45s for systemd services which could cause libvirtd to quit before shutting down slow VMs. Consider adding TimeoutStopSec=120s as an override for libvirtd.service if needed.

fedora-coreos-zfs

Tips and Tricks

Immutability and Podman

These images are immutable and you probably shouldn't install packages like in a mutable "normal" distribution.

Fedora CoreOS expects the user to run services using podman. moby-engine, the free Docker implementation, is installed for those who desire docker instead of podman.

Default Services

To maintain this image's suitability as a minimal container host, most add-on services are not auto-enabled.

To activate pre-installed services (cockpit, docker, tailscaled, etc):

sudo systemctl enable --now SERVICENAME.service

Note: libvirtd is enabled by default, but only starts when triggerd by it's socket (eg, using virsh or other clients).

Docker/Moby and Podman

NOTE: CoreOS cautions against running podman and docker containers at the same time. Thus, docker.socket is disabled by default to prevent accidental activation of the docker daemon, given podman is the default.

Distrobox

Users may use distrobox to run images of mutable distributions where applications can be installed with traditional package managers. This may be useful for installing interactive utilities such has htop, nmap, etc. As stated above, however, services should run as containers.

CoreOS and ostree Docs

It's a good idea to become familar with the Fedora CoreOS Documentation as well as the CoreOS rpm-ostree docs. Note especially, this image is only possible due to ostree native containers.

Sanoid/Syncoid

sanoid/syncoid is a great tool for manual and automated snapshot/transfer of ZFS datasets. However, there is not a current stable RPM, rather they provide instructions on installing via git.

ucore has pre-install all the (lightweight) required dependencies (perl-Config-IniFiles perl-Data-Dumper perl-Capture-Tiny perl-Getopt-Long lzop mbuffer mhash pv), such that a user wishing to use sanoid/syncoid only need install the "sbin" files and create configuration/systemd units for it.

ZFS

The ZFS kernel module and tools are pre-installed, but like other services, ZFS is not pre-configured to load on default.

Load it with the command modprobe zfs and use zfs and zpool commands as desired.

Per the OpenZFS Fedora documentation:

By default ZFS kernel modules are loaded upon detecting a pool. To always load the modules at boot:

echo zfs > /etc/modules-load.d/zfs.conf

ZFS and immutable root filesystem

The default mountpoint for any newly created zpool tank is /tank. This is a problem in CoreOS as the root filesystem (/) is immutable, which means a directory cannot be created as a mountpoint for the zpool. An example of the problem looks like this:

# zpool create tank /dev/sdb
cannot mount '/tank': failed to create mountpoint: Operation not permitted

To avoid this problem, always create new zpools with a specified mountpoint:

# zpool create -m /var/tank tank /dev/sdb

If you do forget to specify the mountpoint, or you need to change the mountpoint on an existing zpool:

# zfs set mountpoint=/var/tank tank

How to Install

Prerequsites

This image is not currently available for direct install. The user must follow the CoreOS installation guide. There are varying methods of installation for bare metal, cloud providers, and virtualization platforms.

All CoreOS installation methods require the user to produce an Ignition file. This Ignition file should, at mimimum, set a password and SSH key for the default user (default username is core).

Install and Manually Rebase

You can rebase any Fedora CoreOS x86_64 installation to uCore. Installing CoreOS itself can be done through a number of provisioning methods.

To rebase an Fedora CoreOS machine to the latest uCore (stable):

  1. Execute the rpm-ostree rebase command (below) with desired IMAGE and TAG.
  2. Reboot, as instructed.
  3. After rebooting, you should pin the working deployment which allows you to rollback if required.
sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/IMAGE:TAG
IMAGE TAG
ucore stable, testing, stable-zfs, testing-zfs
ucore-hci stable, testing, stable-zfs, testing-zfs
fedora-coreos-zfs stable, testing

Install with Auto-Rebase

Your path to a running uCore can be shortend by using examples/ucore-autorebase.butane as the starting point for your CoreOS ignition file.

  1. As usual, you'll need to follow the docs to setup a password. Substitute your password hash for YOUR_GOOD_PASSWORD_HASH_HERE in the ucore-autorebase.butane file, and add your ssh pub key while you are at it.
  2. Generate an ignition file from your new ucore-autorebase.butane using the butane utility.
  3. Now install CoreOS for hypervisor, cloud provider or bare-metal. Your ignition file should work for any platform, auto-rebasing to the ucore:stable (or other IMAGE:TAG combo), rebooting and leaving your install ready to use.

Verification

These images are signed with sigstore's cosign. You can verify the signature by downloading the cosign.pub key from this repo and running the following command:

cosign verify --key cosign.pub ghcr.io/ublue-os/ucore
Description
No description provided
Readme Apache-2.0 432 KiB
Languages
Shell 79.8%
Dockerfile 11.2%
Just 9%