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 452956 - getDmi generates xml ExpatError
Summary: getDmi generates xml ExpatError
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API
Version: 510
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jay Dobies
QA Contact: Sayli Karmarkar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-26 08:42 UTC by Chris Verhoef
Modified: 2015-03-23 01:09 UTC (History)
3 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 19:52:40 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Chris Verhoef 2008-06-26 08:42:54 UTC
Description of problem:
the function getDmi genetares xml.parsers.expat.ExpatError: xml declaration not
at start of external entity: line 1, column 76


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


How reproducible:
calling the getDmi function for example with the following python code:

client = xmlrpclib.Server(SATELLITE_URL, verbose=0)
key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)
list = client.system.listUserSystems(key)
for system in list:
   print system["name"]
   list1 = client.system.getId(key, system["name"])
   dmi = client.system.getDmi(key, list1[0]["id"])
client.auth.logout(key)

 
Actual results:
Traceback (most recent call last):
  File "./dmi.py", line 18, in <module>
    dmi = client.system.getDmi(key, list1[0]["id"])
  File "/usr/lib/python2.5/xmlrpclib.py", line 1150, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.5/xmlrpclib.py", line 1440, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.5/xmlrpclib.py", line 1204, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.5/xmlrpclib.py", line 1338, in _parse_response
    p.feed(response)
  File "/usr/lib/python2.5/xmlrpclib.py", line 547, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: xml declaration not at start of external entity:
line 1, column 76



Expected results:

struct(DMI)

Additional info:

Comment 1 Jay Dobies 2009-02-12 21:12:39 UTC
Commit: 6de58be208a84c940de798043215a4b2a2e17180

Added a check in the DmiSerializer to ensure that the DMI actually has data before trying to serialize it.

Comment 2 Sayli Karmarkar 2009-03-10 23:27:25 UTC
verified manually and with api automation test.

Comment 3 Tomas Lestach 2009-08-13 10:14:12 UTC
The api call from #Description works against a i386 satellite.

When running it against a s390x satellite, I get a following exception:

Traceback (most recent call last):
  File "./dmi.py", line 16, in ?
    dmi = client.system.getDmi(key, list1[0]["id"])
  File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.4/xmlrpclib.py", line 1147, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.4/xmlrpclib.py", line 1284, in _parse_response
    p.close()
  File "/usr/lib64/python2.4/xmlrpclib.py", line 530, in close
    self._parser.Parse("", 1) # end of data
xml.parsers.expat.ExpatError: no element found: line 1, column 0

Comment 4 Tomas Lestach 2009-08-13 15:44:10 UTC
When I deleted the appropriate client, that I got the exception (described in Comment#3) for, I wasn't able to reproduce the problem any again. The getDmi call works for all other clients even on the s390x satellite.

Stage validating -> RELEASE_PENDING

Comment 5 Brandon Perkins 2009-09-10 19:52:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html


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