[katello] content source and client repository configuration

Hi,

I can't seem to find much documentation around this, but how is the content
source option used for installations or applying updates to the system if
there's no correlation to the products we create in katello and the yum
repositories which get configured on the host through a kickstart/finish
install. Is the process for us to sync these repositories to provide the
ability to push updates to the host only, instead of having the hosts pull
updates from the katello HTTP repositories instead?

This could be due to my lack of knowledge on what subscription-manager or
katello-agent… but any help would be much appreciated.

> Hi,
>
> I can't seem to find much documentation around this, but how is the content
> source option used for installations or applying updates to the system if

Content Source only has to do with which server a machine gets installed
from - either the Katello itself or remote capsules.

> there's no correlation to the products we create in katello and the yum
> repositories which get configured on the host through a kickstart/finish
> install. Is the process for us to sync these repositories to provide the
> ability to push updates to the host only, instead of having the hosts pull
> updates from the katello HTTP repositories instead?
>
> This could be due to my lack of knowledge on what subscription-manager or
> katello-agent… but any help would be much appreciated.

It's subscription-manager that handles configuring repos on the client.
You'd need to create an activation key in Katello, and assign that to a
Host group. When you a provision a host in that host group, it'll
register with the activation key and the relevant repos get
automatically enabled.

You can also register hosts manually:
http://www.katello.org/docs/2.1/user_guide/content_hosts/index.html#how-is-a-content-host-registered

··· On Tue, Mar 31, 2015 at 12:58:24AM -0700, Andrew Lau wrote:


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 http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Best Regards,

Stephen Benjamin
Red Hat Engineering

>
> > Hi,
> >
> > I can't seem to find much documentation around this, but how is the
> content
> > source option used for installations or applying updates to the system
> if
>
> Content Source only has to do with which server a machine gets installed
> from - either the Katello itself or remote capsules.
>
> > there's no correlation to the products we create in katello and the yum
> > repositories which get configured on the host through a kickstart/finish
> > install. Is the process for us to sync these repositories to provide the
> > ability to push updates to the host only, instead of having the hosts
> pull
> > updates from the katello HTTP repositories instead?
> >
> > This could be due to my lack of knowledge on what subscription-manager
> or
> > katello-agent… but any help would be much appreciated.
>
> It's subscription-manager that handles configuring repos on the client.
> You'd need to create an activation key in Katello, and assign that to a
> Host group. When you a provision a host in that host group, it'll
> register with the activation key and the relevant repos get
> automatically enabled.
>
> You can also register hosts manually:
>
> http://www.katello.org/docs/2.1/user_guide/content_hosts/index.html#how-is-a-content-host-registered
>

Do we need to follow some sort of naming convention, ie. how is
subscription-manager able to know that a CentOS updates repo is added, but
already exists on the host by default. Or is it more tailored towards
adding non-standard product repositories?

··· On Tuesday, 31 March 2015 19:06:27 UTC+11, Stephen Benjamin wrote: > On Tue, Mar 31, 2015 at 12:58:24AM -0700, Andrew Lau wrote:


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 <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Best Regards,

Stephen Benjamin
Red Hat Engineering

>
>
> >
> > > Hi,
> > >
> > > I can't seem to find much documentation around this, but how is the
> > content
> > > source option used for installations or applying updates to the system
> > if
> >
> > Content Source only has to do with which server a machine gets installed
> > from - either the Katello itself or remote capsules.
> >
> > > there's no correlation to the products we create in katello and the yum
> > > repositories which get configured on the host through a kickstart/finish
> > > install. Is the process for us to sync these repositories to provide the
> > > ability to push updates to the host only, instead of having the hosts
> > pull
> > > updates from the katello HTTP repositories instead?
> > >
> > > This could be due to my lack of knowledge on what subscription-manager
> > or
> > > katello-agent… but any help would be much appreciated.
> >
> > It's subscription-manager that handles configuring repos on the client.
> > You'd need to create an activation key in Katello, and assign that to a
> > Host group. When you a provision a host in that host group, it'll
> > register with the activation key and the relevant repos get
> > automatically enabled.
> >
> > You can also register hosts manually:
> >
> > http://www.katello.org/docs/2.1/user_guide/content_hosts/index.html#how-is-a-content-host-registered
> >
>
> Do we need to follow some sort of naming convention, ie. how is
> subscription-manager able to know that a CentOS updates repo is added, but
> already exists on the host by default. Or is it more tailored towards
> adding non-standard product repositories?

