[Spacewalk-list] Unable to kickstart via spacewalk proxy
Patrick Hurrelmann
patrick.hurrelmann at lobster.de
Mon Dec 8 08:12:20 UTC 2014
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:mg at sococo.com]
> *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 <sherr at redhat.com
> <mailto:sherr at redhat.com>> 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
> <Rolf.Linder at united-security-providers.ch
> <mailto:Rolf.Linder at united-security-providers.ch>
> <mailto:Rolf.Linder at united-security-providers.ch
> <mailto:Rolf.Linder at united-security-providers.ch>>> 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
More information about the Spacewalk-list
mailing list