Problem:
I’ve inherited a very poorly/badly/non documented installation of foreman from an admin that has left.
Many of the configured products with external defined repositories do not sync. I’ve sorted most of them but I am stuck on epel for RHEL8.
I am learning on the hoof - I have no previous foreman experience. It is what it is…
The configured product "epel_x86-64 has two repositories defined within it
epel 7
epel8_x86-64 (no, I dont know why some commonality in naming wasn’t used either.)
epel7 syncs perfectly.
epel8_x86-64 sync thinks about it for some while then errors with “A sub task failed”.
Both setups are configured the same wrt type=yum, no restrictions on architecture, verify SSL is yes, defaults for yum metadata and http proxy (none!) etc etc.
there is a difference in GPG key : epel 7 has NO gpg key connected to it, while epel8 has a key … I have no knowledge of why it has one when 7 doesn’t or where the key it does have came from. If i try the sync with NO epel 8 gpg key configured it errors as above “A sub task failed”.
Expected outcome:
a correct setup so that this rhel8 epel product/repo syncs as expected and is safe to use
Not sure if I can solve your problem, but at least I can give you some explanation and show you some errors.
So the URL for EPEL 8 seems to be correct, you can see this by the directory repodata on this level and it containing the metadata. You could try a mirror instead if problem persists.
But having only this repository is not enough as with EL8 onwards there is a split of non-modular and modular repositories. So next to Everything is Modular which will also be needed!
The GPG key does not matter for the sync, so it explains that you get the same error independent of it being set or not. Having the GPG key set will change the repository on the Hosts by enabling gpg checking and providing the key. So best practice would be to have it always set! You can also have one set for the product which will then be the default for all repositories if it is version independent (not the case for EPEL, but could reduce overhead for others).
Some general hints on debugging repo sync issues.
Pulp (the component that actually handles all the repository stuff in the background) logs everything to journald, so you might find some pointers in there with journalctl -u '*pulp*'.
Sometimes it can also be helpful to take a look at the tasks in the task engine. In the Foreman UI, you can navigate to “Monitor” → “Tasks” and search for e.g. “Sync epel8” in there and take a look at the task details page or continue to “Dynflow Console” and see if you can find any more helpful error messages in there.
For your current problem, I have very vague memories of EPEL changing something in their repository metadata that older versions of Pulp/Katello (like 3.2) do not like. Though this is more of a gut feeling than something I can undermine with facts, it might be worth a try to adjust the mirroring policy of the repo. You can try this from the Foreman UI by navigating to Content → Products → select your EPEL product → select the EPEL8 repo → in the “Sync Settings” section, if “Mirroring Policy” is set to “Complete Mirroring” try changing this to “Additive” or “Content Only”.
What this will do is tell Pulp to not use the upstream metadata (which it might not be able to use), but instead only download the packages and build the repo metadata itself. The difference between “Additive” and “Content Only” is, that “Content Only” will remove packages that are deleted upstream, while “Additive” will only download new packages but not remove the ones that were deleted upstream.
After this, try to sync the repo and see if the error is gone.
“with EL8 onwards there is a split of non-modular and modular repositories. So next to Everything is Modular which will also be needed!”
OK… so how do I configure that in the foreman product/repository? If Everything needs Modular also, how do I tie the two together such that Everything is happy when it syncs?
No problem, just feel free to ask any questions we had all to start somewhere and getting thrown into the cold water is perhaps not the best start you could get.
No need for those repositories to be tied in a way, they just have to be both synced and then available to the systems to function properly. If missing one or the other you will just miss packages. The other way round it would be more likely to cause problems because modular packages can depend on non-modular ones but not the other way round!
modular syncing fine
“everything” syncing continues to error with “Fatal parser error”.
Ive also tried uni of kent mirror and Index of /fedora-epel/8/Everything/x86_64/ as testers - same result. Ive created a new repository in my foreman set up - same result.
Tried journalctl -fu ‘pulp’| grep “16/Jul” | grep epel | grep -v “200 253”
but that returns very little and nothing of anything obvious ie every thing is a 200 return code.
without that final filter I see plenty of logging eg
But the version of pulp_rpm shipped with Red Hat Satellite 6.11 or below is simply unaware of how to handle that type of metadata, hence the fatal error while parsing the comps metadata file.
So Ive got to work out how to update pulp_rpm ona system that gets its own packages from itself… ie doesnt have any updates to install
So a Katello/Foreman system connected to it self is not supported because of exactly this reason!
But there will be no update for just the pulp_rpm like it is for the Satellite, so you will very likely need to update Katello/Foreman. I would advice to do so anyway as 3.2 is quite old, current supported versions are 3.11 and 3.10.
“But there will be no update for just the pulp_rpm like it is for the Satellite, so you will very likely need to update Katello/Foreman. I would advice to do so anyway as 3.2 is quite old, current supported versions are 3.11 and 3.10.”
Aye. That’s the conclusion I have come too also.
Just got to find an idiots guide to a painless in-place upgrade now…
Confidentiality notice: This email (and any attachment) is intended for the addressee(s) named above. It may contain information of a confidential or legally privileged nature. Unauthorised disclosure or use of this email (or any attachment) is prohibited and may be unlawful. If you are not the intended recipient, please delete the email from your systems, destroy any copies and inform the sender immediately. Privacy notice: To find information on how we collect, process and store data, please see our privacy statement on our website Privacy Statement Disclaimer: All attachments have been scanned for viruses. However, Celebrus Technologies Plc cannot accept liability for any loss or damage you may incur as a result of virus infection.
You can just follow the steps from the documentation, it includes all you have possibly to do. But you have to do it one version after the other so start with Upgrading and Updating Foreman, do a quick verification after that then process with the next version and really use the next versions guide as there may be some specific tasks.
It is more or less painless I promise, but I do not promise it is complete free of pain! But if you run into problems just open another issue here.
But if you run into problems just open another issue here.