[Spacewalk-list] Unable to kickstart via spacewalk proxy

Mon Dec 8 08:38:50 UTC 2014

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 ____

    __ __

    _______________________________________________
    Spacewalk-list mailing list
    Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com> <mailto:Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>>
    https://www.redhat.com/mailman/listinfo/spacewalk-list

--

Michael Guidero
Sococo IT
650-265-7013 Ext 1000<tel:650-265-7013%20Ext%201000>

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

--

Michael Guidero
Sococo IT
650-265-7013 Ext 1000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20141208/1a7dff81/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5375 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20141208/1a7dff81/attachment.bin>