Upload deb package through hammer results in empty/invalid packages in repo

Support
1

Problem:
We want to upload a custom package each day so we can install and upgrade it overtime to know when a system is patched.
I’ve made a simple .deb file that makes a file in json format in /etc/ansible/facts.d/ and if i install it it also works. If i upload it through the UI that also works fully. But it’s when i upload it with hammer that i get an empty row and the subscription-manager clients also report they can’t find the package.

Looking with hammer, i see in the deb-package list an ID created but not FILENAME:

image
image699×140 4.51 KB

image
image1265×416 27.8 KB

Trying to remove said .deb also resulsts in a task stuck:

image
image1104×654 47 KB

Error the clients get once we upload the package using hammer:
Failed to fetch katello://foreman.server.lan/pulp/deb/comp/Production/CV_UBUNTU_22-04/custom/Today_I_Patched_Package/Today_I_Patched_Package/dists/default/all/binary-amd64/Packages 404 Not Found

As root i upload the package from the current directory like so:
hammer repository upload-content --path pocket_mouse.deb --organization comp --product “Today I Patched Package” --name “Today I Patched Package”

A seperate product and repo is made with the same name, so we can include the product into every CV.

The upload also goes smoothly: Successfully uploaded file pocket_mouse.deb

I’ve also tried a package that was sync’d from ubuntu and that one also has the same behavior, so i believe the way i packaged shouldn’t be the issue.

Does anyone have a suggestion how i can find more information how to find a possible workaround/the root cause that i or maybe we can provide to fix in foreman itself (if applicable)?

Expected outcome:
deb package is uploaded if it isn’t already in the repository.

Foreman and Proxy versions:
3.11.2

Foreman and Proxy plugin versions:

Installed Packages

  • ansible-collection-theforeman-foreman-4.0.0-2.el9.noarch
  • candlepin-4.4.14-1.el9.noarch
  • candlepin-selinux-4.4.14-1.el9.noarch
  • dynflow-utils-1.6.3-1.el9.x86_64
  • foreman-3.11.2-1.el9.noarch
  • foreman-cli-3.11.2-1.el9.noarch
  • foreman-dynflow-sidekiq-3.11.2-1.el9.noarch
  • foreman-installer-3.11.2-1.el9.noarch
  • foreman-installer-katello-3.11.2-1.el9.noarch
  • foreman-obsolete-packages-1.9-1.el9.noarch
  • foreman-postgresql-3.11.2-1.el9.noarch
  • foreman-proxy-3.11.2-1.el9.noarch
  • foreman-redis-3.11.2-1.el9.noarch
  • foreman-release-3.11.2-1.el9.noarch
  • foreman-selinux-3.11.2-1.el9.noarch
  • foreman-service-3.11.2-1.el9.noarch
  • katello-4.13.1-1.el9.noarch
  • katello-ca-consumer-vcdsat01.virtualcenter.lan-1.0-7.noarch
  • katello-certs-tools-2.10.0-1.el9.noarch
  • katello-client-bootstrap-1.7.9-2.el9.noarch
  • katello-common-4.13.1-1.el9.noarch
  • katello-repos-4.13.1-1.el9.noarch
  • katello-selinux-5.0.2-1.el9.noarch
  • pulpcore-obsolete-packages-1.2.0-1.el9.noarch
  • pulpcore-selinux-2.0.1-1.el9.x86_64
  • python3.11-pulp-ansible-0.21.8-1.el9.noarch
  • python3.11-pulp-cli-0.27.2-1.el9.noarch
  • python3.11-pulp-container-2.20.3-1.el9.noarch
  • python3.11-pulp-deb-3.2.1-1.el9.noarch
  • python3.11-pulp-glue-0.27.2-1.el9.noarch
  • python3.11-pulp-python-3.11.3-1.el9.noarch
  • python3.11-pulp-rpm-3.26.1-1.el9.noarch
  • python3.11-pulpcore-3.49.19-1.el9.noarch
  • rubygem-dynflow-1.8.4-1.el9.noarch
  • rubygem-foreman-tasks-9.1.1-1.fm3_11.el9.noarch
  • rubygem-foreman_ansible-14.0.0-2.fm3_11.el9.noarch
  • rubygem-foreman_azure_rm-2.3.0-1.fm3_11.el9.noarch
  • rubygem-foreman_discovery-24.0.1-2.fm3_11.el9.noarch
  • rubygem-foreman_maintain-1.6.9-1.el9.noarch
  • rubygem-foreman_openscap-8.0.2-1.fm3_11.el9.noarch
  • rubygem-foreman_remote_execution-13.1.0-1.fm3_11.el9.noarch
  • rubygem-foreman_rh_cloud-9.0.56-1.fm3_11.el9.noarch
  • rubygem-hammer_cli-3.11.0-1.el9.noarch
  • rubygem-hammer_cli_foreman-3.11.0-1.el9.noarch
  • rubygem-hammer_cli_foreman_ansible-0.7.0-1.fm3_11.el9.noarch
  • rubygem-hammer_cli_foreman_azure_rm-0.3.1-1.fm3_11.el9.noarch
  • rubygem-hammer_cli_foreman_remote_execution-0.3.0-1.el9.noarch
  • rubygem-hammer_cli_foreman_tasks-0.0.21-1.fm3_11.el9.noarch
  • rubygem-hammer_cli_foreman_virt_who_configure-0.1.0-1.fm3_10.el9.noarch
  • rubygem-hammer_cli_katello-1.13.0-0.2.pre.master.el9.noarch
  • rubygem-katello-4.13.1-1.el9.noarch
  • rubygem-pulp_ansible_client-0.21.3-1.el9.noarch
  • rubygem-pulp_certguard_client-3.49.6-1.el9.noarch
  • rubygem-pulp_container_client-2.20.0-1.el9.noarch
  • rubygem-pulp_deb_client-3.2.0-1.el9.noarch
  • rubygem-pulp_file_client-3.49.6-1.el9.noarch
  • rubygem-pulp_ostree_client-2.3.0-1.el9.noarch
  • rubygem-pulp_python_client-3.11.1-1.el9.noarch
  • rubygem-pulp_rpm_client-3.26.1-1.el9.noarch
  • rubygem-pulpcore_client-3.49.6-1.el9.noarch
  • rubygem-puppetdb_foreman-6.0.2-1.fm3_10.el9.noarch
  • rubygem-smart_proxy_dynflow-0.9.2-1.fm3_11.el9.noarch
  • rubygem-smart_proxy_pulp-3.3.0-1.el9.noarch

