Join the rocket chat channel! https://chat.suse.de/channel/uyuni-distros

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.

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

To consider that a distribution has basic support, we should cover at least:

  1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
  2. Onboarding (both salt and salt-ssh) (this will probably require adding OS to the bootstrap repository creator)
  3. Package management
  4. Patching
  5. Applying any basic salt state
  6. Salt remote commands

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.

My initial proposal:

Amazon Linux 2

https://aws.amazon.com/amazon-linux-2/

PR: https://github.com/uyuni-project/uyuni/pull/1919

This could be really interesting, as it's heavily used on AWS. I could have use a product like SUSE/Manager Uyuni at my former job to take care of over 100 Amazon Linux instances plus some Red Hat, Ubuntu and CentOS we had.

It's neither CentOS 7 or 8 as they do their own maintenance, but the package manager is still yum, and not dnf (so more CentoS7 like, but without binary compatibility, as they can -for example- add packages that break repositories intended for CentOS7 -as it happened to me in the past with Puppet's yum repository-).

There's also Amazon Linux 1, but it's less interesting as Standard Support ends on December 2020, and the Maintenance Support phase will only patch a few packages (https://aws.amazon.com/amazon-linux-ami/)

  • [F] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    1. To pickup the correct region to pick mirrors, a special yum plugin is required, so for the moment I am testing with eu-central-1 at spacecmd-common-channels. We should document that if we add support, so the user can adjust it.
    2. The repositories and channels get added and the patches are detected and added, but NOT the packages. The reason is that the metadata is in sqlite format NOT supported by zypper's libsolv (https://github.com/openSUSE/libsolv/issues/92) and neither supported by our reposyn (backend/satellitetools/repoplugins/yum_src.py:656). Could either enable it at libsolv, or just transform the sqlite into xml at Uyuni itself and use it.
    3. No GPG published on an URL, but making the GPG key part of the uyuni-build-keys and pointing to localhost (server itself) should fix it
  • [P] Onboarding (both salt and salt-ssh) (this will probably require adding OS to the bootstrap repository creator)
    1. After manually installing salt-minion from https://build.opensuse.org/project/show/home:juliogonzalezgil:branches:systemsmanagement:Uyuni:Master:CentOS7-Uyuni-Client-Tools I can bootstrap vía WebUI as salt minion
    2. Bootstrapping as salt-ssh minion via WebUI works
    3. Bootstrapping from script works as long as CentOS7 client tools are available, but it shows an error as it can't accept any bootstrap repo (it doesn't impact the final result: the minion gets onboarded).
  • [F] Package management
    1. Will fail, as we can't do reposync
  • [F] Patching
    1. Will fail, as we can't do reposync
  • [W] Applying any basic salt state
    1. Worked.
  • [W] Salt remote commands
    1. Worked.

IMPORTANT NOTE: Despite salt seems to work, it shows this at the minion log: 2020-02-14 16:38:31,902 [salt.loaded.int.grains.core:1854][ERROR ][5673] Broken CPE_NAME format in /etc/os-release!

Astra Linux

https://astralinux.ru/en/

PR: https://github.com/uyuni-project/uyuni/pull/1915

Originally it was a GNU/Linux developed for the Russian army and intelligence agencies, but it now offers a free (as in free beer) version for general usage. It is based on Debian GNU/Linux, so maybe getting some basic support will not be that hard.

Our team in Russia told me about it, so I joined their Telegram support channel some months ago.

Right now there are more than 1600 users at their Telegram channel (linked to Matrix.org with a bridge, which I suspect is what most of the users use) with a lot of traffic each day talking not only about support, but also about news regarding the distribution.

