February 2021 - Uyuni Development - openSUSE Mailing Lists

by Pau Garcia

________________________________________________________________________________ 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 month, 3 weeks

1
0
0 0

Open positions to work on Uyuni!

by Johannes Renner

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

2 months

1
0
0 0

Uyuni 2021.01 fix for /etc/uyuni-release and WebUI version and release notes update

by Julio González Gil

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

2 months, 1 week

1
0
0 0

Uyuni 2021.01 is released!

by Julio González Gil

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

2 months, 2 weeks

1
3
0 0

Uyuni Community Hours

by Pau Garcia

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-…> ________________________________________________________________________________

2 months, 2 weeks

1
0
0 0

Re: Merging custom CentOS packages to Master

by Stefan Bluhm

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)

2 months, 2 weeks

1
0
0 0

Merging custom CentOS packages to Master

by 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

2 months, 2 weeks

3
2
0 0

2021

2020

2019

2018

Uyuni Development February 2021