Trying to update errata db and fails with existing CVE.
ARSwa4qfy opened this issue · comments
Steve,
I used your script last week to add Errata to a new spacewalk server for CentOS.
Everything worked as I had expected, accept it looked like the errata only on one
of my parent channels that were built with a "spacewalk-clone-by-date". So I decided I would
removed (spacewalk-remove-channel) the cloned channels and see if I could run the script
again. This is when I started to receive the:
"Fault returned from XML RPC Server, fault code 2601: redstone.xmlrpc.XmlRpcFault: Errata already exists with advisory CEBA-2019:1331"
So I was reading your posting "errata is associated with only one channel #4", and in reading the posting I saw where the other user clean out all his errata with 'spacecmd -y "errata_delete *"',
I figured that I am still setting up the spacewalk server, no issues, so I ran the command.
Then I did an errata_list, and there were none listed, so I tried another import, and it failed with the same error. I even tried re-creating my cloned channels, no luck there either.
It is looks like it deleted the errata but not the CVE.
Any thoughts on how to clear these CVE's?
Thanks and Regards,
Mike
Script version 20190125
===================== Example output below ===============
~ ./errata-import.pl --server ******** --errata $TMPDIR/errata.latest.xml --rhsa-oval $TMPDIR/com.redhat.rhsa-all.xml --publish
INFO: Server is running API version 22
INFO: API version 22 is supported
INFO: Authentication successful
INFO: User has administrator access to this server
INFO: Loading errata XML
INFO: Loading Red Hat OVAL XML
INFO: Getting server inventory
INFO: Checking for unpublished errata
INFO: Scanning channel CentOS Server Centosplus (v. 6 for 64-bit x86_64)
INFO: Scanning channel Emerson CentOS6 Custom Packages
INFO: Scanning channel CentOS Server Extras (v. 6 for 64-bit x86_64)
INFO: Scanning channel CentOS Server Updates (v. 7 for 64-bit x86_64)
INFO: Scanning channel CentOS Server Updates (v. 6 for 64-bit x86_64)
INFO: Scanning channel Emerson CentOS7 Custom Packages
INFO: Scanning channel CentOS Server (v. 6 for 64-bit x86_64)
INFO: Scanning channel CentOS Server Extras (v. 7 for 64-bit x86_64)
INFO: Scanning channel CentOS Server Centosplus (v. 7 for 64-bit x86_64)
INFO: Scanning channel CentOS Server (v. 7 for 64-bit x86_64)
INFO: Creating errata for CEBA-2019:1331 (CentOS accountsservice BugFix Update) (5 of 22)
Fault returned from XML RPC Server, fault code 2601: redstone.xmlrpc.XmlRpcFault: Errata already exists with advisory CEBA-2019:1331
~ spacecmd -y "errata_delete *"
Spacewalk Username: #########
Spacewalk Password:
INFO: Connected to https://##################/rpc/api as #########
Erratum Channels
CEBA-2019:1651 1
CEBA-2019:1703 1
CEBA-2019:2472 1
. . .
CESA-2019:3756 1
CESA-2019:3836 1
CESA-2019:3878 1
INFO: Deleted 48 errata
~ spacecmd -y "errata_list"
INFO: Connected to https://#############/rpc/api as #
Hi Mike,
this seems to be one of the (too many) cases of inconsistencies in Spacewalk or its database.
When the script starts, it is getting a server inventory, basically asking Spacewalk which Channels, Packages and Errata it has. Existing errata are treated differently from new errata.
When it reaches CEBA-2019:1331 it assumes that Spacewalk does not know this Erratum since it was not reported in the inventory phase, but suddenly Spacewalk says "Errata already exists". There is not much I can do about that, sorry.
@stevemeier I also had one such case reported against SUSE Manager.
Problem is there can be published errata that are not linked to any channel.
This can happen, for example, after you delete a channel - published errata that was only in that channel are not cleaned up.
You can check the existence of such published errata on your server via this one-liner:
spacewalk-sql --select-mode - <<<"SELECT advisory_name FROM rhnErrata e WHERE id NOT IN (SELECT errata_id FROM rhnChannelErrata)"If errataImport.pl tries to import any published errata from the list returned, it will fail with the error reported by @ARSwa4qfy.
One problem is that currently there is no way to get a list of such errata via the API. What errataImport.pl does is to aggregate the list of all published errata from all channels, which crucially does not get the errata that do not belong to any channel.
I am working at a patch to resolve this issue and plan to open a PR to address it soon, stay tuned!