- ARCHIVED: Uyuni Users

A double dose of issues that are probably related
by Len Ewen 07 Dec '20

07 Dec '20

I've been working to get a test box up and running for a while now as time permitted and for reasons I don't know I cannot install packages to new servers, I just push the button and it doesn't do anything. The second issue is I can't schedule any repo syncs. I try to schedule the sync and nothing happens. I can get remote commands to work, but nothing else. Suggestions? I have no idea where to even look. I am getting this in /var/log/messages 2020-12-07T15:44:51.960474-05:00 uyuni salt-master[2166]: Traceback (most recent call last): 2020-12-07T15:44:51.960667-05:00 uyuni salt-master[2166]: File "/usr/lib/python3.6/site-packages/salt/loader.py", line 853, in grains 2020-12-07T15:44:51.960840-05:00 uyuni salt-master[2166]: ret = funcs[key](**kwargs) 2020-12-07T15:44:51.961009-05:00 uyuni salt-master[2166]: File "/usr/lib/python3.6/site-packages/salt/grains/extra.py", line 106, in uefi 2020-12-07T15:44:51.961274-05:00 uyuni salt-master[2166]: "efi-secure-boot": __secure_boot(), 2020-12-07T15:44:51.961489-05:00 uyuni salt-master[2166]: File "/usr/lib/python3.6/site-packages/salt/grains/extra.py", line 97, in __secure_boot 2020-12-07T15:44:51.961711-05:00 uyuni salt-master[2166]: with salt.utils.files.fopen(sboot[0], "rb") as fd: 2020-12-07T15:44:51.961877-05:00 uyuni salt-master[2166]: File "/usr/lib/python3.6/site-packages/salt/utils/files.py", line 399, in fopen 2020-12-07T15:44:51.962044-05:00 uyuni salt-master[2166]: f_handle = open(*args, **kwargs) # pylint: disable=resource-leakage 2020-12-07T15:44:51.962203-05:00 uyuni salt-master[2166]: PermissionError: [Errno 13] Permission denied: '/sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data' --------------- Len Ewen Systems Administrator 1 Information Technology University of Indianapolis (317) 788-3362 [image: UIndyIT.jpg] Confidentiality Notice: This communication and/or its content are for the sole use of the intended recipient, and may be privileged, confidential, or otherwise protected from disclosure by law. If you are not the intended recipient, please notify the sender and then delete all copies of it. Unless you are the intended recipient, your use or dissemination of the information contained in this communication may be illegal.

1 0

Uyuni disable SSL comunication with salt-api
by Cristian Gherman 02 Dec '20

02 Dec '20

Hello, Where I can disable SSL comunication Uyuni to Salt-api? I can't use my local bot to comunicate with salt-api. Thanks -- Cristian Gherman Support / PHP developer cristian.gherman(a)reea.net | www.reea.net | +4 0365410942

1 0

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