Bug 167250 - Registering a machine to an account with no entitlements generates a traceback.
Summary: Registering a machine to an account with no entitlements generates a traceback.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Backend
Version: rhn400
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Max Spevack
URL:
Whiteboard:
Depends On:
Blocks: 167310
TreeView+ depends on / blocked
 
Reported: 2005-08-31 21:34 UTC by John Wregglesworth
Modified: 2007-04-18 17:31 UTC (History)
3 users (show)

Fixed In Version: rhn40hotfix1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-19 16:42:26 UTC


Attachments (Terms of Use)

Description John Wregglesworth 2005-08-31 21:34:54 UTC
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 15:31:49 UTC
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 15:58:01 UTC
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 17:15:45 UTC
test plan: See comment #1

Comment 4 Nick Hansen 2005-09-07 21:58:50 UTC
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 14:30:29 UTC
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 21:03:24 UTC
verified in stage


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