As Phil said, the easiest mix would probably be to create all of the repos in Pulp and just define them as external repos in Cobbler.
But I think for a true split of responsibilities Cobbler would need to support the distribution's repository being external. If you manually adjust the Kickstart Metadata in the Cobbler's profiles you could probably accomplish this, but cobbler would still need a source for the kernel and initrd in the PXE environment to be defined in the profile..
I cross posted this to the cobbler list.
-greg
On Wed, Oct 26, 2011 at 10:59, Dan White ygor@comcast.net wrote:
So how then do I mix the two ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes)
----- Phil Gardner phil.gardnerjr@gmail.com wrote:
I am actually just now setting up a similar environment. From what I can tell, Pulp is better at managing repos with keeping track of package versions, and can push updates out to the consumers without actually interacting with the server (consumer).
I have been testing with adding a second non-ssl vhost to Pulp's apache and using that url as the install/updates repos when kickstarting (inside cobbler kickstart templates). Or you could just import the base install trees into cobbler and just use that for installs. Each would
work.
Any other important differences between the two? Some of their functionality does overlap, but pulp is better at dealing with lots of repos, and cobbler is great for managing kickstart stuff.
On 10/26/2011 11:40 AM, Dan White wrote:
I have a Cobbler/Puppet/Kickstart environment I am running with, but I
am running into problems maintaining a local set of repo mirrors.
Is it possible to roll Pulp into this mix ?
“Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
-- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
On Oct 26, 2011, at 1:29 PM, Greg Swift wrote:
As Phil said, the easiest mix would probably be to create all of the repos in Pulp and just define them as external repos in Cobbler.
But I think for a true split of responsibilities Cobbler would need to support the distribution's repository being external. If you manually adjust the Kickstart Metadata in the Cobbler's profiles you could probably accomplish this, but cobbler would still need a source for the kernel and initrd in the PXE environment to be defined in the profile..
I cross posted this to the cobbler list.
-greg
On Wed, Oct 26, 2011 at 10:59, Dan White ygor@comcast.net wrote: So how then do I mix the two ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes)
----- Phil Gardner phil.gardnerjr@gmail.com wrote:
I am actually just now setting up a similar environment. From what I can tell, Pulp is better at managing repos with keeping track of package versions, and can push updates out to the consumers without actually interacting with the server (consumer).
I have been testing with adding a second non-ssl vhost to Pulp's apache and using that url as the install/updates repos when kickstarting (inside cobbler kickstart templates). Or you could just import the base install trees into cobbler and just use that for installs. Each would work.
Any other important differences between the two? Some of their functionality does overlap, but pulp is better at dealing with lots of repos, and cobbler is great for managing kickstart stuff.
On 10/26/2011 11:40 AM, Dan White wrote:
I have a Cobbler/Puppet/Kickstart environment I am running with, but I am running into problems maintaining a local set of repo mirrors.
Is it possible to roll Pulp into this mix ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes)
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
-- _____________________ Phil Gardner PGP Key ID 0xFECC890C OTR Fingerprint 6707E9B8 BD6062D3 5010FE8B 36D614E3 D2F80538
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote: So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) < http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html%3E and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
heh.. oops.. i did not remember there was a user list... maybe i should join that one too...
channel varies the times i've been in there
On Oct 26, 2011, at 10:31 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote: On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote: So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
heh.. oops.. i did not remember there was a user list... maybe i should join that one too...
channel varies the times i've been in there
Any time better than others to try ? I'm in UTC-5 (East Coast US) time zone
So would I be spamming to repost to cobbler-dev ? Or might it get some response ?
On Wed, Oct 26, 2011 at 21:49, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 10:31 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) < http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html%3E and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
heh.. oops.. i did not remember there was a user list... maybe i should join that one too...
channel varies the times i've been in there
Any time better than others to try ? I'm in UTC-5 (East Coast US) time zone
So would I be spamming to repost to cobbler-dev ? Or might it get some response ?
good question, but i'm not good to answer it since i don't get to get on much.
this is now a discussion on cobbler-devel so now a few more eyes might see it.
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) < http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html%3E and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
So looking at your problem, I'm actually concerned that you were not gettign the error on both version of yum-rhn-plugin. If the repositories are named the same thing, it should always complain. Maybe they just increased the verbosity of the check, which is unfortunate to you, but is technicaly correct. I'd say the better solution is to rename the name of the repository in cobbler rather than disabling the update of the package.
Am I missing something?
----- Greg Swift gregswift@gmail.com wrote:
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if you uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I still register these client-hosts with Red Hat Network ? I recently encountered a problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) < http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html%3E and did not get any helpful information, and no one is active on the IRC every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
So looking at your problem, I'm actually concerned that you were not gettign the error on both version of yum-rhn-plugin. If the repositories are named the same thing, it should always complain. Maybe they just increased the verbosity of the check, which is unfortunate to you, but is technicaly correct. I'd say the better solution is to rename the name of the repository in cobbler rather than disabling the update of the package.
Am I missing something?
I think you are missing something. Or I am.
Let me use the name of the offending repo as a specific example:
Cobbler/Kickstart-Server (call it cobb) builds host foo
After it finishes, on foo, any yum command fails with error message: "Repository rhel-x86_64-server-5 is listed more than once in the configuration" unless I include a command line option of "--disableplugin=rhnplugin"
RedHat Support told me to edit /etc/yum.repos.d/cobbler-config.repo and change the entry for rhel-x86_64-server-5
The file is generated by cobbler and the particular entry in question reads: ------------------------------------- [rhel-x86_64-server-5] name=rhel-x86_64-server-5 baseurl=http://<cobb's IP>/cobbler/repo_mirror/rhel-x86_64-server-5 enabled=1 priority=99 gpgcheck=0 ---------------------------------------------- So I change the first line to read: [mirror-rhel-x86_64-server-5]
and yum commands work again on foo.
Now, back to cobb. This is where I may have shot off my own foot. ----------------------------------------------------------- #cobbler repo report --name=rhel-x86_64-server-5 Name : rhel-x86_64-server-5 Arch : x86_64 Breed : rhn Comment : Local RHEL - Server Core (v. 5 for 64-bit x86_64) Createrepo Flags : <<inherit>> Environment Variables : {} Keep Updated : True Mirror : rhn://rhel-x86_64-server-5 Mirror locally : True Owners : ['admin'] Priority : 99 RPM List : [] Yum Options : -------------------------------------------------------------- I am of the opinion that this repo name and the name on the host, foo, should be the same. So I changed it. and then tried a "cobbler reposync --only=mirror-rhel-x86_64-server-5" and I get (edited down):
... Exception value: 'ERROR: repository mirror-rhel-x86_64-server-5 needs to be renamed rhel-x86_64-server-5 as the name of the cobbler repository must match the name of the RHN channel' ... !!! TASK FAILED !!!
So I resort to backing the yum-rhn-plugin on foo down to yum-rhn-plugin-0.5.4-22.el from yum-rhn-plugin-0.5.4-22.el5_7.2 and adding an exception in /etc/yum.conf
Contrarywise, RH Support further told me I can edit a file (/etc/yum/pluginconf.d/rhnplugin.conf) and set a section as follows: [main] enabled = 0 gpgcheck = 1
This has the same effect of the --disableplugin command line option, but I am concerned about what other effect this may have.
Does that remove some of the fog or make it worse ?
On Thu, Oct 27, 2011 at 16:03, Dan White ygor@comcast.net wrote:
----- Greg Swift gregswift@gmail.com wrote:
On Wed, Oct 26, 2011 at 20:40, Dan White ygor@comcast.net wrote:
On Oct 26, 2011, at 8:36 PM, Greg Swift wrote:
On Wed, Oct 26, 2011 at 19:06, Dan White ygor@comcast.net wrote:
So, if I understand the patterns (I'm new to using producer/consumer patterns), I set up a Pulp Server to manage the mirror-repositories (producer) and point the Cobbler Server at them (as a client/consumer) and let Cobbler feed out the RPM's to the cobbler-ized client-hosts.
You can actually have Cobbler do pass through repositories to pulp if
you
uncheck 'mirror locally' under advanced (I believe that is the right option).
This sounds very do-able !
I have a repo on my Cobbler server of RPM's that are not from another repo, so I have to run "createrepo" manually whenever I update the collection. The client-hosts connecting thru Cobbler pick up the
changes.
OK, one more question: I'm using Red Hat Enterprise Linux 5. Can I
still
register these client-hosts with Red Hat Network ? I recently
encountered a
problem with Cobbler-generated yum mirror-repositories and the yum-rhn-plugin not playing nice together.
I use cobbler+rhn regularly and haven't seen any issues. feel free to bring this up in #cobbler on freenode or on the cobbler list.
I have brought it up on the cobbler list (not dev) <
http://www.mail-archive.com/cobbler@lists.fedorahosted.org/msg06621.html%3E
and did not get any helpful information, and no one is active on the
IRC
every time I have tried -- #cobbler Right ? Is there a #cobbler-dev ?
So looking at your problem, I'm actually concerned that you were not
gettign
the error on both version of yum-rhn-plugin. If the repositories are
named
the same thing, it should always complain. Maybe they just increased the verbosity of the check, which is unfortunate to you, but is technicaly correct. I'd say the better solution is to rename the name of the repository in cobbler rather than disabling the update of the package.
Am I missing something?
I think you are missing something. Or I am.
Let me use the name of the offending repo as a specific example:
Cobbler/Kickstart-Server (call it cobb) builds host foo
After it finishes, on foo, any yum command fails with error message: "Repository rhel-x86_64-server-5 is listed more than once in the configuration" unless I include a command line option of "--disableplugin=rhnplugin"
RedHat Support told me to edit /etc/yum.repos.d/cobbler-config.repo and change the entry for rhel-x86_64-server-5
The file is generated by cobbler and the particular entry in question reads:
[rhel-x86_64-server-5] name=rhel-x86_64-server-5 baseurl=http://<cobb's IP>/cobbler/repo_mirror/rhel-x86_64-server-5 enabled=1 priority=99 gpgcheck=0
So I change the first line to read: [mirror-rhel-x86_64-server-5]
and yum commands work again on foo.
Now, back to cobb. This is where I may have shot off my own foot.
#cobbler repo report --name=rhel-x86_64-server-5 Name : rhel-x86_64-server-5 Arch : x86_64 Breed : rhn Comment : Local RHEL - Server Core (v. 5 for 64-bit x86_64) Createrepo Flags : <<inherit>> Environment Variables : {} Keep Updated : True Mirror : rhn://rhel-x86_64-server-5 Mirror locally : True Owners : ['admin'] Priority : 99 RPM List : [] Yum Options :
I am of the opinion that this repo name and the name on the host, foo, should be the same. So I changed it. and then tried a "cobbler reposync --only=mirror-rhel-x86_64-server-5" and I get (edited down):
... Exception value: 'ERROR: repository mirror-rhel-x86_64-server-5 needs to be renamed rhel-x86_64-server-5 as the name of the cobbler repository must match the name of the RHN channel' ... !!! TASK FAILED !!!
So I resort to backing the yum-rhn-plugin on foo down to yum-rhn-plugin-0.5.4-22.el from yum-rhn-plugin-0.5.4-22.el5_7.2 and adding an exception in /etc/yum.conf
Contrarywise, RH Support further told me I can edit a file (/etc/yum/pluginconf.d/rhnplugin.conf) and set a section as follows: [main] enabled = 0 gpgcheck = 1
This has the same effect of the --disableplugin command line option, but I am concerned about what other effect this may have.
Does that remove some of the fog or make it worse ?
I think i get what is happening. Correct me if I get something wrong:
1: You have your standard RHN setup that your servers will attach to 2: In your cobbler build environment you are mirroring the RHEL base channel from RHN so that it can be used during installation for install time updates 3: Your cobbler setup then configures your cobbler repos to be present post-installation as well
Once I saw this I went and checked to see why I wasn't having this problem because I actually thought I was doing the exact same thing.
Apparently, I started to set this up, I have the repo being mirrored but I've never attached it inside any of my profiles.
So if I interpreted that correctly then, yes, its breaking because it has duplicate repositories configured. If i'm wrong ignore the following:
I guess the trick to making this "right" would be something along the lines of:
if redhat_management_type is enabled then the generated repo configuration should not include any repositories of the type 'rhn' because of the conflict potential.
OR
cobbler could prefix the repositories with cobbler- in the name when it generates the client configuration file. Since cobbler's configured repo have a lower priority, you'd always just get your packages from RHN.
But either way, I don't think that yum-plugin is the problem.
It was getting too long, so I trimmed back to the last response.
Before I start, I want to thank you for taking some of your time to respond to my questions. I was beginning to think Cobbler was an abandoned orphan child !
----- Greg Swift gregswift@gmail.com wrote:
I think i get what is happening. Correct me if I get something wrong:
1: You have your standard RHN setup that your servers will attach to 2: In your cobbler build environment you are mirroring the RHEL base channel from RHN so that it can be used during installation for install time updates 3: Your cobbler setup then configures your cobbler repos to be present post-installation as well
Close enough. The intention was to serve all the local servers from the one "master mirror" on the Cobbler Server and save some external bandwidth and time taken to vacuum all the updates directly from RHN.
Once I saw this I went and checked to see why I wasn't having this problem because I actually thought I was doing the exact same thing.
Apparently, I started to set this up, I have the repo being mirrored but I've never attached it inside any of my profiles.
Try using the mirrored repo in a profile from which you then build a host. You should see the problem happen.
So if I interpreted that correctly then, yes, its breaking because it has duplicate repositories configured.
Than makes sense, but things never complained until the plugin got an update.
If i'm wrong ignore the following:
I am still confused.
I guess the trick to making this "right" would be something along the lines of:
if redhat_management_type is enabled then the generated repo configuration should not include any repositories of the type 'rhn' because of the conflict potential.
Here's a PasteBin containing the server's "cobbler repo report" and the host's "cat /etc/yum.repo.d/*"
I do not see any rhn-type repos on the host. They are all pointing at the mirrors. The references to the RHN channels are coming from somewhere else.
OR
cobbler could prefix the repositories with cobbler- in the name when it generates the client configuration file. Since cobbler's configured repo have a lower priority, you'd always just get your packages from RHN.
If I get my packages from RHN, the local mirror seems a waste. Does changing the name on the client/host and NOT making the same change on the server break things ?
But either way, I don't think that yum-plugin is the problem.
Well, I can change the behavior by changing which version I use, so I would politely disagree with you on that point.
But I am willing to entertain alternatives. Got any ? :)
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes)
On Thu, Oct 27, 2011 at 17:31, Dan White ygor@comcast.net wrote:
It was getting too long, so I trimmed back to the last response.
Before I start, I want to thank you for taking some of your time to respond to my questions. I was beginning to think Cobbler was an abandoned orphan child !
The support side of it hasn't been as active for some reason lately, but there are those of us still using and working on it. the develoeprs just started to implement a new release cycle, and there has been plenty of working going on. I've got a small list of things I want to add at some point when I have time to.
----- Greg Swift gregswift@gmail.com wrote:
I think i get what is happening. Correct me if I get something wrong:
1: You have your standard RHN setup that your servers will attach to 2: In your cobbler build environment you are mirroring the RHEL base
channel
from RHN so that it can be used during installation for install time
updates
3: Your cobbler setup then configures your cobbler repos to be present post-installation as well
Close enough. The intention was to serve all the local servers from the one "master mirror" on the Cobbler Server and save some external bandwidth and time taken to vacuum all the updates directly from RHN.
Which is a reasonable plan.
So if I interpreted that correctly then, yes, its breaking because it has
duplicate repositories configured.
Than makes sense, but things never complained until the plugin got an update.
If i'm wrong ignore the following:
I am still confused.
I think you have a fairly good grasp of whats wrong and why based on this conversation.
I guess the trick to making this "right" would be something along the
lines
of:
if redhat_management_type is enabled then the generated repo
configuration
should not include any repositories of the type 'rhn' because of the conflict potential.
Here's a PasteBin containing the server's "cobbler repo report" and the host's "cat /etc/yum.repo.d/*"
I do not see any rhn-type repos on the host. They are all pointing at the mirrors. The references to the RHN channels are coming from somewhere else.
I used the wrong terminilogy. the 'breed' is rhn.
OR
cobbler could prefix the repositories with cobbler- in the name when it generates the client configuration file. Since cobbler's configured repo have a lower priority, you'd always just get your packages from RHN.
If I get my packages from RHN, the local mirror seems a waste. Does changing the name on the client/host and NOT making the same change on the server break things ?
It would be a waste considering what you are trying to accomplish. Changing the name on the client is perfectly fine and should not break things. My suggestion of prefixing the 'cobbler-' in the name would accomplish that.
But either way, I don't think that yum-plugin is the problem.
Well, I can change the behavior by changing which version I use, so I would politely disagree with you on that point.
Like I said previously, maybe they just implemented more stringent name
validation. I've had duplicate named repositories in straight yum.repo files before and gotten the error you are experiencing, butmaybe the rhn-plugin didn't used to participate in that check. Making the rhn-plugin use the same checks, while breaking your environment != rhn-plugin being the problem.
The changelog of yum-rhn-plugin does not seem to indicate that they changed it:
* Tue Sep 06 2011 Milan Zazrivec mzazrivec@redhat.com 0.5.4-22.el5_7.2 - Resolves: #736058 - re-allow rhn_check to run successfully without any command line arguments - Resolves: #736060 - re-allow pirut to see repositories provided by RHN - Don't attempt to re-register a registered system from package updater
* Tue Aug 23 2011 Michael Mraka michael.mraka@redhat.com 0.5.4-22.el5_7.1 - Related: #732427 - fixed persistdir definition - Resolves: #732427 - reverted and reimplemented init_hook -> prereposetup_hook change
But my guess is that this has just worked for cobbler because yum-rhn-plugin did not enforce a check before version 0.5.4-22.el5_7.2, and now that it does it breaks. If yum-rhn-plugin should not be doing a name comparison, then its broken. But considering yum usually checks the names in .repo files and looks for dupes, I'd assume that its the correct behavior.
But I am willing to entertain alternatives. Got any ? :)
So the quick and dirty fix is to just change the repo name in your local yum.conf. You could probably throw this into your post script of your kickstart like this:
sed -i '/[rhel-x86_64-server-5]/[mirror-rhel-x86_64-server-5]/' /etc/yum.repos.d/cobbler-config.repo
You might want to test a touch more thoroughly anyways. If the cost is not set as less than 1000 (the default) , RHN will still take precendence. I believe cobbler does default to a 99 cost though. I just haven't tested this part enough to prove that I am right.
As for a more long term fix, I'd love to hear from some of the developers...
cobbler-devel@lists.fedorahosted.org