- 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

IMPORTANT: Security Patch for Uyuni Server 2023.03
by Julio Gonzalez 22 Mar '23

22 Mar '23

Hello! The SUSE Customer support team detected a security problem that caused the password used for bootstrapping or virtual host manager configuration to be captured in clear text in the rhn_web_api.log A patch for Uyuni 2023.03 is now available, and we recommend you apply it as soon as possible, without waiting for the next release (that obviously will include it as well. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2023.01 or earlier, update first to 2023.03 normally (make sure you read the release notes, as special steps maybe required if you are not on 2023.03 already), and then apply the patch as explained above. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Uyuni 2023.03 is released!
by Julio Gonzalez 17 Mar '23

17 Mar '23

VERY IMPORTANT: 2023.03 may require a special procedure if you are not upgrading from 2023.01 Make sure you read the release notes for all the versions between the one you are using now, and 2023.03! We are happy to announce the availability of Uyuni 2023.03. Most openSUSE mirrors should already have 2023.03, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2023.03, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - openSUSE Leap Micro 5.3 support as client - SUSE Linux Enterprise Server Micro product migration - New products enabled - Monitoring: Grafana update to 8.5.15 - Syncing optional channels from from the WebUI - Subscription warning notifications will now happen weekly - Documentation: New look and feel - Salt 3000 End of Life - Debian 9 End of Life - 'spacewalk-clone-by-date' has been deprecated Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2023.03. As always, we hope you will enjoy this new Uyuni version and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

4 8

IMPORTANT: Patch for Uyuni Server 2023.03 and blank notification page for users with SCC accounts
by Julio Gonzalez 16 Mar '23

16 Mar '23

Hello! Some users reported that after the update to Uyuni 2023.03, the notification page was completely blank [1] [2] If you are affected, you will see notifications on the bell icon at the WebUI, and you will still get e-mail notifications. But if you go to the notifications page, it will render completely blank, with no content at all or errors. Although this should only affect Uyuni users with SCC credentials added to the Setup Wizard and with SCC subscriptions expiring, a previous bug [3] can cause this same problem even for some users without SCC subscriptions if they got such notifications but never removed them. A patch for Uyuni 2022.03 is now available, in case you are affected, so you do not need to wait for the next Uyuni release. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2023.01 or earlier, update first to 2023.03 normally (make sure you read the release notes, as special steps may be required if you are not on 2023.03 already), and then apply the patch as explained above. Happy hacking! [1] https://lists.opensuse.org/archives/list/users@lists.uyuni-project.org/mess… [2] https://github.com/uyuni-project/uyuni/issues/6729 [3] https://github.com/uyuni-project/uyuni/issues/6375 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Frequently receiving "Session expired, please reload the page." error
by Allen Beddingfield 03 Mar '23

03 Mar '23

I'm frequently receiving "Session expired, please reload the page." when trying to log into the web interface of Uyuni, after updating to 2023.01 recently. I can't figure out a pattern, but I keep doing combinations of opening it in a private browser windows on Firefox (that finally started giving the error as well, so I had to switch to Chromium, which sometimes give the error and sometimes works). It always gives the error in Opera. I keep going through a whole dance of clearing cache, trying different browsers, etc.... to get logged in each time, but I'm getting concerned that I may get to a point that I can't log in at all. Any ideas? I first suspected a workstation issue, but it is happening on two systems now(both openSUSE Leap). I have also restarted Uyuni, with no luck. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

1 0

Deploying the proxy using Elemental and Fleet demo video
by Cedric Bosdonnat 03 Mar '23

03 Mar '23

Hi all, In the last community hours I told you I had a video demonstrating the automated deployment of the Uyuni proxy with Rancher's Elemental and Fleet. You can find it here: https://www.youtube.com/watch?v=nhSxIcNeYAo If you want to dig further on that topic, here are my notes and setup: https://github.com/cbosdo/elemental-uyuni-proxy/ The git repository used for the fleet bundles is here: https://github.com/cbosdo/fleet-proxy Have fun! I would love to hear if you played with similar things. -- Cedric

1 0

Uyuni 2023.01 on Leap 15.4: ModuleNotFoundError: No module named 'simplejson'
by Johannes Kastl 28 Feb '23

28 Feb '23

Hi all, I installed the latest Uyuni release 2023.01 on an openSUSE Leap 15.4 box. One thing I noticed: "spacewalk-repo-sync -p opensuse_leap15_4" complained that the simplejson module was missing: > root uyuni:/root # spacewalk-repo-sync -p opensuse_leap15_4 > Traceback (most recent call last): > File "/usr/bin/spacewalk-repo-sync", line 25, in <module> > import simplejson as json > ModuleNotFoundError: No module named 'simplejson' > root uyuni:/root # Does anyone else get that, too? Worth a bug report? Or did something go haywire during my installation? 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

3 3

Error on applying highstate after 2023.01 update - tries to pull repomd.xml.key from external url
by Allen Beddingfield 24 Feb '23

24 Feb '23

After the 2023.01 update, I've had a couple of issues. Abid was able to help me (I think) resolve the issue with the channel listing in the web ui. Now, I noticed that an Oracle Linux 8 system that is newly added will give an error with applying the highstate. It appears to be trying to pull the repo key from the original location on the internet, instead of from the Uyuni server, from the managed system. The repositories added are the base channel, appstream, and the uyuni client tools. The error is coming from the Uyuni client tools. It seems that the managed system is trying to pull the repo key from an external URL (where Uyunio syncs this down from), and timing out. What could be going on that is causing this behavior? I would assume that it would pull that from the Uyuni server, itself. Thanks. ID: https_//download.opensuse.org/repositories/systemsmanagement_/Uyuni_/Stable_/CentOS8-Uyuni-Client-Tools/CentOS_8/repodata/repomd.xml.key Function: mgrcompat.run Name: pkg.add_repo_key Result: false Comment: Module function pkg.add_repo_key threw an exception. Exception: Error: HTTP 599: Timeout while connecting reading /repositories/systemsmanagement:/Uyuni:/Stable:/CentOS8-Uyuni-Client-Tools/CentOS_8/repodata/repomd.xml.key Started: 12:59:38.991575 Duration: 20023.057 SLS: channels.gpg-keys Changed: {} -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

1 1

"Internal Server Error" when displaying channels on 2023.01
by Allen Beddingfield 24 Feb '23

24 Feb '23

I'm getting an "Internal Server Error" message when trying to access "All" or "My Channels" under Software/Channel List. The server was recently updated to 2023.01, but that was working after the update. The only change I can think of that I have made is to do try to add the Leap 15.4 channels again, as they were display but not syncing. I did that with similar commands to this for the channels: spacewalk-common-channels -a x86_64 opensuse_leap15_4 Any help in troubleshooting this would be appreciated! Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

4 12

Community Hours today at 16.00 CET
by Julio Gonzalez 24 Feb '23

24 Feb '23

Hello, As every last Friday of each month, we'll be having a session of the Uyuni Community Hours. The agenda for today is: - Uyuni 2023.02/2023.03: What's new? (Julio) - Uyuni roadmap (Abid) - Hack Week: New Operating systems as clients for Uyuni (Raul and Julio) - Hack Week: Building the documentation on any OS and with no toolchain (Julio) - Hack Week: Improvements on the Uyuni Health Check tool (Pablo) - Hack Week: Deploying Uyuni Proxy container with fleet and elemental (Cedric) The link to join is: https://teams.microsoft.com/l/meetup-join/19%3Ameeting_ZjZlMWI0OTctNGMxZi00… See you there! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Issue importing Nodejs 15 debian repositorry in Uyuni
by Bidault, Philippe 23 Feb '23

23 Feb '23

Hi guys ! I have an issue trying to import the nodejs repo for debian 11 in Uyuni. All seems to be good, however, Uyuni don't like the package and just does not import it: 1234567891011121314152023/02/23 14:28:19 -00:00 Repo URL: https://deb.nodesource.com/node_15.x/dists/bullseye/main/binary-amd64/ 2023/02/23 14:28:19 -00:00 Packages in repo: 1 2023/02/23 14:28:19 -00:00 Packages already synced: 0 2023/02/23 14:28:19 -00:00 Packages to sync: 1 2023/02/23 14:28:19 -00:00 New packages to download: 1 2023/02/23 14:28:19 -00:00 Downloading packages: 2023/02/23 14:28:23 -00:00 1/1 : nodejs_15.14.0-deb-1nodesource1_amd64.deb 2023/02/23 14:28:23 -00:00 Importing packages started. 2023/02/23 14:28:23 -00:00 2023/02/23 14:28:23 -00:00 Importing packages to DB: 2023/02/23 14:28:23 -00:00 File not found inside package 2023/02/23 14:28:23 -00:00 Package batch #1 of 1 completed... 2023/02/23 14:28:23 -00:00 Importing packages finished. 2023/02/23 14:28:24 -00:00 2023/02/23 14:28:24 -00:00 Patches in repo: 0. Am I missing something ? Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<http://www.getronics.com> Follow us on: [cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]<https://www.linkedin.com/company/getronics/> <https://twitter.com/getronics> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policy<https://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/>

1 0

Ubuntu patch updates not syncing?
by Paul-Andre Panon 21 Feb '23

21 Feb '23

Hi, We don't seem to have received any new Ubuntu patch information recently, with the latest being 5814-1 dated Jan 19. 5810-1 on the 17th also seems to be missing even though it's on Ubuntu's advisories web page. Is there something wrong with the upstream Uyuni patch processing for Ubuntu? Cheers, Paul-Andre

2 1

Uyuni Proxy not working properly as proxy
by Paul-Andre Panon 01 Feb '23

01 Feb '23

Good morning, I've got an Uyuni proxy which isn't functioning properly as proxy. It's installed on an Azure VM create using an Azure OpenSUSE 15 template. After applying all updates and registering it with Uyuni, I added the proxy pattern with zypper and ran /usr/sbin/configure-proxy.sh. I don't see any obvious errors in the configure-proxy.sh run (I'm using custom certificates signed by our internal CA and this is a re-run): # /usr/sbin/configure-proxy.sh --answer-file=proxy-answers.txt.I3zAA Requesting certificate from server. [1/20] Certificate saved to: /etc/sysconfig/rhn/systemid SUSE Manager Parent [<UyuniMasterServer.fqdn>]: <UyuniMasterServer.fqdn> Using CA Chain (from /etc/sysconfig/rhn/up2date): /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT HTTP Proxy []: Traceback email []: You will now need to either generate or import an SSL certificate. This SSL certificate will allow client systems to connect to this Uyuni Proxy securely. Refer to the Uyuni Proxy Installation Guide for more information. Do you want to import existing certificates? [y]: y Path to CA SSL certificate: [/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT]: /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT Path to the Proxy Server's SSL key: [/root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.key]: /root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.key Path to the Proxy Server's SSL certificate: [/root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.crt]: /root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.crt Installing SSL certificates: After changing the server certificate please execute: $> spacewalk-service stop cp: '/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT' and '/etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT' are the same file $> spacewalk-service start As the CA certificate has been changed, please deploy the CA to all registered clients. On salt-managed clients, you can do this by applying the highstate. SUSE Manager Proxy successfully deactivated. SUSE Manager Proxy successfully activated. Shutting down spacewalk-proxy... Warning: Stopping tftp.service, but it can still be activated by: tftp.socket Done. Loading repository data... Reading installed packages... 'spacewalk-proxy-management' is already installed. No update candidate for 'spacewalk-proxy-management-4.4.2-220400.1.1.uyuni2.noarch'. The highest available version is already installed. Resolving package dependencies... Nothing to do. Loading repository data... Reading installed packages... The following 24 items are locked and will not be changed by any action: Available: plymouth plymouth-branding-openSUSE plymouth-branding-upstream plymouth-devel plymouth-dracut plymouth-lang plymouth-plugin-fade-throbber plymouth-plugin-label plymouth-plugin-label-ft plymouth-plugin-script plymouth-plugin-space-flares plymouth-plugin-throbgress plymouth-plugin-tribar plymouth-plugin-two-step plymouth-scripts plymouth-theme-bgrt plymouth-theme-breeze plymouth-theme-breeze-plugin-breeze plymouth-theme-fade-in plymouth-theme-script plymouth-theme-solar plymouth-theme-spinfinity plymouth-theme-spinner plymouth-theme-tribar Nothing to do. Do you want to use an existing ssh key for proxying ssh-push Salt minions ? [n]: n Generating new SSH key for ssh-push minions. Fetching public ssh-push key from <UyuniMasterServer.fqdn>. Added public ssh-push key from <UyuniMasterServer.fqdn> to /var/lib/spacewalk/mgrsshtunnel/.ssh/authorized_keys. sshd is already configured. Create and populate configuration channel rhn_proxy_config_1000010094? [1]: 1 SUSE Manager username: [<UyuniAdminAcct>]: <UyuniAdminAcct> Password: Using server name <UyuniMasterServer.fqdn> Pushing to channel rhn_proxy_config_1000010094: Local file /etc/apache2/vhosts.d/ssl.conf -> remote file /etc/apache2/vhosts.d/ssl.conf Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf Local file /etc/apache2/conf.d/cobbler-proxy.conf -> remote file /etc/apache2/conf.d/cobbler-proxy.conf Local file /etc/apache2/httpd.conf -> remote file /etc/apache2/httpd.conf Open needed firewall ports... running Warning: ALREADY_ENABLED: suse-manager-proxy success success Activate advertising proxy via SLP? [n]: n Enabling Spacewalk Proxy. Shutting down spacewalk-proxy... Done. Starting spacewalk-proxy... Done. Restarting salt-broker. Some additional details: 1) Unlike other proxies I have set up, the config channel file /etc/jabberd/c2s.xml crated by the configure script for that proxy has an empty element <id require-starttls="mu" pemfile="/etc/pki/spacewalk/jabberd/server.pem" realm="" register-enable="mu"> </id> whereas the corresponding files for the config channels of the other proxies have the proxy name included between the start and end tags. 2) This server doesn't seem to register correctly with DDNS. I first used "hostnamectl set-hostname <proxy.fqdn>" but the fqdn wouldn't display when entering hostname -f after a reboot. Because it's in Azure, I used NETCONFIG_DNS_STATIC_SEARCHLIST= and NETCONFIG_DNS_STATIC_SERVERS= in /etc/sysconfig/network/config to add our domain and DNS servers to the Azure DHCP defaults and it appears to have the desired effect in /etc/resolv.conf. However, that wasn't enough in conjunction with realm/sssd registration (which has worked with the other Uyuni proxy servers I've set up) to have sssd and the network startup register the name via DDNS. I wound up running nsupdate with appropriate settings (update delete and update add for the fqdn) on a daily cronjob to get the DDNS registration to work, showing that there seems to be no networking block preventing it. Note that after/other than the nsupdate hack, sssd and AD authentication work fine. What happens from the Uyuni client standpoint when trying to register with the bootstrap script from the proxy is that the client is properly downloaded and installed from the proxy, and the client registration goes through but appears to happen directly through the server (even though the HOSTNAME= shell variable in the context of the bootstrap script is the proxy server's name - confirmed with an echo statement). When looking at the client's properties on the server, it doesn't show any proxy being associated with it. I'm therefore thinking that perhaps whatever is preventing sssd from getting the right name to register with DDNS perhaps is also causing related problems for the configure-proxy.sh script (or maybe the WSGI redirects or something else on the proxy?) and preventing the client from registering properly. I've been banging my head against the wall on this for quite a while, so I would appreciate any suggestions. Thanks, Paul-Andre

1 1

kickstartfile-sync failed, cobbler-sync failed
by Crefeld, Tobias LKV Bayern e.V. 30 Jan '23

30 Jan '23

Hi, since some weeks we receive (usually after a reboot of the Uyuni server) "TASCOMATIC NOTICATIONS": Subtask kickstartfile-sync failed. Subtask cobbler-sync failed. At the log file /var/log/rhn/rhn_taskomatic_daemon.log we see messages like these one: 2023-01-30 18:15:00,201 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand - XmlRpcFault while logging in. most likely user doesn't have permissions. redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) 2023-01-30 18:16:00,116 [DefaultQuartzScheduler_Worker-17] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Message: We had an error trying to login. 2023-01-30 18:16:00,116 [DefaultQuartzScheduler_Worker-17] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Cause: {} redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) + 2023-01-30 18:37:00,057 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Stack trace:com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We had an error trying to login. [..] Caused by: redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) Actually we renewed our internal Root-CA certificate last month, added a new certificate chain to /etc/apache2/ssl.crt/ and included it in /etc/apache2/vhosts.d/vhost-ssl.conf . Webbrowsers show the updated certificate chain. Initially we forgot to add the new Root-CA-certificate to /etc/ssl/certs/ (+ run "update-ca-certificates") but this has been fixed meanwhile. I wonder if /etc/ssl/ca-bundle.pem is used by Apache Tomcat for validation of SSL-server certificates? Any other idea? Regards, Tobias Crefeld.

2 2

Uyuni 2023.01 is released!
by Julio Gonzalez 30 Jan '23

30 Jan '23

VERY IMPORTANT: 2023.01 will require a special procedure if you are not upgrading from 2022.12 Make sure you read the release notes for all the versions between the one you are using now, and 2023.01! We are happy to announce the availability of Uyuni 2023.01. Most openSUSE mirrors should already have 2023.01, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2023.01, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Release notes cleanup - SUSE Linux Enterprise Micro support as client - Content Lifecycle Management: Disabling modularity for AppStream repositories Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2023.01. As always, we hope you will enjoy this new Uyuni version and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

how to verify salt master config / add custom module
by Heiner Wulfhorst 24 Jan '23

24 Jan '23

Hi list, i want to add a custom salt module "pwgen" but always get this error: salt.exceptions.SaltRenderError: Jinja variable 'salt.utils.templates.AliasedLoader object' has no attribute 'pwgen.get_pw' I tried adding it using "module_dirs" in a custom config file: echo 'module_dirs: [/opt/passdb/pwgen-salt-module]' > /etc/salt/master.d/mycustom.conf I tried using "extension_modules" directly in /etc/salt/master: echo 'extension_modules: /opt/passdb/pwgen-salt-module' > /etc/salt/master I also tried with and without subdirectory "modules" within " /opt/passdb/pwgen-salt-module" After adding to config I restarted uyuni (spacewalk-service stop/start) and also salt (systemctl restart salt-master). Where is my error? In Salt config or in my module (python) code? How can i verify, that salt master accepts my additional config and reads/adds my custom module (/opt/passdb/pwgen-salt-module/pwgen.py)? BR Heiner

3 2

Uyuni salt master lost communications to most minions
by Paul-Andre Panon 19 Jan '23

19 Jan '23

Hi, We've got a weird behaviour that happened in the last day or so. The Uyuni salt master stopped being able to communicate with nearly all minions except one. salt -vvv ServerX test.ping Executing job with jid 20230118190311229937 ------------------------------------------- ServerX: Minion did not return. [Not connected] ERROR: Minions returned with non-zero exit code The venv-salt-minion service seems to be working on the minion. The service has the error salt-minion[952]: [ERROR] File /etc/venv-salt-minion/minion.d/_mgractionchains.conf not found, but that appears to be cosmetic based on the outstanding issue, and the working minion has the same error. However, I restarted one of the salt-minions and the salt master appears to be able to connect afterwards. And yet the minion system was rebooted the previous day and hasn't been patched in the interim so there should have been no version change. Is there possibly a bug in the latest salt minion version? The Ubuntu 22.04 minion version is venv-salt-minion 3004-11.3.uyuni amd64 The venvjailed client component for Salt although we're also getting this across the board on CentOS 7, openSUSE, and multiple versions of Ubuntu. Could the salt master have issued something that put all the salt minions in a wedged state due to some bug? Is there anything we can gather, information wise before restarting those venv-salt-minion services across the board? Cheers, Paul-Andre

1 1

Uyuni 2022.12 is released!
by Julio Gonzalez 17 Jan '23

17 Jan '23

VERY IMPORTANT: 2022.12 will require a special procedure if you are not upgrading from 2022.11 Make sure you read the release notes for all the versions between the one you are using now, and 2022.12! We are happy to announce the availability of Uyuni 2022.12. Most openSUSE mirrors should already have 2022.12, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.12, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Indications for systems requiring reboot or with a scheduled reboot - Notification messages via email - Monitoring: Grafana update to 8.5.15 - Subscription warning notifications - Limit changelogs at repositories metadata to the last 20 entries - Drop legacy way to prevent disabling local repositories at bootstrap scripts Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.12. As always, we hope you will enjoy Uyuni 2022.12 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

5 5

Canceled: Uyuni Community Hours
by Julio Gonzalez 16 Dec '22

16 Dec '22

Dear Community: The December session of the Community hours will be skipped, as a lot of people is away because of the winter holidays. See you again in January, or at Gitter/Mailing lists. Happy hacking!

1 0

IMPORTANT: Security Patch for Uyuni Server 2022.11
by Julio Gonzalez 13 Dec '22

13 Dec '22

Hello! The SUSE security team detected a security problem that caused the proxy password to be present at the browser log, when using the Uyuni Server via WebUI. A patch for Uyuni 2022.11 is now available, and we recommend you apply it as soon as possible, without waiting for the next release (that obviously will include it as well. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

OES 2023 repos
by Nick Fletcher 10 Dec '22

10 Dec '22

Hi, I'm fairly new to Uyuni and I am evaluating it as a better solution than Micro Focus SMT. I've entered my Micro Focus credentials and I can see all the OES 2018 products but not OES 2023, which I can see on my Micro Focus SMT server. Will OES 2023 appear eventually or do I need to do anything in particular to add these products? I couldn't see anything about this in the documentation. Thanks, Nick

4 10

IMPORTANT: Patch for Uyuni Server 2022.11 and Amazon Linux repository syncing
by Julio Gonzalez 02 Dec '22

02 Dec '22

Hello! A user has reported that after the update to Uyuni 2022.11, running spacewalk- repo-sync would fail with a permissions error, when trying to sync certain amazonlinux core channels. If you are affected, repository syncing will fail, and you will see errors similar to those reported at: https://github.com/uyuni-project/uyuni/issues/6244 This was due to a change in a script used by repo-sync, which checked if pages claiming to be mirrorlists were of the right media type. The check was overzealous and excluded some valid types of pages. A patch for Uyuni 2022.11 is now available, in case you are affected, so you do not need to wait for the next Uyuni release. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Thanks to eins for the report and the help debugging the issue. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 01 Dec '22

01 Dec '22

Hi Julio, this vhost configuration didn't belong to Uyuni. Starting to evaluate Uyuni, we had the idea to add Netbox on the same system to provide data like ip-adresses, etc. for automated installations. It didn't work and afterwards we forgot this software installation. It was based on a tar file so there is no rpm entry for this application but after removing the respective configuration file from /etc/apache2/vhosts.s/ (+ 2 services + directory in /opt) it shouldn't disturb any more. Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Mittwoch, 30. November 2022 17:54 Glad to see things are working again :-) Was that a vhost configuration generated by you? I'd assume yes, as nobody else reported similar issues But if you can't recall, or if you are sure that's not yours, then if you still have the filename, please run rpm -qf <full_path> To see if it's owned by any package we provide (<full_path> being the path where file was) Thanks!

1 0

AW: AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 30 Nov '22

30 Nov '22

Hi Julio, the hint with the apache was helpful! It turned out that there was an old vhost configuration. No idea why it didn't cause troubles in the past and why there is a problem now but after removing the respective vhost config spacewalk-common-channels works as expected now. Afterwards spacewalk-repo-sync populated the channel and mgr-create-bootstrap-repo terminated without missing packages. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Dienstag, 29. November 2022 17:31 I'd expect the HTTP 400 from the Uyuni API, and some logs at /var/log/hrn, but maybe somehow the problem is at Apache. Try to check `/var/log/apache2/` or even the output of `journalctl` (as root).

2 1

AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 29 Nov '22

29 Nov '22

Hi Julio, Thanks for you advise! I tested with different credentials including wrong ones - same return code. And yes, this is the user I defined during initial setup of Uyuni 2 years ago. There is no change of the log files in /var/log/rhn/ when I start the command including rhn_web_api.log that usually shows activity whenever I work with the repository management. Other commands like spacewalk-repo-sync or spacewalk-remove-channel work fine. If we talk about http return codes my understanding is, that code 400 is indicating malformed client requests. I will run the update to 2022.11 within the next few days hoping that this will fix the DB-warnings at least. But actually I fear that this won't fix the issue with spacewalk-common-channels Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Montag, 28. November 2022 16:05 An: 'users(a)lists.uyuni-project.org' <users(a)lists.uyuni-project.org> Cc: Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; Julio Gonzalez <jgonzalez(a)suse.com> Betreff: Re: Prob with spacewalk-common-channels Since you are on 2022.08, I'd recommend updating to 2022.11 already (be ware of the manual steps required, carefully read the release notes) For the PostgreSQL log, I seem to remember it was something not harmful, but that was fixed on 2022.10. For the spacewalk-common-channels, I am not sure, but it could be there were some fixes at the API. In any case, since you see an error HTTP 400 Bad Request, you should also be able to see something at /var/log/rhn/ that explains why the request was incorrect. Does this problem happen if you use the first user created when you installed Uyuni?

3 2

Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 28 Nov '22

28 Nov '22

Hi, the command spacewalk-common-channels -n sles15-sp3-uyuni-client returns SUSE Manager username: lkvadmin SUSE Manager password: Traceback (most recent call last): File "/usr/bin/spacewalk-common-channels", line 269, in <module> client, key = connect(options.user, options.password, options.server) File "/usr/bin/spacewalk-common-channels", line 119, in connect key = xmlrpc_login(client, options.user, password) File "/usr/lib/python3.6/site-packages/uyuni/common/cli.py", line 74, in xmlrpc_login sessionkey = client.auth.login(username, password) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1112, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1452, in __request verbose=self.__verbose File "/usr/lib64/python3.6/xmlrpc/client.py", line 1154, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1187, in single_request dict(resp.getheaders()) xmlrpc.client.ProtocolError: <ProtocolError for localhost/rpc/api: 400 Bad Request> lkvbayern is SUSE Manager Administrator and Organization Administrator, being created during initial system setup. I tried another user-ID with the same credentials - same result. There is another fault. Don't know if it is related to the problem with spacewalk-common-channels described above: journalctl -f -u uyuni-check-database.service Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8717]: at /usr/lib/perl5/vendor_perl/5.26.1/Spacewalk/Setup.pm line 29. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8700]: Your database schema already matches the schema package version [uyuni-reportdb-schema-4.3.5-1.21.uyuni2]. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8700]: Schema upgrade: [uyuni-reportdb-schema-4.3.5-1.21.uyuni2] -> [uyuni-reportdb-schema-4.3.5-1.21.uyuni2] Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8726]: Prototype mismatch: sub Spacewalk::Setup::idn_to_ascii: none vs ($;$$) at /usr/lib/perl5/5.26.1/Exporter.pm line 66. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8726]: at /usr/lib/perl5/vendor_perl/5.26.1/Spacewalk/Setup.pm line 29. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8738]: Prototype mismatch: sub Spacewalk::Setup::idn_to_ascii: none vs ($;$$) at /usr/lib/perl5/5.26.1/Exporter.pm li System is running Uyuni 2022.08 on opensuse-15.4. Any idea how to get spacewalk-common-channels running? A result of the fault is that "mgr-create-bootstrap-repo" and therefore "Bootstrapping" isn't successful any more. Regards, Tobias Crefeld.

2 1

IMPORTANT: Patch for Uyuni Server 2022.11
by Julio Gonzalez 25 Nov '22

25 Nov '22

Hello! Several users at Gitter and GitHub have reported that after the update to Uyuni 2022.11, they see a notification whith an error message after a reposync for any channel is complete. The error will contain a python stacktrace as described at https://github.com/uyuni-project/uyuni/issues/6193 Uyuni 2022.11, includes a refactor for the System list page to use a dedicated cache table to improve performance. Because of this refactor, each time a repository is synchronized, we need to refresh the information for the minions using such repository. The query that processes such refresh had a bug, and was referring a non- existing reference. A patch for Uyuni 2022.11 is now available, in case you are affected, so you do not need to wait for the next Uyuni release. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

spacewalk-repo-sync failed after update 2022.10 to 2022.11
by Thomas Weis 24 Nov '22

24 Nov '22

hello everyone After updating from 2022.10 to 2022.11, after running spacewalk-repo-sync -p opensuse_leap15_4-x86_64, the process aborted with an error. The following error message was generated: 12:26:52 Repo URL: http://download.opensuse.org/distribution/leap/15.4/repo/oss/ 12:26:52 Packages in repo: 96026 12:34:39 No new packages to sync. 12:34:40 12:34:40 Patches in repo: 0. 12:34:45 12:34:45 Importing media products file products. 12:34:45 *** NOTE: Importing mediaproducts file for the channel 'opensuse_leap15_4-x86_64'. Previous media products will be discarded. 12:42:56 Updating overview of 1 systems Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 299, in _execute_wrapper retval = function(*p, **kw) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 182, in _execute return self._execute_(args, kwargs) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 322, in _execute_ self._real_cursor.execute(self.sql, params) psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "c" LINE 4: coalesce(c.org_id, 1), ^ During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/spacewalk-repo-sync", line 286, in <module> sys.exit(abs(main() or 0)) File "/usr/bin/spacewalk-repo-sync", line 269, in main elapsed_time, channel_ret_code = sync.sync() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 705, in sync self.update_servers() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 739, in update_servers taskomatic.add_to_system_overview_update_queue(row["id"]) File "/usr/lib/python3.6/site-packages/spacewalk/server/taskomatic.py", line 103, in add_to_system_overview_update_queue h.execute(sid=sid) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 150, in execute return self._execute_wrapper(self._execute, *p, **kw) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 309, in _execute_wrapper raise sql_base.SQLStatementPrepareError(str(self.dbh), e.pgerror, self.sql) spacewalk.server.rhnSQL.sql_base.SQLStatementPrepareError: ('ERROR: missing FROM-clause entry for table "c"\nLINE 4: coalesce(c.org_id, 1),\n ^\n', "<connection object at 0x7f1c42cd6a08 ; dsn: 'user=uyunidbuser password=xxx dbname=uyuni', closed: 0>", "\n INSERT INTO rhnTaskQueue (org_id, task_name, task_data, priority, earliest)\n VALUES (\n coalesce(c.org_id, 1),\n 'update_system_overview',\n %(sid)s,\n 0,\n current_timestamp\n )\n ") After that it was completely canceled. The update from 2022.10 to 2022.11 ran without errors, the webgui is accessible. what can be done Restore from snapshot? Thanks for support! Regards Thomas

3 3

file.directory and user.present: how to configure dependencies
by Heiner Wulfhorst 24 Nov '22

24 Nov '22

Hi List, I am having trouble configuring dependencies between the existence of a user and his homedir ( a mounted lv ). If I put the user as a requirement for the chown (file.directory) I get a python error: "RecursionError: maximum recursion depth exceeded while calling a Python object". How should I do it? Here's my current code: sapinst: group.present: - gid: 200 sapsys: group.present: - gid: 201 daaadm: user.present: - require: - group: sapsys - group: sapinst - mount: /usr/sap/DAA - uid: 1112 - gid: 201 - home: /usr/sap/DAA - groups: - sapinst chown_/usr/sap/DAA_to_daaadm: file.directory: - name: /usr/sap/DAA - user: daaadm - group: sapsys - require: - user: daaadm Thanks a lot, Heiner

1 0

Uyuni 2022.11 is released!
by Julio Gonzalez 23 Nov '22

23 Nov '22

VERY IMPORTANT: 2022.11 will require a special procedure if you are not upgrading from 2022.10 Make sure you read the release notes for all the versions between the one you are using now, and 2022.11! We are happy to announce the availability of Uyuni 2022.11. Most openSUSE mirrors should already have 2022.11, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.11, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Instructions to disable custom channel automatic synchronization - Allow more tools for network management for the Uyuni Server - Monitoring: Grafana update to 8.5.13 - Monitoring: Fix TLS configuration and enable client certificate authentication for Blackbox exporter - Traditional stack being removed Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.11 As always, we hope you will enjoy Uyuni 2022.11 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

3 5

IMPORTANT: Refresh of the Uyuni 2022.11 release notes
by Julio Gonzalez 23 Nov '22

23 Nov '22

Hello! Some users reported two issues: # System list showing empty after the update See: https://www.uyuni-project.org/doc/2022.11/release-notes-uyuni-server.html#_… # Rocky Linux 9 onboarding fails to complete See: https://www.uyuni-project.org/doc/2022.11/release-notes-uyuni-server.html#_… As you can see, we refreshed the release notes at the website. If you want to have them refreshed at your Uyuni Server, we also released the refreshed release notes as a Patch, but keep in mind this is not strictly needed. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 14 Nov '22

14 Nov '22

Hello! ################################################# WARNING: Instead of running `zypper up` as provided by the instructions at the website, we strongly recommend using `zypper up|tee /tmp/update.log` or similar, so you can find errors during the migration in the unlikely event they happen ################################################# Several users at Gitter and GitHub have reported that after the update to Uyuni 2022.10, and after applying the patch from last week, Cobbler had problems to start because templates files were not found, so some features were broken, such as: - Onboarding new clients - Removing existing clients - Autoinstallation In such cases you can see errors in Cobbler like: cobbler.cexceptions.CX: 'serializer: error loading collection profile: Invalid automatic installation template file location /var/lib/cobbler/templates/ xxxxxxxxxxxx.cfg, file not found This problem was caused because the "autoinstall" attribute for the Cobbler collections was wrongly migrated at the time of running the migration from the old Cobbler collections from version 2 to version 3, making Cobbler not able to find the "templates" files for the profiles anymore. Any subdirectory was removed from the "autoinstall" attribute. For "Autoinstallation" profiles generated using Uyuni, the "autoinstall" files are generated and placed by Uyuni at "upload/" and "wizard/" subdirectories of `/var/lib/cobbler/templates/`. These Cobbler collections and templates files (for Uyuni created profiles) are recreated by Uyuni in case they are missing, on every spacewalk-services restart. With this new upgrade, we have fixed the migration of the "autoinstall" attribute from Cobbler collections, and make the migration to run again in order to fix any possible inconsistency created by the execution of the wrong migration from the previous patch, so Cobbler will be now able to find the "autoinstall" templates and finish the startup. The migration will run automatically during the upgrade, if there is any unexpected issue during the migration you should see some errors when zypper is updating "cobbler" or "spacewalk-setup" packages. In the unlikely event there are still some conflicts for the `.cfg` files, you will get instructions provided by the upgrade, to fix the issue. A patch for Uyuni 2022.10 is now available, in case you are affected, so you do not need to wait for Uyuni 2022.11 (this version will also include this fix). You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html (please be aware of the WARNING at the beginning of this email!) Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Security patches and feature patches for Uyuni Server 2022.10
by Julio Gonzalez 04 Nov '22

04 Nov '22

Hello! ### Cobbler migration Some users have reported that after the Update to Uyuni 2022.10, there are still some problems related to Cobbler, where collections are not migrated, so the cobbler service fails to start at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels This is not happening for most users, but we are now releasing a patch to address it, and migrate any collections provided by any past cobbler version. ### File descriptors leakage Some users reported that, after updating to Uyuni 2022.10, and after some days, the Server stopped working, and they saw a steady increase of "open files" or "allocated file descriptors". This was caused after the migration to log4j2. Every time a taskomatic job object gets created, it initializes its own logger programmatically to write its logs into a file. The lifecycle of a job object is relatively short, but the log4j2 runtime doesn't know it. When it gets permissions to write into a file, there's nothing to release it after the job is over. Moreover the log4j2 keeps track of loggers based on the class names. It effectively means we mutate the same logger object in memory over and over again with every new taskomatic job. The fix adds functionality to re-initialize the logger when a new job comes around, dropping any file handler it has. ### Security fixes During a SUSE Manager and Uyuni security audit, the SUSE security team reported three vulnerabilities at the spacewalk-java source package (which provides spacewalk-java-* or spacewalk-taskomatic packages): * CVE-2022-31255: Fix directory path traversal vulnerability * CVE-2022-43754: Fix reflected cross site scripting vulnerability * CVE-2022-43753: Fix arbitrary file disclosure vulnerability You can find more details at: https://www.suse.com/security/cve/CVE-2022-31255.html https://www.suse.com/security/cve/CVE-2022-43754.html https://www.suse.com/security/cve/CVE-2022-43753.html A patch for Uyuni 2022.10 to fix all the issues was just published, and because of the security issues, it is strongly recommended you update your server, even if you are not affected by the cobbler migration issues or the file descriptors leakage. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thanks to all users that reported the issues, and helped with the debugging. Happy hacking!

1 0

Query about config management best practice.
by Simon Avery 04 Nov '22

04 Nov '22

Hello, I've got a query about best practice for config management. We have several Configuration Channels, each with a bunch of files in. Machines are subscribed to appropriate channels based on role and distro. We want to push those files out daily to subscribed machines, replacing any that have been edited on-server. We currently achieve this with a bash script on the Uyuni vm, called by crontab overnight, using "spacecmd -y -- configchannel_forcedeploy channelname" This works fine, but I'm wondering if that's the best way, as it's configured and monitored only outside of the webui? Forcing a regular high state appears to push those files, plus updates the .repo files and generally getting things as Uyuni thinks they should be. The recurring schedule seems to be designed to do this. But I can't see a way to automatically set a recurring schedule? Whilst I can set one for existing machines using SSM, I can't see a way to add one via Activation Key nor automatically enroll all machines into setting a highstate once a day or so. How do others approach this? Is there a gui way, or should I stick with the spacecmd route? S

1 0

Uyuni webui stops responding.
by Simon Avery 27 Oct '22

27 Oct '22

Hi Has anyone encountered an issue with Uyuni where the web interface becomes unresponsive? I've never had this happen before in at least a couple of years usage, but over the past couple of weeks we've had it happen several times to different users and when it happens, it affects all users. The user's web browsers report that no data is sent on page link or reload. Manually running "spacewalk-service restart" brings it back into life within a couple of minutes. This isn't related to the 2022.10 update, since I've held back applying that so far and we're still on 2022.08. The only thing that's changed is a couple of new users, and perhaps something is taking exception to them. (But we're all on similar chrome + windows clients) I've not yet done any serious debugging (each time the priority has been to get it back up), but would appreciate any tips from anyone that's encountered this. (I'll try and remember to run "spacewalk-service status" next time to at least identify which service is faulting) Thanks Simon

3 4

clients can't connect to uyuni server, JWT token
by Haupt, Torsten 25 Oct '22

25 Oct '22

Hi, since some time my clients can't contact the uyuni server. A "zypper ref" shows for example: zypper ref Permission to access 'https://xxxuyuni.xxx.de:443/rhn/manager/download/sle12_5-utilities-x86_64/r…' denied. Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Last contact time in uyuni is also a long time ago. If I copy the url above in a browser, it get: Token is not valid to access repomd.xml in sle12_5-utilities-x86_64: JWT (claims->{"exp":1652861921,"iat":1621325921,"nbf":1621325801,"jti":"kufB_AaMdzSgIr92uq9cfA","org":1,"onlyChannels":["sle12_5-utilities-x86_64"]}) rejected due to invalid claims. Additional details: [The JWT is no longer valid - the evaluation time NumericDate{1666073380 -> 18.10.2022, 08:09:40 MESZ} is on or after the Expiration Time (exp=NumericDate{1652861921 -> 18.05.2022, 10:18:41 MESZ}) claim value.] It seems a token is to old; but how to renew it? Greets Torsten

4 5

Canceled: Uyuni Community Hours
by Julio Gonzalez 24 Oct '22

24 Oct '22

Dear Community: This Friday most of the SUSE Manager team will not be available, including the moderators, so we need to cancel this session. We'll see you in the November session, and meanwhile remember the Community is available at the mailing lists, Gitter and GitHub. Sorry about the inconvenience!

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 24 Oct '22

24 Oct '22

Hello! Several users at Gitter have reported that after the Update to Uyuni 2022.10, and after applying the patch from last week, that the cobbler package fails to update, or that the cobbler service is not starting at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The problem was causes because of bugs at migration scripts for cobbler itself. Such bugs are only happening for long time Uyuni users where the cobbler configuration is old enough, so most users should not notice this problem. If you are affected, you will see the following error while installing the cobbler package: > schema.SchemaError: Key 'proxy_url_ext' error: > None should be instance of 'str' Or the following error at the logs, when starting cobbler: > cobblerd[32057]: schema.SchemaError: Key 'allow_duplicate_hostnames' error: > cobblerd[32057]: 0 should be instance of 'bool' The fix is at the SR: https://build.opensuse.org/package/rdiff/systemsmanagement:Uyuni:Master/cob… (an OBS account is required to see the diff) A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Disconnected Setup with SMT results in "java.io.FileNotFoundException: /path/to/product_tree.json"
by Srinidhi B 20 Oct '22

20 Oct '22

Hello List, I'm trying to use the contents of my existing SMT12 setup in Uyuni and I've followed the steps documented at: https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/disconnect… But I'm getting the following error when I run "mgr-sync refresh": uyuni:~ # mgr-sync refresh Refreshing Channel families Please enter the credentials of SUSE Manager Administrator. Login: admin Password: [DONE] Refreshing SUSE products [FAIL] Error: <Fault -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: com.suse.scc.client.SCCClientException: java.io.FileNotFoundException: /media/SMT/repo/disconnected-setup/product_tree.json (No such file or directory)'> Detailed steps: =============== We use a NFS mount for our SMT servers. On the same NFS mount, I created a new sub-directory called "disconnected-setup" and ran the following two commands: # smt-sync --createdbreplacementfile /tmp/dbrepl.xml # smt-mirror --dbreplfile /tmp/dbrepl.xml --directory /srv/www/htdocs/repo/disconnected-setup/ --fromlocalsmt -L /var/log/smt/smt-mirror-export.log # ls -l /srv/www/htdocs/repo/disconnected-setup/ total 11848 -rw-r--r-- 1 smt www 2 Oct 3 00:07 organizations_orders.json -rw-r--r-- 1 smt www 10006809 Oct 3 00:07 organizations_products_unscoped.json -rw-r--r-- 1 smt www 1744853 Oct 3 00:07 organizations_repositories.json -rw-r--r-- 1 smt www 341708 Oct 3 00:07 organizations_subscriptions.json drwxr-xr-x 4 smt www 4096 Oct 3 04:28 repo lrwxrwxrwx 1 smt www 9 Oct 3 04:28 SUSE -> repo/SUSE Back on the Uyuni server, I ran: # mount -t nfs storage:/srv/ftp/SMT /media/SMT # echo 'server.susemanager.fromdir = /media/SMT/repo/disconnected-setup/' >> /etc/rhn/rhn.conf # systemctl restart tomcat Could someone please tell me what am I missing? How do I get the "product_tree.json" file generated from the SMT server? Regards, Srinidhi.

2 2

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 20 Oct '22

20 Oct '22

Hello! Several users at GitHub, mailing lists and Gitter have reported that after the Update to Uyuni 2022.10, cobbler is not starting at the Uyuni Server, therefore affecting some features, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The following bug reports are related to this problem: - https://github.com/uyuni-project/uyuni/issues/6037 - https://github.com/uyuni-project/uyuni/issues/6041 - https://github.com/uyuni-project/uyuni/issues/6045 The problem was caused for a bug at the script for the migration of the settings and collections to Cobbler 3.3.3 The fix is at the PR https://github.com/uyuni-project/uyuni/pull/6050 A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

no more OES2018 repos in Uyuni after new key for SLES subscriptions
by Thomas Weis 15 Oct '22

15 Oct '22

Hello everyone we synchronize the current OES2018-SP3 repositories via Uyuni. After a maintenance renewal, we received a new key for the SLES subscription because our current subscription could no longer be activated with the existing key. With the new key we can now synchronize all SLES repos within the scope of the subscription again, but obviously all OES2018 repos are missing. I am sure that with the old key all OES2018 repos were listed and could be selected. Are we doing something wrong or does something have to be activated in addition to the new subscription key? Thanks for the support! Thomas Mit freundlichen Grüßen / Kind regards Thomas Weis NTW Netzwerk • Telekommunikation • Datentechnik Burghaldenstrasse 24 D-71336 Waiblingen

2 3

Uyuni 2022.10 is released!
by Julio Gonzalez 14 Oct '22

14 Oct '22

VERY IMPORTANT: 2022.10 requires special procedures for the upgrade from any previous version! Make sure you read the release notes for all the versions between the one you are using now, and 2022.10! We are happy to announce the availability of Uyuni 2022.10. Most openSUSE mirrors should already have 2022.10, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.10, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Special instructions for the update, make sure you read them! - RHEL/Oracle Linux/AlmaLinux/Rocky Linux 9 as clients - Monitoring for Ubuntu 22.04 - pip support for the Salt Bundle - Apache exporter updated to version 0.11.0 for SUSE Linux Enterprise and openSUSE - Cobbler updated to version 3.3.3 Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.10 As always, we hope you will enjoy Uyuni 2022.10 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

CentOS 7 channel selection issue
by Paul-Andre Panon 12 Oct '22

12 Oct '22

Hi, I've been running into an issue with our CentOS 7 clients. We didn't have this problem before but seem to have it with recent client additions. When trying to change the base and child channels for a CentOS 7 system, the change fails and corrupts the client repo config file at /etc/yum.repos.d/susemanager:channels.repo. The gpgkey= lines somehow have the non-Uyuni repo signing keys still in there, with the Uyuni key on a separate line immediately after. For example [susemanager:centos7-x86_64] name=CentOS 7 (x86_64) enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 file:///etc/pki/rpm-gpg/mgr-gpg-pub.key baseurl=https://carmd-nv-uyuni1.sierrawireless.local:443/rhn/manager/download/centos7-x86_64 susemanager_token=eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2OTUyNDgzNzEsImlhdCI6MTY2MzcxMjM3MSwibmJmIjoxNjYzNzEyMjUxLCJqdGkiOiI0UkhWYWUzU0VnTngwRk1yaXFsWG13Iiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsiY2VudG9zNy14ODZfNjQiXX0.EoqL2bHAZ4li3FGsXuatKny5BU0qJ1aDbdJifTD_Gkw gpgcheck=1 repo_gpgcheck=1 type=rpm-md Instead that gpgkey line should just look like gpgkey=file:///etc/pki/rpm-gpg/mgr-gpg-pub.key It currently only seems to happen with the CentOS 7 clients. Is this a bug in a recent CentOS client update, or a database issue? Cheers, Paul-Andre Panon

2 3

SSO redirect not happening
by Georg Pfuetzenreuter 29 Sep '22

29 Sep '22

Hello, I read the document https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/auth-metho…, configured the following additional properties in /etc/rhn/rhn.conf and executed `spacewalk-service restart`: ``` ### custom java.sso = true java.sso.onelogin.saml2.sp.entityid = https://uyuni.example.com/rhn/manager/sso/metadata java.sso.onelogin.saml2.sp.assertion_consumer_service.url = https://uyuni.example.com/rhn/manager/sso/acs java.sso.onelogin.saml2.sp.single_logout_service.url = https://uyuni.example.com/rhn/manager/sso/sls java.sso.onelogin.saml2.idp.x509cert = -----BEGIN CERTIFICATE-----\n<redacted>\n-----END CERTIFICATE----- java.sso.onelogin.saml2.idp.single_sign_on_service.url = https://sso.example.com/realms/dev/protocol/saml java.sso.onelogin.saml2.idp.entityid = https://uyuni.example.com/rhn/manager/sso/metadata java.sso.onelogin.saml2.idp.single_logout_service.url = https://sso.example.com/realms/dev/protocol/saml ``` The linked documentation states "When you visit the Uyuni URL, you are redirected to the IdP for SSO where you are requested to authenticate.", but this does not seem to be the case on my end - opening web UI presents me with the regular/local login page - no redirect to my IDP is happening. The system journal does not seem to show anything "new" either. Any ideas on what I am missing? This is a fresh stable installation. Thanks for reading! Georg

2 2

Permissions for approving salt keys
by Paul-Andre Panon 13 Sep '22

13 Sep '22

Hi, Is it only possible to approve salt keys with Organization or Uyuni administrator privileges? Or is it possible to delegate those permissions somehow without implicitly giving activation key, configuration, Image, and channel permissions as well? It would be good if the administrators of default system groups for activation keys could somehow approve the salt keys for systems added with a bootstrap script using those keys. Salt key approval is most closely associated with the system group administration use cases. Cheers, Paul-Andre Panon

1 0

editing ansible playbooks and inventories
by 4thomasmueller＠gmail.com 12 Sep '22

12 Sep '22

Hi, it would be nice if the playbooks and hostlists can edited/written directly via uyuni GUI (like SALT states). Does anybody know if this is planned for future releases? Thanks, Thomas

2 1

"No job return event was received." (code -1)
by Martin 11 Sep '22

11 Sep '22

Hello list Since some days, all zypper jobs to my openSuSE Clients ends up with "No job return event was received." (code -1). The patches are installes successfully on the clients as shown in /var/log/zypp/history, but uyuni still shows the same number of avaliable patches. When I start a Package List Refresh - it ends up with the same error: Systemverlaufsereignisse Zusammenfassung: Package List Refresh geplant von admin Einzelheiten: Diese Aktion wird ausgeführt nach 08.09.22 12:06:45 MESZ Der Status dieser Aktion ist: Fehlgeschlagen. Der Client hat diese Aktion abgeschlossen am 09.09.22 00:00:51 MESZ Client-Ausführung meldet "No job return event was received." (code -1) Zeit: 08.09.22 12:06:45 MESZ Neu einplanen: Dieses Verlaufsereignis wurde durch eine fehlgeschlagene geplante Aktion verursacht. Falls Sie das Problem behoben haben, können Sie die Aktion unten erneut planen. I use Unyuni Release 2022.08 Best regards Martin

1 0

AW: AW: RE: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 08 Sep '22

08 Sep '22

Hi, meanwhile I updated Uyuni from 2022.06 to 2022.08 and since then patching of (salt) clients works again after some manual resynchronisations. Now most of the Taskomatic jobs get executed successfully again. The Taskomatic job mgr-update-reporting-bunch still fails with similar log messages as before. Another job “minion-action-executor-bunch” that failed can’t be found on the Task Schedules list. Systems with the Contact Method “Push via SSH” still cannot check in. Trying to remove a ssh-client was successful. Trying to re-register the client by the bootstrap dialogue fails with the message “Error: Unable to download https://lkv-srvapp39.lkvbay.net:443/pub/repositories/opensuse/15/1/bootstra… file!” Actually this file doesn’t exist but we never changed the respective repositories manually so we don’t know why the same task worked before. I found a job “ssh-push” with the status “SKIPPED”. The log message is “com.redhat.rhn.taskomatic.task.SSHPush - Maximum number of workers already put ... skipping.” BTW: Returning to latest Uyuni-version before the upgrade to 2022.06 wasn’t successful, too. Seems to be related to different salt versions. Regards, Tobias Crefeld. Von: David Mace [mailto:david@macemail.co.uk] Gesendet: Dienstag, 16. August 2022 11:42 "BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients" Since the update taskomatic also just crashes every 10 seconds for me <https://github.com/uyuni-project/uyuni/issues/5556> https://github.com/uyuni-project/uyuni/issues/5556 -----Original Message----- From: "Crefeld, Tobias LKV Bayern e.V." < <mailto:%22Crefeld,%20Tobias%20LKV%20Bayern%20e.V.%22%20%3cTobias.Crefeld@lkv.bayern.de%3e> Tobias.Crefeld(a)lkv.bayern.de> Reply-To: General discussion related to the openSUSE Uyuni project < <mailto:General%20discussion%20related%20to%20the%20openSUSE%20Uyuni%20project%20%3cusers@lists.uyuni-project.org%3e> users(a)lists.uyuni-project.org> To: 'Paul-Andre Panon via Uyuni Users' < <mailto:'Paul-Andre%20Panon%20via%20Uyuni%20Users'%20%3cusers(a)lists.uyuni-project.org%3e> users(a)lists.uyuni-project.org> Subject: AW: RE: Subtask mgr-update-reporting failed. Date: Tue, 16 Aug 2022 09:11:27 +0000 Hi Robert, "ping lkv-srvapp39" and "host lkv-srvapp39" work as expected. A request with psql works fine, too: uyuni@lkv-srvapp39:~> psql -h lkv-srvapp39 Passwort für Benutzer uyuni: psql (14.3) SSL-Verbindung (Protokoll: TLSv1.3, Verschlüsselungsmethode: TLS_AES_256_GCM_SHA384, Bits: 256, Komprimierung: aus) Geben Sie »help« für Hilfe ein. uyuni=# How can I add the short name to the "TLS SAN"? Where can I configure the host name the application is using? I don't know if It is important, but according to the status of systemctl Uyuni's applications connect to the DB-server via 127.0.0.1 which resolves to localhost: lkv-srvapp39:/var/lib/pgsql/data # systemctl status postgresql ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-08-02 10:41:35 CEST; 2 weeks 0 days ago Process: 2357 ExecStart=/usr/share/postgresql/postgresql-script start (code=exited, status=0/SUCCESS) Main PID: 2388 (postgres) Tasks: 43 (limit: 4915) CGroup: /system.slice/postgresql.service ├─ 828 "postgres: uyuni uyuni 127.0.0.1(49822) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 829 "postgres: uyuni uyuni 127.0.0.1(49824) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 830 "postgres: uyuni uyuni 127.0.0.1(49826) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2388 /usr/lib/postgresql14/bin/postgres -D /var/lib/pgsql/data ├─ 2430 "postgres: logger " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""> ├─ 2445 "postgres: checkpointer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2446 "postgres: background writer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2447 "postgres: walwriter " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2448 "postgres: autovacuum launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2451 "postgres: archiver last was 00000001000000CD000000B0" "" "" "" "" "" ├─ 2452 "postgres: stats collector " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2453 "postgres: logical replication launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2926 "postgres: uyuni uyuni ::1(39194) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 4397 "postgres: uyuni uyuni 127.0.0.1(48680) idle in transaction" ├─ 4403 "postgres: uyuni uyuni 127.0.0.1(48688) idle in transaction" ├─ 4472 "postgres: uyuni uyuni 127.0.0.1(48692) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5145 "postgres: uyuni uyuni 127.0.0.1(48694) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5146 "postgres: uyuni uyuni 127.0.0.1(48696) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5147 "postgres: uyuni uyuni 127.0.0.1(48700) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5148 "postgres: uyuni uyuni 127.0.0.1(48702) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5149 "postgres: uyuni uyuni 127.0.0.1(48704) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5150 "postgres: uyuni uyuni 127.0.0.1(48706) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5151 "postgres: uyuni uyuni 127.0.0.1(48708) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5152 "postgres: uyuni uyuni 127.0.0.1(48710) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5153 "postgres: uyuni uyuni 127.0.0.1(48712) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5155 "postgres: uyuni uyuni 127.0.0.1(48714) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5156 "postgres: uyuni uyuni 127.0.0.1(48716) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5157 "postgres: uyuni uyuni 127.0.0.1(48718) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5159 "postgres: uyuni uyuni 127.0.0.1(48720) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5160 "postgres: uyuni uyuni 127.0.0.1(48722) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5161 "postgres: uyuni uyuni 127.0.0.1(48724) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5226 "postgres: uyuni uyuni 127.0.0.1(48740) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5227 "postgres: uyuni uyuni 127.0.0.1(48738) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5228 "postgres: uyuni uyuni 127.0.0.1(48736) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─12183 "postgres: uyuni uyuni ::1(39198) idle in transaction" "" "" "" "" "" ├─17094 "postgres: uyuni uyuni 127.0.0.1(48018) idle in transaction" ├─18174 "postgres: uyuni uyuni 127.0.0.1(48204) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─22694 "postgres: uyuni uyuni 127.0.0.1(50300) idle in transaction" ├─22915 "postgres: uyuni uyuni 127.0.0.1(48214) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25894 "postgres: uyuni uyuni 127.0.0.1(52958) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25895 "postgres: uyuni uyuni 127.0.0.1(52960) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─26392 "postgres: uyuni uyuni 127.0.0.1(52962) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" └─26670 "postgres: uyuni uyuni 127.0.0.1(48228) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" Notice: journal has been rotated since unit was started, output may be incomplete. BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients. Just as it happened to the ssh clients since the update of Uyuni. No configuration changes since last week. Maybe it's better to recover the system to a version before the update. Regards, Tobias. -----Ursprüngliche Nachricht----- Von: Robert Paschedag [mailto:robert.paschedag@web.de <mailto:robert.paschedag@web.de> ] org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. This sounds to me, that you configuration is using the "short" name to access PostgreSQL. Try from your server, if this is resolvable. Maybe you're missing a proper "search" DNS config option. If the internal connection to your PostgreSQL is TLS encrypted, then the short name also needs to be added to the TLS SAN (Subject Alternative Name) the PostgreSQL is running, of the default TLS verification options are used 1. As mentioned... Is a simple "ping lkv-srvapp39" resolvable from within your uyuni server? 2. Try to change the host setting that defines your PostgreSQL and change it to use the full FQDN. Robert

1 0

since update 2022.08 (probably earlier) error "The scheduling service appears down"
by Thomas Weis 08 Sep '22

08 Sep '22

Hello, everyone recently we upgraded from 2022.06 to Uyuni 2022.08 without any problems. It was noticed that there has been a task in Schdule, Pending Actions since 08/27/2022, which is not being processed. The task should be aborted using chancel Actions, but this was not possible. After marking the task and executing chancel actions, the error message "Could not cancel action. Please make sure that the task scheduler is running" appeared. No tasks/schedules are listed under "Uyuni Schedules" either. systemctl status taskomatic.service indicates that Taskomatic is active. There are regular messages in /var/log/messages: " WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. taskomatic.service: Main process exited, code=exited, status=255/EXCEPTION taskomatic.service: Failed with result 'exit-code'. taskomatic.service: Scheduled restart job, restart counter is at 1 /var/log/rhn/rhn_taskomatic_daemon.log shows: "2022-09-05 09:34:47,805 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceHiLoGenerator] sequence-based id generator; use org.hibernate .id.enhanced.SequenceStyleGenerator instead.See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,808 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:54,777 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:55,003 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:55,214 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['sa.server.class']; use TYPE operator instead : type(sa.server) 2022-09-05 09:34:55,249 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['sa.server.class']; use TYPE operator instead : type(sa.server) 2022-09-05 09:34:55,263 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:56,378 [Thread-41] FATAL com.redhat.rhn.taskomatic.core.TaskomaticDaemon - Failure occurred during job recovery." Synchronize repositories does not work, pat ches and updates are not displayed / processed. Up until 08/26/2022 and Uyuni 2022.06 everything was fine and working correctly. Where can I start troubleshooting, does anyone have an idea? Thank you very much Best Regards Thomas mit freundlichen Gruessen Thomas Weis NTW Netzwerk • Telekommunikation • Datentechnik Burghaldenstrasse 24 D-71336 Waiblingen Fon: +49 7151 9440447 Fax: +49 7151 9440446 E-Mail: tweis(a)ntw-datentechnik.de Web: www.ntw-datentechnik.de Portal: https://support.ntw-datentechnik.de UST-ID: DE175034656 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 3

"The salt master has cached the public key for this node" error.
by Allen Beddingfield 30 Aug '22

30 Aug '22

I have a salt minion that I deleted (by going to "salt keys" in the web ui), stopped the salt minion process on the server, changed the hostname, and re-ran the bootstrap script. It shows up in the lists of keys, and I have selected to approve it, but it never actually turns blue so that it can be selected. The minion on the server is giving this error: "The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate". I've also tried deleting it with salt-key -d, with the same result. I have encountered this before on a SUSE Manger server, and the resolution was to remove the corresponding entry from /var/lib/salt/.ssh/known_hosts, which doesn't seem to exist on my Uyuni 2022.06 server. Any ideas on how to proceed? FYI, the minion is running CentOS 7.x. Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

2 2

AW: Uyuni 2022.08 is released!
by Crefeld, Tobias LKV Bayern e.V. 29 Aug '22

29 Aug '22

Hi, is this true for packages like "Uyuni Server", too? After upgrading from 2022.06 to 2022.08 "zypper up" shows: Loading repository data... Reading installed packages... The following 4 package updates will NOT be installed: Uyuni-Server-release cobbler netty supportutils-plugin-salt The following product update will NOT be installed: "Uyuni Server" Nothing to do. zypper lr says: Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh --+-----------------------------+------------------------------------------- --------------------------------------------------+---------+-----------+--- ----- 1 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 2 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | No 3 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | No 4 | repo-oss | Main Repository | Yes | (r ) Yes | No 5 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 6 | repo-sle-update | Update repository wiht updates from SUSE Linux Enterprise | Yes | (r ) Yes | No 7 | repo-update | Main Update Repository | Yes | (r ) Yes | No 8 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | No 9 | uyuni-server-stable | Uyuni Server Stable | Yes | (r ) Yes | No Thanks & regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Simon Avery [mailto:Simon.Avery@atass-sports.co.uk] Gesendet: Dienstag, 16. August 2022 11:05 An: Julio Gonzalez <jgonzalez(a)suse.com>; General discussion related to the openSUSE Uyuni project <users(a)lists.uyuni-project.org> Cc: Paul-Andre Panon <ppanon(a)sierrawireless.com> Betreff: RE: Uyuni 2022.08 is released! Thanks for the prompt clarification, Julio. Leaving them be. -----Original Message----- From: Julio Gonzalez <jgonzalez(a)suse.com> Sent: 16 August 2022 09:41 To: General discussion related to the openSUSE Uyuni project <users(a)lists.uyuni-project.org>; Simon Avery <Simon.Avery(a)atass-sports.co.uk> Cc: Paul-Andre Panon <ppanon(a)sierrawireless.com> Subject: [EXTERNAL EMAIL] Re: Uyuni 2022.08 is released! Hi all, Never change the vendor for packages, unless we ask for it at the release notes. Doing it can render Uyuni unusable. There are some packages we require strictly from our repositories. Best regards. El martes, 16 de agosto de 2022 10:32:15 (CEST) Simon Avery escribió: > Just chipping in. > > I don't have the original mgr-create-bootstrap-repo error, but during > the upgrade from 2022.06 to 08, I also have some files that weren't upgraded. > > === > The following 3 package updates will NOT be installed: > cobbler netty supportutils-plugin-salt Nothing to do. > === > > Attempting to update them manually gives me options, but I'm unsure > what to do. Uyuni itself seems to be operating normally since the upgrade. > > === > ata-oxy-uyuni01:/home/simon # zypper install cobbler netty > supportutils-plugin-salt Loading repository data... > Reading installed packages... > 'netty' is already installed. > There is an update candidate for 'netty' from vendor 'SUSE LLC > <https://www.suse.com/>', while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install netty-4.1.75-150200.4.9.1.x86_64' to install this candidate. > 'cobbler' is already installed. > There is an update candidate for 'cobbler' from vendor 'openSUSE', > while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install cobbler-3.3.1.0+git.f5b0599a-bp154.1.26.noarch' to install this candidate. 'supportutils-plugin-salt' is already installed. > There is an update candidate for 'supportutils-plugin-salt' from > vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the > current vendor is 'SUSE LLC <https://www.suse.com/>'. Use 'zypper > install supportutils-plugin-salt-1.2.1-1.4.uyuni2.noarch' to install > this candidate. Resolving package dependencies... > Nothing to do. > === > > -----Original Message----- > From: Paul-Andre Panon via Uyuni Users <users(a)lists.uyuni-project.org> > Sent: 12 August 2022 17:58 > To: Julio Gonzalez <jgonzalez(a)suse.com>; General discussion related to > the openSUSE Uyuni project <users(a)lists.uyuni-project.org> Cc: > Paul-Andre Panon <ppanon(a)sierrawireless.com> > Subject: [EXTERNAL EMAIL] RE: Uyuni 2022.08 is released! > > Well, two packages aren't updated because there appears to be > duplicate packages from different repos for netty and cobbler. > > # zypper update > Loading repository data... > Reading installed packages... > > The following 2 package updates will NOT be installed: > cobbler netty > Nothing to do. > > # zypper install cobbler netty > Loading repository data... > Reading installed packages... > 'netty' is already installed. > There is an update candidate for 'netty' from vendor 'SUSE LLC > <https://www.suse.com/>', while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install netty-4.1.75-150200.4.9.1.x86_64' to install this candidate. > 'cobbler' is already installed. > There is an update candidate for 'cobbler' from vendor 'openSUSE', > while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install cobbler-3.3.1.0+git.f5b0599a-bp154.1.26.noarch' to install this candidate. Resolving package dependencies... > Nothing to do. > > I've been assuming that Uyuni vendor packages are the correct ones. If > I try use the zipper install command above then it indicates a whole > bunch of Uyuni package dependencies would get removed, so I'm fairly > sure the one currently installed is the right one. > > # zypper install netty-4.1.75-150200.4.9.1.x86_64 Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: the installed spacewalk-java-4.3.35-1.12.uyuni2.noarch > requires 'netty < 4.1.45', but this requirement cannot be provided Solution 1: > Following actions will be done: deinstallation of > spacewalk-java-4.3.35-1.12.uyuni2.noarch > deinstallation of spacewalk-common-4.3.5-1.12.uyuni2.noarch > deinstallation of spacewalk-postgresql-4.3.5-1.12.uyuni2.noarch > deinstallation of susemanager-tools-4.3.18-1.11.uyuni2.x86_64 > deinstallation of patterns-uyuni_server-2022.08-2.2.uyuni2.x86_64 > deinstallation of susemanager-4.3.18-1.11.uyuni2.x86_64 > deinstallation of spacewalk-backend-tools-4.3.15-1.10.uyuni2.noarch > deinstallation of > supportutils-plugin-susemanager-4.3.4-1.24.uyuni2.noarch > deinstallation of spacewalk-setup-4.3.10-1.2.uyuni2.noarch > deinstallation of spacewalk-utils-4.3.13-1.6.uyuni2.noarch > Solution 2: do not install netty-4.1.75-150200.4.9.1.x86_64 Solution 3: > break spacewalk-java-4.3.35-1.12.uyuni2.noarch by ignoring some of its > dependencies > > Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c > > Otherwise, the server appears up-to-date, has been rebooted, and we > get the error. That said the reprepro does seem different than the > version you indicated. > > # rpm -q -i reprepro > Name : reprepro > Version : 5.3.0 > Release : 2.33.uyuni2 > Architecture: x86_64 > Install Date: Tue Jun 28 15:25:55 2022 > Group : System/Packages > Size : 1179511 > License : GPL-2.0 > Signature : RSA/SHA256, Wed Jun 22 09:25:40 2022, Key ID 972e5d6c0d20833e > Source RPM : reprepro-5.3.0-2.33.uyuni2.src.rpm > Build Date : Wed Jun 22 09:25:33 2022 Build Host : lamb02 > Relocations : (not relocatable) > Packager : https://www.suse.com/ > Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni > URL : https://salsa.debian.org/brlink/reprepro > Summary : Handle local repositories of debian packages > Description : > This project is a lightweight feature complete manager of a debian > package (i.e. binary .deb and source .dsc+.tar.gz+.diff.gz) > repository. Emphasis is put on having all packages in the > pool/-directory, maximal checking of all sources, generation of signed Release file, Contents, ... Distribution: > systemsmanagement:Uyuni:Master / openSUSE_Leap_15.4 > > -----Original Message----- > From: Julio Gonzalez <jgonzalez(a)suse.com> > Sent: Thursday, August 11, 2022 2:35 AM > To: General discussion related to the openSUSE Uyuni project > <users(a)lists.uyuni-project.org> Cc: Paul-Andre Panon > <ppanon(a)sierrawireless.com>; Paul-Andre Panon via Uyuni Users > <users(a)lists.uyuni-project.org> Subject: Re: Uyuni 2022.08 is released! > > Did you fully upgrade the server? > > What's the changelog of the reprepro package? > > IIRC we had to fix this package so it could handle the new zstd > compresed control file, and the fix is part of 2022.08: > > https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/S > table/ > images/repo/Uyuni-Server-POOL-x86_64-Media1/x86_64/reprepro-5.3.0-2.8. > uyuni2 > .x86_64.rpm > > $ rpm -q --changelog reprepro-5.3.0-2.8.uyuni2.x86_64.rpm|more > * mié jun 29 2022 Julio González Gil <jgonzalez(a)suse.com> > - Bump up the maxsize on a fixed-size C buffer to avoid breaking on some > autogenerated rust packages > * 0001-Bump-up-the-maxsize-on-a-fixed-size-C-buffer-to-avoi.patch > - Flush stdout and stderr before execv of an end hook > * 0002-Flush-stdout-stderr-before-calling-endhook.patch > - Add support for Zstd compressed debs > * 0003-Add-Zstd-support.patch > > If you don't have this changelog entry, and if you already updated > your server, maybe be the mirror you used still didn't have the > reprepro version? > El jueves, 11 de agosto de 2022 11:28:54 (CEST) Paul-Andre Panon via > Uyuni Users escribió: > > That's excellent! I was worried we might have to wait longer for > > Ubuntu > > 22.04 support after the lack of a 2022.07 release. Thank you. > > > > That said, when I tried to create an Ubuntu 22.04 bootstrap repo, I > > got the following error message: > > > > # mgr-create-bootstrap-repo --create ubuntu-22.04-amd64-uyuni > > > > Creating bootstrap repo for ubuntu-22.04-amd64-uyuni copy > > 'venv-salt-minion-3004-4.6.uyuni.amd64-deb' > > Could not find a suitable control.tar file within > > '/srv/www/htdocs/pub/repositories/ubuntu/22/4/bootstrap.tmp/debs/ven > > v- > > salt- minion-3004-4.6.uyuni.amd64-deb.deb'! There have been errors! > > Error creating bootstrap repo. > > > > Could it be that that function isn't benefiting from the updates to > > support the new compression algorithm used for Ubuntu 22.04 packages? > > > > Cheers, > > > > Paul-Andre > > > > -----Original Message----- > > From: Julio Gonzalez via Uyuni Users <users(a)lists.uyuni-project.org> > > Sent: Wednesday, August 10, 2022 4:07 AM > > To: announce(a)lists.uyuni-project.org; devel(a)lists.uyuni-project.org; > > users(a)lists.uyuni-project.org Cc: Julio Gonzalez > > <jgonzalez(a)suse.com> > > Subject: Uyuni 2022.08 is released! > > > > VERY IMPORTANT: 2022.08 requires special procedures if you are not > > already using Uyuni 2022.06! The configuration files for the proxy > > on containers also needs to be updated. Make sure you read the > > release notes before updating! > > > > We are happy to announce the availability of Uyuni 2022.08. Most > > openSUSE mirrors should already have 2022.08, but if you do not see > > it yet, wait a few hours until your local openSUSE mirror is synced. > > > > At https://www.uyuni-project.org/pages/stable-version.html you will > > find all the resources you need to start working with Uyuni 2022.08, > > including the release notes, documentation, requirements and setup > > instructions. > > > > This is the list of highlights for this release: > > > > - Ubuntu 22.04 as client > > - GPG key handling in Uyuni > > - Disabling locally defined repositories > > - Technology Preview: Helm chart to deploy containerized Uyuni Proxy > > > > and Retail Branch Server > > > > Remember that Uyuni will follow a rolling release planning, so the > > next version will contain bugfixes for this one and any new features. > > There will be no maintenance of 2022.08 > > > > As always, we hope you will enjoy Uyuni 2022.08 and we invite > > everyone of you to send us your feedback [1] and of course your > > patches, if you can contribute. > > > > Happy hacking! > > > > [1] https://www.uyuni-project.org/pages/contact.html > > > > -- > > Julio González Gil > > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Error "installation medium unavailable" when using autoinstall distro based on tftpboot-installation (SLE-15-SP4-x86_64)
by Heiner W. 25 Aug '22

25 Aug '22

Hi List, for autoinstalling SLES15-SP4 i tried to use the Data from tftpboot-installation package as stated in Uyuni Client Config Documentation "Distribution Based on a RPM Package." (https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/auto…) i queried RPM "tftpboot-installation-SLE-15-SP4-x86_64-16.57.20-150400.1.18.noarch.rpm" on my uyuni Server and found out it installs into "/usr/share/tftpboot-installation" My autoinstall distro files are stored in "/var/autoinstall" where i have plenty of space, so i symlinked: ln -s /var/autoinstall/tftpboot-installation /usr/share/tftpboot-installation After "zypper install"ing said RPM i found this content in "/var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/": EFI README boot net In uyuni gui i created my autoinstall distro using tree path "/var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64" and created matching profile and activation key. I found no special instructions in documentation when using tftpboot-installation instead of full ISO, so i sticked to the defaults. Cobbler shows my new autoinstall distro/profile. When trying to install a System it is able to load linuxrc but says "installation medium unavailable". Uyuni Tomcat logs this: 2022-08-24 15:39:44,266 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/content Not Found .. 404! 2022-08-24 15:39:44,272 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-8] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/repodata/repomd.xml Not Found .. 404! 2022-08-24 15:39:44,278 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/media.1/products Not Found .. 404! It seems like i must set a special path to further Data (media/repos) that isn't included in tftpboot-installation but i don't know what to configure where. For older SLES SPs i downloaded the full 12GB install iso (like "SLE-15-SP3-Full-x86_64-GM-Media1"), unpacked it and put all files into uyuni "tree path" directory of its autoinstall distro. It would be great if i wouldn't need that extra space for SP4 as all RPMs are already stored within my synced Upstream/Product and CLM Repos. Any hint is much appreciated! Thanks, Heiner

1 1

Uyuni 2022.08 is released!
by Julio Gonzalez 24 Aug '22

24 Aug '22

VERY IMPORTANT: 2022.08 requires special procedures if you are not already using Uyuni 2022.06! The configuration files for the proxy on containers also needs to be updated. Make sure you read the release notes before updating! We are happy to announce the availability of Uyuni 2022.08. Most openSUSE mirrors should already have 2022.08, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.08, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Ubuntu 22.04 as client - GPG key handling in Uyuni - Disabling locally defined repositories - Technology Preview: Helm chart to deploy containerized Uyuni Proxy and Retail Branch Server Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.08 As always, we hope you will enjoy Uyuni 2022.08 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

6 18

[uyuni-users] Fresh Install uyuni 2020.05 Error generating bootstrap repo
by Thomas Weis 24 Aug '22

24 Aug '22

Hello everyone we are configuring a fresh installation of Uyuni 2020.05 After a successful reposync of SUSE Linux Enterprise Server 15 SP1 x86_64 we get an error message: Type: Creating Bootstrap Repository failed Summary: Error generating bootstrap repo for: SLE-15-SP1-x86_64 show details said: ERROR: package 'hwdata' not found ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: package 'python3-uyuni-common-libs' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found The installation was error-free, we proceeded exactly according to the documentation. What is our mistake? thanks for suggestions Regards Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 2

IMPORTANT: Problems creating the bootstrap repository for Ubuntu 22.04
by Julio Gonzalez 17 Aug '22

17 Aug '22

Hello, There's a bug affecting Uyuni 2022.08 and the bootstrap repository creating for Ubuntu 22.04. Please check https://github.com/uyuni-project/uyuni/issues/5764#issuecomment-1217969673 for all the information about the problem, and how apply the fix Uyuni for 2022.08. The fix will be part of Uyuni 2022.09. Thanks to kyle-aas, Lukas Magauer (lumarel) and Chri (chr78) for the bug report and all the help provided for debugging the issue. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

AW: RE: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 16 Aug '22

16 Aug '22

Hi Robert, "ping lkv-srvapp39" and "host lkv-srvapp39" work as expected. A request with psql works fine, too: uyuni@lkv-srvapp39:~> psql -h lkv-srvapp39 Passwort für Benutzer uyuni: psql (14.3) SSL-Verbindung (Protokoll: TLSv1.3, Verschlüsselungsmethode: TLS_AES_256_GCM_SHA384, Bits: 256, Komprimierung: aus) Geben Sie »help« für Hilfe ein. uyuni=# How can I add the short name to the "TLS SAN"? Where can I configure the host name the application is using? I don't know if It is important, but according to the status of systemctl Uyuni's applications connect to the DB-server via 127.0.0.1 which resolves to localhost: lkv-srvapp39:/var/lib/pgsql/data # systemctl status postgresql ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-08-02 10:41:35 CEST; 2 weeks 0 days ago Process: 2357 ExecStart=/usr/share/postgresql/postgresql-script start (code=exited, status=0/SUCCESS) Main PID: 2388 (postgres) Tasks: 43 (limit: 4915) CGroup: /system.slice/postgresql.service ├─ 828 "postgres: uyuni uyuni 127.0.0.1(49822) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 829 "postgres: uyuni uyuni 127.0.0.1(49824) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 830 "postgres: uyuni uyuni 127.0.0.1(49826) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2388 /usr/lib/postgresql14/bin/postgres -D /var/lib/pgsql/data ├─ 2430 "postgres: logger " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""> ├─ 2445 "postgres: checkpointer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2446 "postgres: background writer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2447 "postgres: walwriter " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2448 "postgres: autovacuum launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2451 "postgres: archiver last was 00000001000000CD000000B0" "" "" "" "" "" ├─ 2452 "postgres: stats collector " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2453 "postgres: logical replication launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2926 "postgres: uyuni uyuni ::1(39194) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 4397 "postgres: uyuni uyuni 127.0.0.1(48680) idle in transaction" ├─ 4403 "postgres: uyuni uyuni 127.0.0.1(48688) idle in transaction" ├─ 4472 "postgres: uyuni uyuni 127.0.0.1(48692) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5145 "postgres: uyuni uyuni 127.0.0.1(48694) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5146 "postgres: uyuni uyuni 127.0.0.1(48696) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5147 "postgres: uyuni uyuni 127.0.0.1(48700) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5148 "postgres: uyuni uyuni 127.0.0.1(48702) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5149 "postgres: uyuni uyuni 127.0.0.1(48704) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5150 "postgres: uyuni uyuni 127.0.0.1(48706) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5151 "postgres: uyuni uyuni 127.0.0.1(48708) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5152 "postgres: uyuni uyuni 127.0.0.1(48710) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5153 "postgres: uyuni uyuni 127.0.0.1(48712) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5155 "postgres: uyuni uyuni 127.0.0.1(48714) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5156 "postgres: uyuni uyuni 127.0.0.1(48716) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5157 "postgres: uyuni uyuni 127.0.0.1(48718) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5159 "postgres: uyuni uyuni 127.0.0.1(48720) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5160 "postgres: uyuni uyuni 127.0.0.1(48722) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5161 "postgres: uyuni uyuni 127.0.0.1(48724) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5226 "postgres: uyuni uyuni 127.0.0.1(48740) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5227 "postgres: uyuni uyuni 127.0.0.1(48738) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5228 "postgres: uyuni uyuni 127.0.0.1(48736) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─12183 "postgres: uyuni uyuni ::1(39198) idle in transaction" "" "" "" "" "" ├─17094 "postgres: uyuni uyuni 127.0.0.1(48018) idle in transaction" ├─18174 "postgres: uyuni uyuni 127.0.0.1(48204) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─22694 "postgres: uyuni uyuni 127.0.0.1(50300) idle in transaction" ├─22915 "postgres: uyuni uyuni 127.0.0.1(48214) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25894 "postgres: uyuni uyuni 127.0.0.1(52958) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25895 "postgres: uyuni uyuni 127.0.0.1(52960) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─26392 "postgres: uyuni uyuni 127.0.0.1(52962) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" └─26670 "postgres: uyuni uyuni 127.0.0.1(48228) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" Notice: journal has been rotated since unit was started, output may be incomplete. BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients. Just as it happened to the ssh clients since the update of Uyuni. No configuration changes since last week. Maybe it's better to recover the system to a version before the update. Regards, Tobias. -----Ursprüngliche Nachricht----- Von: Robert Paschedag [mailto:robert.paschedag@web.de] org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. This sounds to me, that you configuration is using the "short" name to access PostgreSQL. Try from your server, if this is resolvable. Maybe you're missing a proper "search" DNS config option. If the internal connection to your PostgreSQL is TLS encrypted, then the short name also needs to be added to the TLS SAN (Subject Alternative Name) the PostgreSQL is running, of the default TLS verification options are used 1. As mentioned... Is a simple "ping lkv-srvapp39" resolvable from within your uyuni server? 2. Try to change the host setting that defines your PostgreSQL and change it to use the full FQDN. Robert

2 1

Promoting new Version in CLM Project Environment: How long should it normally take? ("Waiting for repositories data to be generated")
by Heiner W. 08 Aug '22

08 Aug '22

Hi List, we wanted to apply latest available SP2 updates and patches before migrating to SP3. 3.5 hours ago i triggered a final "promote" for the current SLES15 SP2 CLM Project Environment/stage (containing base, packagehub, Server-Applications, Public-Cloud15 and a few small custom repos). Now we are waiting impatiently (WebGUI still says "Waiting for repositories data to be generated") and affected systems aren't aware of new package Versions when calling zypper ref && zypper up. What are your experiences how long repo data regeneration "normally" takes? How can it be tuned? - Which config parameters should we change? - should we increase CPU or Memory? Uyuni VM currently runs on 4x2.2GHz and 32GB Memory We have 65 managed Systems running sles15 sp2 or sp3 in 3 CLM Projects we are running on default values: # java.taskomatic_channel_repodata_workers=2 # taskomatic.java.maxmemory=4096 # taskomatic.java.initmemory=256 # ps -efa|grep tasko root 14974 1 0 Jul28 ? 00:00:00 /bin/sh /usr/sbin/taskomatic root 14989 14974 1 Jul28 ? 04:38:51 /usr/bin/java -Djava.library.path=/usr/lib:/usr/lib64 -classpath /usr/share/rhn/classes:/usr/share/rhn/lib/spacewalk-asm.jar:/usr/share/rhn/lib/rhn.jar:/usr/share/rhn/lib/java-branding.jar:/usr/share/spacewalk/taskomatic/* -Dibm.dst.compatibility=true -Dfile.encoding=UTF-8 -Xms256m -Xmx4096m --add-modules java.annotation,com.sun.xml.bind --add-exports java.annotation/javax.annotation.security=ALL-UNNAMED --add-opens java.annotation/javax.annotation.security=ALL-UNNAMED com.redhat.rhn.taskomatic.core.TaskomaticDaemon Current Load: top - 12:37:44 up 25 days, 58 min, 2 users, load average: 0.00, 0.18, 0.46 Tasks: 369 total, 1 running, 368 sleeping, 0 stopped, 0 zombie %Cpu(s): 23.1 us, 1.5 sy, 0.0 ni, 75.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 32107.11+total, 1894.559 free, 9224.531 used, 20988.02+buff/cache MiB Swap: 0.000 total, 0.000 free, 0.000 used. 18222.20+avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24611 postgres 20 0 4175884 156508 146952 S 53.33 0.476 0:36.23 postgres 13345 tomcat 20 0 5006136 1.317g 23912 S 40.00 4.202 60:20.16 java 14979 root 20 0 4267224 288120 20300 S 6.667 0.876 27:11.55 java Thanks, Heiner

1 0

AW: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 08 Aug '22

08 Aug '22

Hi Simon, thanks for your hints! I followed them and received a lot of messages but actually I'm no java developer. I tried to reduce the log output by leaving out the "at"-lines but it is still large. Hope that no one gets annoyed too much: 2022-08-02 09:56:00,022 [DefaultQuartzScheduler_Worker-18] WARN org.hibernate.orm.deprecation - HHH90000022: Hibernate's legacy org.hibernate.Criteria API is deprecated; use the JPA javax.persistence.criteria.CriteriaQuery instead 2022-08-02 09:56:02,718 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.orm.deprecation - HHH020100: The Ehcache second-level cache provider for Hibernate is deprecated. See https://hibernate.atlassian.net/browse/HHH-12441 for details. 2022-08-02 09:56:33,348 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@1c8f4b1f -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,348 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,348 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator - HHH000342: Could not obtain connection to query metadata : Connections could not be acquired from the underlying database! 2022-08-02 09:56:33,354 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@5ab931dd -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,354 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,360 [DefaultQuartzScheduler_Worker-1] WARN net.sf.ehcache.DiskStorePathManager - diskStorePath '/tmp' is already used by an existing CacheManager either in the same VM or in a different process. The diskStore path for this CacheManager will be set to /tmp/ehcache_auto_created2394383558487899130diskstore. To avoid this warning consider using the CacheManager factory methods to create a singleton CacheManager or specifying a separate ehcache configuration (ehcache.xml) for each CacheManager instance. 2022-08-02 09:56:33,361 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#2] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@68e07fff -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,362 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#2] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@3b518b25 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@5599538e -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,375 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.engine.jdbc.spi.SqlExceptionHelper - SQL Error: 0, SQLState: null 2022-08-02 09:56:33,375 [DefaultQuartzScheduler_Worker-1] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Connections could not be acquired from the underlying database! 2022-08-02 09:56:33,375 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,384 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Executing a task threw an exception: org.quartz.JobExecutionException 2022-08-02 09:56:33,385 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Message: Unable to update reporting db 2022-08-02 09:56:33,385 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Cause: {} org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection Caused by: java.sql.SQLException: Connections could not be acquired from the underlying database! Caused by: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. Caused by: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,387 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Stack trace:org.quartz.JobExecutionException: Unable to update reporting db [See nested exception: org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection] Caused by: org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection Caused by: java.sql.SQLException: Connections could not be acquired from the underlying database! Caused by: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. Caused by: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:57:00,022 [DefaultQuartzScheduler_Worker-2] WARN org.hibernate.orm.deprecation - HHH90000022: Hibernate's legacy org.hibernate.Criteria API is deprecated; use the JPA javax.persistence.criteria.CriteriaQuery instead Maybe someone has a better understanding of this stuff and can explain what's going wrong? BTW: The messages with "QuartzScheduler" are repeated every minute, independent of the status of "mgr-update-reporting-bunch". TIA! Regards. Tobias Crefeld.

4 3

Adding Oracle Linux
by Crefeld, Tobias LKV Bayern e.V. 01 Aug '22

01 Aug '22

Hi, I'd like to add Repositories for Oracle Linux 8 to the Uyuni-Server. Therefore I'm following the advice at https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/clien ts-oracle.html#_add_software_channels and enter spacewalk-common-channels oraclelinux8 Afterwards system requests SUSE-Manager's credentials. There I enter the credentials that I use to logon to the Web-UI which can be found at the Web-UI under Users / User List / Active with the roles "SUSE Manager Administrator" and "Organization Administrator". Afterwards it reports Traceback (most recent call last): File "/usr/bin/spacewalk-common-channels", line 269, in <module> client, key = connect(options.user, options.password, options.server) File "/usr/bin/spacewalk-common-channels", line 119, in connect key = xmlrpc_login(client, options.user, password) File "/usr/lib/python3.6/site-packages/uyuni/common/cli.py", line 74, in xmlrpc_login sessionkey = client.auth.login(username, password) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1112, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1452, in __request verbose=self.__verbose File "/usr/lib64/python3.6/xmlrpc/client.py", line 1154, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1187, in single_request dict(resp.getheaders()) xmlrpc.client.ProtocolError: <ProtocolError for localhost/rpc/api: 400 Bad Request> If I'm using tools like spacewalk-remove-channel, the same credentials work fine. Any idea? Regards, Tobias Crefeld.

1 0

Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 28 Jul '22

28 Jul '22

Hi, recently I upgraded the Uyuni system from 2021.07 to 2022.06. Several tests were successful so I'm not sure if the current problems come from the update. There are two issues: 1. Since Uyuni's update several clients don't check in any more. All of them are using "Push via SSH tunnel" or "Push via SSH" as contact method. Salt clients with contact method "Default" (SLES15-SP3) run fine. Client OS is "openSUSE Leap 15.1 x86_64" or "SUSE Linux Enterprise Server 12 SP5 x86_64". There is no "configuration" or scripting - the only target is to monitor the patch level and provide repositories. 2. After a reboot of the Uyuni host I was sent an email with this content: "Taskomatic bunch mgr-update-reporting-bunch was scheduled to run within the update-reporting-default schedule. Subtask mgr-update-reporting failed. For more information check null." (Checking "null" wasn't successful) Any hints are welcome! Regards, Tobias Crefeld.

