- Uyuni Users - openSUSE Mailing Lists

Uyuni 2020.11 is released!

by Julio González Gil

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

3 days, 15 hours

1
0
0 0

After Upgrade 2020/09: Repository errors; increased shared memory usage

by Tobias Crefeld

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.

3 days, 15 hours

2
2
0 0

Uyuni starvation, not checking registered client

by Bidault, Philippe

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/

1 week

2
2
0 0

Uyuni Community Hours 27.11.2020

by Pau Garcia

** 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 week, 2 days

1
0
0 0

http to https in generated emails?

by Simon Avery

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?

1 week, 4 days

3
5
0 0

testing

by per＠opensuse.org

testing123.

1 week, 4 days

1
0
0 0

IMPORTANT: Recent changes for the mailing lists

by Julio González Gil

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 week, 6 days

1
0
0 0

[uyuni-users] http to https in generated emails?

by Simon Avery

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 week, 6 days

1
0
0 0

[uyuni-users] Centos 7 Bootstrap fails with enabled Epel7

by Markus.Thum＠iese.fraunhofer.de

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 weeks, 6 days

2
1
0 0

[uyuni-users] Fw: Mailing Lists Migration 10. Nov

by Pau Garcia

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

2 weeks, 6 days

1
0
0 0

2020

2019

2018

Uyuni Users