RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1050842 - neutron should not specify signing_dir in neutron-dist.conf
Summary: neutron should not specify signing_dir in neutron-dist.conf
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-neutron
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Ihar Hrachyshka
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks: 1050962
TreeView+ depends on / blocked
 
Reported: 2014-01-09 08:40 UTC by Matthias Runge
Modified: 2016-03-30 23:02 UTC (History)
9 users (show)

Fixed In Version: openstack-neutron-2013.2.3-2.el6
Clone Of:
: 1050962 (view as bug list)
Environment:
Last Closed: 2016-03-30 23:02:39 UTC
Embargoed:


Attachments (Terms of Use)

Description Matthias Runge 2014-01-09 08:40:00 UTC
Description of problem:

I installed via packstack in fedora 20.
After sourcing keystonerc_admin, neutron still complains about missing authentication.


Version-Release number of selected component (if applicable):
rpm -q openstack-neutron
openstack-neutron-2014.1-0.1.b1.fc21.noarch


How reproducible:
100%

Steps to Reproduce:
1. # . ./keystonerc_admin 
2. nova image-list
+----+------+--------+--------+
| ID | Name | Status | Server |
+----+------+--------+--------+
+----+------+--------+--------+

3. # neutron subnet-list
Authentication required


Actual results:
Authentication required

Expected results:
List of subnets

Additional info:

I think it may be connected with the following issue from neutron-server log:
2014-01-09 09:37:51.247 2315 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 127.0.0.1
2014-01-09 09:37:51.317 2315 WARNING keystoneclient.middleware.auth_token [-] Verify error: Command 'openssl' returned non-zero exit status 4
2014-01-09 09:37:51.318 2315 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token 0fc5a67eeb09cb154c04f68255a622c7
2014-01-09 09:37:51.318 2315 INFO keystoneclient.middleware.auth_token [-] Invalid user token - rejecting request
2014-01-09 09:37:51.320 2315 INFO neutron.wsgi [-] 127.0.0.1 - - [09/Jan/2014 09:37:51] "GET /v2.0/subnets.json HTTP/1.1" 401 192 0.077199

rpm -q openssl
openssl-1.0.1e-36.fc20.x86_64

Comment 1 Matthias Runge 2014-01-09 09:02:13 UTC
ah, I'm using PKI token