2 1

A question about venv-salt-minion and systemd
by Simon Avery 22 Jul '22

22 Jul '22

Hi A little flummoxed about this. I've switched to using venv-salt-minion on clients, and it installs okay. However, we require /tmp to have the noexec flag. Salt doesn't like this very much. Our previous workaround was to create a file in /etc/systemd/system/salt-minion.service.d containing [Service] Environment="TMPDIR=/usr/tmp" This told salt-minion to use a different tmpdir that did have the exec flag and it was happy again. However, venv-salt-minion doesn't read that file, because it's a different service. I assumed I could just create /etc/systemd/system/venv-salt-minion.service.d instead, but the process is not reading this. If I edit the system file directly and add that file it works, but I would prefer to use a drop-in file for this. I'm not overly familiar with venv programs, and less so when combined with systemd. Can anyone please point me the right way to do this? Thanks S

2 3

A fix for using HTTP proxies for repository synced is now released
by Julio Gonzalez 21 Jul '22

21 Jul '22

The fix requires two things: - Uyuni 2022.06 - The latest python3-urlgrabber from openSUSE Leap 15.4 The issue is being tracked at https://github.com/uyuni-project/uyuni/issues/4850 Special thanks to Dan Holstad, hbrown-uiowa, phibid and SpeedBlack for the report, and to Dominik Wombacher and Pablo Suárez for the fix. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Re: Error trying to bootstrap / register / onboard sles15sp3 salt client/minion
by Heiner W. 15 Jul '22

