- ARCHIVED: Uyuni Users

RE: Update 2020.x to 2021.5 failed
by Haupt, Torsten 08 Jun '21

08 Jun '21

Hi, I made a new snapshot and installed the mentioned packages. spacewalk-service stop zypper up apache-commons-el Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: jakarta-commons-el The following package is going to be upgraded: apache-commons-el 1 package to upgrade, 1 to remove. Overall download size: 115.8 KiB. Already cached: 0 B. After the operation, 127.0 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): Retrieving package apache-commons-el-1.0-lp152.2.3.1.noarch (1/1), 115.8 KiB (122.0 KiB unpacked) Retrieving delta: ./noarch/apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm, 6.5 KiB Retrieving: apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm .....................................................................................................................................[done] Applying delta: ./apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm ...............................................................................................................................[done] Checking for file conflicts: ............................................................................................................................................................................[done] (1/1) Installing: apache-commons-el-1.0-lp152.2.3.1.noarch ..............................................................................................................................................[done] zypper up subscription-matcher Loading repository data... Reading installed packages... Resolving package dependencies... Problem: subscription-matcher-0.26-6.1.uyuni.noarch requires (mvn(com.thoughtworks.xstream:xstream) >= 1.4.15 with mvn(com.thoughtworks.xstream:xstream) <= 1.5), but this requirement cannot be provided not installable providers: xstream-1.4.15-lp152.2.3.1.noarch[repo-update] xstream-1.4.16-lp152.2.6.1.noarch[repo-update] xstream-1.4.15-lp152.2.3.1.noarch[uyuni-server-stable] Solution 1: install xstream-1.4.16-lp152.2.6.1.noarch (with vendor change) obs://build.opensuse.org/systemsmanagement:Uyuni --> openSUSE Solution 2: do not install subscription-matcher-0.26-6.1.uyuni.noarch Solution 3: break subscription-matcher-0.26-6.1.uyuni.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... The following NEW package is going to be installed: xpp3-minimal The following 2 packages are going to be upgraded: subscription-matcher xstream The following package is going to change vendor: xstream obs://build.opensuse.org/systemsmanagement:Uyuni -> openSUSE 2 packages to upgrade, 1 new, 1 to change vendor. Overall download size: 828.7 KiB. Already cached: 0 B. After the operation, additional 70.1 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package xpp3-minimal-1.1.4c-lp152.5.1.noarch (1/3), 34.9 KiB ( 28.5 KiB unpacked) Retrieving: xpp3-minimal-1.1.4c-lp152.5.1.noarch.rpm ....................................................................................................................................................[done] Retrieving package xstream-1.4.16-lp152.2.6.1.noarch (2/3), 542.6 KiB (636.0 KiB unpacked) Retrieving: xstream-1.4.16-lp152.2.6.1.noarch.rpm .......................................................................................................................................................[done] Retrieving package subscription-matcher-0.26-6.1.uyuni.noarch (3/3), 251.3 KiB (255.3 KiB unpacked) Retrieving: subscription-matcher-0.26-6.1.uyuni.noarch.rpm ..............................................................................................................................................[done] Checking for file conflicts: ............................................................................................................................................................................[done] (1/3) Installing: xpp3-minimal-1.1.4c-lp152.5.1.noarch ..................................................................................................................................................[done] (2/3) Installing: xstream-1.4.16-lp152.2.6.1.noarch .....................................................................................................................................................[done] (3/3) Installing: subscription-matcher-0.26-6.1.uyuni.noarch ............................................................................................................................................[done] spacewalk-service start Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service Done. journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 04 09:36:32 smduyuni systemd[1]: Stopped Uyuni check database. -- Reboot -- Jun 04 09:37:55 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:37:56 smduyuni spacewalk-startup-helper[1392]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:37:56 smduyuni spacewalk-startup-helper[1392]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:37:56 smduyuni systemd[1]: Started Uyuni check database. Jun 04 09:38:58 smduyuni systemd[1]: Stopped Uyuni check database. Jun 04 09:39:57 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:39:58 smduyuni spacewalk-startup-helper[5663]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:39:58 smduyuni spacewalk-startup-helper[5663]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:39:58 smduyuni systemd[1]: Started Uyuni check database. Each time I restart the service, the schema upgrade starts again. I think, these packages are not the problem. Torsten From: Haupt, Torsten [mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de] Sent: Friday, June 4, 2021 9:31 AM To: Strahil Nikolov <hunter86_bg(a)yahoo.com>; Julio Gonzalez <jgonzalez(a)suse.com> Cc: uyuni-users(a)opensuse.org Subject: [EXTERN] RE: {SpamCheck LSA} RE: Update 2020.x to 2021.5 failed Hi, there was no question to install all packages. Or should I install the three packages, I didn’t installed because of the vendor change? Can I install it at this point? Torsten From: Strahil Nikolov [mailto:hunter86_bg@yahoo.com] Sent: Friday, June 4, 2021 9:23 AM To: Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>>; Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>>; Julio Gonzalez <jgonzalez(a)suse.com<mailto:jgonzalez@suse.com>> Cc: uyuni-users(a)opensuse.org<mailto:uyuni-users@opensuse.org> Subject: {SpamCheck LSA} RE: Update 2020.x to 2021.5 failed Hi Thorsten, can you clone the VM and test installing all packages (answer yes to all) Best Regards, Strahil Nikolov On Fri, Jun 4, 2021 at 10:20, Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>> wrote: Hi, well, I had a snapshot of the VM and I returned to the point before upgrade. The installed version was 2020.11 on openSUSE Leap 15.2. I use the upgrade guide at https://www.uyuni-project.org/uyuni-docs/uyuni/upgrade/server-minor-upgrade… I did: spacewalk-service stop zypper refresh zypper patch --with-optional Loading repository data... Reading installed packages... Resolving package dependencies... The following 11 NEW patches are going to be installed: openSUSE-2021-291 openSUSE-2021-354 openSUSE-2021-361 openSUSE-2021-365 openSUSE-2021-614 openSUSE-2021-616 openSUSE-2021-703 openSUSE-2021-744 openSUSE-2021-822 openSUSE-2021-827 openSUSE-2021-831 The following 40 packages are going to be upgraded: e2fsprogs gstreamer gstreamer-lang gstreamer-plugins-base gstreamer-plugins-base-lang libcom_err2 libcom_err2-32bit libext2fs2 libgpgme11 libgstallocators-1_0-0 libgstapp-1_0-0 libgstaudio-1_0-0 libgstfft-1_0-0 libgstgl-1_0-0 libgstpbutils-1_0-0 libgstreamer-1_0-0 libgstriff-1_0-0 libgsttag-1_0-0 libgstvideo-1_0-0 libnetpbm11 libpq5 libvirt-bash-completion libvirt-client libvirt-libs m4 netpbm openssh openssh-askpass-gnome openssh-helpers postgresql10 postgresql10-contrib postgresql10-server postgresql12 postgresql12-contrib postgresql12-llvmjit postgresql12-server sed sed-lang tcl tk 40 packages to upgrade. Overall download size: 39.2 MiB. Already cached: 0 B. After the operation, additional 23.7 KiB will be used. Continue? [y/n/v/...? shows all options] (y): I did a reboot, that all applications uses the new versions. At this point the website was okay. I restarted with a spacewalk-service stop. zypper up Loading repository data... Reading installed packages... The following 3 package updates will NOT be installed: Uyuni-Server-release subscription-matcher xstream The following product update will NOT be installed: "Uyuni Server" The following NEW package is going to be installed: apache-commons-el The following 136 packages are going to be upgraded: apache2-mod_xsendfile bind-formula c3p0 caasp-management-node-formula caasp-management-settings-formula cobbler concurrent cpu-mitigations-formula dhcpd-formula drools dwr ehcache golang-github-QubitProducts-exporter_exporter golang-github-lusitaniae-apache_exporter golang-github-prometheus-node_exporter golang-github-wrouesnel-postgres_exporter grafana-formula guava hibernate5 ical4j jabberd jabberd-sqlite jade4j jcommon jsch kie-api kie-soup libgsasl-lang libgsasl7 libudns0 locale-formula mgr-libmod mgr-osa-dispatcher mgr-push netty nutch-core openvpn-formula optaplanner patterns-uyuni_server perl-Mail-RFC822-Address perl-Satcon perl-Term-Completion perl-Term-Size prometheus-exporters-formula prometheus-formula prometheus-jmx_exporter prometheus-jmx_exporter-tomcat pxe-default-image-opensuse15 py26-compat-msgpack-python py26-compat-salt py26-compat-tornado python-dmidecode python3-dmidecode python3-hwdata python3-mgr-osa-common python3-mgr-osa-dispatcher python3-mgr-push python3-rhnlib python3-spacewalk-certs-tools python3-spacewalk-client-tools python3-suseRegisterInfo python3-urlgrabber python3-uyuni-common-libs release-notes-uyuni reprepro salt-netapi-client simple-core simple-xml sitemesh smdba spacecmd spacewalk-admin spacewalk-backend spacewalk-backend-app spacewalk-backend-applet spacewalk-backend-config-files spacewalk-backend-config-files-common spacewalk-backend-config-files-tool spacewalk-backend-iss spacewalk-backend-iss-export spacewalk-backend-package-push-server spacewalk-backend-server spacewalk-backend-sql spacewalk-backend-sql-postgresql spacewalk-backend-tools spacewalk-backend-xml-export-libs spacewalk-backend-xmlrpc spacewalk-base spacewalk-base-minimal spacewalk-base-minimal-config spacewalk-branding spacewalk-certs-tools spacewalk-client-tools spacewalk-common spacewalk-config spacewalk-html spacewalk-java spacewalk-java-config spacewalk-java-lib spacewalk-java-postgresql spacewalk-postgresql spacewalk-reports spacewalk-search spacewalk-setup spacewalk-setup-jabberd spacewalk-taskomatic spacewalk-utils struts supportutils-plugin-salt supportutils-plugin-susemanager suseRegisterInfo susemanager susemanager-frontend-libs susemanager-schema susemanager-sls susemanager-sync-data susemanager-tftpsync susemanager-tools susemanager-web-libs system-lock-formula tagsoup tftpd-formula tika-core tomcat-taglibs-standard-1_2_5 uyuni-base-common uyuni-base-server uyuni-build-keys uyuni-build-keys-web uyuni-cluster-provider-caasp uyuni-doc-indexes uyuni-docs_en uyuni-docs_en-pdf virtual-host-gatherer virtual-host-gatherer-VMware virtualization-host-formula vsftpd-formula The following pattern is going to be upgraded: uyuni_server 136 packages to upgrade, 1 new. Overall download size: 227.0 MiB. Already cached: 0 B. After the operation, additional 6.9 MiB will be used. Continue? [y/n/v/...? shows all options] (y): During update following question appears: Checking for file conflicts: ...........................................................................................................................................................................[error] Detected 1 file conflict: File /usr/share/java/commons-el.jar from install of apache-commons-el-1.0-lp152.1.1.noarch (Main Repository) conflicts with file from package jakarta-commons-el-1.0-2.6.uyuni.noarch (@System) File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content. Continue? [yes/no] (no): I choosed "yes" Because some packages were not update automatically, I updated them manually zypper update Uyuni-Server-release Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: Uyuni-Server-release The following product is going to be upgraded: Uyuni Server 2020.11-0 -> 2021.05-0 The following product is going to change vendor: Uyuni Server openSUSE -> obs://build.opensuse.org/systemsmanagement:Uyuni 1 package to upgrade. Overall download size: 8.6 KiB. Already cached: 0 B. After the operation, additional 1.0 B will be used. Continue? [y/n/v/...? shows all options] (y): zypper update subscription-matcher Loading repository data... Reading installed packages... Resolving package dependencies... Problem: subscription-matcher-0.26-6.1.uyuni.noarch requires (mvn(com.thoughtworks.xstream:xstream) >= 1.4.15 with mvn(com.thoughtworks.xstream:xstream) <= 1.5), but this requirement cannot be provided not installable providers: xstream-1.4.15-lp152.2.3.1.noarch[repo-update] xstream-1.4.16-lp152.2.6.1.noarch[repo-update] xstream-1.4.15-lp152.2.3.1.noarch[uyuni-server-stable] Solution 1: install xstream-1.4.16-lp152.2.6.1.noarch (with vendor change) obs://build.opensuse.org/systemsmanagement:Uyuni --> openSUSE Solution 2: do not install subscription-matcher-0.26-6.1.uyuni.noarch Solution 3: break subscription-matcher-0.26-6.1.uyuni.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2 Resolving dependencies... Resolving package dependencies... Nothing to do. I didn't installed this update, because of the vendor change from uyuni to openSUSE. zypper up xstream Loading repository data... Reading installed packages... There is an update candidate for 'xstream' from vendor 'openSUSE', while the current vendor is 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper install xstream-1.4.16-lp152.2.6.1.noarch' to install this candidate. Resolving package dependencies... Nothing to do. I didn't installed this update, because of the vendor change from uyuni to openSUSE. zypper up apache-commons-el Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: jakarta-commons-el The following package is going to be upgraded: apache-commons-el 1 package to upgrade, 1 to remove. Overall download size: 115.8 KiB. Already cached: 0 B. After the operation, 127.0 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): n I didn't installed this package, because oft he question above. spacewalk-service start Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 03 20:27:41 smduyuni systemd[1]: Stopped Uyuni check database. Jun 03 20:43:32 smduyuni systemd[1]: Starting Uyuni check database... Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Schema upgrade: [susemanager-schema-4.2.3-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for upgrade path to: [susemanager-schema-4.2.14-1] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for upgrade path to: [susemanager-schema-4.2.14] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for start path: [susemanager-schema-4.2.3-1] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for start path: [susemanager-schema-4.2.3] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: The path: [susemanager-schema-4.2.3] -> [susemanager-schema-4.2.4] -> [susemanager-schema-4.2.5] -> [susemanager-schema-4.2.6] -> [susemanager-schema-4.2.7] -> [susemanager-schema-4.2.8] -> [susemanager-schema-4.2.9] -> [susemanager- schema-4.2.10] -> [susemanager-schema-4.2.11] -> [susemanager-schema-4.2.12] -> [susemanager-schema-4.2.13] -> [susemanager-schema-4.2.14] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Planning to run schema upgrade with dir '/var/log/spacewalk/schema-upgrade/schema-from-20210603-204341' Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Executing spacewalk-sql, the log is in [/var/log/spacewalk/schema-upgrade/schema-from-20210603-204341-to-susemanager-schema-4.2.14.log]. Jun 03 22:50:00 smduyuni spacewalk-startup-helper[7339]: [1.9K blob data] Jun 03 22:50:01 smduyuni spacewalk-startup-helper[7339]: [2.0K blob data] Jun 03 22:50:02 smduyuni spacewalk-startup-helper[7339]: [1.9K blob data] Jun 03 22:50:02 smduyuni spacewalk-startup-helper[7339]: The database schema was upgraded to version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 03 22:50:02 smduyuni systemd[1]: Started Uyuni check database. The Website is not available again. I stopped the spacewalk-service again and startet it without luck. Jun 04 09:14:29 smduyuni systemd[1]: Stopped Uyuni check database. Jun 04 09:14:35 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:14:36 smduyuni spacewalk-startup-helper[8318]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:14:36 smduyuni spacewalk-startup-helper[8318]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:14:36 smduyuni systemd[1]: Started Uyuni check database. So, the same problem like the last run. Greets Torsten > -----Original Message----- > From: Julio Gonzalez [mailto:jgonzalez@suse.com<mailto:jgonzalez@suse.com>] > Sent: Thursday, June 3, 2021 2:55 PM > To: uyuni-users(a)opensuse.org<mailto:uyuni-users@opensuse.org>; users(a)lists.uyuni-project.org<mailto:users@lists.uyuni-project.org> > Cc: Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>> > Subject: [EXTERN] Re: Update 2020.x to 2021.5 failed > > Without knowing the X, it's hard to know what's going on for sure. > > But to me, it looks like you missed one of the manual steps to be applied to > upgrade from 2020.X to 2021.05. Have a look at the release notes and make > sure you follow all the instructions between your 2020.X and 2021.05. > > My main suspect is one of the libraries that now must come from Leap. Without > that changed applied to the server, the WebUI is know to show 404. > > However if 2020.X is too old, it could be it was based on Leap 15.1, and needs to > run the script to migrate to Leap 15.2. But should not be the case if 2020.X is > from the end of last year. > > > On miércoles, 2 de junio de 2021 19:58:20 (CEST) Haupt, Torsten wrote: > > Hi, > > > > I didn't made every uyuni update the last months, but now I did it and > > it failed. I think my installed version was from end oft he last year. > > I followed the instructions on the website and all patches and updates > > were installed. The schema update with the first service start last > > several hours, but it fineshed. But the Uyuni site is not available; > > only the tomcat error "HTTP Status 404 - nicht gefunden Type Status > > Report Beschreibung The origin server did not find a current > > representation for the target resource or is not willing to disclose > > that one exists." appears. I restarted the services and the whole > > server without success. > > > > Every time I do a "spacewalk-service start" the message "Starting > > spacewalk services... > > Running DB schema upgrade. This may take a while. > > Call the following command to see progress: journalctl -f -u > > uyuni-check-database.service Done." appears. > > > > journalctl -f -u uyuni-check-database.service > > -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 02 11:56:41 > > smduyuni systemd[1]: Stopped Uyuni check database. > > Jun 02 11:56:44 smduyuni systemd[1]: Starting Uyuni check database... > > Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Your > > database schema already matches the schema package version > > [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 11:56:44 smduyuni > > spacewalk-startup-helper[22859]: Schema upgrade: > > [susemanager-schema-4.2.14-1.1.uyuni] -> > > [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 11:56:44 smduyuni > systemd[1]: > > Started Uyuni check database. Jun 02 19:42:08 smduyuni systemd[1]: > > Stopped Uyuni check database. Jun 02 19:42:11 smduyuni systemd[1]: > > Starting Uyuni check database... Jun 02 19:42:11 smduyuni spacewalk-startup- > helper[24088]: > > Your database schema already matches the schema package version > > [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 19:42:11 smduyuni > > spacewalk-startup-helper[24088]: Schema upgrade: > > [susemanager-schema-4.2.14-1.1.uyuni] -> > > [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 19:42:12 smduyuni > systemd[1]: > > Started Uyuni check database. > > > > It is always the same schema upgrade. > > > > > > less /var/log/tomcat/catalina.2021-06-02.log > > 02-Jun-2021 19:42:14.398 SEVERE [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Error deploying > > web application directory [/srv/tomcat/webapps/rhn] > > java.lang.IllegalStateException: Error starting child > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > > 720) at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690 > > ) at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) > > at > > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java > > :1132 > > ) at > > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java: > > 1865) at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executor > > s.jav > > a:515) at > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > > at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe > > cutor > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract > > Execu > > torService.java:118) at > > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.ja > > va:10 > > 44) at > > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) > > at > > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at > > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java: > > 309) > > at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas > > e.jav > > a: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.jav > > a:936 > > ) at > > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java: > > 841) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j > > ava:1 > > 384) at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j > > ava:1 > > 374) at > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > > at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe > > cutor > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract > > Execu > > torService.java:140) at > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav > > a:909 > > ) at > > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.j > > ava:2 > > 62) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.StandardService.startInternal(StandardService > > .java > > :421) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.StandardServer.startInternal(StandardServer.j > > ava:9 > > 30) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM > > ethod > > AccessorImpl.java:62) at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Del > > egati > > ngMethodAccessorImpl.java:43) at > > java.base/java.lang.reflect.Method.invoke(Method.java:566) at > > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at > > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: > > org.apache.catalina.LifecycleException: Failed to start component > > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn > > ]] at > > org.apache.catalina.util.LifecycleBase.handleSubClassException(Lifecyc > > leBas > > e.java:440) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > > 717) ... 37 more > > Caused by: java.lang.NullPointerException > > at > > org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScan > > ner.j > > ava:382) at > > org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner > > .java > > :195) at > > org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(C > > ontex > > tConfig.java:1971) at > > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java > > :1129 > > ) at > > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig > > .java > > :775) at > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig > > .java > > :301) at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas > > e.jav > > a:123) at > > org.apache.catalina.core.StandardContext.startInternal(StandardContext > > .java > > :5044) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > ... 38 more > > 02-Jun-2021 19:42:14.400 INFO [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of > > web application directory [/srv/tomcat/webapps/rhn] has finished in > > [982] ms > > 02-Jun-2021 19:42:14.421 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["http-nio-127.0.0.1-8080"] 02-Jun-2021 19:42:14.601 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-127.0.0.1-8009"] 02-Jun-2021 19:42:14.749 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 02-Jun-2021 19:42:14.881 INFO [main] > > org.apache.catalina.startup.Catalina.start Server startup in [1,660] > > milliseconds > > > > Further logs and infos I would provide. > > > > Greets > > Torsten > > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com<mailto:jgonzalez@suse.com>

