This documentation is sufficient to work with the following versions
Chef Server: 12.0.8
Analytics: 1.1.x
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.
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.
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=#
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=#
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....
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.
-
On the Chef Server.
In the
oc_id
database in the psql monitordelete from oauth_access_tokens; delete from oauth_applications;
-
Chef Server Reconfigure
chef-server-ctl reconfigure
-
Chef Server Restart
chef-server-ctl restart
-
Copy the newly generated
/etc/opscode-analytics/actions-source.json
over the same file on the Analytics system -
On the Analytics Server
In the actions
database in the psql monitor
delete from authorizations;
-
Analytics Server Reconfigure
opscode-analytics-ctl reconfigure
-
Analytics Server Restart
opscode-analytics-ctl restart
-
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.