- ARCHIVED: Uyuni Development

Uyuni 2022.11 is released!
by Julio Gonzalez 21 Nov '22

21 Nov '22

VERY IMPORTANT: 2022.11 will require a special procedure if you are not upgrading from 2022.10 Make sure you read the release notes for all the versions between the one you are using now, and 2022.11! We are happy to announce the availability of Uyuni 2022.11. Most openSUSE mirrors should already have 2022.11, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.11, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Instructions to disable custom channel automatic synchronization - Allow more tools for network management for the Uyuni Server - Monitoring: Grafana update to 8.5.13 - Monitoring: Fix TLS configuration and enable client certificate authentication for Blackbox exporter - Traditional stack being removed Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.11 As always, we hope you will enjoy Uyuni 2022.11 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 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 14 Nov '22

14 Nov '22

Hello! ################################################# WARNING: Instead of running `zypper up` as provided by the instructions at the website, we strongly recommend using `zypper up|tee /tmp/update.log` or similar, so you can find errors during the migration in the unlikely event they happen ################################################# Several users at Gitter and GitHub have reported that after the update to Uyuni 2022.10, and after applying the patch from last week, Cobbler had problems to start because templates files were not found, so some features were broken, such as: - Onboarding new clients - Removing existing clients - Autoinstallation In such cases you can see errors in Cobbler like: cobbler.cexceptions.CX: 'serializer: error loading collection profile: Invalid automatic installation template file location /var/lib/cobbler/templates/ xxxxxxxxxxxx.cfg, file not found This problem was caused because the "autoinstall" attribute for the Cobbler collections was wrongly migrated at the time of running the migration from the old Cobbler collections from version 2 to version 3, making Cobbler not able to find the "templates" files for the profiles anymore. Any subdirectory was removed from the "autoinstall" attribute. For "Autoinstallation" profiles generated using Uyuni, the "autoinstall" files are generated and placed by Uyuni at "upload/" and "wizard/" subdirectories of `/var/lib/cobbler/templates/`. These Cobbler collections and templates files (for Uyuni created profiles) are recreated by Uyuni in case they are missing, on every spacewalk-services restart. With this new upgrade, we have fixed the migration of the "autoinstall" attribute from Cobbler collections, and make the migration to run again in order to fix any possible inconsistency created by the execution of the wrong migration from the previous patch, so Cobbler will be now able to find the "autoinstall" templates and finish the startup. The migration will run automatically during the upgrade, if there is any unexpected issue during the migration you should see some errors when zypper is updating "cobbler" or "spacewalk-setup" packages. In the unlikely event there are still some conflicts for the `.cfg` files, you will get instructions provided by the upgrade, to fix the issue. A patch for Uyuni 2022.10 is now available, in case you are affected, so you do not need to wait for Uyuni 2022.11 (this version will also include this fix). You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html (please be aware of the WARNING at the beginning of this email!) Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Security patches and feature patches for Uyuni Server 2022.10
by Julio Gonzalez 04 Nov '22

04 Nov '22

Hello! ### Cobbler migration Some users have reported that after the Update to Uyuni 2022.10, there are still some problems related to Cobbler, where collections are not migrated, so the cobbler service fails to start at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels This is not happening for most users, but we are now releasing a patch to address it, and migrate any collections provided by any past cobbler version. ### File descriptors leakage Some users reported that, after updating to Uyuni 2022.10, and after some days, the Server stopped working, and they saw a steady increase of "open files" or "allocated file descriptors". This was caused after the migration to log4j2. Every time a taskomatic job object gets created, it initializes its own logger programmatically to write its logs into a file. The lifecycle of a job object is relatively short, but the log4j2 runtime doesn't know it. When it gets permissions to write into a file, there's nothing to release it after the job is over. Moreover the log4j2 keeps track of loggers based on the class names. It effectively means we mutate the same logger object in memory over and over again with every new taskomatic job. The fix adds functionality to re-initialize the logger when a new job comes around, dropping any file handler it has. ### Security fixes During a SUSE Manager and Uyuni security audit, the SUSE security team reported three vulnerabilities at the spacewalk-java source package (which provides spacewalk-java-* or spacewalk-taskomatic packages): * CVE-2022-31255: Fix directory path traversal vulnerability * CVE-2022-43754: Fix reflected cross site scripting vulnerability * CVE-2022-43753: Fix arbitrary file disclosure vulnerability You can find more details at: https://www.suse.com/security/cve/CVE-2022-31255.html https://www.suse.com/security/cve/CVE-2022-43754.html https://www.suse.com/security/cve/CVE-2022-43753.html A patch for Uyuni 2022.10 to fix all the issues was just published, and because of the security issues, it is strongly recommended you update your server, even if you are not affected by the cobbler migration issues or the file descriptors leakage. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thanks to all users that reported the issues, and helped with the debugging. Happy hacking!

1 0

Canceled: Uyuni Community Hours
by jgonzalez＠suse.com 24 Oct '22

24 Oct '22

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 24 Oct '22

24 Oct '22