3 3

Update 2020.x to 2021.5 failed
by Haupt, Torsten 04 Jun '21

04 Jun '21

Hi, I didn't made every uyuni update the last months, but now I did it and it failed. I think my installed version was from end oft he last year. I followed the instructions on the website and all patches and updates were installed. The schema update with the first service start last several hours, but it fineshed. But the Uyuni site is not available; only the tomcat error "HTTP Status 404 - nicht gefunden Type Status Report Beschreibung The origin server did not find a current representation for the target resource or is not willing to disclose that one exists." appears. I restarted the services and the whole server without success. Every time I do a "spacewalk-service start" the message "Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service Done." appears. journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 02 11:56:41 smduyuni systemd[1]: Stopped Uyuni check database. Jun 02 11:56:44 smduyuni systemd[1]: Starting Uyuni check database... Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 11:56:44 smduyuni systemd[1]: Started Uyuni check database. Jun 02 19:42:08 smduyuni systemd[1]: Stopped Uyuni check database. Jun 02 19:42:11 smduyuni systemd[1]: Starting Uyuni check database... Jun 02 19:42:11 smduyuni spacewalk-startup-helper[24088]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 19:42:11 smduyuni spacewalk-startup-helper[24088]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 19:42:12 smduyuni systemd[1]: Started Uyuni check database. It is always the same schema upgrade. less /var/log/tomcat/catalina.2021-06-02.log 02-Jun-2021 19:42:14.398 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/srv/tomcat/webapps/rhn] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1865) 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.deployDirectories(HostConfig.java:1044) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) 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:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) 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:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) 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:633) 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:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) ... 37 more Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:382) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:195) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1971) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:775) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5044) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more 02-Jun-2021 19:42:14.400 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [982] ms 02-Jun-2021 19:42:14.421 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 02-Jun-2021 19:42:14.601 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 02-Jun-2021 19:42:14.749 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 02-Jun-2021 19:42:14.881 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [1,660] milliseconds Further logs and infos I would provide. Greets Torsten

