April 2023 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

Mailing lists (except "announce") are now archived, discussions happening now at GitHub discussions
by Julio Gonzalez 25 Apr '23

25 Apr '23

Hello. As announced last week, the following list are now archived: - devel(a)lists.uyuni-project.org - users(a)lists.uyuni-project.org - translation(a)lists.uyuni-project.org While we will keep the following one active: - announce(a)lists.uyuni-project.org All asynchronous discussions are now happening at https://github.com/uyuni-project/uyuni/discussions And as always, remember Gitter [1] is available as well for synchronous discussions. Happy hacking! https://www.uyuni-project.org/pages/contact.html#gitter -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Mailing lists (except "announce") to be archived on April 24th, moving to GitHub discussions
by Julio Gonzalez 20 Apr '23

20 Apr '23

Hello, As agreed by the community at https://github.com/uyuni-project/uyuni/discussions/6821, after two weeks collecting votes, we will be moving from mailing lists to GitHub Discussions (https://github.com/uyuni-project/uyuni/discussions) This means we will archive the following mailing lists: - devel(a)lists.uyuni-project.org - users(a)lists.uyuni-project.org - translation(a)lists.uyuni-project.org While we will keep the following one active: - announce(a)lists.uyuni-project.org Archival is going to be done on Monday morning (April 24th), and another announcement will follow to this list. We recommend avoid opening new threads on the mailing lists, and instead create discussions at GitHub, so the followups happen there, after the archival of the mailing lists. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Yet another ubuntu upgrade issue, due to package conflict
by Guillaume Rousse 18 Apr '23

18 Apr '23

Hello. Here is yet another issue with ubuntu, due this time to package conflicts. When trying to apply 5551-1, I got this error: libapache2-mod-wsgi-py3 : Conflicts: libapache2-mod-wsgi but 4.6.8-1ubuntu3.1 is to be installed The host has libapache2-mod-wsgi-4.6.8-1ubuntu3 installed, not libapache2-mod-wsgi-py3. Apparently, the command issued also results in libapache2-mod-wsgi-py3 being installed, but the resulting conflict make the transition fails. When trying to apply 5722-1, I got this error: nginx-core : Conflicts: nginx-extras but 1.18.0-0ubuntu1.4 is to be installed nginx-extras : Conflicts: nginx-core but 1.18.0-0ubuntu1.4 is to be installed The host has nginx-core-1.18.0-0ubuntu1.3 installed, not nginx-extras, but once again, something apparently pulls nginx-extras in addition, and the resulting transaction fails. I couldn't find any trace of the exact command issued. Salt minion log only has stderr/stdout, and apt/history.log only has successful command results. Regards. -- Guillaume Rousse Direction des Services Applicatifs RENATER - Paris Tel: +33 1 53 94 20 45

2 1

apt strict dependency solver blocks upgrade
by Guillaume Rousse 17 Apr '23

17 Apr '23

Hello list. All my apologies if this issue is documented elsewhere, I couldn't find anything relevant sofar. On our Ubuntu hosts, I'm frequently facing this kind of issue when attempting to apply an errata: libgssapi-krb5-2 : Depends: libkrb5-3 (= 1.16-2ubuntu0.3) but 1.16-2ubuntu0.4 is to be installed This often happens because multiple errata applies to the same package, and apt refuse to apply intermediate transactions. This is usually solved by applying errata individually, starting with the most recent one. However, this one is quite worse: Uyuni considers USN-59591-1 (https://ubuntu.com/security/notices/USN-5959-1) irrelevant, because the vulnerability only concerns the KDC itself, and we don't have any KDC installed. However, the whole krb5 package has been released and published on the mirrors, and when Uyuni attempts to update libgssapi-krb5-2 because of USN-5828-1 (https://ubuntu.com/security/notices/USN-5828-1), it fails for with the previous error message :( Excepted rewriting USN-59591-1 advisory to explicitely includes every krb5 subpackages, or to manually install this blocking update on every host, I don't know how to workaround this.

2 1

Error when adding Leap 15.4 and 15.5: child channel names already in use
by Johannes Kastl 14 Apr '23

14 Apr '23

Hi all, I successfully added the openSUSE Leap 15.5 base channel and child channels to my Uyuni server last week. Today I wanted to add 15.4 in addition, which left out two child channels: > WARNING: opensuse_leap15_4-x86_64-backports-updates: redstone.xmlrpc.XmlRpcFault: The channel name 'Update repository of openSUSE Backports (x86_64)' is already in use, please enter a different name > WARNING: opensuse_leap15_4-x86_64-sle-updates: redstone.xmlrpc.XmlRpcFault: The channel name 'Update repository with updates from SUSE Linux Enterprise 15 (x86_64)' is already in use, please enter a different name The command I used was from the docs: spacewalk-common-channels -a x86_64 opensuse_leap15_4 \ opensuse_leap15_4-uyuni-client \ opensuse_leap15_4-updates \ opensuse_leap15_4-non-oss \ opensuse_leap15_4-non-oss-updates \ opensuse_leap15_4-backports-updates \ opensuse_leap15_4-sle-updates How to solve this? 1. Can I influence the "internal" naming those channels get? The child channels names I gave on the command line included 15_4 or 15_5, but this does not seem to be reflected in the "internal" name (wherever that comes from). 2. Can I add the existing child channels (from 15.5 to the 15.4 base channel? Not sure if this is a good idea, as those are service pack (or Leap minor version dependent) IIRC. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 3

POLL: GitHub discussions or mailing lists for Uyuni for async discussions?
by Julio Gonzalez 13 Apr '23

13 Apr '23

Hello, Since GitHub discussions were enabled in 2020, we have both systems. But that means everyone is duplicating the effort, as both places need to be checked to see if the question you want to ask is there, or if there was a reply. Therefore, we need to pick one system and close the other one. NOTE: We'd still keep the mailing list for announcements You can get more details and vote at: https://github.com/uyuni-project/uyuni/discussions/6821 The poll will be open for 2 weeks, until April 19th 17.00 CEST Remember to vote! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 2

Error when adding RHEL8/9 channels: No channels matching your selection
by Johannes Kastl 06 Apr '23

06 Apr '23

Hi again, I also tried to add RHEL9 according to this documentation: https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/clie… I uploaded the three files using the exact names from the documenation (not sure if the "date" in Entitlement-Cert-date should be replaced by a date?). Anyhow, trying to add those channels simply spits out "No channels matching your selection". spacewalk-common-channels \ el9-pool-x86_64 \ el9-manager-tools-pool-x86_64 \ el9-manager-tools-updates-x86_64 Searching for channels using "spacewalk-common-channels --list" does not find them: > # spacewalk-common-channels --list|grep -i rhel > # spacewalk-common-channels --list|grep -i el9 > almalinux9-epel9: x86_64, aarch64, ppc64le, s390x > rockylinux9-epel9: x86_64, aarch64, ppc64le, s390x > # spacewalk-common-channels --list|grep -i el8 > almalinux8-epel8: x86_64, ppc64le, aarch64 > epel8: x86_64, ppc64le, aarch64 > rockylinux8-epel8: x86_64, ppc64le, aarch64 > # spacewalk-common-channels --list|grep -i el7 > epel7: > # Server version is 2023.03. RHEL8 showed the same behaviour. Any ideas? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 2