The /usr/lib64/python2.7/ConfigParser.py is owned by python, not
rhncfg-client or other Spacewalk code. Could you work with Fedora
python maintainer to have this investigated?

contacted Toshio

Thanks for filing this bug report.

I'm able to reproduce this on a vanilla install of rhncfg-client (i.e. without touching any config files) by running:

   $ rhncfg-client list

This is with:
  rhncfg-5.9.48-2.fc15.noarch
  rhncfg-client-5.9.48-2.fc15.noarch
  python-2.7.1-5.fc15.x86_64
  python-libs-2.7.1-5.fc15.x86_64

Am investigating.

Running under pdb:

  $ python -m pdb /usr/bin/rhncfg-client list

shows that the code in question is:

  540  	        # join the multi-line values collected while reading
  541  	        all_sections = [self._defaults]
  542  	        all_sections.extend(self._sections.values())
  543  	        for options in all_sections:
  544  	            for name, val in options.items():
  545  	                if isinstance(val, list):
  546  ->	                    options[name] = '\n'.join(val)
  547  	

and that "name" is:
  'serverurl'

and that "val" is:
  [{'server_name': 'enter.your.server.url.here', 'proto': 'https'}]

i.e. the first entry is indeed a dict, not a string.

The file is "/etc/sysconfig/rhn/rhncfg-client.conf"

Looking at that file, I see:
  # to use a server other than what up2date is configured to use,
  # do something along the lines of:
  # server_url = https://some.example.com%(server_handler)s
  # server_url = http://another.example.net:8080%(server_handler)s
  # server_url = https://yet.another.example.org:8081/CONFIG-MANAGEMENT
  server_url = %(proto)s://%(server_name)s%(server_handler)s

From my reading of the code/debugging in pdb, it seems:
  - that this is coming from the "defaults" for the config parser.

  - that the defaults are coming from:
       /usr/share/rhn/config_common/rhn_main.py(145):main()
145  ->	            local_config.init(self.config_section, defaults=up2date_cfg)

  - that up2date_cfg is set up in that function by:
130            up2date_cfg = utils.get_up2date_config()

  - and that that's coming from some complex-looking logic in
      /usr/share/rhn/config_common/utils.py:get_up2date_config

(Pdb) p up2date_cfg
{'stagingContentWindow': '24', 'versionOverride': '', 'stagingContent': '1', 'server_name': 'enter.your.server.url.here', 'networkRetries': '1', 'hostedWhitelist': '', 'enableProxy': '0', 'proto': 'https', 'tmpDir': '/tmp', 'serverURL': [{'server_name': 'enter.your.server.url.here', 'proto': 'https'}], 'skipNetwork': '0', 'disallowConfChanges': ['noReboot', 'sslCACert', 'useNoSSLForPackages', 'noSSLServerURL', 'serverURL', 'disallowConfChanges'], 'sslCACert': '/usr/share/rhn/RHNS-CA-CERT', 'retrieveOnly': '0', 'debug': '0', 'httpProxy': '', 'useNoSSLForPackages': '0', 'systemIdPath': '/etc/sysconfig/rhn/systemid', 'writeChangesToLog': '0', 'noReboot': '0'}

Looks like the defaults for a ConfigParser:
  - must be a dictionary
    - where the keys must be strings, and
    - the values must be either strings or lists of strings

The problem is that up2date_cfg['serverURL'] is a list containing a dict.

Admittedly, from my reading of
  http://docs.python.org/library/configparser.html
the precise types expected by the API aren't clear.

Looks like a bug in rhncfg; reassigning component accordingly.

I suggest adding a validation step to the rhncfg code to assert that the defaults for the ConfigParser are sane.

I can confirm that python-2.7 ConfigParser only takes string keys and values as it's bitten me before.  The upstream author considers the ability to take non-string values in previous versions to have been a bug.

rhncfg* has its own code for handling configs. If I use
from up2date_client import config
cfg = config.initUp2dateConfig()
cfg["serverURL"]
I will get correctly:
'http://enter.your.server.url.here/XMLRPC'

I will the the transition to use rhn-client-tools code. I have to do it for work on IDN anyway.

Dear Miroslav,

do you think you could make that happen for the 1.4 client tools, as we are in need to deploy Fedora 15 when it's released.

Greets
Marcus

Nope, it will for sure dit not make it to Spacewalk 1.4.
Sorry.

Removing from space15 as this is Fedora bugzilla.

It is fixed in Fedora 17. If not, please reopen this bug.
Solution is more complex and therefore will not be backported to older Fedora.