On 08.12.2014 08:14, Linder, Rolf wrote: > Dear all > > > > Thanks for your suggestions. > > We too use spacewalk 2.2 on server and proxy. Right now we’re testing a > behavior regarding our channel structure… > > > > We use a “special” channel structure as describe here: > https://www.redhat.com/archives/spacewalk-list/2011-August/msg00082.html > > That’s why, our base channel does not have any packages assigned. > > > > Since kickstarting without proxy is working great we never thought that > this maybe an issue for a proxy setup. Anyone else using a proxy with > this kind of channel structure? Could that be the cause for our issue? > > > > I’ll report back what our test results are with the same server but > “regular” channel structure (base channel includes packages). > > > > Cheers, > > Rolf > > > > *Von:*Michael Guidero [mailto:[email protected]] > *Gesendet:* Samstag, 6. Dezember 2014 00:58 > *An:* spacewalk-list > *Betreff:* Re: [Spacewalk-list] Unable to kickstart via spacewalk proxy > > > > Unfortunately I got the same results, thanks for the suggestion, > though... I didn't know about those files before. > > > > On Fri, Dec 5, 2014 at 3:10 PM, Stephen Herr <[email protected] > <mailto:[email protected]>> wrote: > > Oh, never mind. I see in the first email that it is Spacewalk 2.2. > Hmm. There may be a bug here. > > If you 'rm -f /var/spool/rhn-proxy/list/*; rhn-proxy restart' on the > proxy and try again does the problem go away? > > > > On 12/05/2014 05:47 PM, Stephen Herr wrote: > > Is your Proxy 2.2 instance connected to a Spacewalk 2.2 server? > It is > not supported to have a Spacewalk version < Proxy version. > > -Stephen > > On 12/05/2014 12:09 PM, Michael Guidero wrote: > > We have a similar issue, for Scientific Linux 7. The package in > question is vim-common-7.4.160-1.el7.x86_64.rpmroo > > Log message: > 2014/12/04 18:18:20 -07:00 8897 10.30.20.192 > <http://10.30.20.192>: > broker/rhnRepository.getPackagePath('ERROR', 'Package not in > mapping: > vim-common-7.4.160-1.el7.x86_64.rpm') > > The source distro has a vim-common package named: > vim-common-7.4.160-1.el7:2.x86_64 > > We also get a warning for a "not well-formed" comps.xml, a > closer > inspection of the comps.xml file downloaded to the > kickstarting system > indicates that it is lzma-compressed and would be valid if > it was not > compressed. > > > On Fri, Dec 5, 2014 at 5:04 AM, Linder, Rolf > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > Dear spacewalker’s____ > > __ __ > > We’ve been using spacewalk for the couple of years, now > using > Spacewalk 2.2. Since our servers are growing we have to > enhance our > environment to use spacewalk proxy servers.____ > > __ __ > > While testing the proxy server, we setup a test > spacewalk system > kickstarted a child which we then configured according > > https://fedorahosted.org/spacewalk/wiki/HowToInstallProxy as > a proxy > (so far we have two systems, spacewalk server and spacewalk > proxy).____ > > __ __ > > After this we kickstart a “real” child which works fine > when using > the spacewalk server (including re-provisioning via > WebUI). If we > want to re-provision the system using the proxy we end > up with the > following failure:____ > > __ __ > > (out of /var/log/rhn/rhn_proxy_broker.log from proxy)____ > > broker/rhnRepository.getPackagePath('ERROR', 'Package not in > mapping: iputils-20071127-17.el6_4.2.x86_64.rpm') ____ > > __ __ > > the client stops with the message that the RPM could not be > opened. ____ > > http-access log show the GET request, but squid-logs > does not show > any entry regarding this.____ > > __ __ > > Any help would be highly appreciated!____ > > __ __ > > Kind regards,____ > > Rolf ____ >
Hi all, I tried to debug this some more and I can confirm the findings of Rolf. I too use a master channel like centos-6x or centos-7x as parents with no packages assigned. Kickstarting using this channels fails with the mentioned "package not in mapping error". See log at http://ur1.ca/j1pu7 In this scenario the channels are setup the following: centos6.x-base --> centos6.6-x86_64 --> centos6.6-updates-x86_64 Kickstart tries to download the following rpm: broker/rhnBroker._initConnectionVariables('set self.rhnParent: http://proxy.example.com/ks/dist/centos6.6-x86_64/Packages/python-ethtool-0.6-5.el6.x86_64.rpm',) and tries to fetch locally first (before going up in the chain): broker/rhnBroker.__local_GET_handler('Retrieve from local repository.',) and then it tries to cache the rpm using the parent channel: broker/rhnRepository.getPackagePath('python-ethtool-0.6-5.el6.x86_64.rpm',) broker/rhnRepository._cacheObj('package_mapping:centos6x-base:', '20130308120245', ()) broker/rhnRepository._getPkgListDir('/var/spool/rhn-proxy/list',) broker/rhnRepository.getPackagePath('ERROR', 'Package not in mapping: python-ethtool-0.6-5.el6.x86_64.rpm') Imho there is no fallback to the lower channel (which contains rpms). The same is happening for centos7 kickstarts due to the same channel layout. For testing I cloned my centos-6.6-x86_64 channel and made it a standalone top-level channel and kickstarting is working again. Regards Patrick -- Lobster SCM GmbH, Hindenburgstraße 15, D-82343 Pöcking HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
