Merge "Delete PKI middleware debugging section"
This commit is contained in:
commit
002128208c
|
@ -21,127 +21,3 @@ ideally show an error that explains why an authorization request failed.
|
||||||
If you do not see the request in the logs, run keystone with the
|
If you do not see the request in the logs, run keystone with the
|
||||||
``--debug`` parameter. Pass the ``--debug`` parameter before the
|
``--debug`` parameter. Pass the ``--debug`` parameter before the
|
||||||
command parameters.
|
command parameters.
|
||||||
|
|
||||||
Debug PKI middleware
|
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Problem
|
|
||||||
-------
|
|
||||||
|
|
||||||
If you receive an ``Invalid OpenStack Identity Credentials`` message when
|
|
||||||
you accessing and reaching an OpenStack service, it might be caused by
|
|
||||||
the changeover from UUID tokens to PKI tokens in the Grizzly release.
|
|
||||||
|
|
||||||
The PKI-based token validation scheme relies on certificates from
|
|
||||||
Identity that are fetched through HTTP and stored in a local directory.
|
|
||||||
The location for this directory is specified by the ``signing_dir``
|
|
||||||
configuration option.
|
|
||||||
|
|
||||||
Solution
|
|
||||||
--------
|
|
||||||
|
|
||||||
In your services configuration file, look for a section like this:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[keystone_authtoken]
|
|
||||||
signing_dir = /var/cache/glance/api
|
|
||||||
www_authenticate_uri = http://controller:5000/v2.0
|
|
||||||
identity_uri = http://controller:35357
|
|
||||||
admin_tenant_name = service
|
|
||||||
admin_user = glance
|
|
||||||
|
|
||||||
The first thing to check is that the ``signing_dir`` does, in fact,
|
|
||||||
exist. If it does, check for certificate files:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ ls -la /var/cache/glance/api/
|
|
||||||
|
|
||||||
total 24
|
|
||||||
drwx------. 2 ayoung root 4096 Jul 22 10:58 .
|
|
||||||
drwxr-xr-x. 4 root root 4096 Nov 7 2012 ..
|
|
||||||
-rw-r-----. 1 ayoung ayoung 1424 Jul 22 10:58 cacert.pem
|
|
||||||
-rw-r-----. 1 ayoung ayoung 15 Jul 22 10:58 revoked.pem
|
|
||||||
-rw-r-----. 1 ayoung ayoung 4518 Jul 22 10:58 signing_cert.pem
|
|
||||||
|
|
||||||
This directory contains two certificates and the token revocation list.
|
|
||||||
If these files are not present, your service cannot fetch them from
|
|
||||||
Identity. To troubleshoot, try to talk to Identity to make sure it
|
|
||||||
correctly serves files, as follows:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ curl http://localhost:35357/v2.0/certificates/signing
|
|
||||||
|
|
||||||
This command fetches the signing certificate:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
Certificate:
|
|
||||||
Data:
|
|
||||||
Version: 3 (0x2)
|
|
||||||
Serial Number: 1 (0x1)
|
|
||||||
Signature Algorithm: sha1WithRSAEncryption
|
|
||||||
Issuer: C=US, ST=Unset, L=Unset, O=Unset, CN=www.example.com
|
|
||||||
Validity
|
|
||||||
Not Before: Jul 22 14:57:31 2013 GMT
|
|
||||||
Not After : Jul 20 14:57:31 2023 GMT
|
|
||||||
Subject: C=US, ST=Unset, O=Unset, CN=www.example.com
|
|
||||||
|
|
||||||
Note the expiration dates of the certificate:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
Not Before: Jul 22 14:57:31 2013 GMT
|
|
||||||
Not After : Jul 20 14:57:31 2023 GMT
|
|
||||||
|
|
||||||
The token revocation list is updated once a minute, but the certificates
|
|
||||||
are not. One possible problem is that the certificates are the wrong
|
|
||||||
files or garbage. You can remove these files and run another command
|
|
||||||
against your server; they are fetched on demand.
|
|
||||||
|
|
||||||
The Identity service log should show the access of the certificate files. You
|
|
||||||
might have to turn up your logging levels. Set ``debug = True`` in your
|
|
||||||
Identity configuration file and restart the Identity server.
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
(keystone.common.wsgi): 2013-07-24 12:18:11,461 DEBUG wsgi __call__
|
|
||||||
arg_dict: {}
|
|
||||||
(access): 2013-07-24 12:18:11,462 INFO core __call__ 127.0.0.1 - - [24/Jul/2013:16:18:11 +0000]
|
|
||||||
"GET http://localhost:35357/v2.0/certificates/signing HTTP/1.0" 200 4518
|
|
||||||
|
|
||||||
If the files do not appear in your directory after this, it is likely
|
|
||||||
one of the following issues:
|
|
||||||
|
|
||||||
* Your service is configured incorrectly and cannot talk to Identity.
|
|
||||||
Check the ``auth_port`` and ``auth_host`` values and make sure that
|
|
||||||
you can talk to that service through cURL, as shown previously.
|
|
||||||
|
|
||||||
* Your signing directory is not writable. Use the ``chmod`` command to
|
|
||||||
change its permissions so that the service (POSIX) user can write to
|
|
||||||
it. Verify the change through ``su`` and ``touch`` commands.
|
|
||||||
|
|
||||||
* The SELinux policy is denying access to the directory.
|
|
||||||
|
|
||||||
SELinux troubles often occur when you use Fedora or RHEL-based packages and
|
|
||||||
you choose configuration options that do not match the standard policy.
|
|
||||||
Run the ``setenforce permissive`` command. If that makes a difference,
|
|
||||||
you should relabel the directory. If you are using a sub-directory of
|
|
||||||
the ``/var/cache/`` directory, run the following command:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# restorecon /var/cache/
|
|
||||||
|
|
||||||
If you are not using a ``/var/cache`` sub-directory, you should. Modify
|
|
||||||
the ``signing_dir`` configuration option for your service and restart.
|
|
||||||
|
|
||||||
Set back to ``setenforce enforcing`` to confirm that your changes solve
|
|
||||||
the problem.
|
|
||||||
|
|
||||||
If your certificates are fetched on demand, the PKI validation is
|
|
||||||
working properly. Most likely, the token from Identity is not valid for
|
|
||||||
the operation you are attempting to perform, and your user needs a
|
|
||||||
different role for the operation.
|
|
||||||
|
|
Loading…
Reference in New Issue