Importing CentOS Errata with Pulp3

Yes exactly !
It works nicely, and it’s less cumbersome than having to deal with the RPM + the metadata for the errata :slight_smile:

1 Like

That is one of the reasons why i switched to OL and now AlmaLinux some time ago. For people that like to have errata without hacks and looking for alternatives after CentOS goes EOL.

Oracle Linux 7 and 8 provide errata, but OL8 is missing tracer data about restart/reboot after update.
AlmaLinux 8 provide errata and correctly provide with restart/reboot information in tracer.

Sneaky… I think I can work with this. Thanks for the tip-off.

@sjansen FYI Rocky Linux now provides full errata as well, no hacks necessary.

1 Like

Am I understanding this correctly, that the errata can be contained in its own repo and isn’t imported to my existing repos containing packages?

Example;
Existing Config is:
Product = Centos7
Repos = CentOS-7-Base, CentOS-7-Updates, epel

New Config is:
Product = Centos7
Repos = CentOS-7-Base, CentOS-7-Updates, epel, CentOS-7-Errata

where CentOS-7-Errata has no rpm’s, only Errata once its sync’d?

Thanks

Hi,
That’s correct !
I handle them like that, it’s less of a hassle as you don’t have to merge the errata with a rpm repository

3 Likes

can you please show us commands or how to from gui to create this blank repo for errata shall i use file or yum type for this errata

I stored the repository on the Katello server, in /var/www/html/pub/centos-errata and then added it as a yum repository.

Hi,
As pointed by John above, you have to use a “yum” repository, it’s just that you won’t see any package, just errata.

I made my script public, you can check it out here :

It simply uses a docker container to upload a file to an S3, or use an nginx server to hold the yum repository

1 Like

I’m working on converting the perl script to work with pulp 3 here: https://github.com/mattatnersc/pulp_centos_errata_import. I’ve converted the various “pulp” calls to API calls. It worked, then it stopped working and now I’m baffled. If anyone can figure out why a file like this doesn’t upload, then we’ll be in business:

{
  "status": "final",
  "version": "1",
  "release": "2.el8",
  "description": "Not available",
  "pkglist": [
    {
      "packages": [
        {
          "epoch": "0",
          "filename": "watchdog-5.15-2.el8.x86_64.rpm",
          "version": "5.15",
          "arch": "x86_64",
          "name": "watchdog",
          "release": "2.el8"
        }
      ],
      "name": "collection-0",
      "shortname": ""
    }
  ],
  "issued_date": "2021-11-09 00:00:00",
  "summary": "CentOS watchdog Update",
  "references": [
    {
      "href": "https://access.redhat.com/errata/RHBA-2021:4379",
      "type": "Bug Fix Advisory",
      "title": "CentOS watchdog Update",
      "id": "CEBA-2021:4379"
    }
  ],
  "id": "CEBA-2021:4379",
  "updated_date": "2021-11-09 00:00:00",
  "type": "bugfix",
  "title": "CentOS watchdog Update",
  "severity": "",
  "fromstr": "email@steve-meier.de"
}
http \
        --cert ~/.pulp/cert.pem \
        --cert-key ~/.pulp/priv.pem \
        --form POST \
        'https://foreman.example.com/pulp/api/v3/content/rpm/advisories/' \
        file@./"$JSON_FILE" \
        repository='/pulp/api/v3/repositories/rpm/rpm/bba16ffb-1796-4dca-1234-9dd63432c743/'

The resulting task complains of:

