First experiences with Uyuni and SUSE Manager Podman images

As announced at this year's SUSECON, the new containerized SUSE Manager 5.0 was released in mid-July. The Uyuni project also offers images for the container version since version 2023.10. The most recently released version 2024.08 is the last one that is also offered as a classic RPM version.

Immutable

Compared to the previous versions, SLE Micro 5.5 and openSUSE Leap Micro 5.5 are now used - two immtuable distributions from our own ranks.

The most striking feature compared to conventional distributions is probably the package management, which is controlled via the transactional-update command. Changes are always saved in a new file system snapshot, which is loaded at the next boot. In the event of an error, the old state can be easily booted and restored. With the exception of some directories (e.g. /root, /var and /home), large parts of the operating system are read-only.

The package selection is very minimalistic: rudimentary tools such as tmux (at least there is screen) and yast2 are missing - NetworkManager comes without a TUI by default. On the first boot, the network interface is only configured correctly via DHCP. No parameters for static configurations are requested - even if the wizard suggests otherwise.

The following commands remove the DHCP configuration and perform a static IPv4 configuration:

1# nmcli con del "Wired connection 1"
2# nmcli con add con-name "Homelab" ifname eth0 type ethernet ip4 xxx.xxx.xxx.xxx/24 gw4 xxx.xxx.xxx.xxx
3# nmcli con mod "Homelab" +ipv4.dns xxx.xxx.xxx.xxx
4# nmcli con mod "Homelab" +ipv4.dns xxx.xxx.xxx.xxx
5# nmcli con up "Homelab"

Alternatively, the TUI tool can be installed later:

1# transactional-update pkg install NetworkManager-tui
2# reboot

Volume Mounts and installation

Data persisted by Uyuni and SUSE Manager is swapped to volume mounts, which can also be swapped to dedicated partitions using the mgr-storage-server tool. Unfortunately, the tool currently does not support LVM - KB article and feature request exist.

The installation of the application is much easier compared to previous versions:

1. Add repository (Uyuni) or activate extension (SUSE Manager)
2. Install a few packages (mgr{adm,ctl}{,-bash-completion} netavark)
3. Run mgradm install podman to deploy and configure the required container images

The SUMA documentation is not quite correct, the section on package installation is missing.

Automated deployment

Fortunately, the mgradm install podman command also accepts configuration parameters (such as SSL or organisation details) via YAML document. In fact, significantly more parameters are supported than the documentation suggests - the keys can be derived from the help menu:

 1# Image settings
 2image: registry.opensuse.org/uyuni/server
 3tag: latest
 4
 5# SSL settings
 6ssl:
 7  city: Darmstadt
 8  country: Germany
 9  org: Homelab
10  ou: myserver.shittyrobots.loc
11  password: HurrDurr1337
12  state: Hessen
13
14# Organization name
15organization: Homelab
16
17# Email address sending the notifications
18emailFrom: simone@shittyrobots.loc
19
20# Administrators account details
21admin:
22  password: HurrDurr1337
23  login: admin
24  firstName: Antonia
25  lastName: Administratorin
26  email: admin@shittyrobots.loc

Add software repositories

spacewalk-common-channels has long been established for configuring external software repositories. In future, however, the tool must be executed within the Podman container, as it is not available externally as a package:

1$ podman exec -ti uyuni-server spacewalk-common-channels -a x86_64 almalinux9,almalinux9-appstream-almalinux9-uyuni-client

Migration

A direct migration to a new version of the lifecycle suite is not possible, as the operating system changes as well as the application substructure (Podman). Fortunately, the mgradm migrate podman command provides a wizard that automates the data transfer. The process is documented and takes place in several steps:

1. Install a new openSUSE Leap Micro 5.5 (Uyuni) or SLE Micro 5.5 (SUSE Manager) system
2. Install the required command line tools
3. Transfer data from the legacy system via `mgradm migrate podman
4. Switch off the old system.

In addition to the package data, the migration tool also copies database contents, then stops the database and restarts the application on the new system after successful conversion. In Uyuni version 2024.10, however, there seems to be a bug that stops the database too early.

The wizard cancels the conversion of the reporting database with an error message:

1psql: error: connection to server at "localhost" (::1), port 5432 failed: FATAL:  Ident authentication failed for user "pythia_susemanager"

By chance I found out that the problem can be avoided if the source database is restarted using smdba db-start while the reindexing process is running on the new system:

112:26PM ??? Reindexing database. This may take a while, please do not cancel it!
212:31PM ??? REINDEX

1uyuni-old # smdba db-start

On some systems that I have already migrated, the PostgreSQL configuration file /var/lib/pgsql/data/pg_hba.conf was also incorrect and had to be adjusted:

 1local reportdb  postgres  peer
 2local reportdb  all scram-sha-256
 3host  reportdb  all ::/0  scram-sha-256
 4host  reportdb  all 0.0.0.0/0 scram-sha-256
 5host  reportdb  all ::1/128 scram-sha-256
 6host  reportdb  all 127.0.0.1/32  scram-sha-256
 7local uyuni postgres  peer
 8local uyuni uyuni scram-sha-256
 9host  uyuni uyuni 127.0.0.1/32  scram-sha-256
10host  uyuni uyuni ::1/128 scram-sha-256
11local replication all peer
12host  replication all ::1/128 ident
13host  replication all 127.0.0.1/32  ident
14local all all peer
15host  all all ::1/128 ident
16host  all all 127.0.0.1/32  ident
17local replication postgres  peer
18host uyuni uyuni 10.89.0.8/16 scram-sha-256

On some systems, I found duplicate hostname definitions in the /etc/rhn/rhn.conf file within the container after the migration - these must be removed or commented out for the application to start. The database host for the reporting database could also be incorrect:

1# java.hostname = uiuiuiuyuni1337
2java.hostname = uiuiuiuyuni1337
3
4# report_db_host = uiuiuiuyuni1337
5report_db_host = localhost

Another bug in version 2024.10 seems to be that the application is not started automatically when the container is started. A workaround is to start it manually within the container:

1# mgtctl term
2# spacewalk-service start
3# exit

SUSE Manager 5.0 on IBM POWER

The operation of SUSE Manager 5.0 on the IBM POWER platform is somewhat less transparent. In the download portal there are corresponding files for ppc64le, among others - but it is not entirely clear what is behind the download. The corresponding section of the documentation is not helpful here, as it suggests that SLE Micro 5.5 can be run on POWER - but this is not the case. SLE Micro 5.5 and 6.0 are not available for the ppc64le platform - this will only change with the upcoming version 6.1.

An enquiry with support revealed that the image can be run within a KVM instance. In such a scenario, SLE 15 would be installed natively in a LPAR and then the image would be run as a guest. Another option is to write the image directly to the hard drive of an LPAR using dd. Both procedures are covered by support.

I think that this problem should be solved with the next SUSE Manager release, as SUSE Linux 6.1 has just been released with official IBM POWER support.