Syncing Ubuntu 18.04 repo failed - GNUPGHOME should be a directory?

Support
1

Spinning up a new dev version of Foreman with Katello that has Debian repo support. I’m wanting to get Foreman, Katello and Puppet to manage Ubuntu systems primarily. The installation is on an updated, fresh install of CentOS 7.

I’ve created a repo sync and product, but I’m stuck trying to sync the repo (main 18.04 repo) and the error that spits out suggests a variable is not set, “GNUPGHOME”, but I can’t find any documentation where I missed steps to set that up. Error:

"  File \"/usr/lib/python2.7/site-packages/pulp_deb/plugins/importers/sync.py\", line 187, in verify_release_file\n" +
 "    gpg = self.gnupg_factory(homedir=os.path.join(self.get_working_dir(), 'gpg-home'))\n" +
 "  File \"/usr/lib/python2.7/site-packages/pulp_deb/plugins/importers/sync.py\", line 177, in gnupg_factory\n" +
 "    return gnupg.GPG(*args, **kwargs)\n" +
 "  File \"/usr/lib/python2.7/site-packages/gnupg.py\", line 827, in __init__\n" +
 "    raise ValueError('gnupghome should be a directory (it isn\\'t): %s' % gnupghome)\n" +
 "ValueError: gnupghome should be a directory (it isn't): /var/cache/pulp/reserved_resource_worker-3@dev-foreman/e9d6a31e-9e86-405d-bec6-9268020266af/gpg-home\n",

Can anyone help me with this? I have a feeling this is something that shouldn’t be too hard to fix.

2

I experience the same on Foreman 2.0.2 / Katello 3.15 trying to sync Debian Buster repos. It used to work with 1.24 / 3.14.

3

I could solve this by removong the GPG key from the Debian repository definitions in Foreman/Katello. At least the repos sync again now.

4

Don’t I need to have a GPG key added/declared for it to accept the sync configuration? Or does it magically retrieve the correct GPG key from the repo under the assumption I trust the repo when first setting it up?

Also, I don’t know why I didn’t get notifications you posted here, oof. Thanks for the ideas so far! I’ll have to try them soon :slight_smile:

5

The underlying issue is that a newer version of python2-gnupg has changed its behaviour vis-a-vis directory creation, when it is not there already.

There is a fix on the pulp_deb side that was merged to master:

(Strictly speaking only the following commit is the actual fix: Fix gnupg metadata verification by quba42 · Pull Request #190 · pulp/pulp_deb · GitHub)

Unfortunately I missed the last opportunity for a final pulp_deb for Pulp 2 release, and it looks uncertain if and when there will be another.

Your current options are to stop using GPG verification for Debian/Ubuntu syncs, or to manually add the above patch. (The file you need should be at /usr/lib/python2.7/site-packages/pulp_deb/plugins/importers/sync.py, do a foreman-maintain service restart after patching the file.)

@BloodyIron For GPG keys to be used you need to manually add them as a content credential. There is no automatic adding of GPG keys/setup for signature verification.

1 Like
6

Thanks @quba42 ! I’ll check into that fix and probably just apply the code manually. I don’t think running syncs without signing is a good idea.

That being said, I’m not entirely sure for Ubuntu/Debian repos which key I should be getting and from where, as all the guides I’ve found talk about CentOS/Fedora/RHEL repos, and those steps don’t translate for Ubuntu/Debian. Can you advise me on that aspect? I have imported a key, but not yet sure if I’ve imported the right one.

Your help is appreciated! :slight_smile:

7

We have some documentation on obtaining content credentials for Ubuntu and Debian in our downstream orcharhino documentation: Redirect Notice

I hope that helps.

PS: There is an active project to convert our orcharhino documentation to the same format used by the new Foreman documentation. At that point we hope to make some of our documentation available to the upstream Foreman documentation. However, I expect this effort will still take some time. :wink:

4 Likes
8

This has been exceptionally helpful! I was worried posting on the forums for such a bleeding edge use-case would not get me anywhere. I’ll definitely have to make the time to get this going, and I suspect I should be successful with this all! :slight_smile:

Thanks! And I also should remember to post my results here once I have them.

2 Likes
9

Hey @quba42 so I tried your instructions for modifying the sync.py file as per that github commit, and it didn’t resolve the matter by itself.

I made sure to remove the specific line and add the lines of code that the commit talks about, verified correct spacing, no silly hidden characters etc. I ran “foreman-maintain service restart” and the sync task kept complaining about “/var/lib/pulp/gpg-home/” (directory) not existing. I even tried a full reboot, same thing.

I verified the py file didn’t get reverted, or permissions changed on it, so I do believe I followed your instructions to the letter. I also followed your linked guide for getting the relevant PGP key (which btw helped a tonne!) and I do believe I have the correct key in-place now.

That being said, what I had to do to get the sync task actually executing (and it appears to be downloading content as I type this) is by making the “gpg-home” folder, that didn’t exist, in the /var/lib/pulp/ directory. I set it with 775 permissions, and set ownership of apache:pulp as that seemed like a logical configuration. I’m not sure if that’s the actual configuration I should have set, as I see the code talks about 700 modes being set, my set was best-effort.

So, I’m not sure why the code change didn’t fix it, since the code clearly talks about making the folder. Any idea why this failed?

Also, this is a dev box, but I am curious, will updates to these packages in the future from my repos eventually give me the newer pulp python scripts with the latest “fixed” code that has already been submitted? I’m curious about best-practices here, if I should change permissions/ownership of that folder, stuff like that.

Your help is greatly appreciated here, and without it I would really be so very stuck! So I look forward to your further thoughts on this topic. :slight_smile:

10

This sounds like fixing your original issue allowed you to run into a secondary issue.

Full explanation:

The fix I had you apply will create a GPG home folder in the working directory of the pulp worker executing the sync task. This is needed to verify the signature of the remote repository you are syncing.

By contrast, the GPG home at /var/lib/pulp/gpg-home/ is normally used to house a (secret) key for signing any repositories published by Pulp (this is configuration dependent, so it is difficult to make general statements). Katello always has Pulp publishes any repositories you have synchronized (as part of the same Foreman sync task). As a result, applying the fix to your first issue allowed you to run into this secondary issue (which is not handled by the fix I posted).

As you found out already, you can work around this issue without any code changes, since the relevant directory is not located in a temporary worker location, but in a fixed place. Regarding best practice permissions: On our system we create this folder with ownership apache:apache (but apache:pulp is probably also fine), with permissions of 700. Any files within the folder are given permissions of 600.

The workaround might be summarized as:

mkdir -p /var/lib/pulp/gpg-home/
chown apache:apache /var/lib/pulp/gpg-home/
chmod 700 /var/lib/pulp/gpg-home/
1 Like
11

Unfortunately there is a fair chance that the fix will not be packaged for Pulp 2.
The reason is that Pulp 2 is in maintenance mode and may not receive many more releases (and I sometimes miss releases even if they happen, since I am not a full time Pulp developer).

This means that the bug will likely remain in Foreman/Katello until your Katello installation is switched to Pulp 3. (Pulp 3 is a complete rewrite with a completely separate code base, so at that point all existing bugs will be gone, replaced by all new Pulp 3 bugs :wink:.)

There will probably be several more Foreman/Katello releases before the Pulp 3 version of the Pulp Debian plugin is integrated into Katello. If you update to such a release the bug will likely return and you will have to reapply the patch.

12

Well that makes sense. Any idea why the secondary, more permanent, folder isn’t getting made from earlier steps?

I’ll have to remember these permission recommendations next attempt I make, I’ve gotten roadblocked later in the Content Host management aspect. Thanks as always! :slight_smile:

13

I really don’t mind rebuilding from scratch anyways, as it looks like I’m rather behind on versions for Foreman anyways, as I think I’m on 1.24 hahah! This is dev, so rebuilding from scratch, while annoying, is plenty acceptable. I’m effectively trying to identify what I need to do to eventually build a production environment to leverage these tools, and if that means rebuilding several times along the way, so be it!

I appreciate your insight into me probably needing to use Pulp3! Thanks for all this :slight_smile:

14

Oh, forgot to ask. Do you know if the Foreman+Katello installation methods have been or will be updated to include Pulp3 and/or the relevant fixes here? Or am I misunderstanding?

16

They will be, however this is still in development and will still take some time.
For example, adding Pulp3 Debian support to Katello is still a PR at this point (https://github.com/Katello/katello/pull/8632).

17

Update: The fix is slated for inclusion in the Pulp 2.21.4 Release:
https://pulp.plan.io/projects/pulp/wiki/2214_Release_Schedule

1 Like