{
  "pulp_href": "/pulp/api/v3/tasks/dfd45719-9b8a-497c-a4e6-b7862ebe51f5/",
  "pulp_created": "2021-12-16T23:24:23.950390Z",
  "state": "failed",
  "name": "pulpcore.app.tasks.base.general_create_from_temp_file",
  "logging_cid": "f8a8f7f331bd4ae786d9f5246bb03788",
  "started_at": "2021-12-16T23:24:24.281947Z",
  "finished_at": "2021-12-16T23:24:24.613998Z",
  "error": {
    "traceback": "  File \"/usr/lib/python3.6/site-packages/pulpcore/tasking/pulpcore_worker.py\", line 317, in _perform_task\n    result = func(*args, **kwargs)\n  File \"/usr/lib/python3.6/site-packages/pulpcore/app/tasks/base.py\", line 18, in general_create_from_temp_file\n    general_create(app_label, serializer_name, data=data, *args, **kwargs)\n  File \"/usr/lib/python3.6/site-packages/pulpcore/app/tasks/base.py\", line 35, in general_create\n    serializer.save()\n  File \"/usr/lib/python3.6/site-packages/rest_framework/serializers.py\", line 205, in save\n    self.instance = self.create(validated_data)\n  File \"/usr/lib/python3.6/site-packages/pulp_rpm/app/serializers/advisory.py\", line 135, in create\n    raise serializers.ValidationError(\"Advisory already exists in Pulp.\")\n",
    "description": "[ErrorDetail(string='Advisory already exists in Pulp.', code='invalid')]"
  },
  "worker": "/pulp/api/v3/workers/a5fe8c87-d11a-495b-b60f-b1cb731dcc6d/",
  "parent_task": null,
  "child_tasks": [],
  "task_group": null,
  "progress_reports": [],
  "created_resources": [],
  "reserved_resources_record": [
    "/pulp/api/v3/repositories/rpm/rpm/bba16ffb-1796-4dca-1234-9dd63432c743/"
  ]
}

I used this method to sync the errata to foreman. However I think there are some issues how foreman processes the errata.

I used this python script to process the errata.xml file.GitHub - vmfarms/generate_updateinfo
then proceeded to make a local repository on the host and synced the repo to foreman. All this works just fine.

The issue however seems to be with how foreman handles that information. CESA_2021__5192 for example. According to foreman there are no hosts that this applies to. While according to spacewalk this errata affects hosts that are registered to foreman.

Package installed currently on the host.
samba-common-4.10.16-15.el7_9.noarch
Package that should contain fix for the security issue.
samba-common-4.10.16-17.el7_9.noarch

So I believe that foreman does not correctly inform the admin about what needs to be updated. AFAIK the packages where the version is lower than what is listed on the updated packages here https://access.redhat.com/errata/RHSA-2021:5192 is affected.

kuva

Foreman does see that the package needs to be updated but doesn’t inform that there is some errata to be applied to the host even though the errata is synced to the host.

I’m curious wheter this is an issue with how foreman handles this specific errata file or something else. ATM I have not updated the package yet, but I’m guessing that when the package matches the package version on the errata updated packaged foreman might inform that there is errata that need to be applied. I’m currently using this errata file. https://cefs.steve-meier.de/errata.latest.xml.bz2

Also noticing the same, I have imported errata also from the same steve-meier source into a new repo centos7-errata which is in my Product named Centos7.

I can find the latest polkit errata from centos mailing list [CentOS-announce] CESA-2022:0274 Important CentOS 7 polkit Security Update in the Centos7 → Centos7-errata repo in katello. If I select the errata it shows me I have hosts this is applicable to, and I’m redirected to the content page listing those hosts.

The applicable package is installable on those hosts, but that list of hosts shows no security errata available.

Correction, the following is not accurate:

If I select the errata it shows me I have hosts this is applicable to, and I’m redirected to the content page listing those hosts.

If I click on the errata it shows no hosts are applicable, and no content hosts are listed. If I select packages, click the applicable package, ie polkit from example above, I then see the count of hosts polkit is installed on, and how many are upgradable. Clicking on upgradable redirects to content → with the following query upgradable_rpms=polkit-0.112-26.el7_9.1.x86_64.

So the errata from the centos7-errata repo doesn’t associate with packages in another repo.

Hi @Stevedd
Do you use a content view? In my case, i see the errata in the repo, but it doesn’t present in published versions of ContentView.

