OpenStack : Install Juno

http://docs.openstack.org/juno/install-guide/install/yum/openstack-install-guide-yum-juno.pdf

Basic Environment

Database password (no variable used)	Root password for the database
RABBIT_PASS	Password of user guest of RabbitMQ
KEYSTONE_DBPASS	Database password of Identity service
DEMO_PASS	Password of user demo
ADMIN_PASS	Password of user admin
GLANCE_DBPASS	Database password for Image Service
GLANCE_PASS	Password of Image Service user glance
NOVA_DBPASS	Database password for Compute service
NOVA_PASS	Password of Compute service user nova
DASH_DBPASS	Database password for the dashboard
CINDER_DBPASS	Database password for the Block Storage service
CINDER_PASS	Password of Block Storage service user cinder
NEUTRON_DBPASS	Database password for the Networking service
NEUTRON_PASS	Password of Networking service user neutron
HEAT_DBPASS	Database password for the Orchestration service
HEAT_PASS	Password of Orchestration service user heat
CEILOMETER_DBPASS	Database password for the Telemetry service
CEILOMETER_PASS	Password of Telemetry service user ceilometer
TROVE_DBPASS	Database password of Database service
TROVE_PASS	Password of Database Service user trove

Database

To install and configure the database server

1. Install the packages:
   

   	Note
   	The Python MySQL library is compatible with MariaDB.

   # yum install mariadb mariadb-server MySQL-python

2. Edit the /etc/my.cnf file and complete the following actions:
   
   1. In the [mysqld] section, set the bind-address key to the management IP address of the controller node to enable access by other nodes via the management network:
      
      

      1 2 3

      [mysqld] ... bind-address = 10.0.0.11

   2. In the [mysqld] section, set the following keys to enable useful options and the UTF-8 character set:
      
      

      1 2 3 4 5 6 7

      [mysqld] ... default-storage-engine = innodb innodb_file_per_table collation-server = utf8_general_ci init-connect = 'SET NAMES utf8' character-set-server = utf8

To finalize installation

1. Start the database service and configure it to start when the system boots:
   

   # systemctl enable mariadb.service
   # systemctl start mariadb.service

   Note:

   # systemctl enable mariadb.service
   ln -s '/usr/lib/systemd/system/mariadb.service' '/etc/systemd/system/multi-user.target.wants/mariadb.service'
    

2. Secure the database service including choosing a suitable password for the root account:
   

   # mysql_secure_installation

   Note:

   # mysql_secure_installation
   /bin/mysql_secure_installation: line 379: find_mysql_client: command not found
   
   NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
         SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
   
   In order to log into MariaDB to secure it, we'll need the current
   password for the root user.  If you've just installed MariaDB, and
   you haven't set the root password yet, the password will be blank,
   so you should just press enter here.
   
   Enter current password for root (enter for none):
   OK, successfully used password, moving on...
   
   Setting the root password ensures that nobody can log into the MariaDB
   root user without the proper authorisation.
   
   Set root password? [Y/n] Y
   New password:
   Re-enter new password:
   Password updated successfully!
   Reloading privilege tables..
    ... Success!
   
   
   By default, a MariaDB installation has an anonymous user, allowing anyone
   to log into MariaDB without having to have a user account created for
   them.  This is intended only for testing, and to make the installation
   go a bit smoother.  You should remove them before moving into a
   production environment.
   
   Remove anonymous users? [Y/n] Y
    ... Success!
   
   Normally, root should only be allowed to connect from 'localhost'.  This
   ensures that someone cannot guess at the root password from the network.
   
   Disallow root login remotely? [Y/n] Y
    ... Success!
   
   By default, MariaDB comes with a database named 'test' that anyone can
   access.  This is also intended only for testing, and should be removed
   before moving into a production environment.
   
   Remove test database and access to it? [Y/n] Y
    - Dropping test database...
    ... Success!
    - Removing privileges on test database...
    ... Success!
   
   Reloading the privilege tables will ensure that all changes made so far
   will take effect immediately.
   
   Reload privilege tables now? [Y/n] Y
    ... Success!
   
   Cleaning up...
   
   All done!  If you've completed all of the above steps, your MariaDB
   installation should now be secure.
   
   Thanks for using MariaDB!

Messaging Server

To install the RabbitMQ message broker service

• # yum install rabbitmq-server

To configure the message broker service

1. Start the message broker service and configure it to start when the system boots:
   

   # systemctl enable rabbitmq-server.service
   # systemctl start rabbitmq-server.service

   Note:

   # systemctl enable rabbitmq-server.service
   ln -s '/usr/lib/systemd/system/rabbitmq-server.service' '/etc/systemd/system/multi-user.target.wants/rabbitmq-server.service'
    

