Video Recording of openSUSE Conference session which introduced the project

Core Project

MicroOS (and it's Kubernetes focused sister, Kubic) is an exciting distribution that takes much of the cool stuff we're doing in Tumbleweed, adds solutions to the problems of updating a running system, and is becoming the perfect base system for running containers.

But in openSUSE, running server stuff is only half the fun.

Why should servers be the only platform enjoying automatic, atomic, "auto-rollbackable" system updates?

Surely desktop users want to be lazy like server admins also?

Can the tools and approaches implemented in MicroOS help create the desktop distribution of the future?

Let's find out!

This Project will try to build, test, and introduce to the world the 'openSUSE MicroOS Desktop', a desktop focused variant of MicroOS based on Tumbleweed.

Sub Projects (Hackweek 18/19)

BPF powered Tor networking for flatpaks

A BPF program which can we attached to flatpaks (via CGROUP_BPF, "cgroup/skb" section) which will redirect all the egress traffic from the given flatpak to Tor network. Such a program should be trivial to write, but it will be a good alternative for running whole virtualized systems like Tails or Whonix.

openSUSE Flatpaks

in the similar way Fedora is doing that - flatpaks based on OCI images. Those OCI images could be build with kiwi. That approach gives us benefits from flatpak, but at the same time we avoid bundling libraries in each flatpak image, instead we reuse our packaging and good model of handling dependencies globally for all the software.

Hackweek 20

During Hackweek 20 (March 22-26 2021) I'm going to be working again on getting MicroOS Desktop polished and ready for primetime use.

For those interested in joining this Hackweek, I'd recommend watching the following videos to catch up with the Project's current status

Richard talking about MicroOS Generally and the Desktop current status at FOSDEM 2021

Dario talking about how he uses MicroOS Desktop already as his daily driver

Most of the Hackweek will be addressing the problems with the current builds and inventing solutions for the current main sticking points of getting MicroOS's config 'perfect' out of the box, such as configuring Flatpak with Flathub and installing some Flatpaks by default.

People can join the kubic@lists.opensuse.org mailing list to discuss issues asynchronously

We will also be on #microos-desktop on irc.freenode.org to talk to us via chat

And we'll also be on video chat on meet.opensuse.org/MicroOSDesktop as often as we can. Specific 'open hours' may be announced on the MicroOS Twitter Account

Hackweek 20 Results

After Hackweek 20 the GNOME variant of the MicroOS Desktop finally achieved [BETA] status, meaning its now feature complete and ready for most people to use, with the caveat of a small possibility of bugs/issues which will be fixed quickly.

More details can be found on this slide deck

Looking for hackers with the skills:

opensuse tumbleweed gnome flatpak kiwi obs distribution

This project is part of:

Hack Week 18 Hack Week 19 Hack Week 20 Hack Week 21

Activity

  • over 2 years ago: PeterMaris12 joined this project.
  • over 2 years ago: PeterMaris12 liked this project.
  • over 2 years ago: JonathanKang liked this project.
  • over 3 years ago: mrohde joined this project.
  • over 3 years ago: lpalovsky liked this project.
  • over 3 years ago: markgharvey liked this project.
  • over 3 years ago: bakano liked this project.
  • over 3 years ago: bakano disliked this project.
  • over 3 years ago: bakano liked this project.
  • over 3 years ago: bdekany liked this project.
  • over 3 years ago: jblainchristen liked this project.
  • over 3 years ago: hsehic joined this project.
  • over 3 years ago: acho liked this project.
  • over 3 years ago: michals liked this project.
  • over 3 years ago: radolin liked this project.
  • over 3 years ago: yfjiang liked this project.
  • over 3 years ago: salisburyk liked this project.
  • over 3 years ago: franjsco liked this project.
  • over 3 years ago: sydsb liked this project.
  • over 3 years ago: sydsb joined this project.
  • over 3 years ago: hbarnes joined this project.
  • over 3 years ago: RBrownSUSE liked this project.
  • over 4 years ago: aitvaras liked this project.
  • almost 5 years ago: vinzv liked this project.
  • almost 5 years ago: vinzv joined this project.
  • All Activity

    Comments

    • mrostecki
      almost 5 years ago by mrostecki | Reply

      I would like to join that project and propose two "subprojects" I would like to work on:

      • A BPF program which can we attached to flatpaks (via CGROUP_BPF, "cgroup/skb" section) which will redirect all the egress traffic from the given flatpak to Tor network. Such a program should be trivial to write, but it will be a good alternative for running whole virtualized systems like Tails or Whonix.
      • openSUSE flatpaks - in the similar way Fedora is doing that - flatpaks based on OCI images. Those OCI images could be build with kiwi. That approach gives us benefits from flatpak, but at the same time we avoid bundling libraries in each flatpak image, instead we reuse our packaging and good model of handling dependencies globally for all the software.

      • RBrownSUSE
        almost 5 years ago by RBrownSUSE | Reply

        +1 to both to me..lets do this! :)

      • mrostecki
        almost 5 years ago by mrostecki | Reply

        The main job here will be catching egress packets from the given cgroup and redirecting them to localhost:9050 or to whatever port the SOCKS proxy of Tor is listening to.

    • dfaggioli
      almost 5 years ago by dfaggioli | Reply

      I was wondering, how does one do development, in an environment like this. I mean, the classic dev cycle of a good old (say, for instance) C project where even just to build test it (perhaps with your changes), you'd need to install a bunch of libfoo-devel, libbar-devel, libfoo-bar-devel, etc., which I don't think one wants to install on the "main OS" and, e.g., have to reboot each time that building with a new dependency is necessary. Libvirt, QEMU, Xen could be examples, arbitrarily chosen just because they're the ones I deal with sort of on a daily basis, but I think there may well be others.

      My wild guess would be that a "toolbox like" [1] approach could work? That is, having a simple way to spin up a container inside which one can build his project? Dependencies, one would install them inside the container manually, or we can allow for stashing a (or more) "dockerfile(s)" somewhere, that can then be fine-tuned and reused...

      If this makes any sort of sense, I would like to join the project with the aim of testing such a workflow, give feedback about it and, hopefully, improve it.

      I feel like adding that I have very few experience with MicroOS/Kubic, as well as with containers in general. And although learning new things is indeed the purpose of Hackweek, I'm not sure how far I'll be able to get.

      Anyway, let me know what you think. :-)

      • fcrozat
        almost 5 years ago by fcrozat | Reply

        you mean https://kubic.opensuse.org/blog/2019-10-22-toolbox/ ? ;)

        • dfaggioli
          almost 5 years ago by dfaggioli | Reply

          I definitely do mean that! I actually meant to put that very link in my comment... see the "[1]" I have there?

          But then I guess I forgot :-) Thanks

      • mrostecki
        almost 5 years ago by mrostecki | Reply

        That's an interesting problem to solve and I was also thinking about it, but didn't come up with any solution.

        But yes, working on something "toolbox like" based on podman and container images sounds like a good approach to me.

        • fcrozat
          almost 5 years ago by fcrozat | Reply

          This would have also the good approach of developers being able to use either MicroOS Desktop or Fedora Silverblue in the same way, without the need to learn something new for our solution.

          • dfaggioli
            almost 5 years ago by dfaggioli | Reply

            Yep, indeed. Basically, this: "Toolbox: using Silverblue for development - Debarshi Ray - Flock 2019" ( https://www.youtube.com/watch?v=BGXs0W6NRBM )

        • dfaggioli
          almost 5 years ago by dfaggioli | Reply

          Ok. So I guess I'm actually joining, I will look into how toolbox actually works and see if I can come up with something similar (but different! :-D)

          • mrostecki
            almost 5 years ago by mrostecki | Reply

            Can't we actually use toolbox and contribute to it if you are not going to find any big disadvantages of that project? It's under "containers" organization on Github - https://github.com/containers/toolbox, so IMO we shouldn't consider it to be a "Red Hat project" - SUSE contributes to various github.com/containers projects too. It seems to use podman and it doesn't seem to depend on (rpm-)ostree, so it should work on openSUSE just fine.

            • dfaggioli
              almost 5 years ago by dfaggioli | Reply

              Sure, I'm fine trying that and see if I can make it work for us. Definitely

          • mrostecki
            almost 5 years ago by mrostecki | Reply

            Maybe we could start contribution with having the openSUSE image in images/ directory ;)

          • mrostecki
            almost 5 years ago by mrostecki | Reply

            On the other hand, seems like there is a huge rewrite in Go pending https://github.com/containers/toolbox/pull/318

            • RBrownSUSE
              almost 5 years ago by RBrownSUSE | Reply

              Our toolbox we already have is already better than most other distros toolboxes..it does everything I'd ever want (except one thing..which I will fix one day) but hey if others want to look at it I dont object :)

    • RBrownSUSE
      almost 5 years ago by RBrownSUSE | Reply

      Hi all - anyone working on this project, I'm hanging out in #microos-desktop on irc.freenode.org now - we should use that to coordinate/chat :)

    • RBrownSUSE
      almost 5 years ago by RBrownSUSE | Reply

      Current Steps In Progress at Time of Writing:

      • Submit new skelcd-control-MicroOS to YaST>Factory
      • Submit new microos-patterns to Factory
      • Ensure product builds media with new patterns-microos-[gnome|kde]-desktop patterns

      At this point MicroOS ISO's should have both a KDE and GNOME system role in 'Alpha' status

      Steps that must be accomplished to reach 'Beta'

      • Some openQA testing
      • Basic working functionality like logging in, application installation, etc

      Steps to remove the ugly 'Alpha' or 'Beta' flag from the installation

      • openQA testing for boot, login, application installation and some apps running
      • No unexpected reboots/sensible rebootmgr configuration
      • Notification to the user when a reboot is required

      • RBrownSUSE
        almost 5 years ago by RBrownSUSE | Reply

        > Steps to remove the ugly 'Alpha' or 'Beta' flag from the installation

        • Both KDE and GNOME should have an optimised package list from the hacked together examples right now

      • RBrownSUSE
        almost 5 years ago by RBrownSUSE | Reply

        > Current Steps In Progress at Time of Writing: > > * Submit new skelcd-control-MicroOS to YaST>Factory > * Submit new microos-patterns to Factory > * Ensure product builds media with new patterns-microos-[gnome|kde]-desktop patterns

        https://build.opensuse.org/request/show/773663 https://build.opensuse.org/request/show/773664 https://build.opensuse.org/request/show/773665

        Above is all otw to Factory, to be staged and adjusted there

    • Cbran
      almost 5 years ago by Cbran | Reply

      Could someone show me around this?

    • dfaggioli
      almost 5 years ago by dfaggioli | Reply

      Update from me: - we're discussing (in opensuse-kubic@opensuse.org) whether/how to change our toolbox image in order for it to fulfill the requirements of https://github.com/containers/toolbox - Thorsted has pushed some of those changes to devel:kubic:containers (see: https://build.opensuse.org/package/rdiff/devel:kubic:containers/opensuse-toolbox-image?linkrev=base&rev=7 ) - I've worked on making our toolbox a little bit more comfortable to use for development: https://github.com/dfaggioli/microos-toolbox/tree/user-mode https://github.com/kubic-project/microos-toolbox/pull/2

    • dfaggioli
      almost 5 years ago by dfaggioli | Reply

      [Sorry for posting this twice, but the previous comment I wrote is barely readable! :-/]

      Update from me:

    • RBrownSUSE
      over 3 years ago by RBrownSUSE | Reply

      Hackweek 20 went well, briefest summary is currently on twitter, and will be included in the Lightning talks on Friday

      https://twitter.com/sysrich/status/1375443718132613120

    Similar Projects

    Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons

    Description

    We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.

    Goals

    Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:

    • git-annex
    • pandoc
    • xmonad
    • cabal-install

    Resources

    • https://build.opensuse.org/project/show/devel:languages:haskell/
    • https://github.com/opensuse-haskell/configuration/
    • #discuss-haskell
    • https://www.twitch.tv/peti343


    YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

    tl;dr

    Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

    See section "Result" at the bottom for the current status after the hack week.

    The Past and the Present

    We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

    You can search packages based on name, description, "requires" or "provides" level, and many more things.

    The Future

    YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

    Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

    For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

    But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

    The Idea

    YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

    For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

    For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

    Preparatory Work: Initializing the Package Subsystem

    To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

    Yes, it is: That part is already working:

    https://github.com/yast/yast-ycp-ui-bindings/pull/71

    Go there for a screenshot

    That's already halfway there.

    The complete Ruby code of this example is here. The real thing will be pure C++ without any YaST dependencies.

    The Plan


    Create openSUSE images for Arm/RISC-V boards by avicenzi

    Project Description

    Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.

    Goal for this Hackweek

    Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

    Consider generic EFI images where possible, as some boards can hold a bootloader.

    Document in the openSUSE Wiki how to flash and use the image for a given board.

    Boards that I have around and there are no images:

    • Rock 3B
    • Nano PC T3 Plus
    • Lichee RV D1
    • StartFive VisionFive (has some image needs testing)

    Hack Week 22

    Hack Week 21

    Resources


    New migration tool for Leap by lkocman

    Update

    I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

    Description

    SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

    Goals

    A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

    • Leap -> Leap n+1 (minor and major version updates)
    • Leap -> SLES docs
    • Leap -> Tumbleweed
    • Leap -> Slowroll
    • Leap Micro -> Leap Micro n+1 (minor and major version updates)
    • Leap Micro -> MicroOS

    Hackweek 24 update

    Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

    Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

    Repository

    https://github.com/openSUSE/opensuse-migration-tool

    Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

    Resources

    Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction


    Digital art wallpapers for openSUSE Leap and Tumbleweed by lkocman

    Description

    We've enrolled set of new wallpapers to both Leap 16 and Tumbleweed as part of https://news.opensuse.org/2024/10/26/leap-tw-get-makeovers/

    We've previewed digital art wallpapers which were not part of the initial drop. I'd like to spend time on hackweek to finialize my current Taipei (mountains) and Mauritius digital art wallpapers.

    Goals

    Finalize existing two digital art wallpapers for Leap and Tumbleweed https://github.com/openSUSE/branding/issues/155 Make them available as part of leap16 dir in https://github.com/openSUSE/wallpapers and update (This makes is available to Tumbleweed users as well). Update https://build.opensuse.org/package/show/X11:common:Factory/wallpapers-openSUSE-extra && Leap:16.0 && Factory.

    Resources

    https://github.com/openSUSE/branding/issues/155 The mauritius draft can be found in https://github.com/lkocman/geo-wallpapers


    Tumbleweed on Mars-CM (RISC-V board) by ph03nix

    RISC-V is awesome, Tumbleweed is awesome, chocolate cake is awesome. I'm planning to combine all of them in one project.

    Project Description

    I recently purchased a MILK-V Mars CM and managed to setup it up already using Debian Linux. My project for this Hackweek is to see how far I can get to run Tumbleweed on this compute module board.

    Goal for this Hackweek

    • Run Tumbleweed on the Compute Module

    Resources

    • http://milkv.io/mars-cm
    • https://en.opensuse.org/HCL:VisionFive2


    Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons

    Description

    We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.

    Goals

    Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:

    • git-annex
    • pandoc
    • xmonad
    • cabal-install

    Resources

    • https://build.opensuse.org/project/show/devel:languages:haskell/
    • https://github.com/opensuse-haskell/configuration/
    • #discuss-haskell
    • https://www.twitch.tv/peti343


    Write a shell extension for GNOME by tdz

    Description

    I usually do kernel and systems programming. This project is about learning more about the userspace and application side. Writing an extension to gnome-shell seems like a good place to start. The GNOME shell is scriptable via JavaScript and a number of such extension is available from upstream.

    On X11, there used to be a toy rsp. screensaver called XPenguins. After the desktop being idle for some time, it sent penguins falling down the screen and walking along window borders. It doesn't work any longer with Wayland-based compositing, but re-implementing it as extension for the GNOME shell might be possible. There already existed a port around a decade ago that could serve as starting point.

    Goals

    • Learn about how shell extensions work and how to write one
    • See if XPenguins can be converted
    • If successful, try to upstream the result

    Resources


    Explore the integration between OBS and GitHub by pdostal

    Project Description

    The goals:

    1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.

    Goal for this Hackweek

    Do as much as possible, blog about it and maybe use it another existing project.

    Resources


    Git CI to automate the creation of product definition by gyribeiro

    Description

    Automate the creation of product definition

    Goals

    Create a Git CI that will:

    • automatically be triggered once a change (commit) in package list is done.
    • run tool responsible to update product definition based on the changes in package list
    • test the updated product definition in OBS
    • submit a pull request updating the product definition in the repository

    NOTE: this Git CI may also be triggered manually

    Resources

    • https://docs.gitlab.com/ee/ci/
    • https://openbuildservice.org/2021/05/31/scm-integration/
    • https://github.com/openSUSE/openSUSE-release-tools


    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    FUSS

    FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

    https://fuss.bz.it/

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
    • [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
    • [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
    • [W] Applying any basic salt state (including a formula)
    • [W] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources


    Research openqa-trigger-from-obs and openqa-trigger-from-ibs-plugin by qwang

    Description

    openqa-trigger-from-obs project is a framework that OSD is using it to automatically sync the defined images and repositories from OBS/IBS to its assets for testing. This framework very likely will be used for the synchronize to each location's openqa include openqa.qa2.suse.asia Beijing local procy scc scc-proxy.suse.asia(although it's not a MUST to our testing) it's now rewriting requests to openqa.qa2.suse.asia instead of openqa.suse.de, the assets/repo should be consistent the format Beijing local openQA is maintaining an own script but still need many manually activities when new build comes, and not consistent to OSD, that will request many test code change due to CC network change

    Goals

    Research this framework in case it will be re-used for Beijing local openQA, and will need to be setup and maintained by ourselves

    Resources

    https://github.com/os-autoinst/openqa-trigger-from-obs/tree/master https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin

    beijing :rainbow machine


    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    FUSS

    FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

    https://fuss.bz.it/

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
    • [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
    • [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
    • [W] Applying any basic salt state (including a formula)
    • [W] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement


    Switch software-o-o to parse repomd data by hennevogel

    Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org


    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