15 Jul '22

Hi List, here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21") What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt* Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup ... and rebooted the client os. I tried bootstrapping with new venv salt and also the old salt-minion packages. I even tried using another network interface on my client, with another ip, net, route to uyuni. Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try? Thanks, Heiner

3 5

Where is mgr-bootstrap on a containerized proxy?
by Paul-Andre Panon 14 Jul '22

14 Jul '22

After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy? Thanks Paul-Andre Panon

2 9

Spacewalk add channel has failed
by Martin Willisegger 12 Jul '22

12 Jul '22

Hello list Currently I cannot attach a specific channel for opensuse Leap 15.4 to Uyuni. I get the following error message: uyuni:~ # spacewalk-common-channels -a x86_64 opensuse_leap15_4-sle-updates SUSE Manager username: admin SUSE Manager password: Base channel 'openSUSE Leap 15.4 (x86_64)' - exists 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 I think there is a conflict with the existing subchannel from Leap 15.3: opensuse_leap15_3-x86_64-sle-updates However, this repo is needed for 15.3 and 15.4. What possibility do i have to import and attach this channel for 15.4 anyway? Best regards Martin

1 0

Patch for Uyuni 2022.06
by Julio Gonzalez 06 Jul '22

06 Jul '22

Hello! Several users syncing openSUSE Leap 15.3/15.4 and/or the SUSE PackageHub reported that they are getting the following error running reposync from CLI, or at the WebUI notifications area: 2022/07/05 09:22:01 +02:00 Importing packages to DB: 2022/07/05 09:22:02 +02:00 'rpm.hdr' object has no attribute 'get' Please note that this bug does **not** prevent syncing other packages, it just means that the package `kicad-packages3D` version `5.1.8-bp154.1.18` failed to sync due to the bug. So it wont be available for Uyuniu clients, as it won't be synced at the server. Other than that the reposync will work just as usual. If automated syncing is for the affected channels is enabled, then you will also get notifications at the UI (the "bell" icon). A patch for Uyuni 2022.06 to fix both problems was just published, in case you do not want to wait for Uyuni 2022.07 (it will be part of that release as well). You can apply the patch by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are using Uyuni 2022.05 or older: make sure you update to 2022.06, and remember 2022.06 changes the base OS to openSUSE Leap 15.4, so you need to follow a special procedure (check the release notes). Thank to all users that reported the issue, and specially to Jonathan Müller (LordofAgents) for providing the information about the affected package. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

How to mirror/sync repos of type yast
by Heiner Wulfhorst 04 Jul '22

04 Jul '22

Hi List, i need to sync a HPE Foundation Repo into my CLM: https://update1.linux.hpe.com/repo/hpe-foundation/2.4.3/Suse/SLES15-SP3/ Unfortunately it seems to have yast structure: https://en.opensuse.org/openSUSE:Standards_YaST2_Repository_Metadata#Reposi… How can I mirror it into uyuni? Configuring it as yum type repo produces this error when trying to sync: *# spacewalk-repo-sync --type yum --channel hpe-foundation-workaround* 16:52:20 ====================================== 16:52:20 | Channel: hpe-foundation-workaround 16:52:20 ====================================== 16:52:20 Sync of channel started. Retrieving repository 'hpe-foundation-workaround' metadata ......................................................................................................................[done] Building repository 'hpe-foundation-workaround' cache ...........................................................................................................................[done] All repositories have been refreshed. 16:52:24 Unexpected error: <class 'FileNotFoundError'> 16:52:24 Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 610, in sync repo_checksum_type = plugin.get_md_checksum_type() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/repo_plugins/yum_src.py", line 750, in get_md_checksum_type infile = fileutils.decompress_open(repomd_path) File "/usr/lib/python3.6/site-packages/uyuni/common/fileutils.py", line 521, in decompress_open file_obj = codecs.open(filename, 'r', encoding="utf8") File "/usr/lib64/python3.6/codecs.py", line 897, in open file = builtins.open(filename, mode, buffering) *FileNotFoundError: [Errno 2] No such file or directory: '/var/cache/rhn/reposync/1/hpe_foundation_workaround_repo/var/cache/zypp/raw/hpe-foundation-workaround/repodata/repomd.xml'* 16:52:24 Total time: 0:00:04 Thanks, BR, Heiner

3 4

Re: Uyuni 2022.06 is released!
by Julio Gonzalez 27 Jun '22

27 Jun '22

On lunes, 27 de junio de 2022 17:37:49 (CEST) Michele Bussolotto wrote: > > "In the Uyuni Server Web UI, navigate to proxy system's details page, > > click > > the Reactivation subtab. Click Generate New Key to generate a reactivation > > key." > > > > Is this really necessary ? I understand that we don't need to re-register > > the proxy. Just selecting the 15.4 repos and executing on the proxy > > 'zypper > > dup --allow-vendor-change' is enough, correct ? > > Correct, reactivation is no longer required. Thanks for noticing! @Philippe, can you maybe prepare a PR for the doc? It's quite easy, actually, the file is at https://github.com/uyuni-project/uyuni-docs/blob/master/modules/installatio… > ________________________________________ > From: Julio Gonzalez > Sent: Monday, June 27, 2022 5:27 PM > To: General discussion related to the openSUSE Uyuni project; > announce(a)lists.uyuni-project.org; devel(a)lists.uyuni-project.org; Bidault, > Philippe; Michele Bussolotto Subject: Re: Uyuni 2022.06 is released! > > > I can't tell for sure. > > @Michele? > > If it's not needed, then we should remove it from the doc. > > On lunes, 27 de junio de 2022 16:13:08 (CEST) Bidault, Philippe wrote: > > Hi Julio, > > > > Thanks for this ! Uyuni server upgraded, so far so good. > > > > However, I am still confused with the Proxy upgrade procedure > > (https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation-and-upgrad > > e > > /proxy-uyuni.html): > > > > "In the Uyuni Server Web UI, navigate to proxy system's details page, > > click > > the Reactivation subtab. Click Generate New Key to generate a reactivation > > key." > > > > Is this really necessary ? I understand that we don't need to re-register > > the proxy. Just selecting the 15.4 repos and executing on the proxy > > 'zypper > > dup --allow-vendor-change' is enough, correct ? > > > > Regards, > > Philippe. > > > > > > > > Philippe Bidault | Unix Engineer | Getronics > > > > M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com > > > > > > > > > > Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. > > Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, > > Porcel, 21 planta 11, 08016 Barcelona, Spain. > > > > The information transmitted is intended only for use by the addressee and > > may contain confidential and/or privileged material. Any review, > > re-transmission, dissemination or other use of it, or the taking of any > > action in reliance upon this information by persons and/or entities other > > than the intended recipient is prohibited. If you received this in error, > > please inform the sender and/or addressee immediately and delete the > > material. Thank you. > > > > Legal disclaimer: www.getronics.com/legal and further details of how we > > treat your personal data can be found in our privacy policy > > <www.getronics.com/policy-pages/corporate-policy-legal-disclaimer> > > -----Original Message----- > > From: Julio Gonzalez via Uyuni Users <users(a)lists.uyuni-project.org> > > Sent: 27 June 2022 09:59 > > To: announce(a)lists.uyuni-project.org; users(a)lists.uyuni-project.org; > > devel(a)lists.uyuni-project.org Cc: Julio Gonzalez <jgonzalez(a)suse.com> > > Subject: Uyuni 2022.06 is released! > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Uyuni 2022.06 is released!
by Julio Gonzalez 27 Jun '22

27 Jun '22

VERY IMPORTANT: Uyuni 2022.06 switches the base OS for the Server and the Proxy to openSUSE Leap 15.4. Make sure you read the release notes before updating! We are happy to announce the immediate availability of Uyuni 2022.06. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.06, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Upgrade notes (read them carefully!) - Base system upgrade to openSUSE Leap 15.4 - PostgreSQL 14 - Salt 3004 - New products enabled Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.06 As always, we hope you will enjoy Uyuni 2022.06 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

3 5

Re: [EXTERNAL] Re: Uyuni 2022.06 is released!
by Allen Beddingfield 27 Jun '22

27 Jun '22

We really need a well-documented and support way to progress from one version to another, without jumping straight to the current version, for those who get behind. I know there used to be an archive of each version out there that one could manually point to for accomplishing this. Does that still exist? -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu ________________________________ From: Julio Gonzalez via Uyuni Users Sent: Monday, June 27, 2022 8:41 AM To: General discussion related to the openSUSE Uyuni project; Simon Avery Cc: Julio Gonzalez Subject: [EXTERNAL] Re: Uyuni 2022.06 is released! Needless to say, you should not leave Uyuni without updates for a year, so ideally everyone should be already on 2022.05 or, at least, something newer than 2021.06 :-) If someone is on 2021.05 or earlier, updating could work, but it's not supported. Hope it helps. > Or should I follow the minor update procedure to go from 05 to 06 before > doing the major update procedure? > > Thanks, > > Simon > > -----Original Message----- > From: Julio Gonzalez via Uyuni Users <users(a)lists.uyuni-project.org> > Sent: 27 June 2022 08:59 > To: announce(a)lists.uyuni-project.org; users(a)lists.uyuni-project.org; > devel(a)lists.uyuni-project.org Cc: Julio Gonzalez <jgonzalez(a)suse.com> > Subject: [EXTERNAL EMAIL] Uyuni 2022.06 is released! > > VERY IMPORTANT: Uyuni 2022.06 switches the base OS for the Server and the > Proxy to openSUSE Leap 15.4. Make sure you read the release notes before > updating! > > We are happy to announce the immediate availability of Uyuni 2022.06. > > At https://www.uyuni-project.org/pages/stable-version.html you will find all > the resources you need to start working with Uyuni 2022.06, including the > release notes, documentation, requirements and setup instructions. > > This is the list of highlights for this release: > > - Upgrade notes (read them carefully!) > - Base system upgrade to openSUSE Leap 15.4 > - PostgreSQL 14 > - Salt 3004 > - New products enabled > > Remember that Uyuni will follow a rolling release planning, so the next > version will contain bugfixes for this one and any new features. There will > be no maintenance of 2022.06 > > As always, we hope you will enjoy Uyuni 2022.06 and we invite everyone of > you to send us your feedback [1] and of course your patches, if you can > contribute. > > Happy hacking! > > [1] https://www.uyuni-project.org/pages/contact.html > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Problem setting up an Uyuni Proxy
by Paul-Andre Panon 17 Jun '22

17 Jun '22

I'm trying to set up an Uyuni proxy (using the proxy pattern) . It's a bit of an unusual configuration: 1. Uyuni server is a different domain 2. Have network connectivity but not DNS resolution 3. Application level firewall in between to networks 4. Certificates are signed by a separate internal Intermediate [+root] CA The networks will eventually get more integrated, but to get around 1 & 2, the proxy is in the server's host file, and the server and internal CA are in the proxy's host file. This seems to work well enough to get the proxy system registered as a minion/client with the Uyuni server. However, once I've created the cert for the proxy, when trying to run configure-proxy.sh, we get Requesting certificate from server. [1/20] ... Requesting certificate from server. [20/20] Certificate not received from server. Exit. /etc/sysconfig/rhn/systemid:1: parser error : Document is empty ^ unable to parse /etc/sysconfig/rhn/systemid SUSE Manager Parent [Uyuni_server.FQDNl]: Using CA Chain (from /etc/sysconfig/rhn/up2date): /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT HTTP Proxy []: Traceback email []: <removed spammer bait> You will now need to either generate or import an SSL certificate. This SSL certificate will allow client systems to connect to this Uyuni Proxy securely. Refer to the Uyuni Proxy Installation Guide for more information. Do you want to import existing certificates? [y/N]: y Path to CA SSL certificate: []: /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT Path to the Proxy Server's SSL key: []: /root/ssl-build/<proxy>.key Path to the Proxy Server's SSL certificate: []: /root/ssl-build/<proxy>.crt Installing SSL certificates: XXX: User postgres does not exist XXX: Group postgres does not exist cp: '/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT' and '/etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT' are the same file WARNING: upon deactivation attempt: unknown error - <Fault -12: 'redstone.xmlrpc.XmlRpcFault: method invalid param'> There was a problem activating the SUSE Manager Proxy entitlement: WARNING: upon deactivation attempt: unknown error - <Fault -12: 'redstone.xmlrpc.XmlRpcFault: method invalid param'> Proxy activation failed! Installation interrupted. WARNING: upon deactivation attempt: unknown error - <Fault -12: 'redstone.xmlrpc.XmlRpcFault: method invalid param'> There were some answers you had to enter manually. Would you like to have written those into file formatted as answers file? [Y/n]: y Writing proxy-answers.txt.u4qp3 I'm hoping the first few errors aren't too much of an issue. I'm not sure what I would have missed, step wise, to lead to the SUSE Manager Proxy entitlement errors. I didn't find anything obvious through a google search for those errors. The CA certs have been installed on the proxy, so if I try to use wget to fetch a file from the pub folder on the Uyuni server, it has no apparent problems with cert verification. I appreciate any suggestions or pointers you can offer. Thanks, Paul-Andre Panon

2 3

Uyuni support for Ubuntu 22.04?
by Paul-Andre Panon 13 Jun '22

13 Jun '22

Hi, Any idea when we can expect Uyuni client packages for Ubuntu 22.04? Has there been sufficiently few changes to the apt interfaces that the Ubuntu 20.04 packages can still be used? Thanks, Paul-Andre

4 5

lldp information within uyuni
by Heiner Wulfhorst 28 May '22

28 May '22

Dear uyuni users, how do you query uyuni-managed systems for lldp information like connected switch/ports, etc? We are about to install a bunch of bare-metal server systems and would like to ensure all cabling is correct / as expected. Currently uyuni does not show any information about which network interface is connected to which switch interface. Is there any option to get it into uyuni GUI? Or can someone recommend any salt code for querying it? BR Heiner

2 1

Uyuni 2022.05 is released!
by Julio Gonzalez 10 May '22

10 May '22

IMPORTANT NOTE: The release is done, but it seems OpenBuildService is a bit overloaded now, so we recommend waiting at least a few hours before applying the update, to give more time for the mirrors to sync We are happy to announce the immediate availability of Uyuni 2022.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.05, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Always read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Reporting Database documentation * spacewalk-report now uses data from the reporting database * Adding systems with failed actions to System Set Manager * Technology Preview: JSON over HTTP API Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.05 As always, we hope you will enjoy Uyuni 2022.05 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Taskomatic errors since 2022.4
by Simon Avery 10 May '22

10 May '22

Hi I've been seeing email warnings since upgrading to Uyuni latest over the past couple of weeks. Taskomatic bunch update-payg-data-bunch was scheduled to run within the update-payg-default schedule. Subtask update-payg-hosts failed. For more information check null. And then ten minutes later, at the next run, a second email with Subtask update-payg-hosts finished successfully and is back to normal. These occur every day or two, always early in the morning (0130 or 0220), and there have been some other taskomatic emails referencing things other than payg-hosts. Prior to this version, I'd only ever see these emails for repo errors. rhn_taskomatic_daemon.log has a few entries like * 2022-04-03 16:20:00,562 [Thread-6531] ERROR com.redhat.rhn.taskomatic.task.payg.PaygUpdateHostsTask - p11-kit: couldn't create symlink: /var/lib/ca-certificates/openssl/dbc54cab.0: File exists * 2022-05-10 02:10:00,996 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.payg.PaygUpdateHostsTask - Message: Command '[/usr/share/rhn/certs/update-ca-cert-trust.sh]' exited with error code 1: p11-kit: couldn't complete writing of file: /var/lib/ca-certificates/ca-bundle.pem.tmp: File exists The first file exists when I check, the second does not. If I run /usr/share/rhn/certs/update-ca-cert-trust.sh manually, it completes without error. It's like the same task is being run twice concurrently but I don't know how to check; there's no duplicates in Uyuni -> Admin -> Task schedules. Obviously not a major issue as it's apparently self-healing, but I don't want to get into the habit of ignoring emails from Uyuni so would like to get to the bottom of it. Any ideas? Simon Avery Linux Systems Administrator: ATASS Sports Oxygen House | Grenadier Road, Exeter Business Park | EX1 3LH t: 01392 440 400 e: simon.avery(a)atass-sports.co.uk<mailto:simon.avery@atass-sports.co.uk> www.atass-sports.co.uk<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.atass-…> Follow us on Twitter: @atassSports<https://twitter.com/atassSports> NOTICE This email and any attachments confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Please notify the sender immediately. ATASS Ltd is incorporated in England and Wales with company number 04807405. See our website for further details and our privacy policy

3 3

Odd error
by McGranahan, Jamen (VU) 10 May '22

10 May '22

Good afternoon - On our Centos 7 servers, I am seeing the following errors when trying to update packages: saltutil_|-sync_states_|-sync_states_|-sync_states: name: sync_states changes: { } result: true comment: No updates to sync __sls__: util.syncstates __run_num__: 0.0 start_time: '14:49:31.179203' duration: 214.441 __id__: sync_states file_|-mgrchannels_susemanagerplugin_yum_|-/usr/share/yum-plugins/susemanagerplugin.py_|-managed: changes: { } comment: File /usr/share/yum-plugins/susemanagerplugin.py is in the correct state name: /usr/share/yum-plugins/susemanagerplugin.py result: true __sls__: channels __run_num__: 1.0 start_time: '14:49:31.405372' duration: 139.592 __id__: mgrchannels_susemanagerplugin_yum file_|-mgrchannels_susemanagerplugin_conf_yum_|-/etc/yum/pluginconf.d/susemanagerplugin.conf_|-managed: changes: { } comment: File /etc/yum/pluginconf.d/susemanagerplugin.conf is in the correct state name: /etc/yum/pluginconf.d/susemanagerplugin.conf result: true __sls__: channels __run_num__: 2.0 start_time: '14:49:31.545144' duration: 35.11 __id__: mgrchannels_susemanagerplugin_conf_yum file_|-mgrchannels_enable_yum_plugins_|-/etc/yum.conf_|-replace: result: true name: /etc/yum.conf changes: { } comment: onlyif condition is false skip_watch: true __sls__: channels __run_num__: 3.0 start_time: '14:49:31.580457' duration: 6319.884 __id__: mgrchannels_enable_yum_plugins file_|-mgrchannels_repo_|-/etc/yum.repos.d/susemanager:channels.repo_|-managed: changes: { } comment: File /etc/yum.repos.d/susemanager:channels.repo is in the correct state name: /etc/yum.repos.d/susemanager:channels.repo result: true __sls__: channels __run_num__: 4.0 start_time: '14:49:37.901468' duration: 72.448 __id__: mgrchannels_repo cmd_|-mgrchannels_yum_clean_all_|-/usr/bin/yum clean all_|-run: changes: { } result: true duration: 0.003 start_time: '14:49:37.974496' comment: State was not run because none of the onchanges reqs changed __state_ran__: false __run_num__: 5.0 __sls__: channels cmd_|-trust_res_gpg_key_|-rpm --import https://opensuse.library.vanderbilt.edu:443/pub/res-gpg-pubkey-0182b964.key…: result: true name: rpm --import https://opensuse.library.vanderbilt.edu:443/pub/res-gpg-pubkey-0182b964.key changes: { } comment: unless condition is true skip_watch: true __sls__: channels __run_num__: 6.0 start_time: '14:49:37.974555' duration: 464.903 __id__: trust_res_gpg_key ? cmd_|-trust_suse_manager_tools_rhel_gpg_key_|-rpm --import https://opensuse.library.vanderbilt.edu:443/pub/sle12-gpg-pubkey-39db7c82.k… : result: true name: rpm --import https://opensuse.library.vanderbilt.edu:443/pub/sle12-gpg-pubkey-39db7c82.k… changes: { } comment: unless condition is true skip_watch: true __sls__: channels __run_num__: 7.0 start_time: '14:49:38.439839' duration: 171.767 __id__: trust_suse_manager_tools_rhel_gpg_key pkg_|-pkg_installed_|-pkg_installed_|-installed: name: pkg_installed changes: venv-salt-minion: old: - version: '3002.2' release: 45.1.uyuni arch: x86_64 install_date_time_t: 1.650462456E9 epoch: null new: - version: '3002.2' release: 48.1.uyuni arch: x86_64 install_date_time_t: 1.651521007E9 epoch: null python2-rhnlib: old: - version: 4.3.3 release: 3.1.uyuni arch: noarch install_date_time_t: 1.650389632E9 epoch: null new: - version: 4.3.4 release: 2.1.uyuni arch: noarch install_date_time_t: 1.651521E9 epoch: null python2-uyuni-common-libs: old: - version: 4.3.3 release: 3.1.uyuni arch: x86_64 install_date_time_t: 1.650389632E9 epoch: null new: - version: 4.3.4 release: 2.1.uyuni arch: x86_64 install_date_time_t: 1.651521E9 epoch: null result: false comment: |- The following packages failed to install/update: grub2-common=1:2.02-0.87.el7.centos.7, grub2=1:2.02-0.87.el7.centos.7, grub2-pc-modules=1:2.02-0.87.el7.centos.7, grub2-tools-minimal=1:2.02-0.87.el7.centos.7, grub2-pc=1:2.02-0.87.el7.centos.7, grub2-tools=1:2.02-0.87.el7.centos.7, grub2-tools-extra=1:2.02-0.87.el7.centos.7 3 targeted packages were installed/updated. __sls__: packages.pkginstall __run_num__: 8.0 start_time: '14:49:38.612594' duration: 129411.979 __id__: pkg_installed Packages Scheduled: * venv-salt-minion-3002.2-48.1.uyuni.x86_64 * grub2-common-2.02-0.87.el7.centos.7:1.noarch * grub2-2.02-0.87.el7.centos.7:1.x86_64 * grub2-pc-modules-2.02-0.87.el7.centos.7:1.noarch * python2-rhnlib-4.3.4-2.1.uyuni.noarch * grub2-tools-minimal-2.02-0.87.el7.centos.7:1.x86_64 * grub2-pc-2.02-0.87.el7.centos.7:1.x86_64 * grub2-tools-2.02-0.87.el7.centos.7:1.x86_64 * python2-uyuni-common-libs-4.3.4-2.1.uyuni.x86_64 * grub2-tools-extra-2.02-0.87.el7.centos.7:1.x86_64 [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image002.png@01D85EF2.E3A00000]

