Tomas - I'd read that whole thread. I have a post in there too which explains my view of the world - it works well for our (large (20k+), multi region, multi user) setup and takes a very structured approach. Its probably overkill for a few hundred servers.
On Monday, February 27, 2017 at 11:54:16 AM UTC-5, Jason B. Nance wrote: > > 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] <javascript:>> > *To: *"Foreman Users" <[email protected] <javascript:>> > *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 - 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 < > [email protected] <javascript:>> 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" <[email protected] <javascript:>> >> *To: *"Foreman Users" <[email protected] <javascript:>> >> *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. 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit 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. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at https://groups.google.com/group/foreman-users. > For more options, visit 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.
