[Spacewalk-list] script to create webserver accessible repo of packages under Spacewalk channels

[Jeremy Davis]

Hello Matthew,

The url I provided is actually showing the base channel and the sub-channel
for v5 64bit. The v5 and 64bit is part of the channel name. So to use a
different example. Say you had a base channel with the name centos6 that
was configured as a 64bit channel and then had a sub-channel as updates
then you could write the url as follows. Note that the centos6 is set in
the URL to tell Spacewalk to look under the centos6 base channel for the
updates channel.

http://<Spacewalk app server or proxy server
FQDN>/dist/child/updates/centos6/

You can use this url to pull packages. All you would need to do is add
getPackage/<full rpm package name including version and arch.rpm>. This
would be the same as if yum was calling for the package as it would know
the version, release, and arch it was needing to install. The repodata yum
uses is generated by Spacewalk so there is no need to create any additional
scripts or anything like that in order to pull packages from Spacewalk or
provide this config to a client for use with yum.

On Tue, Sep 4, 2012 at 3:13 PM, Matthew Patton <mpatton at inforelay.com>wrote:

> On Tue, 04 Sep 2012 13:41:03 -0400, Jeremy Davis <jdavis4102 at gmail.com>
> wrote:
>
>  baseurl=
>> http://proxy_FQDN/ks/dist/**child/spacewalk-client-prod-**
>> v5-64bit/centos-production-**base-v5-64bit<http://proxy_FQDN/ks/dist/child/spacewalk-client-prod-v5-64bit/centos-production-base-v5-64bit>
>>
>
> maybe this can be addressed in 1.8+ or whatever but it's really quite
> asinine to have to use "child" and I think I even saw an example of
> "child/child" somewhere. the URL should be properly written
>
> http://proxy/ks/dist/<dist name>/<sub-channel>/<sub-sub-**channel>/<pkg>
>
> though to be frank, this artificial distinction between "distname" and
> "base channel" is pointless and a source of aggravation if not confusion I
> would wager. If I have channels defined, why do I need a Distribution for
> the getPackage API call to even work?
>
> I should be able to do:
>
> http://<space>/rhn/common/**DownloadFile.do?url=<chan>/<**pkgname>
>
> WITHOUT having to specify the entire version string and arch. If there are
> multiple matches (versions and/or arch) then spit back a simple
> 'index.html' with them listed as hyperlinks. Even in the pathological case
> if I omit <pkgname> I should expect to see the full listing. Now maybe we
> don't want to do that because of the processing overhead (eg. 7000+
> packages in EPEL6) and instead return a 4xx code. I can live with that.
>
>
> --
> Cloud Services Architect, Senior System Administrator
> InfoRelay Online Systems (www.inforelay.com)
>
> ______________________________**_________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/**mailman/listinfo/spacewalk-**list<https://www.redhat.com/mailman/listinfo/spacewalk-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120904/511059a3/attachment.htm>