Fixup Analytics oauth

gistfile1.md

This documentation is sufficient to work with the following versions

Chef Server: 12.0.8

Analytics: 1.1.x

Problem

Analytics is no longer able to auth with the oc_id service back on the Chef Server it's pointed to in it's /etc/opscode-analytics/actions-source.json file. The uid field in that file is used during the initial and any subsequent authorization calls back to the Chef Server.

Error messages like this are appearing in the Analytics system's web interface when trying to login, or the interface is unable to login

An error has occurred
Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method.

Explanation

The installation documentation for Analytics, which will help to understand more about how the config works can be found at http://docs.chef.io/analytics/install_analytics.html#standalone-version-1-1

In the URL bar of the browser, you wil see a URL like this after hitting the Analytics FQDN and trying to login

https://centos-6.3/id/oauth/authorize?response_type=token&client_id=e63fb9b90fd1d0c7127d71c34da87e2cfbb512e58f2943b628d3301bd482eee9&redirect_uri=https%3A%2F%2Fcentos-6.5-analytics&scope=&state=

The client_id portion will show up in /etc/opscode-analytics/actions-source.json as the uid field, like this

{
  "private_chef": {
    "api_fqdn": "centos-6.3",
    "oc_id_application": {
      "name": "analytics",
      "uid": "e63fb9b90fd1d0c7127d71c34da87e2cfbb512e58f2943b628d3301bd482eee9",
      "secret": "18dbfcc146ca0a4fe6254d8481bde16e06f7242954dff901f85d0e20f27495ba",
      "redirect_uri": "https://centos-6.5-analytics/"
    },
    "rabbitmq_host": "33.33.33.9",
    "rabbitmq_port": "5672",
    "rabbitmq_vhost": "/analytics",
    "rabbitmq_exchange": "actions",
    "rabbitmq_user": "actions",
    "rabbitmq_password": "c907781a43abaf1967863396b70419c2d9dab81b978aed69a6d07d197244977768df8ae86c403d9233688b3bc4c29b7d9f34"
  }
}

This file's config sends the Analytics system back to centos-6.3 to try authenticate using that Chef Server's oc_id service. It will use the uid field as the client_id field of the oauth call it makes back to that Chef Server. Both the Chef Server and the Analytics server must be configured to use the same uid / client_id, or the attempted auths will fail.

You can dig around in the following databases / tables on the two system types to try to repair the damage.

Notice specifically how the token column in the Analytics actions/authorizations table reflects the token found in the Chef Server's oc_id/oauth_access_tokens table.

Analytics

sudo su - chef-pgsql
bash
psql actions

actions=# select * from authorizations;                                                                                                                                                                                                              id                  |          expiration           |                              token                               |               user_id
--------------------------------------+-------------------------------+------------------------------------------------------------------+--------------------------------------
 9e679346-46f9-46ce-9b5c-cf6d6cf84ed5 | 2015-06-11 19:51:20.601325+00 | c549f92b155037c6b4f5242cd7b514d0bba627581d3d4e841d99bb117e23e50c | bf12fc41-8cea-4a1a-a6f4-e1a7a97fa7fb
(1 row)

actions=#

Chef Server

sudo su - opscode-pgsql
bash
psql oc_id

oc_id=# select * from oauth_access_tokens;
 id | resource_owner_id | application_id |                              token                               | refresh_token | expires_in | revoked_at |         created_at         | scopes
----+-------------------+----------------+------------------------------------------------------------------+---------------+------------+------------+----------------------------+--------
 33 | sean_horn         |              3 | c549f92b155037c6b4f5242cd7b514d0bba627581d3d4e841d99bb117e23e50c |               |       7200 |            | 2015-06-11 17:51:51.438681 |
(1 row)

oc_id=# select * from oauth_applications;
 id |   name    |                               uid                                |                              secret                              |         redirect_uri          |         created_at         |         update
d_at
----+-----------+------------------------------------------------------------------+------------------------------------------------------------------+-------------------------------+----------------------------+---------------
-------------
  3 | analytics | e63fb9b90fd1d0c7127d71c34da87e2cfbb512e58f2943b628d3301bd482eee9 | 18dbfcc146ca0a4fe6254d8481bde16e06f7242954dff901f85d0e20f27495ba | https://centos-6.5-analytics/ | 2015-06-11 17:41:44.081419 | 2015-06-11 17:
41:44.081419
(1 row)

oc_id=#

Nice Option

You may be able to repair any damage by just confirming actions-source.json is the same on both sides, and then reconfigure on both the Analytics and Chef Server systems. However, if you see the Analytics system trying to send a client_id back to the Chef Server that you know is not correct, then the oauth process will never work, and you need to move along to the....

Nuclear Option

If you get tired of digging around the above, you can do the following to cleanup and start over. This process will not destroy data the Analytics system has already collected.

1. On the Chef Server.

   In the oc_id database in the psql monitor

     delete from oauth_access_tokens;
     delete from oauth_applications;
   

2. Chef Server Reconfigure

      chef-server-ctl reconfigure
   

3. Chef Server Restart

      chef-server-ctl restart
   

4. Copy the newly generated /etc/opscode-analytics/actions-source.json over the same file on the Analytics system

5. On the Analytics Server

In the actions database in the psql monitor

      delete from authorizations;

6. Analytics Server Reconfigure

      opscode-analytics-ctl reconfigure
   

7. Analytics Server Restart

      opscode-analytics-ctl restart
   

8. Hit the Analytics Server webpage in a new browser again. You should be redirected to the Chef Server where you will need to reauthorize through oauth. If something weird happens, the logs will be in /var/opt/opscode/oc_id/current on the Chef Server.