RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2020678 - [conn] reposync with installroot fails when repo_gpgcheck is True
Summary: [conn] reposync with installroot fails when repo_gpgcheck is True
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf
Version: 8.0
Hardware: All
OS: Linux
medium
unspecified
Target Milestone: rc
: ---
Assignee: amatej
QA Contact: Jan Blazek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-05 15:46 UTC by Drazen Kacar
Modified: 2022-11-08 12:29 UTC (History)
4 users (show)

Fixed In Version: dnf-4.7.0-11.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-08 10:47:20 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
reposync debug output (3.96 KB, text/plain)
2021-11-05 15:46 UTC, Drazen Kacar
no flags Details
dnf.librepo.log from installroot (47.64 KB, text/plain)
2021-11-05 15:47 UTC, Drazen Kacar
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-102182 0 None None None 2021-11-09 15:09:03 UTC
Red Hat Product Errata RHBA-2022:7712 0 None None None 2022-11-08 10:47:35 UTC

Description Drazen Kacar 2021-11-05 15:46:37 UTC
Created attachment 1840207 [details]
reposync debug output

Description of problem:

reposync with installroot specified fails when repo file contains repo_gpgcheck=1. When I comment out that directive it works fine.



Version-Release number of selected component (if applicable):

# rpm -qa python3-dnf
python3-dnf-4.4.2-11.el8.noarch


How reproducible:

I'm doing this:
> sudo su - repoman
> pubrepoadm distro sync -n pgdg14

pubrepoadm is a script which calls:

reposync -c /data/yumrepos/public/distroroot/common-8/etc/dnf.conf -p /data/yumrepos/public/pkgmirror/common/8/x86_64 -g -n --download-metadata --remote-time --repoid=pgdg14

There is installroot specified in that dnf.conf. The repo file contains this:

[pgdg14]
name=PostgreSQL 14 for RHEL/CentOS $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/14/redhat/rhel-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
repo_gpgcheck = 1

I'm getting:

Errors during downloading metadata for repository 'pgdg14':
  - Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG]
Error: Failed to retrieve GPG key for repo 'pgdg14': Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG]

I've tried with --installroot instead of -c and with both of them specified, but
the result is the same.

Debug output with '-d 10' is in the attachment.

Contents of dnf.conf in installroot:

[main]
installroot=/data/yumrepos/public/distroroot/common-8
# This should probably be removed for CentOS 8 because it's logging in
# reporoot.
logfile=/var/log/repoman/dnf.log
keepcache=0

payload_gpgcheck=1
gpgcheck=1

assumeno=1

installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False


The default OS directory does not contain the GPG key mentioned in the error message:
# ls /etc/pki/rpm-gpg 
RPM-GPG-KEY-AlmaLinux  RPM-GPG-KEY-EPEL-8

But it is present in the installroot:
# ls /data/yumrepos/public/distroroot/common-8/etc/pki/rpm-gpg 
RPM-GPG-KEY-elrepo.org  RPM-GPG-KEY-jenkins  RPM-GPG-KEY-SALTSTACK
RPM-GPG-KEY-EPEL-8      RPM-GPG-KEY-nginx
RPM-GPG-KEY-grafana     RPM-GPG-KEY-PGDG

All those keys are imported in the respective keyrings (OS default in the OS keyring and installroot keys in the installroot keyring).

It seems to me that reposync attempted to fetch the GPG key file from the OS path /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG instead from that path inside installroot.

I'm also attaching dnf.librepo.log from the installroot. It doesn't have additional information, though.

Steps to Reproduce:


1. Create minimal installroot necessary for reposync to function
2. Add the above repo file
3. Run reposync

If I comment out repo_gpgcheck directive everything works fine.

Actual results:

Execution is aborted.

Expected results:

reposync should be able to do its thing without an error.

Additional info:

In the debug output there is:

Failed to create directory "/run/user/1104": 13 - Permission denied

1104 is the UID for repoman user. I've created that directory manually, but the result is the same. The only difference is that an empty directory named gnupg is created there.

Comment 1 Drazen Kacar 2021-11-05 15:47:47 UTC
Created attachment 1840208 [details]
dnf.librepo.log from installroot

Comment 4 amatej 2022-06-15 07:39:48 UTC
I have investigated this and I believe it is not a bug.

> It seems to me that reposync attempted to fetch the GPG key file from the OS path /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG instead from that path inside installroot.
You are correct, this is documented in the dnf manpage installroot section: 
...
cachedir, log files, releasever, and gpgkey are taken from or stored in the installroot.
Gpgkeys are imported into the installroot from a path relative to the host which can be specified in the repository section of configuration files.
...

This means that it tries to load the gpg key from the host and store it inside the installroot. I think the first sentence could be confusing and there is room for improvement but it is clarified in the second sentence.

> All those keys are imported in the respective keyrings (OS default in the OS keyring and installroot keys in the installroot keyring).
If you mean they are imported by rpm that is only relevant to the `gpgcheck` option (so for packages) for `repo_gpgcheck` - for signed repository metadata we actually store keys separately for each repo. Therefore the key is likely not yet imported for the pgdg14 repo.
You can verify this if you place the key into /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG on the host and run reposync, it will ask to import it and everything will work. If you try reposync again but remove the `gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG` setting from the repo config it will continue to work because the key is already imported.

I think this is not documented anywhere though so we could fix that if you think it would be helpful.

Comment 5 amatej 2022-06-23 07:48:29 UTC
I have created a PR with the doc update: https://github.com/rpm-software-management/dnf/pull/1833

Comment 12 errata-xmlrpc 2022-11-08 10:47:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7712


Note You need to log in before you can comment on or make changes to this bug.