November 2020 - 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 starvation, not checking registered client
by Bidault, Philippe 28 Jan '21

28 Jan '21

Hi all, Our Uyuni infra is quite little with 90 registered clients and increasing, however since some days we notice like a starvation of taskomatic which don't seem to be able to launch SSHPush tasks and check Uyuni client status. All the registered servers are consequently shown as inactive ("System not checking in with Uyuni"). Important perhaps to mention that "push via SSH" is the registration method used for all the registered servers ( = no Salt minion installed). The only one servers not affected by this issue are the Uyuni proxies which are registered with salt-minion. We can repetitively see in the taskomatik logs this: 2020-11-22 10:21:00,500 [DefaultQuartzScheduler_Worker-88] WARN com.redhat.rhn.taskomatic.task.SSHPush - Maximum number of workers already put ... skipping. 2020-11-22 10:22:00,327 [DefaultQuartzScheduler_Worker-22] WARN com.redhat.rhn.taskomatic.task.SSHPush - Maximum number of workers already put ... skipping. 2020-11-22 10:23:00,173 [DefaultQuartzScheduler_Worker-92] WARN com.redhat.rhn.taskomatic.task.SSHPush - Maximum number of workers already put ... skipping. No more info in any logs, and repositories sync is still working without issue though. Seems so that the SSHPush tasks queue is blocked at some point ? A restart of taskomatic temporarily solve the issue. I have tried to follow this https://www.uyuni-project.org/uyuni-docs/uyuni/large-deployments/tuning.html, but well, from what mentioned the doc, it should not be necessary in my case ("Tuning is not required on installations of fewer than 1000 clients. Do not perform these instructions on small or medium scale installations."), and no luck with it anyway. Any ideas ? Somebody who experienced this same issue ? 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 3

Uyuni 2020.11 is released!
by Julio González Gil 26 Nov '20

26 Nov '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.11 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.11, including the release notes, documentation, requirements and setup instructions. IMPORTANT: Keep in mind Uyuni 2020.07 changed the base OS to openSUSE Leap 15.2, so a special procedure is needed if you are not upgrading from 2020.07 but from a previous version! Check the release notes and the documentation for all the details This is the list of highlights for this release: * Recent Salt CVEs remediation * CentOS 7/8 ppc64le support * Prometheus Exporter Exporter for CentOS, Oracle and RHEL 7 and 8 * Node Exporter updated to version 1.0.1 for most operating systems * Web UI themes * Prometheus Exporter Exporter * XML-RPC power management API * Third-party errata information on vendor channels * Bootstrap repositories no longer flushed by default * DNSSEC enabled by default by bind update * Virtualization: Creation of virtual machines with Yomi, KickStart or AutoYaST profiles * Japanese translation 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 2020.11 As always, we hope you will enjoy Uyuni 2020.11 and we invite everyone of you to send us your feedback [2] and of course your patches, if you can contribute. Happy hacking! [2] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

After Upgrade 2020/09: Repository errors; increased shared memory usage
by Tobias Crefeld 26 Nov '20

26 Nov '20

Hi, some days ago I attempted to upgrade our Uyuni system again and this time I was more lucky than in the past. The upgrade path was 2020/04 on opensuse-15.1 to 2020/09 (on opensuse-15.2). The procedure is described at the end of the mail. Since the upgrade there are two issues: 1.) During the daily sync of the repositories (SLES15-SP1 and SLES15-SP2) the system reports messages at the Web-GUI for every channel like this one: Creating Bootstrap Repository failed Error generating bootstrap repo for: SLE-15-SP2-x86_64 "Details" show: 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: 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 synchronization of the channels seems to be successful as there are reports of new patches. The updates of the clients work fine, too. 2.) The usage of shared memory has increased significantly since the upgrade. 24 h after restart of the PostgreSQL-DB its level is nearly 2 GB which is 25%. ipcs says that this is the only process using it. Is this normal? Does the system need more memory? FYI - the upgrade was done according to https://www.uyuni-project.org/doc/2020.09/uyuni_upgrade_guide.pdf with these tasks in short (leaving out backup and snapshot of the system powered off): (Enabling all repositories) spacewalk-service stop zypper ref zypper up susemanager /usr/lib/susemanager/bin/server-migrator.sh /usr/lib/susemanager/bin/pg-migrate-10-to-12.sh fast reboot Thanks for any hints! Regards, Tobias.

