Bug 1076490 - Unable to kickstart when duplicate package with different checksum exists in child channel
Summary: Unable to kickstart when duplicate package with different checksum exists in ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 2.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Radovan Drazny
URL:
Whiteboard:
Depends On:
Blocks: 1395886 space27
TreeView+ depends on / blocked
 
Reported: 2014-03-14 12:56 UTC by dave
Modified: 2017-09-27 18:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1395886 (view as bug list)
Environment:
Last Closed: 2017-09-27 18:55:07 UTC
Embargoed:


Attachments (Terms of Use)

Description dave 2014-03-14 12:56:20 UTC
Description of problem:  

If two versions of the same package exists with different checksums:

[root@sw ~]# locate redhat-logos-60.0.14-12.el6.centos.noarch.rpm
/var/satellite/redhat/1/28d/redhat-logos/60.0.14-12.el6.centos/noarch/28de9ed3b8d891044155cdd9c4941a65352b3bd683c8cb008ab598a286b8a805/redhat-logos-60.0.14-12.el6.centos.noarch.rpm
/var/satellite/redhat/1/74d/redhat-logos/60.0.14-12.el6.centos/noarch/74dbed48cbd714b3a7debeaebc4a093bbce9976dc76f144b9249e553b7793427/redhat-logos-60.0.14-12.el6.centos.noarch.rpm

, one in the base channel and one in a child channel, a request to 

http://[spacewalkserver]/ks/dist/[distro]/Packages/[packagename]

for example:

http://sw.example.com/ks/dist/centos65-x86_64/Packages/redhat-logos-60.0.14-12.el6.centos.noarch.rpm

may download the package from the child channel ( and not the base channel )

This then causes the kickstart to fail as the checksum does not match what is in the repository metadata.

Version-Release number of selected component (if applicable):


How reproducible:

Sometimes - the ordering of packages from the database returned is random

Steps to Reproduce:
1.  Create a base channel from a centos 6.5 distribution
2.  Add a child channel with updates from ( say 6.3 and 6.4 ) that contain overlapping packages with different checksums
3.  Create a kickstart profile , with only the base channel selected
4.  Attempt to kickstart a machine

Actual results:

Kickstart fails with error:

Try 6/10 for http://sw.example.com/ks/dist/centos65-x86_64/Packages/redhat-logos-60.0.14-12.el6.centos.noarch.rpm
failed: [Errno -1] Package does not match intended download. 
Suggestion: rum yum --enablerepo=anaconda-CentOS--201303050102.x86_64 clean metadata

Expected results:

Kickstart should complete.


Additional info:

I have developed a patch for this issue.  In com/redhat/rhn/domain/channel/Channel.hbm.xml in /usr/share/rhn/lib/rhn.jar

The following HQL should be changed from 

    <sql-query name="Channel.packageByFileName">
      <![CDATA[SELECT {p.*}
          FROM rhnPackage {p}
             left join rhnSolarisPatchSet P_2_ on p.id = P_2_.package_id
             left join rhnSolarisPatch P_1_ on p.id = P_1_.package_id,
             rhnChannelPackage CP,
             rhnChannel C
             WHERE (C.id = :channel_id OR C.parent_channel = :channel_id)
               AND (CP.channel_id = C.id  OR CP.channel_id = C.parent_channel)
               AND CP.package_id = P.id
               AND P.path LIKE :pathlike
        ]]>
    <return alias="p" class="com.redhat.rhn.domain.rhnpackage.Package" />
    </sql-query>

to 

    <sql-query name="Channel.packageByFileName">
      <![CDATA[SELECT {p.*}
          FROM rhnPackage {p}
             left join rhnSolarisPatchSet P_2_ on p.id = P_2_.package_id
             left join rhnSolarisPatch P_1_ on p.id = P_1_.package_id,
             rhnChannelPackage CP,
             rhnChannel C
             WHERE (C.id = :channel_id OR C.parent_channel = :channel_id)
               AND (CP.channel_id = C.id  OR CP.channel_id = C.parent_channel)
               AND CP.package_id = P.id
               AND P.path LIKE :pathlike
               ORDER BY CASE WHEN C.id = :channel_id THEN 1 ELSE 2 END
        ]]>
    <return alias="p" class="com.redhat.rhn.domain.rhnpackage.Package" />
    </sql-query>

- adding an order by statement meaning that the first row returned is the package from the matching channel ( if it exists )

Comment 1 dave 2015-06-10 13:43:22 UTC
Having just upgraded to Spacewalk 2.3 - it appears that this bug still exists.

