1.0pre4 client traceback when server disallows connection

[lueningh]

I added aliases to all of my machines in clients.xml, giving me an entry for one particular machine that looked like:

  <Client profile='bgp-mgt8' name='mgt8.ether.alcf.anl.gov' address='10.40.2.8'>
    <Alias name='mgt8-mgmt.ether.alcf.anl.gov' address='10.40.2.8'/>
  </Client>

When running the client, it tracebacked:

mgt8:/var/lib/bcfg2/Metadata # bcfg2 -v -I -b ssh -S https://10.40.2.8:6789 -C /tmp/bcfg2.conf 
Unknown failure
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/Bcfg2/Proxy.py", line 41, in __call__
    return _Method.__call__(self, *args)
  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/site-packages/Bcfg2/Proxy.py", line 132, in request
    msglen = int(headers.dict['content-length'])
KeyError: 'content-length'
Failed to download probes from bcfg2
Server Failure

and the server (running in debug mode) complained:

Address 10.40.2.8 has multiple reverse assignments; a uuid must be used
Client 10.40.2.8 failed to authenticate due to metadata problem
Authentication Failure
mgt8.ether.alcf.anl.gov - - [09/Jul/2009 09:30:58] code 401, message Unauthorized

Two thoughts here:

1. The client shouldn't traceback, of course

2. Does the use of aliases for CNAMES _really_ count as having multiple reverse assignments?

[desai]

OK, the address issue appears to be due to using the same address multiple times. This shouldn't be required. (and removing the dup fixes the problem)

The traceback appears to be due to the permission denied. We need to track this one down.

[desai]

Resolved in [48d42e7350487b62e1f2a924cab9f1d15444f327] (SVN r5494)