JohnAdams
Flight Engineer
Flight Engineer
  • 172 Views

Custom product repo sloppiness leads to woe--how to fix it?

Hi, folks,

     I've got a design question resurfacing because of a poor (in my opinion) decision in the past.

     Our Satellite instance is set up with one custom product containing four repos, organized by category. Today I hit a major OS conflict--RHEL 7 boxes asking for a RHEL 8 package--and it's got me rethinking. What is the best way to organize custom products and the repos they contain. Should I create a product for each OS release level, and put repos in there? Maybe just one product/release, one repo/product?

     What do you do?

Thanks,

     John A

Labels (1)
0 Kudos
1 Reply
Fran_Garcia
Flight Engineer Flight Engineer
Flight Engineer
  • 154 Views

Each repository should only contain RPMs pertaining to a specific product and RHEL combination, ie:  foo.rpm for RHEL7 in repo foo-for-rhel7 ; foo.rpm for RHEL8 in foo-for-rhel8 to avoid issues as you describe.

There's another caveat that with custom repos, all repos are automatically enabled when added to a Content View, so you need to be mindful which repos are present in each CV as to not incur a repo for RHEL_8 when your clients are RHEL_7.

 

If you don't use CVs, or you have multiple repositories of a product for different versions of RHEL in the same CV, you need to ensure only the relevant repository is enabled in each client, although that approach seems to be more error-prone and subject to misconfiguration in the clients (again, all repos pertaining to a custom product will be enabled by default).

 

HTH

 

Fran

0 Kudos
Join the discussion
You must log in to join this conversation.