[Spacewalk-list] Unable to kickstart via spacewalk proxy

Mon Dec 8 16:16:24 UTC 2014

did you by any chance include the updates channel during the kickstart?
this is known to cause occasional conflicts. if the updates are in the
base channel thats fine because it will actually use the repomd file
from the installation disk instead of the one in the repo; however if
you have additional repos with updates added to the distro it will
utilize them and this often creates problems for the kickstart process
because anaconda is not as smart as yum about resolving potential
conflicts.
Your best bet is not to include any updates during the installation
then update immediately after the first boot.

Also you are better off using the base channel for the packages from
the installation disk. you can at your option also include the updates
in the base channel but if you do so they will be ignored during the
kickstart which is correct behavior.

On Mon, Dec 8, 2014 at 3:51 AM, Patrick Hurrelmann
<patrick.hurrelmann at lobster.de> wrote:
> 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
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list