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
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" To: "Foreman Users" Sent: Friday, February 24, 2017 6:25:37 PM Subject: [foreman-users] Recommendations for products with discovered repositories and subscriptions for content hostsGreetings,
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 [ mailto:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
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 ] .
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 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 foreman-users+unsubscribe@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.–
Later,
Lukas @lzap Zapletal
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 > 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 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. > > > > -- > Later, > Lukas @lzap Zapletal >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 < foreman-users@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” thajek@gmail.com
*To: *“Foreman Users” foreman-users@googlegroups.com
*Sent: *Friday, February 24, 2017 6:25:37 PM
*Subject: *[foreman-users] Recommendations for products with discovered
repositories and subscriptions for content hostsGreetings,
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-users+unsubscribe@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.–
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/to
pic/foreman-users/tYSmZHjDKL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@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.
The first question was
'How do I setup my custom products best?'
A single custom Product with repositories for each version (EL5,6,7) and
architecture (i386, x86_64).
The second question was
'How do I enable repositories that only match the hosts architecture?'
For Red Hat repositories, there is metadata (the 'Tags:' field) viewable
on the client by running 'rct cat-cert' on the certificates in
/etc/pki/entitlement.
This field is what allows you to mix Red Hat content of differing
versions/architecture in the same content view and have the client 'see'
(and enable) only the correct ones.
For custom products you don't have that capability today. What you can
do is setup activation keys for each version/arch combo for EPEL. (And
you'd want to use activation keys anyway, because you probably don't
want to use username/password for registration anyway.
When registering systems, you'd want to use 2 (or even 3) activation keys:
- One to attach a Operating system sub.
- One to attach systems to their content view/environment
- One to attach systems to the custom sub (and enable disable repos)
The first two keys can be combined depending on your environment. But
yes, I think a reasonable RFE would be for Custom Products to only
enable repos (by default) which match the host's architecture.
- Rich
···
On 02/27/2017 04:20 AM, 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 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 foreman-users+unsubscribe@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. > > >–
Rich Jerrido, RHC{E,{D,S}S,{V,S,}A}
Technical Marketing Manager, Red Hat Satellite
+1.484.366.1239 • rwj@redhat.com • @SideAngleSide
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" To: "Foreman Users" Sent: Monday, February 27, 2017 10:41:46 AM Subject: Re: [foreman-users] Recommendations for products with discovered repositories and subscriptions for content hostsGood 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:foreman-users@googlegroups.com | foreman-users@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” < [ mailto:thajek@gmail.com | thajek@gmail.com ] >
To: “Foreman Users” < [ mailto:foreman-users@googlegroups.com | foreman-users@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 | 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:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
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:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
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:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
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 ] .
Thanks everyone for all the great recommendations. This really helps. I
also found the following document useful (
) particularly the information regarding naming conventions. I'll also
open a case with Red Hat Support regarding the RFE that Rich mentioned
(assuming he didn't already put one in).
I think this gets me moving in the right direction again.
Thanks!
···
On Mon, Feb 27, 2017 at 3:11 PM, Rich Jerrido wrote:The first question was
‘How do I setup my custom products best?’
A single custom Product with repositories for each version (EL5,6,7) and
architecture (i386, x86_64).The second question was
‘How do I enable repositories that only match the hosts architecture?’
For Red Hat repositories, there is metadata (the ‘Tags:’ field) viewable
on the client by running ‘rct cat-cert’ on the certificates in
/etc/pki/entitlement.This field is what allows you to mix Red Hat content of differing
versions/architecture in the same content view and have the client ‘see’
(and enable) only the correct ones.For custom products you don’t have that capability today. What you can do
is setup activation keys for each version/arch combo for EPEL. (And you’d
want to use activation keys anyway, because you probably don’t want to use
username/password for registration anyway.When registering systems, you’d want to use 2 (or even 3) activation keys:
- One to attach a Operating system sub.
- One to attach systems to their content view/environment
- One to attach systems to the custom sub (and enable disable repos)
The first two keys can be combined depending on your environment. But yes,
I think a reasonable RFE would be for Custom Products to only enable repos
(by default) which match the host’s architecture.
- Rich
On 02/27/2017 04:20 AM, 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 thajek@gmail.com 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 foreman-users+unsubscribe@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.–
Rich Jerrido, RHC{E,{D,S}S,{V,S,}A}
Technical Marketing Manager, Red Hat Satellite
+1.484.366.1239 • rwj@redhat.com • @SideAngleSide–
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/to
pic/foreman-users/tYSmZHjDKL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@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.
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. >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 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 hostsGood 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 hostsGreetings,
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/to
pic/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-users+unsubscribe@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.
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.