The distribution is now Linux Foundation Corporate Member (Silver).

  • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    1. After adding the repositories to spacewalk-common-channels works fine.
  • [W] Onboarding (both salt and salt-ssh)
    1. WebUI works (salt and salt-ssh), with some caveats: https://github.com/uyuni-project/uyuni/pull/1915
    2. I can bootstrap using a script.
  • [W] Package management
    1. Works!
  • [ ] Patching
    1. Can't test yet, no patches available.
  • [W] Applying any basic salt state
    1. Works!
  • [W] Salt remote commands
    1. Works!

Oracle Linux

https://www.oracle.com/linux/

As Spacewalk suported it, Uyuni should support it as well, but as it is not tested for a long time, maybe something is broken. Time to try again if we have time, and see what needs to be fixed.

This distribution is mostly CentOS/RHEL without the trademarks and with some goodies from Oracle, so -again- getting some basic support should not be that problematic.

As CentOS/RHEL8 full support is still on it's way, I'd propose testing Oracle Linux 7.

Debian 10/9

PR: https://github.com/uyuni-project/uyuni/pull/1917

I'd say this distribution does not need an introduction :-)

On paper the support we added for Ubuntu 16.04/18.04 should make things easier, but mgr-bootstrap-creator and susemanager-sls will require some love. The first one to allow creating bootstrap repositories, the second one to allow the bootstrap itself.

  • [ W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file) spacewalk-common-channels works fine.
  • [P] Onboarding (both salt and salt-ssh) (this will probably require adding OS to the bootstrap repository creator) 1.Added debian 9 and 10 to mgr_bootstrap_data.py, now mgr-create-bootstrap-repo works fine
    1. to do susemanager-utils/susemanager-sls/salt/bootstrap
  • [ ] Package management
    1. To be tested
  • [ ] Patching
    1. To be tested
  • [ ] Applying any basic salt state
    1. To be tested
  • [ ] Salt remote commands
    1. To be tested

Others

Interested on testing other distributions? Ping me and let's try.

[W] = works [F] = Fails [P] = in Progress

Looking for hackers with the skills:

uyuni susemanager distribution linux management testing

This project is part of:

Hack Week 19

