- ARCHIVED: Uyuni Users

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

Excluding Uyuni from automatic updates/patching?
by Johannes Kastl 31 Mar '23

31 Mar '23

Good morning/evening/afternoon/night/day/... everyone, I am starting with Uyuni and am still learning new things everyday, so please excuse if this is a FAQ or already answered in the documentation. How do I exclude Uyuni and its components from being updated automatically in case of automatic updates being enabled. Maybe I am running yast2-online-update or there is another mechanism to patch/update the system periodically. As far as I read minor updates could be done this way (but might need a stop of the spacewalk services). But as there are no separate repositories for major upgrades, how to prevent the automatic updates from doing major upgrades? I thought of adding zypper locks for the packages or of disabling the repository (zypper mr -d) and only enabling it, when doing the Uyuni updates. Maybe someone can share their experiences or recommendations. Thanks in advance! 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

1 0

Community Hours tomorrow, Friday 31st, at 16.00 CEST
by Julio Gonzalez 30 Mar '23

30 Mar '23

Hello, As every last Friday of each month, we'll be having tomorrow a session of the Uyuni Community Hours. The agenda (as of today) is: - Hack Week: OpenSCAP usability improvements - Hack Week: Code coverage of Uyuni triggered by our Cucumber Test suite - Visualising Salt events - Project Lotus - Syncing optional channel from UI (and not just from CLI) The link to join is: https://teams.microsoft.com/l/meetup-join/19%3Ameeting_ZjZlMWI0OTctNGMxZi00… Remember you can find all the information about the Community hours, included updated agenda and link for the meeting at https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours See you there! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Unable to create new Organization
by Ken Cote 23 Mar '23

23 Mar '23

Hello, I am encountering an issue where I am unable to create a new Organization. When I try to create an organization I receive a WEB TRACEBACK. I have also tried creating a new organization with spacecmd and I receive the same traceback. The error from spacecmd is: ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: ERROR: null value in column "group_type" of relation "rhnusergroup" violates not-null constraint Detail: Failing row contains (176, Cluster Administrators, Cluster Administrators for Org OIS, null, 0, null, 24, 2023-02-24 11:57:40.317269-07, 2023-02-24 11:57:40.317269-07). Where: SQL statement "insert into rhnUserGroup ( id, name, description, max_members, group_type, org_id ) values ( group_val, 'Cluster Administrators', 'Cluster Administrators for Org ' || name_in, NULL, ug_type, new_org_id )" PL/pgSQL function create_new_org(character varying,character varying) line 146 at SQL statement The error in the emailed traceback is the same. I am currently running Uyuni 2023.01. Any ideas on how I might go about troubleshooting and resolving this issue? Thanks!

4 5