Bug 1452189

Summary: rhnpush not pushing packages into the correct channel if a package without a signature is encountered during the push
Product: Red Hat Satellite 5 Reporter: Radovan Drazny <rdrazny>
Component: ClientAssignee: Tomáš Kašpárek <tkasparek>
Status: CLOSED DEFERRED QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 580CC: tlestach
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-09 15:30:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1450940    

Description Radovan Drazny 2017-05-18 13:52:47 UTC
Description of problem:
When pushing signed packages into a channel without the "--nosig" option, and adding an unsigned package to the mix, already uploaded packages will be present on the Satellite server, but not assigned to the expected channel.

Version-Release number of selected component (if applicable):
rhnpush-5.5.89-20.el6sat

How reproducible:
always

Steps to Reproduce:
1. Prepare a custom channel on the Satellite server
2. Prepare a few signed rpms, and add an unsigned rpm (one is enough)
3. Run the rhnpush command without the "--nosig" option:

# rhnpush --server=https://satserver.example.com/APP -u admin -p nimda -vvv -c pushchan -d . --newest
Uploading files from directory .
Connecting to https://satserver.example.com/APP
Connecting to https://satserver.example.com/APP
url is https://satserver.example.com/PACKAGE-PUSH
Result codes: 200 OK
Computing checksum and package info. This may take some time ...
Package /root/rpms/sigmix/389-ds-base-1.2.10.2-15.el6.x86_64.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/389-ds-base-1.2.10.2-15.el6.x86_64.rpm
Using POST request
Package /root/rpms/sigmix/abrt-cli-2.0.8-21.el6.x86_64.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/abrt-cli-2.0.8-21.el6.x86_64.rpm
Using POST request
Package /root/rpms/sigmix/authconfig-6.1.12-10.el6.x86_64.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/authconfig-6.1.12-10.el6.x86_64.rpm
Using POST request
Package /root/rpms/sigmix/bacula-client-5.0.0-12.el6.x86_64.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/bacula-client-5.0.0-12.el6.x86_64.rpm
Using POST request
Package /root/rpms/sigmix/bind-libs-9.7.0-5.P2.el6_0.1.x86_64.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/bind-libs-9.7.0-5.P2.el6_0.1.x86_64.rpm
Using POST request
Package /root/rpms/sigmix/rhn-check-1.0.0.1-38.el6.noarch.rpm Not Found on RHN Server -- Uploading
Uploading package /root/rpms/sigmix/rhn-check-1.0.0.1-38.el6.noarch.rpm
ERROR: /root/rpms/sigmix/rhn-check-1.0.0.1-38.el6.noarch.rpm: unsigned rpm (use --nosig to force)


Actual results:
rhnpush quits on the unsigned rpm (which is expected). Problem is, already uploaded packages are not linked to the channel passed by the "-c" option and end up as packages without a channel. 

Expected results:
Packages already uploaded before rhnpush encounters the unsigned packages and quits should be linked to the correct channel.

Additional info:
This behaviour can be mitigated by using "--tolerant" option, as rhnpush then doesn't quit prematurely, skips unsigned packages, finishes upload of signed packages, and correctly links them to the channel. Still, rhnpush should link all uploaded packages to the correct channel, even if it doesn't upload all of them.

Comment 2 Tomas Lestach 2018-04-09 15:30:00 UTC
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog.

This is a low priority bug and has no currently open customer cases. While this bug may still valid, we do not see it being implemented prior to the EOL of the Satellite 5.x product. As such, this is being CLOSED DEFERRED. 

Closing now to help set customer expectations as early as possible. You are welcome to re-open this bug if needed.