- ARCHIVED: Uyuni Development

Uyuni Community Hours
by Pau Garcia 26 Feb '21

26 Feb '21

________________________________________________________________________________ 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_OTIyZTM4OWUtNWQ5Ni00…> Or call in (audio only) +34 917 94 59 77,,861379706#<tel:+34917945977,,861379706#> Spain, Madrid Phone Conference ID: 861 379 706# 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

Open positions to work on Uyuni!
by Johannes Renner 17 Feb '21

17 Feb '21

Hello, for those of you who might be interested but were not present during the last community hour: We currently have two open positions at SUSE (with flexible location) to work on Uyuni full-time, and if you are familiar with the project or if you are already a contributor this would be a great advantage! Here are the links to those positions: https://jobs.suse.com/us/en/job/71000171/Software-Engineer-Flexible-Location https://jobs.suse.com/us/en/job/71000288/Software-Engineer-Flexible-Location Please reach out to me in case you have any questions. Otherwise feel free to apply directly via those pages, or maybe consider to recommend those jobs to your friends. Greetings, Johannes -- 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: Felix Imendörffer

1 0

Uyuni 2021.01 fix for /etc/uyuni-release and WebUI version and release notes update
by Julio González Gil 08 Feb '21

08 Feb '21

Hello, Those of you that already updated to 2021.01 maybe already noticed that the WebUI incorrectly says "2021.02", and the same information is present at /etc/uyuni-release [1] We added an update to the Patches repository [2] that can be installed on top of 2021.01 to fix this issue. The patches repository also contains updated release notes with the information about the WebUI not starting because of a vendor change for some Java dependencies [3] To get the fixes installed, follow the next steps (as root) at the Uyuni Server: 1. Install the patches repository (if it's already present, zypper will exit with an error that you can just ignore) zypper ar https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… 2. Refresh the repositories: zypper ref 3. Stop the services: spacewalk-service stop 4. Run the update (this will get you updates for at least release-notes-uyuni, spacewalk-base, spacewalk-base-minimal, spacewalk-base-minimal-config, spacewalk-common, spacewalk-html, spacewalk-postgresql, susemanager-web-libs and any other pending updates from Leap): zypper up 5. After the update is complete, start the services: spacewalk-service start You will see the correct version 2021.01 at the WebUI, /etc/uyuni-release as well as the updated release notes. NOTE: Starting the services will tell you about a schema upgrade. Do not worry. That is perfectly normal and you will see that message each time you start the services. An upgrade is always attempted, in case there is something pending. [1] https://github.com/uyuni-project/uyuni/issues/3233 [2] https://www.uyuni-project.org/pages/patches.html [3] https://github.com/uyuni-project/uyuni/issues/3230 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Uyuni 2021.01 is released!
by Julio González Gil 05 Feb '21

05 Feb '21

Hello everyone! We are happy to announce the immediate availability of Uyuni 2021.01 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.01, 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 or later, 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: * Fix version comparison algorithm for deb packages (Ubuntu) * New products enabled * SAP content * CPU mitigations formula * Vendor change on SP migration * Autoinstallation of older operating systems * Oracle Linux ULN repositories * CentOS 6 repositories * New countries and timezones * Cluster management: upgrade plan * Yomi refresh * Uyuni Server connections are always and only secure * Monitoring updates - Grafana 7.3.1 - Prometheus 2.22.1 - Prometheus Exporter Exporter for Ubuntu 18.04/20.04 and Debian 9/10 Please check the release notes for full details. For the fixes for salt CVEs, there will be an Uyuni 2021.02 release by the end of February as the fixes rescheduled by upstream [2] 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 2021.01 As always, we hope you will enjoy Uyuni 2021.01 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html [2] https://saltproject.io/security_announcements/salt-feb-4th-cve-release-dela… -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 3

Uyuni Community Hours
by Pau Garcia 03 Feb '21

03 Feb '21

Agenda TBD. If interested in any topic in particular, please send an e-mail to the mailing list! ________________________________________________________________________________ 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_MjA2MmI2MDUtZmYzZS00…> Or call in (audio only) +34 917 94 59 77,,868473242#<tel:+34917945977,,868473242#> Spain, Madrid Phone Conference ID: 868 473 242# 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

Re: Merging custom CentOS packages to Master
by Stefan Bluhm 03 Feb '21

03 Feb '21

Hello Michael, the new packages are in my repo: https://build.opensuse.org/project/monitor/home:sbluhm:systemsmanagement:Uy… As they are in a "hacking" stage, I would need to revisit them to align them to standards. I believe the project config is public (let me know if not). Below the list of packages. Let me know if you want them in any other format (text file, CSV,...) EPEL packages (https://download.fedoraproject.org/pub/epel/8/Everything/x86_64): ============== google-gson.noarch 2.8.2-4.el8 @epel libgsasl.x86_64 1.8.0-8.el8 @epel libntlm.x86_64 1.6-1.el8 @epel libsodium.x86_64 1.0.18-2.el8 @epel libunwind.x86_64 1.3.1-3.el8 @epel openpgm.x86_64 5.2.122-21.el8 @epel perl-Net-LibIDN.x86_64 0.12-35.el8 @epel python-django3-bash-completion.noarch 3.1.4-1.el8 @epel python2-psutil.x86_64 5.7.3-1.el8 @epel python3-asgiref.noarch 3.2.10-1.el8 @epel python3-cheetah.x86_64 3.2.3-2.el8 @epel python3-cheroot.noarch 8.5.2-1.el8 @epel python3-cherrypy.noarch 18.4.0-1.el8 @epel python3-django3.noarch 3.1.4-1.el8 @epel python3-future.noarch 0.18.2-2.el8 @epel python3-jaraco.noarch 6.2-6.el8 @epel python3-jaraco-functools.noarch 2.0-4.el8 @epel python3-ldap3.noarch 2.8.1-2.el8 @epel python3-more-itertools.noarch 7.2.0-3.el8 @epel python3-msgpack.x86_64 0.6.2-1.el8 @epel python3-pam.noarch 1.8.4-6.el8 @epel python3-portend.noarch 2.6-1.el8 @epel python3-psutil.x86_64 5.7.3-1.el8 @epel python3-pyvmomi.noarch 7.0.1-1.el8 @epel python3-simplejson.x86_64 3.17.0-2.el8 @epel python3-sqlparse.noarch 0.2.4-6.el8 @epel python3-tempora.noarch 1.14.1-5.el8 @epel python3-tornado.x86_64 6.0.2-1.el8 @epel python3-trustme.noarch 0.6.0-4.el8 @epel python3-zc-lockfile.noarch 2.0-2.el8 @epel python3-zmq.x86_64 19.0.0-1.el8 @epel tomcat-native.x86_64 1.2.23-1.el8 @epel zeromq.x86_64 4.3.3-1.el8 @epel PowerTools (http://mirror.centos.org/centos-8/8/PowerTools/x86_64/os/): =========== antlr-tool.noarch 2.7.7-56.module_el8.0.0+30+832da3a1 @powertools apache-commons-beanutils.noarch 1.9.3-4.module_el8.0.0+30+832da3a1 @powertools apache-commons-logging.noarch 1.2-13.module_el8.0.0+30+832da3a1 @powertools bcel.noarch 6.2-2.module_el8.0.0+30+832da3a1 @powertools cglib.noarch 3.2.4-7.module_el8.0.0+30+832da3a1 @powertools jakarta-oro.noarch 2.0.8-23.module_el8.0.0+30+832da3a1 @powertools javamail.noarch 1.5.2-7.module_el8.0.0+30+832da3a1 @powertools javapackages-filesystem.noarch 5.3.0-2.module_el8.0.0+30+832da3a1 @powertools javapackages-tools.noarch 5.3.0-2.module_el8.0.0+30+832da3a1 @powertools jdom.noarch 1.1.3-17.module_el8.0.0+30+832da3a1 @powertools jsch.noarch 0.1.54-6.module_el8.0.0+30+832da3a1 @powertools jzlib.noarch 1.1.3-8.module_el8.0.0+30+832da3a1 @powertools log4j12.noarch 1.2.17-22.module_el8.0.0+30+832da3a1 @powertools objectweb-asm.noarch 6.2-5.module_el8.0.0+30+832da3a1 @powertools perl-B-Hooks-EndOfScope.noarch 0.21-6.el8 @powertools perl-Class-Data-Inheritable.noarch 0.08-27.el8 @powertools perl-Class-Method-Modifiers.noarch 2.12-8.el8 @powertools perl-Class-Singleton.noarch 1.5-9.el8 @powertools perl-Date-ISO8601.noarch 0.005-2.el8 @powertools perl-DateTime.x86_64 2:1.50-1.el8 @powertools perl-DateTime-Locale.noarch 1.17-2.el8 @powertools perl-DateTime-TimeZone.noarch 2.19-1.el8 @powertools perl-DateTime-TimeZone-SystemV.noarch 0.010-3.el8 @powertools perl-DateTime-TimeZone-Tzfile.noarch 0.011-3.el8 @powertools perl-Devel-CallChecker.x86_64 0.008-3.el8 @powertools perl-Devel-Caller.x86_64 2.06-15.el8 @powertools perl-Devel-LexAlias.x86_64 0.05-16.el8 @powertools perl-Devel-StackTrace.noarch 1:2.03-2.el8 @powertools perl-Dist-CheckConflicts.noarch 0.11-11.el8 @powertools perl-DynaLoader-Functions.noarch 0.003-2.el8 @powertools perl-Eval-Closure.noarch 0.14-5.el8 @powertools perl-Exception-Class.noarch 1.44-2.el8 @powertools perl-Module-Implementation.noarch 0.09-15.el8 @powertools perl-Package-Stash.noarch 0.37-9.el8 @powertools perl-Package-Stash-XS.x86_64 0.28-17.el8 @powertools perl-PadWalker.x86_64 2.3-2.el8 @powertools perl-Params-Classify.x86_64 0.015-2.el8 @powertools perl-Params-Validate.x86_64 1.29-5.el8 @powertools perl-Params-ValidationCompiler.noarch 0.27-1.el8 @powertools perl-Ref-Util.noarch 0.203-4.el8 @powertools perl-Ref-Util-XS.x86_64 0.117-2.el8 @powertools perl-Role-Tiny.noarch 2.000006-2.el8 @powertools perl-Specio.noarch 0.42-2.el8 @powertools perl-Sub-Exporter-Progressive.noarch 0.001013-5.el8 @powertools perl-Sub-Identify.x86_64 0.14-6.el8 @powertools perl-Variable-Magic.x86_64 0.62-3.el8 @powertools perl-namespace-autoclean.noarch 0.28-10.el8 @powertools perl-namespace-clean.noarch 0.27-7.el8 @powertools perltidy.noarch 20180220-1.el8 @powertools slf4j-log4j12.noarch 1.7.25-4.module_el8.0.0+30+832da3a1 @powertools Modules from Powertools: javapackages-tools 201801 Modules from AppStream httpd 2.4 jmc rhel8 maven 3.6 perl 5.26 perl-DBD-Pg 3.7 perl-DBI 1.641 perl-IO-Socket-SSL 2.066 perl-libwww-perl 6.34 pki-deps 10.6 postgresql 12 python27 2.7 python36 3.6 Best wishes, Stefan ----- Ursprüngliche Mail ----- Von: "Michael Calmer" <mc(a)suse.de> An: "devel" <devel(a)lists.uyuni-project.org> Gesendet: Mittwoch, 3. Februar 2021 10:34:46 Betreff: Re: Merging custom CentOS packages to Master Hi Stefan We need a bit of time to review this an give a proper answer. We hope that we can enable CentOS building on Master by end of the week and then we can try some tricks to include a selection of EPEL and PowerTools packages into a resulting repo for Uyuni server. These packages would be refreshed with every "release" of Uyuni. So we would get also fixes of these packages when they appear in EPEL/PowerTools. What would help is, if you could provide a list of packages which are required and the source where it come from. Also packages you want to submit newly . And the list of Steams which needs to be enabled would help too. Thanks Am Dienstag, 2. Februar 2021, 12:37:29 CET schrieb Stefan Bluhm: > Hello all, > > Next big activity is pushing the required CentOS 8 packages to the Uyuni Master branches. > > The distribution of packages to repositories on the Uyuni Server are: > - Uyuni Master: 98 + Uyuni Master Other: 58 > > - New custom packages: 46 > - EPEL: 34 > - PowerTools: 50 > > - CentOS 8 BaseOS: 477 + CentOS 8 AppStream: 196 > > > 1) I would push my newly created custom packages including kits to "Uyuni Master Other". Are there any guidelines? Otherwise I would just split out the change log of the spec file and submit. > > 2) What do we do about the EPEL and PowerTools packages? I feel a bit uneasy of pushing 84 packages (+ probable build dependencies) to OPS. Especially when you consider that these packages need to be maintained and monitored for security fixes. > > 3) One more (not so pleasant) thought is the module system. Installation requires activation of 10 modules and deactivation of 2 more modules. If we go for loading all packages of point 2) into OBS, we might as well add the ones from the modules and create an Uyuni Server module (one per major release?). That would simplify the user experience and probably use the module system as intended (but kill maintainability...). > > Let me know your thoughts and ways to continue. > > Best wishes, > > Stefan > -- 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: Felix Imendörffer (HRB 36809, AG Nürnberg)

1 0

PXE Boot process/trouble shooting
by Stefan Bluhm 24 Jan '21

24 Jan '21

Hello all, at the moment, I am looking at the automated kickstart and PXE boot functionality. My boot is stuck somewhere but I cannot spot anything in the logs or what/where something is supposed to happen. Can you please assist me in troubleshooting? This is where I am at (CentOS Uyuni Server): 1. Kickstartable tree is downloaded (via reposync). 2. Distribution is set up via WebUI. (Tree path=/var/spacewalk/rhn/kickstart/1/centos8-baseos-x86_64 and it exists on the file system for apache:apache). 3. Basic Profile created via WebUI ("kickstart-profile", OS seems OK, "Available tree" as in 2., software URL: /ks/dist/org/1/centos8-baseos-x86_64 ) 4. DHCP set up Now starting up a server: 5. PXE picked up DHCP. 6. PXE loaded the blue Cobbler menu Here, I can chose "kickstart-profile:1:test" 7. Now, whenever that entry is selected, the blue screen flashes and I am pretty much at the same place as 6. Pressing tab to see the boot details, these lines are shown: /images/centos8-baseos-x86_64:1:test/vmlinuz initrd=/images/centos8-baseos-x86_64:1:test/initrd.img ks=http://dev2.bluhm-de.com/cblr/svc/op/autoinstall/profile/kickstart-profi… BOOTIF=01-00-0a-21-31-56-34 wget http://dev2.bluhm-de.com/cblr/svc/op/autoinstall/profile/kickstart-profile:… BOOTIF=01-00-0a-21-31-56-34 wget http://server/images/centos8-baseos-x86_64:1:test/vmlinuz wget http://server/images/centos8-baseos-x86_64:1:test/initrd.img All download content. Also firewall is disabled. So I am not really sure what exactly is supposed to happen when you press [enter] at step 6 above. What would be the real next step? Download a file? Boot an already downloaded file? Any hints for debugging would be great. Thank you and best wishes, Stefan

1 1

Uyuni Community Hours
by Pau Garcia 20 Jan '21

20 Jan '21

Back from vacation! Agenda: 1. Uyuni 2021.01. What's new. 2. Ansible integration. SUSE did some research and will present the outcome. 3. RHEL/CentOS modularity with CLM 4. Open RFCs 5. Q&A ________________________________________________________________________________ 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_ZDVkMWE0YzQtMWIxNy00…> Or call in (audio only) +34 917 94 59 77,,749456124#<tel:+34917945977,,749456124#> Spain, Madrid Phone Conference ID: 749 456 124# 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

Got opinions about Uyuni Docs?
by Lana Brindley 12 Jan '21

12 Jan '21

Hi everyone, Lana from the docs team here. We're planning to do some work on the Uyuni documentation in the new year, and we'd like to get your feedback on what you would like to see. We've got a short survey up for you to fill out: https://www.surveymonkey.com/r/V73GQJR <https://www.surveymonkey.com/r/V73GQJR> Make sure you get your responses in, so that we can include your suggestions. At the moment, the Uyuni documentation is largely created from the same source as SUSE Manager documentation, but we know that that doesn't always work as well as it could. We specifically want to hear from you on what content you think is required for Uyuni that might be different to what is required for SUSE Manager. Thanks, Lana -- Lana Brindley @Loquacities Technical Writer - SUSE Manager "The question is," said Alice, "whether you can make words mean so many different things."

1 2

reposync issues on CentOS - [Errno 14] curl#1 - "Protocol "b'http" not supported or disabled in libcurl".
by Stefan Bluhm 09 Jan '21

09 Jan '21

Hello, me again... I tried to run reposync on CentOS with Zypper and DNF as backend. In both cases, I get these messages for http links: [Errno 14] curl#1 - "Protocol "b'http" not supported or disabled in libcurl". for https links: [Errno 14] curl#1 - "Protocol "b'https" not supported or disabled in libcurl". curl cli can download the sources without issues. I also tried a minimal pycurl script and it can download a https rpm file without issues. So it is not a setup issue. Not sure if i am at the right place but I cannot identify any potential issues in spacewalk/satellite_tools/download.py. The Urls seem to be passed properly. Are you aware of these issues or can pinpoint me where to look? Maybe the exact place that is calling/configuring pycurl to see what is passed? Thank you and best wishes, Stefan

1 0