Custom channell as child of many parent channels ?

Latest response

I would like to create custom Satellite channel with our internal packages (rpms).
Is it possible to have the same channel available (as child) to multiple parent channels (which are cloned from official RH channels) ?


Q: Is it possible to have the same channel available (as child) to multiple parent channels
A: I believe the answer is: No.

If your "internal repo" is a child in one of the Base Channels, you could clone it at the same time?
|- team-repo
|- rhn-tools-rhel-x86_64-server-6

|- clone1-team-repo
|- clone1-rhn-tools-rhel-x86_64-server-6

However - depending on how you use the channel... you could make a repo external to the Satellite. (using createrepo and maintain your *.repo file, GPG key, etc...) I do this for repos which do not have to be sync'd at a particular date - like the Dell hardware and OMSA packages, they can always be current and don't have to match the point-in-time when I Clone a base-channel - therefore, I maintain the Dell repo indendently of Satellite.

Let me know if I did not answer the question.

Hi James,

in general I am looking for a way to provide our internal packages to all our servers using Satellite only.
The number of channels on our Satellite is growing but I would like to keep one repository (at least for now) for all these channels (as a child for all of them if possible).

I would like to avoid using /etc/yum.repos.d/.

I would like to avoid using /etc/yum.repos.d/.

I completely understand. There is definitely an advantage to having everything managed within Satellite.

Did my clone example seem as though it would help? I have a few "3rd-party" channels owned by Red Hat Base Channel and I use spacecmd to clone my channels.
Using a few scripts,
* create my repo from a directory on my Satellite (which is also web-accessible by browsing)
* push the repo up to my Satellite to be "owned" by a Base Channel (based on Arch and Release)
* polll my existing Base/Child channels and to create my spacecmd clone configuration
* use spacecmd to clone my Base/Child channels to a specific date

In my environment, it's a bit of an involved process as I create new Activation Keys, create a new Clone, update my bootstrap script to list all the available Clones - but it works for us ;-)

Hi James,

thanks for your suggestion. I am doing it right now (not scripted yet ...) and faced a problem when doing a clone from a child channel (which is our custom channel) to another child channel. Using your example:

|- team-repo (being cloned)
|- rhn-tools-rhel-x86_64-server-6

|- clone1-team-repo (already cloned)
|- clone1-rhn-tools-rhel-x86_64-server-6

|- clone1-team-repo (failed !!!)
|- clone1-rhn-tools-rhel-x86_64-server-6

The clone is failing and I get a message:
"That channel label already exists in our database. Please choose another.".

What is your approach to this problem (am I following your steps ?) ?


you're really not going to like my answer (and even less so if my thoughts are absolutely true, not just my opinion ;-).
I ran in to the same "issue" with most of my 3rd-party channels. They are almost the same channel, but for a different parent.
rhel 5 i386
rhel 5 x86_64
rhel 6 x86_64

What I did...
* for channels that do not have to be separate (i.e. the same channel works for multiple releasees and base-architectures) I did a simple (reposync,createrepo) for that repo and I use the yum files (and I recall that you did not want to use that approach).
* for the channels that are arch/release dependent, I had to name them accordingly. Fortunately we don't actually have i386 clients - so I did not have to worry about basearch as much.

So - in your case

python -c 'import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)'
Loaded plugins: product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
{'arch': 'ia32e',
 'basearch': 'x86_64',
 'releasever': '6Server',
 'uuid': '873123a4-ebb2-4938-9ada-ff4e08155233'}

Let me know if this does (or does not) seem valid. This is one of those topcis that I have been dealing with so long, it feels like it's the right way (even though it may not be).