Hello! Several users at Gitter have reported that after the Update to Uyuni 2022.10, and after applying the patch from last week, that the cobbler package fails to update, or that the cobbler service is not starting at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The problem was causes because of bugs at migration scripts for cobbler itself. Such bugs are only happening for long time Uyuni users where the cobbler configuration is old enough, so most users should not notice this problem. If you are affected, you will see the following error while installing the cobbler package: > schema.SchemaError: Key 'proxy_url_ext' error: > None should be instance of 'str' Or the following error at the logs, when starting cobbler: > cobblerd[32057]: schema.SchemaError: Key 'allow_duplicate_hostnames' error: > cobblerd[32057]: 0 should be instance of 'bool' The fix is at the SR: https://build.opensuse.org/package/rdiff/systemsmanagement:Uyuni:Master/cob… (an OBS account is required to see the diff) A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 20 Oct '22

20 Oct '22

Hello! Several users at GitHub, mailing lists and Gitter have reported that after the Update to Uyuni 2022.10, cobbler is not starting at the Uyuni Server, therefore affecting some features, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The following bug reports are related to this problem: - https://github.com/uyuni-project/uyuni/issues/6037 - https://github.com/uyuni-project/uyuni/issues/6041 - https://github.com/uyuni-project/uyuni/issues/6045 The problem was caused for a bug at the script for the migration of the settings and collections to Cobbler 3.3.3 The fix is at the PR https://github.com/uyuni-project/uyuni/pull/6050 A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Java rhn webapp not starting on Enterprise Linux 9
by Stefan Bluhm 19 Oct '22

19 Oct '22

Hello all, I am having an issue on starting the rhn Webapp on Tomcat with Enterprise Linux 9. Can you give me some pointers on what to look at? I have partially bodged together my own Java jars... From what I can tell, this seems to be the only log entry (unless I am overlooking something): /var/log/tomcat/localhost.2022-10-17.log 17-Oct-2022 21:07:12.279 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [com.redhat.rhn.webapp.RhnServletListener] java.lang.NullPointerException at com.redhat.rhn.common.hibernate.AbstractConnectionManager.getSession(AbstractConnectionManager.java:258) at com.redhat.rhn.common.hibernate.HibernateFactory.getSession(HibernateFactory.java:352) at com.redhat.rhn.common.hibernate.HibernateFactory.listObjectsByNamedQuery(HibernateFactory.java:275) at com.redhat.rhn.common.hibernate.HibernateFactory.listObjectsByNamedQuery(HibernateFactory.java:220) at com.redhat.rhn.domain.reactor.SaltEventFactory.countSaltEvents(SaltEventFactory.java:55) at com.suse.manager.reactor.PGEventStream.<init>(PGEventStream.java:105) at com.suse.manager.webui.services.impl.SaltService.createEventStream(SaltService.java:579) at com.suse.manager.webui.services.impl.SaltService.createOrGetEventStream(SaltService.java:533) at com.suse.manager.webui.services.impl.SaltService.getEventStream(SaltService.java:587) at com.suse.manager.reactor.SaltReactor.connectToEventStream(SaltReactor.java:190) at com.suse.manager.reactor.SaltReactor.start(SaltReactor.java:161) at com.redhat.rhn.webapp.RhnServletListener.contextInitialized(RhnServletListener.java:130) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4768) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5230) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:690) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1889) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:583) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:772) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) 17-Oct-2022 21:07:12.417 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStop Exception sending context destroyed event to listener instance of class [com.redhat.rhn.webapp.RhnServletListener] java.lang.NullPointerException at com.redhat.rhn.common.hibernate.AbstractConnectionManager.close(AbstractConnectionManager.java:121) at com.redhat.rhn.common.hibernate.HibernateFactory.closeSessionFactory(HibernateFactory.java:92) at com.redhat.rhn.webapp.RhnServletListener.stopHibernate(RhnServletListener.java:107) at com.redhat.rhn.webapp.RhnServletListener.contextDestroyed(RhnServletListener.java:164) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4816) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5477) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:690) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1889) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:583) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:772) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) Thank you and best wishes, Stefan

1 0

Uyuni 2022.10 is released!
by Julio Gonzalez 14 Oct '22

14 Oct '22

VERY IMPORTANT: 2022.10 requires special procedures for the upgrade from any previous version! Make sure you read the release notes for all the versions between the one you are using now, and 2022.10! We are happy to announce the availability of Uyuni 2022.10. Most openSUSE mirrors should already have 2022.10, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.10, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Special instructions for the update, make sure you read them! - RHEL/Oracle Linux/AlmaLinux/Rocky Linux 9 as clients - Monitoring for Ubuntu 22.04 - pip support for the Salt Bundle - Apache exporter updated to version 0.11.0 for SUSE Linux Enterprise and openSUSE - Cobbler updated to version 3.3.3 Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.10 As always, we hope you will enjoy Uyuni 2022.10 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 -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Code scanning using SonarCloud
by Cedric Bosdonnat 27 Sep '22

27 Sep '22

Hi all, I am pleased to announce you that I finally managed to setup SonarCloud to analyze the Uyuni code. https://sonarcloud.io/project/pull_requests_list?id=uyuni-project_uyuni You can just login there with your github account so that it associates the founds issues with your user. Concretely, there are two kinds of scans: * Periodic scans on the master branch * Scans on each PR containing Java code The scans are run on SUSE infrastructure and the results are published to SonarCloud. You can help in two ways: * Get the sonarcloud report is green on your Java PRs * Fix issues you can find in the sonarcloud UI I hope you will enjoy that new tool! -- Cédric

1 0

Canceled: Uyuni Community Hours
by jgonzalez＠suse.com 26 Aug '22

26 Aug '22

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 0