2 2

Uyuni Community Hours 27.11.2020
by Pau Garcia 20 Nov '20

20 Nov '20

** Please note we are moving the time of the Uyuni Community Hours this month ** Agenda: 1. Uyuni Server on CentOS: status update (Stephan Bluhm, community) 2. Uyuni 2020.11 (Pau Garcia, SUSE) ________________________________________________________________________________ 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_NWNjZGY1NjEtNjgxYS00…> Or call in (audio only) +34 917 94 59 77,,531061056#<tel:+34917945977,,531061056#> Spain, Madrid Phone Conference ID: 531 061 056# 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

http to https in generated emails?
by Simon Avery 18 Nov '20

18 Nov '20

Hi This is a mildly irritating issue I'd like to resolve. When Uyuni generates emails like this: Uyuni has determined that the following advisory is applicable to one or more of the systems you have registered: Complete information about this patch can be found at the following location: http://hostname_redacted.com/rhn/errata/details/Details.do?eid=1824 ... If I click on that link, it takes me to Uyuni's login page at http:/... /rhn/manager/login?url_bounce=%2Frhn%2Ferrata%2Fdetails%2FDetails.do%3Feid%3D1824&request_method=GET No matter what I enter, I get bounced back. If I manually replace the emailed url with https, everything works as expected. Notes: 1. https is enabled throughout. 2. I assume that the http -> https redirection is not handling that transition well. 3. I assume that I can somewhere change the URLs supplied used in these emails to https. This would allow emails to work without redirection. However - I have not been able to locate anywhere in the webui or /etc configuration that allow me to change this. I've not been able to locate it in Uyuni's documentation (although it is an awful thing to search for) Can somebody please give me a pointer as to where I can change this, please?

3 5

testing
by per＠opensuse.org 18 Nov '20

18 Nov '20

testing123.

1 0

IMPORTANT: Recent changes for the mailing lists
by Julio González Gil 16 Nov '20

16 Nov '20

Hi everyone, As part of the openSUSE Migration of the mailing lists [1], we have a few new things that you need to be aware of: 1. The lists addresses are now: announce(a)lists.uyuni-project.org devel(a)lists.uyuni-project.org users(a)lists.uyuni-project.org translation(a)lists.uyuni-project.org 2. The old addresses will be working for some unspecified time, but we recommend you start using the new addresses. 3. To avoid some problems DMARC authentication [2], the lists (among other things) will not add prefixes such as "[uyuni-user]" to the subject, and will not alter the body adding any links to the mailing lists. 4. As a consequence: If you used the subject to filter emails, please change your filters to start using email headers(check the openSUSE Migration page for details [1]) 5. The new system uses mailman v3 and hyperkitty, so now all management can be done via webUI at https://lists.uyuni-project.org or https://lists.opensuse.org 6. Your subscription should remain unchanged. We would like to thank the openSUSE Heroes [3] for the migration, as the change from mlmmj to mailman+hyperkitty is a big step forward making life easier for both users and mailing list administrators. Best regards. [1] https://en.opensuse.org/openSUSE:Mailing_Lists_Migration [2] https://dmarc.org/ [2] https://en.opensuse.org/openSUSE:Heroes -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-users] http to https in generated emails?
by Simon Avery 16 Nov '20

16 Nov '20

Hi This is a mildly irritating issue I'd like to resolve. When Uyuni generates emails like this: Uyuni has determined that the following advisory is applicable to one or more of the systems you have registered: Complete information about this patch can be found at the following location: http://hostname_redacted.com/rhn/errata/details/Details.do?eid=1824 ... If I click on that link, it takes me to Uyuni's login page at http:/... /rhn/manager/login?url_bounce=%2Frhn%2Ferrata%2Fdetails%2FDetails.do%3Feid%3D1824&request_method=GET No matter what I enter, I get bounced back. If I manually replace the emailed url with https, everything works as expected. Notes: 1. https is enabled throughout. 2. I assume that the http -> https redirection is not handling that transition well. 3. I assume that I can somewhere change the URLs supplied used in these emails to https. This would allow emails to work without redirection. However - I have not been able to locate anywhere in the webui or /etc configuration that allow me to change this. I've not been able to locate it in Uyuni's documentation (although it is an awful thing to search for) Can somebody please give me a pointer as to where I can change this, please? Simon Avery Linux Systems Administrator

1 0

