Hi Tomas, No, we don't use multiple activations keys. We tie the AK_<os>_<product>_<lifecycle> key to the <os>/<region(s)>/<lifecycle>/<product> hostgroup. We have 7 lifecycles and 4 regions, so each product has 7 * <no of os's> activation keys and each product has <os's> * 7 (lifecycles) * 4 (regions) hostgroups. You end up with a lot quickly! The only way to manage this is scripting. For building the activations keys, we copy the os key (so it keeps the subscriptions) then we add the new subscriptions (the products created) and adjust the content view.
On Thursday, March 2, 2017 at 12:59:11 PM UTC-5, Tomas Hajek wrote: > > Andrew, > I did read over you post in that thread and it was very helpful. I think > even though we only have a couple hundred servers there are very few that > are actually alike I think your methodology probably fits fairly well but I > also like Rich's suggestion of using multiple activation keys. I was > wondering about the shear number of activation keys that we would wind up > with and I suppose automating that might help, that appears to be what you > did base on your note about building the Activation Keys pragmatically. Do > you use multiple activation keys, I'm somewhat assuming not based on you > example of AK_<os>_<lifecycle> and AK_<os>_<product>_<lifecycle>? > thanks again, > -Tomas > > On Wed, Mar 1, 2017 at 9:24 PM, Andrew Schofield <a...@ourhavens.co.uk > <javascript:>> wrote: > >> 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" <tha...@gmail.com> >>> *To: *"Foreman Users" <forema...@googlegroups.com> >>> *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 < >>> forema...@googlegroups.com> 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" <tha...@gmail.com> >>>> *To: *"Foreman Users" <forema...@googlegroups.com> >>>> *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 foreman-user...@googlegroups.com. >>>> To post to this group, send email to forema...@googlegroups.com. >>>> 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 >>>> foreman-user...@googlegroups.com. >>>> To post to this group, send email to forema...@googlegroups.com. >>>> 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 foreman-user...@googlegroups.com. >>> To post to this group, send email to forema...@googlegroups.com. >>> 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 >> foreman-user...@googlegroups.com <javascript:>. >> To post to this group, send email to forema...@googlegroups.com >> <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 foreman-users+unsubscr...@googlegroups.com. To post to this group, send email to foreman-users@googlegroups.com. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
