Thanks everyone for all the great recommendations. This really helps. I also found the following document useful ( https://access.redhat.com/sites/default/files/pages/attachments/2015-10_Steps_to_Build_a_Standard_Operating_Environment.pdf ) 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 <[email protected]> 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 <[email protected]> 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]. >>> 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. >>> >> >> >> >> > -- > Rich Jerrido, RHC{E,{D,S}S,{V,S,}A} > Technical Marketing Manager, Red Hat Satellite > +1.484.366.1239 • [email protected] • @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 > [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. > -- 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.
