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-Locationhttps://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
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
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
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)
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