Seeking Clarification on Content Views

Hi,

In ‘Content Views,’ when one of the contents is selected, under Repositories, it shows a URL labeled ‘Published At:’. Clicking this URL displays a ‘config.repo’ file, which I assume gets posted in the /etc/yum.repos.d/redhat.repo on the relevant client.

My questions are:

How is the URL in 'Published At:' created?
How is the 'config.repo' file generated?

Both the URL and the ‘config.repo’ file include the web address of the /pulp/content/…

Thank you!

Hi @SarathHewage

Please have a look at Content views in Foreman which describes how the URLs to versioned content are structured. Does this help?

Published At is always “latest greatest synchronized content” for a specific repository.

Thanka for the reply.
I will go through this and let you know.

Hi @maximilian

The link you send me explain what is the Published At URL is. Thanks for that.

I would like to know where the information goes once the link is clicked. In our Production Foreman environment, which is fully functional and has all the subscriptions enabled, it shows details like links, Packages/, config.repo, and repodata/.

When a client is added to the Prod Foreman, it creates the /etc/yum.repos.d/redhat.repo file, which contains all the entries from those config.repo pages.

I am configuring a DEV Foreman environment that doesn’t have subscriptions, and its repositories don’t sync as they do in the Prod Foreman environment. However, I would like to have the same structure of links as in the PROD Foreman environment. Currently, in the DEV environment, it only has repodata/ in the Published At URLs. So, when a client is added to DEV, the /etc/yum.repos.d/redhat.repo file doesn’t get populated.

Is there any way to fix it?

Also, anyone else has an idea about this ?

Has anyone any idea about the question I asked?

From Managing content

A particular package or repository is available to a host only if all of the following are true:

  • The repository is included in the host’s content view and lifecycle environment.
  • The host’s content view has been published after the repository was added to it.
  • The repository has not been filtered out by a content view filter.
  • The repository is enabled by default or overridden to Enabled using a content override.
  • The repository has no architecture or OS version restrictions or it has architecture or OS version restrictions that match the host.
  • For certain Red Hat repositories either no release version is set or the release version matches that of the host.

subscription-manager adds repositories to your redhat.repo based on what’s in the host’s content view environments. So check all of the above. In particular, custom repositories are disabled by default and need to be overridden to Enabled (but I think they should show up in redhat.repo regardless, just with an Enabled: 0 instead of Enabled: 1)

Thanks, I will check this and let you know.