and 
[root@turing ~(keystone_admin)]# neutron --debug subnet-list
Authentication required
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/neutronclient/shell.py", line 517, in run_subcommand
    return run_command(cmd, cmd_parser, sub_argv)
  File "/usr/lib/python2.7/site-packages/neutronclient/shell.py", line 78, in run_command
    return cmd.run(known_args)
  File "/usr/lib/python2.7/site-packages/neutronclient/common/command.py", line 35, in run
    return super(OpenStackCommand, self).run(parsed_args)
  File "/usr/lib/python2.7/site-packages/cliff/display.py", line 84, in run
    column_names, data = self.take_action(parsed_args)
  File "/usr/lib/python2.7/site-packages/neutronclient/common/command.py", line 41, in take_action
    return self.get_data(parsed_args)
  File "/usr/lib/python2.7/site-packages/neutronclient/neutron/v2_0/__init__.py", line 586, in get_data
    data = self.retrieve_list(parsed_args)
  File "/usr/lib/python2.7/site-packages/neutronclient/neutron/v2_0/__init__.py", line 555, in retrieve_list
    data = self.call_server(neutron_client, search_opts, parsed_args)
  File "/usr/lib/python2.7/site-packages/neutronclient/neutron/v2_0/__init__.py", line 527, in call_server
    data = obj_lister(**search_opts)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 108, in with_params
    ret = self.function(instance, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 351, in list_subnets
    **_params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1197, in list
    for r in self._pagination(collection, path, **params):
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1210, in _pagination
    res = self.get(path, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1183, in get
    headers=headers, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request
    headers=headers, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request
    resp, replybody = self.httpclient.do_request(action, method, body=body)
  File "/usr/lib/python2.7/site-packages/neutronclient/client.py", line 192, in do_request
    self.endpoint_url + url, method, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutronclient/client.py", line 156, in _cs_request
    raise exceptions.Unauthorized(message=body)
Unauthorized: Authentication required

Comment 2 Kashyap Chamarthy 2014-01-09 09:06:07 UTC
Matthias,

It'd also be useful to add any other related snippets in

  - /var/log/keystone.log
  - /var/log/neutron/server/log

Comment 3 Matthias Runge 2014-01-09 09:10:32 UTC
keystone log:
tons of messages like 
2014-01-09 10:06:27.081 16281 WARNING keystone.common.utils [-] Deprecated: v2 API is deprecated as of Icehouse in favor of v3 API and may be removed in K.

(I wonder if that's related at all)

and the interesting snippet from neutron server log is posted in above:
That's the log produced, when running neutron subnet-list

Comment 4 Jamie Lennox 2014-01-09 11:43:07 UTC
the deprecation warning isn't related.

Can you check the auth_token parts of the neutron config file? Specifically have a look to see where the signing_dir is set. This is where the PKI certificates are saved. Make sure that they have been downloaded and is accessible (that would indicate that the auth_url is set correctly).

If it's reproducable and you are willing to hack around with things have a look at keystoneclient/common/cms.py:101 cms_verify function. you can see the openssl command that is generated to verify the PKI token. If you log that command you should be able to run it yourself and maybe see why the process is failing.

Comment 5 Matthias Runge 2014-01-09 11:52:31 UTC
[keystone_authtoken]
# auth_host = 127.0.0.1
auth_host = 127.0.0.1
# auth_port = 35357
auth_port = 35357
# auth_protocol = http
auth_protocol = http
# admin_tenant_name = %SERVICE_TENANT_NAME%
admin_tenant_name = services
# admin_user = %SERVICE_USER%
admin_user = neutron
# admin_password = %SERVICE_PASSWORD%
admin_password = a0684557452e407e
# signing_dir = $state_path/keystone-signing
auth_uri=http://127.0.0.1:5000/

Comment 6 Matthias Runge 2014-01-09 12:01:08 UTC
setting signing dir = /tmp fixes this issue

from my logs,  /var/lib/neutron/keystone-signing was used earlier, when it didn't work

Comment 7 Alan Pevec 2014-01-09 12:36:08 UTC
There's bad value set in neutron-dist.conf:

signing_dir = $state_path/keystone-signing

http://pkgs.fedoraproject.org/cgit/openstack-neutron.git/tree/neutron-dist.conf#n21

This should be removed to let default from keystoneclient/authtoken apply.

Comment 8 Matthias Runge 2014-01-09 12:39:52 UTC
I can confirm, removing that lins from neutron-dist.conf makes it work, and I didn't define signing_dir in /etc/neutron/neutron.conf

Comment 9 flybirding 2014-01-27 02:41:54 UTC
I have encountered this problem too, when I want to build two controllers for HA.

Comment 10 Ihar Hrachyshka 2014-04-03 12:29:25 UTC
Tried to reproduce the issue:
- installed fedora 20;
- installed openstack-packstack;
- run packstack --gen-answer-file=answers.txt;
- set CONFIG_QPID_ENABLE_AUTH = y;
- run packstack --answer-file=answers.txt;

- hit bug 1066112, so applied workaround:
> $ sudo touch /var/log/mysqld.log
> $ sudo chown mysql:mysql /var/log/mysqld.log
> $ sudo chcon system_u:object_r:mysqld_log_t:s0 /var/log/mysqld.log
- restarted packstack --answer-file=answers.txt;

- once packstack installation is done, sourced keystonerc_admin file and issued 'neutron subnet-list' with no issues. (empty output, echo $? == 0)

Comment 11 Matthias Runge 2014-04-03 14:40:15 UTC
Ihar, 

when using environment variables for authentication: is that the same as using client libraries via keystone token? 

Horizon gets a token from keystone and passes that token to neutron. I *believe*, when providing username and password via env. variables, neutron handles all that auth stuff. That sounds significantly different to me.

Comment 12 Ihar Hrachyshka 2014-04-03 14:51:57 UTC
The same applies here: neutronclient (which is represented by 'neutron' binary) gets a token from keystone and passes that token to neutron (which is represented by 'neutron-server' binary).

Comment 13 Pádraig Brady 2014-04-27 22:35:00 UTC
I see the default /etc/neutron/neutron.conf has always had a signing_dir specified. I'm guessing that that was replaced by puppet rewriting neutron.conf ?
So for sane defaults without puppet involved, it seems like we should remove this value from the default neutron.conf also, and provide an equivalent patch upstream?


Note You need to log in before you can comment on or make changes to this bug.