On 02/24/2012 08:14 AM, Stephen Benjamin wrote:
Also to make this work I installed qpid-server and qpid-tools on the CDS, and
linked them and shared the heartbeat topic:
On Server:
qpid-route link add pulp-server.example.com pulp-cds.example.com --durable
qpid-route dynamic add pulp-server.example.com pulp-cds.example.com heartbeat
--durable
On CDS:
qpid-route link add pulp-cds.example.com pulp-server.example.com --durable
qpid-route dynamic add pulp-cds.example.com pulp-server.example.com heartbeat
--durable
Should any other topics be shared? And perhaps there's a better way to setup
the qpidd on the CDS?
I've looked into setting federated brokers but not in enough depth to
provide much help here. The heartbeat is the only /topic/ but /queues/
will need to be routed as well. I know of a user that maintains a
federated broker network. I'll get with them or someone on the QPID
team and get back with you.
- Steve
----- Original Message -----
From: "Stephen Benjamin"<[email protected]>
To: [email protected]
Sent: Friday, February 24, 2012 2:24:42 PM
Subject: [Pulp-list] Issuing API commands to CDS
Hi,
I have a situation where the clients can only talk to the CDS in the
datacenter, not the pulp server itself. It seems like a good idea
that consumers could issue commands to the API instead of the CDS
(like rhnproxy can accept API requests).
Now I have it working to the CDS when you authenticate with with
pulp-consumer (pulp-consumer -u blah -p blah consumer history) since
that bypasses client certificate authentication, but I'd like to be
able to use the certificate. Of course passing the client
authentication would be difficult or impossible, since it's
effectively a man-in-the-middle attack.
I was thinking that maybe something like this would work:
API call, auth to cds w/ client cert forwards api
call, auth to pulp w/ cds ubercertificate
[consumer] --------------------------------> [cds]
--------------------------------------------------------> [pulp]
If this were possible, then I guess a consumer could issue basically
any command to pulp. This does work for our needs, though. Would
this be possible today, for the cds to have it's own client
certificate w/ more permissions?
A complete solution would have the cds only let consumers issue
commands for their own hostname I guess. Here's my
/etc/httpd/conf.d/pulp-api.conf on my CDS, working w/
username/password authentication:
SSLProxyEngine on
ProxyRequests On
<Proxy *>
Order deny,allow
Allow from *.example.com
</Proxy>
<Location /pulp/api>
SSLCACertificateFile /etc/pki/pulp/ca.crt
SSLVerifyClient optional
SSLVerifyDepth 2
SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth
ProxyPass https://pulp.example.com/pulp/api
ProxyPassReverse https://pulp.example.com/pulp/api
</Location>
- Steve
--
Stephen Benjamin
Red Hat GmbH
http://europe.redhat.com/
Mobile:+49(0)173-728-5703
______________________________________________________
Reg. Adresse: Rudower Chaussee 29, D-12489 Berlin
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Mark Hegarty,Charlie Peters, Michael Cunningham,
Charles Cachera
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
