Horizon is the Web Dashboard for OpenStack. Since it manages some very sensitive information, it should be accessed via SSL. I’ve written up in the past how to do this for a generic web server. Here is how to apply that approach to Horizon.
Continue reading
Horizon is The OpenStack Dashboard. It is a DJango (Python) Web app. During a default installation, Horizon has resources at one level under the main Hostname in the URL scheme. For example, authentication is under http://hostname/auth.
Devstack performs single system deployments. Packstack has an “all-in-one” option that does the same thing. If these deployment tools are going to deploy other services via HTTPD, Horizon needs to be taught how to share the URL space. Fortunately, this is not hard to do.
Continue reading
The PKI version of the Keystone tokens use a standard format for cryptographic signing of documents. Crypto Message Syntax (CMS) is the mechanism behind S/MIME and is well supported by the major cryptographic libraries: OpenSSL and NSS both have well documented CMS support. Messaging in OpenStack requires guaranteed identification of the author.
We want to replace the shell call to openssl for certificate generation in Keystone (and the rest of OpenStack) with calls to Certmonger. Certmonger supports both OpenSSL and NSS. Certmonger can support a selfsigned approach, as well as tie in to a real Certificate Authority. Here are the steps I took to test out selfsigning, as well as my notes for follow on work.
Continue reading
The maximum header size between a HTTPD and an WSGI process is fixed at 8 Kilobytes. With a sufficiently large catalog, the token in PKI format won’t fit. Compression seems like it would be such an easy solution. But the there is a Hobgoblin or two hiding in the shadows.
Continue reading
The majority of web service calls in OpenStack require token validation. Checking a token ID against a list is a cheap hashtable lookup. Comparing a token to a set of events is more expensive. How can we keep costs down?
Continue reading
To make things easier for your code reviewer, each patch should be small, and hold one well defined change. I break this rule all the time, and it comes back to bite me. What happens is that I get heads down coding, and I have a solution that involves changes to wide number of files and subsystems, new abstractions, etc. Here is how I am currently dealing with breaking down a big patch.
OpenStack Milestone Icehouse 2 (I2) is due this Tuesday. The gate is deep and the penalty for messing it up is costly. I recently had to update a patch that depends on three patches that are approved but but not merged to master. Using the git review command line, all 5 patches would get resubmitted. This was too high a risk for me.
Much of the future work we need to do on Keystone falls into issued of scope. I’m going to merely try and define the problems here, and avoid talking about solutions. I’ll try to address more specific aspects in future posts. Continue reading
My last post showed how to load the user data using curl. This is only interesting if you love curl. Its pretty easy to do the same thing from the command line. Now, we at Keystone central hate responsibility. We have no desire to do more than we have to. That includes wrint the Command Line Client.
There is an effort afoot to move to a unified command line. Here is a sneak peek:
To get this to work took a little finagling: When a user gets a token, it contains the URL for the Keystone admin port, and the CLI uses this to perform the user create action. There is work going to to do better discoverability (figure out which version of the API is supported), but until then, you can do the following hack (not recommended for production)
Edit the database
mysql --user keystone --password=keystone keystone
Make the admin URL V3 specific:
update endpoint set url='http://127.0.0.1:35357/v3' where url like 'http://127.0.0.1:35357/%';
Restart Keystone.
And you can use the command:
export OS_AUTH_URL=http://127.0.0.1:5000/v3 export OS_USERNAME=admin export OS_PASSWORD=freeipa4all export OS_TENANT_NAME=admin openstack --os-identity-api-version=3 user create testname2 --password=testme --project=demo --domain=default
So my previous example would be reduced to:
while read USERNAME ; do openstack --os-identity-api-version=3 user create $USERNAME --password=changeme --project=demo ; done < usernames.txt