[Spacewalk-list] eva-direct-errata-sync.pl setup & example usage

Wed Nov 21 19:26:26 UTC 2012

Hi Paul,

I have been bitten by cross-contamination myself when creating errata's as mentioned in 2).

The workaround I have implemented in CEFS is to save the channel membership of each
package before publishing an errata and then deleting newly created memberships. That
restores the previous channel status. It's an ugly hack but so far the only solution I have found.

Regards,
  Steve

Am 21.11.2012 um 07:09 schrieb Paul Robert Marino:

> By the way one thing I forgot and an other thing which is new information.
> 1) you should always use the -r flag if you intend to include child channels right now its broken and always acts like its always on but this will be fixed shortly.
> 2) I've gotten the multi base channel sync feature working on my development host but it introduces the problem where it cross contaminates the channels when two channels have a package with the same name so it is dangerous to use right now. The problem seems to be in the spacewalk APIs not in the script its self. I've tried several different methods to work around it but it looks like the APIs and possibly the database will need work before its viable.
> 
> On Nov 20, 2012 12:59 PM, "Paul Robert Marino" <prmarino1 at gmail.com> wrote:
> On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu <elias.rabi at gmail.com> wrote:
> > Hello list,
> >
> > This is my very first post on this list.
> > I have questions regarding eva-direct-errata-sync.pl.
> > I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to all
> > this and wondering how I should setup the errata sync.
> >
> > I have the following RHEL channels in my spacewalk:
> > rh6-x64-base-channel ( = rhel-x86_64-server-6)
> > rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
> > rh5-x64-base-channel ( = rhel-x86_64-server-5)
> > rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
> >
> > And the following CentOS channels:
> > centos6-x64-base-channel (contains base and updates repos)
> > centos5-x64-base-channel (contains base and updates repos)
> > centos5-x32-base-channel (contains base and updates repos)
> >
> > I want to run errata sync every night for both my RHEL and CentOS channels.
> > So what I've come up with so far is this:
> > ERRATASRCUSER=xxx
> > ERRATADSTUSER=xxx
> > ERRATASRCPASS=xxx
> > ERRATADSTPASS=xxx
> > ERRATADST=localhost
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> > --destinationchannel=rh5-x64-base-channel -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=rh6-x64-base-channel -F day
> >
> > So for the child channel rh6-x64-optional-channel, do I use the -r flag? And
> > what will happen with my channel label name differences
> > (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
> > #   -r or --recursive
> >
> > When do I use these flags?
> > #   -e RH or --rewriteerratanamefrom RH
> > #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
> This rewrites the name of the errata so you don't get conflicting
> errata names essentially you cant have two erratas with the same name
> even if they are on different channels.
> for example RHBA-2012:1441 would be published in spacewalk as
> CENTOSX86_64BA-2012:1441
> 
> > #   --rewritepackagereleasefrom el6
> > #   --rewritepackagereleaseto el6.centos
> these flags deal with alternate package names in Centos here is an
> example in the Redhat errata it might say the package is names
> at-spi-1.28.1-2.el6..x86_64.rpm but the Centos 6 name for the package
> is at-spi-1.28.1-2.el6.centos.x86_64.rpm this happens when Centos has
> added an additional patch that wasn't in the Redhat version of the
> rpm.
> These flags make it match the right package in the channel if it
> matches the el6 or el6.centos
> you should always use this for Centos channels
> 
> >
> >
> > My best guess for the CentOS channels I should use these flags:
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> > --destinationchannel=centos5-x64-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=centos6-x64-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
> > --destinationchannel=centos5-x32-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> >
> this would give you better results
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=centos5-x64-base-channel
> --rewritepackagereleasefrom el5 --rewritepackagereleaseto el5.centos
> -F day  -e RH  -E CENTOS5X64
> 
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=centos6-x64-base-channel
> --rewritepackagereleasefrom el6 --rewritepackagereleaseto el6.centos
> -F day  -e RH  -E CENTOS6X64
> 
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
> --destinationchannel=centos5-x32-base-channel
> --rewritepackagereleasefrom el5 --rewritepackagereleaseto el5.centos
> -F day -e RH  -E CENTOS5X32
> 
> > Are my assumptions/examples correct? If not, can someone correct me?
> you were very close
> 
> one piece of advice I posted a new version of the script yesterday
> that fixed a few long standing bugs so make sure you have the latest
> version
> also I intend to release a new version latter this week to handle
> multiple target base channels which should reduce the need to rewrite
> the errata names.
> >
> > Regards,
> > Elias Abacioglu
> >
> > _______________________________________________
> > Spacewalk-list mailing list
> > Spacewalk-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20121121/6f232e05/attachment.htm>