3 5

Re: [EXTERNAL] Re: Equivalent of macros functionality with salt registered system?
by Allen Beddingfield 28 May '21

28 May '21

Thanks. Sigh. That's is a lot further off into the weeds than I wanted to get, but I can probably make something work. My usage for SUSE Manager and Uyuni is about 50% patching, 40% pushing config files, and 10% remote execution. I really haven't gotten into the Salt states, because until I started finding that macros don't work, I haven't had much need to change my process from the original way I've been doing things forerver (pre-salt). Postfix was the example I gave, but I've been using salt postfix.set_main to set relayhost and the hostname. What I'm trying to do is to deploy an rpm-based agent to about 500 clients, then push the config file, having the hostname populated. With this, I can figure out enough of salt to do a salt state to put the agent out there, then do what you suggested with the file replace, or push it as I had planned, and remote execute something to use sed in a shell script to do it. Or, I can remote execute a shell script to do the whole thing. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu <https://www.ua.edu/> ________________________________ From: Julio Gonzalez Sent: Friday, May 28, 2021 4:52 PM To: uyuni-users(a)opensuse.org; users(a)lists.uyuni-project.org Cc: Allen Beddingfield Subject: [EXTERNAL] Re: Equivalent of macros functionality with salt registered system? On viernes, 28 de mayo de 2021 21:48:28 (CEST) Allen Beddingfield wrote: > Is there an equivalent of the Spacewalk macros that work with traditional > clients for systems registered with salt? > > For example, here is what I used to put in the /etc/postfix/main.cf config > file: myhostname = {| rhn.system.hostname |} > > When the client is registered with salt, it puts that string of text, > instead of putting the value of the hostname. How can I accomplish this > with a salt client? > > Here is a link to the functionality I mention. > https://access.redhat.com/documentation/en-us/red_hat_satellite/5.6/html/get > ting_started_guide/getting_started_guide-channel_management-managing_configu > ration_channels-including_macros_in_configuration_files You use grains, and can use pillar data, depend on what you need. https://www.uyuni-project.org/uyuni-docs/uyuni/salt/salt-states.html https://docs.saltproject.io/en/3002/topics/grains/ https://docs.saltproject.io/en/3002/topics/pillar/index.html And since 2021.05 you can have also any custom data as pillar data, that then you can use at the salt states: https://www.uyuni-project.org/doc/2021.05/release-notes-uyuni-server.html#_… For your example, if you only want to change a single line, you could use file.replace as part of a state https://docs.saltproject.io/en/latest/ref/states/all/salt.states.file.html#… mystate: file.replace: - name: /etc/postfix/main.cf - pattern: 'myhostname = .*' - repl: 'myhostname = '"{{salt['grains.get']('fqdn')}}"' But as I guess you want to change more things at that postfix configuration, then you should consider "file.managed" and jinja templates: https://docs.saltproject.io/en/3002/topics/jinja/index.html#jinja-in-files Hope it helps :-) > Thanks! > Allen B. > -- > Allen Beddingfield > Systems Engineer > Office of Information Technology > The University of Alabama > Office 205-348-2251 > allen(a)ua.edu -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Equivalent of macros functionality with salt registered system?
by Allen Beddingfield 28 May '21

