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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