Distribution and version:
RHEL 9.4

Other relevant data:

2

So I tried reproducing this with a random package (just to make sure there isn’t anything specific to your self built package that is causing this).

My example package was vim_9.0.1378-2_amd64.deb.

In my case, uploading the package sometimes resulted in what you described, depending on what hammer options I used. The following resulted in a blank line package entry:

hammer repository upload-content --path vim_9.0.1378-2_amd64.deb --id 123 --content-type deb

However the following appears to have worked:

hammer repository upload-content --path vim_9.0.1378-2_amd64.deb --id 124 --content-type deb --organization Example

In both cases Hammer claimed success:

[...............................................] [100%]
Successfully uploaded file vim_9.0.1378-2_amd64.deb

I initially tried supplying both --id and --product-id, but Hammer complained I can’t supply both of those. This does not make any sense to me, since supplying just a product does not yet uniquely identify a Katello repository, but o well…

@Macley Can you perhaps try adding the --content-type deb flag and parameter to your command? I recommend testing the upload on an entirely new otherwise empty repository to see if that changes the result.

Even if some combination of Hammer flags end up resulting an a working deb upload, other combinations should not result in a broken state. They should either fail hard with a meaningful error or fully succeed. So that is definitely a bug.

Can you please open an issue at Issues - Foreman?

I will also raise this internally.

1 Like
3

Ok, I did some more testing and it looks like what I reported in my previous post is not quite right.

It is not the case that this worked depending on what Hammer options I use, but rather it appears to always fail the first time I upload the package in question to a repo. Then If I try to upload that same package again to a different repo, I now appear to get a working state. Re-upload to the first repo that contains the broken state, results in that repo reporting that it now contains 2 packages, one of which is the broken state, and one is what looks like a working state.

Pretty weird, definitely a bug.

1 Like
4

Hi! Just wanted to try out your first suggestion! But the tests you did futher definitly align with what i’m experiencing aswell! I will make a bug report!
Thank you so much already for responding so quickly and giving such throughout explaination! It’s very appricated!
Btw, i do believe if you do the same with an rpm package that you won’t have this issue (tho i only tested this with Satellite). Will update this message to include the bug report i’ve made!

5

Please post a link to the issue you create in this thread, so I can find it. :wink:

1 Like
6

Have to wait for an admin to approve my account :slight_smile: But will write down a message in notepad so i can post it immediatly! Definitly will link to this discussion aswell!

7

sorry still can’t upload the bug to the site, have to wait still for my account to be approved.

8

Done.

You should have received a mail with a verification link, tho :slight_smile:

1 Like
9

thank you very much you two! I have created the bug here:

Sorry for submitting it with having the resolved in version ticked, i tried to untick it but it didn’t let me sadly (and i think it’s less ideal to recreate the whole bug report).

It’s a low prioty issue (IMO) as double uploading does fix it in a way that the package can be downloaded, even when upgraded!

1 Like