28 May '21

Is there an equivalent of the Spacewalk macros that work with traditional clients for systems registered with salt? For example, here is what I used to put in the /etc/postfix/main.cf config file: myhostname = {| rhn.system.hostname |} When the client is registered with salt, it puts that string of text, instead of putting the value of the hostname. How can I accomplish this with a salt client? Here is a link to the functionality I mention. https://access.redhat.com/documentation/en-us/red_hat_satellite/5.6/html/ge… Thanks! Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

2 1

Fix for a problem syncing Debian/Ubuntu client tools
by Julio Gonzalez 28 May '21

28 May '21

Hi, Thanks to a report from Markus Thum, we realized that the repository syncing scripts did not support DEB packages without a Maintainer field at the control file. This was never a problem because Debian and Ubuntu DEB packages always have this field (it is mandatory according to their policies). But the new "scap-security-guide-*" DEBs don't have this field at this moment. We intend to fix this in collaboration with the SLE package maintaners (as we just build the package for Ubuntu/Debian from their sources), but that is going to take some time, and it would require republishing the client tools for Uyuni. While this problem does not break the repository syncing scripts, it shows an error on-screen, or at the logs (that produces an email each time an automated sync is launched). For this reason we decided to use the Patch procedure to fix this issue at the server (in the end packages without the Maintaner field are valid [1]), instead of waiting until Uyuni 2021.06 is released. You can apply the patch by following the instructions at: https://www.uyuni-project.org/pages/patches.html#server Of course, the fix will be part of Uyuni 2021.06 as well, so it's not required if you don't manage Debian or Ubuntu clients. Best regards. [1] https://manpages.debian.org/buster/dpkg-dev/deb-control.5.en.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Reposync error Debian10-Uyuni-Client-Tools
by Markus.Thum＠iese.fraunhofer.de 28 May '21

