[Spacewalk-list] Unable to kickstart via spacewalk proxy
Patrick Hurrelmann
patrick.hurrelmann at lobster.de
Mon Dec 8 08:51:37 UTC 2014
On 08.12.2014 09:38, Linder, Rolf wrote:
> Hi again
>
>
>
> So, when using a channel structure like this:
>
>
>
> CentOS 6
>
> ------CentOS 6 updates
>
> ------CentOS 6 approved updates
>
> ------CentOS 6 internal packages
>
>
>
> With base channel having packages in it, it is working.
>
>
>
> But the channel structure (which is working smooth on the
> spacewalk-server without proxy),
>
>
>
> CentOS 6 (contains no packages)
>
> ------CentOS 6.0
>
> ------CentOS 6.0 updates
>
> ------CentOS 6.0 approved updates
>
> ------CentOS 6 internal packages
>
>
>
> we keep seeing these errors:
>
>
>
> ==> /var/log/httpd/ssl_access_log <==
>
> 10.0.2.11 - - [05/Dec/2014:15:27:35 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/repodata/filelists.xml.gz
> HTTP/1.1" 200 6264
>
> 10.0.2.11 - - [05/Dec/2014:15:27:35 +0100] "GET
> /ks/dist/child/centos6-usp-x86_64/centos6-6-x86_64/repodata/filelists.xml.gz
> HTTP/1.1" 200 236
>
> 10.0.2.11 - - [05/Dec/2014:15:27:35 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 200 69804
>
> 10.0.2.11 - - [05/Dec/2014:15:27:36 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/osad-5.11.43-1.el6.noarch.rpm
> HTTP/1.1" 200 76856
>
> 10.0.2.11 - - [05/Dec/2014:15:27:37 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhn-setup-2.2.7-1.el6.noarch.rpm
> HTTP/1.1" 200 89220
>
> 10.0.2.11 - - [05/Dec/2014:15:27:37 +0100] "GET
> /ks/dist/child/centos6-usp-x86_64/centos6-6-x86_64/getPackage/osad-selinux-permissive-0.1-1.el6.noarch.rpm
> HTTP/1.1" 200 2452
>
> 10.0.2.11 - - [05/Dec/2014:15:27:37 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-actions-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 200 42388
>
> 10.0.2.11 - - [05/Dec/2014:15:27:37 +0100] "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-client-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 200 39560
>
> 10.0.2.11 - - [05/Dec/2014:15:27:37 +0100] "HEAD
> /ty/bTdDsFLh/Packages/iputils-20071127-17.el6_4.2.x86_64.rpm HTTP/1.1" 200 -
>
>
>
> ==> /var/log/httpd/ssl_request_log <==
>
> [05/Dec/2014:15:27:35 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/repodata/filelists.xml.gz
> HTTP/1.1" 6264
>
> [05/Dec/2014:15:27:35 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-usp-x86_64/centos6-6-x86_64/repodata/filelists.xml.gz
> HTTP/1.1" 236
>
> [05/Dec/2014:15:27:35 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 69804
>
> [05/Dec/2014:15:27:36 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/osad-5.11.43-1.el6.noarch.rpm
> HTTP/1.1" 76856
>
> [05/Dec/2014:15:27:37 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhn-setup-2.2.7-1.el6.noarch.rpm
> HTTP/1.1" 89220
>
> [05/Dec/2014:15:27:37 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-usp-x86_64/centos6-6-x86_64/getPackage/osad-selinux-permissive-0.1-1.el6.noarch.rpm
> HTTP/1.1" 2452
>
> [05/Dec/2014:15:27:37 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-actions-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 42388
>
> [05/Dec/2014:15:27:37 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "GET
> /ks/dist/child/centos6-spacewalk22-client-x86_64/centos6-6-x86_64/getPackage/rhncfg-client-5.10.73-1.el6.noarch.rpm
> HTTP/1.1" 39560
>
> [05/Dec/2014:15:27:37 +0100] 10.0.2.11 TLSv1.2
> ECDHE-RSA-AES256-GCM-SHA384 "HEAD
> /ty/bTdDsFLh/Packages/iputils-20071127-17.el6_4.2.x86_64.rpm HTTP/1.1" -
>
>
>
> ==> /var/log/rhn/rhn_server_xmlrpc.log <==
>
> 2014/12/05 15:27:38 +02:00 1793 127.0.0.1:
> server/rhnChannel._list_packages('ERROR', 'No packages found in
> channel', '108', 'centos6-x86_64')
>
>
>
> ==> /var/log/httpd/error_log <==
>
> [Fri Dec 05 15:27:38 2014] [error] Spacewalk 1793 2014/12/05 15:27:38
> +02:00: ('No packages found in channel', '108', 'centos6-x86_64')
>
>
>
> Note that there are packages which can be downloaded via proxy without
> issues (osad, rhncfg,…) but package iptutils cannot.
>
>
>
> This quite seems as a missing feature / bug within the proxy component,
> since without proxy you can use both channel structures…
>
>
>
> Cheers,
>
> Rolf
>
>
>
> *Von:*Linder, Rolf
> *Gesendet:* Montag, 8. Dezember 2014 08:14
> *An:* spacewalk-list at redhat.com
> *Betreff:* Re: [Spacewalk-list] Unable to kickstart via spacewalk proxy
>
>
>
> 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 ____
Right, kickstarting with bypassing the proxy works fine. Other
operations via proxy work, too. It's just the downloading of rpms during
kickstart via a parent channel without rpms which is broken in proxy 2.2.
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