2 1

venv-salt-minion failing to install as part of bootstrap script
by Paul-Andre Panon 09 May '22

09 May '22

Hi, We're trying to bootstrap an ubuntu 20.04 server with the same bootstrap script that we've used on many other servers. However on this server the package install is failing in the post-install script. ... FINISHED --2022-05-06 19:08:52-- Total wall clock time: 0.007s Downloaded: 1 files, 1.1K in 0s (223 MB/s) Reading package lists... Done Building dependency tree Reading state information... Done gnupg is already the newest version (2.2.19-3ubuntu2.1). 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up venv-salt-minion (3002.2-47.3.uyuni) ... dpkg: error processing package venv-salt-minion (--configure): installed venv-salt-minion package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: venv-salt-minion E: Sub-process /usr/bin/dpkg returned an error code (1) OK ... Looks like it's trying to do something with dpkg so perhaps there's a missing or conflicting dependency. With Uyuni's cross-platform build, I haven't been able to figure out what that post-install script is to figure out what it might be trying to do. Any suggestions? Thanks, Paul-Andre

2 6

Salt ID continues to return
by McGranahan, Jamen (VU) 06 May '22

06 May '22

I've got an oddity that I am having trouble figuring out. One of our servers is not listed on the Uyuni web admin site, but there's a Salt ID for it. I've deleted it multiple times, but it keeps reappearing, even after rejecting it and deleting it. What I am trying to do is to remove any instance of this server from Uyuni and then re-add it - hoping that a clean install will take care of this issue. Ideas? [cid:image001.png@01D8606A.22AD1D00] [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image003.png@01D8606A.22AD1D00]

4 6

grub2
by McGranahan, Jamen (VU) 05 May '22

05 May '22

Most of our CentOS 7 servers are reporting that grub2 package needs to be upgraded, but they all fail to upgrade, giving this error message: comment: |- The following packages failed to install/update: grub2-common=1:2.02-0.87.el7.centos.7, grub2=1:2.02-0.87.el7.centos.7, grub2-pc-modules=1:2.02-0.87.el7.centos.7, grub2-tools-minimal=1:2.02-0.87.el7.centos.7, grub2-pc=1:2.02-0.87.el7.centos.7, grub2-tools=1:2.02-0.87.el7.centos.7, grub2-tools-extra=1:2.02-0.87.el7.centos.7 (code 2) When I manually run yum update on these servers, I get "No packages marked for update". So why is Uyuni reporting that grub2 needs to be updated? [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image002.png@01D86073.1C59C3A0]

2 4

SLES15_SAP SP3: Missing GPG Key for PackageHub-15-SP3-Backports // how to install nmon RPM
by Heiner Wulfhorst 03 May '22

03 May '22

Hi List, we would like to install nmon on our SLES15 SP3 SAP Systems, it can be obtained from SUSE-PackageHub-15-SP3-Backports-Pool repository. Problem: Uyuni Bootstrapping fails if we include it into autoyast.xml ("key ID 65176565: NOKEY"), because zypper tries to install python3-pycares-3.1.1-bp153.1.17.x86_64.rpm as a recommended package for salt: Retrieving: python3-pycares-3.1.1-bp153.1.17.x86_64.rpm [done] python3-pycares-3.1.1-bp153.1.17.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 9c214d4065176565: NOKEY V3 RSA/SHA256 Signature, key ID 9c214d4065176565: NOKEY warning: /var/tmp/AP_0xAKTyvC/getPackage/NULL/42ce2ba338b2c092f38882d20e7c38f316a90a89d76d6f74235eb8f039da609d/python3-pycares-3.1.1-bp153.1.17.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 65176565: NOKEY Looking for gpg key ID 65176565 in cache /var/cache/zypp/pubkeys. Repository sles15sp3-sap-sandbox PackageHub-15-SP3-Backports-Pool does not define additional 'gpgkey=' URLs. python3-pycares-3.1.1-bp153.1.17.x86_64 (sles15sp3-sap-sandbox PackageHub-15-SP3-Backports-Pool): Signature verification failed [4-Signatures public key is not available] Abort, retry, ignore? [a/r/i] (a): a Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. no package provides salt ERROR: Failed to install all missing packages. Key Details: gpg-pubkey-65176565-5d94a381 gpg(openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org>): http://download.opensuse.org/distribution/leap/15.3/repo/oss/gpg-pubkey-651… - Why is that key missing? A Temporary bug? Or must i manually/explicitly add it in uyuni? - I do not like the idea of using backports within installation and keeping them enabled. Can someone recommend a better solution? How about autoyast w/o backport repos, adding them (disabled) using salt, then installing nmon using 'zypper --plus-content <reponame> install nmon'? Thanks, BR, Heiner

2 1

Uyuni 2022.04 is released!
by Julio Gonzalez 29 Apr '22

29 Apr '22

IMPORTANT NOTE: The release is done, but it seems OpenBuildService is a bit overloaded now, so we recommend waiting at least a few hours before applying the update, to give more time for the mirrors to sync We are happy to announce the immediate availability of Uyuni 2022.04 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.04, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Always read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Salt SSH now uses the Salt Bundle * Technology Preview: Containerized Uyuni Proxy and Retail Branch Server * Reporting Database improvements * Improved image management * HSTS Enabled Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.04 As always, we hope you will enjoy Uyuni 2022.04 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

how to get servers to update
by McGranahan, Jamen (VU) 27 Apr '22

27 Apr '22

Alright, I am closer to getting Uyuni set up the way we want it. Now, how can we get our servers that are registered to update through Uyuni? I was only given a option to schedule the update, so I picked as soon as possible, but they are all waiting and I do not know why: [cid:image001.png@01D85422.7C84AA40] Jamen McGranahan Associate Director of Library Technology & Digital Services Jean and Alexander Heard Libraries, Vanderbilt University 615-343-1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> he/his/him [cid:image002.png@01D85422.7C84AA40]

3 4

Uyuni 2022.03 new setups or updates, broken after April 20th 07:03UTC
by Julio Gonzalez 27 Apr '22

27 Apr '22

Hello, For those of you that installed Uyuni 2022.03 or updated from a previous version after pril 20th 07:03UTC, you will notice that the WebUI does not start and you see a HTTP error 404. Anyway that installed or updated before that date and time should not be affected by this This problem was caused by a netty update at openSUSE Leap 15.3. The bug report for Uyuni is available at: https://github.com/uyuni-project/uyuni/issues/5278 The explanation of why this happened is available at: https://github.com/uyuni-project/uyuni/issues/5278#issuecomment-1110868000 The remediation: - For Uyuni 2022.04 (release pending), this is alredy fixed by PR we merged this morning - For Uyuni 2022.03 you can apply a workaround: https://github.com/uyuni-project/uyuni/issues/5278#issuecomment-1110861789 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Uyuni erroneously reports packages need to be updated?
by McGranahan, Jamen (VU) 25 Apr '22

25 Apr '22

Sorry all, but here's another problem I have run into. My Uyuni interface is reporting 8 packages that need to be updated on this server, yet when I try to run the update, I get the error that there are no packages found. So on the server itself, when I run "yum update", I get "No packages marked for update". So why is Uyuni reporting there are packages that need to be updated? [cid:image001.png@01D85647.3AA6DB30] [cid:image002.png@01D85647.3AA6DB30] [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image004.png@01D85647.3AA6DB30]

2 1

Create vms with VmWare - possible?
by Simon Avery 25 Apr '22

25 Apr '22

Hi Quick question: Can Uyuni provision new VMs using VmWare, or is that functionality restricted to Xen and Kvm? Background: We have a VCenter cluster running our vms. By following the documentation here<https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/virt…>, I've successfully added Vsphere as a VHM and it's populating correctly. (Thanks for the bugfix in the new Uyuni version that now does correctly display the Virtualization tab that allowed me to get further than last time I tried this) But the "Create Guest" link as mentioned in the docs is absent. Elsewhere in the official docs it does say For VMWare, including VMWare vSphere, and Nutanix AHV, Uyuni requires you to set up a virtual host manager (VHM) to control the VMs. This gives you control over the hosts and guests, but in a more limited way than available with Xen and KVM. But I've also found this on some unofficial documentation here<https://infallible-goldberg-3dc8f3.netlify.app/uyuni/master/advanced_topics…> that seems to give more specific guidance Autoinstalling and managing {vmguest}s via Uyuni is limited to {xen} and {kvm} guests. Thanks, Simon

2 2

Public key not installed?
by McGranahan, Jamen (VU) 22 Apr '22

22 Apr '22

OK, I am getting so close to having a fully operational centralized package management system. Just need to figure out this one last issue (I hope). After removing some of the old spacewalk packages, and then re-attach the servers to Uyuni, I am now seeing this message when trying to update the packages - both within Uyuni and on the server itself when I run yum update: Public key for python2-hwdata-2.3.5-5.1.uyuni.noarch.rpm is not installed What am I missing? [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image002.png@01D85642.2B3CBA20]

3 3

sync autoinstall snipped folder with git repo
by Heiner Wulfhorst 22 Apr '22

22 Apr '22

Hi List, we are storing autoinstall snipped files (/var/lib/cobbler/snippets/spacewalk/1/) in a Azure DevOps (git) repo. In ADO we trigger a pipeline on every push to master. This pipeline can copy files from repo to our uyuni server using ssh, execute a script on uyuni server, and various other tasks. I did not find any information regarding git versioning of uyuni files/folders online, so i am curious: How do you do jobs like this? Local Repos on uyuni server? Is there already any plan to implement git support in uyuni for cases like this? Or would a feature request be helpful? Thanks, BR Heiner

1 0

unable to register
by McGranahan, Jamen (VU) 21 Apr '22

21 Apr '22

Thanks all for the help earlier. Now I am just trying to get our servers registered to our local Uyuni system. I followed the bootstrap method, creating an shell script, but when I launch it, I get the following: CHECKING THE REGISTRATION STACK ------------------------------------------------- * check for necessary packages being installed... * client codebase is centos-7 CentOS7 bootstrap repository not found, using RES7 bootstrap repository instead https://opensuse.library.vanderbilt.edu/pub/repositories/res/7/bootstrap/re…: 2022-04-18 15:00:08 ERROR 404: 404. Bootstrap repo 'https://opensuse.library.vanderbilt.edu/pub/repositories/res/7/bootstrap' does not exist. package spacewalk-check is not installed package spacewalk-client-setup is not installed package spacewalk-client-tools is not installed yum-rhn-plugin-2.0.1-10.el7.noarch * going to install missing packages... Loaded plugins: fastestmirror, product-id, search-disabled-repos, : subscription-manager, tmprepo This system is not registered with an entitlement server. You can use subscription-manager to register. Loading mirror speeds from cached hostfile * base: centos.mirrors.hoobly.com * centos-sclo-rh: ftp.usf.edu<ftp://ftp.usf.edu> * epel: mirror.steadfastnet.com * extras: mirror.mia11.us.leaseweb.net * updates: nc-centos-mirror.iwebfusion.net No package spacewalk-check available. No package spacewalk-client-setup available. No package spacewalk-client-tools available. Error: Nothing to do package spacewalk-check is not installed ERROR: Failed to install all missing packages. Jamen McGranahan Associate Director of Library Technology & Digital Services Jean and Alexander Heard Libraries, Vanderbilt University 615-343-1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> he/his/him [cid:image001.png@01D8534D.9DDAA990]

3 3

Uyuni proxy does not cache *.deb packages ?
by Bidault, Philippe 20 Apr '22

20 Apr '22

Hi all ¡ Has somebody already noticed that the Uyuni Squid just does not seems to cache the *.deb packages ? A simple test downloading several times in a raw from an Ubuntu registered server a 91KB package size ends up with a TCP_MISS: 10.264 242 127.0.0.1 TCP_MISS/200 91356 GET http://proxy_uyuni /rhn/manager/download/ubuntu-1804-amd64-main-security-uyuni/getPackage/gzip_1.6-5ubuntu1.2.amd64-deb.deb<http://proxy_uyuni.cms.colt/rhn/manager/download/ubuntu-1804-amd64-main-sec…> - HIER_DIRECT/10.206.29.108 application/octet-stream 1650464072.536 310 127.0.0.1 TCP_MISS/200 91356 GET http://proxy_uyuni /rhn/manager/download/ubuntu-1804-amd64-main-security-uyuni/getPackage/gzip_1.6-5ubuntu1.2.amd64-deb.deb<http://proxy_uyuni.cms.colt/rhn/manager/download/ubuntu-1804-amd64-main-sec…> - HIER_DIRECT/10.206.29.108 application/octet-stream 1650464272.667 171 127.0.0.1 TCP_MISS/200 91356 GET http://proxy_uyuni /rhn/manager/download/ubuntu-1804-amd64-main-security-uyuni/getPackage/gzip_1.6-5ubuntu1.2.amd64-deb.deb<http://proxy_uyuni.cms.colt/rhn/manager/download/ubuntu-1804-amd64-main-sec…> - HIER_DIRECT/10.206.29.108 application/octet-stream Should not be the case from the Squid's configuration: cache_mem 400 MB maximum_object_size 200 MB maximum_object_size_in_memory 1024 KB ... # rpm will hardly ever change, force to cache it for very long time refresh_pattern \.rpm$ 10080 100% 525960 override-expire override-lastmod ignore-reload reload-into-ims refresh_pattern \.deb$ 10080 100% 525960 override-expire override-lastmod ignore-reload reload-into-ims refresh_pattern . 0 100% 525960 The RPM are correctly cached it seems: access.log:1650178125.754 0 127.0.0.1 TCP_MEM_HIT/200 154067 GET http://proxy_uyuni/rhn/manager/download/rockylinux8-x86_64/getPackage/1/a69… - HIER_NONE/- application/octet-stream Am I missing something here ? Thanks ! Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<http://www.getronics.com> Follow us on: [cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]<https://www.linkedin.com/company/getronics/> [cid:SocialLink_Twitter_32x32_cb75fe15-abe1-46a3-9ac3-fc99d077e43b.png] <https://twitter.com/getronics> [cid:SocialLink_Youtube_32x32_1946f212-29cc-40bc-9061-3536027a9813.png] <https://www.youtube.com/channel/UCfEFIFxLdxxhMN-Eaa6pXVA> <https://twitter.com/getronics> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policy<https://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/>

1 0

SUSE Manager
by Jamen McGranahan 19 Apr '22

19 Apr '22

Apologies for the newbie question here, but I've installed Uyuni on a Open SUSE Leap virtual server in the hopes of using it for a centralized package management system for all of our CentOS servers. However, we do not have a SUSE Manager account. Is there no other way to get software channels registered in Uyuni other than having a subscription to SUSE Manager?

5 5

minor issues trying to use rhnpush
by Paul-Andre Panon 14 Apr '22

14 Apr '22

We ran into some minor issues trying to load packages into a custom child channel. First, rhnpush wouldn't recognize deb packages. This minor change allowed rhnpush to recognize .deb files diff -u /usr/lib/python3.6/site-packages/rhnpush/uploadLib.py.bak /usr/lib/python3.6/site-packages/rhnpush/uploadLib.py --- /usr/lib/python3.6/site-packages/rhnpush/uploadLib.py.bak 2022-04-13 11:02:58.598147587 -0700 +++ /usr/lib/python3.6/site-packages/rhnpush/uploadLib.py 2022-04-13 10:07:14.590320048 -0700 @@ -177,7 +177,7 @@ for filename in listdir(self.options.dir): # only add packages - if filename[-3:] in ("rpm", "mpm"): + if filename[-3:] in ("rpm", "mpm", "deb"): self.files.append(filename) def filter_excludes(self): Next, we ran into some permission issues on the back end. Exception Handler Information Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/server/apacheUploadServer.py", line 102, in _wrapper ret = function(req) File "/usr/share/rhn/upload_server/handlers/package_push/package_push.py", line 117, in handler self.file_checksum_type, self.file_checksum) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnPackageUpload.py", line 281, in save_uploaded_package prefix='-'.join((nevra[0], nevra[2], nevra[3], nevra[4]))) File "/usr/lib64/python3.6/tempfile.py", line 551, in NamedTemporaryFile (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type) File "/usr/lib64/python3.6/tempfile.py", line 262, in _mkstemp_inner fd = _os.open(file, flags, 0o600) PermissionError: [Errno 13] Permission denied: '/var/spacewalk/packages/1/stage/Newpackaget-8.3.0-X-amd64-debmdg_d6ri' Turns out permissions on /var/spacewalk/packages/1/stage were root.root. Chown wwwrun.www /var/spacewalk/packages/1/stage to match the other dirs in /var/spacewalk/packages/1 allowed the rhnpush to succeed. Cheers, Paul-Andre Panon

2 2

AW: Salt-Minion doesn't work after migration of system
by Crefeld, Tobias LKV Bayern e.V. 14 Apr '22

14 Apr '22

Hi, the error message is a little misleading as we don't run multiple masters. Actually the moved systems didn't have access to 4505/tcp and 4506/tcp of the Uyuni system due to the firewall setup. After adding the respective rules to the firewall, the error messages disappeared and system management works as usual. Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Crefeld, Tobias LKV Bayern e.V. Gesendet: Montag, 11. April 2022 10:45 we had to move several SLES15 systems to another network behind a firewall. Therefore we changed the respective files ifcfg-eth0, route and hosts and reloaded wicked. Access to repositories works fine but the service salt-minion shows: "Error while bringing up minion for multi-master. Is master at lkv-srvapp39.lkvbay.net responding?" (lkv-srvapp39 is the only Uyuni system)

1 0

Installed products - can this be changed?
by Tim Shaw 12 Apr '22

12 Apr '22

After running a product migration dry run on a SLES systsem in Uyuni 2022.02 I discovered that the "Installed Products" for that server bow displays the version which would have been installed had the migration actually been performed. I assume something went wrong in the restoration of the object to the state which it was in before the product migration dry run was performed Is there a way to correct the value of "Installed products" for a system using some command line tool? Or should I blow this system away and re register it? Thanks T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

3 2

Re: Problem deleting systems from Uyuni 2022.03 (and probably 2022.02 as well before upgrading)
by Paul-Andre Panon 12 Apr '22

12 Apr '22

P.S. We’re seeing similar errors in the taskomatic log 2022-04-08 12:44:00,035 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - re-throwing exception since we havent yet. 2022-04-08 12:44:00,035 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Executing a task threw an exception: com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException 2022-04-08 12:44:00,035 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Message: We had an error trying to login. 2022-04-08 12:44:00,035 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Cause: redstone.xmlrpc.XmlRpcFault: <class 'cobbler.cexceptions.CX'>:'login failed (taskomatic_user)' 2022-04-08 12:44:00,035 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Stack trace:com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We had an error trying to login. at com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:56) at com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:113) at com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:66) at com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.<init>(CobblerCommand.java:60) at com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.<init>(CobblerCommand.java:81) at com.redhat.rhn.manager.kickstart.cobbler.CobblerDistroSyncCommand.<init>(CobblerDistroSyncCommand.java:47) at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:85) at com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:89) at com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:158) at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) Caused by: redstone.xmlrpc.XmlRpcFault: <class 'cobbler.cexceptions.CX'>:'login failed (taskomatic_user)' at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:444) at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376) at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165) at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69) at com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:51) ... 10 more Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

3 5

Salt-Minion doesn't work after migration of system
by Crefeld, Tobias LKV Bayern e.V. 11 Apr '22

11 Apr '22

Hi, we had to move several SLES15 systems to another network behind a firewall. Therefore we changed the respective files ifcfg-eth0, route and hosts and reloaded wicked. Access to repositories works fine but the service salt-minion shows: Error while bringing up minion for multi-master. Is master at lkv-srvapp39.lkvbay.net responding? (lkv-srvapp39 is the only Uyuni system) Any idea? Uyuni is release 2021.06. We used the workaround that Julio Gonzalez described at 01.04.22 and applied the patches of the salt packages only at the Uyuni system. Gruß, Tobias Crefeld.

1 0

Problem deleting systems from Uyuni 2022.03 (and probably 2022.02 as well before upgrading)
by Paul-Andre Panon 08 Apr '22

08 Apr '22

Hi, I looked in the last few months of the archive but couldn't see anything regarding this. My apologies if I missed it somehow. We're having strange behaviour in the GUI where trying to delete systems is failing. We've had this problem with different admin accounts: organization admins, Uyuni admins, admin accounts that are AD-integrated through PAM, the initial local admin account. We've enabled Duo multi-factor authentication but also had this problem before adding MFA. In all cases Uyuni fails to delete the system. After Confirming System Profile deletion, we first get a popup indicating Cleanup timed out. Please check if the machine is reachable. in the case of one system that had already been taken offline, but after indicating the profile should be deleted without cleanup (or without that first popup if we try to delete a system that is online) we get a follow-up error: Server error, please check log files.. Other operations work fine against systems: updating packages, rebooting systems, etc. We just can't delete systems. If we switch to the Admin menu to go look at the tomcat log, we see a notice: System profile 1000010001 could not be deleted. In the "tomcat" /var/log/rhn/rhn_web_ui.log log file, we see the errors: 2022-04-08 12:30:48,726 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-14] WARN com.suse.manager.webui.services.impl.SaltService - Got no result for state.apply on minion CARMD-EX-DWsbx4.sierrawireless.local (minion did not respond in time) 2022-04-08 12:30:50,542 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-9] ERROR com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand - XmlRpcFault while logging in. most likely user doesn't have permissions. redstone.xmlrpc.XmlRpcFault: <class 'cobbler.cexceptions.CX'>:'login failed (<myaccount>)' at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:444) at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376) at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165) at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69) at com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:51) at com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:113) at com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:66) at com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.<init>(CobblerCommand.java:66) at com.redhat.rhn.manager.kickstart.cobbler.CobblerSystemRemoveCommand.<init>(CobblerSystemRemoveCommand.java:37) at com.redhat.rhn.manager.system.SystemManager.deleteServer(SystemManager.java:725) at com.redhat.rhn.manager.system.SystemManager.deleteServer(SystemManager.java:704) at com.suse.manager.webui.controllers.SystemsController.delete(SystemsController.java:218) at com.suse.manager.webui.utils.SparkApplicationHelper.lambda$withUser$1(SparkApplicationHelper.java:88) at spark.RouteImpl$1.handle(RouteImpl.java:72) at spark.http.matching.Routes.execute(Routes.java:61) at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:130) at spark.servlet.SparkFilter.doFilter(SparkFilter.java:173) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:142) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:69) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:55) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:432) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1591) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:829) 2022-04-08 12:30:50,543 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-9] ERROR com.redhat.rhn.frontend.servlets.SessionFilter - Error during transaction. Rolling back com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We had an error trying to login. at com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:56) at com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:113) at com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:66) at com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.<init>(CobblerCommand.java:66) at com.redhat.rhn.manager.kickstart.cobbler.CobblerSystemRemoveCommand.<init>(CobblerSystemRemoveCommand.java:37) at com.redhat.rhn.manager.system.SystemManager.deleteServer(SystemManager.java:725) at com.redhat.rhn.manager.system.SystemManager.deleteServer(SystemManager.java:704) at com.suse.manager.webui.controllers.SystemsController.delete(SystemsController.java:218) at com.suse.manager.webui.utils.SparkApplicationHelper.lambda$withUser$1(SparkApplicationHelper.java:88) at spark.RouteImpl$1.handle(RouteImpl.java:72) at spark.http.matching.Routes.execute(Routes.java:61) at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:130) at spark.servlet.SparkFilter.doFilter(SparkFilter.java:173) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:142) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:69) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:55) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:432) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1591) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: redstone.xmlrpc.XmlRpcFault: <class 'cobbler.cexceptions.CX'>:'login failed (<myaccount>)' at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:444) at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376) at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165) at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69) at com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:51) ... 50 more It's not clear to me why trying to remove a system would be causing cobbler exceptions. Any ideas or suggestions? Thanks Paul-Andre Panon

1 0

Uyuni 2022.03 is released!
by Julio Gonzalez 04 Apr '22

04 Apr '22

We are happy to announce the immediate availability of Uyuni 2022.03 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.03, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Fixes for Salt security issues - New XML-RPC API version 26 - smdba: changed defaults for newer PostgreSQL versions - Monitoring: Grafana 8.3.5 - Salt SSH now uses the Salt Bundle - Some products are now becoming unsupported Please check the release notes for full details. For the Salt Security issues, you must update the Salt master on the Uyuni Server before updating any client. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.03 As always, we hope you will enjoy Uyuni 2022.03 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 1

IMPORTANT: Broken salt communications between minions and master on 2022.02, after the last fixes for Salt CVEs
by Julio Gonzalez 01 Apr '22

01 Apr '22

Hello, If you suddenly see at your minions: 2022-03-28 13:19:41,880 [salt.crypt :743 ][ERROR ][15942] Sign-in attempt failed: {'publish_port': 4505, 'pub_key': '-----BEGIN PUBLIC KEY----- \n...\n-----END PUBLIC KEY-----\n''enc': 'pub','sig': ".."} 2022-03-28 13:19:41,885 [salt.minion :1056][ERROR ][15942] Error while bringing up minion for multi-master. Is master at salt-master-server.tf.local responding? That's a consecuence of the fixes for the last Salt CVEs. The official solution is updating to Uyuni 2022.03 If you want to stay on 2022.02, this is an unofficial, untested and unsupported solution: - Apply the updates for the Salt Master on the server - Resync all client tools - Update the salt minon at all salt clients Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

RE: Set up Uyuni with YaST ERROR
by Paul-Andre Panon 28 Mar '22

28 Mar '22

Hi Julio, I am getting the same error. This is with a new install of Uyuni 2022.02. It looks like the certificate is getting created in /root/ssl-build but the rpm package is not. I manually copied the certificate and key to the locations in /etc/pki/tls/ indicated by the apache2 config to be able to start the web service, but we need to build the cert rpm package for deployment to clients. We're actually going to go through the procedure to build a custom CA-signed cert so we will see whether that goes OK or if it breaks as well, but the default process for using a self-signed cert seems to be broken after the creation of the cert. The self signed cert also appears to have the OU and O order mixed up, although I expect that shouldn't be enough to break the cert configuration. Cheers, Paul-Andre Panon

1 1

Uyuni 2022.02 is released!
by Julio Gonzalez 18 Mar '22

18 Mar '22

We are happy to announce the immediate availability of Uyuni 2021.02 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.02, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Reporting Database * Ubuntu errata installation * Monitoring: Prometheus 2.32.1 * Monitoring: Postgres exporter updated to version 0.10.0 for SUSE Linux Enterprise and openSUSE * SLES PAYG client support on cloud * openscap for Debian 11 (Tech Preview) Please check the release notes for full details, and in particular review the section about the Postgres exporter update and the Prometheus update, as it could require manual if you are using monitoring. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.02 As always, we hope you will enjoy Uyuni 2022.02 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

5 7

Using Prometheus and Grafana on Centos
by Simon Avery 15 Mar '22

15 Mar '22

Has anyone managed to get the Grafana dashboards working on Centos or Rocky? I have tried several times over various versions and just given another hour to the task without any joy. Following the guide and applying the Salt formula always fails on the targets I've tried, with: ID: install_prometheus Function: pkg.installed Name: golang-github-prometheus-prometheus Result: false Comment: Error occurred installing package(s). Additional info follows: errors: - Running scope as unit: run-r4cd5eeb15cd8494685380c6107f1045b.scope Last metadata expiration check: 0:00:03 ago on Thu Mar 10 14:37:34 2022. No match for argument: golang-github-prometheus-prometheus Error: Unable to find a match: golang-github-prometheus-prometheus Started: 14:37:18.669658 Duration: 20980.625 SLS: prometheus Changed: {} And indeed - the package is not called that on EL. It is supplied in the Epel repos (although on Centos 7 that appears to be broken - it does install fine manually on Rocky 8) - but the package is called golang-github-prometheus - so always fails. Anyone know how to work around this? I don't have any Suse machines other than the one Uyuni runs on. Manually, I always seem to get into configuration problems with Prometheus. It's not software I'm familiar with and it does seem very fussy about syntax (something I've seen discussed at https://github.com/uyuni-project/uyuni/issues/2082 ) I have an existing Grafana server that I'd like to be able to use this with. Simon Avery Linux Systems Administrator: ATASS Sports Oxygen House | Grenadier Road, Exeter Business Park | EX1 3LH t: 01392 440 400 e: simon.avery(a)atass-sports.co.uk<mailto:simon.avery@atass-sports.co.uk> www.atass-sports.co.uk<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.atass-…> Follow us on Twitter: @atassSports<https://twitter.com/atassSports> NOTICE This email and any attachments confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Please notify the sender immediately. ATASS Ltd is incorporated in England and Wales with company number 04807405. See our website for further details and our privacy policy

2 4

Ubuntu repos not working after upgrade to 2022.02
by Bidault, Philippe 15 Mar '22

15 Mar '22

Hi all ! After upgrading from 2021.12 to 2022.02, the registered Ubuntu 18.04/20.04 are not able to get the repos anymore. Result of an 'apt update': E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-uyuni/… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-18.04-pool-amd64-uyuni… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-uyuni-clien… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-universe-uy… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-multiverse-… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-update… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-securi… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-universe-up… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-multiverse-… 404 Not Found [IP: 10.0.0.1 443] E: Some index files failed to download. They have been ignored, or old ones used instead. I have tried to remove the apt cache on the registered servers, but no luck. I have tried to force the repo sync to regenerate the repos metadata on the Uyuni server , but it did not help neither. Somebody with this same issue ? Do I just need to be patient to let internal Uyuni mechanism to regenerate caches or whatever ? Thanks ! Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<http://www.getronics.com> Follow us on: [cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]<https://www.linkedin.com/company/getronics/> [cid:SocialLink_Twitter_32x32_cb75fe15-abe1-46a3-9ac3-fc99d077e43b.png] <https://twitter.com/getronics> [cid:SocialLink_Youtube_32x32_1946f212-29cc-40bc-9061-3536027a9813.png] <https://www.youtube.com/channel/UCfEFIFxLdxxhMN-Eaa6pXVA> <https://twitter.com/getronics> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policy<https://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/>

2 4

Containerized Uyuni
by Strahil Nikolov 14 Mar '22

14 Mar '22

Hi Julio, Are there any plans for moving Uyuni into the container world ? Best Regards,Strahil Nikolov

2 1

Set up Uyuni with YaST ERROR
by M C 11 Mar '22

11 Mar '22

Can someone help I am getting the following Error output. Setup script output lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xPerforming forced re-installation! x xShutting down spacewalk services... x xDone. x xDelete existing database... x xDelete existing salt minion keys x xCREATE ROLE w x* Loading answer file: /root/spacewalk-answers. x x** Database: Setting up database connection for PostgreSQL backend. x x** Database: Populating database. x x** Database: --clear-db option used. Clearing database. x x** Database: Shutting down spacewalk services that may be using DB. x x** Database: Services stopped. Clearing DB. x x*** Progress: # x x* Configuring tomcat. x x* Setting up users and groups. x x* Performing initial configuration. x x* Configuring apache SSL virtual host. x x* Configuring jabberd. x x* Creating SSL certificates. x x** SSL: Generating CA certificate. x x** SSL: Generating server certificate. x xCould not deploy the certificates. Exit value: 1. x xPlease examine /var/log/rhn/rhn_installation.log for more information. v mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj Error output xWarning: ALREADY_ENABLED: suse-manager-server x xERROR: spacewalk-setup failed x x

2 1

How to configure Uyuni to bootstrap systems to use public available repo URL
by jd＠eurisco.dk 06 Mar '22

06 Mar '22

I would like to configure an Uyuni installation to bootstrap systems to use a public available repo URL instead of a local one. I believe this is achieved by changing the "Uyuni server hostname" under "Uyuni Configuration - Bootstrap", but when bootstrapping a system, the repo URL is using the "Uyuni Hostname" (e.g. uyuni.my-local-domain) and not the Uyuni server hostname (e.g. update.my-public-domain). I have checked all the Uyuni documentation, and googled this topic, but I have only found hints that it should be possible, but not an explanation how to actually achieve this, so I wonder if my understanding is wrong, or if something is missing in our installation. Running Uyuni 2022.01 on openSUSE Leap 15.3 I would highly appreciate if someone could help with getting this up and running. Thanks, Jacob Dall

1 0

Re: Containerized Uyuni
by Strahil Nikolov 04 Mar '22

04 Mar '22

Sending it to the list, as it somehow ended in the Bcc. It will be useful if we have Uyuni (and later SUMA) on a Kubernetes/Openshift cluster. Best Regards,Strahil Nikolov On Thu, Mar 3, 2022 at 16:03, Julio Gonzalez<jgonzalez(a)suse.com> wrote: On jueves, 3 de marzo de 2022 14:48:28 (CET) Strahil Nikolov wrote: > Hi Julio, > Are there any plans for moving Uyuni into the container world ? > Best Regards,Strahil Nikolov Hi! Please send the question to the users list. It seems you did it, but the list was not present at the TO field :-) -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Filters and module streams
by Karjanlahti Janne 09 Feb '22

09 Feb '22

Hello! Thank you for the CLM build java stack overflow fix, that was very fast response. I can confirm that CLM build succeed every time after installing the patch. I had another minor problem regarding to Content Lifecyle filters. I have created several module stream filters to our test environment, but somehow I cannot add more filters to existing project. GUI allows me to pick additional filters (via Add/Detach filters) and there is no error message when I click save button. However nothing happens, it doesn't get saved, there was only 9 filters total in use. I was forced to detach every single filter from project, then do CLM build without any module filtered and after that I was able to add every 12 filters at once. Only then all the filters came into use. What indeed is correct way to deal with modules? My intended purpose is that nothing changes from servers perspective when it gets bootstrapped to Uyuni. I want to use all the default packages that vanilla CentOS/Rocky/Alma is using after initial installation. I understand that Uyuni does not directly support RedHat-specific module-enabled repositories and whole (stupid) module stream concept, but you can deal with modules using module filters and building Content Lifecyle environment where module enabled repositories get "flattened" to ordinary repos, and you can alter the flattening process using module filters. After initial Rocky/Alma/CentOS installation there is several module streams enabled, you can view it using "dnf module list" command. Then you bootstrap server to Uyuni and all the original repost get replaced in favor of custom channels from Uyuni's lifecycle environment. But... still "dnf module list" show that there is enabled module streams. How should I deal with it? Should I inactivate all the streams using "dnf module reset" command? And what after that? Create module filter for all the different modules, or should I create filter only for those I want to use? What happens if I don't create any module filter at all? I know that SUSE is not using whole module streams etc... so this is not directly related to Uyuni, but I hope anyway that some of you can guide me to right direction. Br, Janne Janne Karjanlahti (Mr.) Vastaava järjestelmäasiantuntija | Senior Systems Specialist ICT- ja digitaaliset palvelut | ICT and Digital Services Satakunnan ammattikorkeakoulu | Satakunta University of Applied Sciences Satakunnankatu 23 | 28130 | PORI | Finland +358 44 710 3339 janne.karjanlahti(a)samk.fi<mailto:janne.karjanlahti@samk.fi> www.samk.fi<http://www.samk.fi>

1 0

Occasional 'minion is down' warning
by Tim Shaw 08 Feb '22

08 Feb '22

Occasionally I get a failure to apply updates or a failed to reboot and the reason given in the event summary is : Minion is down or could not be contacted. Retrying the command immediately afterwards almost invariably results in success - which leads me to believe that the minion is not down and this is a time-out issue and that the minion maybe takes a while to "wake up " if it has been inactive for a time It's annoying. Do others have this issue - and is there a setting which will allow the Uyuni server to grant more time to the minion to respond? Many thanks T ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

1 0

Content Lifecycle Project build failed / resulting messed up repository
by Karjanlahti Janne 08 Feb '22

08 Feb '22

