Rex was setting up a server and wanted some help. His hosting provider had set him up with a username and password for authentication. He wanted me to log in to the machine under his account to help out. I didn’t want him to have to give me his password. Rex is a smart guy, but he is not a Linux user. He is certainly not a system administrator. The system was CentOS. The process was far more difficult to walk
The ever elusive bug 968696 is still out there, due, in no small part, to the distributed nature of the policy mechanism. One Question I asked myself as I chased this beastie is “how many distinct policy rules do we actually have to implement?” This is an interesting question because, if we can an automated way to answer that question, it can lead to an automated way to transforming the policy rules themselves, and thus getting to a more unified approach to policy.
This is more musing than a practical design.
Most application servers have a means to query LDAP for the authorization information for a user. This is separate from, and follows after, authentication which may be using one of multiple mechanism, possibly not even querying LDAP (although that would be strange).
And there are other mechanisms (SAML2, SSSD+mod_lookup_identity) that can, also, provide the authorization attributes.
One way to understand threads, process, containers, and VMs is to look at what each level of abstraction provides for isolation.
When you make a call to Keystone to get a token, you also get back the service catalog. While many of my scripts have used the $OS_AUTH_URL to make follow on calls, if the calls are administrative in nature, you should use the URL in service catalog.
This makes use of curl fetch the token and jq to parse the output.
When working with New APIS we need to test them with curl prior to writing the python client. I’ve often had to hand create the JSON used for the token request, as I wrote about way back here. Here is a simple bash script to convert the V3 environment variables into the JSON for a token request.
Here is a proof of concept of deploying an OpenStack Tripleo Overcloud using the Fernet token provider.
My team is working on the ability to automatically enroll servers launched from Nova in FreeIPA. Debugging the process has proven challenging; when things fail, the node does not come up, and there is little error reporting. This article posts a baseline of what things look like prior to any changes, so we can better see what we are breaking.
When I booted a VM yesterda, I noticed that there was a huge command line that showed up if I ran ps. I tried to run that by hand. It is huge, so I wrapped it with a script, but the command is not too bad to understand: everything that qemu needs to do needs to be passed in on the command line.
Just because Icehouse is EOL does not mean no one is running it. One part of my job is back-porting patches to older versions of Keystone that my Company supports.
A dirty secret is that we only package the code needed for the live deployment, though, not the unit tests. In the case of I need to test a bug fix against a version of Keystone that was, essentially, Upstream Icehouse.