Open Stack

We were adding our CA to the bundle, we are using python-requests.
python-requests is getting installed via pip in a venv, and it includes
it's own CA bundle. So we were creating a symlink from the system bundle to
the venv requests bundle. Then something upgraded python-requests in the
venv, which overwrote the symlink, which actually overwrote the system
bundle, for maximum lols.

At that point we decided to go with the openstack config file route :)


- jlk

On Wed, Mar 25, 2015 at 2:03 PM, John Dewey <john at dewey.ws> wrote:

>  I faced this very issue in the past.  We solved the problem by adding the
> CA to the system bundle (as you stated).  We also ran into problems where
> python would still not validate the CA.  However, this turned out to be a
> permissions error with cacerts.txt[1] when httplib2 was installed through
> pip.  Nowadays openstack uses requests which I don’t believe utilizes
> httplib2.
>
> [1] https://code.google.com/p/httplib2/issues/detail?id=292&q=certificate
>
> On Wednesday, March 25, 2015 at 11:13 AM, Jesse Keating wrote:
>
> We're facing a bit of a frustration. In some of our environments, we're
> using a self-signed certificate for our ssl termination (haproxy). We have
> our various services pointing at the haproxy for service cross-talk, such
> as nova to neutron or nova to glance or nova to cinder or neutron to nova
> or cinder to glance or all the things to keystone. When using a self-signed
> certificate, these services have trouble validating the cert when they
> attempt to talk to each other. This problem can be solved in a few ways,
> such as adding the CA to the system bundle (of your platform has such a
> thing), adding the CA to the bundle python requests uses (because
> hilariously it doesn't always use the system bundle), or the more direct
> way of telling nova, neutron, et al the direct path to the CA file.
>
> This last choice is the way we went forward, more explicit, and didn't
> depend on knowledge if python-requests was using its own bundle or the
> operating system's bundle. To configure this there are a few places that
> need to be touched.
>
> nova.conf:
> [keystone_authtoken]
> cafile = <path>
>
> [neutron]
> ca_certificates_file = <path>
>
> [cinder]
> ca_certificates_file = <path>
>
> (nothing for glance hilariously)
>
>
> neutron.conf
> [DEFAULT]
> nova_ca_certificates_file = <path>
>
> [keystone_authtoken]
> cafile = <path>
>
> glance-api.conf and glance-registry.conf
> [keystone_authtoken]
> cafile = <path>
>
> cinder.conf
> [DEFAULT]
> glance_ca_certificates_file = <path>
>
> [keystone_authtoken]
> cafile = <path>
>
> heat.conf
> [clients]
> ca_file = <path>
>
> [clients_<whatever>]
> ca_file = <path>
>
>
> As you can see, there are a lot of places where one would have to define
> the path, and the frustrating part is that the config name and section
> varies across the services. Does anybody think this is a good thing? Can
> anybody think of a good way forward to come to some sort of agreement on
> config names? It does seem like heat is a winner here, it has a default
> that can be defined for all clients, and then each client could potentially
> point to a different path, but every config entry is named the same. Can we
> do that across all the other services?
>
> I chatted a bit on twitter last night with some nova folks, they suggested
> starting a thread here on ops list and potentially turning it into a
> hallway session or real session at the Vancouver design summit (which
> operators are officially part of).
>
> - jlk
>  _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150325/6bbbbbac/attachment.html>