On my Foreman server i’ve created a local repo in /var/www/html/pub/centos_errata/7, then using a script i import and inject errata to the local repo
generate_updateinfo.py -s all -t all -v <(bzip2 -dc /tmp/errata.latest.xml.bz2)
/usr/bin/modifyrepo /tmp/updateinfo-7/updateinfo.xml /var/www/html/pub/centos_errata/7/repodata/

In Foreman i’ve added a new repo, synched it to a local repo https://foreman/pub/centos_errata/7/ (here i see all errata), added this new repo to a CV and published.
There are no errata in published version

It appear only in case if i add an errata by an incremental update:
hammer content-view version incremental-update --content-view-version-id NNNN --errata-ids NNNN --organization XXXX

I’m on foreman-3.0.1-1, katello-4.2.1-1

Best regards,

Finally i’ve found a problem:
my ContentView had a filter for one rpm ( qpid-proton-c ), after deleting this filter and publishing a new version of CV, all errata is visible in the CV version and at the host.

The errata in from the repo doesn’t seem to be associated correctly by foreman. For CESA-2022:0274 polkit-0.112-26.el7_9.1.x86_64.rpm seem to be the solution package which has the vulnerability fixed. So the errata should show all hosts that need to upgraded to that package. For example polkit-0.112-11.el7_3.x86_64 which should be shown as a security errata for that packages simply gets registered to a package which need to be upgraded and not showing errata properly.

kuva
kuva
kuva

I’ve created a separate post regarding that issue but so far no solutions have been provided. I don’t know wether the issue lies in xml file, the script that processes it or in how foreman handles errata from local repos. Errata is shown correctly atleast with AlmaLinuxes.

I’m using a locally built CentOS 7 errata repository, attached to a content view, and it seems to be working fine for the CESA mentioned:

As “yum list-sec” shows it:

CESA_2022__0274 Important/Sec. polkit-0.112-26.el7_9.1.x86_64

Well how do you create that repo? I’m wondering if there is some difference on how we create the local repo and that’s the reason why it doesn’t work properly for me.

using this script (https://github.com/vmfarms/generate_updateinfo)

This is how i sync the errata. I’m not using content views but that really shouldn’t affect on how errata is handled in the system


#download latest errata
wget -q https://cefs.steve-meier.de/errata.latest.xml.bz2 -e use_proxy=yes -e https_proxy=http://proxy:3128 -O /var/lib/foreman-errata/errata.latest.xml.bz2
/usr/bin/bzip2 -d -f /var/lib/foreman-errata/errata.latest.xml.bz2
#process the errrata
/usr/bin/python /usr/bin/generate_updateinfo.py -s all -t all /var/lib/foreman-errata/errata.latest.xml -d /tmp/ > /dev/null 2>&1
#inject errata to a local repo
modifyrepo /tmp/updateinfo-7/updateinfo.xml /var/www/html/pub/centos7-errata/repodata/ > /dev/null 2>&1
#sync via api


Hi John- Can you please explain me on this.

  • Ive created a folder on /var/www/html/pub/centos-errata/
  • used createrepo /var/www/html/pub/centos-errata/ to create the repodata.
  • Executed the commands as per the git (GitHub - vmfarms/generate_updateinfo)

wget -q -N -P/tmp http://cefs.steve-meier.de/errata.latest.xml.bz2

(cd /tmp/ && sha1sum -c <(wget -qO- http://cefs.steve-meier.de/errata.latest.sha1|grep bz2) )

generate_updateinfo.py <(bzip2 -dc /tmp/errata.latest.xml.bz2)

but it throws the below error. Can you help what im i missing here

WARNING:root:Unwanted advisory type: CEEA-2021:4452. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4473. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4488. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4491. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4498. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4514. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:4539. Skipping
WARNING:root:Unwanted advisory type: CEEA-2021:5239. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0684. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0687. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0702. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0703. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0790. Skipping
WARNING:root:Unwanted security advisory severity: CESA-2014:0827. Skipping