- 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