Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 570393 - system.getCpu returns empty HTTP body when there is no hardware info (rhnreg_ks --nohardware)
Summary: system.getCpu returns empty HTTP body when there is no hardware info (rhnreg_...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On:
Blocks: sat540-canfix
TreeView+ depends on / blocked
 
Reported: 2010-03-04 07:24 UTC by Michael Kearey
Modified: 2018-11-14 20:18 UTC (History)
5 users (show)

Fixed In Version: spacewalk-java-1.2.36-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-28 14:48:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Michael Kearey 2010-03-04 07:24:47 UTC
Description of problem:
When perl Frontier::Client is used to request data from the Satellite and the data is non-existent, the Satellite xmlrpc API returns an empty 'object.' instead of an XML object. The Frontier::Client call function does not at all handle an empty object. Instead it drops an ugly parser error

Version-Release number of selected component (if applicable):
perl-Frontier-RPC-0.07b4p1-8.el5sat  is effected

How reproducible:
100%

Steps to Reproduce:
1. Register a system to RHN Satellite using rhnreg_ks --nohardware  to ensure no hardware information is sent
2. Use the perl-Frontier-RPC-0.07b4p1-8.el5sat supplied Frontier::Client module to request CPU data for the registered profile via the RHN Satellite API
  
Actual results:
When no hardware data is found the perl script fails with :


no element found at line 1, column 0, byte -1 at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/XML/Parser.pm line 185

Expected results:

I expect to be able to check return value to determine if anything was found instead of an error like the 'Actual Results'  show

Additional info:

Test script in perl :

#!/usr/bin/perl

use Frontier::Client;
use MIME::Lite;
use Error qw(:try);


my $client = new Frontier::Client(url => "http://$HOST/rpc/api");
$session = $client->call('auth.login','test', 'test');

my $query = $client->call('system.getCpu', $session, XXXXXXX);


Edit it to use a system ID that matches a registered system, where that system has no hardware included

Comment 2 Michael Kearey 2010-03-04 07:30:00 UTC
I have modified the Frontier::Client Client.pm module:

In /usr/lib/perl5/vendor_perl/5.8.8/Frontier/Client.pm, the call function was
where the error happens, at the line:

   my $result = $self->{'enc'}->decode($content);


The decode function does not handle a variable with '' in it.


I altered the call function from Frontier::Client so that if the content was ''
it returned, by adding :


   if ( $content eq '') {
       return;
       }


The complete function looks like this:


sub call {
   my $self = shift;

   my $content = $self->raw_call(@_);

   if ($self->{'debug'}) {
       print "---- response ----\n";
       print $content;
   }
   if ( $content eq '') {
       return;
       }
   my $result = $self->{'enc'}->decode($content);

   if ($result->{'type'} eq 'fault') {
       die "Fault returned from XML RPC Server, fault code " .
$result->{'value'}[0]{'faultCode'} . ": "
           . $result->{'value'}[0]{'faultString'} . "\n";
   }

   return $result->{'value'}[0];
}



I then altered the example code so it looked like this:


#!/usr/bin/perl

use Data::Dumper;
use Frontier::Client;
use MIME::Lite;
use Error qw(:try);
$HOST = 'localhost';

my $client = new Frontier::Client(url => "http://$HOST/rpc/api",debug => 200);
$session = $client->call('auth.login','XUSERX', 'XPASSWORDX');

my $hwinfo = $client->call('system.getCpu', $session, "1000010040");

# Check that $hwinfo is defined !! If it is we use it
if (defined $hwinfo) {
       print "size of hash: " . keys (%hwinfo) . "\n";


       print Dumper $hwinfo;

               for my $key ( keys %hwinfo) {
                       my $value = $hash{$key};
                       print "$key = $value\n";
               }
       }

else {
       print "No data!\n";
       }


I really do not know if this is the right place to fix it, seems logical to me.

Comment 3 Jan Pazdziora 2010-03-18 12:39:54 UTC
Michael,

my feeling is that this is actually not an error in the client code but in the server code. The server code should never return status 200 OK and then an empty body.

This is supported by the fact that an equivalent Python code 

import xmlrpclib

s = xmlrpclib.ServerProxy("http://localhost/rpc/api")
session = s.auth.login('test', 'test')
q = s.system.getCpu(session, 1000023369)

fails as well:

Traceback (most recent call last):
  File "test-empty-return-from-xmlrpc.py", line 7, in ?
    q = s.system.getCpu(session, 1000023369)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in _parse_response
    return u.close()
  File "/usr/lib/python2.4/xmlrpclib.py", line 742, in close
    raise ResponseError()
xmlrpclib.ResponseError: <xmlrpclib.ResponseError instance at 0xb7cf11ac>

Therefore, flipping to component API for investigation.

Comment 6 Tomas Lestach 2010-09-09 14:03:31 UTC
return empty struct in case no hardware info is available

spacewalk.git: a2627a78fd6bbb65437907389857802d31d1fad3

same for system.getDmi API:

spacewalk.git: 0d66294db74b79eee53532e43c97b22cefcc2dfd

Comment 9 Miroslav Suchý 2010-10-22 13:16:25 UTC
passed beaker test (j:25547)

Comment 10 Clifford Perry 2010-10-28 14:43:48 UTC
The 5.4.0 RHN Satellite and RHN Proxy release has occurred. This issue has been resolved with this release. 


RHEA-2010:0801 - RHN Satellite Server 5.4.0 Upgrade
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10332

RHEA-2010:0803 - RHN Tools enhancement update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10333

RHEA-2010:0802 - RHN Proxy Server 5.4.0 bug fix update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10334

RHEA-2010:0800 - RHN Satellite Server 5.4.0
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10335

Docs are available:

http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html 

Regards,
Clifford


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