Hello! Yesterday Content Lifecycle Project build failed without any additional information. It was our test environment and it was never happened before. I (re)synced all source repos by hand (just in case) and after that build succeeded and all seemed to be ok. I was a bit hurry and I didn't find any errors in log files at first glance so I leave it... This morning I encountered same "failed" notice in our production Uyuni server. This time I clicked "Build" again without additional repo resync and the second build succeeded. However repository content seems to be somewhat messed up, in both Uyuni servers. Client servers found a lot of updates, mainly different Perl packages but couldn't update because of many conflicting dependencies. There is a lot of Perl 5.30 -version updates available even if I have not enabled this module stream. Default Perl version branch in Redhat EL8 derived distributions is 5.26 and additional versions is provided with module streams. Currently installed Perl version in my servers is 5.26. In fact there isn't any filters concerning Perl at all in this Content Lifecyle Project. I found errors in /var/log/rhn/ rhn_web_ui.log -file corresponding the failed environment build: 2022-02-08 07:03:03,580 [RHN Message Dispatcher] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.redhat.rhn.frontend.events.AlignSoftwareTargetAction$AlignSoftwareTargetException: java.lang.StackOverflowError 2022-02-08 07:03:03,656 [RHN Message Dispatcher] ERROR com.redhat.rhn.frontend.events.AlignSoftwareTargetAction - Error aligning target 3 com.redhat.rhn.frontend.events.AlignSoftwareTargetAction$AlignSoftwareTargetException: java.lang.StackOverflowError at com.redhat.rhn.frontend.events.AlignSoftwareTargetAction.execute(AlignSoftwareTargetAction.java:71) at com.redhat.rhn.common.messaging.ActionExecutor.lambda$run$0(ActionExecutor.java:67) at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:63) at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:47) at com.redhat.rhn.common.messaging.ActionExecutor.run(ActionExecutor.java:67) at com.redhat.rhn.common.messaging.MessageDispatcher.run(MessageDispatcher.java:91) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.StackOverflowError at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) Last message continues about thousand lines. Is there any other log files I should check? We are using openSUSE Leap 15.3 and Uyuni 2022.01 version. All the client servers and repositories/channels are Rocky Linux 8. I think we must ditch current Lifecycle Environment and build totally new for our Rocky Linux servers. I wonder however is this a bug or is there something we should do differently this time to avoid this kind of errors? Br, Janne Janne Karjanlahti (Mr.) Vastaava järjestelmäasiantuntija | Senior Systems Specialist ICT- ja digitaaliset palvelut | ICT and Digital Services Satakunnan ammattikorkeakoulu | Satakunta University of Applied Sciences Satakunnankatu 23 | 28130 | PORI | Finland +358 44 710 3339 janne.karjanlahti(a)samk.fi<mailto:janne.karjanlahti@samk.fi> www.samk.fi<http://www.samk.fi>

3 2

Bugfix for Content Lifecycle Managent build failures
by Julio Gonzalez 08 Feb '22

08 Feb '22

Dear Uyuni Community. In order to support the growing number of distributions that use modular repositories, the Content Lifecycle Management feature had some updates that cause stack overflow exceptions that could fail the builds, and showed the stack overflow errors at `rhn_web_ui.log`. A bugfix to offload the work from the Java stack to prevent such overflows is now released. See how to apply the patch at https://uyuni-project.org/pages/patches.html. The fix will be part of Uyuni 2022.02 as well, but we recommend you don't wait and apply the patch as soon as possible, in particular if you are already using Content Lifecycle Management. Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Configuration issue
by Martin Willisegger 08 Feb '22

08 Feb '22

Hello list I make first tests with the configuration in Uyuni. It worked to create a configuration channel, assign it to a server and copy a file 1:1 to this server. What I can't do yet is to add dynamic values of the target system to this file. Actually I thought it works like in the manual (content configuration file): # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} Unfortunately, this is exactly what the file looked like on the target system: # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} and not as in the manual: # My test file hostname=myserver.mydomain.tld ip_address=192.168.5.31 This is probably because my openSuSE client is not "Traditional" but connected with "Salt". Even if I try it with python the python code is copied 1:1 to the target system and not interpreted. Can someone give me a working example of how I would have to create this to achieve the desired goal - after that I could certainly build on it. Btw: Now that openSuSE 15.3 reports itself as SLES15 - is there still no traditional client for OpenSuSE? :) Best regards Martin

3 2

Uyuni 2022.01 is released!
by Julio Gonzalez 31 Jan '22

31 Jan '22

We are happy to announce the immediate availability Uyuni release of this year: 2021.01 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.01, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Debian 11 as client * Link to vendor security advisory in Patch details page * Add support for custom SSH port for SSH minions * Change proxy used for clients from the WebUI Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.01 As always, we hope you will enjoy Uyuni 2022.01 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Finally, remember we will be having today the first session of 2022 of the Uyuni Cummunity Hours: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Limit Bandwidth during Repo Sync (5 Mbps for example)
by Richard.Ambaud＠isocel.info 27 Jan '22

27 Jan '22

Hello, My configuration is uyuni server last version. I would like limit the bandwidth 5 Mbps for example when i launch a sync channel. If it is possible, please explain me the different steps to have the result. Thanks. Regards Richard

2 1

Content lifecycle management - from the CLI?
by Tim Shaw 27 Jan '22

27 Jan '22

Hello I've been looking at the content lifecycle manager but would quite like to be able to script the promotion of builds from the CLI rather than interactively using the GUI Is this possible? If not is it in the roadmap? Many thanks T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

3 2

2 packages not updated on Uyuni proxies while updating to 2021.12
by Bidault, Philippe 26 Jan '22

26 Jan '22

Hi all, I am updating our Uyuni platform from 2021.08 to 2021.12, all good for the Uyuni server, but I have noticed that 2 packages are not updated on our Uyuni proxies: 1. "python3-pyvmomi" because of a Vendor change: # zypper update python3-pyvmomi Loading repository data... Reading installed packages... There is an update candidate for 'python3-pyvmomi' from vendor 'SUSE LLC https://www.suse.com/', while the current vendor is 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper install python3-pyvmomi-6.7.3-3.2.1.noarch' to install this candidate. Resolving package dependencies... Nothing to do. Do I have to update by changing the vendor for this package ? 1. "susemanager-tftpsync-recv" because seems that tftp is not installed: # zypper update susemanager-tftpsync-recv Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed susemanager-tftpsync-recv-4.3.4-1.1.uyuni1.noarch requires 'tftp', but this requirement cannot be provided not installable providers: tftp-5.2-5.3.1.x86_64[susemanager:opensuse_leap15_3-x86_64] Solution 1: deinstallation of atftp-0.7.2-lp153.2.1.x86_64 Solution 2: do not install susemanager-tftpsync-recv-4.3.4-1.1.uyuni1.noarch Solution 3: break susemanager-tftpsync-recv-4.3.4-1.1.uyuni1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c Somebody already had this issue ? Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<http://www.getronics.com> Follow us on: [cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]<https://www.linkedin.com/company/getronics/> [cid:SocialLink_Twitter_32x32_cb75fe15-abe1-46a3-9ac3-fc99d077e43b.png] <https://twitter.com/getronics> [cid:SocialLink_Youtube_32x32_1946f212-29cc-40bc-9061-3536027a9813.png] <https://www.youtube.com/channel/UCfEFIFxLdxxhMN-Eaa6pXVA> <https://twitter.com/getronics> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policy<https://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/>

1 0

Uyuni 2021.12 is released!
by Julio Gonzalez 21 Jan '22

21 Jan '22

We are happy to announce the immediate availability of Uyuni 2021.12 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.12, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Salt as a Bundle * aarch64 support for openSUSE Leap 15.3, CentOS 7/8, clones and related systems * System reactivation * Low Diskspace notification * Package Locking for Salt Minions * Monitoring: Prometheus Blackbox exporter * Monitoring: Formulas * Content Lifecycle Management improvement * New XMLRPC API methods for SaltKey * New product enabled * CVE-2021-40348 remediation * CentOS 8 End of Life * Future deprecation of the traditional stack Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2021.12 As always, we hope you will enjoy Uyuni 2021.12 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

4 11

How to push a new susemanager:channels.repo file?
by Simon Avery 19 Jan '22

19 Jan '22

Hi How can I automate regular refreshes of the /etc/yum.repos.d/susemanager:channels.repo file for EL systems? I've looked through the spacecmd reference document<https://documentation.suse.com/external-tree/en-us/suma/3.2/susemanager-adv…>, but can't spot anything that does this, although it's possible I'm just not spotting the obvious. Thanks Reasoning: On a few machines now, this file has been empty of anything but the initial comments, leading to machines not being updated since they can't see any repos. I can get Uyuni to send a fresh copy just by changing any of the Software channels through the webui and that always fixes it, but want to force this periodically with a script. I don't know why some machines have this issue and not others. I'm presuming it's a bug in Uyuni, rather than any local activity truncating it. Simon Avery Linux Systems Administrator: ATASS Sports Oxygen House | Grenadier Road, Exeter Business Park | EX1 3LH t: 01392 440 400 e: simon.avery(a)atass-sports.co.uk<mailto:simon.avery@atass-sports.co.uk> www.atass-sports.co.uk<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.atass-…> Follow us on Twitter: @atassSports<https://twitter.com/atassSports> NOTICE This email and any attachments confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Please notify the sender immediately. ATASS Ltd is incorporated in England and Wales with company number 04807405. See our website for further details and our privacy policy

1 0

Minion bug on server with 2 IP addresses
by Cristian Gherman 10 Jan '22

10 Jan '22

Hello, I have on server with 2 IP adresses on one interface and salt-minion refuse to start. File "/usr/lib/python2.7/site-packages/salt/grains/core.py", line 2378, in ip6_interfaces socket.inet_pton(socket.AF_INET6, secondary["address"]) error: illegal IP address string passed to inet_pton Because is my only server with this issue, I just comment that line to run the minion, but not very happy about this solution. I found this recomandation on SUSE site: https://www.suse.com/support/kb/doc/?id=000020527. Exist some update for Uyuni 2021.12 stable ? -- Cristian Gherman Sysadmin @Reea SRL Romania | cristian.gherman(a)reea.net | www.reea.net

2 3

Scheduling auto errata update for systems or groups
by Paul 07 Jan '22

07 Jan '22

Hello, I'm wondering if it is possible to schedule a patch installation for a system or a system group, for example every friday at 11PM, in Uyuni. I've tried several things without success, and I'm kind of lost... Regards, Paul

3 2

Confusion around using gitfs for Salt configuration.
by Kiyotoshi Ichikawa 28 Dec '21

28 Dec '21

Hello! My team and I have been working through evaluating Uyuni and we have an existing git repository with all our Salt states. The documentation here: https://www.uyuni-project.org/uyuni-docs/en/uyuni/salt/salt-gitfs.html states that we can use gitfs as the file-server backend but this does not seem to be reflected in the Uyuni Web UI. We added a configuration file to /etc/salt/master/master.d with our git remotes and get all expected values when running salt '*' cp.list_master_dirs. So, it appears that from the Salt perspective the configuration is working but the Uyuni UI does not reflect any managed states. What exactly is expected when using git remotes for Salt state/configuration?

2 2

Registering CentOS 7 client - Question and salt state error
by Stefan Bluhm 28 Dec '21

28 Dec '21

Good Morning, Can you please assist me with two questions whilst I am trying to get familiar with the salt minions/registration? (Background: AlmaLinux 8 Uyuni Server 2021.12 / CentOS7 client) 1. Bootstrapping the CentOS7 client manually does work. It took me a long time to accept the key on the master (multitasking/dinner). The minion tried to contact the server a few times but then not anymore (it seems). I had to manually restart "venv-salt-minion.service" on the client. Is this the expected behavior? 2. Failed to apply state(s): highstate I have quite some errors when applying the initial state to the minion. Are these error messages from the server or from the client?

2 4

UTF-8 issue during reposync
by Stefan Bluhm 23 Dec '21

23 Dec '21

Hello, whilst trying to do the initial CentOS 7 import into Uyuni 12.2021 on AlmaLinux 8, I am hitting the below reproducible error: 2021/12/23 07:52:50 +02:00 Package batch #471 of 480 completed... 2021/12/23 07:52:50 +02:00 Package batch #472 of 480 completed... 2021/12/23 07:52:50 +02:00 Package batch #473 of 480 completed... 2021/12/23 07:52:50 +02:00 Package batch #474 of 480 completed... 2021/12/23 07:52:50 +02:00 Package batch #475 of 480 completed... 2021/12/23 07:52:50 +02:00 Package batch #476 of 480 completed... 2021/12/23 07:52:51 +02:00 Package batch #477 of 480 completed... 2021/12/23 07:52:51 +02:00 Package batch #478 of 480 completed... 2021/12/23 07:52:51 +02:00 Package batch #479 of 480 completed... 2021/12/23 07:52:51 +02:00 Package batch #480 of 480 completed... 2021/12/23 07:53:41 +02:00 'utf-8' codec can't encode character '\udcf8' in position 19: surrogates not allowed 2021/12/23 07:53:41 +02:00 Package batch #388 of 480 completed... 2021/12/23 07:53:45 +02:00 'utf-8' codec can't encode character '\udcf8' in position 19: surrogates not allowed 2021/12/23 07:53:45 +02:00 Package batch #387 of 480 completed... 2021/12/23 07:53:45 +02:00 Importing packages finished. 2021/12/23 07:53:45 +02:00 2021/12/23 07:53:45 +02:00 Linking packages to the channel. 2021/12/23 07:54:13 +02:00 Unexpected error: <class 'spacewalk.server.importlib.importLib.InvalidPackageError'> Do you have any experience what this means? Is it a DB/File System/Package or code issue (bug)? In the meantime, I will see if I can spot the error package/code location. Thank you and best wishes, Stefan

2 5

Removing local repos with salt after an OS upgrade
by Tim Shaw 21 Dec '21

21 Dec '21

Hello When a SUSE or OES OS is upgraded it typically involves re-registration which adds a number of 'local' SUSE repos which had been previously removed by Uyuni when the system was first registered. How can I utilise Uyuni/Salt to remove those repos once more leaving only the ones coming from the Uyuni/susemanager server ? Applying highstate appears not to have any effect Applying salt 'system state.apply ''channels'' runs but has no effect Applying salt 'system' state.apply ''channels/disablelocalrepos'' runs but fails - I assume you are not meant to do this... I expect this is simple if only I knew how.... T __________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

1 0

AW: Log4Shell announcement (CVE-2021-44228)
by Crefeld, Tobias LKV Bayern e.V. 14 Dec '21

14 Dec '21