The activation key says which repos to enable, you select them in the
UI. subscription-mnaager creates a "redhat.repo" in the yum.repos.d.

You'd need to disable the CentOS yum repos, there's an RFE somewhere for
us to disable other repos than Katello's.

··· On Tue, Mar 31, 2015 at 01:09:58AM -0700, Andrew Lau wrote: > On Tuesday, 31 March 2015 19:06:27 UTC+11, Stephen Benjamin wrote: > > On Tue, Mar 31, 2015 at 12:58:24AM -0700, Andrew Lau wrote:


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 <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Best Regards,

Stephen Benjamin
Red Hat Engineering


Best Regards,

Stephen Benjamin
Red Hat Engineering

> >
> >
> > >
> > > > Hi,
> > > >
> > > > I can't seem to find much documentation around this, but how is the
> > > content
> > > > source option used for installations or applying updates to the
> system
> > > if
> > >
> > > Content Source only has to do with which server a machine gets
> installed
> > > from - either the Katello itself or remote capsules.
> > >
> > > > there's no correlation to the products we create in katello and the
> yum
> > > > repositories which get configured on the host through a
> kickstart/finish
> > > > install. Is the process for us to sync these repositories to provide
> the
> > > > ability to push updates to the host only, instead of having the hosts
> > > pull
> > > > updates from the katello HTTP repositories instead?
> > > >
> > > > This could be due to my lack of knowledge on what
> subscription-manager
> > > or
> > > > katello-agent… but any help would be much appreciated.
> > >
> > > It's subscription-manager that handles configuring repos on the client.
> > > You'd need to create an activation key in Katello, and assign that to a
> > > Host group. When you a provision a host in that host group, it'll
> > > register with the activation key and the relevant repos get
> > > automatically enabled.
> > >
> > > You can also register hosts manually:
> > >
> > >
> http://www.katello.org/docs/2.1/user_guide/content_hosts/index.html#how-is-a-content-host-registered
> > >
> >
> > Do we need to follow some sort of naming convention, ie. how is
> > subscription-manager able to know that a CentOS updates repo is added,
> but
> > already exists on the host by default. Or is it more tailored towards
> > adding non-standard product repositories?
>
> The activation key says which repos to enable, you select them in the
> UI. subscription-mnaager creates a "redhat.repo" in the yum.repos.d.
>
> You'd need to disable the CentOS yum repos, there's an RFE somewhere for
> us to disable other repos than Katello's.
>
>
​Thanks, that cleared a lot of confusion. ​Got things working now…

​Ran into one more issue, perhaps you may know…
Is 'require-encryption=yes' meant to be set in qpidd.conf with katello 2.2?
When set to yes, I see a heap of error messages about failing to connect
(gofred and katello-services). Setting to =no clears the issue…

··· On 31 March 2015 at 20:12, Stephen Benjamin wrote: > On Tue, Mar 31, 2015 at 01:09:58AM -0700, Andrew Lau wrote: > > On Tuesday, 31 March 2015 19:06:27 UTC+11, Stephen Benjamin wrote: > > > On Tue, Mar 31, 2015 at 12:58:24AM -0700, Andrew Lau wrote:


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 <javascript:>.

To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Best Regards,

Stephen Benjamin
Red Hat Engineering


Best Regards,

Stephen Benjamin
Red Hat Engineering