Ask Your Question
1

nova network-create fails with "401 Unauthorized" [closed]

asked 2013-09-18 02:57:35 -0500

Stuart Longland gravatar image

updated 2013-09-18 03:03:44 -0500

Riddle me this.

I've set up a collection of Ansible PlayBooks to deploy OpenStack. I've sanitised the configurations and placed them at http://git.longlandclan.yi.org/?p=openstack-ansible.git if people want to take a look. In particular, the README there contains some further detail as to what I'm attempting to achieve.

The playbooks are based on the OpenStack user guide, with some steps taken from the HA guide.

Now, the install guide for Ubuntu 12.04 tells me after performing a number of steps with Nova, to create the private VM network using the following command:

nova network-create private --fixed-range-v4=192.168.100.0/24 --bridge-interface=br100

My management node reports the following:

root@node:~# nova network-create private --fixed-range-v4=192.168.100.0/24 --bridge-interface=br100
ERROR: You must provide a username via either --os-username or env[OS_USERNAME]

So I try adding in credentials...

root@node:~# nova --os-username adminuser --os-password adminpassword --os-auth-url http://keystonehost:35357/v2.0/ --os-tenant-name admin_tenant --os-region-name RegionOne network-create private --fixed-range-v4=10.20.30.40/24 --bridge-interface=br100
ERROR: Unauthorized (HTTP 401)

I've tried variations on the above theme, trying a log-in as 'nova' for example, different port number, different tenants. Each time I get told: Unauthorized. Now, my /etc/nova/nova.conf has the following settings:

[DEFAULT]
auth_strategy = keystone

[keystone_authtoken]
auth_host = keystonehost
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = nova
signing_dirname = /tmp/keystone-signing-nova

What did I miss? Is there something else I need to configure in order to get Nova and Keystone communicating?

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by koolhead17
close date 2014-06-05 09:00:25.819319

2 answers

Sort by ยป oldest newest most voted
0

answered 2013-09-25 00:46:36 -0500

Stuart Longland gravatar image

updated 2013-09-25 00:49:29 -0500

Okay, seems this is an omission in the documentation. To locate the problem, I tried running the following:

tcpdump -i lo -s 0 -A port 35357

and watching as I tried the nova command again. Sure enough, I saw the request that was being put in, and the one that was coming out, nova was logging in as the non-existant user %SERVICE_USER%...

Host: 127.0.0.1:35357
Accept-Encoding: identity
Content-Length: 138
Content-type: application/json
Accept: application/json

{"auth": {"tenantName": "%SERVICE_TENANT_NAME%", "passwordCredentials": {"username": "%SERVICE_USER%", "password": "%SERVICE_PASSWORD%"}}}
15:33:17.687775 IP 127.0.0.1.35357 > 127.0.0.1.59112:

...A grep revealed the file, /etc/nova/api-paste.ini needed to be updated (something I did not spot in the documentation).

So if people observe the above, first try a tcpdump on the port where keystone is listening, see what the service is attempting to log in as, then do a grep for that user in your /etc directory, and you'll possibly spot it, and other locations where configuration was missed.

edit flag offensive delete link more
0

answered 2013-11-18 08:33:10 -0500

This is a great way for debugging! Thanks a lot!

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-09-18 02:57:35 -0500

Seen: 909 times

Last updated: Nov 18 '13