The admin token is a random number. We will use the openssl tool in order to create it:

openssl rand -hex 10

In my case, it is b7098d7d5eb7bf889842; please make a note of this and have it ready for the next section.

We will also set the environment variable to be used later in the installation and configuration process, using the following command:

export OS_SERVICE_TOKEN=b7098d7d5eb7bf889842

This will set the service token.

The Keystone configuration file is located at /etc/keystone/keystone.conf. Edit this using your favorite editor by making the following changes:

Once the configuration file is completed, it will look as shown in the following screenshot:

We have a blank Keystone database at the moment; we will use the sync command in order to populate it with base data.

Please ensure that you are running the following command as root:

keystone-manage db_sync keystone

Alternatively, if you don't have root access or are performing it with sudo rights, then use the following command. (Both commands don't need to run.)

su -s /bin/sh -c "keystone-manage db_sync" keystone

Once this completes, you will see messages as shown in the following screenshot:

You can also log in to the MySQL client and execute the show tables command to see all the different tables that are created:

Restart the service using the following command:

sudo service keystone restart

While modifying the configuration, you will have noted that there was already a SQL configuration; I am just reminding you of this because Keystone by default comes with a SQLite database. Since we won't be using this anymore, let's delete it. It is located at /var/lib/keystone/keystone.db. We will delete this file using the following command:

rm -f /var/lib/keystone/keystone.db

We will need to create an administrative tenant (or project) that will allow us to log in to Horizon (once we install it in the next chapter) and perform other Keystone related functions. The order in which the components are created is as follows:

You will need the following information in order to perform the actions:

The role names are defined in the policy.json file in Keystone, so we will use the admin role.

Setting up environment variables

We generated a token in the previous section; we have already exported it in that section. Please verify this using the env command and check whether OS_SERVICE_TOKEN is set. If the token is not set (you may have logged out and logged in to the shell), then you can set it using the following command:

export OS_SERVICE_TOKEN=b7098d7d5eb7bf889842

We should also export the service endpoint. The default port for the Keystone administrative function is 35357 (you can verify this by the netstat –nlp command; you will see the server listening on this port). To export service endpoint, execute the following command:

export OS_SERVICE_ENDPOINT=http://OSControllerNode:35357/v2.0

Please ensure that you are able to ping the name and telnet on the 35357 port.

Tip

We can skip this step, but then we have to add the following commands with two additional parameters, --os-token and --os-endpoint, in all the commands we execute.

Creating the tenant

Once the environment variables are set up, execute the following command to create the tenant:

keystone tenant-create --name firsttenant --description "Our First Tenant"

You will see the output confirming that the tenant has been created.

Creating the user

We will now create the user, again using a single command:

keystone user-create --name admin --pass h33l0world --email [email protected]

This will create the user called admin:

Creating and mapping the role

In this section, we will create a role called admin and associate it with the admin user and the firsttenant tenant. Execute the following command to create the role:

keystone role-create --name admin

For mapping, execute the following command:

keystone user-role-add --user admin --tenant firsttenant --role admin

This command will not give us any output. However, we can verify it by the following command:

keystone user-role-list --tenant firsttenant --user admin

We should be able see the GUID of the tenant and the user that we created earlier.

This task is now complete.

In a distributed tool such as OpenStack, it is a good practice for each component to talk to the others using an API, which means that, even when you are using the Horizon dashboard, in the backend the functions will be performed using an API.

In order for the APIs to work, Keystone provides a catalog sub-system. This provides us with the different services of OpenStack and their URLs, so we will start with the identity service itself.

Creating the service

The service needs to be created in the database before its endpoints can be added; this is done by the following command:

keystone service-create --name keystone --type identity --description "OpenStack Identity"

Note down the ID as this is needed for the next step. In my case, it is c0dc26226c42450a82838fc1c18b11fe.

Execute the following command:

keystone service-list

This will show the currently created service, as shown in the following screenshot:

Tip

Sometimes the system acts up and you will get a HTTP 5XX error; just restart the service using the service Keystone restart command.

Creating the endpoint

We will need the following information handy:

Name	Info
Controller node name	OSControllerNode
Service port	5000
Admin port	35357
Service ID (from previous step)	c0dc26226c42450a82838fc1c18b11fe
Public URL	http://OSControllerNode:5000/v2.0
Internal URL	http://OSControllerNode:5000/v2.0
Admin URL	http://OSControllerNode:35357/v2.0
Region name	dataCenterOne

Before we dive in, we should understand the following things that we have filled:

• Public URL: This is the one that should be accessible from outside (by other departments); so, if you have a different name or FQDN that you are trying to publish, use that here. Please note that we have used the service port here.
• Internal URL: This is same as the public URL but from inside the company.
• Admin URL: This is for administrative tasks and allows things such as creating a user (if we are using a local database).
• Region name: This is needed simply because we need to keep the API EC2-compliant.
• V2.0: We have used the Keystone identity version 2.0, even after the 3.0 version is out. We can just change these URLs to v3.0, and the new identity can be used. However, at the time of writing, the v2.0 version was the most compatible one.

Armed with the preceding information, let's construct the command. This is a single-line command, but is broken into multiple lines for readability purposes; the instructs the shell executing the command to wait for the remaining:

keystone endpoint-create 
  --service-id c0dc26226c42450a82838fc1c18b11fe 
  --publicurl http://oscontrollernode:5000/v2.0 
  --internalurl http://oscontrollernode:5000/v2.0 
  --adminurl http://oscontrollernode:35357/v2.0 
  --region dataCenterOne

So we have successfully created our endpoint, which the different OpenStack components can use in order to communicate with the Keystone service.