Activity

  • 10 months ago: Pharaoh_Atem liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: pagarcia liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: jcavalheiro liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: nicoladm joined Testing GNU/Linux distributions on Uyuni
  • 10 months ago: keichwa joined Testing GNU/Linux distributions on Uyuni
  • 10 months ago: keichwa liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: nicoladm liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: nicoladm disliked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: nicoladm liked Testing GNU/Linux distributions on Uyuni
  • 10 months ago: juliogonzalezgil added keyword "testing" to Testing GNU/Linux distributions on Uyuni
  • All Activity

    Comments

    • nicoladm
      10 months ago by nicoladm | Reply

      Hi, nice project. I was trying to help with the debian 9 onboarding testing https://github.com/uyuni-project/uyuni/issues/1356 since the process is still fairly manual. Looks like mgr-create-bootstrap-repo needs tweaking https://github.com/uyuni-project/uyuni/issues/1495 i am not a developer but i can probably tweak scripts and help with some guidance

    • juliogonzalezgil
      10 months ago by juliogonzalezgil | Reply

      Hi @nicoladm

      If that's the only think that's failing, it's not so hard to fix.

      The packages to be added to a bootstrap repository by mgr-create-bootstra-repo are at https://github.com/uyuni-project/uyuni/blob/master/susemanager/src/mgrbootstrapdata.py

      You just need to add a new variable PKGLISTDEBIAN9 with the list of packages required to bootstrap with salt (salt itself and all dependencies). Most probably the list will be similar to Ubuntu18.04.

      Then at DATA you need a new entry debian8-amd64-uyuni (similar to ubuntu-18.04-amd64-uyuni) using the basechannel debian-9-pool-amd64 and adapting the rest.

      And finally, you maybe you will need to adjust https://github.com/uyuni-project/uyuni/tree/master/susemanager-utils/susemanager-sls/salt/bootstrap (specifically init.sls) if the bootstrap procedure itself fails to find the repository.

      It would be good if you can add both Debian9 and Debian10 :-)

      • nicoladm
        10 months ago by nicoladm | Reply

        systems used: KVM VM openSUSE Leap 15.1 with Uyuni 2020.01 KVM VM debian 9.9 Salt minion version: salt-minion2019.2.0+ds-1all.deb

        NOTE: The following repo as mentioned by mateiw on github should contain the patch for salt-minion deb package that suppose to fix the problems related with removing/disabling Debian repos during the bootstrap hence i am using this version salt patch (https://build.opensuse.org/package/show/systemsmanagement:saltstack:products:testing:debian/salt): https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/products:/testing:/debian/Debian_10/

        Debian 9 repos synced successfully, created a test/qa channel using the Content lifecycle section and created an activation key (1-qa-debian9-test) with the qa channels added to it.

        spacecmd softwarechannel_listchildchannels 
        
        debian-9-amd64-main-security
        debian-9-amd64-main-updates
        debian9-opensuse-salt
        debian9-servers-qa-debian9-debian-9-amd64-main-security
        debian9-servers-qa-debian9-debian-9-amd64-main-updates
        debian9-servers-qa-debian9-debian9-opensuse-salt
        
        spacecmd activationkey_listchildchannels 1-qa-debian9-test
        
        debian9-servers-qa-debian9-debian-9-amd64-main-security
        debian9-servers-qa-debian9-debian-9-amd64-main-updates
        debian9-servers-qa-debian9-debian9-opensuse-salt
        

        After the bootstrap the file pushed by salt is empty.

        /etc/apt/sources.list.d/susemanager\:channels.list 
        

        First question that is puzzling me: Is it normal that the channels are not subscribed automatically even if the activation key has the debian channells assigned correctly? Has this something to do with the susemanager-sls state you have mentioned right?

        I will have a closer look to the below files on the uyuni server tomorrow and start play with them

        /usr/share/susemanager/mgr_bootstrap_data.py
        /usr/sbin/mgr-create-bootstrap-repo
        

        • juliogonzalezgil
          10 months ago by juliogonzalezgil | Reply

          What's the content of /etc/apt/sources.list.d/susemanager\:channels.list

          Is it normal that the channels are not subscribed automatically even if the activation key has the debian channells assigned correctly?

          Well, if the activation key had the channels assigned BEFORE the onboarding, then that's a bug.

          If you add channels to an activation key AFTER the onboarding, then already onboarded clients will not get the channels.

          • nicoladm
            10 months ago by nicoladm | Reply

            What's the content of /etc/apt/sources.list.d/susemanager:channels.list

            root@debian9-uyuni:~# cat /etc/apt/sources.list/susemanager\:channels.list 
            # Channels managed by SUSE Manager
            # Do not edit this file, changes will be overwritten
            

            To double check I have tried to deselect and reselect the debian channels from the activation key and bootstrapped again and i can confirm I had the same behaviour - i needed to manually subscribe the channels from Systems --> Debian host --> Software --> Software channels because shown as none, disable service.

            Where is the place to raise this bug?

            • juliogonzalezgil
              10 months ago by juliogonzalezgil | Reply

              Did the onboarding complete without issues?

              • nicoladm
                10 months ago by nicoladm | Reply

                Not yet, at least not automatically.

                I am facing like a chicken and the egg situation where i need salt-minion-2019.2.0+ds-1.all-deb to be installed in order for the bootstrap to work properly (disable default debian channels and assign the susemanager channels and so on).

                I am looking at the bootstrap script there might be something we need to tweak there as well which is failing with:

                pkg_|-salt-minion-package_|-salt-minion_|-latest(retcode=2): No     information found for 'salt-minion'. file_|-/etc/salt/minion.d/susemanager.conf_|-/etc/salt/minion.d/susemanager.conf_|-managed(retcode=2): One or more requisite failed: bootstrap.salt-minion-package file_|-/etc/salt/pki/minion/minion.pub_|-/etc/salt/pki/minion/minion.pub_|-managed(retcode=2): One or more requisite failed: bootstrap.salt-minion-package service_|-salt-minion_|-salt-minion_|-running(retcode=2): One or more requisite failed: bootstrap.salt-minion-package, bootstrap./etc/salt/pki/minion/minion.pem, bootstrap./etc/salt/minion.d/susemanager.conf, bootstrap./etc/salt/pki/minion/minion.pub, bootstrap./etc/salt/minion_id file_|-/etc/salt/minion_id_|-/etc/salt/minion_id_|-managed(retcode=2): One or more requisite failed: bootstrap.salt-minion-package file_|-/etc/salt/pki/minion/minion.pem_|-/etc/salt/pki/minion/minion.pem_|-managed(retcode=2): One or more requisite failed: bootstrap.salt-minion-package<\code>
                

                Regarding the mgr-bootstrap i made the changes you suggested to /usr/share/susemanager/mgrbootstrapdata.py and it seems to be working fine:

                mgr-create-bootstrap-repo --with-custom-channels
                1. SLE-12-SP4-x86_64
                2. debian9-amd64-uyuni
                Enter a number of a product label: 2
                Creating bootstrap repo for debian9-amd64-uyuni
                
                copy 'libsodium18-1.0.11-2.amd64-deb'
                copy 'dctrl-tools-2.24-2+b1.amd64-deb'
                copy 'libzmq5-4.2.1-4+deb9u2.amd64-deb'
                copy 'python-chardet-2.3.0-2.all-deb'
                copy 'python-croniter-0.3.12-2.all-deb'
                copy 'python-crypto-2.6.1-7.amd64-deb'
                copy 'python-dateutil-2.5.3-2.all-deb'
                copy 'python-enum34-1.1.6-1.all-deb'
                copy 'python-ipaddress-1.0.17-1.all-deb'
                copy 'python-jinja2-2.8-1.all-deb'
                copy 'python-markupsafe-0.23-3.amd64-deb'
                copy 'python-minimal-2.7.13-2.amd64-deb'
                copy 'python-msgpack-0.4.8-1.amd64-deb'
                copy 'python-openssl-16.2.0-1.all-deb'
                copy 'python-pkg-resources-33.1.1-1.all-deb'
                copy 'python-psutil-5.0.1-1.amd64-deb'
                copy 'python-requests-2.12.4-1.all-deb'
                copy 'python-six-1.10.0-3.all-deb'
                copy 'python-systemd-233-1.amd64-deb'
                copy 'python-tornado-4.4.3-1.amd64-deb'
                copy 'python-tz-2016.7-0.3.all-deb'
                copy 'python-urllib3-1.19.1-1.all-deb'
                copy 'python-yaml-3.12-1.amd64-deb'
                copy 'python-zmq-16.0.2-2.amd64-deb'
                copy 'python-pycurl-7.43.0-2.amd64-deb'
                copy 'salt-common-2019.2.0+ds-1.all-deb'
                copy 'salt-minion-2019.2.0+ds-1.all-deb'
                copy 'dmidecode-3.0-4.amd64-deb'
                Exporting indices...
                
                ll /srv/www/htdocs/pub/repositories/debian/9/bootstrap/
                 total 0
                drwxr-xr-x 1 root root  26 Feb 11 23:21 conf
                drwxr-xr-x 1 root root 154 Feb 11 23:21 db
                drwxr-xr-x 1 root root  18 Feb 11 23:21 dists
                drwxr-xr-x 1 root root   8 Feb 11 23:21 pool
                

                • juliogonzalezgil
                  10 months ago by juliogonzalezgil | Reply

                  Is it normal that the channels are not subscribed automatically even if the activation key has the debian channells assigned correctly?

                  Then in this case, I think it normal. The first thing the bootstraping does is disabling the repositories, and then add the bootstrap repository.

                  no information found for 'salt-minion' seems to show that the package was not found, despite I can at the log you offer.

                  First, check that you can find the package at /srv/www/htdocs/pub/repositories/debian/9/bootstrap/(most probably you will).

                  If that's the case, then it's time to check the susemanage-sls package, as there is where the association between an OS and the bootstrap repository happens, according to the salt grains available during bootstrap (check susemanager-utils/susemanager-sls/salt/bootstrap/).

                  Maybe a patch is needed there, most probably at the init.sls file.

                  • juliogonzalezgil
                    10 months ago by juliogonzalezgil | Reply

                    BTW, if you can join Rocket.chat maybe we'll be able to collaborate faster than only using the website :-)

    • juliogonzalezgil
      10 months ago by juliogonzalezgil | Reply

      Having a look at Amazon Linux 2 already :-)

    • nicoladm
      10 months ago by nicoladm | Reply

      @juliogonzalezgil thanks Julio for the suggestions!! will start to do some testing hopefully this afternoon/evening

    • Pharaoh_Atem
      10 months ago by Pharaoh_Atem | Reply

      @juliogonzalezgil What about OpenMandriva? They seem interesting... add-emoji

    • juliogonzalezgil
      10 months ago by juliogonzalezgil | Reply

      @Pharaoh_Atem join and try :-D

      So far I will be happy if can complete Amazon Linux, Astra Linux and (maybe) Oracle Linux. No more time during this hackweek :-\

      So either for next hackweek, or you (or someone else) can have a look :-)

      • juliogonzalezgil
        10 months ago by juliogonzalezgil | Reply

        For reference, we are using a rocket.chat channel as so far only Nicola and I working on this.

        If someone from the community wants to join during this hackweek, we can move to Freenode or Gitter.

    • truquaeb
      9 months ago by truquaeb | Reply

      I'm trying to move away from Spacewalk, but getting stuck with my Fedora clients. It seems there aren't Uyuni client tools built for Fedora, I've got the repo's syncing and salt seems to work, machines are registered. Can't access the susemanager repos. I assume client tools need to be built, but where can I start?

      • juliogonzalezgil
        8 months ago by juliogonzalezgil | Reply

        Well, that depends. New distributions will only support salt (unless community actually takes care of maintaining traditional for them)

        You could start by creating an OBS repository based on Fedora and try to build salt there. You can use https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:CentOS8-Uyuni-Client-Tools as inspiration.

        But I guess we'd also need changes at other packages, so Uyuni is able to recognize this new distribution. My PR to Add Astra Linux (https://github.com/uyuni-project/uyuni/pull/1915) can also be used as insperation (Astra Linux is Debian Based, but even with this in mind, it can be of help).

    Similar Projects

    Uyuni: re-architecting code with Akka by moio

    Simplify the codebase by using a more _modern...


    Provisioning Prometheus exporters with Uyuni revisited by j_renner

    There is a number of annoyances and pending imp...


    Investigate options to introduce Plugins to SUSE Manager by cbosdonnat

    For years we have been discussing the idea to m...


    SUSE Manager: Better feedback for scheduled actions by fkobzik

    Motivation

    Running async actions in SUSE ...


    Uyuni: re-architecting code with Akka by moio

    Simplify the codebase by using a more _modern...


    Investigate options to introduce Plugins to SUSE Manager by cbosdonnat

    For years we have been discussing the idea to m...


    MicroOS Desktop by RBrownSUSE

    [Video Recording of openSUSE Conference sessio...


    Test functional package manager for delivering packages by jevrard

    During the week, I install guix and analyse how...


    Management 101 - mental models and cognitive biases by jcavalheiro

    Put together a collection of ideas and resource...


    labgrid: add support for sispmctl and remote ykush access by mbrugger

    labgrid [0] is an embedded board control python...


    libuitest - a generic GUI testing library by dancermak

    Testing GUIs is hard: unit tests require a ...


    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...