Bug 167250 - Registering a machine to an account with no entitlements generates a traceback.
Registering a machine to an account with no entitlements generates a traceback.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend (Show other bugs)
rhn400
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Max Spevack
:
Depends On:
Blocks: 167310
  Show dependency treegraph
 
Reported: 2005-08-31 17:34 EDT by John Wregglesworth
Modified: 2007-04-18 13:31 EDT (History)
3 users (show)

See Also:
Fixed In Version: rhn40hotfix1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-19 12:42:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Wregglesworth 2005-08-31 17:34:54 EDT
Description of problem: Whenever a user registers a machine to an account with
no entitlements, a traceback is generated and mailed out. As far as I can tell
it isn't visible to an end user, but it is annoying as hell.

The cause of this is in eng/backend/server/rhnChannels.py, in the
system_reg_message function. Whenever server_lib.check_entitlement(server_id) is
called on an account without any entitlements it returns an empty {}, which in
turn causes an exception to be explicitly raised. This exception causes the
traceback. 

The main question seems to be how to handle this. Should we just get rid of the
check that causes the exception to be raised? This is a legitimate option
because having server_lib.check_entitlement(server_id) return an empty {} is now
acceptable. Or is there any way that we can tell that the values returned by
server_lib.check_entitlement(server_id) are valid? Checking to make sure that
either all of the correct keys are in the {} or none of them are seems possible.

Hopefully some of that made sense. 

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


How reproducible: Always


Steps to Reproduce:
1. Register a machine to an account with no entitlements.
2.
3.
  
Actual results: Traceback.


Expected results: No Traceback.


Additional info:
Comment 1 Mihai Ibanescu 2005-09-02 11:31:49 EDT
Steps to reproduce:
Use the up2date.py script.

1. register a system

python up2date.py --server live --username XXX --password YYY --test new_system
--profile finish_message --save-systemid-file /tmp/systemid-finish-message

2. Go to the web site, unentitle the system.

3. Try to run the finish_message XMLRPC call:

python up2date.py --server live --username mibanescu --password 4everblu --test
new_system --profile finish_message --save-systemid-file
/tmp/systemid-finish-message

It will fail with
...
xmlrpclib.ProtocolError: <ProtocolError for xmlrpc.rhn.redhat.com /XMLRPC: 500
Internal Server Error>
Comment 2 Mihai Ibanescu 2005-09-02 11:58:01 EDT
Fixed in checkin 64215 (in HEAD: eng/backend/server/rhnChannel.py).

rhns-4.0.0.1-1 and 4.0.0-187 for the fixes.
Comment 3 Robin Norwood 2005-09-07 13:15:45 EDT
test plan: See comment #1
Comment 4 Nick Hansen 2005-09-07 17:58:50 EDT
see as how I couldn't find the pacakges that misa mentioned in comment #2, I've
build the rhns-4.0.0.1-1.rhel4 packages into the devel collection in the build
system and promoted them to the qa collection as well. 
I also built the packages into the satellite-4.0-3AS|4AS collections as well.
those versions are 4.0.0.1-2 and 4.0.0.1-3, respectively.
Comment 5 Max Spevack 2005-09-09 10:30:29 EDT
no more ISE in webqa

rhns-4.0.0.1-1.rhel4 is on rhnxml.back-webqa

PROD_READY
Comment 6 Vlady Zlatkin 2005-09-13 17:03:24 EDT
verified in stage

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