- ARCHIVED: Uyuni Users

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