28 May '21

Hi, synchronizing the repository "External - Uyuni Client Tools for Debian 10 Buster AMD64<https://uyuni.iese.fhg.de/rhn/channels/manage/repos/RepoEdit.do?id=526>" throws an error. In the logs I find 11:47:44 | Channel: debian-10-amd64-uyuni-client 11:47:44 ====================================== 11:47:44 Sync of channel started. 11:47:45 Repo URL: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… 11:47:45 Packages in repo: 35 11:47:45 Packages already synced: 31 11:47:45 Packages to sync: 4 11:47:45 New packages to download: 4 11:47:45 Downloading packages: 11:47:45 Downloading total 4 files from 1 queues. 11:47:45 1/4 : scap-security-guide_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:46 2/4 : scap-security-guide-debian_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:46 3/4 : scap-security-guide-ubuntu_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:47 4/4 : scap-security-guide-redhat_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:47 11:47:47 Importing packages to DB: 11:47:47 Package batch #1 of 1 completed... 11:47:47 11:47:47 Patches in repo: 0. 11:47:47 Total time: 0:00:02 2021-05-27 11:47:47,372 [Thread-113] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - 11:47:47 'Maintainer' 11:47:47 'Maintainer' 11:47:47 'Maintainer' 11:47:47 'Maintainer' 2021-05-27 11:47:47,439 [DefaultQuartzScheduler_Worker-7] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Command '[/usr/bin/spacewalk-repo-sync, --channel, debian-10-amd64-uyuni-client, --type, deb, --non-interactive]' exited with error code 4 Uyuni 2021.05 on openSUSE Leap 15.2 Regards Markus

