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