Hi Lukas, Thanks for the reply I will look into the Candlepin pieces. If I go down the route of using Activation Keys, do you have any recommendations on how best to organize them. For example, would it be best to create all combinations of RHEL version and architecture (e.g. RHEL6_i686, RHEL6_x86_64, RHEL7_x86_64,etc.). I would think that might work as a starting point but if I start to include items like PostgreSQL where there are multiple versions for each RHEL version and arch it seems I would need to add that piece into the activation key (so then have something like RHEL6_x86_64_PostgreSQL_9.4) or potentially install or upgrading the version of PostgreSQL unknowingly. If I follow this through and add other items like MySQL, MariaDB, Nginx, PHP, etc. I seem to then have a large combination of Activation keys. Perhaps I am thinking about this incorrectly or the end result is that I have to manage this manually per host. I was somewhat hoping that the RHEL version and arch would be magically taken care and I could then use the Activation Keys for the specific applications. I could also be overly concerned around installing the incorrect versions of applications. At least where things like PostgreSQL is concerned I believe that most of the package names include the version so postgresql93 is different from postgresql94 and just having those 2 repositories installed would not cause a problem other than overhead on the hosts for pulling down the repo metadata, although then I am reminded of tools like pgbouncer which exist in several repos but tend to be the same version. In cases like that would I be better off in having the PostgreSQL repositories as version specific products instead of having one PostgreSQL product that contained all the PostgreSQL version repos? Has anyone else had a similar problem and solved it or have any other suggestions?
thanks again, -Tomas On Monday, February 27, 2017 at 4:21:13 AM UTC-5, Lukas Zapletal wrote: > > Tomas, > > I am afraid you need to use activation keys mechanism to register to > specific repositories. There is a mechanism for Red Hat products, but > this is X509 based (RHEL contains what's called Product Certificate > that gets sent along with registration and server calculates the > resulting products). Someone from Katello or Candlepin team might know > the details, technically you should be able to leverage that, but this > is pretty low level magic that will be undocumented I believe. > > If you don't get a response here in a week, try candlepin team (they > run their own list). They implemented this feature in Candlepin server > and RHSM client tool, Foreman/Katello should pass this along. > > LZ > > On Sat, Feb 25, 2017 at 1:25 AM, Tomas Hajek <[email protected] > <javascript:>> wrote: > > 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. > > > > -- > Later, > Lukas @lzap Zapletal > -- 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.