Hi, although it's unlikely that this configuration got changed in our installation, I'd like to check it. Can someone tell me which file contains the log4j configuration? TIA! Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Johannes Renner [mailto:jrenner@suse.de] Gesendet: Montag, 13. Dezember 2021 15:52 An: uyuni-users(a)opensuse.org; uyuni-announce(a)opensuse.org Betreff: Log4Shell announcement (CVE-2021-44228) Dear Uyuni users, With regard to the latest publication of the Log4Shell vulnerability [1], we can announce that as to our current knowledge Uyuni installations are not affected. Log4j is used in Uyuni, but we are shipping version 1.2.17 (from openSUSE Leap 15.3) which apparently is showing that specific problem only when it is configured to use JMSAppender [2]. This is not the case in Uyuni as long as the log4j configuration has not manually been changed to use it. A general fix for the 1.2.17 package is currently being worked on and should become available soon. Best regards, Johannes Renner [1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228 [2] https://access.redhat.com/security/cve/CVE-2021-4104

2 1

Log4Shell announcement (CVE-2021-44228)
by Johannes Renner 13 Dec '21

13 Dec '21

Dear Uyuni users, With regard to the latest publication of the Log4Shell vulnerability [1], we can announce that as to our current knowledge Uyuni installations are not affected. Log4j is used in Uyuni, but we are shipping version 1.2.17 (from openSUSE Leap 15.3) which apparently is showing that specific problem only when it is configured to use JMSAppender [2]. This is not the case in Uyuni as long as the log4j configuration has not manually been changed to use it. A general fix for the 1.2.17 package is currently being worked on and should become available soon. Best regards, Johannes Renner [1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228 [2] https://access.redhat.com/security/cve/CVE-2021-4104 -- Johannes Renner - Engineering Manager, SUSE Manager; R&D SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Ivo Totev

2 1

No package sync
by Martin Willisegger 12 Dec '21

12 Dec '21

Hello List I have two servers in the system overview - both systems show a different number of packages and erata to be installed. When I install these packages the job completes successfully but the number remains the same in the system overview. A zypper update directly on the systems reports that there are no updates and when I use zypper info to compare the version of the displayed packages inside Uyuni, the packages in the list are already installed. How can I force Uyuni to correctly detect the installed packages and correct the list? Best regards Martin

2 1

Re: Problem with salt states pushed to OES
by Tim Shaw 08 Dec '21

08 Dec '21

Michael, Thanks! It sounds like you think the OES people should not be using such a method? I can query it with the product management people there... The issue here has been simply resolved for now by me with a minor modification to /usr/share/susemanager/salt/packages/init.sls but it's a crude solution because it relies on identifying an OES system by virtue of the fact that it's oscodename grain is 'SUSE Linux Enterprise Server 12 SP5' - so ancient that our OES servers are the only systems running this! So we can use it to identify OES It would be better to have a grain specifically identifying Open Enterprise Server - if anyone is listening... Pseudo code might be: if exists /etc/novell-release read version from file create grain for OES version Agreed - *-migration products should NOT be candidates for automatic installation - but I'm afraid I do not have the necessary skills to propose a modification to https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/susema… But if suitably knowledgeable person contribute, it's a job worth doing! T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480 >>> Michael Calmer <mc(a)suse.de> 08/12/2021 14:41 >>> Hi We thought the time of migration products is over. Well, anyway. You can create a Content Live Management Project and filter the migration packages out. This would be a permanent solution. You can also manually change /usr/share/susemanager/salt/packages/init.sls This is the state which call the installation. And if you are really good, you can make a PR and fix the state module directly https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/susema… ¶ I think the goal would be to remove all "*-migration" packages from the list. I hope it helps. Am Mittwoch, 8. Dezember 2021, 15:21:08 CET schrieb Tim Shaw: > Hello > > I think there is a problem with the way Uyuni works with Open Enterprise Server systems > > On OES, when a Service Pack becomes available it is delivered as a zypper product which SHOULD remain uninstalled until such time as the Service Pack migration is initiated. Then as part of the migration the product is installed. > > From what we can see Uyuni is ignoring this and blindly installing the product if it sees it present but not installed. Se below from the event history on an OES2018SP2 system. The Open_Enterprise_Server-SP3-migration product is NOT supposed to be installed - just left available until a decision to upgrade is taken. > > ---------- ID: mgr_install_products Function: product.installed Name: mgr_install_products Result: true Comment: 1 targeted package was installed/updated. Started: 09:09:31.882562 Duration: 12961.896 SLS: packages Changed: Open_Enterprise_Server-SP3-migration: new: 2018.2-3.1 old: '' > > This is serious because it causes new repos for the new service pack to be collected from the SUSE registration server and offered to the system - so you then get packages from the new Service Pack introduced to a system running the older service release > > AAARRGGHH!!! > > How can I sort this out - I'm assuming it is a bug...- but in the meantime where can I find and disable this procedure? > > T > > > *Please note I am now working part-time - Tuesdays and Wednesday only* > ___________________________________________________________ > TIM SHAW - MSD IT Systems & Network Services > Medical Sciences Division - University of Oxford > email : tim.shaw(a)medsci.ox.ac.uk > tel : +44 (0)1865 289480 > > > -- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer(a)suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nürnberg)

1 1

Problem with salt states pushed to OES
by Tim Shaw 08 Dec '21

08 Dec '21

Hello I think there is a problem with the way Uyuni works with Open Enterprise Server systems On OES, when a Service Pack becomes available it is delivered as a zypper product which SHOULD remain uninstalled until such time as the Service Pack migration is initiated. Then as part of the migration the product is installed. From what we can see Uyuni is ignoring this and blindly installing the product if it sees it present but not installed. Se below from the event history on an OES2018SP2 system. The Open_Enterprise_Server-SP3-migration product is NOT supposed to be installed - just left available until a decision to upgrade is taken. ---------- ID: mgr_install_products Function: product.installed Name: mgr_install_products Result: true Comment: 1 targeted package was installed/updated. Started: 09:09:31.882562 Duration: 12961.896 SLS: packages Changed: Open_Enterprise_Server-SP3-migration: new: 2018.2-3.1 old: '' This is serious because it causes new repos for the new service pack to be collected from the SUSE registration server and offered to the system - so you then get packages from the new Service Pack introduced to a system running the older service release AAARRGGHH!!! How can I sort this out - I'm assuming it is a bug...- but in the meantime where can I find and disable this procedure? T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

2 1

Cant sync jitsi debian repository
by Timo Brunn 08 Dec '21

08 Dec '21

When I try to sync the following repository, it throws an error (see below): Repository URL*: https://download.jitsi.org/stable/ Repository Type*: deb Has Signed Metadata?: false The errors are like this: 12:55:54 ERROR: Download failed: https://download.jitsi.org/stable/stable/jitsi-videobridge2_2.1-376-g9f12bf… - [Errno 14] HTTPS Error 404 - Not Found. 12:55:54 388/396 : jitsi-videobridge2_2.1-376-g9f12bfe2-1_all.deb (failed) It seems to add a second "stable" to every file it tries to download. While on the other hand this and some other repos (all type "deb") synced perfectly: https://packages.prosody.im/debian/dists/focal/main/binary-amd64/

2 1

Reminder: Uyuni Community Hours on Friday Nov 26th (16.00 CET)
by Julio Gonzalez 22 Nov '21

22 Nov '21

As every month, we are having the Uyuni Community Hours on the last Friday of the month. The provisional agenda, as well as the link to Join the meeting is at https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours Remember that you, as member of the community, can also present at the Community Hours. So if you have any topic that you think is interesting, just contact me here or at Gitter. See you on Friday! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Playing with Uyuni XMLRPC API using Python demo videos!
by Pablo Suárez Hernández 16 Nov '21

16 Nov '21

Hi there! this is just a short announcement, to let you know that we have published two small demo/tutorial videos in our Uyuni Youtube channel about "Playing with Uyuni XMLRPC API using Python". The idea of these videos is to give you a quick overview and examples that help you to understand how you can interact with the Uyuni XMLRPC API and how easy is to do it using Python. The videos are around 5 minutes long each so they are easy to consume: - Part 1: https://www.youtube.com/watch?v=gItPMQfQyG0 - Part 2: https://www.youtube.com/watch?v=DjCXCvTzx8U I hope these are helpful for you! Cheers, Pablo -- Pablo Suárez Hernández - <psuarezhernandez(a)suse.de> SUSE Manager Development Team SUSE Software Solutions Germany GmbH Maxfeldstrasse 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, HRB 36809, AG Nürnberg

1 0

Re: Removing packages not assigned to a channel from the command line
by Tim Shaw 10 Nov '21

10 Nov '21

Apologies - I have found a spacecmd command called package_removeorphans Sorry to have posted without looking more carefully! T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480 >>> Tim Shaw <tim.shaw(a)medsci.ox.ac.uk> 10/11/2021 11:59 >>> Hello I recently removed some channels using the GUI in 2021.09 and somehow I managed to fail to delete the associated packages with the result that I now have a large number of packages in the system which belong to no channel. Attempts to process these 23000+ packages through the GUI result in a timeout error message on the web interface and it isn't clear whether any background process has actually started to purge these packages... Is there a command line way to deal with these packages now that they belong to no channel which will tell me what's going on without timing out? I cannot immediately see a spacewalk‑xxxx coammnd or a spacecmd subcommand which looks likely... Many thanks! T *Please note I am now working part‑time ‑ Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW ‑ MSD IT Systems & Network Services Medical Sciences Division ‑ University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

1 0

Removing packages not assigned to a channel from the command line
by Tim Shaw 10 Nov '21

10 Nov '21

Hello I recently removed some channels using the GUI in 2021.09 and somehow I managed to fail to delete the associated packages with the result that I now have a large number of packages in the system which belong to no channel. Attempts to process these 23000+ packages through the GUI result in a timeout error message on the web interface and it isn't clear whether any background process has actually started to purge these packages... Is there a command line way to deal with these packages now that they belong to no channel which will tell me what's going on without timing out? I cannot immediately see a spacewalk-xxxx coammnd or a spacecmd subcommand which looks likely... Many thanks! T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

2 1

Security bugfix for CVE-2021-40348 (Uyuni Server)
by Julio Gonzalez 28 Oct '21

28 Oct '21

Dear Uyuni Community. A security bugfix for CVE-2021-40348, for the Uyuni Server, is now released, to be installed on top of Uyuni 2021.09 The patch fixes an arbitrary code execution vulnerability at rhn-config- satellite.pl See how to apply the patch at https://uyuni-project.org/pages/patches.html. The fix will be part of Uyuni 2021.11 as well, but we strongly recommend you don't wait and apply the patch as soon as possible. Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Unable to install last version of Uyuni stable
by Bidault, Philippe 26 Oct '21

26 Oct '21

Hi all ¡ I am trying to install Uyuni on top of a fresh OpenSuse 15.3 installation. I am following the simple instructions from there https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation/install-uyun… but no luck, I have dependencies issue: # zypper in patterns-uyuni_server Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed patterns-uyuni_server-2021.09-1.1.uyuni1.x86_64 requires 'py26-compat-salt', but this requirement cannot be provided not installable providers: py26-compat-salt-2016.11.10-71.1.uyuni1.noarch[uyuni-server-stable] Solution 1: Following actions will be done: downgrade of rpm-4.14.3-37.2.x86_64 to rpm-4.14.1-29.46.x86_64 downgrade of python3-rpm-4.14.3-37.2.x86_64 to python3-rpm-4.14.1-29.2.x86_64 Solution 2: do not install patterns-uyuni_server-2021.09-1.1.uyuni1.x86_64 Solution 3: break patterns-uyuni_server-2021.09-1.1.uyuni1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c If I try to install py26-compat-salt by hand, more dependencies issue: # zypper install py26-compat-salt Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed py26-compat-salt-2016.11.10-71.1.uyuni1.noarch requires 'rpm-python', but this requirement cannot be provided not installable providers: python2-rpm-4.14.1-29.2.x86_64[repo-oss] Solution 1: Following actions will be done: downgrade of rpm-4.14.3-37.2.x86_64 to rpm-4.14.1-29.46.x86_64 downgrade of python3-rpm-4.14.3-37.2.x86_64 to python3-rpm-4.14.1-29.2.x86_64 Solution 2: do not install py26-compat-salt-2016.11.10-71.1.uyuni1.noarch Solution 3: break py26-compat-salt-2016.11.10-71.1.uyuni1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c Nothing exotic on the server, only the default Opensuse repos: # zypper lr Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+-----------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- 1 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | Yes | (r ) Yes | Yes 2 | repo-debug | Debug Repository | Yes | (r ) Yes | Yes 3 | repo-debug-non-oss | Debug Repository (Non-OSS) | Yes | (r ) Yes | Yes 4 | repo-debug-update | Update Repository (Debug) | Yes | (r ) Yes | Yes 5 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | Yes | (r ) Yes | Yes 6 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 7 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 8 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes 9 | repo-source | Source Repository | Yes | (r ) Yes | Yes 10 | repo-source-non-oss | Source Repository (Non-OSS) | Yes | (r ) Yes | Yes 11 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 12 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes 13 | uyuni-server-stable | uyuni-server-stable Did somebody already struggle with this and know how to overcome it ? Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.getronics.com> [cid:3-lines_7512e235-163a-4853-8e4f-b0d4fc62ce73.png]<https://getronics.com/> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

1 0

Uyuni community hours: next Friday October 29th
by Julio Gonzalez 22 Oct '21

22 Oct '21

Hello, Last month, I did a mistake when I created the recurring appointment for the Uyuni Community Hours, and as a result the meeting was schedule for today (October 22nd) instead of being scheduled for the last Friday of the month (October 29th) I just fixed the problem, and the appointment should now be correctly displayed in your calendars. Sorry about the inconvenience. See you in one week! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Uyuni Community Hours
by Julio Gonzalez 22 Oct '21

22 Oct '21

Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours Uyuni Community Hours are held every last Friday of the month, at 4 PEM CET/CEST. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A NOTE: This schedule overrides the previous one and does not request attendance confirmation. ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZjZlMWI0OTctNGMxZi00…> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=ef7551ee-a699-477f-…> ________________________________________________________________________________

1 0

New Uyuni install on openSUSE Leap 15.3 - Tomcat failing to start
by Neil Sherin 15 Oct '21

15 Oct '21

Hi, I've installed Uyuni on a fresh openSUSE 15.3 install. it's a VM with 4 CPUs, 8GB RAM plus the required storage. The VM is dedicated to Uyuni as a test environment. I've gone through the setup wizard via YAST, but there seems to be an issue with Tomcat starting. I have no clue about where to begin as to debugging the issue with Tomcat. Any help would be much appreciated. I have copied the output from the log files below. Many thanks, Neil Output from log files below: t-uyuni:/var/log # cat /var/log/susemanager_setup.log Asserting correct java version... /var/spacewalk already exists. Leaving it untouched. Filesystem type for /var/cache is ext4 - ok. Open needed firewall ports... running success success Performing forced re-installation! Shutting down spacewalk services... Done. Delete existing database... Delete existing salt minion keys CREATE ROLE * Loading answer file: /root/spacewalk-answers. ** Database: Setting up database connection for PostgreSQL backend. ** Database: Populating database. ** Database: --clear-db option used. Clearing database. ** Database: Shutting down spacewalk services that may be using DB. ** Database: Services stopped. Clearing DB. *** Progress: # * Configuring tomcat. * Setting up users and groups. ** GPG: Initializing GPG and importing key. * Performing initial configuration. * Configuring apache SSL virtual host. * Configuring jabberd. * Creating SSL certificates. ** SSL: Generating CA certificate. ** SSL: Deploying CA certificate. ** SSL: Generating server certificate. ** SSL: Storing SSL certificates. * Deploying configuration files. * Update configuration in database. * Setting up Cobbler.. * Restarting services. Tomcat failed to start properly or the installer ran out of tries. Please check /var/log/tomcat/catalina.out or /var/log/tomcat/catalina.$(date +%Y-%m-%d).log for errors t-uyuni:/var/log # cat /var/log/tomcat/catalina.out: tomcat-9.0.36 RPM installed t-uyuni:/var/log # cat /var/log/tomcat/catalina.2021-10-15.log 15-Oct-2021 00:23:43.424 SEVERE [main] org.apache.catalina.startup.Catalina.initDirs Cannot find specified temporary folder at [/var/cache/tomcat/temp] 15-Oct-2021 00:23:43.893 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.36 15-Oct-2021 00:23:43.893 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Mar 17 2021 12:00:00 UTC 15-Oct-2021 00:23:43.893 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.36.0 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.3.18-59.27-default 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib64/jvm/java-11-openjdk-11 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.12+7-suse-3.62.1-x8664 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /usr/share/tomcat 15-Oct-2021 00:23:43.894 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat 15-Oct-2021 00:23:43.895 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -ea 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms256m 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx1G 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.xml.sax.driver=com.redhat.rhn.frontend.xmlrpc.util.RhnSAXParser 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:MaxNewSize=256 15-Oct-2021 00:23:43.896 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:-UseConcMarkSweepGC 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dnet.sf.ehcache.skipUpdateCheck=true 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-exports=java.annotation/javax.annotation.security=ALL-UNNAMED 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.annotation/javax.annotation.security=ALL-UNNAMED 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-modules=java.annotation,com.sun.xml.bind 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/share/tomcat 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/share/tomcat 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs= 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/var/cache/tomcat/temp 15-Oct-2021 00:23:43.897 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties 15-Oct-2021 00:23:43.898 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 15-Oct-2021 00:23:43.898 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.23] using APR version [1.6.3]. 15-Oct-2021 00:23:43.898 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 15-Oct-2021 00:23:43.898 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] 15-Oct-2021 00:23:43.901 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1d 10 Sep 2019] 15-Oct-2021 00:23:44.443 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:23:44.494 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:23:44.496 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:23:44.500 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [1,076] milliseconds 15-Oct-2021 00:23:44.580 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 15-Oct-2021 00:23:44.580 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.36] 15-Oct-2021 00:23:44.584 SEVERE [main] org.apache.catalina.startup.HostConfig.beforeStart Unable to create directory for deployment: [/etc/tomcat/Catalina/localhost] 15-Oct-2021 00:23:44.590 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/srv/tomcat/webapps/rhn] 15-Oct-2021 00:23:44.645 WARNING [main] org.apache.catalina.core.StandardContext.postWorkDirectory Failed to create work directory [/usr/share/tomcat/work/Catalina/localhost/rhn] for context [/rhn] 15-Oct-2021 00:23:56.306 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 15-Oct-2021 00:23:59.601 INFO [MLog-Init-Reporter] com.mchange.v2.log.MLog$1.run MLog clients using java 1.4+ standard logging. 15-Oct-2021 00:23:59.725 INFO [main] com.mchange.v2.c3p0.C3P0Registry.banner Initializing c3p0-0.9.5.2 [built 28-November-2020 12:00:00 +0000; debug? false; trace: 5] 15-Oct-2021 00:23:59.854 INFO [main] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@1f90fe4 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@7ec3c36 [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|3ca7f198, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@3224f2b7 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|674f5034, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztqmgw1fjdewj|5db16956, numHelperThreads -> 3 ] 15-Oct-2021 00:24:02.696 INFO [RHN Message Dispatcher] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@1b002e00 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@815d6c47 [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|56c640d3, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@898f6136 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|3b48d01b, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztqmgw1fjdewj|45e17594, numHelperThreads -> 3 ] 15-Oct-2021 00:24:03.712 INFO [salt-event-connection-watchdog] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@cd96a19c [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@33ce53fc [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|4eae19e2, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@e2719916 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|454e4cc, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztqmgw1fjdewj|2fc9b33b, numHelperThreads -> 3 ] 15-Oct-2021 00:24:04.501 INFO [main] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@5a587ba1 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@abc5536c [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|76eb41bc, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@d0214c51 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztqmgw1fjdewj|275c02dd, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztqmgw1fjdewj|4a238791, numHelperThreads -> 3 ] 15-Oct-2021 00:24:04.844 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file 15-Oct-2021 00:24:04.852 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal Context [/rhn] startup failed due to previous errors 15-Oct-2021 00:24:04.890 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [rhn] registered the JDBC driver [org.postgresql.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. 15-Oct-2021 00:24:04.891 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [rhn] registered the JDBC driver [com.impossibl.postgres.jdbc.PGDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. 15-Oct-2021 00:24:04.891 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [pool-1-thread-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:340) org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.execute(PoolingNHttpClientConnectionManager.java:221) org.apache.http.impl.nio.client.CloseableHttpAsyncClientBase$1.run(CloseableHttpAsyncClientBase.java:64) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.897 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.898 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.899 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 3] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.900 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 4] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.902 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [RHN Message Dispatcher] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(LinkedQueue.java:170) com.redhat.rhn.common.messaging.MessageQueue.popEventMessage(MessageQueue.java:144) com.redhat.rhn.common.messaging.MessageDispatcher.run(MessageDispatcher.java:80) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.902 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|5db16956]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:24:04.903 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|5db16956]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.904 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|5db16956]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.905 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|5db16956]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.906 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [__DEFAULT__] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.lang.Object.wait(Object.java:328) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:527) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:24:04.907 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [PG-JDBC Housekeeper] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) java.base@11.0.12/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176) com.impossibl.postgres.jdbc.ThreadedHousekeeper$1.run(ThreadedHousekeeper.java:187) 15-Oct-2021 00:24:04.908 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [PG-JDBC I/O (1)] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141) io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68) io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803) io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457) io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:24:04.909 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|45e17594]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:24:04.910 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|45e17594]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.911 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|45e17594]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.912 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|45e17594]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.912 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|2fc9b33b]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:24:04.913 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|2fc9b33b]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.913 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|2fc9b33b]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.914 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|2fc9b33b]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.915 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|4a238791]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:24:04.916 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|4a238791]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.917 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|4a238791]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.917 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|4a238791]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:24:04.919 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@41999e96]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@63ca45e0]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 15-Oct-2021 00:24:04.920 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@41999e96]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@50d4c4dc]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 15-Oct-2021 00:24:04.928 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [20,338] ms 15-Oct-2021 00:24:04.932 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:24:04.950 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:24:04.956 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:24:04.959 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [20,458] milliseconds 15-Oct-2021 00:28:59.875 INFO [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztqmgw1fjdewj|5db16956]-AdminTaskTimer] org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading Illegal access: this web application instance has been stopped already. Could not load [com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load [com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1385) at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1373) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1226) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1188) at com.mchange.v2.resourcepool.BasicResourcePool.checkIdleResources(BasicResourcePool.java:1635) at com.mchange.v2.resourcepool.BasicResourcePool.access$2000(BasicResourcePool.java:44) at com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(BasicResourcePool.java:2176) at java.base/java.util.TimerThread.mainLoop(Timer.java:556) at java.base/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:29:58.883 INFO [main] org.apache.catalina.core.StandardServer.await A valid shutdown command was received via the shutdown port. Stopping the Server instance. 15-Oct-2021 00:29:58.884 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:29:58.890 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:29:58.896 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:29:58.902 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service [Catalina] 15-Oct-2021 00:29:58.904 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:29:58.908 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:29:58.911 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:29:58.915 INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:30:20.700 SEVERE [main] org.apache.catalina.startup.Catalina.initDirs Cannot find specified temporary folder at [/var/cache/tomcat/temp] 15-Oct-2021 00:30:21.136 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.36 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Mar 17 2021 12:00:00 UTC 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.36.0 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.3.18-59.27-default 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 15-Oct-2021 00:30:21.137 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib64/jvm/java-11-openjdk-11 15-Oct-2021 00:30:21.138 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.12+7-suse-3.62.1-x8664 15-Oct-2021 00:30:21.138 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 15-Oct-2021 00:30:21.138 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /usr/share/tomcat 15-Oct-2021 00:30:21.138 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -ea 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms256m 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx1G 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.xml.sax.driver=com.redhat.rhn.frontend.xmlrpc.util.RhnSAXParser 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 15-Oct-2021 00:30:21.145 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:MaxNewSize=256 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:-UseConcMarkSweepGC 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dnet.sf.ehcache.skipUpdateCheck=true 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-exports=java.annotation/javax.annotation.security=ALL-UNNAMED 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.annotation/javax.annotation.security=ALL-UNNAMED 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-modules=java.annotation,com.sun.xml.bind 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/share/tomcat 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/share/tomcat 15-Oct-2021 00:30:21.146 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs= 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/var/cache/tomcat/temp 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.23] using APR version [1.6.3]. 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 15-Oct-2021 00:30:21.147 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] 15-Oct-2021 00:30:21.150 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1d 10 Sep 2019] 15-Oct-2021 00:30:22.602 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:30:22.727 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:30:22.740 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:30:22.748 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [2,048] milliseconds 15-Oct-2021 00:30:23.023 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 15-Oct-2021 00:30:23.023 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.36] 15-Oct-2021 00:30:23.027 SEVERE [main] org.apache.catalina.startup.HostConfig.beforeStart Unable to create directory for deployment: [/etc/tomcat/Catalina/localhost] 15-Oct-2021 00:30:23.066 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/srv/tomcat/webapps/rhn] 15-Oct-2021 00:30:23.168 WARNING [main] org.apache.catalina.core.StandardContext.postWorkDirectory Failed to create work directory [/usr/share/tomcat/work/Catalina/localhost/rhn] for context [/rhn] 15-Oct-2021 00:30:33.404 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 15-Oct-2021 00:30:36.592 INFO [MLog-Init-Reporter] com.mchange.v2.log.MLog$1.run MLog clients using java 1.4+ standard logging. 15-Oct-2021 00:30:36.724 INFO [main] com.mchange.v2.c3p0.C3P0Registry.banner Initializing c3p0-0.9.5.2 [built 28-November-2020 12:00:00 +0000; debug? false; trace: 5] 15-Oct-2021 00:30:36.898 INFO [main] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@a1bbdb61 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@1a8d630f [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztz4s2162y2vk|21358f6c, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@5859dcb1 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztz4s2162y2vk|3c68a85f, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztz4s2162y2vk|1df0f641, numHelperThreads -> 3 ] 15-Oct-2021 00:30:39.793 INFO [RHN Message Dispatcher] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@78d300e0 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@d768dc5a [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztz4s2162y2vk|6ca86bab, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@f0807a9c [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztz4s2162y2vk|66bfec9, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztz4s2162y2vk|40761d63, numHelperThreads -> 3 ] 15-Oct-2021 00:30:40.674 INFO [salt-event-connection-watchdog] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@3fc43092 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@40130bf7 [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztz4s2162y2vk|25768b08, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@dec86c09 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztz4s2162y2vk|22762e4d, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztz4s2162y2vk|418aab0b, numHelperThreads -> 3 ] 15-Oct-2021 00:30:41.460 INFO [main] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getPoolManager Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@77186e2f [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@4e92c539 [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 1hge1vpakztz4s2162y2vk|5d98a66e, idleConnectionTestPeriod -> 300, initialPoolSize -> 5, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 300, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 20, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@25af1126 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 1hge1vpakztz4s2162y2vk|dae3613, jdbcUrl -> jdbc:postgresql://localhost:5432/uyuni, properties -> {driver_proto=jdbc:postgresql, password=******, user=******} ], preferredTestQuery -> select 'c3p0 ping' from dual, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> true, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 1hge1vpakztz4s2162y2vk|d304447, numHelperThreads -> 3 ] 15-Oct-2021 00:30:41.763 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file 15-Oct-2021 00:30:41.767 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal Context [/rhn] startup failed due to previous errors 15-Oct-2021 00:30:41.810 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [rhn] registered the JDBC driver [org.postgresql.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. 15-Oct-2021 00:30:41.810 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [rhn] registered the JDBC driver [com.impossibl.postgres.jdbc.PGDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. 15-Oct-2021 00:30:41.812 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [pool-1-thread-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:340) org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.execute(PoolingNHttpClientConnectionManager.java:221) org.apache.http.impl.nio.client.CloseableHttpAsyncClientBase$1.run(CloseableHttpAsyncClientBase.java:64) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.813 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.814 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.815 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 3] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.816 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [I/O dispatcher 4] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.818 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [RHN Message Dispatcher] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(LinkedQueue.java:170) com.redhat.rhn.common.messaging.MessageQueue.popEventMessage(MessageQueue.java:144) com.redhat.rhn.common.messaging.MessageDispatcher.run(MessageDispatcher.java:80) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.819 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|1df0f641]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:30:41.819 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|1df0f641]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.820 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|1df0f641]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.821 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|1df0f641]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.822 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [__DEFAULT__] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.lang.Object.wait(Object.java:328) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:527) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:30:41.822 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [PG-JDBC Housekeeper] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) java.base@11.0.12/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176) com.impossibl.postgres.jdbc.ThreadedHousekeeper$1.run(ThreadedHousekeeper.java:187) 15-Oct-2021 00:30:41.823 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [PG-JDBC I/O (1)] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/sun.nio.ch.EPoll.wait(Native Method) java.base@11.0.12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) java.base@11.0.12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) java.base@11.0.12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141) io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68) io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803) io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457) io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) java.base@11.0.12/java.lang.Thread.run(Thread.java:829) 15-Oct-2021 00:30:41.825 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|40761d63]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:30:41.825 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|40761d63]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.826 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|40761d63]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.827 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|40761d63]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.828 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|418aab0b]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:30:41.828 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|418aab0b]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.829 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|418aab0b]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.830 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|418aab0b]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.830 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|d304447]-AdminTaskTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) java.base@11.0.12/java.util.TimerThread.mainLoop(Timer.java:553) java.base@11.0.12/java.util.TimerThread.run(Timer.java:506) 15-Oct-2021 00:30:41.831 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|d304447]-HelperThread-#0] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.832 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|d304447]-HelperThread-#1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.832 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|d304447]-HelperThread-#2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11.0.12/java.lang.Object.wait(Native Method) com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:683) 15-Oct-2021 00:30:41.834 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@67f49986]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@5d349cc2]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 15-Oct-2021 00:30:41.835 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@67f49986]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@227be37c]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 15-Oct-2021 00:30:41.841 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [18,775] ms 15-Oct-2021 00:30:41.844 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 15-Oct-2021 00:30:41.866 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 15-Oct-2021 00:30:41.876 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 15-Oct-2021 00:30:41.885 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [19,137] milliseconds 15-Oct-2021 00:35:36.918 INFO [C3P0PooledConnectionPoolManager[identityToken->1hge1vpakztz4s2162y2vk|1df0f641]-AdminTaskTimer] org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading Illegal access: this web application instance has been stopped already. Could not load [com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load [com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1385) at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1373) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1226) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1188) at com.mchange.v2.resourcepool.BasicResourcePool.checkIdleResources(BasicResourcePool.java:1635) at com.mchange.v2.resourcepool.BasicResourcePool.access$2000(BasicResourcePool.java:44) at com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(BasicResourcePool.java:2176) at java.base/java.util.TimerThread.mainLoop(Timer.java:556) at java.base/java.util.TimerThread.run(Timer.java:506)

2 1

Correct way to import repository GPG key when adding channels to management system?
by Allen Beddingfield 14 Oct '21

14 Oct '21

What is the correct/preferred way to import the GPG key for a repository to a managed system? If the GPG key info is correctly filled out on the repository configuration, should they be automatically imported and trusted by the client when the channel is added? I've found these instructions in the documentation for doing this with a Salt state. Is this the preferred method? https://www.uyuni-project.org/uyuni-docs/en/uyuni/salt/custom-states.html If they are supposed to be added automatically, and mine is just not working correctly, I may need to get some troubleshooting assistance. Also, I've gotten around this in the past on SUSE systems by just unchecking "Enable GPG Check" for the repo. This apparently does not work for CentOS systems. Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

1 0

Need help with repository GPG settings.
by Allen Beddingfield 05 Oct '21

05 Oct '21

I have configured a repository and channel for Zabbix 5.4. It syncs and works as expected. For SUSE systems, I have unchecked "Enable GPG Check", and it works fine. Now, I have setup a repository for this for CentOS 7, but it gives errors similar to the following, when trying to install a package: "Public key for zabbix-agent2-5.4.5-1.el7.x86_64.rpm is not installed". It seems that just unchecking GPG check doesn't work with yum as it does with zypper. In the GPG section, for "GPG Key URL", I have put " http://repo.zabbix.com/RPM-GPG-KEY-ZABBIX-A14FE591" I'm not sure what to put for "GPG Key ID" or "GPG Key Fingerprint". The key in the URL is correct, because I can manually install that one on the client and have it work. How do I get this to work when the channel is associated with a CentOS system (as it does on SLES), without having to manually import that key on the system? Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

1 1

Upgrade 2021.09 - Wrong vendor on packages?
by Simon Avery 05 Oct '21

05 Oct '21

Hi Thanks to all involved in the latest version - good to see it keep growing in strength! I did the upgrade from 2021.08 this morning, following the usual MINOR procedure. All seemed to have go well and Uyuni came back after rebooting and functioned normally. However - a question following the update and reboot - some updates and flagged as below. I'm guessing it is safe to override the vendor and install the new packages? Thanks ata-oxy-uyuni01:/home/simon # zypper up Loading repository data... Reading installed packages... The following 6 package updates will NOT be installed: mgr-osa-dispatcher python3-mgr-osa-common python3-mgr-osa-dispatcher python3-rhnlib python3-suseRegisterInfo suseRegisterInfo Nothing to do. ata-oxy-uyuni01:/home/simon # zypper up mgr-osa-dispatcher Loading repository data... Reading installed packages... There is an update candidate for 'mgr-osa-dispatcher' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install mgr-osa-dispatcher-4.3.1-1.2.uyuni1.noarch' to install this candidate. Resolving package dependencies... Nothing to do. simon@ata-oxy-uyuni01:~> zypper repos Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh --+-----------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- 1 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 2 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes 3 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 4 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 5 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 6 | repo-sle-update | Update repository wiht updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes 7 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 8 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes 9 | uyuni-server-stable | Uyuni Server Stable | Yes | (r ) Yes | Yes Simon Avery Linux Systems Administrator

3 5

Error when using "Product Migration" on openSuSE Clients
by Martin Willisegger 30 Sep '21

30 Sep '21

Hello list I get a system error every time I click on the "System Migration" menu item in uyuni with an openSuSE 15.3 client. This is not particularly bad, because a system migration is not offered with openSuSE. Nevertheless, this should not immediately cause an error. After that I get the following uyuni WEB TRACEBACK system mail: The following exception occurred while executing this request: GET /rhn/systems/details/SPMigration.do Date:9/30/21 5:22:26 PM CEST Headers: host: uyuni.wizonet user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0 accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 accept-language: de,en-US;q=0.7,en;q=0.3 accept-encoding: gzip, deflate, br connection: keep-alive referer:https://uyuni.wizonet/rhn/systems/details/packages/Packages.do?date_hour=17&date_year=2021&schedule_type=date&date_month=8&date_day=30&date_minute=21&sid=1000010001 cookie: DWRSESSIONID=V56dyvHj2F9FrG4OVCcUm2VtqSe4uWziTMn; JSESSIONID=03FEFA72F1D29CC4B0C583AEDE4BE345; pxt-session-cookie=525659xd418885dfa66c3fa7dfc0579fc041f50ca7ec8ac2990cb8386ca1cd3553757df Upgrade-Insecure-Requests: 1 Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: same-origin Sec-Fetch-User: ?1 Request: Local Name = uyuni.wizonet Server Name = uyuni.wizonet Requested Session Id came from Cookie Requested Session Valid = true Session = org.apache.catalina.session.StandardSessionFacade@6e0a108f[session=StandardSession[03FEFA72F1D29CC4B0C583AEDE4BE345]] Protocol = https Request Locale = en_US Request Character Encoding = UTF-8 Attribute Names = rhnActiveLang, org.apache.struts.action.MESSAGE, org.apache.struts.action.mapping.instance, targetProductSelectedEmpty, org.apache.tomcat.util.net.secure_protocol_version, requestedUri, isSUSEMinion, session, zyppPluginInstalled, isSaltUpToDate, javax.servlet.request.key_size, org.apache.struts.action.MODULE, isMinion, productMigrationForm, updateStackUpdateNeeded, javax.servlet.request.cipher_suite, javax.servlet.request.ssl_session_id, __sitemesh__filterapplied, upgradeSupported, system, javax.servlet.jsp.jstl.fmt.timeZone.request, javax.servlet.error.exception, User Information: User admin (id 1, org_id 1) Exception: javax.servlet.ServletException: java.lang.NullPointerException at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:237) at com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProcessor.java:104) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:634) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:142) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:69) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:55) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:432) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1591) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.NullPointerException at com.redhat.rhn.domain.product.SUSEProductSet.toString(SUSEProductSet.java:256) at com.redhat.rhn.frontend.action.systems.SPMigrationAction.lambda$execute$0(SPMigrationAction.java:228) at java.base/java.util.Optional.ifPresent(Optional.java:183) at com.redhat.rhn.frontend.action.systems.SPMigrationAction.execute(SPMigrationAction.java:228) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) ... 47 more

2 1

Newly registered client shows last booted time = registration time
by J-M Roth 28 Sep '21

28 Sep '21

Hello, We found that for a newly registered system, Detail > Overview > System Events > Last Booted shows the time at which the system was registered/bootstrapped, and not actually booted. I opened a ticket with support, they just gave me "works as designed" because the documentation for "Overview > System Status" notes "This message indicates the current state of your system _in relation to SUSE Manager_." I fail what that is supposed to mean, especially since system status and system events are different parts of the GUI. best regards, J-M Roth

2 3

Client tools for CentOS 7 - verison issue for salt
by Cristian Gherman 28 Sep '21

28 Sep '21

Hello all @Julio I spotted again a issue with latest salt-minon packages form CentOS 7 - which on repo have a lower version as we had in 25.May From my reposync log: 2021/05/26 15:43:05 -04:00 38/54 : salt-minion-3000-20.2.uyuni.x86_64.rpm 2021/08/22 03:47:11 -04:00 36/58 : salt-minion-3000-14.1.uyuni.x86_64.rpm 2021/09/23 13:35:02 -04:00 11/25 : salt-minion-3000-16.2.uyuni.x86_64.rpm Package salt-minion-3000-20.2 which I have installed on my servers have last patch from 5 May And the current salt-minion-3000-16.2 has last patch from 19 Aug. As I see this version - salt-minion-3000-20.2 works ok with Uyuni 2021.09 My previous thread with similar isssue: https://lists.opensuse.org/archives/list/users@lists.uyuni-project.org/thre… Best Regards, -- Cristian Gherman Syasadmin @Reea | cristian.gherman(a)reea.net | www.reea.net

2 2

Some packages for the Server not bing updated during the update to Uyuni 2021.09
by Julio Gonzalez 24 Sep '21

24 Sep '21

Hello, Some users reported that some packages are not being updated on the Server during the update to Uyuni 2021.09. The cause and the workaround is now documented at: https://github.com/uyuni-project/uyuni/issues/4244 The problem is in fact that openSUSE is shipping some SUSE Manager packages, so we filled https://bugzilla.opensuse.org/show_bug.cgi?id=1190851 This announce is now posted at the website, and Twitter, and it will be part of the Release Notes for Uyuni 2021.10 if the problem is still not solved. Sorry about the inconvenience. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Uyuni 2021.09 is released!
by Julio Gonzalez 23 Sep '21

23 Sep '21

We are happy to announce the immediate availability of Uyuni 2021.09 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.09, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Prometheus available for Uyuni Proxy and Retail Branch Server * Ansible available for Uyuni Proxy and Retail Branch Server * AppStreams WebUI improvements * Improve the date time handling on the UI * Support syncing patches with advisory status 'pending' * Virtualization: UEFI support: and virt-tuner templates * spacecmd: allow massive archive and delete actions * Recent cobbler CVEs remediation Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2021.09 As always, we hope you will enjoy Uyuni 2021.09 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Reminder: Uyuni Community Hours this Friday (Sep 24th) at 16.00 CEST
by Julio Gonzalez 21 Sep '21

21 Sep '21

The provisional agenda and the link to the meeting is at: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours If you want to present, remember to send me an e-email, and we'll schedule a slot for you :-) See you on Friday! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

migrate from RMT to Uyuni while patching SLES15 SP2 systems to SP3?
by Heiner Wulfhorst 17 Sep '21

17 Sep '21

Hi list! I was asked to patch our SLES15 SP2 systems to SP3. Currently they are connected to SUSE RMT. Do you think that is a good opportunity to also migrate them into our uyuni? Pros: * I don't have to touch every system twice * am able to do any post-upgrade task faster and more easy as i have "the power of salt" Con: Double risk for incidents Or would you separate that change? -> why? I think the biggest risk lies within SP Upgrade, am i right? Is there any "compatibility check" / dry run i can do on target systems to see how they would be affected by the Upgrade before i run it? Or anything else to minimize risk? What are your thoughts about this? BR Heiner

1 0

Recent errors syncing EL7's EPEL repo
by Simon Avery 08 Sep '21

08 Sep '21

Hi Folks, Anyone else having sync issues with EL7's EPEL repo for the past week or so? I've split out and recreated the repo on Uyuni but it still bombs out when importing one of the errata files. My hunch is this is actually an EPEL issue rather than a Uyuni one, but the pertinent error makes me wonder if this is a new thing that's going to need extra handling in Uyuni? "CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck"" Things were okay a week or so-ish ago and I made no changes on my side, but started getting sync failures late last week, or over the weekend. Thanks Example repo url; https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/7/x86_64/ 2021/09/08 13:35:47 +01:00 Add Patch FEDORA-EPEL-2019-3630e34c31 2021/09/08 13:35:47 +01:00 Add Patch FEDORA-EPEL-2018-81bb24fe00 2021/09/08 13:35:47 +01:00 Add Patch FEDORA-EPEL-2018-6f7d6eeeed 2021/09/08 13:35:47 +01:00 Syncing 4684 new patch(es) to channel. 2021/09/08 13:36:02 +01:00 Unexpected error: <class 'psycopg2.errors.CheckViolation'> 2021/09/08 13:36:02 +01:00 Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 600, in sync self.import_updates(plugin) File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 741, in import_updates processed_updates_count = self.upload_updates(notices) File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 967, in upload_updates importer.run() File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/importLib.py", line 778, in run self.submit() File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/errataImport.py", line 217, in submit dml = self.backend.processErrata(self.batch) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 1011, in processErrata transactional=1) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2151, in __processObjectCollection return self.__processObjectCollection__(objColl, parentTable, childDict, **kwargs) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2322, in __processObjectCollection__ return self.__doDML(dml) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2427, in __doDML self.__doInsert(dml.insert, dml.tables) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2434, in __doInsert self.__doInsertTable(tname, dict) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2449, in __doInsertTable insertObj.query(hash) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backendLib.py", line 453, in query statement.execute_values(self._buildQuery(None), value_list, fetch=False, page_size=10_000) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 166, in execute_values return self._execute_wrapper(self._execute_values, sql, argslist, template, page_size, fetch) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 299, in _execute_wrapper retval = function(*p, **kw) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 353, in _execute_values results = psycopg2.extras.execute_values(self._real_cursor, sql, argslist, template=template, page_size=page_size, fetch=fetch) File "/usr/lib64/python3.6/site-packages/psycopg2/extras.py", line 1289, in execute_values cur.execute(b''.join(parts)) psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (11847, FEDORA-EPEL-2021-aa19cf2506, Product Enhancement Advisory, FEDORA-EPEL-2021-aa19cf2506, 200, Fedora EPEL 7, Rebuild for Knot DNS 3.1, knot-resolver-5.4.1-2.el7, , , 2021-09-06 03:52:14-01, 2021-09-06 03:52:14-01, null, null, 1, null, updates(a)fedoraproject.org<mailto:updates@fedoraproject.org>, 2021-09-08 11:34:52.299009-01, 2021-09-08 11:34:52.299009-01, 2021-09-08 11:34:52.299009-01, 1, pending). Simon Avery Linux Systems Administrator

2 2

Packages not updated after update 2021:06 -> 2021:08
by Bidault, Philippe 06 Sep '21

06 Sep '21

Hi all ¡ I have just updated Uyuni to 2021:08, and have noticed 6 packages not being update because of a vendor change: uyuni:~ # zypper update Loading repository data... Reading installed packages... The following 6 package updates will NOT be installed: mgr-osa-dispatcher python3-mgr-osa-common python3-mgr-osa-dispatcher python3-rhnlib python3-suseRegisterInfo suseRegisterInfo Nothing to do. uyuni:~ # zypper update mgr-osa-dispatcher python3-mgr-osa-common python3-mgr-osa-dispatcher python3-rhnlib python3-suseRegisterInfo suseRegisterInfo Loading repository data... Reading installed packages... There is an update candidate for 'python3-rhnlib' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install python3-rhnlib-4.3.1-1.2.uyuni1.noarch' to install this candidate. There is an update candidate for 'suseRegisterInfo' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install suseRegisterInfo-4.3.1-1.2.uyuni1.noarch' to install this candidate. There is an update candidate for 'mgr-osa-dispatcher' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install mgr-osa-dispatcher-4.3.1-1.2.uyuni1.noarch' to install this candidate. There is an update candidate for 'python3-mgr-osa-common' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install python3-mgr-osa-common-4.3.1-1.2.uyuni1.noarch' to install this candidate. There is an update candidate for 'python3-mgr-osa-dispatcher' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install python3-mgr-osa-dispatcher-4.3.1-1.2.uyuni1.noarch' to install this candidate. There is an update candidate for 'python3-suseRegisterInfo' from vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the current vendor is 'SUSE LLC https://www.suse.com/'. Use 'zypper install python3-suseRegisterInfo-4.3.1-1.2.uyuni1.noarch' to install this candidate. Resolving package dependencies... Nothing to do. Do I have to change vendor for them and force the update or do I have to keep them like that ? Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.getronics.com> [cid:3-lines_7512e235-163a-4853-8e4f-b0d4fc62ce73.png]<https://getronics.com/> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

2 4

Problems when using server-migrator.sh to get from 2021.02 to .08
by Heiner Wulfhorst 02 Sep '21

02 Sep '21

Hi List, first i ran zypper ref and zypper up susemanager which said " *No update candidate*, *The highest available version is already installed* , Nothing to do ": # *zypper ref* Repository 'Non-OSS Repository' is up to date. Repository 'Main Repository' is up to date. Repository 'Main Update Repository' is up to date. Repository 'Update Repository (Non-Oss)' is up to date. Repository 'uyuni-server-2021-02' is up to date. *All repositories have been refreshed.* # *zypper up susemanager* Loading repository data... Reading installed packages... *No update candidate for 'susemanager-4.2.8-1.1.uyuni.x86_64'. The highest available version is already installed.* Resolving package dependencies... *Nothing to do.* But then i got this error when running /usr/lib/susemanager/bin/ server-migrator.sh (for full output see attachment): Computing distribution upgrade... 5 Problems: Problem: nothing provides 'postgresql13' needed by the to be installed spacewalk-postgresql-4.3.1-1.2.uyuni1.noarch Problem: nothing provides 'libcrypt.so.1(XCRYPT_2.0)(64bit)' needed by the to be installed jabberd-sqlite-2.7.0-5.5.uyuni1.x86_64 Problem: nothing provides 'product(Leap) >= 15.3' needed by the to be installed product:Uyuni-Server-2021.08-0.x86_64 Problem: nothing provides 'product(Leap) >= 15.3' needed by the to be installed product:Uyuni-Server-2021.08-0.x86_64 Problem: nothing provides 'postgresql13' needed by the to be installed spacewalk-postgresql-4.3.1-1.2.uyuni1.noarch Problem: nothing provides 'postgresql13' needed by the to be installed spacewalk-postgresql-4.3.1-1.2.uyuni1.noarch Solution 1: Following actions will be done: deinstallation of spacewalk-postgresql-4.2.3-1.2.uyuni.noarch deinstallation of spacewalk-common-4.2.3-1.2.uyuni.noarch Solution 2: keep obsolete spacewalk-postgresql-4.2.3-1.2.uyuni.noarch Solution 3: break spacewalk-postgresql-4.3.1-1.2.uyuni1.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c): c =================================================================== If you did not yet migrate the database to postgresql12, do so now by running /usr/lib/susemanager/bin/pg-migrate-10-to-12.sh Reboot system afterwards. =================================================================== After that error i ran zypper ref and zypper up susemanager again, which (whyever) then found this update for susemanager: # zypper ref Repository 'Non-OSS Repository' is up to date. Repository 'Main Repository' is up to date. Repository 'Main Update Repository' is up to date. Repository 'Update Repository (Non-Oss)' is up to date. Repository 'Uyuni Server Stable' is up to date. All repositories have been refreshed. # zypper up susemanager Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: susemanager 1 package to upgrade. Overall download size: 83.8 KiB. Already cached: 0 B. After the operation, additional 14.0 KiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package susemanager-4.3.2-1.1.uyuni1.x86_64 (1/1), 83.8 KiB (197.6 KiB unpacked) Retrieving: susemanager-4.3.2-1.1.uyuni1.x86_64.rpm .............................................................................................[done] Checking for file conflicts: ....................................................................................................................[done] (1/1) Installing: susemanager-4.3.2-1.1.uyuni1.x86_64 ...........................................................................................[done] Executing %posttrans scripts ....................................................................................................................[done] After that i ran /usr/lib/susemanager/bin/server-migrator.sh again which then returned no more errors/problems and began to upgrade my system: <...> Executing %posttrans scripts ....................................................................................................................[done] Update notifications were received from the following packages: susemanager-schema-4.3.1-1.2.uyuni1.noarch (/var/adm/update-messages/susemanager-schema-4.3.1-1.2.uyuni1) View the notifications now? [y/n] (n): n There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. Since the last system boot core libraries or services have been updated. Reboot is suggested to ensure that your system benefits from these updates. =================================================================== If you did not yet migrate the database to postgresql13, do so now by running /usr/lib/susemanager/bin/pg-migrate-x-to-y.sh Reboot system afterwards. =================================================================== What went wrong? Is there an error in the upgrade guide ( https://www.uyuni-project.org/doc/2021.08/uyuni_upgrade_guide.pdf)? Looks like at first try it is using leap/15.2 repos and at second try 15.3... BR, Heiner

2 4

Uyuni Community Hours
by Julio Gonzalez 27 Aug '21

27 Aug '21

Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours Uyuni Community Hours are held every last Friday of the month, at 4 PEM CET/CEST. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A NOTE: This schedule overrides the previous one and does not request attendance confirmation. ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZjZlMWI0OTctNGMxZi00…> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=ef7551ee-a699-477f-…> ________________________________________________________________________________

1 0

Re: [EXTERNAL] Re: Error after upgrading to latest version
by Allen Beddingfield 25 Aug '21

25 Aug '21

I was finally able to get the time to complete this process. Your instructions were great, and worked perfectly. I was able to get upgraded to the latest version, with the May release as an interim - as you suggested. Thanks! Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu <https://www.ua.edu/> ________________________________ From: Julio Gonzalez Sent: Friday, July 23, 2021 12:22 PM To: uyuni-users(a)opensuse.org; users(a)lists.uyuni-project.org Cc: Allen Beddingfield Subject: [EXTERNAL] Re: Error after upgrading to latest version On viernes, 23 de julio de 2021 16:44:17 (CEST) Allen Beddingfield wrote: > This is the output of "zypper dup". > > Loading repository data... > Reading installed packages... > Warning: You are about to do a distribution upgrade with all enabled > repositories. Make sure these repositories are compatible before you > continue. See 'man zypper' for more information about this command. > Computing distribution upgrade... > Nothing to do. > > I have a VM snapshot that I can revert. What I can't figure out how to do > is to upgrade only to 2020.07, instead of the current version, as required. > What would be the process to get to that intermediate version? I could > revert the snapshot, upgrade to 2020.07, then to the current version, if I > knew the steps to upgrade to that intermediate version. Thanks! > Allen B. There is a way, but unsupported. So I will do my best, but can tell you: "yeah, this will work for sure!" :-) We have Snapshots for the different versions, they are only used for reproducing migration bugs. The last one for the server on top of Leap 15.2 is at: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Snapsh… So that means you can use a special procedure to migat to 2021.05 first: MIGRATING TO 2021.05 =================== # zypper ar https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Snapsh… uyuni-2021.05 # zypper in susemanager At this point you will have the migration script that was used to migrate from Uyuni on top Leap 15.1 to Uyuni on top of Leap 15.2 DO NOT RUN IT YET!!!!!! Edit the migration script, with vim or other editor: # vim /usr/lib/susemanager/bin/server-migrator.sh Change the line: zypper ar -n "Uyuni Server Stable" https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… uyuni-server-stable To: zypper ar -n "Uyuni Server 2021.05" https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Snapsh… uyuni-2021.05 Run the script: # /usr/lib/susemanager/bin/server-migrator.sh This should take your system to openSUSE Leap 15.2 and Uyuni 2021.05, in terms of packaging. Run /usr/lib/susemanager/bin/pg-migrate-10-to-12.sh as instructed. DO NOT REBOOT YET. Check the current release notes for 2021.06 (yes), and run any manual steps documented between 2020.09 and 2021.05 (both included). Most of them could probably be skipped since they are about changing the vendor to openSUSE (and that should be done by server-migrator) but run them anyway, just in case. After all manual steps are executed, you can reboot. Check that the server is able to start, that the WebUI is loading, and then run some smoke tests, just in case (for example run a salt remote command against a couple of minions). If everything is working at this point, then you can migrate to 2021.06 MIGRATING TO 2021.06 =================== Add the Stable repository again: # zypper ar -n "Uyuni Server Stable" https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… uyuni-server-stable And run the regular procedure for the migration from 2021.05 to 2021.06 So as you can see, this is doing an upgrade in two steps: 2020.07 to 2021.05 first (Leap 15.3 to Leap 15.2) 2021.05 to 2021.06 then (Leap 15.2 to Leap 15.3) I never tried this, but should work :-) > > -- > Allen Beddingfield > Systems Engineer > Office of Information Technology > The University of Alabama > Office 205-348-2251 > allen(a)ua.edu > <https://www.ua.edu/> > > ________________________________ > From: Julio Gonzalez > Sent: Friday, July 23, 2021 9:40 AM > To: uyuni-users(a)opensuse.org; users(a)lists.uyuni-project.org > Cc: Allen Beddingfield > Subject: [EXTERNAL] Re: Error after upgrading to latest version > > On viernes, 23 de julio de 2021 16:31:16 (CEST) Allen Beddingfield wrote: > > I have three Uyuni servers that I've updated to the latest version. The > > first two went well. The third fails on the startup of Tomcat. This one > > was from an older revision. The other two were running an Uyuni version > > at > > Leap 15.2, but the one with the problem was old enough to be on 15.1. > > Not supported. That's why the release notes say: > > "You need at least Uyuni 2020.07 already installed to perform the upgrade." > > As that's the first version on top of openSUSE Leap 15.1 > > Let's see if we can help, but no promises :-) > > > I did > > "zypper up susemanager" > > Ran server-migrator.sh > > Then ran pg-migrate-10-to-13.sh > > All completed with no errors. > > > > On restart, there is an issue with Tomcat. This appears in the most > > recent > > catalina log: > > > > 23-Jul-2021 09:23:03.806 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Server version name: > > Apache Tomcat/9.0.36 23-Jul-2021 09:23:03.822 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Server built: > > Mar 17 2021 12:00:00 UTC 23-Jul-2021 09:23:03.822 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Server version > > number: 9.0.36.0 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log OS Name: > > Linux 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log OS Version: > > 5.3.18-59.16-default 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Architecture: > > amd64 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Java Home: > > /usr/lib64/jvm/java-11-openjdk-11 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log JVM Version: > > 11.0.11+9-suse-3.56.1-x8664 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: > > Oracle Corporation 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: > > /usr/share/tomcat 23-Jul-2021 09:23:03.823 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: > > /usr/share/tomcat 23-Jul-2021 09:23:03.826 INFO [main] > > > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -ea 23-Jul-2021 09:23:03.826 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Xms256m 23-Jul-2021 09:23:03.826 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Xmx1G 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Djava.awt.headless=true 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: > > -Dorg.xml.sax.driver=com.redhat.rhn.frontend.xmlrpc.util.RhnSAXParser > > 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 > > 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -XX:MaxNewSize=256 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -XX:-UseConcMarkSweepGC 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Dnet.sf.ehcache.skipUpdateCheck=true 23-Jul-2021 09:23:03.827 > > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command > > line argument: --add-modules=java.annotation,com.sun.xml.bind 23-Jul-2021 > > 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: > > --add-exports=java.annotation/javax.annotation.security=ALL-UNNAMED > > 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: > > --add-opens=java.annotation/javax.annotation.security=ALL-UNNAMED > > 23-Jul-2021 09:23:03.827 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Dcatalina.base=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Dcatalina.home=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Djava.endorsed.dirs= 23-Jul-2021 09:23:03.828 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: -Djava.io.tmpdir=/var/cache/tomcat/temp 23-Jul-2021 09:23:03.828 > > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command > > line argument: > > -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties > > 23-Jul-2021 09:23:03.831 INFO [main] > > org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > 23-Jul-2021 09:23:03.832 INFO [main] > > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache > > Tomcat Native library [1.2.23] using APR version [1.6.3]. 23-Jul-2021 > > 09:23:03.832 INFO [main] > > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR > > capabilities: IPv6 [true], sendfile [true], accept filters [false], random > > [true]. 23-Jul-2021 09:23:03.832 INFO [main] > > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL > > configuration: useAprConnector [false], useOpenSSL [true] 23-Jul-2021 > > 09:23:03.834 INFO [main] > > org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL > > successfully initialized [OpenSSL 1.1.1d 10 Sep 2019] 23-Jul-2021 > > 09:23:05.159 INFO [main] org.apache.coyote.AbstractProtocol.init > > Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 > > 09:23:05.280 INFO [main] org.apache.coyote.AbstractProtocol.init > > Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 > > 09:23:05.305 INFO [main] org.apache.coyote.AbstractProtocol.init > > Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 23-Jul-2021 > > 09:23:05.313 INFO [main] org.apache.catalina.startup.Catalina.load Server > > initialization in [1,874] milliseconds 23-Jul-2021 09:23:05.631 INFO > > [main] > > org.apache.catalina.core.StandardService.startInternal Starting service > > [Catalina] 23-Jul-2021 09:23:05.631 INFO [main] > > org.apache.catalina.core.StandardEngine.startInternal Starting Servlet > > engine: [Apache Tomcat/9.0.36] 23-Jul-2021 09:23:05.680 INFO [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Deploying web > > application directory [/srv/tomcat/webapps/rhn] 23-Jul-2021 09:23:07.488 > > SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error > > deploying web application directory [/srv/tomcat/webapps/rhn] > > java.lang.IllegalStateException: Error starting child > > > > at > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java > > : > > 720) at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at > > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:113 > > 2 > > ) at > > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java > > : > > 1865) at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja > > v > > a:515) at > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecuto > > r > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExec > > u > > torService.java:118) at > > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1 > > 0 > > 44) at > > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at > > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at > > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) > > at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.ja > > v > > a:123) at > > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java > > : > > 423) at > > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:93 > > 6 > > ) at > > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java: > > 1 > > 384) at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java: > > 1 > > 374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > > at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecuto > > r > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExec > > u > > torService.java:140) at > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:90 > > 9 > > ) at > > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java: > > 2 > > 62) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.StandardService.startInternal(StandardService.jav > > a > > > > :421) at > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at > > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java: > > 9 > > 30) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMetho > > d > > AccessorImpl.java:62) at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegat > > i > > ngMethodAccessorImpl.java:43) at > > java.base/java.lang.reflect.Method.invoke(Method.java:566) at > > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at > > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: > > org.apache.catalina.LifecycleException: Failed to start component > > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] > > at > > org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBa > > s > > e.java:440) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java > > : > > 717) ... 37 more > > > > Caused by: java.lang.NullPointerException > > > > at > > > > org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner. > > j > > ava:382) at > > org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.jav > > a > > > > :195) at > > > > org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(Conte > > x > > tConfig.java:1971) at > > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:112 > > 9 > > ) at > > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.jav > > a > > > > :775) > > : > > at > > > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.jav > > a > > > > :301) at > > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.ja > > v > > a:123) at > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.jav > > a > > > > :5044) at > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... > > 38 > > more > > 23-Jul-2021 09:23:07.492 INFO [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web > > application directory [/srv/tomcat/webapps/rhn] has finished in [1,813] ms > > 23-Jul-2021 09:23:07.524 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 09:23:07.752 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 09:23:07.880 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["http-nio-127.0.0.1-8080"] 23-Jul-2021 09:23:07.913 INFO [main] > > org.apache.catalina.startup.Catalina.start Server startup in [2,600] > > milliseconds > > Can you provide the output of: > > `zypper dup`? > > I wonder if some of the Java dependencies didn't change to come from Leap. > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni > jgonzalez(a)suse.com -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

how to upload custom rpms to uyuni
by Heiner Wulfhorst 24 Aug '21

24 Aug '21

Hi list, my customer needs following RPMs on his systems: - oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm - oracle-instantclient12.2-sqlplus-12.2.0.1.0-1.x86_64.rpm Is there any (maybe hidden) form in Web UI to upload RPMs into Uyuni? Or can i upload them with scp into any special path in uyuni server's filesystem to then assign them to a channel? In uyuni reference manual i found following information: "To create a new channel, click the Create Channel link. Select the appropriate options for the newchannel, including base architecture and GPG options, then click [Create Channel]. Note that a channel created in this manner is blank, containing no packages. You must either *upload software packages* or add packages from other repositories. You may also choose to include patches in your custom channel." This makes me believe there must be a way to upload any rpm into uyuni, but i (so far) couldn't find it. I created a new (empty) software channel but only find a form to select already existing packages into that channel. Thx, BR, Heiner

4 3

Use Salt-Api externally from Uyuni
by Jesse Harris 18 Aug '21

18 Aug '21

Good day fellow uyuni users. I would like to leverage the salt-api that is used by uyuni. Currently the uyuni API does not have a method to list, accept or deny a salt-key. But the salt api does. I would like to do something like is mentioned here: https://stackoverflow.com/questions/19067341/using-salt-api-to-call-salt-ke… I have inspected the salt-api that is setup on uyuni and it is currently set up to only listen on the loopback interface which is easy to change. The next problem I have seems to be that the file based admin authentication does not match the admin account that I used to set up uyuni. I'm wondering if it is stored somewhere in the database for internal communication with the salt-api? Is there a safe way to get/set the password without disrupting internal comms with the api? Or is there a way to set up a second salt-api on the same box? I'm not a saltstack guru so I would love it if someone could point me in the right direction. Thanks -Jesse

2 1

Uyuni 2021.08 is released!
by Julio Gonzalez 17 Aug '21

17 Aug '21

We are happy to announce the immediate availability of Uyuni 2021.08 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.08, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Rocky Linux 8 as client * Ansible Playbooks test mode * Kiwi parameters for OS Image profiles * Fixes for AArch64 hosts, including virtualization * Virtual Machines and UEFI * Pacemaker support for KVM and Xen virtual machines * New CLM Filter Template * OpenSCAP Audit * Logs for Salt SSH clients * Tech-preview: Inter-Server Synchronization version 2 * Monitoring: prometheus and grafana updates Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2021.08 As always, we hope you will enjoy Uyuni 2021.08 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

3 2

Problems using Autoinstall Distro
by Heiner Wulfhorst 13 Aug '21

13 Aug '21

Hi List, i am trying to autoinstall SLES15 systems but my autoinstall distribution seems to have problems. After booting (PXE) i get a gray tui box on blue background saying " Please make sure your installation medium is available". The URL in "install" Kernel Parameter of the distro was generated automatically, i did not change it. When i try to accessit with browser i get an error message: Internal Server Error The server experienced a problem which prevented your request from being filled out. It may not be possible to execute this action at this time. Please help us correct this problem by contacting us with details of how you received this message. URLs of other Distros can be accessed w/o errors. I deleted and re-created the Distro, rebuilt the (staged/contentlifecycle) Repo, both without luck. Any hint is welcome! Thanks! Heiner PGP: C5160402C3F27014(a)keys.gnupg.net <http://keys.gnupg.net/pks/lookup?search=0xC5160402C3F27014&fingerprint=on&o…>

2 3

notify about staged channels that need to be synced to distribute (security) patches
by Heiner Wulfhorst 12 Aug '21

12 Aug '21

Hi List, We use Content Lifecycle Management and have our systems in staged channels. To be informed about new patches for those systems we have to first sync the channels. How can we get this notification *before *syncing, so that we know when we have to sync? Or is it best to have one of each systems unstaged so we get to know about those updates? (i don't think so) Thanks, BR Heiner

3 3

Uyuni Community Hours
by Julio Gonzalez 12 Aug '21

12 Aug '21

Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours NB: Uyuni Community Hours are held every last Friday of the month, at 4 PEM CET/CEST. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZjZlMWI0OTctNGMxZi00…> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=ef7551ee-a699-477f-…> ________________________________________________________________________________

1 0

Re: [EXTERNAL] Re: Error after upgrading to latest version
by Allen Beddingfield 23 Jul '21

23 Jul '21

This is the output of "zypper dup". Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... Nothing to do. I have a VM snapshot that I can revert. What I can't figure out how to do is to upgrade only to 2020.07, instead of the current version, as required. What would be the process to get to that intermediate version? I could revert the snapshot, upgrade to 2020.07, then to the current version, if I knew the steps to upgrade to that intermediate version. Thanks! Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu <https://www.ua.edu/> ________________________________ From: Julio Gonzalez Sent: Friday, July 23, 2021 9:40 AM To: uyuni-users(a)opensuse.org; users(a)lists.uyuni-project.org Cc: Allen Beddingfield Subject: [EXTERNAL] Re: Error after upgrading to latest version On viernes, 23 de julio de 2021 16:31:16 (CEST) Allen Beddingfield wrote: > I have three Uyuni servers that I've updated to the latest version. The > first two went well. The third fails on the startup of Tomcat. This one > was from an older revision. The other two were running an Uyuni version at > Leap 15.2, but the one with the problem was old enough to be on 15.1. Not supported. That's why the release notes say: "You need at least Uyuni 2020.07 already installed to perform the upgrade." As that's the first version on top of openSUSE Leap 15.1 Let's see if we can help, but no promises :-) > I did > "zypper up susemanager" > Ran server-migrator.sh > Then ran pg-migrate-10-to-13.sh > All completed with no errors. > > On restart, there is an issue with Tomcat. This appears in the most recent > catalina log: > > 23-Jul-2021 09:23:03.806 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Server version name: > Apache Tomcat/9.0.36 23-Jul-2021 09:23:03.822 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Server built: > Mar 17 2021 12:00:00 UTC 23-Jul-2021 09:23:03.822 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Server version > number: 9.0.36.0 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log OS Name: > Linux 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log OS Version: > 5.3.18-59.16-default 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Architecture: > amd64 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Java Home: > /usr/lib64/jvm/java-11-openjdk-11 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log JVM Version: > 11.0.11+9-suse-3.56.1-x8664 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: > Oracle Corporation 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: > /usr/share/tomcat 23-Jul-2021 09:23:03.823 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: > /usr/share/tomcat 23-Jul-2021 09:23:03.826 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -ea 23-Jul-2021 09:23:03.826 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Xms256m 23-Jul-2021 09:23:03.826 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Xmx1G 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Djava.awt.headless=true 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: > -Dorg.xml.sax.driver=com.redhat.rhn.frontend.xmlrpc.util.RhnSAXParser > 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 > 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -XX:MaxNewSize=256 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -XX:-UseConcMarkSweepGC 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Dnet.sf.ehcache.skipUpdateCheck=true 23-Jul-2021 09:23:03.827 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command > line argument: --add-modules=java.annotation,com.sun.xml.bind 23-Jul-2021 > 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: > --add-exports=java.annotation/javax.annotation.security=ALL-UNNAMED > 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: --add-opens=java.annotation/javax.annotation.security=ALL-UNNAMED > 23-Jul-2021 09:23:03.827 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Dcatalina.base=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Dcatalina.home=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Djava.endorsed.dirs= 23-Jul-2021 09:23:03.828 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Djava.io.tmpdir=/var/cache/tomcat/temp 23-Jul-2021 09:23:03.828 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command > line argument: > -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties > 23-Jul-2021 09:23:03.831 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > 23-Jul-2021 09:23:03.832 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache > Tomcat Native library [1.2.23] using APR version [1.6.3]. 23-Jul-2021 > 09:23:03.832 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR > capabilities: IPv6 [true], sendfile [true], accept filters [false], random > [true]. 23-Jul-2021 09:23:03.832 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL > configuration: useAprConnector [false], useOpenSSL [true] 23-Jul-2021 > 09:23:03.834 INFO [main] > org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL > successfully initialized [OpenSSL 1.1.1d 10 Sep 2019] 23-Jul-2021 > 09:23:05.159 INFO [main] org.apache.coyote.AbstractProtocol.init > Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 > 09:23:05.280 INFO [main] org.apache.coyote.AbstractProtocol.init > Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 > 09:23:05.305 INFO [main] org.apache.coyote.AbstractProtocol.init > Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 23-Jul-2021 > 09:23:05.313 INFO [main] org.apache.catalina.startup.Catalina.load Server > initialization in [1,874] milliseconds 23-Jul-2021 09:23:05.631 INFO [main] > org.apache.catalina.core.StandardService.startInternal Starting service > [Catalina] 23-Jul-2021 09:23:05.631 INFO [main] > org.apache.catalina.core.StandardEngine.startInternal Starting Servlet > engine: [Apache Tomcat/9.0.36] 23-Jul-2021 09:23:05.680 INFO [main] > org.apache.catalina.startup.HostConfig.deployDirectory Deploying web > application directory [/srv/tomcat/webapps/rhn] 23-Jul-2021 09:23:07.488 > SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error > deploying web application directory [/srv/tomcat/webapps/rhn] > java.lang.IllegalStateException: Error starting child > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > 720) at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132 > ) at > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java: > 1865) at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.jav > a:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutor > Service.java:75) at > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecu > torService.java:118) at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:10 > 44) at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.jav > a:123) at > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java: > 423) at > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936 > ) at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1 > 384) at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1 > 374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutor > Service.java:75) at > java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecu > torService.java:140) at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909 > ) at > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:2 > 62) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardService.startInternal(StandardService.java > :421) at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:9 > 30) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > AccessorImpl.java:62) at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegati > ngMethodAccessorImpl.java:43) at > java.base/java.lang.reflect.Method.invoke(Method.java:566) at > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: > org.apache.catalina.LifecycleException: Failed to start component > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at > org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBas > e.java:440) at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > 717) ... 37 more > Caused by: java.lang.NullPointerException > at > org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.j > ava:382) at > org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java > :195) at > org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(Contex > tConfig.java:1971) at > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129 > ) at > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java > :775) > > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java > :301) at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.jav > a:123) at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java > :5044) at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 > more > 23-Jul-2021 09:23:07.492 INFO [main] > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web > application directory [/srv/tomcat/webapps/rhn] has finished in [1,813] ms > 23-Jul-2021 09:23:07.524 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 09:23:07.752 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 09:23:07.880 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["http-nio-127.0.0.1-8080"] 23-Jul-2021 09:23:07.913 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in [2,600] > milliseconds Can you provide the output of: `zypper dup`? I wonder if some of the Java dependencies didn't change to come from Leap. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Error after upgrading to latest version
by Allen Beddingfield 23 Jul '21

23 Jul '21

I have three Uyuni servers that I've updated to the latest version. The first two went well. The third fails on the startup of Tomcat. This one was from an older revision. The other two were running an Uyuni version at Leap 15.2, but the one with the problem was old enough to be on 15.1. I did "zypper up susemanager" Ran server-migrator.sh Then ran pg-migrate-10-to-13.sh All completed with no errors. On restart, there is an issue with Tomcat. This appears in the most recent catalina log: 23-Jul-2021 09:23:03.806 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.36 23-Jul-2021 09:23:03.822 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Mar 17 2021 12:00:00 UTC 23-Jul-2021 09:23:03.822 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.36.0 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.3.18-59.16-default 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib64/jvm/java-11-openjdk-11 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.11+9-suse-3.56.1-x8664 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /usr/share/tomcat 23-Jul-2021 09:23:03.823 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat 23-Jul-2021 09:23:03.826 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -ea 23-Jul-2021 09:23:03.826 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms256m 23-Jul-2021 09:23:03.826 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx1G 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.xml.sax.driver=com.redhat.rhn.frontend.xmlrpc.util.RhnSAXParser 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:MaxNewSize=256 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:-UseConcMarkSweepGC 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dnet.sf.ehcache.skipUpdateCheck=true 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-modules=java.annotation,com.sun.xml.bind 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-exports=java.annotation/javax.annotation.security=ALL-UNNAMED 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.annotation/javax.annotation.security=ALL-UNNAMED 23-Jul-2021 09:23:03.827 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/share/tomcat 23-Jul-2021 09:23:03.828 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs= 23-Jul-2021 09:23:03.828 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/var/cache/tomcat/temp 23-Jul-2021 09:23:03.828 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties 23-Jul-2021 09:23:03.831 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 23-Jul-2021 09:23:03.832 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.23] using APR version [1.6.3]. 23-Jul-2021 09:23:03.832 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 23-Jul-2021 09:23:03.832 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] 23-Jul-2021 09:23:03.834 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1d 10 Sep 2019] 23-Jul-2021 09:23:05.159 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 09:23:05.280 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 09:23:05.305 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 23-Jul-2021 09:23:05.313 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [1,874] milliseconds 23-Jul-2021 09:23:05.631 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 23-Jul-2021 09:23:05.631 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.36] 23-Jul-2021 09:23:05.680 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/srv/tomcat/webapps/rhn] 23-Jul-2021 09:23:07.488 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/srv/tomcat/webapps/rhn] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1865) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1044) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) ... 37 more Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:382) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:195) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1971) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:775) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5044) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more 23-Jul-2021 09:23:07.492 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [1,813] ms 23-Jul-2021 09:23:07.524 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 23-Jul-2021 09:23:07.752 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 23-Jul-2021 09:23:07.880 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 23-Jul-2021 09:23:07.913 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [2,600] milliseconds -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

2 1

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 23 Jul '21

23 Jul '21

Hi Victor, I never have heard of this rule. At least I would expect an hint in the logs that salt versions are incompatible if there are dependencies. Regards, Tobias. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Freitag, 23. Juli 2021 15:19 Hi Tobias. I suppose your server running salt-master 3000 before. It's not possible to handle newer minion version with old master. Victor

1 0

AW: AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 23 Jul '21

23 Jul '21

Hi Viktor, meanwhile I upgraded our Uyuni server (2020.11 -> 2021.06) and now salt 3002.2 works on all our SLES15-SP2 clients. Actually I had to repeat the patch because the first attempt to patch via Uyuni failed and the log of the respective salt-minion showed the following entries: 2021-07-23 13:24:44,487 [salt.loaded.int.module.cmdmod:836 ][ERROR ][18655] Command 'systemd-run' failed with return code: 103 2021-07-23 13:24:44,488 [salt.loaded.int.module.cmdmod:838 ][ERROR ][18655] stdout: Loading repository data... Reading installed packages... Patch 'SUSE-SLE-Module-Server-Applications-15-SP2-2021-2106-1' is not needed. Resolving package dependencies... The following NEW patch is going to be installed: SUSE-SLE-Module-Basesystem-15-SP2-2021-2106 The following 3 packages are going to be upgraded: python3-salt salt salt-minion 3 packages to upgrade. Overall download size: 8.7 MiB. Already cached: 0 B. After the operation, additional 699.1 KiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package salt-3002.2-37.1.x86_64 (1/3), 175.9 KiB ( 49.9 KiB unpacked) Retrieving: salt-3002.2-37.1.x86_64.rpm [done] Retrieving package python3-salt-3002.2-37.1.x86_64 (2/3), 8.4 MiB ( 45.3 MiB unpacked) Retrieving: python3-salt-3002.2-37.1.x86_64.rpm [.done (1.6 MiB/s)] Retrieving package salt-minion-3002.2-37.1.x86_64 (3/3), 170.8 KiB ( 41.7 KiB unpacked) Retrieving: salt-minion-3002.2-37.1.x86_64.rpm [done] Checking for file conflicts: [......done] (1/3) Installing: salt-3002.2-37.1.x86_64 [...............done] (2/3) Installing: python3-salt-3002.2-37.1.x86_64 [...................done] (3/3) Installing: salt-minion-3002.2-37.1.x86_64 [..........done] Executing %posttrans script 'python3-salt-3002.2-37.1.x86_64.rpm' [....done] Warning: One of the installed patches affects the package manager itself. Run this command once more to install any other needed patches. 2021-07-23 13:24:44,488 [salt.loaded.int.module.cmdmod:840 ][ERROR ][18655] stderr: Running scope as unit: run-rb22f00149355472aaa170fd01ea9b47b.scope 2021-07-23 13:24:44,488 [salt.loaded.int.module.cmdmod:842 ][ERROR ][18655] retcode: 103 2021-07-23 13:24:51,647 [salt.state :323 ][ERROR ][18655] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 1999, in call # duration in milliseconds.microseconds File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2036, in wrapper # improperly loaded File "/usr/lib/python3.6/site-packages/salt/states/pkg.py", line 2368, in patch_installed targets = _find_advisory_targets(name, advisory_ids, **kwargs) File "/usr/lib/python3.6/site-packages/salt/states/pkg.py", line 411, in _find_advisory_targets cur_patches = __salt__["pkg.list_installed_patches"](**kwargs) File "/usr/lib/python3.6/site-packages/salt/modules/zypperpkg.py", line 2939, in list_installed_patches return _get_patches(installed_only=True, root=root) File "/usr/lib/python3.6/site-packages/salt/modules/zypperpkg.py", line 2885, in _get_patches .nolock.xml.call("se", "-t", "patch") File "/usr/lib/python3.6/site-packages/salt/modules/zypperpkg.py", line 355, in __call self.__call_result = __salt__["cmd.run_all"](cmd, **kwargs) File "/usr/lib/python3.6/site-packages/salt/loader.py", line 1269, in __getitem__ File "/usr/lib/python3.6/site-packages/salt/utils/lazy.py", line 111, in __getitem__ KeyError: 'cmd.run_all' Repeating the job at Uyuni was successful. Thanks for your efforts! Regards, Tobias. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 19. Juli 2021 15:44 It's very confusing. Just tried `salt-call state.apply util.systeminfo` on my testing SLE15SP2 system with salt-minion-3002.2-37.1 and it works fine. But in your case it seems `salt-call state.apply util.systeminfo` will fail. Please check if it's failing. If so, please collect the output of `salt-call -l trace state.apply util.systeminfo` and send me as a file. Thanks for advance. Regards, Victor

2 1

Issue while upgrading Uyuni proxies to 2021.06
by Bidault, Philippe 22 Jul '21

22 Jul '21

Hi all ¡! I am stuck with the upgrade of Uyuni 2021.06 (from Uyuni 2021.04). I have followed the steps there https://www.uyuni-project.org/uyuni-docs/en/uyuni/upgrade/proxy-uyuni.html, however the step 8 (Click Software Packages Upgrade, and select all the packages to be updated on the proxy, and then apply the selection.) failed with the following errors (seen on the GUI, Schedule -> Failed Actions): Refreshing service 'spacewalk'. Loading repository data... Reading installed packages... Resolving package dependencies... 9 Problems: Problem: nothing provides kmod = 25-6.7.1 needed by kmod-compat-2 [...] s systemd-bash-completion provided by systemd-bash-completion-234-24.90.1.noarch Problem: product:openSUSE-Addon-NonOss-15.2-0.x86_64 requires product(openSUSE-Addon-NonOss) = 15.2-0, but this requirement cannot be provided Problem: product:Uyuni-Proxy-2021.04-0.x86_64 requires product(openSUSE) >= 15.2, but this requirement cannot be provided Problem: product:Leap-15.3-1.x86_64 requires product(Leap) = 15.3-1, but this requirement cannot be provided Problem: patterns-uyuni_proxy-2021.04-1.2.uyuni.x86_64 requires Uyuni-Proxy-release, but this requirement cannot be provided Problem: nothing provides kmod = 25-6.7.1 needed by kmod-compat-25-6.7.1.x86_64 Solution 1: do not install kmod-compat-25-6.7.1.x86_64 Solution 2: break kmod-compat-25-6.7.1.x86_64 by ignoring some of its dependencies Removing kmon-compat no really seems to be an option, to many dependencies: # zypper rm kmod-compat Reading installed packages... Resolving package dependencies... The following 22 packages are going to be REMOVED: dracut kmod-compat libbd_mdraid2 lvm2 mdadm os-prober patterns-base-apparmor patterns-base-apparmor_opt patterns-base-base patterns-base-enhanced_base patterns-base-minimal_base patterns-uyuni_proxy plymouth plymouth-branding-openSUSE plymouth-dracut plymouth-scripts supportutils supportutils-plugin-salt supportutils-plugin-susemanager-client supportutils-plugin-susemanager-proxy udisks2 udisks2-lang The following 6 patterns are going to be REMOVED: apparmor apparmor_opt base enhanced_base minimal_base uyuni_proxy 22 packages to remove. After the operation, 8.7 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n Strangely, can't see kmod-compat installed on the Uyuni server, so not sure where it is coming from. Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.getronics.com> [cid:3-lines_7512e235-163a-4853-8e4f-b0d4fc62ce73.png]<https://getronics.com/> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

2 5

Missing Repositories for Open Enterprise Server 2018 SP3
by Thomas Weis 22 Jul '21

22 Jul '21

Hello there, SP3 for Open Enterprise Server 2018 has been released for some time. We receive the repos for OES2018 SP1 and OES2018 SP2 via the subscriptions in the SCC, but not the repos for OES2018 SP3. Is there a time when the repositories are available or is that not planned? Many thanks to the project team! Regards Thomas

3 5

Error while syncing EPEL 8 repository
by jordi＠priscoelectronica.com 22 Jul '21

22 Jul '21

Hello, Since nine days ago I'm observing an error while syncing EPEL 8 repository. This error has appeared on different days with different instances of the same kind (rhnerrata pgsql table constraint violation): 2021/07/06 -> Initial EPEL 8 sync, no errors. All errata in. 2021/07/11 -> first error appears psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (8678, FEDORA-EPEL-2021-360b258add, Product Enhancement Advisory, FEDORA-EPEL-2021-360b258add, 200, pending, Fedora EPEL 8, Initial package , rnnoise-0-0.3.20210312git7f449bf.el8, , , 2021-07-09 07:48:35-02, 2021-07-09 07:48:52-02, null, null, 1, null, updates(a)fedoraproject.org, 2021-07-10 22:02:40.365219-02, 2021-07-10 22:02:40.365219-02, 2021-07- 10 22:02:40.365219-02, null). 2021/07/19 -> the same with different data psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (8715, FEDORA-EPEL-2021-41eeae14d9, Product Enhancement Advisory, FEDORA-EPEL-2021-41eeae14d9, 200, pending, Fedora EPEL 8, Initial package, python-nagiosplugin-1.3.2- 1.el8, , , 2021-07-18 17:55:58-02, 2021-07-18 17:55:58-02, null, null, 1, null, updates(a)fedoraproject.org, 2021-07-19 04:22:00.854661- 02, 2021-07-19 04:22:00.854661-02, 2021-07-19 04:22:00.854661-02, null). 2021/07/21 -> third occurrence, this time repeating "python- nagiosplugin" instance. psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (8735, FEDORA-EPEL-2021-41eeae14d9, Product Enhancement Advisory, FEDORA-EPEL-2021-41eeae14d9, 200, pending, Fedora EPEL 8, Initial package, python-nagiosplugin-1.3.2- 1.el8, , , 2021-07-18 17:55:58-02, 2021-07-18 17:55:58-02, null, null, 1, null, updates(a)fedoraproject.org, 2021-07-19 22:02:34.756984- 02, 2021-07-19 22:02:34.756984-02, 2021-07-19 22:02:34.756984-02, null). This is from last night: psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (8752, FEDORA-EPEL-2021-a5a0c05adf, Product Enhancement Advisory, FEDORA-EPEL-2021-a5a0c05adf, 200, pending, Fedora EPEL 8, Initial package, python-jdcal-1.4.1-1.el8, , , 2021-07-19 16:46:28-02, 2021-07-19 16:46:28-02, null, null, 1, null, updates(a)fedoraproject.org, 2021-07-20 04:05:53.484279-02, 2021-07-20 04:05:53.484279-02, 2021-07-20 04:05:53.484279-02, null). Full log: # LANG=C spacewalk-repo-sync -c epel8-almalinux8-x86_64 08:46:02 ====================================== 08:46:02 | Channel: epel8-almalinux8-x86_64 08:46:02 ====================================== 08:46:02 Sync of channel started. Retrieving repository 'epel8-almalinux8-x86_64' metadata ...............................[done] Building repository 'epel8-almalinux8-x86_64' cache ....................................[done] All repositories have been refreshed. 08:46:06 08:46:06 Importing comps file 96d01da780a309a1803ea903a9f2a33b1c239a265847c6a86718acb9ef85f06e-comps- Everything.x86_64.xml. 08:46:06 Renaming non-standard filename 96d01da780a309a1803ea903a9f2a33b1c239a265847c6a86718acb9ef85f06e-comps- Everything.x86_64.xml to comps.x86_64.xml. 08:46:06 *** NOTE: Importing comps file for the channel 'epel8- almalinux8-x86_64'. Previous comps will be discarded. 08:46:06 Repo URL: https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/ 08:46:06 Packages in repo: 7558 08:46:14 No new packages to sync. 08:46:15 08:46:15 Patches in repo: 3017. 08:46:15 Add Patch FEDORA-EPEL-2021-3ec3998292 08:46:16 Add Patch FEDORA-EPEL-2021-7dc78a18ca 08:46:16 Add Patch FEDORA-EPEL-2021-d33da662e7 08:46:16 Add Patch FEDORA-EPEL-2021-87b303b50e 08:46:17 Add Patch FEDORA-EPEL-2021-7ed6a63b7b 08:46:17 Add Patch FEDORA-EPEL-2021-a5a0c05adf 08:46:17 Add Patch FEDORA-EPEL-2021-f77315a931 08:46:17 Add Patch FEDORA-EPEL-2021-333cf44938 08:46:17 Add Patch FEDORA-EPEL-2021-fdb6cf1e3a 08:46:17 Add Patch FEDORA-EPEL-2021-b3771b0cd1 08:46:18 Add Patch FEDORA-EPEL-2021-15c5b7660c 08:46:18 Add Patch FEDORA-EPEL-2021-384d2492fa 08:46:18 Add Patch FEDORA-EPEL-2021-247500b671 08:46:18 Add Patch FEDORA-EPEL-2021-d4c3bbff96 08:46:19 Add Patch FEDORA-EPEL-2021-a60d1222d2 08:46:19 Add Patch FEDORA-EPEL-2021-ec70035a87 08:46:19 Add Patch FEDORA-EPEL-2021-d48e8d2d55 08:46:19 Add Patch FEDORA-EPEL-2021-293195e59b 08:46:19 Add Patch FEDORA-EPEL-2021-41eeae14d9 08:46:19 Add Patch FEDORA-EPEL-2021-ec2a0a616a 08:46:19 Add Patch FEDORA-EPEL-2021-b8960f6143 08:46:19 Add Patch FEDORA-EPEL-2021-20a66b3776 08:46:20 Add Patch FEDORA-EPEL-2020-7c3fde7f74 08:46:20 Add Patch FEDORA-EPEL-2021-ac096c00b0 08:46:20 Add Patch FEDORA-EPEL-2021-aa67d44d29 08:46:20 Add Patch FEDORA-EPEL-2021-d3d8cfc98d 08:46:20 Syncing 25 new patch(es) to channel. 08:46:20 Unexpected error: <class 'psycopg2.errors.CheckViolation'> 08:46:20 Traceback (most recent call last): File "/usr/lib/python3.6/site- packages/spacewalk/satellite_tools/reposync.py", line 600, in sync self.import_updates(plugin) File "/usr/lib/python3.6/site- packages/spacewalk/satellite_tools/reposync.py", line 741, in import_updates processed_updates_count = self.upload_updates(notices) File "/usr/lib/python3.6/site- packages/spacewalk/satellite_tools/reposync.py", line 967, in upload_updates importer.run() File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/importLib.py", line 778, in run self.submit() File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/errataImport.py", line 217, in submit dml = self.backend.processErrata(self.batch) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 1011, in processErrata transactional=1) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 2151, in __processObjectCollection return self.__processObjectCollection__(objColl, parentTable, childDict, **kwargs) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 2322, in __processObjectCollection__ return self.__doDML(dml) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 2427, in __doDML self.__doInsert(dml.insert, dml.tables) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 2434, in __doInsert self.__doInsertTable(tname, dict) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backend.py", line 2449, in __doInsertTable insertObj.query(hash) File "/usr/lib/python3.6/site- packages/spacewalk/server/importlib/backendLib.py", line 453, in query statement.execute_values(self._buildQuery(None), value_list, fetch=False, page_size=10_000) File "/usr/lib/python3.6/site- packages/spacewalk/server/rhnSQL/sql_base.py", line 166, in execute_values return self._execute_wrapper(self._execute_values, sql, argslist, template, page_size, fetch) File "/usr/lib/python3.6/site- packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 299, in _execute_wrapper retval = function(*p, **kw) File "/usr/lib/python3.6/site- packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 353, in _execute_values results = psycopg2.extras.execute_values(self._real_cursor, sql, argslist, template=template, page_size=page_size, fetch=fetch) File "/usr/lib64/python3.6/site-packages/psycopg2/extras.py", line 1289, in execute_values cur.execute(b''.join(parts)) psycopg2.errors.CheckViolation: new row for relation "rhnerrata" violates check constraint "rhn_errata_adv_status_ck" DETAIL: Failing row contains (8816, FEDORA-EPEL-2021-a5a0c05adf, Product Enhancement Advisory, FEDORA-EPEL-2021-a5a0c05adf, 200, pending, Fedora EPEL 8, Initial package, python-jdcal-1.4.1-1.el8, , , 2021-07-19 16:46:28-02, 2021-07-19 16:46:28-02, null, null, 1, null, updates(a)fedoraproject.org, 2021-07-20 04:46:02.984641-02, 2021-07-20 04:46:02.984641-02, 2021-07-20 04:46:02.984641-02, null). 08:46:20 Total time: 0:00:17 Any ideas ? Thank you, Jordi.

4 5

Proposed packages on Uyuni server after 2021.06 upgrade
by Bidault, Philippe 20 Jul '21

20 Jul '21

Hi all, After the upgrade and reboot of Uyuni server to 2021.06 following the proc https://www.uyuni-project.org/uyuni-docs/en/uyuni/upgrade/server-major-upgr…, I can still see those kernel and PostgreSQL updates available: # zypper ref Repository 'Update repository of openSUSE Backports' is up to date. Repository 'Non-OSS Repository' is up to date. Repository 'Main Repository' is up to date. Retrieving repository 'Update repository wiht updates from SUSE Linux Enterprise 15' metadata .........................................................................................[done] Building repository 'Update repository wiht updates from SUSE Linux Enterprise 15' cache ..............................................................................................[done] Repository 'Main Update Repository' is up to date. Repository 'Update Repository (Non-Oss)' is up to date. Repository 'Uyuni Server Stable' is up to date. All repositories have been refreshed. # zypper ls # | Alias | Name | Enabled | GPG Check | Refresh | Type --+-----------------------------+---------------------------------------------------------------------------------------------+---------+-----------+---------+------- 1 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- | NONE 2 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | No | rpm-md 3 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | No | rpm-md 4 | repo-oss | Main Repository | Yes | (r ) Yes | No | rpm-md 5 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- | NONE 6 | repo-sle-update | Update repository wiht updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | No | rpm-md 7 | repo-update | Main Update Repository | Yes | (r ) Yes | No | rpm-md 8 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | No | rpm-md 9 | uyuni-server-stable | Uyuni Server Stable | Yes | (r ) Yes | No | rpm-md # zypper lu Loading repository data... Reading installed packages... S | Repository | Name | Current Version | Available Version | Arch --+--------------------------------------------------------------+-------------------------+-----------------+-------------------+------- v | Update repository wiht updates from SUSE Linux Enterprise 15 | kernel-default | 5.3.18-59.13.1 | 5.3.18-59.16.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | kernel-default-extra | 5.3.18-59.13.1 | 5.3.18-59.16.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | kernel-default-optional | 5.3.18-59.13.1 | 5.3.18-59.16.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | libpq5 | 13.2-5.6.1 | 13.3-5.13.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | libsystemd0 | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | libudev1 | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | postgresql13 | 13.2-5.6.1 | 13.3-5.13.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | postgresql13-contrib | 13.2-5.6.1 | 13.3-5.13.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | postgresql13-server | 13.2-5.6.1 | 13.3-5.13.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | systemd | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | systemd-doc | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | systemd-lang | 246.13-7.5.1 | 246.13-7.8.1 | noarch v | Update repository wiht updates from SUSE Linux Enterprise 15 | systemd-network | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | systemd-sysvinit | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 v | Update repository wiht updates from SUSE Linux Enterprise 15 | udev | 246.13-7.5.1 | 246.13-7.8.1 | x86_64 Is this expected ? Do I have to upgrade those too ? Thought that the script /usr/lib/susemanager/bin/server-migrator.sh would have take care to update everything. Regards, Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.getronics.com> [cid:3-lines_7512e235-163a-4853-8e4f-b0d4fc62ce73.png]<https://getronics.com/> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

1 0

Missing Repositories for Open Enterprise Server 2018 SP3
by Thomas Weis 20 Jul '21

20 Jul '21

Hello there, SP3 for Open Enterprise Server 2018 has been released for some time. We receive the repos for OES2018 SP1 and OES2018 SP2 via the subscriptions in the SCC, but not the repos for OES2018 SP3. Is there a time when the repositories are available or is that not planned? Many thanks to the project team! Regards Thomas

1 0

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 19 Jul '21

19 Jul '21

Hi Viktor, I hope that this output is related to lkv-srvapp42 only: lkv-srvapp39:~ # salt-run state.event pretty=True salt/auth { "_stamp": "2021-07-19T13:28:59.586422", "act": "accept", "id": "lkv-srvapp42.lkvbay.net", "pub": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApU/6mKT1NrxhllRpDgaR\ndT+FYKpH0c+oueRiB+bvbSXRMbvwJePDFT2CYFyjFQKU85XBmq3r1HRwP8CNn0Z3\nP12l2F+eAl2DHRWdGLnCeIQX/sau5YLBI7acTNAdpkNY0FJ1t7lapobGCdNfRfsh\nS5MCfxEf7CwK/us64uF55cY50vss6JSL/MMD5YoiHXUY7AhaasVv1q/3zYoyf7AN\n6tIJtqF/XdjocWE8gQTEMNbmAHvtqJ/09nyEBrh0ZlDZ/po1adbTvDH8z95cm2cL\nKa1TdasQRfSv4AGR0USH+iS8pWqGDlfnd7UuXgKHfTIyMu59nRZg5CY9qmRsL8UR\nNwIDAQAB\n-----END PUBLIC KEY-----\n", "result": true } minion/refresh/lkv-srvapp42.lkvbay.net { "Minion data cache refresh": "lkv-srvapp42.lkvbay.net", "_stamp": "2021-07-19T13:28:59.712892" } salt/minion/lkv-srvapp42.lkvbay.net/start { "_stamp": "2021-07-19T13:29:00.145784", "cmd": "_minion_event", "data": "Minion lkv-srvapp42.lkvbay.net started at Mon Jul 19 15:29:00 2021", "id": "lkv-srvapp42.lkvbay.net", "pretag": null, "tag": "salt/minion/lkv-srvapp42.lkvbay.net/start" } 20210719132900304963 { "_stamp": "2021-07-19T13:29:00.305236", "minions": [ "lkv-srvapp42.lkvbay.net" ] } salt/job/20210719132900304963/new { "_stamp": "2021-07-19T13:29:00.305678", "arg": [], "fun": "mgractionchains.resume", "jid": "20210719132900304963", "minions": [ "lkv-srvapp42.lkvbay.net" ], "missing": [], "tgt": "lkv-srvapp42.lkvbay.net", "tgt_type": "glob", "user": "salt" } salt/job/20210719132900304963/ret/lkv-srvapp42.lkvbay.net { "_stamp": "2021-07-19T13:29:00.378168", "cmd": "_return", "fun": "mgractionchains.resume", "fun_args": [], "id": "lkv-srvapp42.lkvbay.net", "jid": "20210719132900304963", "metadata": { "suma-action-chain": true }, "retcode": 0, "return": {}, "success": true } 20210719132900367742 { "_stamp": "2021-07-19T13:29:00.392732", "minions": [ "lkv-srvapp42.lkvbay.net" ] } salt/job/20210719132900367742/new { "_stamp": "2021-07-19T13:29:00.393136", "arg": [], "fun": "test.ping", "jid": "20210719132900367742", "minions": [ "lkv-srvapp42.lkvbay.net" ], "missing": [], "tgt": [ "lkv-srvapp42.lkvbay.net" ], "tgt_type": "list", "user": "admin" } salt/job/20210719132900367742/ret/lkv-srvapp42.lkvbay.net { "_stamp": "2021-07-19T13:29:00.459355", "cmd": "_return", "fun": "test.ping", "fun_args": [], "id": "lkv-srvapp42.lkvbay.net", "jid": "20210719132900367742", "metadata": { "batch-mode": true, "suma-action-chain": false, "suma-action-id": 0, "suma-force-pkg-list-refresh": false, "suma-minion-startup": true }, "retcode": 0, "return": true, "success": true } salt/batch/20210719132900368080/start { "_stamp": "2021-07-19T13:29:00.463419", "available_minions": [ "lkv-srvapp42.lkvbay.net" ], "down_minions": [], "metadata": { "batch-mode": true, "suma-action-chain": false, "suma-action-id": 0, "suma-force-pkg-list-refresh": false, "suma-minion-startup": true } } 20210719132900368080 { "_stamp": "2021-07-19T13:29:00.491610", "minions": [ "lkv-srvapp42.lkvbay.net" ] } salt/job/20210719132900368080/new { "_stamp": "2021-07-19T13:29:00.492090", "arg": [ { "__kwarg__": true, "mods": [ "util.systeminfo" ], "queue": true } ], "fun": "state.apply", "jid": "20210719132900368080", "minions": [ "lkv-srvapp42.lkvbay.net" ], "missing": [], "tgt": [ "lkv-srvapp42.lkvbay.net" ], "tgt_type": "list", "user": "salt" } 20210719132900559758 { "_stamp": "2021-07-19T13:29:00.560013", "minions": [ "lkv-srvapp42.lkvbay.net" ] } salt/job/20210719132900559758/new { "_stamp": "2021-07-19T13:29:00.560412", "arg": [], "fun": "test.ping", "jid": "20210719132900559758", "minions": [ "lkv-srvapp42.lkvbay.net" ], "missing": [], "tgt": [ "lkv-srvapp42.lkvbay.net" ], "tgt_type": "list", "user": "admin" } salt/job/20210719132900559758/ret/lkv-srvapp42.lkvbay.net { "_stamp": "2021-07-19T13:29:00.632379", "cmd": "_return", "fun": "test.ping", "fun_args": [], "id": "lkv-srvapp42.lkvbay.net", "jid": "20210719132900559758", "retcode": 0, "return": true, "success": true } minion/refresh/lkv-srvapp42.lkvbay.net { "Minion data cache refresh": "lkv-srvapp42.lkvbay.net", "_stamp": "2021-07-19T13:29:00.720947" } 20210719132900746311 { "_stamp": "2021-07-19T13:29:00.746618", "minions": [ "lkv-srvapp42.lkvbay.net" ] } salt/job/20210719132900746311/new { "_stamp": "2021-07-19T13:29:00.747039", "arg": [ "machine_id", "saltboot_initrd", "susemanager", { "__kwarg__": true, "sanitize": false } ], "fun": "grains.item", "jid": "20210719132900746311", "minions": [ "lkv-srvapp42.lkvbay.net" ], "missing": [], "tgt": [ "lkv-srvapp42.lkvbay.net" ], "tgt_type": "list", "user": "admin" } salt/job/20210719132900746311/ret/lkv-srvapp42.lkvbay.net { "_stamp": "2021-07-19T13:29:00.813641", "cmd": "_return", "fun": "grains.item", "fun_args": [ "machine_id", "saltboot_initrd", "susemanager", { "sanitize": false } ], "id": "lkv-srvapp42.lkvbay.net", "jid": "20210719132900746311", "out": "nested", "retcode": 0, "return": { "machine_id": "945e1982bdbf5494212beb1c5ea9a35b", "saltboot_initrd": "", "susemanager": { "activation_key": "1-SLES15" } }, "success": true } salt/job/20210719132900368080/ret/lkv-srvapp42.lkvbay.net { "_stamp": "2021-07-19T13:29:01.522183", "cmd": "_return", "fun": "state.apply", "fun_args": [ { "mods": [ "util.systeminfo" ], "queue": true } ], "id": "lkv-srvapp42.lkvbay.net", "jid": "20210719132900368080", "metadata": { "batch-mode": true, "suma-action-chain": false, "suma-action-id": 0, "suma-force-pkg-list-refresh": false, "suma-minion-startup": true }, "out": "highstate", "retcode": 2, "return": { "mgrcompat_|-grains_update_|-grains.item_|-module_run": { "__id__": "grains_update", "__run_num__": 5, "__sls__": "util.systeminfo", "changes": {}, "comment": "An exception occurred in this state: Traceback (most recent call last):\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 352, in _call_function\n return self._function(*args, **kwargs)\nTypeError: _run() missing 1 required positional argument: 'name'\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/usr/lib/python3.6/site-packages/salt/state.py\", line 2176, in call\n *cdata[\"args\"], **cdata[\"kwargs\"]\n File \"/usr/lib/python3.6/site-packages/salt/loader.py\", line 2113, in wrapper\n return f(*args, **kwargs)\n File \"/var/cache/salt/minion/extmods/states/mgrcompat.py\", line 85, in module_run\n ret = module.run(**new_kwargs)\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 738, in _decorate\n return self._call_function(kwargs)\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 355, in _call_function\n self._function, self._orig_f_name\nTypeError: replace() argument 1 must be str, not function\n", "duration": 2.997, "name": "grains.item", "result": false, "start_time": "15:29:01.517152" }, "mgrcompat_|-status_uptime_|-status.uptime_|-module_run": { "__id__": "status_uptime", "__run_num__": 4, "__sls__": "util.systeminfo", "changes": {}, "comment": "An exception occurred in this state: Traceback (most recent call last):\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 352, in _call_function\n return self._function(*args, **kwargs)\nTypeError: _run() missing 1 required positional argument: 'name'\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/usr/lib/python3.6/site-packages/salt/state.py\", line 2176, in call\n *cdata[\"args\"], **cdata[\"kwargs\"]\n File \"/usr/lib/python3.6/site-packages/salt/loader.py\", line 2113, in wrapper\n return f(*args, **kwargs)\n File \"/var/cache/salt/minion/extmods/states/mgrcompat.py\", line 85, in module_run\n ret = module.run(**new_kwargs)\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 738, in _decorate\n return self._call_function(kwargs)\n File \"/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py\", line 355, in _call_function\n self._function, self._orig_f_name\nTypeError: replace() argument 1 must be str, not function\n", "duration": 5.542, "name": "status.uptime", "result": false, "start_time": "15:29:01.511454" }, "saltutil_|-sync_beacons_|-sync_beacons_|-sync_beacons": { "__id__": "sync_beacons", "__run_num__": 3, "__sls__": "util.syncbeacons", "changes": {}, "comment": "No updates to sync", "duration": 29.281, "name": "sync_beacons", "result": true, "start_time": "15:29:01.480125" }, "saltutil_|-sync_grains_|-sync_grains_|-sync_grains": { "__id__": "sync_grains", "__run_num__": 2, "__sls__": "util.syncgrains", "changes": {}, "comment": "No updates to sync", "duration": 359.752, "name": "sync_grains", "result": true, "start_time": "15:29:01.120157" }, "saltutil_|-sync_modules_|-sync_modules_|-sync_modules": { "__id__": "sync_modules", "__run_num__": 0, "__sls__": "util.syncmodules", "changes": {}, "comment": "No updates to sync", "duration": 139.887, "name": "sync_modules", "result": true, "start_time": "15:29:00.948134" }, "saltutil_|-sync_states_|-sync_states_|-sync_states": { "__id__": "sync_states", "__run_num__": 1, "__sls__": "util.syncstates", "changes": {}, "comment": "No updates to sync", "duration": 31.873, "name": "sync_states", "result": true, "start_time": "15:29:01.088161" } }, "success": false } minion/refresh/lkv-srvapp42.lkvbay.net { "Minion data cache refresh": "lkv-srvapp42.lkvbay.net", "_stamp": "2021-07-19T13:29:02.265064" } salt/batch/20210719132900368080/done { "_stamp": "2021-07-19T13:29:02.527884", "available_minions": [ "lkv-srvapp42.lkvbay.net" ], "done_minions": [ "lkv-srvapp42.lkvbay.net" ], "down_minions": [], "metadata": { "batch-mode": true, "suma-action-chain": false, "suma-action-id": 0, "suma-force-pkg-list-refresh": false, "suma-minion-startup": true }, "timedout_minions": [] } ^CException occurred in runner state.event: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/client/mixins.py", line 385, in low data['return'] = func(*args, **kwargs) File "/usr/lib/python3.6/site-packages/salt/runners/state.py", line 313, in event node=node) File "/usr/lib/python3.6/site-packages/salt/modules/state.py", line 2412, in event ret = sevent.get_event(full=True, auto_reconnect=True) File "/usr/lib/python3.6/site-packages/salt/utils/event.py", line 638, in get_event ret = self._get_event(wait, tag, match_func, no_block) File "/usr/lib/python3.6/site-packages/salt/utils/event.py", line 544, in _get_event raw = self.subscriber.read_sync(timeout=wait) File "/usr/lib/python3.6/site-packages/salt/transport/ipc.py", line 693, in read_sync return self.io_loop.run_sync(lambda: self._read(timeout)) File "/usr/lib/python3.6/site-packages/salt/ext/tornado/ioloop.py", line 454, in run_sync self.start() File "/usr/lib/python3.6/site-packages/salt/ext/tornado/ioloop.py", line 865, in start event_pairs = self._impl.poll(poll_timeout) File "/usr/lib/python3.6/site-packages/salt/scripts.py", line 78, in _handle_signals hardcrash, trace=trace) File "/usr/lib/python3.6/site-packages/salt/scripts.py", line 43, in _handle_interrupt raise exc SystemExit: Exiting gracefully on Ctrl-c lkv-srvapp39:~ # Regards, Tobias. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 19. Juli 2021 15:20 Tobias, could you please collect the output of `salt-run state.event pretty=True` for this minion on restarting it. 1. stop salt-minion on the affected system 2. Run `salt-run state.event pretty=True` on SUSE Manager Server 3. start salt-minion on the affected system And show the events captured related to this minion Victor

2 1

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 19 Jul '21

19 Jul '21

Hi Robert, I'm not running any special python, so "standard python" of SLES15 should be active: > python3 -V Python 3.6.13 In the traceback there are some paths with "python3.6" so I estimate that actually this version is active. Regards, Tobias. -----Ursprüngliche Nachricht----- Von: Robert Paschedag [mailto:robert.paschedag@web.de] Gesendet: Montag, 19. Juli 2021 15:12 An: Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de> Cc: 'Victor Zhestkov' <victor.zhestkov(a)suse.com>; users(a)lists.uyuni-project.org Betreff: Re: SLES15SP2-Clients: salt-minion problem Are you running python 3.9? There was a big fix a few weeks ago... You might still hit it. Check https://github.com/openSUSE/salt/pull/390 Robert ⁣sent from my mobile device -------- Originale Nachricht -------- Von: "Crefeld, Tobias LKV Bayern e.V." <tobias.crefeld(a)lkv.bayern.de> Gesendet: Mon Jul 19 14:57:30 GMT+02:00 2021 An: 'Victor Zhestkov' <victor.zhestkov(a)suse.com>, "'users(a)lists.uyuni-project.org'" <users(a)lists.uyuni-project.org> Betreff: AW: SLES15SP2-Clients: salt-minion problem Hi Viktor, I entered “zypper up” and salt-minion immediately shows the exception and doesn’t execute a job on the Uyuni system successfully: lkv-srvapp42:~ # zypper up Loading repository data... Reading installed packages... The following NEW package is going to be installed: python3-pycryptodome The following package is going to be REMOVED: python3-pycrypto The following 3 packages are going to be upgraded: python3-salt salt salt-minion 3 packages to upgrade, 1 new, 1 to remove. Overall download size: 15.8 MiB. Already cached: 0 B. After the operation, additional 23.5 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package python3-pycryptodome-3.9.0-6.1.x86_64 (1/4), 7.1 MiB ( 25.3 MiB unpacked) Retrieving: python3-pycryptodome-3.9.0-6.1.x86_64.rpm .............................................................................................................................................................[done] Retrieving package salt-3002.2-37.1.x86_64 (2/4), 175.9 KiB ( 49.9 KiB unpacked) Retrieving: salt-3002.2-37.1.x86_64.rpm ...........................................................................................................................................................................[done] Retrieving package python3-salt-3002.2-37.1.x86_64 (3/4), 8.4 MiB ( 45.3 MiB unpacked) Retrieving: python3-salt-3002.2-37.1.x86_64.rpm ...................................................................................................................................................................[done] Retrieving package salt-minion-3002.2-37.1.x86_64 (4/4), 170.8 KiB ( 41.7 KiB unpacked) Retrieving: salt-minion-3002.2-37.1.x86_64.rpm ....................................................................................................................................................................[done] Checking for file conflicts: ......................................................................................................................................................................................[done] (1/4) Installing: python3-pycryptodome-3.9.0-6.1.x86_64 ...........................................................................................................................................................[done] (2/4) Installing: salt-3002.2-37.1.x86_64 .........................................................................................................................................................................[done] (3/4) Installing: python3-salt-3002.2-37.1.x86_64 .................................................................................................................................................................[done] (4/4) Installing: salt-minion-3002.2-37.1.x86_64 ..................................................................................................................................................................[done] Executing %posttrans scripts ......................................................................................................................................................................................[done] There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. Output in /var/log/salt/minion: lkv-srvapp42:~ # File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function Further output after a “Package List Refresh” on Uyuni: lkv-srvapp42:~ # 2021-07-19 14:52:12,141 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,144 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,147 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,147 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,151 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,151 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,154 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,155 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function Any idea? Regards, Tobias. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 19. Juli 2021 12:17 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com>; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; users(a)lists.uyuni-project.org Betreff: Re: AW: AW: SLES15SP2-Clients: salt-minion problem Hi Tobias. I have `python3-salt-3002.2-37.1` installed and it's running fine and our QA testing salt we are releasing for all supported OSes. Try to update salt-minion with all of it's dependencies, I beleive it should work. Regards, Victor On Mon, 2021-07-19 at 09:46 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Viktor, your hint with the version of python3-salt made me think about downgrading it, which was successful. zypper in --oldpackage python3-salt-3000-30.1 and accepting the dependent downgrades of the packages of salt and salt-minion makes service salt-minion work again. It seems that Patch SUSE-15-SP2-2021-2106 is responsible for dysfunction of the service salt-minion. BTW: Is there a way to block a patch from being activated in general? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com <mailto:Victor.Zhestkov@suse.com> >; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de <mailto:Tobias.Crefeld@lkv.bayern.de> >; users(a)lists.uyuni-project.org <mailto:users@lists.uyuni-project.org> Betreff: Re: AW: SLES15SP2-Clients: salt-minion problem Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs? On Mon, 2021-07-12 at 15:49 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Victor, thanks for your fast reply! I guess it's "3002.2-37.1" : zypper se -s salt |grep "^i" i | python3-salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i | salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i+ | salt-minion | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 BTW: The SLES15SP1 systems where salt-minion is running fine, show version 3000-19.1. Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com <mailto:Victor.Zhestkov@suse.com> ] Gesendet: Montag, 12. Juli 2021 17:31 Hi Tobias. What is the salt version installed on the minion. It's better to check the output of: zypper se -s salt Regards, Victor

1 0

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 19 Jul '21

19 Jul '21

Hi Viktor, I entered “zypper up” and salt-minion immediately shows the exception and doesn’t execute a job on the Uyuni system successfully: lkv-srvapp42:~ # zypper up Loading repository data... Reading installed packages... The following NEW package is going to be installed: python3-pycryptodome The following package is going to be REMOVED: python3-pycrypto The following 3 packages are going to be upgraded: python3-salt salt salt-minion 3 packages to upgrade, 1 new, 1 to remove. Overall download size: 15.8 MiB. Already cached: 0 B. After the operation, additional 23.5 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package python3-pycryptodome-3.9.0-6.1.x86_64 (1/4), 7.1 MiB ( 25.3 MiB unpacked) Retrieving: python3-pycryptodome-3.9.0-6.1.x86_64.rpm .............................................................................................................................................................[done] Retrieving package salt-3002.2-37.1.x86_64 (2/4), 175.9 KiB ( 49.9 KiB unpacked) Retrieving: salt-3002.2-37.1.x86_64.rpm ...........................................................................................................................................................................[done] Retrieving package python3-salt-3002.2-37.1.x86_64 (3/4), 8.4 MiB ( 45.3 MiB unpacked) Retrieving: python3-salt-3002.2-37.1.x86_64.rpm ...................................................................................................................................................................[done] Retrieving package salt-minion-3002.2-37.1.x86_64 (4/4), 170.8 KiB ( 41.7 KiB unpacked) Retrieving: salt-minion-3002.2-37.1.x86_64.rpm ....................................................................................................................................................................[done] Checking for file conflicts: ......................................................................................................................................................................................[done] (1/4) Installing: python3-pycryptodome-3.9.0-6.1.x86_64 ...........................................................................................................................................................[done] (2/4) Installing: salt-3002.2-37.1.x86_64 .........................................................................................................................................................................[done] (3/4) Installing: python3-salt-3002.2-37.1.x86_64 .................................................................................................................................................................[done] (4/4) Installing: salt-minion-3002.2-37.1.x86_64 ..................................................................................................................................................................[done] Executing %posttrans scripts ......................................................................................................................................................................................[done] There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. Output in /var/log/salt/minion: lkv-srvapp42:~ # File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function Further output after a “Package List Refresh” on Uyuni: lkv-srvapp42:~ # 2021-07-19 14:52:12,141 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,144 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,147 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,147 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,151 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,151 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function 2021-07-19 14:52:12,154 [salt.utils.decorators:714 ][WARNING ][3229] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-19 14:52:12,155 [salt.state :322 ][ERROR ][3229] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function Any idea? Regards, Tobias. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 19. Juli 2021 12:17 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com>; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; users(a)lists.uyuni-project.org Betreff: Re: AW: AW: SLES15SP2-Clients: salt-minion problem Hi Tobias. I have `python3-salt-3002.2-37.1` installed and it's running fine and our QA testing salt we are releasing for all supported OSes. Try to update salt-minion with all of it's dependencies, I beleive it should work. Regards, Victor On Mon, 2021-07-19 at 09:46 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Viktor, your hint with the version of python3-salt made me think about downgrading it, which was successful. zypper in --oldpackage python3-salt-3000-30.1 and accepting the dependent downgrades of the packages of salt and salt-minion makes service salt-minion work again. It seems that Patch SUSE-15-SP2-2021-2106 is responsible for dysfunction of the service salt-minion. BTW: Is there a way to block a patch from being activated in general? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com <mailto:Victor.Zhestkov@suse.com> >; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de <mailto:Tobias.Crefeld@lkv.bayern.de> >; users(a)lists.uyuni-project.org <mailto:users@lists.uyuni-project.org> Betreff: Re: AW: SLES15SP2-Clients: salt-minion problem Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs? On Mon, 2021-07-12 at 15:49 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Victor, thanks for your fast reply! I guess it's "3002.2-37.1" : zypper se -s salt |grep "^i" i | python3-salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i | salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i+ | salt-minion | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 BTW: The SLES15SP1 systems where salt-minion is running fine, show version 3000-19.1. Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com <mailto:Victor.Zhestkov@suse.com> ] Gesendet: Montag, 12. Juli 2021 17:31 Hi Tobias. What is the salt version installed on the minion. It's better to check the output of: zypper se -s salt Regards, Victor

3 2

AW: AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 19 Jul '21

19 Jul '21

Hi Viktor, your hint with the version of python3-salt made me think about downgrading it, which was successful. zypper in --oldpackage python3-salt-3000-30.1 and accepting the dependent downgrades of the packages of salt and salt-minion makes service salt-minion work again. It seems that Patch SUSE-15-SP2-2021-2106 is responsible for dysfunction of the service salt-minion. BTW: Is there a way to block a patch from being activated in general? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com>; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; users(a)lists.uyuni-project.org Betreff: Re: AW: SLES15SP2-Clients: salt-minion problem Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs? On Mon, 2021-07-12 at 15:49 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Victor, thanks for your fast reply! I guess it's "3002.2-37.1" : zypper se -s salt |grep "^i" i | python3-salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i | salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i+ | salt-minion | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 BTW: The SLES15SP1 systems where salt-minion is running fine, show version 3000-19.1. Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com <mailto:Victor.Zhestkov@suse.com> ] Gesendet: Montag, 12. Juli 2021 17:31 Hi Tobias. What is the salt version installed on the minion. It's better to check the output of: zypper se -s salt Regards, Victor

2 1

Ubuntu 20.04 salt client not "checking in" when going through a Squid proxy
by Paul-Andre Panon 17 Jul '21

17 Jul '21

Hi, We’ve got an Ubuntu 20.04 system which is set up to connect to the Uyuni server through a standard Squid proxy. It can do most typical client patching tasks against the Uyuni server fine: apt-get update, apt-get upgrade, etc. . I didn’t try pushing packages from the Uyuni side recently, though it used to work before inserting the web proxy. However the server is no longer checking in. It is in a DMZ so connections from the system to the Uyuni server are blocked except through the web proxy. This approach/mechanism worked with a traditional client config Ubuntu client and Spacewalk, where rhn_check was used to check in. Looking at the documentation, it looks like I should have set up and used a different activation key that used push via ssh. https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/cont… Is there any way to convert a standard salt client into the salt-ssh contact method? Is there a recommended way to get myself out of the hole I’ve dug myself into here? I’ve got to think I’m not the first person with a system that needs to move into a DMZ after setup and needs a contact method change. I seem to remember reading that you need to take care in unregistering and reregistering clients, so I’m not sure if trying to do that with a new activation code would work. Does the push via ssh use salt-ssh via public/private key pair? That would seem to be more secure than a user/password approach. Thanks, Paul-Andre Panon -- *For more information on how and why we collect your personal information, please visit our Privacy Policy <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackI…>.*

2 1

AW: AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 16 Jul '21

16 Jul '21

Hi Viktor,, the output is „null“, probably meaning “ok”. How can I find out from which channel a package has been installed? What do you mean with “tweaks”? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs?

3 4

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 12 Jul '21

12 Jul '21

2 1

SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 12 Jul '21

12 Jul '21

Hi, after upgrading some SLES15 systems from SP1 to SP2 the service "salt-minion" of those systems don't work anymore although it still can get started. Uyuni release is 2020.11. The following channels are enabled - except the "perl channel" all channels are standard channels from SCC: 1 | SLES15-15-0 | No 2 | SLE-Module-Basesystem15-SP2-Pool for x86_64 | Yes 3 | SLE-Module-Basesystem15-SP2-Updates for x86_64 | Yes 4 | SLE-Module-Legacy15-SP2-Pool for x86_64 | Yes 5 | SLE-Module-Legacy15-SP2-Updates for x86_64 | Yes 6 | SLE-Module-Packagehub-Subpackages15-SP2-Pool for x86_64 | Yes 7 | SLE-Module-Packagehub-Subpackages15-SP2-Updates for x86_64 | Yes 8 | SLE-Module-Server-Applications15-SP2-Pool for x86_64 | Yes 9 | SLE-Module-Server-Applications15-SP2-Updates for x86_64 | Yes 10 | SLE-Module-Web-Scripting15-SP2-Pool for x86_64 | Yes 11 | SLE-Module-Web-Scripting15-SP2-Updates for x86_64 | Yes 12 | SLE-Product-SLES15-SP2-Pool for x86_64 | Yes 13 | SLE-Product-SLES15-SP2-Updates for x86_64 | Yes 14 | perl modules (SLE_15_SP2) | Yes 15 | SUSE-PackageHub-15-SP2-Backports-Pool for x86_64 | Yes 16 | SUSE-PackageHub-15-SP2-Pool for x86_64 | Yes /var/log/salt/minion shows multiple log entries like this one: ---------------------------------------------------------------------------- 2021-07-12 16:26:20,138 [salt.utils.decorators:714 ][WARNING ][7870] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-12 16:26:20,139 [salt.state :322 ][ERROR ][7870] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function ---------------------------------------------------------------------------- I played around with disabling several channels without any effect. Actually I have no clue which packets might be responsible for these exceptions. Maybe some Python experts have an idea about the reason of these exceptions. During update (by using Uyuni's "SP Migrate") there were some warnings: problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 problem with installed package perl-gettext-1.07-322.1.x86_64 problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 "Dry Run" runs successfully only if I mark "Allow Vendor Change". The real upgrade worked only with "zypper dup" at the client's CLI. Using "SP Migrate" for this task doesn't work - not even with "Allow Vendor Change". The upgrade is actually successful but without salt-minion Uyuni's WebGUI still show the old patch level. Any idea? Regards, Tobias Crefeld.

2 1

how to import GPG Keys in Uyuni (RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported)
by Heiner Wulfhorst 12 Jul '21

12 Jul '21

Hi List, i added " https://downloads.linux.hpe.com/SDR/repo/spp-gen10/SUSE/15/x86_64/current/" as a custom channel in Uyuni. If i want to sync its repo with checked "Has Signed Metadata?" Box i always get this error in my reposync log: RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported If that box is unchecked it syncs fine. - I filled out the "Security: GPG" Fields with data from " https://downloads.linux.hpe.com/SDR/keys.html" - added the Key to "Systems > Autoinstallation > GPG and SSL Keys", and - did rpm --import on my uyuni server Is there a way to add more verbosity to that log so i can ensure i really added the right key (should be gpg-pubkey-26c2b797-5669d0b9)? Thanks, Heiner

2 2

Difference between SLES Channels "Product-SLES15-SP2-Pool" and "Product-SLES15-Pool": When to use which?
by Heiner Wulfhorst 12 Jul '21

12 Jul '21

Hi List, i need HPE ssacli on my uyuni managed Systems, so i added this Repository as a Custom Channel: https://downloads.linux.hpe.com/SDR/repo/spp-gen10/SUSE/15/x86_64/current/ As it seems to be for all SLES Service Packs i created it as a child to the parent channel "SLE-Product-SLES15-Pool for x86_64". My managed Systems have been installed with SLES SP2, so i added them to a staged ("lifecycle management") version of Base Channel "SLE-Product-SLES15- *SP2*-Pool for x86_64". 1. Within my Lifecycle Project I can add the "foreign" Child Channel to my Systems. But how would I accomplish this if my systems would be using the latest / upstream version? 2. Is there a "better" way to add Service Pack independent Software to my systems? 3. Should i even use "Product-SLES15-*SP2*-Pool" as a base channel for my Systems, or would it be better to use the general " Product-SLES15-Pool"? 4. What is the difference between "Product-SLES15-*SP2*-Pool" and "Product-SLES15-Pool", how/when should they be used? Hope to get a better understanding of how it is meant to be used so i can avoid possible future problems! Thanks! Heiner

2 3

Where to find bootstrap logs
by Stefan Bluhm 12 Jul '21

12 Jul '21

Hello, I seem to be blind or have lost my patience. When entering "host" (tried IP/hostname), "user"/"password", "activation key" and "Disable SSH.." under "Systems --> Bootstrapping" a blue info message appears "Your system is bootstrapping: waiting for a response..". After some long time, the bar changes to the red error bar saying: "Server error, please check log files.". Where are the logs for the bootstrap attempts? I claim, I searched "everywhere". Thank you and best wishes, Stefan

3 10

How to install old Uyuni release 2021.02
by Heiner Wulfhorst 01 Jul '21

01 Jul '21

Hi List, i need to do a fresh install of Uyuni release 2021.02 on my test system as that is the version our prod is currently running. How/where do i get that version? All docs i found refer to https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… BR Heiner

2 1

Unable to restart Uyuni following Uyuni upgrade 2021-06
by Simon Avery 30 Jun '21

30 Jun '21

Hi Folk, Thanks for the new release - but I'm having significant issues (around four hours so far) in updating this and currently have a broken system. Please advise! 'spacewalk-server status' reports all is fine, however the webui times out (At other stages, it was returning a 404 for all urls) Steps I have done: * Changed repos and upgraded base OS to Leap 15.3 * Upgraded database as per https://www.uyuni-project.org/uyuni-docs/en/uyuni/upgrade/db-migration-13.h… * Changed the Uyuni repo. * Normal Uyuni upgrade. All package issues seemingly resolved, apart from this: Problem: the to be installed patch:SUSE-2020-3767-1.noarch conflicts with 'apache-commons-el < 1.0-3.3.1' provided by the installed apache-commons-el-1.0-bp153.2.24.noarch Solution 1: Following actions will be done: deinstallation of apache-commons-el-1.0-bp153.2.24.noarch deinstallation of spacewalk-java-4.2.23-1.7.uyuni1.noarch deinstallation of spacewalk-common-4.2.3-1.6.uyuni1.noarch deinstallation of spacewalk-postgresql-4.2.3-1.6.uyuni1.noarch deinstallation of patterns-uyuni_server-2021.06-2.3.uyuni1.x86_64 deinstallation of susemanager-4.2.19-1.2.uyuni1.x86_64 deinstallation of supportutils-plugin-susemanager-4.2.2-2.4.uyuni1.noarch deinstallation of uyuni-cluster-provider-caasp-4.2.3-1.4.uyuni1.noarch Solution 2: do not install patch:SUSE-2020-3767-1.noarch (Did try #1, then reinstalling uyuni-server patterns, but it just reappears. ISTR there was a breaking issue with apache-commons-el in a previous update) The main issue appears to be related to this, in catalina's logs: (The dir is present and has an index.jsp file and dirs.) 24-Jun-2021 11:24:31.328 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.36] 24-Jun-2021 11:24:31.357 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/srv/tomcat/webapps/rhn] 24-Jun-2021 11:24:33.950 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/srv/tomcat/webapps/rhn] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1865) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1044) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) ... 37 more Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:382) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:195) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1971) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:775) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5044) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more 24-Jun-2021 11:24:33.958 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [2,601] ms 24-Jun-2021 11:24:33.990 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 24-Jun-2021 11:24:34.297 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 24-Jun-2021 11:24:34.509 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 24-Jun-2021 11:24:34.564 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [3,354] milliseconds Simon Avery Linux Systems Administrator

