December 2021 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

[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

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

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