3 5

Centos 7 - salt-minion regresion ?
by Cristian Gherman 27 May '21

27 May '21

Hello I spoted a issue with install packges action from Uyuni which not marked as finished (but process is ok on minions) From my log I saw a newer version in instaled on my minion. From my yum log: /var/log/yum.log:Feb 08 02:53:54 Updated: salt-minion-3000-26.2.uyuni.x86_64 /var/log/yum.log:Mar 10 07:47:56 Updated: salt-minion-3000-29.1.uyuni.x86_64 /var/log/yum.log:Apr 24 01:52:50 Updated: salt-minion-3000-36.1.uyuni.x86_64 But now on server in folder http://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:… I see version salt-minion-3000-20.2 On my server (Opensuse 15.2) after upgrade to Uyuni 2021.05 I have slat master version salt-master-3000-lp152.3.33.1.x86_64 (I think form Opensuse repos). After I downgraded on one sever to salt-minion-3000-20.2.uyuni.x86_64 install , the task Package Install/Upgrade is marked as finished. I checked also the sync log: From my sync log: 2021/04/22 03:14:17 -04:00 Command: ['/usr/bin/spacewalk-repo-sync', '--channel', 'centos7-uyuni-client', '--type', 'yum', '--non-interactive'] 2021/04/22 03:14:17 -04:00 Sync of channel started. 2021/04/22 03:14:21 -04:00 Repo URL: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… 2021/04/22 03:14:21 -04:00 Packages in repo: 269 2021/04/22 03:14:21 -04:00 Packages already synced: 215 2021/04/22 03:14:21 -04:00 Packages to sync: 54 2021/04/22 03:14:21 -04:00 New packages to download: 54 2021/04/22 03:14:21 -04:00 Downloading packages: 2021/04/22 03:14:29 -04:00 30/54 : python2-suseRegisterInfo-4.2.3-2.1.uyuni.noarch.rpm 2021/04/22 03:14:29 -04:00 31/54 : go1.15-bin-1.15.2-10.1.uyuni.x86_64.rpm 2021/04/22 03:14:29 -04:00 32/54 : python2-uyuni-common-libs-4.2.3-3.2.uyuni.x86_64.rpm 2021/04/22 03:14:29 -04:00 33/54 : salt-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 34/54 : salt-cloud-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 35/54 : salt-api-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 36/54 : salt-master-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 37/54 : salt-minion-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 38/54 : salt-proxy-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 39/54 : python2-salt-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 40/54 : salt-ssh-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 41/54 : salt-standalone-formulas-configuration-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 42/54 : salt-doc-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 43/54 : salt-syndic-3000-36.1.uyuni.x86_64.rpm Than you. -- Cristian Gherman Support / PHP developer cristian.gherman(a)reea.net | www.reea.net | +4 0365410942

