Troubleshooting OpenStack Authentication and Networking

  • (4.0)

Troubleshooting OpenStack Authentication

The OpenStack Authentication service (Keystone) is a complex service, as it has to deal with underpinning the authentication and authorization for the complete cloud environment. Common problems include misconfigured endpoints, incorrect parameters being stored, and general user authentication issues, which involve resetting passwords or providing further details to the end user.

Getting started

Administrator access is required to troubleshoot Keystone, so we first, configure our environment, so that we can simply execute the relevant Keystone commands.

# Administrator Credentialsexport OS_USERNAME=adminexport OS_PASSWORD=openstack
export OS_AUTH_URL= export OS_TENANT_NAME=cookbook

How to achieve it…

Carry out the following steps when encountering the problems presented.

To gain in-depth knowledge and be on par with practical experience, then explore  OpenStack Training course.

Misconfigured endpoints

The Keystone is the central service that directs authenticated users to the correct service, so it’s vital that the users be sent to the correct location. Symptoms include HTTP 500 error messages in various logs regarding the services that are being accessed and clients timing out trying to connect to network services that don’t exist. To verify your endpoints in each region, perform the following command:

keystone endpoint-list

We can drill down into specific service types with the following command. For example, to show admin URL for the compute service type in all regions:

keystone endpoint-get --service compute --endpoint_type adminURL

An alternative to listing the endpoints in this format is to list the catalog, which outputs the details in a more human-readable way:

keystone catalog

This provides a convenient way of seeing the endpoints configured.

Authentication issues

From time to time, users will have trouble authenticating against Keystone due to forgotten or expired details or unexpected failure within the authentication system. Being able to identify such issues will allow you to restore service or allow the user to continue using the environment.
The first place to look will be the relevant logs. This includes the /var/log/nova logs, the /var/log/glance logs (if related to images), as well as the /var/log/keystone logs.
Troubleshooting accounts might include missing accounts, so view the users on the system using the following command:

keystone user-list

After displaying the user list to ensure an account exists for the user, we can get further information on a particular user by issuing, for example, the following command, after retrieving the user ID of a particular user:

keystone user-get 68ba544e500c40668435aa6201e557e4

This will display output similar to the following screenshot:

This allows us to verify that the user has a valid account in a particular tenant.
If a user’s password needs resetting, we can execute the following command after getting the user ID, to set a user’s password to (for example) openstack:

keystone user-password-update  --pass openstack  68ba544e500c40668435aa6201e557e4

If it turns out to be a user which has been set to disabled, we can simply re-enable the account with the following command:

keystone user-update --enabled true 68ba544e500c40668435aa6201e557e4

There could be times when the account is working, but problems exist on the client side. Before looking at Keystone for the issue, ensure your environment is set up correctly for the user account you are working with, in other words, set the following environment variables (example using a user called kevinj):

export OS_USERNAME=kevinjexport OS_PASSWORD=openstack 
export OS_AUTH_URL= 
export OS_TENANT_NAME=cookbook

Frequently Asked OpenStack Interview Question & Answers

How it works…

User authentication issues can be either client-side or server-side, and when some basic troubleshooting has occurred on the client, we can use Keystone commands to find out why someone’s user journey has been interrupted. With this, we are able to view and update user details, set passwords, set them into the appropriate tenants, and disable or enable them, as required.

Troubleshooting OpenStack Networking

Network troubleshooting can be hard. Network troubleshooting in a complex distributed system like OpenStack can be even harder
OpenStack Networking is now a complex service with the introduction of Neutron, as it now gives users the ability to define and create their own networking within their cloud environment. Common problems for an OpenStack administrator include misconfigured Neutron installations, routing problems and switch plugin problems. Problems for users include misunderstanding the capabilities of Neutron or limitations imposed by administrators.

Getting started

We’ll be troubleshooting Neutron installations so administrator access is required to troubleshoot this service. Ensure you’re logged in as root on our controller, compute, and network hosts and configure our environment to enable us to run various commands.
To log into our hosts that were created using Vagrant issue the following in separate shells:

vagrant ssh controller 
vagrant ssh compute 
vagrant ssh network

In our Controller and Network host sessions, as root, issue the following:

# Administrator Credentialsexport OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL= 
export OS_TENANT_NAME=cookbook

How to achieve it…

Carry out the following steps when encountering the problems presented.

Cloud-init reporting Connection Refused when accessing Metadata

In an instance’s console log (when you issue nova console-log INSTANCE_ID) you may see lines such as:There are a number of possibilities for this, but the result will be the same and we will be unable to log into our cloud instance because the instance was unable to have its SSH key injected into it.
Check that you have configured our physical interfaces on our network and compute nodes for use with OVS. As part of the installation and configuration, ensure that you have run the following command:

ovs-vsctl add-port br-eth1 eth1

Where eth1 is our physical interface and br-eth1 is the bridge created on this interface.
Check that your instance can route to the metadata host from the gateway of the instance, and if not create a route to this network. When subnets are created and a gateway is specified, it is assumed that this gateway address can route to the address. If it can’t, you will see errors described in the sections as we saw. To create a route on the instance itself, create the subnet with the following options:

quantum subnet-create demoNet1 
--name snet1  --no-gateway 
--host_routes type=dict list=true  destination=,nexthop=  --allocation-pool start=,end=

By specifying –no- gateway, Neutron will inject the route into the instance so it shows up in the instance routing table, but to provide a default gateway, we specify a destination of and if appropriate the next hop in the route to allow that instance to access elsewhere.

Explore OpenStack Sample Resumes! Download & Edit, Get Noticed by Top Employers!  Download Now!


Related Pages:


Popular Courses in 2018

Get Updates on Tech posts, Interview & Certification questions and training schedules