| Summary: | Client error during registration/rhn_check if activation key contains uninstallable RPM (xml.parsers.expat.ExpatError, not well-formed) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Tim Jackson <tjackson> | ||||||||
| Component: | Client | Assignee: | Michael Mráka <mmraka> | ||||||||
| Status: | CLOSED DEFERRED | QA Contact: | Red Hat Satellite QA List <satqe-list> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 540 | CC: | jpazdziora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-07-04 13:28:55 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 462714 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 492045 [details]
List of installed RHN/Satellite/Spacewalk RPMs on client/server
Created attachment 492047 [details]
Output of rhn_check -v -v -v -v -v
Also tested with a few packages installed on the client from RHEL 6.1 beta, without any benefit: rhn-client-tools-1.0.0-53.el6 rhn-check-1.0.0-53.el6 rhn-setup-1.0.0-53.el6 This also happens with broken RPM dependencies. Alternative Steps to Reproduce: 1. Create a clean client machine which has NOT been previously registered to the Satellite server. (this is important) 2. Create or find an RPM (let's call it xyz.rpm) which has an unresolvable dependency within the context of the deployment environment (I used an RPM with a dependency on a file that does not exist) 3. Import xyz.rpm to the Satellite server (rhnpush) and place it in a channel which the client will be subscribed to upon registration 4. Create on the Satellite server an activation key (say, "TEST") which include "xyz" in its list of packages 5. Run, on the client, rhnreg_ks --activationkey=1-TEST The output is the same as in the original description. |
Created attachment 492043 [details] /var/log/up2date Description of problem: An error is seen if a client tries to register against a Satellite server using activation keys, and one of the packages listed in the activation key is signed by a GPG key unknown to the client. Version-Release number of selected component (if applicable): Satellite server 5.4, full list of rhn/satellite/spacewalk packages on client/server is attached. How reproducible: always Steps to Reproduce: 1. Create a clean client machine which has NOT been previously registered to the Satellite server. (this is important) 2. Create an RPM package (say, "xyz.rpm") and sign it with a key which is NOT present on the client. 3. Upload xyz.rpm to Satellite server (rhnpush) and place it in a channel which the client will be subscribed to upon registration 4. Create on the Satellite server an activation key (say, "TEST") which include "xyz" in its list of packages 5. Run, on the client, rhnreg_ks --activationkey=1-TEST Actual results: On the client CLI: "An error has occurred: <class 'xml.parsers.expat.ExpatError'> See /var/log/up2date for more information" [The contents of /var/log/up2date are attached] Note that at this point the client *has* successfully registered to the Satellite server; the error occurs during installation of RPMs listed in the activation key. (It may have even installed some preceding RPMs listed in the activation key.) The error can subsequently be reproduced at will by running "rhn_check"; the output of that running with "-v -v -v -v -v" is attached. Expected results: Client does not throw an internal XML error which is not comprehensible by an end user. This situation is a configuration error, however it should be handled more gracefully and the client should output something like: "Attempted to install package xyz whilst activating with key TEST; however this package is signed by an unknown GPG key (abcdef123)"