[uyuni-users] Centos 7 Bootstrap fails with enabled Epel7
by Markus.Thum＠iese.fraunhofer.de 09 Nov '20

09 Nov '20

The mailing list changed, so my first reply didn't arrived. I'm resending this email for the record. Hi, this was a problem with epel, too. The link in the last message leads to another issue (#2115). It was closed with the advice to follow the release notes. There is written: "If you need to enable the EPEL repository, make sure you filter out the Salt packages from EPEL (for instance, by creating a new channel using Content Lifecycle Management)." I'll try that. Thanks Markus -----Original Message----- From: Strahil Nikolov <hunter86_bg(a)yahoo.com> Sent: Mittwoch, 4. November 2020 11:35 To: uyuni-users(a)opensuse.org; Thum, Markus <Markus.Thum(a)iese.fraunhofer.de> Subject: Re: [uyuni-users] Centos 7 Bootstrap fails with enabled Epel7 This looks like https://github.com/uyuni-project/uyuni/issues/1275 which was supposed to be fixed. Can you check and reopen ? Best Regards, Strahil Nikolov В сряда, 4 ноември 2020 г., 11:22:24 Гринуич+2, Markus.Thum(a)iese.fraunhofer.de <markus.thum(a)iese.fraunhofer.de> написа: Hallo, I’m new to Uyuni and trying to bootstrap a centos 7 client. Uyuni Server is at 2020.09. My problem: if the Epel7 Channel is added, the bootstrap fails. Without the bootstrapping succeeds. What I found out so far: Without EPEL the bootstrap x86_64 directory contains: PyYAML-3.10-11.el7.x86_64.rpm dmidecode-3.2-3.el7.x86_64.rpm libyaml-0.1.4-11.el7_0.x86_64.rpm openssl-1.0.2k-19.el7.x86_64.rpm openssl-libs-1.0.2k-19.el7.x86_64.rpm python-backports-1.0-8.el7.x86_64.rpm python-futures-2.1.3-0.8.8.uyuni.x86_64.rpm python-markupsafe-0.11-10.el7.x86_64.rpm python-msgpack-python-0.4.6-2.8.uyuni.x86_64.rpm python-psutil-1.2.1-0.10.8.uyuni.x86_64.rpm python-pycrypto-2.6.1-2.8.uyuni.x86_64.rpm python-simplejson-3.3.1-2.8.uyuni.x86_64.rpm python-tornado-4.2.1-5.el7.x86_64.rpm python-zmq-14.5.0-3.8.uyuni.x86_64.rpm python2-salt-3000-19.1.uyuni.x86_64.rpm python2-uyuni-common-libs-4.2.1-2.1.uyuni.x86_64.rpm rpm-python-4.11.3-43.el7.x86_64.rpm salt-3000-19.1.uyuni.x86_64.rpm salt-minion-3000-19.1.uyuni.x86_64.rpm zeromq-4.0.5-1.8.uyuni.x86_64.rpm With EPEL: PyYAML-3.10-11.el7.x86_64.rpm dmidecode-3.2-3.el7.x86_64.rpm libyaml-0.1.4-11.el7_0.x86_64.rpm openssl-1.0.2k-19.el7.x86_64.rpm openssl-libs-1.0.2k-19.el7.x86_64.rpm python-backports-1.0-8.el7.x86_64.rpm python-futures-2.1.3-0.8.8.uyuni.x86_64.rpm python-markupsafe-0.11-10.el7.x86_64.rpm python-msgpack-python-0.4.6-2.8.uyuni.x86_64.rpm python-psutil-1.2.1-0.10.8.uyuni.x86_64.rpm python-pycrypto-2.6.1-2.8.uyuni.x86_64.rpm python-simplejson-3.3.1-2.8.uyuni.x86_64.rpm python-tornado-4.2.1-5.el7.x86_64.rpm python-zmq-14.5.0-3.8.uyuni.x86_64.rpm python2-salt-3000-19.1.uyuni.x86_64.rpm python2-uyuni-common-libs-4.2.1-2.1.uyuni.x86_64.rpm rpm-python-4.11.3-43.el7.x86_64.rpm salt-3000-19.1.uyuni.x86_64.rpm salt-minion-3000-19.1.uyuni.x86_64.rpm zeromq-4.1.4-6.el7.x86_64.rpm The difference is an newer zeromq. Running bottstrap.sh on the client fails with the error message: ---> Package python-zmq.x86_64 0:14.5.0-3.8.uyuni will be installed --> Processing Dependency: libzmq.so.4()(64bit) for package: python-zmq-14.5.0-3.8.uyuni.x86_64 --> Running transaction check ---> Package python-backports.x86_64 0:1.0-8.el7 will be installed ---> Package python-zmq.x86_64 0:14.5.0-3.8.uyuni will be installed --> Processing Dependency: libzmq.so.4()(64bit) for package: python-zmq-14.5.0-3.8.uyuni.x86_64 --> Finished Dependency Resolution Error: Package: python-zmq-14.5.0-3.8.uyuni.x86_64 (susemanager:bootstrap) Requires: libzmq.so.4()(64bit) Am I doing something wrong? Gruß Markus

2 1

[uyuni-users] Fw: Mailing Lists Migration 10. Nov
by Pau Garcia 09 Nov '20

09 Nov '20

Hello This already happeneded to our mailing lists. Unfortunately, we were taken as canaries without notice. Please update your filters accordingly. Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +1 385-666-5608 SUSE Software Solutions Spain ________________________________ From: openSUSE Admins <admin(a)opensuse.org> Sent: Monday, November 9, 2020 9:59 AM To: Pau Garcia <pau.garcia(a)suse.com> Subject: Mailing Lists Migration 10. Nov Hi, We will be temporarly freezing the openSUSE Mailing Lists infrastructure for the time of migration on 10. Nov 2020 after 10:00 CET. We will send out another email confirming the details of the migration once it's finished. You can read on the details of the migration at https://en.opensuse.org/openSUSE:Mailing_Lists_Migration You are subscribed to the following mailing lists: opensuse-buildservice opensuse-project To unsubscribe from a mailing list, send an email to {listname}+unsubscribe(a)opensuse.org (for example opensuse-factory+unsubscribe(a)opensuse.org for the opensuse-factory mailing list) Sorry for the inconvenience, openSUSE Mailing Lists Admins

1 0

[uyuni-users] test
by per＠opensuse.org 08 Nov '20

08 Nov '20

testing 2

2 1

[uyuni-users] Special update for CVE-2020-16846, CVE-2020-17490 and CVE-2020-25592
by Pau Garcia 06 Nov '20

06 Nov '20

Hello Today we have released an unscheduled update for Uyuni 2020.09, for 3 security issues affecting the Salt master and minions: CVE-2020-16846, CVE-2020-17490 and CVE-2020-25592. First, a small warning. The current salt on openSUSE Leap 15.1/15.2 fixes the CVEs already, but contains a regression that breaks onboarding from WebUI and salt ssh managed minions. A fix for this is already in the openSUSE queue and should be released soon. Server ====== Please make sure you are on the most recent release (2020.09) and use the following commands on the Uyuni server: # zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… # zypper refresh # spacewalk-service stop # zypper update # spacewalk-service start This will download the required spacewalk-java and py26-compat-salt packages, as well as salt from openSUSE Leap 15.2 Proxies and Clients =================== Just sync your channels on the Uyuni Server for all operating systems, and that will get the updated salt packages. Then apply the updates to all your clients as you would do for any other security updates. More information ================ https://www.saltstack.com/blog/on-november-3-2020-saltstack-publicly-disclo… https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16846/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25592/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17490/ Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

1 0

[uyuni-users] Special update for CVE-2020-8028 (bsc#1175884)
by Julio González Gil 06 Nov '20

06 Nov '20

Dear lists, Today we released an unscheduled release on top of Uyuni 2020.09, for CVE-2020-16846, CVE-2020-17490 and CVE-2020-25592 that affect salt master and clients. First, a small warning. The current salt on openSUSE Leap 15.2/15.2 fixes the CVEs already, but contains a regression that breaks onboarding from WebUI and salt ssh manage minions. A fix for this is already in the openSUSE queue and should be released soon. Server ====== Please make sure you are on the most recent release (2020.09) and use the following commands on the Uyuni server: zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… zypper refresh spacewalk-service stop zypper update spacewalk-service start This will download the required spacewalk-java and py26-compat-salt packages and packages, as well as salt from openSUSE Leap 15.2 Proxies and Clients =================== Just sync your channels on the Uyuni Server for all operating systems, and that will get the updated salt packages. Then apply the updates to all your clients as you would do for any other security updates. More information ================ https://www.saltstack.com/blog/on-november-3-2020-saltstack-publicly-disclo… https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16846/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25592/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17490/ -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 1

[uyuni-users] Centos 7 Bootstrap fails with enabled Epel7
by Markus.Thum＠iese.fraunhofer.de 04 Nov '20

04 Nov '20

Hallo, I'm new to Uyuni and trying to bootstrap a centos 7 client. Uyuni Server is at 2020.09. My problem: if the Epel7 Channel is added, the bootstrap fails. Without the bootstrapping succeeds. What I found out so far: Without EPEL the bootstrap x86_64 directory contains: PyYAML-3.10-11.el7.x86_64.rpm dmidecode-3.2-3.el7.x86_64.rpm libyaml-0.1.4-11.el7_0.x86_64.rpm openssl-1.0.2k-19.el7.x86_64.rpm openssl-libs-1.0.2k-19.el7.x86_64.rpm python-backports-1.0-8.el7.x86_64.rpm python-futures-2.1.3-0.8.8.uyuni.x86_64.rpm python-markupsafe-0.11-10.el7.x86_64.rpm python-msgpack-python-0.4.6-2.8.uyuni.x86_64.rpm python-psutil-1.2.1-0.10.8.uyuni.x86_64.rpm python-pycrypto-2.6.1-2.8.uyuni.x86_64.rpm python-simplejson-3.3.1-2.8.uyuni.x86_64.rpm python-tornado-4.2.1-5.el7.x86_64.rpm python-zmq-14.5.0-3.8.uyuni.x86_64.rpm python2-salt-3000-19.1.uyuni.x86_64.rpm python2-uyuni-common-libs-4.2.1-2.1.uyuni.x86_64.rpm rpm-python-4.11.3-43.el7.x86_64.rpm salt-3000-19.1.uyuni.x86_64.rpm salt-minion-3000-19.1.uyuni.x86_64.rpm zeromq-4.0.5-1.8.uyuni.x86_64.rpm With EPEL: PyYAML-3.10-11.el7.x86_64.rpm dmidecode-3.2-3.el7.x86_64.rpm libyaml-0.1.4-11.el7_0.x86_64.rpm openssl-1.0.2k-19.el7.x86_64.rpm openssl-libs-1.0.2k-19.el7.x86_64.rpm python-backports-1.0-8.el7.x86_64.rpm python-futures-2.1.3-0.8.8.uyuni.x86_64.rpm python-markupsafe-0.11-10.el7.x86_64.rpm python-msgpack-python-0.4.6-2.8.uyuni.x86_64.rpm python-psutil-1.2.1-0.10.8.uyuni.x86_64.rpm python-pycrypto-2.6.1-2.8.uyuni.x86_64.rpm python-simplejson-3.3.1-2.8.uyuni.x86_64.rpm python-tornado-4.2.1-5.el7.x86_64.rpm python-zmq-14.5.0-3.8.uyuni.x86_64.rpm python2-salt-3000-19.1.uyuni.x86_64.rpm python2-uyuni-common-libs-4.2.1-2.1.uyuni.x86_64.rpm rpm-python-4.11.3-43.el7.x86_64.rpm salt-3000-19.1.uyuni.x86_64.rpm salt-minion-3000-19.1.uyuni.x86_64.rpm zeromq-4.1.4-6.el7.x86_64.rpm The difference is an newer zeromq. Running bottstrap.sh on the client fails with the error message: ---> Package python-zmq.x86_64 0:14.5.0-3.8.uyuni will be installed --> Processing Dependency: libzmq.so.4()(64bit) for package: python-zmq-14.5.0-3.8.uyuni.x86_64 --> Running transaction check ---> Package python-backports.x86_64 0:1.0-8.el7 will be installed ---> Package python-zmq.x86_64 0:14.5.0-3.8.uyuni will be installed --> Processing Dependency: libzmq.so.4()(64bit) for package: python-zmq-14.5.0-3.8.uyuni.x86_64 --> Finished Dependency Resolution Error: Package: python-zmq-14.5.0-3.8.uyuni.x86_64 (susemanager:bootstrap) Requires: libzmq.so.4()(64bit) Am I doing something wrong? Gruß Markus

2 1

[uyuni-users] Use non-privileged user for ssh_push registered client
by Bidault, Philippe 04 Nov '20

04 Nov '20

Hi all, I want to use non-root user for ssh-push server registration and patch management. However, I can't find any documentation regarding this. This link https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/contact… only seems to apply for bootstrapping through ssh. >From what I can see, this unprivileged user would need write/read permissions on /etc/yum.repo.d, /etc/apt/sources.list.d or /etc/zypp depending of the OS, and permissions to execute yum/apt/zypper commands. And I guess some extra configurations needed as the Uyuni server will sudo the commands. Does somebody already worked on this ? 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: http://www.getronics.com/legal/

2 2

[uyuni-users] DNF module support Uyuni
by Bidault, Philippe 04 Nov '20

04 Nov '20

Hi all, Does somebody know when the DNF modules available in CentOS 8 for example will be supported in Uyuni ? If we enable some DNF modules on a CentOS 8, we currently have mismatch between updates showed in the Web UI and real available updates. 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: http://www.getronics.com/legal/

4 8

[uyuni-users] What do YOU want?
by Pau Garcia 03 Nov '20

03 Nov '20

Hello What features and enhancements would you like to see in the future in Uyuni? Is it Terraform integration? Ansible integration? Split it in several applications to make it slimmer? Support for more operating systems? Which ones? Remove some feature? Let's open the thread here and let's also discuss that at hour Uyuni Community Hours, today at 4pm CET! Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

5 4

[uyuni-users] errata-import.py
by Paul-Andre Panon 02 Nov '20

02 Nov '20

Hi, I was a little confused because, while diving in the archives for how to fix errata-import.py failing to import Ubuntu Errata, I came across Philippe Bidault's August 7 e-mail where he said: >I have noticed that the CVE ID were truncated, importing them from the philicious script >(https://github.com/philicious/spacewalk-scripts/blob/master/errata-impor t.py) > >Truncated because of the regexp limitation "CVE = "(?P<cve>CVE-\d{4}-\d{4})". > >I have modified it to accept 5 digits ( CVE = "(?P<cve>CVE-\d{4}-\d{5} ), but >to be able to import them again, I would need to remove all the erratas from >the Ubuntu repositories. but I couldn't actually find that regexp in the errata-import.py script, so I'm not quite sure how to apply that fix. However I did see another reference to PR23 for errata-import.pl and used that info to create --- errata-import.py.old 2020-10-31 00:36:47.471814842 -0700 +++ errata-import.py 2020-10-31 01:01:28.297772339 -0700 @@ -3,6 +3,7 @@ # Pedro Andujar || twitter: pandujar || email: @segfault.es || @digitalsec.net # # Changelog: +# 2020-10-31 - Allow to work also with API 24 on Uyuni 2020.06 and later # 2017-11-06 - Set UTF-8 caracter encoding to import errata from Spacewalk correctly # 2015-08-25 - Fix to support python2.6. Added reattempts # 2015-06-19 - Limit description 4000 chars @@ -35,6 +36,7 @@ client = '' publish = True attempts = 0 +apiversion = 0 #xmlrpc connect to server and retrieve key def connect(url, login, passwd): @@ -43,6 +45,8 @@ client = xmlrpclib.Server(url, verbose=0) key = client.auth.login(login, passwd) print "[+] Connected to %s" % url + apiversion = int(client.api.get_version()) + print "[+] with API version %d" % apiversion except Exception, e: print "[-] Error connecting to %s: %s" % (url, e) sys.exit(1) @@ -104,7 +108,10 @@ def createErratum(key, erratum, issue_date, erratainfo, keywords, packageids, cves, publish, channels): try: print "[+] Creating errata %s:" % erratum - print client.errata.create(key, erratainfo, bug, keywords, [], publish, list(set(channels))) + if apiversion < 24: + print client.errata.create(key, erratainfo, bug, keywords, [], publish, list(set(channels))) + else: + print client.errata.create(key, erratainfo, bug, keywords, [], list(set(channels))) #Include aditional info using setDetails method (not supported by create method) #http://www.spacewalkproject.org/documentation/api/2.3/handlers/ErrataHand ler.html#setDetails client.errata.setDetails(key, erratum, {'update_date': issue_date}) That patch updates errata-import.py (which I have used for parsing and submitting Ubuntu errata/patches into Spacewalk) to work with Uyuni. If someone wants to submit it to philicious as a PR, feel free to do so. Cheers, Paul-Andre Panon, B.Sc. Senior Systems Administrator Video Security & Analytics -- *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…>.* -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

1 2