Composite content view as both normal repositories and some file based repositories

Problem: hammer content-view show --id ${ID} (where ID is set to the id for the composite content view) shows that all of the requested repositories are present - including the file based repositories. However, after connecting a client server to the satellite server and then doing a yum repolist all, only the non-file based repositories are display.

Expected outcome: Should it not include the file based repositories? I checked in the repo file and the file based repositories are not mentioned.

Foreman and Proxy versions: 2.3.3-1

Foreman and Proxy plugin versions: katello 3.18.2-1

Distribution and version: CentOS 7.9

Other relevant data:

I think I answered my own question after doing some research. Based on https://access.redhat.com/articles/3358991, it appears one must download the file based rpms via curl or the equivalent and do a local install. I verified that this worked. Thanks for taking a look. :slight_smile:

2 Likes

Hi @bradawk

Glad you got it figured out, sorry for the delay. You were next up on my list of topics to look at.

Just one thing I am not sure about in your answer: You are using a repository of type file instead of yum for rpms? Any reason for this? Because file is for arbitrary content and using yum even if it is for uploading your own packages instead of syncing some upstream will give you the desired work flow were you simply can do a yum install on the systems.

I thought the file based repositories would be seen on the client systems
via yum. But they are not. Our servers are totally disconnected from the
Internet. We internally mirror a lot of external repositories and I point
to them for CentOS, foreman, kubernetes, katello, etc. However, some do
not have a mirror. For those, I have to download manually. I was hoping a
file based repository would provide them to the clients. It looks like
I’ll have to run createrepo on those files and then point to that instead
of using file based repositories.

Yes, this would give you the better workflow. File based will not create the yum specific metadata.

If you do not want to fiddle with createrepo, simply use a repository of type yum and upload the files to it using hammer/API/GUI, Katello will then create metadata for you so a client can work with it.

I use this quite often to provide some customer specific repositories when setting Katello up for them. It works very well to have one repository for their own packages and another for randomly downloaded packages if they do sign their own packages but not want to resign others and are fine with skipping key validation then.

So, instead of running createrepo, I can just run hammer to create a
repository with --content-type yum and don’t provide a URL. Then run
hammer repository upload-content and then katello will do the rest?

Yes, this was exactly what I wanted to say.

One problem I have found. I had created file based repositories and
uploaded the file contents, but then found that I could only have the
clients of the satellite server get them via curl or wget. So, I deleted
the repositories and then re-created as yum based repositories and tried to
upload the files. It only uploaded some of the files. For the rest, it
gave either a SHA256 or SHA384 checksum error as well as “NoMethodError:
undefined method ‘id’ for nil:NilClass.” After some googling, I found
others that had files uploaded, then for various reasons had to upload
again and got this message. One person had speculated that pulp knew that
the file had been uploaded already and did not seem to want to allow it to
happen again? Other than killing my satellite servers and re-installing
from scratch, how do I get around this?

This sound like a bug where a developer (Katello and/or Pulp) has to have a look into. I have not hit this bug before so I unfortunately can not help.

I was able to get everything uploaded the second attempt except the nvidia rpms. Not sure why katello does not like them? I added a new splunkforwarder rpm to the splunk repository. I published a new version of the splunk content view and saw the additional one package in it. I then published a new version of the content view and promoted that throughout the lifecycle. I can also see one more package in that version as compared with the previous version. However, on a client server, when I run yum --showduplicates list available splunkforwarder, I do not see the newly added version. Is there another step I need to do to get the client host to see it?

I think it is working now after running a yum clean all. I should have figured that! :slight_smile:

1 Like