Edge Image Builder and mkosi for Uyuni
a project by oholecek
Updated about 1 month ago. 4 hacker ♥️. 1 follower.

Description

One part of Uyuni system management tool is ability to build custom images. Currently Uyuni supports only Kiwi image builder.

Kiwi however is not the only image building system out there and with the goal to also become familiar with other systems, this projects aim to add support for Edge Image builder and systemd's mkosi systems.

Goals

Uyuni is able to

  • provision EIB and mkosi build hosts
  • build EIB and mkosi images and store them

Resources

  • Uyuni - https://github.com/uyuni-project/uyuni
  • Edge Image builder - https://github.com/suse-edge/edge-image-builder
  • mkosi - https://github.com/systemd/mkosi

Join this project

Looking for hackers with the skills:

uyuni edge eib mkosi imagebuilding

This project is part of:

Hack Week 24

Activity

  • 29 days ago: juliogonzalezgil liked this project.
  • about 1 month ago: mweiss2 liked this project.
  • about 1 month ago: llansky3 liked this project.
  • about 1 month ago: vizhestkov liked this project.
  • about 1 month ago: oholecek added keyword "imagebuilding" to this project.
  • about 1 month ago: oholecek added keyword "uyuni" to this project.
  • about 1 month ago: oholecek added keyword "edge" to this project.
  • about 1 month ago: oholecek added keyword "eib" to this project.
  • about 1 month ago: oholecek added keyword "mkosi" to this project.
  • about 1 month ago: oholecek started this project.
  • about 1 month ago: oholecek originated this project.


    • Comments

    • oholecek
      25 days ago by oholecek | Reply

      Progress during the Hackweek

      • adapted service salt states for both EIB and mkosi and also updated original Kiwi (handling build host preparation)
      • adapted build image salt state for mkosi and original Kiwi (for actual image building)
      • adapted Java profile creation and editing to support EIB and mkosi

      TODO next:

      • adapt Java side to select correct build host variant
      • post build image inspection for EIB and mkosi and image collection

    Similar Projects

    Install Uyuni on Kubernetes in cloud-native way by cbosdonnat

    Description

    For now installing Uyuni on Kubernetes requires running mgradm on a cluster node... which is not what users would do in the Kubernetes world. The idea is to implement an installation based only on helm charts and probably an operator.

    Goals

    Install Uyuni from Rancher UI.

    Resources

    Enable the containerized Uyuni server to run on different host OS by j_renner

    Description

    The Uyuni server is provided as a container, but we still require it to run on Leap Micro? This is not how people expect to use containerized applications, so it would be great if we tested other host OSs and enabled them by providing builds of necessary tools for (e.g. mgradm). Interesting candidates should be:

    • openSUSE Leap
    • Cent OS 7
    • Ubuntu
    • ???

    Goals

    Make it really easy for anyone to run the Uyuni containerized server on whatever OS they want (with support for containers of course).

    Run local LLMs with Ollama and explore possible integrations with Uyuni by PSuarezHernandez

    Description

    Using Ollama you can easily run different LLM models in your local computer. This project is about exploring Ollama, testing different LLMs and try to fine tune them. Also, explore potential ways of integration with Uyuni.

    Goals

    • Explore Ollama
    • Test different models
    • Fine tuning
    • Explore possible integration in Uyuni

    Resources

    • https://ollama.com/
    • https://huggingface.co/
    • https://apeatling.com/articles/part-2-building-your-training-data-for-fine-tuning/

    Create SUSE Manager users from ldap/ad groups by mbrookhuis

    Description

    This tool is used to create users in SUSE Manager Server based on LDAP/AD groups. For each LDAP/AD group a role within SUSE Manager Server is defined. Also, the tool will check if existing users still have the role they should have, and, if not, it will be corrected. The same for if a user is disabled, it will be enabled again. If a users is not present in the LDAP/AD groups anymore, it will be disabled or deleted, depending on the configuration.

    The code is written for Python 3.6 (the default with SLES15.x), but will also work with newer versions. And works against SUSE Manger 4.3 and 5.x

    Goals

    Create a python and/or golang utility that will manage users in SUSE Manager based on LDAP/AD group-membership. In a configuration file is defined which roles the members of a group will get.

    Table of contents

    Installation

    To install this project, perform the following steps:

    • Be sure that python 3.6 is installed and also the module python3-PyYAML. Also the ldap3 module is needed:

    bash zypper in python3 python3-PyYAML pip install yaml

    • On the server or PC, where it should run, create a directory. On linux, e.g. /opt/sm-ldap-users

    • Copy all the file to this directory.

    • Edit the configsm.yaml. All parameters should be entered. Tip: for the ldap information, the best would be to use the same as for SSSD.

    • Be sure that the file sm-ldap-users.py is executable. It would be good to change the owner to root:root and only root can read and execute:

    bash chmod 600 * chmod 700 sm-ldap-users.py chown root:root *

    Usage

    This is very simple. Once the configsm.yaml contains the correct information, executing the following will do the magic:

    bash /sm-ldap-users.py

    repository link

    https://github.com/mbrookhuis/sm-ldap-users

    Improve Development Environment on Uyuni by mbussolotto

    Description

    Currently create a dev environment on Uyuni might be complicated. The steps are:

    • add the correct repo
    • download packages
    • configure your IDE (checkstyle, format rules, sonarlint....)
    • setup debug environment
    • ...

    The current doc can be improved: some information are hard to be find out, some others are completely missing.

    Dev Container might solve this situation.

    Goals

    Uyuni development in no time:

    • using VSCode:
      • setting.json should contains all settings (for all languages in Uyuni, with all checkstyle rules etc...)
      • dev container should contains all dependencies
      • setup debug environment
    • implement a GitHub Workspace solution
    • re-write documentation

    Lots of pieces are already implemented: we need to connect them in a consistent solution.

    Resources

    • https://github.com/uyuni-project/uyuni/wiki

    Small healthcheck tool for Longhorn by mbrookhuis

    Project Description

    We have often problems (e.g. pods not starting) that are related to PVCs not running, cluster (nodes) not all up or deployments not running or completely running. This all prevents administration activities. Having something that can regular be run to validate the status of the cluster would be helpful, and not as of today do a lot of manual tasks.

    As addition (read enough time), we could add changing reservation, adding new disks, etc. --> This didn't made it. But the scripts can easily be adopted.

    This tool would decrease troubleshooting time, giving admins rights to the rancher GUI and could be used in automation.

    Goal for this Hackweek

    At the end we should have a small python tool that is doing a (very) basic health check on nodes, deployments and PVCs. First attempt was to make it in golang, but that was taking to much time.

    Overview

    This tool will run a simple healthcheck on a kubernetes cluster. It will perform the following actions:

    • node check: This will check all nodes, and display the status and the k3s version. If the status of the nodes is not "Ready" (this should be only reported), the cluster will be reported as having problems

    • deployment check: This check will list all deployments, and display the number of expected replicas and the used replica. If there are unused replicas this will be displayed. The cluster will be reported as having problems.

    • pvc check: This check will list of all pvc's, and display the status and the robustness. If the robustness is not "Healthy", the cluster will be reported as having problems.

    If there is a problem registered in the checks, there will be a warning that the cluster is not healthy and the program will exit with 1.

    The script has 1 mandatory parameter and that is the kubeconf of the cluster or of a node off the cluster.

    The code is writen for Python 3.11, but will also work on 3.6 (the default with SLES15.x). There is a venv present that will contain all needed packages. Also, the script can be run on the cluster itself or any other linux server.

    Installation

    To install this project, perform the following steps:

    • Create the directory /opt/k8s-check

    mkdir /opt/k8s-check

    • Copy all the file to this directory and make the following changes:

    chmod +x k8s-check.py

    Build Edge Image Builder ISO with SUSE Manager by mweiss2

    Description

    With SUSE Manager, we can build OS Images using KIWI and container images. As we have Edge Image Builder, we want to see if it is possible to use SUSE Manager to build/customize OS Images by integrating Edge Image Builder as well.

    Goals

    To make the process easier for customers, a single-build pipeline that automatically adds the combustion and artifact files from the EIB process is desirable.

    • Kiwi and EIB need to come from a Git Repository.
    • Kiwi and EIB need to be running as containers.
    • Configuration options for the images used for Kiwi and EIB build.
    • X86 and ARM64 Support.
    • SUSE Manager 4.3 and 5.X Support.
    • SLES 15 SP6 / SL Micro 6.0 and SL Micro 6.1 Support.

    Outcome

    • Change the Kiwi build process to use Podman with the Kiwi image registry.suse.com/bci/kiwi:10.1.10
    • Change the Edge Image Builder to produce a combustion-only ISO
    • Extract the contents and write them to a dedicated /OEM partition integrated via Kiwi into the ISO Kiwi creates.

    Sources and PRs

    • https://github.com/Martin-Weiss/kiwi-image-micro-gpu-60
    • https://github.com/suse-edge/edge-image-builder/pull/618
    • https://github.com/uyuni-project/uyuni/pull/9507

    Build Edge Image Builder ISO with SUSE Manager by mweiss2

    Description

    With SUSE Manager, we can build OS Images using KIWI and container images. As we have Edge Image Builder, we want to see if it is possible to use SUSE Manager to build/customize OS Images by integrating Edge Image Builder as well.

    Goals

    To make the process easier for customers, a single-build pipeline that automatically adds the combustion and artifact files from the EIB process is desirable.

    • Kiwi and EIB need to come from a Git Repository.
    • Kiwi and EIB need to be running as containers.
    • Configuration options for the images used for Kiwi and EIB build.
    • X86 and ARM64 Support.
    • SUSE Manager 4.3 and 5.X Support.
    • SLES 15 SP6 / SL Micro 6.0 and SL Micro 6.1 Support.

    Outcome

    • Change the Kiwi build process to use Podman with the Kiwi image registry.suse.com/bci/kiwi:10.1.10
    • Change the Edge Image Builder to produce a combustion-only ISO
    • Extract the contents and write them to a dedicated /OEM partition integrated via Kiwi into the ISO Kiwi creates.

    Sources and PRs

    • https://github.com/Martin-Weiss/kiwi-image-micro-gpu-60
    • https://github.com/suse-edge/edge-image-builder/pull/618
    • https://github.com/uyuni-project/uyuni/pull/9507

    Explore simple and distro indipendent declarative Linux starting on Tumbleweed or Arch Linux by janvhs

    Description

    Inspired by mkosi the idea is to experiment with a declarative approach of defining Linux systems. A lot of tools already make it possible to manage the systems infrastructure by using description files, rather than manual invocation. An example for this are systemd presets for managing enabled services or the /etc/fstab file for describing how partitions should be mounted.

    If we would take inspiration from openSUSE MicroOS and their handling of the /etc/ directory, we could theoretically use systemd-sysupdate to swap out the /usr/ partition and create an A/B boot scheme, where the /usr/ partition is always freshly built according to a central system description. In the best case it would be possible to still utilise snapshots, but an A/B root scheme would be sufficient for the beginning. This way you could get the benefit of NixOS's declarative system definition, but still use the distros package repositories and don't have to deal with the overhead of Flakes or the Nix language.

    Goals

    • A simple and understandable system
    • Check fitness of mkosi or write a simple extensible image builder tool for it
    • Create a declarative system specification
    • Create a system with swappable /usr/ partition
    • Create an A/B root scheme
    • Swap to the new system without reboot (kexec?)

    Resources

    • Ideas that have been floating around in my head for a while
    • https://0pointer.net/blog/fitting-everything-together.html
    • GNOME OS
    • MicroOS
    • systemd mkosi
    • Vanilla OS