Procedure 3.1. Installing Packages

1. Log in to the system that will host the Foreman installation as the root user.
2. Install the openstack-foreman-installer and foreman-selinux packages.

   # yum install -y openstack-foreman-installer foreman-selinux

Procedure 3.2. Configuring the Installer

1. Log in to the system that will host the Foreman installation as the root user.
2. Open the /usr/share/foreman-installer/bin/foreman_server.sh file in a text editor.

   # vi /usr/share/foreman-installer/bin/foreman_server.sh

3. Locate the OpenStack configuration keys within the file. The first configuration key listed is PRIVATE_CONTROLLER_IP.

   Example 3.1. OpenStack Configuration

   #PRIVATE_CONTROLLER_IP=10.0.0.10
   #PRIVATE_INTERFACE=eth1
   #PRIVATE_NETMASK=10.0.0.0/23
   #PUBLIC_CONTROLLER_IP=10.9.9.10
   #PUBLIC_INTERFACE=eth2
   #PUBLIC_NETMASK=10.9.9.0/24
   #FOREMAN_GATEWAY=10.0.0.1 (or false for no gateway)

   
   
4. Remove the comment character (#) from the start of each line, then edit the value of each configuration key. These configuration keys will determine the network topology of the OpenStack environment, once deployed:

   PRIVATE_CONTROLLER_IP

   The IP address to assign to the Compute controller node on the private OpenStack network.

   Example 3.2. Value for PRIVATE_CONTROLLER_IP

   10.0.0.10

   
   

   PRIVATE_INTERFACE

   The network interface on the controller node to connect to the private OpenStack network.

   Example 3.3. Values for PRIVATE_INTERFACE

   • eth1
   • em1
   • p1p3

   
   

   PRIVATE_NETMASK

   The IP range to associate with the OpenStack private network is defined using Classless Inter-Domain Routing (CIDR) notation.

   Example 3.4. Value for PRIVATE_NETMASK

   10.0.0.0/23

   
   

   PUBLIC_CONTROLLER_IP

   The IP address to assign to the Compute controller node on the public OpenStack network.

   Example 3.5. Value for PUBLIC_CONTROLLER_IP

   10.9.9.10

   
   

   PUBLIC_INTERFACE

   The network interface on the Compute controller node to connect to the public OpenStack network.

   Example 3.6. Values for PUBLIC_INTERFACE

   • eth2
   • em2
   • p1p4

   
   

   PUBLIC_NETMASK

   The IP range to associate with the OpenStack public network is defined using Classless Inter-Domain Routing (CIDR) notation.

   Example 3.7. Value for PUBLIC_NETMASK

   10.9.9.0/24

   
   

   FOREMAN_GATEWAY

   The IP address of the default gateway on the Foreman network. The nodes will use this gateway to access installation media during the provisioning process.

   Example 3.8. Value for FOREMAN_GATEWAY

   10.0.0.1

   
   

   Important

   If bare metal provisoning is not required then set the value of the FOREMAN_GATEWAY configuration key to false. The FOREMAN_PROVISIONING configuration key found elsewhere in the file must also be set to false.

   • Before:

     if [ "x$FOREMAN_PROVISIONING" = "x" ]; then
       FOREMAN_PROVISIONING=true
     fi
     

   • After:

     if [ "x$FOREMAN_PROVISIONING" = "x" ]; then
       FOREMAN_PROVISIONING=false
     fi
     

   Note

   It is possible to use identical network definitions for the OpenStack public and private network for testing purposes. Such a configuration is not recommended for production environments.
5. Save the file and exit the text editor.

Procedure 3.3. Running the Installer

1. Log in to the system that will host the Foreman installation as the root user.
2. Change to the /usr/share/openstack-foreman-installer/bin/ directory. The installer must be run from this directory.

   # cd /usr/share/openstack-foreman-installer/bin/

3. Run the foreman_server.sh script.

   # sh foreman_server.sh

4. A message is displayed indicating that the functionality being deployed is provided as a Technology Preview:

   #################### RED HAT OPENSTACK #####################
   Thank you for using the Red Hat OpenStack Foreman Installer!
   Please note that this tool is a Technology Preview
   For more information about Red hat Technology Previews, see
   https://access.redhat.com/support/offerings/techpreview/
   ############################################################
   Press [Enter] to continue

   Press the Enter key to indicate that you understand the support ramifications of the Technology Preview designation and wish to proceed with installation.
5. The installer deploys Foreman using Puppet manifests. This may take a significant amount of time.
6. A message is displayed once deployment of the Puppet manifests has been completed:

   Foreman is installed and almost ready for setting up your OpenStack
   First, you need to alter a few parameters in Foreman.
   Visit:
   https://FQDN/puppetclasses/quickstack::compute/edit
   https://FQDN/puppetclasses/quickstack::controller/edit
   Go to the Smart Class Parameters tab and work though each of the parameters
   in the left-hand column
   
   Then copy /tmp/foreman_client.sh to your openstack client nodes
   Run that script and visit the HOSTS tab in foreman. Pick CONTROLLER
   host group for your controller node and COMPUTE host group for the rest
   
   Once puppet runs on the machines, OpenStack is ready!

   In the actual output FQDN will have been replaced with the fully qualified domain name of the system to which Foreman was deployed.

Procedure 4.1. Changing the Password

1. Open a web browser either on the Foreman server itself or on a system with network access to the Foreman server.
2. Browse to https://FQDN/. Replace FQDN with the fully qualified domain name of your Foreman server.

   Example 4.1. Foreman URL

   https://foreman.example.com/
   
   
3. The login screen is displayed. Type admin in the Username field and changeme in the Password field. Click the Login button to log in.
   

   Figure 4.1. Foreman Login Screen

   
   
4. The Overview screen is displayed. Select the Admin User → My account option in the top right hand corner of the screen to access account settings.
   

   Figure 4.2. Accessing Account Settings

   
   
5. The Edit User screen is displayed. Enter a new password in the Password field.
6. Enter the new password again in the Verified field.
7. Click the Submit button to save the change.

Procedure 4.2. Configuring Installation Media

1. Use a web browser on a system with network access to the Foreman server to open the Foreman web user interface.
2. Log in using the admin user and the password that was set in Section 4.1, “Changing the Password”.
3. Click More → Provisioning → Installation Media in the top right hand corner of the page.
   

   Figure 4.3. Provisioning Menu Items

   
   
4. The Installation Media page is displayed. An OpenStack RHEL mirror entry already exists by default but the associated path is only provided as an example and must be corrected.
   

   Figure 4.4. Installation Media Page

   
   
5. Click the OpenStack RHEL mirror entry.
6. The Edit Medium page is displayed.
7. Update the Path field to contain the URL of a local installation mirror. These variables can be used in the URL and will be replaced automatically:

   $arch

   The system architecture, for example x86_64.

   $version

   The operating system version, for example 6.5.

   $major

   The operating system major version, for example 6.

   $minor

   The operating system minor version, for example 4.

   Example 4.2. Path

   http://download.example.com/rhel/$version/Server/$arch/os/
   
   
8. Click Submit to save the updated Path.

Procedure 4.3. Editing Host Groups

1. Use a web browser on a system with network access to the Foreman server to open the Foreman web user interface.
2. Log in using the admin user and the associated password.
3. Click More → Configuration → Host Groups.
   

   Figure 4.5. The Host Groups Menu Item

   
   
4. The Host Groups page is displayed. The available options are:
   • OpenStack Controller
   • OpenStack Nova Compute
   Click the name of the host group to edit.
5. The Edit page is displayed. Select the Parameters tab.
6. The list of parameters associated with the host group is displayed. For each parameter to be edited click the associated override button. A text field will appear at the bottom of the page. Enter the new value for the parameter in the text field.
   

   Figure 4.6. Override Button

   
   
   For more information on the available host group parameters see:
   • Section 4.3.1, “Controller Node”
   • Section 4.3.2, “Compute Node”
7. Repeat the previous step for each parameter in the host group that needs to be edited.
8. Click Submit to save the updated parameter values.

Procedure 5.1. Registering Hosts

1. Log in to the Foreman server.
2. Copy the /tmp/foreman_client.sh file from the Foreman server to the new host:

   $ scp /tmp/foreman_client.sh USER@IP:DIR

   Replace USER with the user to use when logging in to the new host, replace IP with the IP address or fully qualified domain name of the new host, and replace DIR with the path to the directory in which the file must be stored on the remote machine. The directory must already exist.

   Example 5.1. Copying the Script

   $ scp /tmp/foreman_client.sh root@controller.example.com:~/

   
   
3. Log in to the new host as the root user.
4. Change into the directory to which the foreman_client.sh script was copied:

   # cd DIR

   Replace DIR with the path to the directory used when copying the file to the host.
5. Run the foreman_client.sh script:

   # sh foreman_client.sh

6. When the script completes successfully the Puppet agent is started and this message is displayed:

   Starting puppet agent:        [  OK  ]

7. Use a web browser on a system with network access to the Foreman server to open the Foreman web user interface.
8. Log in using the admin user and the password that was defined during the Foreman installation.
9. Click the Hosts tab.
10. Verify that the newly registered host is listed:
    

    In this example the two hosts listed are:

    • The Foreman server (foreman.example.com).
    • The host destined to be the controller node (controller.example.com).

    Note that although the fully qualified domain name indicates the role that the new host will take (controller node) this is not actually determined until the host is assigned to the relevant host group.

    Figure 5.1. Hosts Tab

    
    

Procedure 5.2. Provisioning New Hosts

1. Use a web browser on a system with network access to the Foreman server to open the Foreman web user interface.
2. Log in using the admin user and associated password.
3. Click the Hosts tab.
4. Click the New Host button.
5. Enter the desired fully qualified domain name for the new host in the Name field.
6. Do not select a Host Group at this time.
7. Click the Network tab. The Network tab contains settings that define the networking configuration for the new host.
   1. Enter the MAC address of the network interface on the physical machine that is connected to the Foreman network in the MAC address field.

      Example 5.2. MAC Address

      In this example the ip link command is used to identify the MAC address of the eth0 network interface.

      # ip link show eth0
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
          link/ether 00:1a:4a:0f:18:bb brd ff:ff:ff:ff:ff:ff

      The MAC address of the eth0 network device is 00:1a:4a:0f:18:bb.
      
      
   2. Ensure that the value in the Domain field matches the domain that Foreman is expected to manage.

      Example 5.3. Domain

      example.com
      
      
   3. Ensure that a subnet is selected in the Subnet field. The IP address field will be automatically selected based on the subnet selection.

      Example 5.4. Subnet

      OpenStack (192.0.43.0/24)
      
      
8. Click the Operating System tab. The Operating System tab contains options for configuring the operating system installation for the host.
   1. Select x86_64 in the Architecture field.
   2. Select RedHat 6.5 in the Operating System field.
   3. Enter a password for the root user in the Root password field.

      Warning

      It is highly recommended that a secure root password is provided. Strong passwords contain a mix of uppercase, lowercase, numeric and punctuation characters. They are six or more characters long and do not contain dictionary words. Failure to enter a secure root password in this field will result in the default root password, 123123, being used.
   4. Click the Resolve button. Two templates will appear:
      • OpenStack PXE Template
      • OpenStack Kickstart Template
9. Click the Parameters tab. The Parameters tab contains settings that will be used to register the new host to Red Hat Network or a Red Hat Network Satellite server.
   • To configure the host to register to Red Hat Network:
     1. Click the Override button next to the satellite_type configuration key. Enter hosted in the Value field.
     2. Click the Override button next to the satellite_host configuration key. Enter xmlrpc.rhn.redhat.com in the associated Value field.
     3. Click the Override button next to the activation_key configuration key. Enter the Red Hat Network activation key to be used when registering the host in the associated Value field.
   • To configure the host to register to a Red Hat Network Satellite server:
     1. Ensure the satellite_type is set to the default value, site.
     2. Click the Override button next to the satellite_host configuration key. Enter the IP address or fully qualified domain name of the Red Hat Network Satellite server in the associated Value field.
     3. Click the Override button next to the activation_key configuration key. Enter the Red Hat Network activation key to be used when registering the host in the associated Value field.

   Important

   If the system is intended to be provisioned using packages from a different location instead of Red Hat Network or a Red Hat Network Satellite server then the OpenStack Kickstart Template must be edited. Access the template editor by clicking More → Provisioning → Provisioning Templates, selecting the OpenStack Kickstart Template entry, and removing this line from the template:

   <%= snippets "redhat_register" %>

   The line must be replaced with environment specific commands suitable for registering the system and adding equivalent software repositories.
10. Click the Submit button. Foreman will prepare to add the hosts the next time they boot.
11. Ensure network boot (PXE) is enabled on the new host. Instructions for confirming this will be in the manufacturer instructions for the specific system.
12. Restart the host. The host will retrieve an installation image from the Foreman PXE/TFTP server and begin the installation process.
13. The host will restart again once installation has completed. Once this occurs use the Foreman web user interface to verify that the new host appears by clicking the Hosts tab.

Procedure 5.3. Assigning Hosts

1. Use a web browser on a system with network access to the Foreman server to open the Foreman web user interface.
2. Log in using the admin user and associated password.
3. Click the Hosts tab.
4. Select the host from the list displayed in the table.
5. Click the Select Action → Change Group option.
   

   In this example one host (controller.example.com) is selected and the options available in the Select Action menu are visible.

   Figure 5.2. Selecting an Action

   
   
6. The Change Group window is displayed.
   

   Figure 5.3. The Change Group Window

   
   
7. Use the Select host group field to select a host group. The available options are:
   • OpenStack Controller
   • OpenStack Nova Compute
   If no controller node has been configured yet, select OpenStack Controller, otherwise select OpenStack Nova Compute to provision compute nodes.

   Important

   A controller node must be provisioned before attempting to provision a compute node. Puppet must have completed installation and configuration of the controller node before compute nodes are deployed.
8. Click the Submit button to save the host group selection.

• Install the required packages using the yum command:

  # yum install -y mysql-server

1. Open the /etc/sysconfig/iptables file in a text editor.
2. Add an INPUT rule allowing TCP traffic on port 3306 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

   -A INPUT -p tcp -m multiport --dports 3306 -j ACCEPT

3. Save the changes to the /etc/sysconfig/iptables file.
4. Restart the iptables service to ensure that the change takes effect.

   # service iptables restart

1. Use the service command to start the mysqld service.

   # service mysqld start

2. Use the chkconfig command to ensure that the mysqld service will be started automatically in the future.

   # chkconfig mysqld on

1. Use the mysqladmin command to set the password for the root database user.

   # /usr/bin/mysqladmin -u root password "PASSWORD"

   Replace PASSWORD with the intended password.
2. The mysqladmin command can also be used to change the password of the root database user if required.

   # /usr/bin/mysqladmin -u root -p OLDPASS NEWPASS

   Replace OLDPASS with the existing password and NEWPASS with the password that is intended to replace it.

• Install the required packages using the yum command:

  # yum install -y qpid-cpp-server qpid-cpp-server-ssl

1. Open the /etc/sysconfig/iptables file in a text editor.
2. Add an INPUT rule allowing incoming connections on port 5672 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

   -A INPUT -p tcp -m tcp --dport 5672  -j ACCEPT

3. Save the changes to the /etc/sysconfig/iptables file.
4. Restart the iptables service for the firewall changes to take effect.

   # service iptables restart

1. Use the service command to start the service.

   # service qpidd start

2. Use the chkconfig command to enable the service permanently.

   # chkconfig qpidd on

• Install the required packages using the yum command:

  # yum install -y openstack-keystone \
        openstack-utils \
        openstack-selinux

1. Connect to the database service using the mysql command.

   # mysql -u root -p

2. Create the keystone database.

   mysql> CREATE DATABASE keystone;

3. Create a keystone database user and grant it access to the keystone database.

   mysql> GRANT ALL ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'PASSWORD';

   mysql> GRANT ALL ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'PASSWORD';

   Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.
4. Flush the database privileges to ensure that they take effect immediately.

   mysql> FLUSH PRIVILEGES;

5. Exit the mysql client command.

   mysql> quit

1. Use the service command to start the openstack-keystone service.

   # service openstack-keystone start

2. Use the chkconfig command to ensure that the openstack-keystone service will be started automatically in the future.

   # chkconfig openstack-keystone on

1. Set the SERVICE_TOKEN Environment Variable

   Set the SERVICE_TOKEN environment variable to the administration token. This is done by reading the token file created when setting the administration token.

   # export SERVICE_TOKEN=`cat ~/ks_admin_token`

2. Set the SERVICE_ENDPOINT Environment Variable

   Set the SERVICE_ENDPOINT environment variable to point to the server hosting the identity service.

   # export SERVICE_ENDPOINT="http://IP:35357/v2.0"

   Replace IP with the IP address or host name of your identity server.

3. Create a Service Entry

   Create a service entry for the identity service using the keystone service-create command.

   # keystone service-create --name=keystone --type=identity \
           --description="Keystone Identity Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |     Keystone Identity Service    |
   | id          | a8bff1db381f4751bd8ac126464511ae |
   | name        |             keystone             |
   | type        |             identity             |
   +-------------+----------------------------------+

   Take note of the unique identifier assigned to the entry. This value will be required in subsequent steps.

4. Create an Endpoint for the API

   Create an endpoint entry for the v2.0 API identity service using the keystone endpoint-create command.

   # keystone endpoint-create \
           --service_id ID \
           --publicurl 'http://IP:5000/v2.0' \
           --adminurl 'http://IP:35357/v2.0' \
           --internalurl 'http://IP:5000/v2.0'
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | adminurl    |       http://IP:35357/v2.0       |
   | id          | 1295011fdc874a838f702518e95a0e13 |
   | internalurl |       http://IP:5000/v2.0        |
   | publicurl   |       http://IP:5000/v2.0        |
   | region      |             regionOne            |
   | service_id  |                 ID               |
   +-------------+----------------------------------+

   Replace ID with the service identifier returned in the previous step. Replace IP with the IP address or host name of the identity server.

   Important

   Ensure that the publicurl, adminurl, and internalurl parameters include the correct IP address for your Keystone identity server.

   Note

   By default, the endpoint is created in the default region, regionOne. If you need to specify a different region when creating an endpoint use the --region argument to provide it.

1. Set the SERVICE_TOKEN environment variable to the value of the administration token. This is done by reading the token file created when setting the administration token:

   # SERVICE_TOKEN=`cat ~/ks_admin_token`

2. Set the SERVICE_ENDPOINT environment variable to point to the server hosting the identity service:

   # export SERVICE_ENDPOINT="http://IP:35357/v2.0"

   Replace IP with the IP address or host name of your identity server.
3. Use the keystone user-create command to create an admin user:

   # keystone user-create --name admin --pass PASSWORD
   +----------+-----------------------------------+
   | Property |              Value                |
   +----------+-----------------------------------+
   | email    |                                   |
   | enabled  |              True                 |
   | id       | 94d659c3c9534095aba5f8475c87091a  |
   | name     |              admin                |
   | tenantId |                                   |
   +----------+-----------------------------------+

   Replace PASSWORD with a secure password for the account. Take note of the created user's ID as it will be required in subsequent steps.
4. Use the keystone role-create command to create an admin role:

   # keystone role-create --name admin
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   | id       | 78035c5d3cd94e62812d6d37551ecd6a |
   | name     |              admin               |
   +----------+----------------------------------+

   Take note of the admin user's ID as it will be required in subsequent steps.
5. Use the keystone tenant-create command to create an admin tenant:

   # keystone tenant-create --name admin
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |                                  |
   | enabled     |              True                |
   | id          | 6f8e3e36c4194b86b9a9b55d4b722af3 |
   | name        |              admin               |
   +-------------+----------------------------------+

   Take note of the admin tenant's ID as it will be required in the next step.
6. Now that the user account, role, and tenant have been created, the relationship between them must be explicitly defined using the keystone user-role-add:

   # keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID

   Replace the user, role, and tenant IDs with those obtained in the previous steps.
7. The newly created admin account will be used for future management of the identity service. To facilitate authentication, create a keystonerc_admin file in a secure location such as the home directory of the root user.
   Add these lines to the file to set the environment variables that will be used for authentication:

   export OS_USERNAME=admin
   export OS_TENANT_NAME=admin
   export OS_PASSWORD=PASSWORD
   export OS_AUTH_URL=http://IP:35357/v2.0/
   export PS1='[\u@\h \W(keystone_admin)]\$ '

   Replace PASSWORD with the password of the admin user and replace IP with the IP address or host name of the identity server.
8. Run the source command on the file to load the environment variables used for authentication:

   # source ~/keystonerc_admin

1. Load identity credentials from the ~/keystonerc_admin file that was generated when the administrative user was created:

   # source ~/keystonerc_admin

2. Use the keystone user-create to create a regular user:

   # keystone user-create --name USER --pass PASSWORD
   +----------+-----------------------------------+
   | Property |              Value                |
   +----------+-----------------------------------+
   | email    |                                   |
   | enabled  |              True                 |
   | id       | b8275d7494dd4c9cb3f69967a11f9765  |
   | name     |              USER                 |
   | tenantId |                                   |
   +----------+-----------------------------------+

   Replace USER with the user name that you would like to use for the account. Replace PASSWORD with a secure password for the account. Take note of the created user's ID as it will be required in subsequent steps.
3. Use the keystone role-create command to create an Member role. The Member role is the default role required for access to the dashboard:

   # keystone role-create --name Member
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   | id       | 78035c5d3cd94e62812d6d37551ecd6a |
   | name     |             Member               |
   +----------+----------------------------------+

   Take note of the created role's ID as it will be required in subsequent steps.
4. Use the keystone tenant-create command to create a tenant:

   # keystone tenant-create --name TENANT
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |                                  |
   | enabled     |              True                |
   | id          | 6f8e3e36c4194b86b9a9b55d4b722af3 |
   | name        |             TENANT               |
   +-------------+----------------------------------+

   Replace TENANT with the name that you wish to give to the tenant. Take note of the created tenant's ID as it will be required in the next step.
5. Now that the user account, role, and tenant have been created, the relationship between them must be explicitly defined using the keystone user-role-add:

   # keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID

   Replace the user, role, and tenant IDs with those obtained in the previous steps.
6. To facilitate authentication create a keystonerc_user file in a secure location such as the home directory of the root user.
   Set these environment variables that will be used for authentication:

   export OS_USERNAME=USER
   export OS_TENANT_NAME=TENANT
   export OS_PASSWORD=PASSWORD
   export OS_AUTH_URL=http://IP:5000/v2.0/
   export PS1='[\u@\h \W(keystone_user)]\$ '

   Replace USER and TENANT with the name of the new user and tenant respectively. Replace PASSWORD with the password of the user and replace IP with the IP address or host name of the identity server.

1. Run the source command on the file containing the environment variables used to identify the Identity service administrator.

   # source ~/keystonerc_admin

2. Create the services tenant in the Identity service:

   # keystone tenant-create --name services --description "Services Tenant"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |         Services Tenant          |
   | enabled     |              True                |
   | id          | 7e193e36c4194b86b9a9b55d4b722af3 |
   | name        |             services             |
   +-------------+----------------------------------+

1. Run the source command on the file containing the environment variables used to identify the identity service administrator.

   # source ~/keystonerc_admin

2. Run the keystone user-list command to authenticate with the identity service and list the users defined in the system.

   # keystone user-list
   +----------------------------------+--------+---------+------------------+
   |                id                |  name  | enabled |      email       |
   +----------------------------------+--------+---------+------------------+
   | 94d659c3c9534095aba5f8475c87091a | admin  |   True  |                  |
   | b8275d7494dd4c9cb3f69967a11f9765 |  USER  |   True  |                  |
   +----------------------------------+--------+---------+------------------+

   The list of users defined in the system is displayed. If the list is not displayed then there is an issue with the installation.
   1. If the message returned indicates a permissions or authorization issue then check that the administrator user account, tenant, and role were created properly. Also ensure that the three objects are linked correctly.

      Unable to communicate with identity service: {"error": {"message": "You are not authorized to perform the requested action: admin_required", "code": 403, "title": "Not Authorized"}}. (HTTP 403)

   2. If the message returned indicates a connectivity issue then verify that the openstack-keystone service is running and that iptables is configured to allow connections on ports 5000 and 35357.

      Authorization Failed: [Errno 111] Connection refused

3. Run the source command on the file containing the environment variables used to identify the regular identity service user.

   # source ~/keystonerc_user

4. Run the keystone user-list command to authenticate with the identity service and list the users defined in the system.

   # keystone user-list
   Unable to communicate with identity service: {"error": {"message": "You are not authorized to perform the requested action: admin_required", "code": 403, "title": "Not Authorized"}}. (HTTP 403)

   An error message is displayed indicating that the user is Not Authorized to run the command. If the error message is not displayed but instead the user list appears then the regular user account was incorrectly attached to the admin role.
5. Run the keystone token-get command to verify that the regular user account is able to run commands that it is authorized to access.

   # keystone token-get
   +-----------+----------------------------------+
   |  Property |              Value               |
   +-----------+----------------------------------+
   |  expires  |       2013-05-07T13:00:24Z       |
   |     id    | 5f6e089b24d94b198c877c58229f2067 |
   | tenant_id | f7e8628768f2437587651ab959fbe239 |
   |  user_id  | 8109f0e3deaf46d5990674443dcf7db7 |
   +-----------+----------------------------------+

Procedure 10.1. Installing the Object Storage Service Packages

• Install the required packages using the yum command as the root user:

  # yum install -y openstack-swift-proxy \
          openstack-swift-object \
          openstack-swift-container \
          openstack-swift-account \
          openstack-utils \
          memcached

1. On your proxy server node, use the openstack-config command to turn on debug level logging:

   # openstack-config --set /etc/swift/proxy-server.conf DEFAULT log_level debug

2. Set up the shell to access Keystone as a user that has the admin role. The admin user is shown in this example:
   Use the swift list to make sure you can connect to your proxy server:

   $ swift list
         Message from syslogd@thildred-swift-01 at Jun 14 02:46:00 ...
    �135 proxy-server Server reports support for api versions: v3.0, v2.0
   

3. Use the swift command to upload some files to your Object Storage Service nodes

   $ head -c 1024 /dev/urandom > data1.file ; swift upload c1 data1.file
   $ head -c 1024 /dev/urandom > data2.file ; swift upload c1 data2.file
   $ head -c 1024 /dev/urandom > data3.file ; swift upload c1 data3.file

4. Use the swift command to take a listing of the objects held in your Object Storage Service cluster.

   $ swift list
   $ swift list c1
   data1.file
   data2.file
   data3.file
   

1. Connect to the database service using the mysql command.

   # mysql -u root -p

2. Create the glance database.

   mysql> CREATE DATABASE glance;

3. Create a glance database user and grant it access to the glance database.

   mysql> GRANT ALL ON glance.* TO 'glance'@'%' IDENTIFIED BY 'PASSWORD';
   mysql> GRANT ALL ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'PASSWORD';

   Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.
4. Flush the database privileges to ensure that they take effect immediately.

   mysql> FLUSH PRIVILEGES;

5. Exit the mysql client.

   mysql> quit