2 13

Uyuni talks at openSUSE Conference 2021
by Pau Garcia 25 Jun '21

25 Jun '21

Hi I gave a couple of talks at openSUSE Conference last week. Here are the links: * Uyuni, the movie Slide deck: https://www.slideshare.net/UyuniProject/uyuni-the-movie Video recording: https://youtu.be/wZxnmruV_Uo * Enabling new client operating systems in Uyuni Slide deck: https://www.slideshare.net/UyuniProject/enabling-new-client-operating-syste… Video recording: https://youtu.be/mX5XRI_l-1M Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Engineering & Innovation SUSE Software Solutions Spain

1 0

Uyuni 2021.06 is released!
by Julio Gonzalez 24 Jun '21

24 Jun '21

We are happy to announce the immediate availability of Uyuni 2021.06 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.06, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Read the release notes. Uyuni 2021.06 will change the base OS for the Server and Proxy to openSUSE Leap 15.3 and some manual special steps are required. The upgrade is only possible if you are on 2020.07 or newer. This is the list of highlights for this release: * Salt 3002 * Base System Upgrade * PostgreSQL 13 * Missing openSUSE Leap 15.3 channels added to spacewalk-common-channels * Integration of Ansible into an Uyuni automation environment to protect customer investment and ease migration (Technology Preview) Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2021.06 As always, we hope you will enjoy Uyuni 2021.06 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Salt state for SLES 12 firewall. Use salt.states.iptables?
by Allen Beddingfield 23 Jun '21

