You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, in our environment our servers install packages from our internal Red Hat Satellite server.
Normally we have no issue mimicking the configuration of the repository as represented in a repo-definition in Satellite (version 6.13.1).
With the routinator repo however for RedHat 9, we run into the problem that Satellite will not synchronize the repository. The error we get is:
Katello::Errors::Pulp3Error: Treeinfo file should have INI format
After looking into it a little, it turns out that yum repository's may contain a file named '.treeinfo', and expects a 404 response if a repository does not contain one. When I send a GET request to https://packages.nlnetlabs.nl/linux/centos/9/main/x86_64/.treeinfo for example I receive a 200 OK response of:
Hi, thanks, we've worked around this by upgrading satellite to 6.14.4 which (from version 6.14.1 I think) has an option Ignore treeinfo which can be enabled.
Hi, in our environment our servers install packages from our internal Red Hat Satellite server.
Normally we have no issue mimicking the configuration of the repository as represented in a repo-definition in Satellite (version 6.13.1).
With the routinator repo however for RedHat 9, we run into the problem that Satellite will not synchronize the repository. The error we get is:
After looking into it a little, it turns out that yum repository's may contain a file named '.treeinfo', and expects a 404 response if a repository does not contain one. When I send a GET request to https://packages.nlnetlabs.nl/linux/centos/9/main/x86_64/.treeinfo for example I receive a 200 OK response of:
The pulp error is I think from trying to parse that response as an INI file.
Would it be possible to respond with a 404 to any /.treeinfo or /treeinfo GET requests to avoid this issue?
Kind regards,
George Salisbury
The text was updated successfully, but these errors were encountered: