Hi Tomas, Check out my reply in the following thread:
https://groups.google.com/d/msg/foreman-users/q_Qr9sg2PJs/XUN8YEeMDAAJ It includes my reasoning for using CVs and a bit of insight into why I structured how I did. If you have further questions don't hesitate to ask. j From: "Tomas Hajek" <[email protected]> To: "Foreman Users" <[email protected]> Sent: Monday, February 27, 2017 10:41:46 AM Subject: Re: [foreman-users] Recommendations for products with discovered repositories and subscriptions for content hosts Good question. I'm not actively trying to avoid using Content Views just thought I could get a particular issue resolved without them. I am still trying to wrap my head around all of the various organizational structures (Products, Content Views, Activation Keys, Host Groups, Host Collections, Config Groups, etc.) and determine what fits best for various use cases and how best to structure them for our environment. Based on training I am going through right now (RH403 Satellite 6 Administration) I thought one of my use cases would be fairly simple and straight forward to accomplish. Basically, I have about 200 RHEL 6 systems that I need to transition from RHN Classic subscriptions to subscription-manager but with the caveat that most of these systems pull in non-Red Hat repositories and I wanted to get them into Satellite instead of sending each system out through a Squid proxy. So, Instead of going from RHN Classic to RHSM and then to Satellite I thought I would setup the existing repositories that we use as products in Satellite, unregister from RHN Classic, and register with Satellite as Content Hosts and basically be done (without having to deal with Life Cycle Environments and promoting Content Views, etc. as that brings a whole additional level of complexity). If my use case was to only use Red Hat repositories then I think this would work as demonstrated in the training course but as with most things it got complicated quickly. It seemed like Products and repositories were the basic unit set to work with so I wanted to start there. I kind of thought that the discovery mechanism and resultant exposure to clients would work similar to the .repo files with $releasever and $basearch but it's obviously more complicated than that. Would you mind sharing generally how you organized your products and content views (or any other structures) to work with non-Red Hat repositories? Are there any good references that you found on how to organize a Satellite installation? I've gone through a number of youTube videos and some presentations, I thought that the following ( [ https://www.youtube.com/watch?v=9i9Fem9f_I0 | https://www.youtube.com/watch?v=9i9Fem9f_I0 ] - Managing your content with Red Hat Satellite 6) was somewhat helpful but I'd like a little more detail. The RH training is somewhat useful but only if you already have a good idea of how you want to structure and lay everything out and just want to know what commands to execute. Thanks again and I really appreciate all the feedback! On Mon, Feb 27, 2017 at 9:19 AM, 'Jason B. Nance' via Foreman users < [ mailto:[email protected] | [email protected] ] > wrote: Tomas, Are you trying to avoid using Content Views? That is how I deal with this situation. My products are divvied up by vendor but my Content Views are EL version-specific. Regards, j From: "Tomas Hajek" < [ mailto:[email protected] | [email protected] ] > To: "Foreman Users" < [ mailto:[email protected] | [email protected] ] > Sent: Friday, February 24, 2017 6:25:37 PM Subject: [foreman-users] Recommendations for products with discovered repositories and subscriptions for content hosts Greetings, I have a Satellite 6.2.7 installation and I am adding third party repositories using the Discover Repositories function within a product. For example, I add the EPEL repositories with the url [ https://dl.fedoraproject.org/pub/epel | https://dl.fedoraproject.org/pub/epel ] . The repos get discovered for EL 5,6,7 and various architectures (x86_64, i386, etc.). I select those that I am interested in and this all works fine. However, when I register a content host (subscription-manager register --org "Organization" I noticed that the host sees all of the available repositories from that product and not just those specific to it's RHEL version or architecture. So my RHEL 6 x86_64 system now has access RHEL 5 and RHEL 7 packages. Does any one have a recommendation or best practice for how to deal with external repositories like this. It seems that the Red Hat repositories with their related products seem to do this such that the system registered only sees repositories for its relevant RHEL version and arch. I know that there are a number of ways to do this manually with activation keys or specifying within each host entry in Satellite what repositories within a product are on by default but is there a better or simpler way. I considered creating products specific to arch and version but that seems just as difficult to manage. If all all possible I'd prefer that the content host only be able to subscribe to repositories that are relevant to arch and version. I hope that my question makes sense, if not I can try to clarify. Any advice on this would be much appreciated. thanks -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [ mailto:[email protected] | [email protected] ] . To post to this group, send email to [ mailto:[email protected] | [email protected] ] . Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] . For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to a topic in the Google Groups "Foreman users" group. To unsubscribe from this topic, visit [ https://groups.google.com/d/topic/foreman-users/tYSmZHjDKL4/unsubscribe | https://groups.google.com/d/topic/foreman-users/tYSmZHjDKL4/unsubscribe ] . To unsubscribe from this group and all its topics, send an email to [ mailto:[email protected] | [email protected] ] . To post to this group, send email to [ mailto:[email protected] | [email protected] ] . Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] . For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [ mailto:[email protected] | [email protected] ] . To post to this group, send email to [ mailto:[email protected] | [email protected] ] . Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] . For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