23 Jun '21

I have been using the firewalld state module for SLES 15 successfully, but I'm now trying to write a state for SLES 12, which uses the older SuSEfirewall2. Is the salt.states.iptables module the correct approach for this? Wondering if directly inserting iptables rules with that is going to cause any issues if someone opens the yast firewall module later? Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

3 7

Issue with salt-minion
by Simon Avery 22 Jun '21

22 Jun '21

Hello I've hit an issue since migrating a few machines from Centos 8.4 to Rocky 8.4. Still using the C8 Uyuni Tools. Remote-commands work fine, but I'm unable to change Software Channels on the amended machines, which were fine before. /var/log/salt/minion reports this salt.exceptions.SaltRenderError: Jinja variable 'salt.utils.templates.AliasedLoader object' has no attribute 'pkg.version' Re-bootstrapping the machines doesn't help. Is this due to the old version of salt-minion that's been mentioned in recent community hours, and is the upcoming release likely to fix it? Thanks Uyuni Current: <https://ata-oxy-uyuni01.atass.com/docs/en/release-notes/release-notes-serve…> 2021.05 Simon Avery Linux Systems Administrator

3 5

Some leap 15.3 update channels missing?
by David Mace 16 Jun '21

16 Jun '21

Hi, I've just used: `spacewalk-common-channels -u admin -p pass -k unlimited -a x86_64 'opensuse_leap15_3*'` to create the Leap 15.3 channels in Uyuni (2021.05). However if I compare to a Leap 15.3 client it did not import these repos: repo-backports-update - http://download.opensuse.org/update/leap/15.3/backports/ repo-sle-update - http://download.opensuse.org/update/leap/15.3/sle/ Is that intentional or should I create these channels/repos manually? Thanks David

2 1

How do I apply a highstate to a group of systems?
by Allen Beddingfield 15 Jun '21

15 Jun '21

I have created a state channel, with an init.sls entered that deploys a package, and pulls in a couple of files that are attached to the state channel. If I add that state channel to a system, and apply the highstate to that system, it works. However, what I need is a way to apply the highstate to a group of systems. What I want to do is to attach this to about 100 systems, and have it deploy - without having to individually go to each system and click "apply high state". Surely there is a way to do this? With config channels, I would deploy files by adding all the systems, selecting the files to deploy, and deploying them to all systems. I don't see any option from the state channel to apply it to all systems. Am I missing something obvious? Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

3 4

Autoinstall EL8 warnings for deprecated ks options
by jordi＠priscoelectronica.com 15 Jun '21

15 Jun '21

Hello, Just FYI, while autoinstalling almalinux8 hosts in Uyuni 2021.05 I get the following warnings: Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: 'ks=http://X.X.X.X/cblr/svc/op/autoinstall/profile/almalinux8-x86_64:1:Organization' Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: ks has been deprecated. All usage of Anaconda boot arguments without 'inst.' prefix have been deprecated and will be removed in a future major release. Please use inst.ks instead. Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: 'kssendmac=' Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: kssendmac has been deprecated. All usage of Anaconda boot arguments without 'inst.' prefix have been deprecated and will be removed in a future major release. Please use inst.ks.sendmac instead. best regards, Jordi

1 0

Centos 8 module updates - how are people dealing with this?
by Simon Avery 11 Jun '21

11 Jun '21

Hello, The recent Centos 8.4 release appears to have triggered more issues for us, and made me review how we manage our Centos 8 clients. We plan to move to Rocky soon but the same issue will persist there. Currently: Uyuni syncs Centos repos. My workaround so far has been to run "dnf -y update" on a schedule to each client instead of patching from within Uyuni as we do with Centos7. This pulls packages from the Uyuni mirror and has largely worked okay, but not any longer - lots of module related issues on all C8 clients since I updated the repos to 8.4. I'm not clear exactly why this has triggered this problem re-appearing, but it has. My understanding of this is that Uyuni doesn't update the module metadata when it populates its repositories, so the clients can't see this and fail. I've read about the Uyuni method of using the Content Lifecycle and have trialled this. This does work, but we don' t particularly want to be manually doing this for each Centos update or patch cycle. We're not big enough to warrant a corporate approval cycle for Centos, so updates are directly applied to our servers. (This has resulted in relatively few issues) The only other method I can think of is to change the clients to having local .repo files and pull updates directly from the Centos mirror. This obviously negates some of the benefits Uyuni brings to package management, but would work reliably. So I'm wondering - how are the other Centos/Alma/Oracle/Rocky 8 users of Uyuni applying updates, and how have you overcome the module problems? Simon Avery Linux Systems Administrator

6 15

FW: Uyuni Community Hours
by Pau Garcia 09 Jun '21

09 Jun '21

________________________________________ From: Pau Garcia <pau.garcia(a)suse.com> Sent: Wednesday, June 9, 2021 1:46:18 PM (UTC+01:00) Brussels, Copenhagen, Madrid, Paris To: users(a)lists.uyuni-project.org; devel(a)lists.uyuni-project.org; announce(a)lists.uyuni-project.org Cc: Victor Zhestkov; Stefan Bluhm; Karl Tarvas; Dan Čermák; Bidault, Philippe; Richard Schaertel Subject: Uyuni Community Hours When: Friday, June 25, 2021 4:00 PM-5:00 PM. Where: Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours NB: Uyuni Community Hours are held every last Friday of the month, at 4pm CET. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjNhOWQzOTktZTk0MS00…> Or call in (audio only) +34 917 94 59 77,,418209063#<tel:+34917945977,,418209063#> Spain, Madrid Phone Conference ID: 418 209 063# Find a local number<https://dialin.teams.microsoft.com/58c3986f-4c3a-4b77-b4e8-f431171ef66d?id=…> | Reset PIN<https://mysettings.lync.com/pstnconferencing> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=83d1ce03-a2c8-4530-…> ________________________________________________________________________________

1 0

Uyuni Community Hours
by Pau Garcia 09 Jun '21

09 Jun '21

Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours NB: Uyuni Community Hours are held every last Friday of the month, at 4pm CET. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjNhOWQzOTktZTk0MS00…> Or call in (audio only) +34 917 94 59 77,,418209063#<tel:+34917945977,,418209063#> Spain, Madrid Phone Conference ID: 418 209 063# Find a local number<https://dialin.teams.microsoft.com/58c3986f-4c3a-4b77-b4e8-f431171ef66d?id=…> | Reset PIN<https://mysettings.lync.com/pstnconferencing> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=83d1ce03-a2c8-4530-…> ________________________________________________________________________________

1 0