Manageyum 2019 how to#
Manageyum 2019 install#
Manageyum 2019 manual#

The view might also use filters to create a stripped down list of packages from the repos. Then I create a Content View called “Standard CentOS 7” and include each of these products in the view. I then associate repos with each of those products. So I create products for Lynis, PHP7, Katello Agent and perhaps Puppet Forge. On my servers I don’t just want the CentOS distro packages, I also want to be able to use things like Lynis, PHP7.2, the Katello Agent and a bunch of Puppet modules to manage it all. In my particular case I’m trying to put together a standard build that I’ll use on all machines in a given Org. I’ll use an example to explain how I think Content Views are supposed to work. I think that’s enough questions for now, if anyone has worked through this in a complex environment please let me know what you did. Is this still possible or am I required to use the Foreman provisioning system if I’m using Katello repos?

Normally when I image a host using PXE/kickstart, I point to a local centos repo URL in the.

Otherwise, I would have many different composite content views for every variation of repos. Maybe I’m supposed to use Composite Content View, but this would become very complex and is much less flexible than adding multiple Content Views to hosts depending on their needs.

Manageyum 2019 how to#

I can’t figure out how to assign many content views for all my repos to a host. Also, it looks like I can only assign a single Content View (epel for example), to a host.I’d need to figure out a way to totally automate this process of subscribing hosts to the correct repos based on their host type and environment during the imaging process.

Manageyum 2019 manual#

There was a lot of manual clicking for assigning a host to an environment and which content view the host should use, etc, which wouldn’t be ideal for setting up thousands of hosts. In an attempt to understand the subscription model, I subscribed a host as a “content host”.

I guess the only way to see which repos a host has is to check foreman?

When I subscribe a host, no files are added to.

Is it still possible to access the yum repos using that same system, or is Host subscription required?.

Is this even possible for us anymore? I manage all those files using puppet to add the correct repos to the correct hosts, and I can have a single file for all hosts using the variables $releasever and $basearch, for example:

Right now we are using repos the traditional way, using files.

Then we have multiple internal repos for our app, I guess each of these should be it’s own content view? I’m not sure what hosts will overlap for different repos (db hosts, vmware hosts, etc all have different repos on them).

If that’s not correct, then I’m assuming I’ll basically have a 1:1 mapping of content views to products.

I’ve seen some people make a content view called “ Centos”, did they put both Centos 6 and 7 repos inside one content view?.

However, what would be an example of a name for a content view? Same as product, should it be “ Centos”, or “ Centos 7”, or “ Centos 7 x86_64”.

The idea of creating a “locked version” of a product and promoting it is clear.

If the repo is “ Centos 7 x86_64”, then it’s clear to add the os/updates/extras to it, but if it’s the more generic such as “ Centos 7” or “ Centos”, should I add multiple arch and versions (6,7) into a product?.

If at some point I’m requested to mirror the 32bit repos for one of those, is that a different product, “ Centos 6 i386”?

Should a product be something like “ Centos”, or “ Centos 7”, or “ Centos 7 x86_64”? It seems like “ Centos 6” and “ Centos 7” are different products.

These are managed by normal “createrepo” and right now. I have many repos to mirror, both public and internal, each with different CentOS version (6,7).

I’ve done a bit of testing and a lot of reading, but I want to understand more about how others have set it up.

Manageyum 2019 install#

I have a new install of Katello with newest version (3.10).