[Spacewalk-list] mrepo / gensystemid errors

[Boyd, Robert]

If you’re having trouble with gensystemid Try changing the first few lines of the code like this:

if os.path.exists('/usr/share/mrepo/up2date_client/'):
    sys.path.insert(7, '/usr/share/mrepo/')
    sys.path.insert(7, '/usr/share/mrepo/up2date_client/')
elif os.path.exists('/usr/share/rhn/up2date_client/'):
    sys.path.insert(7, '/usr/share/rhn/')
    sys.path.insert(7, '/usr/share/rhn/up2date_client/')

This will insert the mrepo or rhn libraries ahead of the python site-packages.  For some reason the site packages were promoted by several hops in the path list.

A better alternative would be to actually search the list and insert the rhn or mrepo libraries just prior to the site packages.   Maybe I’ll have to learn enough python to pull this off.

In any event, I’m now getting an intelligible error message … Error communicating with the server. The message was:  Name or service not known.

That is something I can investigate more directly I think.

Robert

From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Boyd, Robert
Sent: Monday, August 06, 2012 5:52 PM
To: spacewalk-list at redhat.com; Alan Pittman; 'fnwsa at yahoo.com'
Subject: Re: [Spacewalk-list] mrepo / gensystemid errors

I found one answer to my question.   There is a handy tool called dumpObj that you can copy from http://code.activestate.com/recipes/137951-dump-all-the-attributes-of-an-object/

So I copied it and inserted it into gensystemid on both servers.   Here is the key thing I see that is different:

On the server where gensystemid fails (RHEL6.3) :

__file__              /usr/lib/python2.6/site-packages/rhn/rpclib.pyc
  __name__              rhn.rpclib
  __package__           rhn
  __version__           $Revision$

With sys.path:  ['/root', '/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/gst-0.10', '/usr/lib64/python2.6/site-packages/gtk-2.0', '/usr/lib64/python2.6/site-packages/webkit-1.0', '/usr/lib/python2.6/site-packages', '/usr/share/mrepo/', '/usr/share/mrepo/up2date_client/', '/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info']

On the RHEL 5.8 server where it works:

__file__              /usr/share/mrepo/rhn/rpclib.pyc
  __name__              rhn.rpclib
  __version__           $Revision: 118741 $

sys.path:  ['/root', '/usr/lib64/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/gtk-2.0', '/usr/share/mrepo/', '/usr/share/mrepo/up2date_client/', '/usr/lib/python2.4/site-packages']

So on the failing configuration somehow it’s not finding the module which is clearly there.   I checked.

Is there something wrong with the new search order?   I see that there are many differences in these 2 lists.   Anyone have a suggestion about what needs to be changed on the RHEL 6.3/Python 2.6 configuration to get the right module found?

Robert


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120806/ef1dcdb8/attachment.htm>