2 2

Uyuni 2021.05 is released!
by Julio Gonzalez 24 May '21

24 May '21

Hello everyone! We are happy to announce the immediate availability of Uyuni 2021.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.05, including the release notes, documentation, requirements and setup instructions. IMPORTANT: Read the release notes. Depending on your current Uyuni version some more manual steps can be required to update the Server (for example if your current version is < 2021.05) This is the list of highlights for this release: - SLE Micro 5.0 and openSUSE MicroOS as clients - Deprecated products (RHEL6 and clones, Ubuntu16.04) - Prometheus TLS - Updated Prometheus - Migrate clients from openSUSE Leap to SUSE Linux Enterprise Server - Easier system group and configuration channel assignment - Enhanced CLM filter list - Notify beacon for DEB-based clients - Allow setting primary FQDN for the systems - Virtualization improvements - Custom data as pillar - Retracted patches - Client systems forwarded to SUSE Customer Center - Configuration state summary - Live patching made easy with filter templates - HTML documentation for the API - New API calls - spacecmd improvements - Activation key dropped from system details - Software Crashes (ABRT) dropped Please check the release notes for full details. 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 2021.05 As always, we hope you will enjoy Uyuni 2021.05 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

Schema migration with Uyuni 2021.05 upgrade fails
by Bob Martens 24 May '21

24 May '21

I have run into an issue where the schema migration has failed with the 2021.05 upgrade. This is what I get when I try to run the migration on my own: Schema upgrade: [susemanager-schema-4.2.9-1.1.uyuni] -> [susemanager-schema-4.2.13-1.1.uyuni] Searching for upgrade path to: [susemanager-schema-4.2.13-1] Searching for upgrade path to: [susemanager-schema-4.2.13] Searching for upgrade path to: [susemanager-schema-4.2] Was not able to find upgrade path in directory [/etc/sysconfig/rhn/schema-upgrade]. There is no directory beyond susemanager-schema-4.2.11-to-susemanager-schema-4.2.12. I am wondering if something is missing on my end and what I can do to get it back and get back up and running. Thanks!

2 1

Replacing the SSL cert for the web interface
by Bob Martens 24 May '21

24 May '21

Is there a supported way to replace the web interface SSL cert? Is it the best option to keep that (Apache certificate) and the SSL certs used for management separate? If I had used a signed wildcard cert to set up the server originally, would it be best to switch to a self-signed cert for the management portion now? Thanks!

2 2