{"id":13559861,"url":"https://github.com/ublue-os/ucore","last_synced_at":"2025-05-16T07:07:46.121Z","repository":{"id":151453156,"uuid":"614494866","full_name":"ublue-os/ucore","owner":"ublue-os","description":"An OCI base image of Fedora CoreOS with batteries included","archived":false,"fork":false,"pushed_at":"2025-05-14T19:18:33.000Z","size":272,"stargazers_count":306,"open_issues_count":26,"forks_count":46,"subscribers_count":18,"default_branch":"main","last_synced_at":"2025-05-14T20:31:03.764Z","etag":null,"topics":["coreos","fedora","linux","oci"],"latest_commit_sha":null,"homepage":"https://projectucore.io","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ublue-os.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-03-15T17:43:32.000Z","updated_at":"2025-05-11T05:48:28.000Z","dependencies_parsed_at":"2023-10-04T11:56:42.551Z","dependency_job_id":"f986fa20-12b5-4436-92d0-5072ad96f7fe","html_url":"https://github.com/ublue-os/ucore","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ublue-os%2Fucore","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ublue-os%2Fucore/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ublue-os%2Fucore/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ublue-os%2Fucore/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ublue-os","download_url":"https://codeload.github.com/ublue-os/ucore/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254485065,"owners_count":22078767,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["coreos","fedora","linux","oci"],"created_at":"2024-08-01T13:00:34.524Z","updated_at":"2025-05-16T07:07:41.114Z","avatar_url":"https://github.com/ublue-os.png","language":"Shell","funding_links":[],"categories":["linux","Shell"],"sub_categories":[],"readme":"# uCore \u003c!-- omit in toc --\u003e\n\n[![stable](https://github.com/ublue-os/ucore/actions/workflows/build-stable.yml/badge.svg)](https://github.com/ublue-os/ucore/actions/workflows/build-stable.yml)\n[![testing](https://github.com/ublue-os/ucore/actions/workflows/build-testing.yml/badge.svg)](https://github.com/ublue-os/ucore/actions/workflows/build-testing.yml)\n\nuCore is an OCI image of [Fedora CoreOS](https://getfedora.org/coreos/) with \"batteries included\". More specifically, it's an opinionated, custom CoreOS image, built daily with some common tools added in. The idea is to make a lightweight server image including commonly used services or the building blocks to host them.\n\nPlease take a look at the included modifications, and help us improve uCore if the project interests you.\n\n## Table of Contents \u003c!-- omit in toc --\u003e\n\n- [Announcements](#announcements)\n- [Features](#features)\n  - [Images](#images)\n    - [`fedora-coreos`](#fedora-coreos)\n    - [`ucore-minimal`](#ucore-minimal)\n    - [`ucore`](#ucore)\n    - [`ucore-hci`](#ucore-hci)\n  - [Tag Matrix](#tag-matrix)\n- [Installation](#installation)\n  - [Image Verification](#image-verification)\n  - [Auto-Rebase Install](#auto-rebase-install)\n  - [Manual Install/Rebase](#manual-installrebase)\n- [Tips and Tricks](#tips-and-tricks)\n  - [CoreOS and ostree Docs](#coreos-and-ostree-docs)\n  - [Podman](#podman)\n    - [Immutability and Podman](#immutability-and-podman)\n    - [Docker/Moby and Podman](#dockermoby-and-podman)\n    - [Podman and FirewallD](#podman-and-firewalld)\n    - [Automatically start containers on boot](#automatically-start-containers-on-boot)\n  - [Default Services](#default-services)\n  - [SELinux Troubleshooting](#selinux-troubleshooting)\n  - [Distrobox](#distrobox)\n  - [NAS - Storage](#nas---storage)\n    - [NFS](#nfs)\n    - [Samba](#samba)\n  - [SecureBoot w/ kmods](#secureboot-w-kmods)\n  - [NVIDIA](#nvidia)\n    - [Included Drivers](#included-drivers)\n    - [Other Drivers](#other-drivers)\n  - [ZFS](#zfs)\n    - [ZFS and immutable root filesystem](#zfs-and-immutable-root-filesystem)\n    - [Sanoid/Syncoid](#sanoidsyncoid)\n- [DIY](#diy)\n- [Metrics](#metrics)\n\n## Announcements\n\n### 2024.11.12 - uCore has updated to Fedora 41\n\nAs of today our upstream Fedora CoreOS stable image updated to Fedora 41 under the hood, so expect a lot of package updates.\n\n### 2024.11.12 - uCore *stable* has pinned to kernel version *6.11.3*\n\nKernel version `6.11.3` was the previous *stable* update's kernel, and despite the update to Fedora 41, we've stuck with `6.11.3` rather than updating to `6.11.5` from upstream.\n\nThis is due to a kernel bug in versions `6.11.4`/`6.11.5` which [breaks tailscale status reporting](https://github.com/tailscale/tailscale/issues/13863). As many users of uCore do use tailscale, we've decided to be extra cautious and hold back the kernel, even though the rest of stable updated as usual.\n\nWe expect the next update of Fedora CoreOS to be on `6.11.6` per the current state of the testing stream. So uCore will follow when that update occurs.\n\n## Features\n\nThe uCore project builds four images, each with different tags for different features.\n\nThe image names are:\n\n- [`fedora-coreos`](#fedora-coreos)\n- [`ucore-minimal`](#ucore-minimal)\n- [`ucore`](#ucore)\n- [`ucore-hci`](#ucore-hci)\n\nThe [tag matrix](#tag-matrix) includes combinations of the following:\n\n- `stable` - for an image based on the Fedora CoreOS stable stream\n- `testing` - for an image based on the Fedora CoreOS testing stream\n- `nvidia` - for an image which includes nvidia driver and container runtime\n- `zfs` - for an image which includes zfs driver and tools\n\n### Images\n\n#### `fedora-coreos`\n\n\u003e [!IMPORTANT]\n\u003e This was previously named `fedora-coreos-zfs`, but that version of the image did not offer the nvidia option. If on the previous image name, please rebase with `rpm-ostree rebase`.\n\nA generic [Fedora CoreOS image](https://quay.io/repository/fedora/fedora-coreos?tab=tags) image with choice of add-on kernel modules:\n\n- [nvidia versions](#tag-matrix) add:\n  - [nvidia driver](https://github.com/ublue-os/akmods) - latest driver built from negativo17's akmod package\n  - [nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/sample-workload.html) - latest toolkit which supports both root and rootless podman containers and CDI\n  - [nvidia container selinux policy](https://github.com/NVIDIA/dgx-selinux/tree/master/src/nvidia-container-selinux) - allows using `--security-opt label=type:nvidia_container_t` for some jobs (some will still need `--security-opt label=disable` as suggested by nvidia)\n- [ZFS versions](#tag-matrix) add:\n  - [ZFS driver](https://github.com/ublue-os/akmods) - latest driver (currently pinned to 2.2.x series)\n\n\u003e [!NOTE]\n\u003e zincati fails to start on all systems with OCI based deployments (like uCore). Upstream efforts are active to develop an alternative.\n\n#### `ucore-minimal`\n\nSuitable for running containerized workloads on either bare metal or virtual machines, this image tries to stay lightweight but functional.\n\n- Starts with a [Fedora CoreOS image](https://quay.io/repository/fedora/fedora-coreos?tab=tags)\n- Adds the following:\n  - [bootc](https://github.com/containers/bootc) (new way to update container native systems)\n  - [cockpit](https://cockpit-project.org) (podman container and system management)\n  - [firewalld](https://firewalld.org/)\n  - guest VM agents (`qemu-guest-agent` and `open-vm-tools`))\n  - [docker-buildx](https://github.com/docker/buildx) and [docker-compose](https://github.com/docker/compose) (versions matched to moby release) *docker(moby-engine) is pre-installed in CoreOS*\n  - [podman-compose](https://github.com/containers/podman-compose) *podman is pre-installed in CoreOS*\n  - [tailscale](https://tailscale.com) and [wireguard-tools](https://www.wireguard.com)\n  - [tmux](https://github.com/tmux/tmux/wiki/Getting-Started)\n  - udev rules enabling full functionality on some [Realtek 2.5Gbit USB Ethernet](https://github.com/wget/realtek-r8152-linux/) devices\n- Optional [nvidia versions](#tag-matrix) add:\n  - [nvidia driver](https://github.com/ublue-os/ucore-kmods) - latest driver built from negativo17's akmod package\n  - [nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/sample-workload.html) - latest toolkit which supports both root and rootless podman containers and CDI\n  - [nvidia container selinux policy](https://github.com/NVIDIA/dgx-selinux/tree/master/src/nvidia-container-selinux) - allows using `--security-opt label=type:nvidia_container_t` for some jobs (some will still need `--security-opt label=disable` as suggested by nvidia)\n- Optional [ZFS versions](#tag-matrix) add:\n  - [ZFS driver](https://github.com/ublue-os/ucore-kmods) - latest driver (currently pinned to 2.2.x series) - [see below](#zfs) for details\n  - `pv` is installed with zfs as a complementary tool\n- Disables Zincati auto upgrade/reboot service\n- Enables staging of automatic system updates via rpm-ostreed\n- Enables password based SSH auth (required for locally running cockpit web interface)\n- Provides public key allowing [SecureBoot](#secureboot) (for ucore signed `nvidia` or `zfs` drivers)\n\n\u003e [!IMPORTANT]\n\u003e Per [cockpit's instructions](https://cockpit-project.org/running.html#coreos) the cockpit-ws RPM is **not** installed, rather it is provided as a pre-defined systemd service which runs a podman container.\n\n#### `ucore`\n\nThis image builds on `ucore-minimal` but adds drivers, storage tools and utilities making it more useful on bare metal or as a storage server (NAS).\n\n- Starts with a [`ucore-minimal`](#ucore-minimal) image providing everything above, plus:\n- Adds the following:\n  - [cockpit-storaged](https://cockpit-project.org) (udisks2 based storage management)\n  - [distrobox](https://github.com/89luca89/distrobox) - a [toolbox](https://containertoolbx.org/) alternative\n  - [duperemove](https://github.com/markfasheh/duperemove)\n  - all wireless (wifi) card firmwares (CoreOS does not include them) - hardware enablement FTW\n  - [mergerfs](https://github.com/trapexit/mergerfs)\n  - nfs-utils - nfs utils including daemon for kernel NFS server\n  - [pcp](https://pcp.io) Performance Co-pilot monitoring\n  - [rclone](https://www.rclone.org/) - file synchronization and mounting of cloud storage\n  - [samba](https://www.samba.org/) and samba-usershares to provide SMB sevices\n  - [snapraid](https://www.snapraid.it/)\n  - usbutils(and pciutils) - technically pciutils is pulled in by open-vm-tools in ucore-minimal\n- Optional [ZFS versions](#tag-matrix) add:\n  - [cockpit-zfs-manager](https://github.com/45Drives/cockpit-zfs-manager) (an interactive ZFS on Linux admin package for Cockpit)\n  - [sanoid/syncoid dependencies](https://github.com/jimsalterjrs/sanoid) - [see below](#zfs) for details\n\n#### `ucore-hci`\n\nHyper-Coverged Infrastructure(HCI) refers to storage and hypervisor in one place... This image primarily adds libvirt tools for virtualization.\n\n- Starts with a [`ucore`](#ucore) image providing everything above, plus:\n- Adds the following:\n  - [cockpit-machines](https://github.com/cockpit-project/cockpit-machines): Cockpit GUI for managing virtual machines\n  - [libvirt-client](https://libvirt.org/): `virsh` command-line utility for managing virtual machines\n  - [libvirt-daemon-kvm](https://libvirt.org/): libvirt KVM hypervisor management\n  - virt-install: command-line utility for installing virtual machines\n\n\u003e [!NOTE]\n\u003e Fedora 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.\n\n### Tag Matrix\n\n| IMAGE | TAG |\n|-|-|\n| [`fedora-coreos`](#fedora-coreos) - *stable* | `stable-nvidia`, `stable-zfs`,`stable-nvidia-zfs` |\n| [`fedora-coreos`](#fedora-coreos) - *testing* | `testing-nvidia`, `testing-zfs`, `testing-nvidia-zfs` |\n| [`ucore-minimal`](#ucore-minimal) - *stable* | `stable`, `stable-nvidia`, `stable-zfs`,`stable-nvidia-zfs` |\n| [`ucore-minimal`](#ucore-minimal) - *testing* | `testing`, `testing-nvidia`, `testing-zfs`, `testing-nvidia-zfs` |\n| [`ucore`](#ucore) - *stable* | `stable`, `stable-nvidia`, `stable-zfs`,`stable-nvidia-zfs` |\n| [`ucore`](#ucore) - *testing* | `testing`, `testing-nvidia`, `testing-zfs`, `testing-nvidia-zfs` |\n| [`ucore-hci`](#ucore-hci) - *stable* | `stable`, `stable-nvidia`, `stable-zfs`,`stable-nvidia-zfs` |\n| [`ucore-hci`](#ucore-hci) - *testing* | `testing`, `testing-nvidia`, `testing-zfs`, `testing-nvidia-zfs` |\n\n## Installation\n\n\u003e [!IMPORTANT]\n\u003e **Read the [CoreOS installation guide](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/)** before attempting installation. uCore extends Fedora CoreOS; it does not provide it's own custom or GUI installer.\n\nThere are varying methods of installation for bare metal, cloud providers, and virtualization platforms.\n\n**All CoreOS installation methods require the user to [produce an Ignition file](https://docs.fedoraproject.org/en-US/fedora-coreos/producing-ign/).** This Ignition file should, at mimimum, set a password and SSH key for the default user (default username is `core`).\n\n\u003e [!TIP]\n\u003e For bare metal installs, first test your ignition configuration by installing in a VM (or other test hardware) using the bare metal process.\n\n### Image Verification\n\nThese images are signed with sigstore's [cosign](https://docs.sigstore.dev/cosign/overview/). You can verify the signature by running the following command:\n\n```bash\ncosign verify --key https://github.com/ublue-os/ucore/raw/main/cosign.pub ghcr.io/ublue-os/IMAGE:TAG\n```\n\n### Auto-Rebase Install\n\nOne of the fastest paths to running uCore is using [examples/ucore-autorebase.butane](examples/ucore-autorebase.butane) as a template for your CoreOS butane file.\n\n1. As usual, you'll need to [follow the docs to setup a password](https://coreos.github.io/butane/examples/#using-password-authentication). 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.\n1. Generate an ignition file from your new `ucore-autorebase.butane` [using the butane utility](https://coreos.github.io/butane/getting-started/).\n1. Now install CoreOS for [hypervisor, cloud provider or bare-metal](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/), i.e. `sudo coreos-installer install /dev/nvme0n1 --ignition-url https://example.com/ucore-autorebase.ign` (or `--ignition-file /path/to/ucore-autorebase.ign`). 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.\n\n### Manual Install/Rebase\n\nOnce a machine is running any Fedora CoreOS version, you can easily rebase to uCore.  Installing CoreOS itself can be done through [a number of provisioning methods](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/).\n\n\u003e [!WARNING]\n\u003e **Rebasing from Fedora IoT or Atomic Desktops is not supported!**\n\u003e If ignition doesn't provide a desired feature, then Fedora CoreOS doesn't support that feature. Rebasing from another system to gain a filesystem feature or GUI installation is very likely to cause problems later on.\n\nTo rebase an existing CoreOS machine to the latest uCore:\n\n1. Execute the `rpm-ostree rebase` command (below) with desired `IMAGE` and `TAG`.\n1. Reboot, as instructed.\n1. After rebooting, you should [pin the working deployment](https://docs.fedoraproject.org/en-US/fedora-silverblue/faq/#_how_can_i_upgrade_my_system_to_the_next_major_version_for_instance_rawhide_or_an_upcoming_fedora_release_branch_while_keeping_my_current_deployment) which allows you to rollback if required.\n\n```bash\nsudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/IMAGE:TAG\n```\n\n#### Verified Image Updates \u003c!-- omit in toc --\u003e\n\nThe `ucore*` images include container policies to support image verification for improved trust of upgrades. Once running one of the `ucore*` images, the following command will rebase to the verified image reference:\n\n```bash\nsudo rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/IMAGE:TAG\n```\n\n\u003e [!NOTE]\n\u003e This policy is not included with `fedora-coreos:*` as those images are kept very stock.*\n\n## Tips and Tricks\n\n### CoreOS and ostree Docs\n\nIt's a good idea to become familar with the [Fedora CoreOS Documentation](https://docs.fedoraproject.org/en-US/fedora-coreos/) as well as the [CoreOS rpm-ostree docs](https://coreos.github.io/rpm-ostree/). Note especially, this image is only possible due to [ostree native containers](https://coreos.github.io/rpm-ostree/container/).\n\n### Podman\n\n#### Immutability and Podman\n\nA CoreOS root filesystem system is immutable at runtime, and it is not recommended to install packages like in a mutable \"normal\" distribution.\n\nFedora CoreOS expects the user to run services using [podman](https://podman.io). `moby-engine`, the free Docker implementation, is also installed for those who desire docker instead of podman.\n\n#### Docker/Moby and Podman\n\n\u003e [!IMPORTANT]\n\u003e CoreOS [cautions against](https://docs.fedoraproject.org/en-US/fedora-coreos/faq/#_can_i_run_containers_via_docker_and_podman_at_the_same_time) 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.\n\u003e\n\u003e Only run both simultaneously if you understand the risk.\n\n#### Podman and FirewallD\n\nPodman and firewalld [can sometimes conflict](https://github.com/ublue-os/ucore/issues/90) such that a `firewall-cmd --reload` removes firewall rules generated by podman.\n\nAs of [netavark v1.9.0](https://blog.podman.io/2023/11/new-netavark-firewalld-reload-service/) a service is provided to handle re-adding netavark (Podman) firewall rules after a firewalld reload occurs.  If needed, enable like so: `systemctl enable netavark-firewalld-reload.service`\n\n#### Automatically start containers on boot\n\nBy default, UCore does not automatically start `restart: always` containers on system boot, however this can be easily enabled:\n\n##### For containers running under the `core` user\n\n```bash\n# Copy the system's podman-restart service to the user location\nmkdir -p /var/home/core/.config/systemd/user\ncp /lib/systemd/system/podman-restart.service /var/home/core/.config/systemd/user\n\n# Enable the user service\nsystemctl --user enable podman-restart.service\n\n# Check that it's running\nsystemctl --user list-unit-files | grep podman\n```\n\nWhen you next reboot the system, your `restart: always` containers will automatically start.\n\nYou may also need to enable “linger” mode on your user session, to prevent containers exiting which you have started interactively. To do that, run:\n\n```bash\nloginctl enable-linger $UID\n```\n\nYou can find more information regarding this on the [Podman troubleshooting page](https://github.com/containers/podman/blob/main/troubleshooting.md#21-a-rootless-container-running-in-detached-mode-is-closed-at-logout).\n\n##### For containers running under the root user (rootful containers)\n\nYou just need to enable the built-in service:\n\n```bash\nsudo systemctl enable podman-restart.service\n```\n\n### Default Services\n\nTo maintain this image's suitability as a minimal container host, most add-on services are not auto-enabled.\n\nTo activate pre-installed services (`cockpit`, `docker`, `tailscaled`, etc):\n\n```bash\nsudo systemctl enable --now SERVICENAME.service\n```\n\n\u003e [!NOTE]\n\u003e The `libvirtd` is enabled by default, but only starts when triggerd by it's socket (eg, using `virsh` or other clients).\n\n### SELinux Troubleshooting\n\nSELinux is an integral part of the Fedora Atomic system design. Due to a few interelated issues, if SELinux is disabled, it's difficult to re-enable.\n\n\u003e [!WARNING]\n\u003e **We STRONGLY recommend: DO NOT DISABLE SELinux!**\n\nShould you suspect that SELinux is causing a problem, it is easy to enable permissive mode at runtime, which will keep SELinux functioning, provide reporting of problems, but not enforce restrictions.\n\n```bash\n# setenforce 0\n$ getenforce\nPermissive\n```\n\nAfter the problem is resolved, don't forget to re-enable:\n\n```bash\n# setenforce 1\n$ getenforce\nEnforcing\n```\n\nFedora provides useful docs on [SELinux troubleshooting](https://docs.fedoraproject.org/en-US/quick-docs/selinux-troubleshooting/).\n\n### Distrobox\n\nUsers may use [distrobox](https://github.com/89luca89/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.\n\n### NAS - Storage\n\n`ucore` includes a few packages geared towards a storage server which will require individual research for configuration:\n\n- [duperemove](https://github.com/markfasheh/duperemove)\n- [mergerfs](https://github.com/trapexit/mergerfs)\n- [snapraid](https://www.snapraid.it/)\n\nBut two others are included, which though common, warrant some explanation:\n\n- nfs-utils - replaces a \"light\" version typically in CoreOS to provide kernel NFS server\n- samba and samba-usershares - to provide SMB sevices\n\n#### NFS\n\nIt's suggested to read Fedora's [NFS Server docs](https://docs.fedoraproject.org/en-US/fedora-server/services/filesharing-nfs-installation/) plus other documentation to understand how to setup this service. But here's a few quick tips...\n\n##### Firewall - NFS \u003c!-- omit in toc --\u003e\n\nUnless you've disabled `firewalld`, you'll need to do this:\n\n```bash\nsudo firewall-cmd --permanent --zone=FedoraServer --add-service=nfs\nsudo firewall-cmd --reload\n```\n\n##### SELinux - NFS \u003c!-- omit in toc --\u003e\n\nBy default, nfs-server is blocked from sharing directories unless the context is set. So, generically to enable NFS sharing in SELinux run:\n\nFor read-only NFS shares:\n\n```bash\nsudo semanage fcontext --add --type \"public_content_t\" \"/path/to/share/ro(/.*)?\"\nsudo restorecon -R /path/to/share/ro\n```\n\nFor read-write NFS shares:\n\n```bash\nsudo semanage fcontext --add --type \"public_content_rw_t\" \"/path/to/share/rw(/.*)?\"\nsudo restorecon -R /path/to/share/rw\n```\n\nSay you wanted to share all home directories:\n\n```bash\nsudo semanage fcontext --add --type \"public_content_rw_t\" \"/var/home(/.*)?\"\nsudo restorecon -R /var/home\n```\n\nThe least secure but simplest way to let NFS share anything configured, is...\n\nFor read-only:\n\n```bash\nsudo setsebool -P nfs_export_all_ro 1\n```\n\nFor read-write:\n\n```bash\nsudo setsebool -P nfs_export_all_rw 1\n```\n\nThere is [more to read](https://linux.die.net/man/8/nfs_selinux) on this topic.\n\n##### Shares - NFS \u003c!-- omit in toc --\u003e\n\nNFS shares are configured in `/etc/exports` or `/etc/exports.d/*` (see docs).\n\n##### Run It - NFS \u003c!-- omit in toc --\u003e\n\nLike all services, NFS needs to be enabled and started:\n\n```bash\nsudo systemctl enable --now nfs-server.service\nsudo systemctl status nfs-server.service\n```\n\n#### Samba\n\nIt's suggested to read Fedora's [Samba docs](https://docs.fedoraproject.org/en-US/quick-docs/samba/) plus other documentation to understand how to setup this service. But here's a few quick tips...\n\n##### Firewall - Samba \u003c!-- omit in toc --\u003e\n\nUnless you've disabled `firewalld`, you'll need to do this:\n\n```bash\nsudo firewall-cmd --permanent --zone=FedoraServer --add-service=samba\nsudo firewall-cmd --reload\n```\n\n##### SELinux - Samba \u003c!-- omit in toc --\u003e\n\nBy default, samba is blocked from sharing directories unless the context is set. So, generically to enable samba sharing in SELinux run:\n\n```bash\nsudo semanage fcontext --add --type \"samba_share_t\" \"/path/to/share(/.*)?\"\nsudo restorecon -R /path/to/share\n```\n\nSay you wanted to share all home directories:\n\n```bash\nsudo semanage fcontext --add --type \"samba_share_t\" \"/var/home(/.*)?\"\nsudo restorecon -R /var/home\n```\n\nThe least secure but simplest way to let samba share anything configured, is this:\n\n```bash\nsudo setsebool -P samba_export_all_rw 1\n```\n\nThere is [much to read](https://linux.die.net/man/8/samba_selinux) on this topic.\n\n##### Shares - Samba \u003c!-- omit in toc --\u003e\n\nSamba shares can be manually configured in `/etc/samba/smb.conf` (see docs), but user shares are also a good option.\n\nAn example follows, but you'll probably want to read some docs on this, too:\n\n```bash\nnet usershare add sharename /path/to/share [comment] [user:{R|D|F}] [guest_ok={y|n}]\n```\n\n##### Run It - Samba \u003c!-- omit in toc --\u003e\n\nLike all services, Samba needs to be enabled and started:\n\n```bash\nsudo systemctl enable --now smb.service\nsudo systemctl status smb.service\n```\n\n### SecureBoot w/ kmods\n\nFor those wishing to use `nvidia` or `zfs` images with pre-built kmods AND run SecureBoot, the kernel will not load those kmods until the public signing key has been imported as a MOK (Machine-Owner Key).\n\nDo so like this:\n\n```bash\nsudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der\n```\n\nThe utility will prompt for a password. The password will be used to verify this key is the one you meant to import, after rebooting and entering the UEFI MOK import utility.\n\n### NVIDIA\n\n#### Included Drivers\n\nIf you installed an image with `-nvidia` in the tag, the nvidia kernel module, basic CUDA libraries, and the nvidia-container-toolkit are all are pre-installed.\n\nNote, this does NOT add desktop graphics services to your images, but it DOES enable your compatible nvidia GPU to be used for nvdec, nvenc, CUDA, etc. Since this is CoreOS and it's primarily intended for container workloads the [nvidia container toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html) should be well understood.\n\nThe included driver is the [latest nvidia driver](https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec) as bundled by [negativo17](https://negativo17.org/nvidia-driver/). This package was chosen over rpmfusion's due to it's granular packages which allow us to install just the minimal `nvidia-driver-cuda` packages.\n\n#### Other Drivers\n\nIf you need an older (or different) driver, consider looking at the [container-toolkit-fcos driver](https://hub.docker.com/r/fifofonix/driver/). It provides pre-bundled container images with nvidia drivers for FCOS, allowing auto-build/loading of the nvidia driver IN podman, at boot, via a systemd service.\n\nIf going this path, you likely won't want to use the `ucore` `-nvidia` image, but would use the suggested systemd service. The nvidia container toolkit will still be required but can by layered easily.\n\n### ZFS\n\nIf you installed an image with `-zfs` in the tag (or `fedora-coreos-zfs`), the ZFS kernel module and tools are pre-installed, but like other services, ZFS is not pre-configured to load on default.\n\nLoad it with the command `modprobe zfs` and use `zfs` and `zpool` commands as desired.\n\nPer the [OpenZFS Fedora documentation](https://openzfs.github.io/openzfs-docs/Getting%20Started/Fedora/index.html):\n\n\u003e By default ZFS kernel modules are loaded upon detecting a pool. To always load the modules at boot:\n\n```bash\necho zfs \u003e /etc/modules-load.d/zfs.conf\n```\n\n#### ZFS and immutable root filesystem\n\nThe 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:\n\n```bash\n# zpool create tank /dev/sdb\ncannot mount '/tank': failed to create mountpoint: Operation not permitted\n```\n\nTo avoid this problem, always create new zpools with a specified mountpoint:\n\n```bash\n# zpool create -m /var/tank tank /dev/sdb\n```\n\nIf you do forget to specify the mountpoint, or you need to change the mountpoint on an existing zpool:\n\n```bash\n# zfs set mountpoint=/var/tank tank\n```\n\n#### ZFS scrub timers\n\nIt's good practice to run a `zpool scrub` periodically on ZFS pools to check and repair the integrity of data. This can be easily configured with ucore by enabling the timer. There are two timers available: weekly and monthly.\n\n```bash\n# Substitute \u003cpool\u003e with the name of the zpool\nsystemctl enable --now zfs-scrub-weekly@\u003cpool\u003e.timer\n\n# Or to run it monthly:\nsystemctl enable --now zfs-scrub-monthly@\u003cpool\u003e.timer\n```\n\nThis can be enabled for multiple storage pools by enabling and starting a timer for each.\n\n#### Sanoid/Syncoid\n\nsanoid/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](https://github.com/jimsalterjrs/sanoid/blob/master/INSTALL.md#centos).\n\n`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.\n\n## DIY\n\nIs all this too easy, leaving you with the desire to create a custom uCore image?\n\nThen [create an image `FROM ucore`](https://github.com/ublue-os/image-template) using our [image template](https://github.com/ublue-os/image-template)!\n\n## Metrics\n\n![Alt](https://repobeats.axiom.co/api/embed/07d1ed133f5ed1a1048ea6a76bfe3a23227eedd5.svg \"Repobeats analytics image\")\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fublue-os%2Fucore","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fublue-os%2Fucore","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fublue-os%2Fucore/lists"}