Bug 2020678

Summary: [conn] reposync with installroot fails when repo_gpgcheck is True
Product: Red Hat Enterprise Linux 8 Reporter: Drazen Kacar <drazen.kacar>
Component: dnfAssignee: amatej
Status: CLOSED ERRATA QA Contact: Jan Blazek <jblazek>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 8.0CC: amatej, james.antill, mbanas, pkratoch
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dnf-4.7.0-11.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-08 10:47:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reposync debug output
none
dnf.librepo.log from installroot none

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