Installation of OpenStack
The steps in the later part of the chapter document the installation of OpenStack services, including Keystone, Glance, Nova Compute, and Horizon, on a single controller and compute node. Neutron, the OpenStack Networking service, will be installed in the next chapter.
Installing and configuring the MySQL database server
On the controller node, use yum to install the MySQL database server:
# yum -y install mysql mysql-server MySQL-python
Once installed, set the IP address that MySQL will bind to by editing the /etc/my.cnf configuration file and adding the bind-address definition. Doing so will allow connectivity to MySQL from other hosts in the environment. The value for bind-address should be the management IP of the controller node:
# crudini --set /etc/my.cnf mysqld bind-address 10.254.254.100
Start the mysqld process, and configure it to start at boot:
# service mysqld start # chkconfig mysqld on
The MySQL secure installation utility is used to build the default MySQL database and set a password for the MySQL root user. The following command will begin the MySQL installation and configuration process:
# mysql_secure_installation
During the MySQL installation process, you will be prompted to enter a password and change various settings. For this installation, the chosen root password is openstack. A more secure password suitable for your environment is highly recommended.
Answer [Y]es to the remaining questions to exit the configuration process. At this point, MySQL server has been successfully installed on the controller node.
Installing the MySQL database client
The compute nodes in the environment should be configured as MySQL clients rather than as MySQL servers. On compute01, install the MySQL client as follows:
# yum -y install mysql MySQL-python
Installing and configuring the messaging server
Advanced Message Queue Protocol (AMQP) is the messaging technology chosen for use with an OpenStack-based cloud. Components such as Nova, Cinder, and Neutron communicate internally via AMQP and to each other using API calls. The following are instructions to install Qpid, an AMQP broker. Popular alternatives include RabbitMQ and ZeroMQ.
On the controller node, install the messaging server:
# yum -y install qpid-cpp-server memcached
To simplify this installation, disable Qpid authentication by editing the /etc/qpidd.conf file and changing the auth option to no, as follows:
# sed -i "/^auth/s/auth=yes/auth=no/" /etc/qpidd.conf
Tip
While disabling authentication is acceptable for this test environment, authentication should be enabled on a production deployment. Consult Qpid documentation for further instructions on how to enable authentication.
Start the qpid service, and set it to automatically start at boot:
# service qpidd start # chkconfig qpidd on
Installing and configuring the Identity service
Keystone is the Identity service for OpenStack and is used to authenticate and authorize users and services in the OpenStack cloud. Keystone should only be installed on the controller node along with python-keystoneclient:
# yum -y install openstack-keystone python-keystoneclient
Using crudini, configure Keystone to use MySQL as its database. In this installation, the username and password will be keystone:
# crudini --set /etc/keystone/keystone.conf sql connection mysql://keystone:keystone@controller/keystone
Tip
Insecure passwords are used throughout the book to simplify the configuration and are not recommended for production use. Visit http://www.strongpasswordgenerator.org to generate strong passwords for your environment.
Use the openstack-db command to create the Keystone database, related tables, and a database user named keystone that will be used by the Keystone service to connect to the database:
# openstack-db --init --service keystone --password keystone
You may be prompted to enter the password for the MySQL root user. Unless it has been changed, this installation set the MySQL root password to openstack.
Define an authorization token to use as a shared secret between Keystone and other OpenStack services. When defined, the authorization token, admin_token, can be used to make changes to Keystone in the event an administrative user has not been configured or the password has been forgotten. Clients making calls to Keystone can pass the authorization token, which is then validated by Keystone before actions are taken.
OpenSSL can be used to generate a random token and store it in the configuration file:
# ADMIN_TOKEN=$(openssl rand -hex 10) # crudini --set /etc/keystone/keystone.conf DEFAULT admin_token $ADMIN_TOKEN
By default, Keystone uses PKI tokens for authentication. The following steps will create the signing keys and certificates:
# keystone-manage pki_setup --keystone-user keystone --keystone-group keystone # chown -R keystone:keystone /etc/keystone/* /var/log/keystone/keystone.log
Using crudini, edit /etc/keystone/keystone.conf, and set the provider value to PKI:
# crudini --set /etc/keystone/keystone.conf token provider keystone.token.providers.pki.Provider
Start the Keystone service and enable it to start at boot time by entering the following command:
# service openstack-keystone start # chkconfig openstack-keystone on
Defining users, tenants, and roles in Keystone
Once the installation of Keystone is complete, it is necessary to set up users, tenants, roles, and endpoints that will be used by various OpenStack services.
Typically, a username and password are used to authenticate against Keystone. But because users have not yet been created, it is necessary to use the authorization token created earlier. The token can be passed using the --os-token option of the keystone command or by setting the OS_SERVICE_TOKEN environment variable. We will use both the OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT environment variables to provide the authorization token and to specify where the Keystone service is running.
Use the export command to export the variables and their values to your environment. OS_SERVICE_TOKEN should be set to the $ADMIN_TOKEN value determined earlier:
# export OS_SERVICE_TOKEN=$ADMIN_TOKEN # export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0
In Keystone, a tenant represents a logical group of users to which resources are assigned. Resources are assigned to tenants and not directly to users. Create an admin tenant for the administrative user and a service tenant for other OpenStack services to use as follows:
# keystone tenant-create --name=admin --description="Admin Tenant" # keystone tenant-create --name=service --description="Service Tenant"
Additional tenants can be created later for other users of the cloud. Next, create an administrative user called admin. Specify a secure password and an email address for the admin user as follows:
# keystone user-create --name=admin --pass=secrete --email=admin@learningneutron.com
Once the admin user has been created, create a role for administrative tasks called admin:
# keystone role-create --name=admin
Any roles that are created should map to roles specified in the policy.json files of the corresponding OpenStack services. The default policy files use the admin role to allow access to services. For more information on user management in Keystone, please refer to the following URL: http://docs.openstack.org/admin-guide-cloud/content/keystone-user-management.html.
Finally, associate the admin role to the admin user when logging in with the admin tenant as follows:
# keystone user-role-add --user=admin --tenant=admin --role=admin
Define services and API endpoints in Keystone
Each OpenStack service that is installed should be registered with Keystone, so its location on the network can be tracked. There are two commands involved in registering a service:
keystone service-create: This describes the service that is being createdkeystone endpoint-create: This associates API endpoints with the service
Keystone itself is among the services that must be registered. You can create a service entry for Keystone with the following command:
# keystone service-create --name=keystone --type=identity --description="Keystone Identity Service"
The resulting output will be in table format and will include a unique ID that will be used in the subsequent command:
+-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Keystone Identity Service | | id | 47b36f2684e94cfdbd78ba912e6091ec | | name | keystone | | type | identity | +-------------+----------------------------------+
Next, you can specify an API endpoint for the Identity service using the returned ID. When specifying an endpoint, you must provide URLs for the public API, internal API, and the admin API. The three URLs can potentially be on three different IP networks depending on your network setup and if NAT is used. The short name of the controller will be used to populate the URLs. Each host can reference the other based on hostname via DNS or the local /etc/hosts entries created earlier. Have a look at the following commands:
# keystone endpoint-create \ --service-id=`keystone service-get keystone | awk '/ id / { print $4 }'` \ --publicurl=http://controller:5000/v2.0 \ --internalurl=http://controller:5000/v2.0 \ --adminurl=http://controller:35357/v2.0
The resulting output is as follows:
+-------------+-----------------------------------+ | Property | Value | +-------------+-----------------------------------+ | adminurl | http://controller:35357/v2.0 | | id | 7c1112c14cd8494fbd8dadb09581926f| | internalurl | http://controller:5000/v2.0 | | publicurl | http://controller:5000/v2.0 | | region | regionOne | | service_id | 47b36f2684e94cfdbd78ba912e6091ec| +-------------+-----------------------------------+
Verify the Keystone installation
To verify that Keystone was installed and configured properly, use the unset command to unset the OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT environment variables. Those variables are only needed to bootstrap the administrative user and to register the Keystone service. Have a look at the following command:
# unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT
Once the environment variables are unset, it should be possible to use username-based authentication. You can request an authentication token using the admin user and the password specified earlier:
# keystone --os-username=admin --os-password=secrete --os-auth-url=http://controller:35357/v2.0 token-get
Keystone should respond with a token that is paired with the specified user ID. This verifies that the user account is established in Keystone with the expected credentials. The resulting output is as follows:
+-----------+----------------------------------+ | Property | Value | +-----------+----------------------------------+ | expires | 2014-07-25T00:45:46Z | | id | <Base64-encoded Token> | user_id | 6d8b854881ff4568a22342fae7cc4df6 | +-----------+----------------------------------+
Next, you can verify that authorization is working as expected by requesting authorization for a tenant:
# keystone --os-username=admin --os-password=secrete --os-tenant-name=admin --os-auth-url=http://controller:35357/v2.0 token-get
You should receive a new token in response, this time including the tenant ID of the admin tenant. This verifies that your user account has an explicitly defined role in the specified tenant and that the tenant exists as expected.
Setting environment variables
To avoid having to provide credentials every time you run an OpenStack command, create a file containing environment variables that can be loaded at any time:
# mkdir ~/credentials # cat >> ~/credentials/admin <<EOF export OS_USERNAME=admin export OS_PASSWORD=secrete export OS_TENANT_NAME=admin export OS_AUTH_URL=http://controller:35357/v2.0 EOF
Use the source command to load the environment variables from the file. To test Keystone, issue the following commands:
# source ~/credentials/admin # keystone token-get # keystone user-list
Keystone should return the token and user list as requested as follows:
Installing and configuring the image service
Glance is the image service for OpenStack. It is responsible for storing images and snapshots of instances and for providing images to compute nodes when instances are created.
To install Glance, run the following command from the controller node:
# yum -y install openstack-glance
You can use openstack-db to initialize the Glance database and add the glance user to MySQL:
# openstack-db --init --service glance --password glance
Use crudini to set the SQL connection string in the Glance configuration files:
# crudini --set /etc/glance/glance-api.conf DEFAULT sql_connection mysql://glance:glance@controller/glance # crudini --set /etc/glance/glance-registry.conf DEFAULT sql_connection mysql://glance:glance@controller/glance
You can then add the glance user to Keystone and create the appropriate role:
# keystone user-create --name=glance --pass=glance --email=glance@learningneutron.com # keystone user-role-add --user=glance --tenant=service --role=admin
Use crudini to set Keystone attributes in the Glance configuration files:
# crudini --set /etc/glance/glance-api.conf keystone_authtoken auth_host controller # crudini --set /etc/glance/glance-api.conf keystone_authtoken admin_user glance # crudini --set /etc/glance/glance-api.conf keystone_authtoken admin_tenant_name service # crudini --set /etc/glance/glance-api.conf keystone_authtoken admin_password glance # crudini --set /etc/glance/glance-registry.conf keystone_authtoken auth_host controller # crudini --set /etc/glance/glance-registry.conf keystone_authtoken admin_user glance # crudini --set /etc/glance/glance-registry.conf keystone_authtoken admin_tenant_name service # crudini --set /etc/glance/glance-registry.conf keystone_authtoken admin_password glance
Glance includes default configuration files that should be copied and modified as follows:
# cp /usr/share/glance/glance-api-dist-paste.ini /etc/glance/glance-api-paste.ini # cp /usr/share/glance/glance-registry-dist-paste.ini /etc/glance/glance-registry-paste.ini
Each of the files mentioned in the preceding commands must then be edited to add the following options:
# crudini --set /etc/glance/glance-api-paste.ini filter:authtoken auth_host controller # crudini --set /etc/glance/glance-api-paste.ini filter:authtoken admin_user glance # crudini --set /etc/glance/glance-api-paste.ini filter:authtoken admin_tenant_name service # crudini --set /etc/glance/glance-api-paste.ini filter:authtoken admin_password glance # crudini --set /etc/glance/glance-api-paste.ini filter:authtoken flavor keystone # crudini --set /etc/glance/glance-registry-paste.ini filter:authtoken auth_host controller # crudini --set /etc/glance/glance-registry-paste.ini filter:authtoken admin_user glance # crudini --set /etc/glance/glance-registry-paste.ini filter:authtoken admin_tenant_name service # crudini --set /etc/glance/glance-registry-paste.ini filter:authtoken admin_password glance # crudini --set /etc/glance/glance-registry-paste.ini filter:authtoken flavor keystone
You can start the Glance services and enable them to start at boot time with the following command:
# service openstack-glance-api start # service openstack-glance-registry start # chkconfig openstack-glance-api on # chkconfig openstack-glance-registry on
Define the Glance service and API endpoints in Keystone
Like other OpenStack services, Glance should be added to the Keystone database using the service-create and endpoint-create commands:
# keystone service-create --name=glance --type=image --description="Glance Image Service"
The resulting output is as follows:
+-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Glance Image Service | | id | bbbacfbe630341b181659f00a2ef6a90| | name | glance | | type | image | +-------------+----------------------------------+
The id value here should be used to populate the service-id value as follows:
# keystone endpoint-create \ --service-id=`keystone service-get glance | awk '/ id / { print $4 }'` \ --publicurl=http://controller:9292 \ --internalurl=http://controller:9292 \ --adminurl=http://controller:9292
The resulting output is as follows:
+-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | adminurl | http://controller:9292 | | id | 32504596c4cc4661a04adbf1dfb97c08| | internalurl | http://controller:9292 | | publicurl | http://controller:9292 | | region | regionOne | | service_id | bbbacfbe630341b181659f00a2ef6a90| +-------------+----------------------------------+
Verify the Glance image service installation
To verify that Glance was installed and configured properly, download a test image from the Internet, and verify that it can be uploaded to the image server:
# mkdir /var/tmp/images ; cd /var/tmp/images/ # wget http://cdn.download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img
Upload the image to Glance using the following command:
# glance image-create --name=CirrOS-0.3.1 --disk-format=qcow2 --container-format=bare --is-public=true --file /var/tmp/images/cirros-0.3.1-x86_64-disk.img
Verify that the image exists in Glance using the image-list command. Have a look at the following screenshot:
The CirrOS image is very limited in functionality and is recommended only for testing connectivity and operational Compute functionality. Multiple vendors provide cloud-ready images for use with OpenStack as follows:
- Ubuntu cloud images: http://cloud-images.ubuntu.com/
- Red Hat-based images: http://openstack.redhat.com/Image_resources
To install an image from a remote location, use the --location parameter instead of --file as follows:
# glance image-create --name=Ubuntu-14.04 --disk-format=qcow2 --container-format=bare --is-public=true --location http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
Another look at the image list (in the following screenshot) shows the new images are available for use:
Installing and configuring the Compute service
OpenStack Compute is a collection of services that enable cloud operators and tenants to launch virtual machine instances. Most services run on the controller node, with the exception of the openstack-nova-compute service, which runs on the compute nodes and is responsible for launching the virtual machine instances.
Installing and configuring controller node components
Install the openstack-nova package, which installs various Nova (Compute) services that are used on the controller node, as follows:
# yum -y install openstack-nova python-novaclient
Run the openstack-db command to initialize and create the Nova (Compute) service database, related tables, and MySQL user as follows:
# openstack-db --init --service nova --password nova
Use crudini to configure Nova Compute to use MySQL as its database as follows:
# crudini --set /etc/nova/nova.conf database connection mysql://nova:nova@controller/nova
Set these configuration keys to configure Nova (Compute) to use the Qpid message broker:
# crudini --set /etc/nova/nova.conf DEFAULT rpc_backend nova.openstack.common.rpc.impl_qpid # crudini --set /etc/nova/nova.conf DEFAULT qpid_hostname controller
The VNC Proxy is an OpenStack component that allows users to access their instances through VNC clients. VNC stands for Virtual Network Computing, and is a graphical desktop sharing system that uses the Remote Frame Buffer protocol to control another computer over a network. The controller must be able to communicate with compute nodes for VNC services to work properly through the Horizon dashboard or other VNC clients.
Use crudini to set the my_ip, vncserver_listen and vncserver_proxyclient_address configuration options to the management IP address of the controller node:
# crudini --set /etc/nova/nova.conf DEFAULT my_ip 10.254.254.100 # crudini --set /etc/nova/nova.conf DEFAULT vncserver_listen 10.254.254.100 # crudini --set /etc/nova/nova.conf DEFAULT vncserver_proxyclient_address 10.254.254.100
Create a user called nova in Keystone that the Nova (Compute) service will use for authentication. After this, place the user in the service tenant, and give the user the admin role:
# keystone user-create --name=nova --pass=nova --email=nova@learningneutron.com # keystone user-role-add --user=nova --tenant=service --role=admin
Configure Nova (Compute) to use the following Keystone credentials:
# crudini --set /etc/nova/nova.conf DEFAULT auth_strategy keystone # crudini --set /etc/nova/nova.conf keystone_authtoken auth_host controller # crudini --set /etc/nova/nova.conf keystone_authtoken auth_protocol http # crudini --set /etc/nova/nova.conf keystone_authtoken auth_port 35357 # crudini --set /etc/nova/nova.conf keystone_authtoken admin_user nova # crudini --set /etc/nova/nova.conf keystone_authtoken admin_tenant_name service # crudini --set /etc/nova/nova.conf keystone_authtoken admin_password nova
Credentials must be added to the /etc/nova/api-paste.ini file that corresponds to the details of this build. These options should be added to the [filter:authtoken] section of the ini file:
# crudini --set /etc/nova/api-paste.ini filter:authtoken auth_host controller # crudini --set /etc/nova/api-paste.ini filter:authtoken auth_port 35357 # crudini --set /etc/nova/api-paste.ini filter:authtoken auth_protocol http # crudini --set /etc/nova/api-paste.ini filter:authtoken auth_uri http://controller:5000/v2.0 # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_tenant_name service # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_user nova # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_password nova
You can ensure that the api_paste_config=/etc/nova/api-paste.ini option is set in the /etc/nova/nova.conf file using the following command:
# crudini --set /etc/nova/nova.conf DEFAULT api_paste_config /etc/nova/api-paste.ini
You should then register Nova (Compute) with the Identity service so that other OpenStack services can locate it. Register the service and specify the endpoint:
# keystone service-create --name=nova --type=compute --description="Nova Compute service"
The resulting output should resemble the following:
+-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Nova Compute service | | id | a946cbd06a124ec39662622cc2d6e4ec| | name | nova | | type | compute | +-------------+----------------------------------+
Use the id property that is returned to create the endpoint:
# keystone endpoint-create \ --service-id=`keystone service-get nova | awk '/ id / { print $4 }'` \ --publicurl=http://controller:8774/v2/%\(tenant_id\)s \ --internalurl=http://controller:8774/v2/%\(tenant_id\)s \ --adminurl=http://controller:8774/v2/%\(tenant_id\)s
Start the Nova (Compute) services, and configure them to start when the system boots:
# service openstack-nova-api start # service openstack-nova-cert start # service openstack-nova-consoleauth start # service openstack-nova-scheduler start # service openstack-nova-conductor start # service openstack-nova-novncproxy start # service openstack-nova-console start # chkconfig openstack-nova-api on # chkconfig openstack-nova-cert on # chkconfig openstack-nova-consoleauth on # chkconfig openstack-nova-scheduler on # chkconfig openstack-nova-conductor on # chkconfig openstack-nova-novncproxy on # chkconfig openstack-nova-console on
Tip
The openstack-nova-network service will be installed as part of the openstack-nova package but should not be started. The openstack-nova-network service is the legacy networking service replaced by Neutron. Neutron will be installed in Chapter 3, Installing Neutron.
Installing and configuring compute node components
Once the Nova (Compute) services have been configured on the controller node, another host must be configured as a compute node. The compute node receives requests from the controller node to host virtual machine instances. Separating the services by running dedicated compute nodes means that Nova (Compute) can be scaled horizontally by adding additional compute nodes once all available resources have been utilized.
On the compute node, install the openstack-nova-compute package. This package provides virtualization services to the compute node:
# yum -y install openstack-nova-compute
Using crudini, edit the /etc/nova/nova.conf configuration file to specify MySQL as the database and configure various Keystone authentication settings. The nova keystone user was configured in the previous section. Have a look at the following commands:
# crudini --set /etc/nova/nova.conf database connection mysql://nova:nova@controller/nova # crudini --set /etc/nova/nova.conf DEFAULT auth_strategy keystone # crudini --set /etc/nova/nova.conf keystone_authtoken auth_host controller # crudini --set /etc/nova/nova.conf keystone_authtoken auth_protocol http # crudini --set /etc/nova/nova.conf keystone_authtoken auth_port 35357 # crudini --set /etc/nova/nova.conf keystone_authtoken admin_user nova # crudini --set /etc/nova/nova.conf keystone_authtoken admin_tenant_name service # crudini --set /etc/nova/nova.conf keystone_authtoken admin_password nova
Next, configure Nova (Compute) to use the Qpid messaging broker configured on the controller node:
# crudini --set /etc/nova/nova.conf DEFAULT rpc_backend nova.openstack.common.rpc.impl_qpid # crudini --set /etc/nova/nova.conf DEFAULT qpid_hostname controller
Then configure Nova (Compute) to provide remote console access to instances through a proxy on the controller node. The remote console is accessible through the Horizon dashboard. The IP configured as follows should be the management IP of the compute node:
# crudini --set /etc/nova/nova.conf DEFAULT my_ip 10.254.254.101 # crudini --set /etc/nova/nova.conf DEFAULT vnc_enabled True # crudini --set /etc/nova/nova.conf DEFAULT vncserver_listen 0.0.0.0 # crudini --set /etc/nova/nova.conf DEFAULT vncserver_proxyclient_address 10.254.254.101 # crudini --set /etc/nova/nova.conf DEFAULT novncproxy_base_url http://controller:6080/vnc_auto.html
Specify the host that runs the Glance image service. In this installation, Glance runs on the controller node:
# crudini --set /etc/nova/nova.conf DEFAULT glance_host controller
Edit the /etc/nova/api-paste.ini configuration to add credentials to the [filter:authtoken] section:
# crudini --set /etc/nova/api-paste.ini filter:authtoken auth_host controller # crudini --set /etc/nova/api-paste.ini filter:authtoken auth_port 35357 # crudini --set /etc/nova/api-paste.ini filter:authtoken auth_protocol http # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_tenant_name service # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_user nova # crudini --set /etc/nova/api-paste.ini filter:authtoken admin_password nova
Ensure that the api_paste_config=/etc/nova/api-paste.ini option is set in the /etc/nova/nova.conf file:
# crudini --set /etc/nova/nova.conf DEFAULT api_paste_config /etc/nova/api-paste.ini
Start the Nova (Compute) service and configure it to start when the system boots:
# service libvirtd start # service messagebus start # service openstack-nova-compute start # chkconfig libvirtd on # chkconfig messagebus on # chkconfig openstack-nova-compute on
Verify communication between services
To check the status of Nova services throughout the environment, use the Nova service-list command on the controller node as follows:
# nova service-list
The command should return statuses on all Nova services that have checked in:
In the above output, the state of the services on both the controller and compute nodes are reflected under the Status column. The nova service-list command can be run on any node in the environment but will require proper authentication credentials. If there are inconsistencies in the output among multiple nodes, it's worth ensuring that network time (NTP) is synchronized properly on all nodes.
Installing the OpenStack dashboard
The OpenStack Dashboard, also known as Horizon, provides a web-based user interface to OpenStack services, including Compute, Networking, Storage, and Identity, among others.
To install Horizon, install the following packages on the controller node:
# yum -y install mod_wsgi openstack-dashboard
Allowing connections to the dashboard
A setting called ALLOWED_HOSTS exists in the /etc/openstack-dashboard/local_settings file with the following defaults:
ALLOWED_HOSTS = ['horizon.example.com', 'localhost']
The domain and host names in the list represent HTTP hosts for which the Apache web server will respond. The preceding settings would require users who wish to access the Horizon dashboard to do so via http://horizon.example.com in their browser. Feel free to add your own domain that references the management/API address of the controller. Otherwise, comment out the line using a pound sign, and save the file to allow any host header to be used:
# sed -i 's/ALLOWED_HOSTS/#ALLOWED_HOSTS/' /etc/openstack-dashboard/local_settings
Identifying the Keystone server
Edit the /etc/openstack-dashboard/local_settings file to set the hostname of the Identity server. In this installation, the Keystone services are running on the controller node. Change the OPENSTACK_HOST and OPENSTACK_KEYSTONE_URL values using the following commands:
# sed -i "/OPENSTACK_HOST/c\OPENSTACK_HOST = \"controller\"" /etc/openstack-dashboard/local_settings # sed -i -e "\$aOPENSTACK_KEYSTONE_URL = \"http://controller:5000/v2.0\"" /etc/openstack-dashboard/local_settings
Changing the listener address
By default, the Apache web server is configured to listen for HTTP requests on port 80 and any IPv6 address. To change this behavior, edit /etc/httpd/conf/httpd.conf, and change the Listen address to 10.254.254.100:
# sed -i 's/Listen 80/Listen 10.254.254.100:80/' /etc/httpd/conf/httpd.conf
Following this, save the file and start the dashboard services. Use chkconfig to enable the services to start at boot:
# service httpd start # chkconfig httpd on
Testing connectivity to the dashboard
From a machine that has access to the management network of the controller node, open the following URL in a web browser:
The /etc/hosts file of my client has been updated to include the same hostname-to-IP mappings configured earlier in this chapter. The following screenshot demonstrates a successful connection to the dashboard. The username and password were created in the Defining users, tenants, and roles in Keystone section earlier in this chapter. In this installation, the username is admin, and the password is secrete. Have a look at the following screenshot:
Upon successful login, the dashboard defaults to the administrative tab. From here, information about the environment is provided in a graphical format. In the next screenshot, the System Info panel provides the user with information about the environment, including Services, Compute Services, Availability Zones, and Host Aggregates. The services listed in the following screenshot are services that were installed earlier in this chapter:
To view the status of Nova (Compute) services, click on the Compute Services tab. Doing so will return output similar to that of nova service-list in the CLI, as follows:
