[Spacewalk-list] CentOS Errata with synced update channels
Jonathan Scott
I've attempted to hack the centos-errata.py script using multiple .cfg files, full command switches (--x86_64-channel=centos5-updates-x86_64 --x86_64-packagedir=, etc...), but to no avail. I believe it is because the script needs specific folders for each architecture and the "internal" (for lack of a better word) repo-sync dumps everything to /var/satellite/redhat/1/ and let's the database sort it out. I've pretty much given up on it at this point.
Has anyone been successful in adapting a centos errata sync system while using the repository sync function within Spacewalk?
Thank you for your time,
Jonathan
Paul Robert Marino
Ive gotten so frustrated with the issues I've had with that script and
rhn-clone-errata.py that I've started to write a ground up rewrite.
unfortunately its written in Perl (because that's the language i know
well) so I know it wont gain as easy acceptance as a python script
would but I should have something ready by the end of this week at the
rate I'm going.
one of the big changes I've made in my script is I've dumper the
concept of the repo map.
instead I've implemented 1 to 1 channel mapping on execution with the
option of a recursive search to detect the packages in child channels.
This methodology is slightly slower but it fixes issues with multiple
archs in one errata and cross channel package contamination issues
I've seen with other scripts. It also makes the configuration simpler
as a bonus.
The one thing I haven't implemented is the ability for is
functionality you are asking about because I came to the conclusion
that running a spacewalk-repo-sync on the channels first made more
sense given my design.
Since my script requires that the rpm already exist on the target
channel(s) running a spacewalk-repo-sync first is the only viable
option I can think of.
right now it doesn't trigger the spacewalk-repo-sync itself but it
easily could since it automatically detects the channel list on the
target server.
Right now I only handle 1 target base channel, and now that I think
about it it wouldn't be too difficult to add the ability to search
multiple target base channels recursively. essentially the only reason
i didn't do it in the first place is i hadn't thought of it but it
could be useful for erratas that span multiple releases.
I'm also giving multiple errata source type options
1) RHN or Spacewalk/Satellite
my code internally normalizes the difference in the responses from
the two from the XMLRPC API's so it treats them like one source type
to the user,
2) Standard mailing list archive
this should work for CentOS, RHEL's and possibly Fedoras mailing
list and any others formatted the same way note I will even detect if
the gziped digest is really gziped because the ones for RHEL are not
and ive seen it break other scripts.
3) Down the road I will also make one to read Scientific Linux's mail
archive which is a completely different format however i consider this
low priority because at least on the base it should be identical to
RHEL.
> _______________________________________________
> Spacewalk-list mailing list
> Spacewa...@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________
Spacewalk-list mailing list
Spacewa...@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list