2. The message broker creates a default account that uses guest for the username and password. To simplify installation of your test environment, we recommend that you use this account, but change the password for it.
   Run the following command:
   Replace RABBIT_PASS with a suitable password.
   

   # rabbitmqctl change_password guest RABBIT_PASS
   Changing password for user "guest" ...
   ...done.

   You must configure the rabbit_password key in the configuration file for each OpenStack service that uses the message broker.
   

   	Note
   	For production environments, you should create a unique account with suitable password. For more information on securing the message broker, see the documentation. If you decide to create a unique account with suitable password for your test environment, you must configure the rabbit_userid and rabbit_password keys in the configuration file of each OpenStack service that uses the message broker.

3. For RabbitMQ version 3.3.0 or newer, you must enable remote access for the guest account.
   
   1. Check the RabbitMQ version:
      

      # rabbitmqctl status | grep rabbit
      Status of node 'rabbit@controller' ...
       {running_applications,[{rabbit,"RabbitMQ","3.4.2"},

   2. If necessary, edit the /etc/rabbitmq/rabbitmq.config file and configure loopback_users to reference an empty list:
      

      [{rabbit, [{loopback_users, []}]}].

      	Note
      	Contents of the original file might vary depending on the source of the RabbitMQ package. In some cases, you might need to create this file.

   3. Restart the message broker service:
      

      # systemctl restart rabbitmq-server.service

Add Identity Service

Install and configure

This section describes how to install and configure the OpenStack Identity service on the controller node.

 

To configure prerequisites

Before you configure the OpenStack Identity service, you must create a database and an administration token.

1. To create the database, complete these steps:
   
   1. Use the database access client to connect to the database server as the root user:
      

      $ mysql -u root -p

   2. Create the keystone database:
      

      CREATE DATABASE keystone;

   3. Grant proper access to the keystone database:
      

      GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
        IDENTIFIED BY 'KEYSTONE_DBPASS';
      GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
        IDENTIFIED BY 'KEYSTONE_DBPASS';

      Replace KEYSTONE_DBPASS with a suitable password.
   4. Exit the database access client.
2. Generate a random value to use as the administration token during initial configuration:
   

   # openssl rand -hex 10

 

To install and configure the components

1. Run the following command to install the packages:
   

   # yum install openstack-keystone python-keystoneclient

2. Edit the /etc/keystone/keystone.conf file and complete the following actions:
   
   1. In the [DEFAULT] section, define the value of the initial administration token:
      
      

      1 2 3

      [DEFAULT] ... admin_token = ADMIN_TOKEN

      Replace ADMIN_TOKEN with the random value that you generated in a previous step.
   2. In the [database] section, configure database access:
      
      

      1 2 3

      [database] ... connection = mysql://keystone:KEYSTONE_DBPASS@controller/keystone

      Replace KEYSTONE_DBPASS with the password you chose for the database.
   3. In the [token] section, configure the UUID token provider and SQL driver:
      
      

      1 2 3 4

      [token] ... provider = keystone.token.providers.uuid.Provider driver = keystone.token.persistence.backends.sql.Token

   4. In the [revoke] section, configure the SQL revocation driver:
      
      

      1 2 3

      [revoke] ... driver = keystone.contrib.revoke.backends.sql.Revoke

   5. (Optional) To assist with troubleshooting, enable verbose logging in the [DEFAULT] section:
      
      

      1 2 3

      [DEFAULT] ... verbose = True

3. Create generic certificates and keys and restrict access to the associated files:
   

   # keystone-manage pki_setup --keystone-user keystone --keystone-group keystone
   # chown -R keystone:keystone /var/log/keystone
   # chown -R keystone:keystone /etc/keystone/ssl
   # chmod -R o-rwx /etc/keystone/ssl

4. Populate the Identity service database:
   

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

 

To finalize installation

1. Start the Identity service and configure it to start when the system boots:
   

   # systemctl enable openstack-keystone.service
   # systemctl start openstack-keystone.service

2. By default, the Identity service stores expired tokens in the database indefinitely. The accumulation of expired tokens considerably increases the database size and might degrade service performance, particularly in environments with limited resources.
   We recommend that you use cron to configure a periodic task that purges expired tokens hourly:
   

   # (crontab -l -u keystone 2>&1 | grep -q token_flush) || \
     echo '@hourly /usr/bin/keystone-manage token_flush >/var/log/keystone/keystone-tokenflush.log 2>&1' \
     >> /var/spool/cron/keystone