Hi,

 

After updated those packages now some services not starting .

 

● taskomatic.service - Taskomatic

   Loaded: loaded (/usr/lib/systemd/system/taskomatic.service; enabled; vendor preset: disabled)

  Drop-In: /usr/lib/systemd/system/taskomatic.service.d

           └─override.conf

   Active: failed (Result: exit-code) since Fri 2020-09-18 09:50:08 EEST; 47min ago

  Process: 8439 ExecStart=/usr/sbin/taskomatic (code=exited, status=255)

Main PID: 8439 (code=exited, status=255)

 

● spacewalk-wait-for-taskomatic.service - Spacewalk wait for taskomatic

   Loaded: loaded (/usr/lib/systemd/system/spacewalk-wait-for-taskomatic.service; static; vendor preset: disabled)

   Active: active (exited) since Fri 2020-09-18 09:51:31 EEST; 46min ago

  Process: 7290 ExecStart=/usr/sbin/spacewalk-startup-helper wait-for-taskomatic (code=exited, status=0/SUCCESS)

Main PID: 7290 (code=exited, status=0/SUCCESS)

    Tasks: 0

   CGroup: /system.slice/spacewalk-wait-for-taskomatic.service

 

● salt-secrets-config.service - Configures secrets between salt-master and other services

   Loaded: loaded (/usr/lib/systemd/system/salt-secrets-config.service; static; vendor preset: disabled)

  Drop-In: /usr/lib/systemd/system/salt-secrets-config.service.d

           └─override.conf

   Active: active (exited) since Fri 2020-09-18 09:49:32 EEST; 48min ago

  Process: 6781 ExecStart=/usr/bin/salt-secrets-config.py (code=exited, status=0/SUCCESS)

Main PID: 6781 (code=exited, status=0/SUCCESS)

    Tasks: 0

   CGroup: /system.slice/salt-secrets-config.service

 

● mgr-websockify.service - TCP to WebSocket proxy

   Loaded: loaded (/usr/lib/systemd/system/mgr-websockify.service; static; vendor preset: disabled)

   Active: active (running) since Fri 2020-09-18 09:49:41 EEST; 47min ago

  Process: 6812 ExecStartPre=/usr/bin/sh -c grep secret_key /etc/rhn/rhn.conf | tr -d ' ' | cut -f2 -d '=' | perl -ne 's/([0-9a-f]{2})/print chr hex $1/gie' > /etc/rhn/websockify.key (code=exited, status=0/SUCCESS)

Main PID: 6832 (websockify)

    Tasks: 4

   CGroup: /system.slice/mgr-websockify.service

           └─6832 /usr/bin/python3 /usr/bin/websockify --token-plugin JWTTokenApi --token-source /etc/rhn/websockify.ke…50

● spacewalk.target - Spacewalk

   Loaded: loaded (/usr/lib/systemd/system/spacewalk.target; enabled; vendor preset: disabled)

   Active: inactive (dead)

● jabberd.service - Jabber Server

   Loaded: loaded (/usr/lib/systemd/system/jabberd.service; enabled; vendor preset: disabled)

   Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago

Main PID: 3398 (code=exited, status=0/SUCCESS)

● osa-dispatcher.service - OSA Dispatcher daemon

   Loaded: loaded (/usr/lib/systemd/system/osa-dispatcher.service; enabled; vendor preset: disabled)

   Active: inactive (dead) since Fri 2020-09-18 09:49:30 EEST; 48min ago

Main PID: 3466 (code=killed, signal=TERM)

spacewalk:/var/log #

 

 

 

 

Best Regards,

Suhail Siddiqui

Service Delivery – Datacenter Services

HCL Technologies Ltd. – UPM Partner for IT Services

Mob: +91-9717193941

 

-----Original Message-----
From: Julio González Gil <jgonzalez@suse.com>
Sent: 16 September 2020 20:15
To: uyuni-announce@opensuse.org; uyuni-devel@opensuse.org; uyuni-users@opensuse.org
Subject: [uyuni-announce] Special update for CVE-2020-8028 (bsc#1175884)

 

Dear lists,

 

today we released an unscheduled maintenance update for CVE-2020-8028 (bsc#1175884), which is a security vulnerability of SUSE Manager and Uyuni Servers. The bug has been kept under embargo since it was reported to this day while we prepared a fix and coordinated the release.

 

Only users that have shell access to the Uyuni server can exploit this vulnerability. This is not a common setup, shell access to the server should usually be restricted to the server administrators.

 

In order to install this update please make sure you are on the most recent release (2020.07) and use the following commands on the Uyuni server:

 

zypper addrepo https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:/Patches/openSUSE_Leap_15.2/systemsmanagement:Uyuni:Stable:Patches.repo

zypper refresh

spacewalk-service stop

zypper update spacewalk-java-lib spacewalk-java spacewalk-java-config spacewalk-java-postgresql spacewalk-taskomatic spacewalk-admin spacewalk-setup salt-netapi-client spacewalk-service start

 

After services start again, the Salt API endpoint will be authenticated and encrypted.

 

As the fix changes the way the Salt API endpoint is served, it is expected to break any third-party scripts or software that may rely on it. We will take this occasion to remind you that:

 

- the Salt API endpoint configured by Uyuni at installation time is

   exclusively for internal Uyuni use and by default not exposed to the

   network. If your custom software depends on using the Salt API directly,

   you are relying on something not supported by Uyuni.

- it is possible to define additional API endpoints, and secure them in a

   variety of ways, and those are fine for custom scripts. More information

   about how to configure those are available at: https://docs.saltstack.com/en/latest/ref/netapi/all/salt.netapi.rest_tornado.html#module-salt.netapi.rest_tornado

 

If applying the update is not readily feasible, we recommend to restrict shell access to the Uyuni Server to the minimum set of users who really need it - which is a standard, recommended security practice in any case.

 

More information is available at:

- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8028

- https://github.com/uyuni-project/uyuni/pull/2613

 

--

Julio González Gil

Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com



Please note. The information contained in this message is confidential and is intended only for the use of the individual named above and others who have been specially authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. The attachments have been scanned for viruses prior to leaving our E-mail system. UPM-Kymmene Corporation shall not be liable for any consequences of any virus being passed on.