The new SQL is:

    <sql-query name="Channel.packageByFileName">
      <![CDATA[SELECT {p.*}
          FROM rhnPackage {p},
             rhnChannelPackage CP,
             rhnChannel C
             WHERE (C.id = :channel_id OR C.parent_channel = :channel_id)
               AND (CP.channel_id = C.id  OR CP.channel_id = C.parent_channel)
               AND CP.package_id = P.id
               AND P.path LIKE :pathlike
               ORDER BY CASE WHEN C.id = :channel_id THEN 1 ELSE 2 END
        ]]>

Comment 3 jeff 2015-11-24 20:36:29 UTC
Ver 2.4, still exists. The ORDER BY workaround does not work for me.

In my case right now, it is mailcap-2.1.31-2.el6.noarch.rpm which is in a 6.6 channel and also a 6.6 updates channel.

The only change is the package signature.

< Signature   : RSA/SHA1, Sun 25 Sep 2011 11:12:20 PM CDT, Key ID 0946fca2c105b9de
---
> Signature   : RSA/SHA1, Sun 25 Sep 2011 11:21:48 PM CDT, Key ID 0946fca2c105b9de


This one change stops the KS process. The only way I can see to proceed is to delete the pkg from the uddate repo and filter out this version in the updates repository.

Comment 4 Tomas Lestach 2015-11-27 09:33:36 UTC
Dave,
you're right. I was able to reproduce your issue. Your patch fixes the issues and I like it. Accepting to Spacewalk as ...

spacewalk.git: cd86e50291053f2fc2d6d8dc219f4429a5a0d04e

Sorry, it took so long. If possible, we prefer a pull request. Anyway, thank you!

Comment 5 Tomas Lestach 2015-11-27 09:35:26 UTC
jeff, I believe the provided patch is ok. Are you sure, you've applied it correctly?

Comment 6 dave 2015-11-27 10:28:50 UTC
@Tomas - no problems, thanks for fixing this!

Comment 7 jeff 2015-11-30 18:49:43 UTC
Well, if all there is to do is add the ORDER BY, then I am not not sure why it wouldn't work here.

-jar xf rhn.jar com/redhat/rhn/domain/channel/Channel.hbm.xml
-Edit com/redhat/rhn/domain/channel/Channel.hbm.xml, adding ORDER BY to Channel.packageByFileName query
-jar uf rhn.jar com/redhat/rhn/domain/channel/Channel.hbm.xml
-spacewalk-service stop/start

But if 2 people tested/confirmed, I'll chalk it up to an issue on my side.

Comment 8 jeff 2015-12-01 20:27:28 UTC
Looking again, more than likely the patch doesn't work for me as I use an empty base channel for Centos Major-Arch revisions and each Centos X.Y release has its own child channel under that.

Kickstarting is done by selecting the base + X.Y child channel. Looks like the db query gets data returned from the all channels. The package with the highest package id is returned.

Comment 9 Tomas Lestach 2015-12-02 17:15:09 UTC
jeff, this looks like a different (even if close related) problem.
Would you describe, how you get kickstart trees to child channels? (Preferably in a new BZ.) I'd say, no one really used that before. Our default is to have ks trees in the base channel.

Comment 10 jeff 2015-12-02 19:01:42 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1287829

I'm not sure what you mean about the default. I didn't have to do anything the gui didnt allow. Distro tree is selected in the kickstart profile. So I can choose C6 base channel, 6.6 Child channel and 6.6 distro tree for example and it works.

If I were to create a 6.4 KS profile, and choose C6 Base + 6.4 Child channel and 6.4 distro tree, the 6.6 version will no longer work.

Thanks

Comment 11 Radovan Drazny 2016-11-16 11:10:27 UTC
Reproduced on Spacewalk 2.4:

1. Create two RPMs with a same name and version, and different checksum (use rpmfluff for example and set different description for each package).

2. Have a software channel with one child channel. Both must have kickstart tree (Centos 6.7 and 6.8 can be used). 

3. Using rhnpush push packages from step 1 into channels, one for each channel. Make sure you are pushing into child channel first, so this package gets lower ID. 

4. Check both channels for pushed packages to make sure that each channel has a package with same name and different checksum.

5. Try to download packages using wget.

  #wget http://<spacewalk-fqdn>/ks/dist/centos67/Packages/moje-0.1-1.x86_64.rpm
  #wget http://<spacewalk-fqdn>/ks/dist/centos68/Packages/moje-0.1-1.x86_64.rpm

6. Check checksum for downloaded packages using the "sha256sum -b" command.

7. Both downloaded packages have checksum of package from the child channel. This is gonna cause problems described in the initial report - package from the parent channel (with different checksum) is expected during kickstarting.

Verified on Spacewalk 2.6 - the package from the parent channel is always downloaded.

VERIFIED

Comment 12 Eric Herget 2017-09-27 18:55:07 UTC
Spacewalk 2.7 has been released.

https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes27


Note You need to log in before you can comment on or make changes to this bug.