To reproduce:

- pulp-admin auth login -uadmin -padmin
- pulp-admin repo create --id=foo --feed=yum:http://mmccune.fedorapeople.org/pulp/
- pulp-admin repo sync --id=foo


The following traceback is seen:

Traceback (most recent call last):
  File "/usr/bin/pulp-admin", line 30, in <module>
    pulpcli.PulpCore().main()
  File "/usr/lib/python2.6/site-packages/pulp/client/pulpcli.py", line 108, in main
    cmd.main()
  File "/usr/lib/python2.6/site-packages/pulp/client/core/basecore.py", line 120, in main
    self._do_core()
  File "/usr/lib/python2.6/site-packages/pulp/client/core/core_repo.py", line 122, in _do_core
    self._sync()
  File "/usr/lib/python2.6/site-packages/pulp/client/core/core_repo.py", line 193, in _sync
    status = self.pconn.sync_status(task_object['status_path'])
  File "/usr/lib/python2.6/site-packages/pulp/client/connection.py", line 266, in sync_status
    return self.conn.request_get(status_path)
  File "/usr/lib/python2.6/site-packages/pulp/client/connection.py", line 119, in request_get
    return self._request("GET", method)
  File "/usr/lib/python2.6/site-packages/pulp/client/connection.py", line 111, in _request
    return json.loads(rinfo)
  File "/usr/lib64/python2.6/json/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/lib64/python2.6/json/decoder.py", line 319, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib64/python2.6/json/decoder.py", line 338, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded


Oddly, in /var/log/httpd/ssl_access_log, the following is seen:

127.0.0.1 - - [27/Aug/2010:15:30:30 -0400] "POST /pulp/api//repositories/foo/sync/ HTTP/1.1" 202 295
127.0.0.1 - - [27/Aug/2010:15:30:35 -0400] "G" 501 273

For some reason, the request coming from the client is mangled when using client certificates (i.e. httpslib).


Testing directly on the status URL using wget works fine:

wget --no-check-certificate --certificate=/home/jdob/.pulp/admin-cert.pem --private-key=/home/jdob/.pulp/admin-key.pem https://guardian/pulp/api/repositories/foo/sync/f26ec5ca-b211-11df-b669-00508d977dff/

This will properly retrieve the JSON encoded status of the sync.


Furthermore, I threw together a sample python app that uses the same approach the CLI does. This is also successful:

-----
import locale
from M2Crypto import SSL, httpslib

try:
    import json
except ImportError:
    import simplejson as json

context = SSL.Context('sslv3')
context.load_cert('/home/jdob/.pulp/admin-cert.pem', '/home/jdob/.pulp/admin-key.pem')
conn = httpslib.HTTPSConnection('guardian', 443, ssl_context=context)

url = '/pulp/api/repositories/foo/sync/e9eacbdc-b215-11df-b57e-00508d977dff/'

headers = {"Content-type":"application/json",
           "Authorization": None,
           "Accept": "application/json",
           "Accept-Language": locale.getdefaultlocale()[0].lower().replace('_', '-')}

conn.request('GET', url, body=json.dumps(None), headers=headers)
response = conn.getresponse()
print(response.read())
-----

Again, this properly prints out the JSON encoded response.

There is something else at play in the CLI that's causing the requests to be mangled. My bigger concern is that this will eventually bite us in a consumer operation which requires use of client certs, since they both go through the same connection codebase.