This guide shows you how to create a controller node to host most services and a compute node to run virtual machine instances. Subsequent chapters create additional nodes to run more services. OpenStack is flexible about how and where you run each service, so other configurations are possible. However, you must configure certain operating system settings on each node. This chapter details a sample configuration for the controller node and any additional nodes. You can configure the operating system in other ways, but this guide assumes that your configuration is compatible with the one described here. All example commands assume you have administrative privileges. Either run the commands as the root user or prefix them with the sudo command.

We strongly recommend that you install a 64-bit operating system on your compute nodes. If you use a 32-bit operating system, attempting a start a virtual machine using a 64-bit image will fail with an error. For more information about system requirements, see the OpenStack Operations Guide.

For an OpenStack production deployment, most nodes must have these network interface cards: One network interface card for external network traffic Another card to communicate with other OpenStack nodes. For simple test cases, you can use machines with a single network interface card. The following example configures Networking on two networks with static IP addresses and manually manages a list of host names on each machine. If you manage a large network, you might already have systems in place to manage this. If so, you can skip this section but note that the rest of this guide assumes that each node can reach the other nodes on the internal network by using the controller and compute1 host names. Disable the NetworkManager service and enable the network service. The network service is more suitable for the static network configuration done in this guide. # service NetworkManager stop # service network start # chkconfig NetworkManager off # chkconfig network on Since Fedora 19, firewalld replaces iptables as the default firewall system. You can use firewalld successfully, but this guide recommends and demonstrates the use of the default iptables. For Fedora 19 systems, run the following commands to disable firewalld and enable iptables: # service firewalld stop # service iptables start # chkconfig firewalld off # chkconfig iptables on RHEL and derivatives including CentOS and Scientific Linux enable a restrictive firewall by default. During this installation, certain steps will fail unless you alter this setting or disable the firewall. For further information about securing your installation, refer to the OpenStack Security Guide. When you set up your system, use the traditional network scripts and do not use NetworkManager. You can change the settings after installation with the YaST network module: # yast2 network Configure both eth0 and eth1. The examples in this guide use the 192.168.0.x IP addresses for the internal network and the 10.0.0.x IP addresses for the external network. Make sure to connect your network devices to the correct network. In this guide, the controller node uses the 192.168.0.10 and 10.0.0.10 IP addresses. When you create the compute node, use the 192.168.0.11 and 10.0.0.11 addresses instead. Additional nodes that you add in subsequent chapters also follow this pattern.

# Internal Network DEVICE=eth0 TYPE=Ethernet BOOTPROTO=static IPADDR=192.168.0.10 NETMASK=255.255.255.0 DEFROUTE=yes ONBOOT=yes # External Network DEVICE=eth1 TYPE=Ethernet BOOTPROTO=static IPADDR=10.0.0.10 NETMASK=255.255.255.0 DEFROUTE=yes ONBOOT=yes To configure the network interfaces, start the YaST network module, as follows: # yast2 network Use these parameters to set up the eth0 ethernet card for the internal network: Statically assigned IP Address IP Address: 192.168.0.10 Subnet Mask: 255.255.255.0 Use these parameters to set up the eth1 ethernet card for the external network: Statically assigned IP Address IP Address: 10.0.0.10 Subnet Mask: 255.255.255.0 Set up a default route on the external network. # Internal Network auto eth0 iface eth0 inet static address 192.168.0.10 netmask 255.255.255.0 # External Network auto eth1 iface eth1 inet static address 10.0.0.10 netmask 255.255.255.0 After you configure the network, restart the daemon for changes to take effect: # service networking restart # service network restart Set the host name of each machine. Name the controller node controller and the first compute node compute1. The examples in this guide use these host names. Use the hostname command to set the host name: # hostname controller Use yast network to set the host name with YaST. To have the host name change persist when the system reboots, you must specify it in the proper configuration file. In Red Hat Enterprise Linux, CentOS, and older versions of Fedora, you set this in the file /etc/sysconfig/network. Change the line starting with HOSTNAME=. HOSTNAME=controller As of Fedora 18, Fedora uses the /etc/hostname file, which contains a single line with the host name. To configure this host name to be available when the system reboots, you must specify it in the /etc/hostname file, which contains a single line with the host name. Finally, ensure that each node can reach the other nodes by using host names. You must manually edit the /etc/hosts file on each system. For large-scale deployments, use DNS or a configuration management system like Puppet. 127.0.0.1 localhost 192.168.0.10 controller 192.168.0.11 compute1

To synchronize services across multiple machines, you must install NTP. The examples in this guide configure the controller node as the reference server and any additional nodes to set their time from the controller node. Install the ntp package on each system running OpenStack services. # apt-get install ntp # yum install ntp # zypper install ntp Set up the NTP server on your controller node so that it receives data by modifying the ntp.conf file and restarting the service. # service ntpd start # chkconfig ntpd on # service ntp start # chkconfig ntp on On additional nodes, it is advised that you configure the other nodes to synchronize their time from the controller node rather than from outside of your LAN. To do so, install the ntp daemon as above, then edit /etc/ntp.conf and change the server directive to use the controller node as internet time source.

The various OpenStack services and the required software like the database and the Messaging server have to be password protected. These passwords are needed when configuring a service and then again to access the service. You have to choose a random password while configuring the service and later remember to use the same password when accessing it. To generate a list of passwords, you can use the pwgen program to generate a list of passwords or take the output of: $ openssl rand -hex 10 This guide uses the convention that SERVICE_PASS is password to access the service SERVICE and SERVICE_DBPASS is the database password used by the service SERVICE to access the database. The complete list of passwords you need to define in this guide are:

Passwords

Password name	Description
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
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

Most OpenStack services require a database to store information. These examples use a MySQL database that runs on the controller node. You must install the MySQL database on the controller node. You must install MySQL client software on any additional nodes that access MySQL. Most OpenStack services require a database to store information. This guide uses a MySQL database on SUSE Linux Enterprise Server and a compatible database on openSUSE running on the controller node. This compatible database for openSUSE is MariaDB. You must install the MariaDB database on the controller node. You must install the MariaDB client software on any nodes that access the MariaDB database.

For SUSE Linux Enterprise Server: On the controller node, install the MySQL client and server packages, and the Python library. # zypper install mysql-client mysql python-mysql For openSUSE: On the controller node, install the MariaDB client and database server packages, and the MySQL Python library. # zypper install mariadb-client mariadb python-mysql # apt-get install python-mysqldb mysql-server # yum install mysql mysql-server MySQL-python When you install the server package, you are prompted for the root password for the database. Choose a strong password and remember it. Edit /etc/mysql/my.cnf/etc/my.cnf and set the bind-address to the internal IP address of the controller, to enable access from outside the controller node. [mysqld] ... bind-address = 192.168.0.10 Restart the MySQL service to apply the changes: # service mysql restart Start the MySQL MariaDB or MySQL database server and set it to start automatically when the system boots. # service mysqld start # chkconfig mysqld on # service mysql start # chkconfig mysql on Finally, you should set a root password for your MySQL MariaDB or MySQL database. The OpenStack programs that set up databases and tables prompt you for this password if it is set. You must delete the anonymous users that are created when the database is first started. Otherwise, database connection problems occur when you follow the instructions in this guide. To do this, use the mysql_secure_installation command. Note that if mysql_secure_installation fails you might need to use mysql_install_db first: # mysql_install_db # mysql_secure_installation If you have not already set a root database password, press ENTER when you are prompted for the password. This command presents a number of options for you to secure your database installation. Respond yes to all prompts unless you have a good reason to do otherwise.

On all nodes other than the controller node, install the MySQL MariaDB (on openSUSE) client and the MySQL Python library on any system that does not host a MySQL database: # apt-get install python-mysqldb # yum install mysql MySQL-python # zypper install mariadb-client python-mysql For SUSE Linux Enterprise, install MySQL: # zypper install mysql-client python-mysql

Distributions might release OpenStack packages as part of their distribution or through other methods because the OpenStack and distribution release times are independent of each other. This section describes the configuration you must complete after you configure machines to install the latest OpenStack packages. The examples in this guide use the OpenStack packages from the RDO repository. These packages work on Red Hat Enterprise Linux 6, compatible versions of CentOS, and Fedora 19. To enable the RDO repository, download and install the rdo-release-havana package. # yum install http://repos.fedorapeople.org/repos/openstack/openstack-havana/rdo-release-havana-6.noarch.rpm The EPEL package includes GPG keys for package signing and repository information. This should only be installed on Red Hat Enterprise Linux and CentOS, not Fedora. Install the latest epel-release package (see http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html). For example: # yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm The openstack-utils package contains utility programs that make installation and configuration easier. These programs are used throughout this guide. Install openstack-utils. This verifies that you can access the RDO repository. # yum install openstack-utils Use the Open Build Service repositories for Havana based on your openSUSE or SUSE Linux Enterprise Server version, for example if you run openSUSE 12.3 use: # zypper addrepo -f obs://Cloud:OpenStack:Havana/openSUSE_12.3 Havana If you use SUSE Linux Enterprise Server 11 SP3, use: # zypper addrepo -f obs://Cloud:OpenStack:Havana/SLE_11_SP3 Havana For openSUSE 13.1, nothing needs to be done because OpenStack Havana packages are part of the distribution itself. The openstack-utils package contains utility programs that make installation and configuration easier. These programs are used throughout this guide. Install openstack-utils. This verifies that you can access the Open Build Service repository: # zypper install openstack-utils The openstack-config program in the openstack-utils package uses crudini to manipulate configuration files. However, crudini version 0.3 does not support multi valued options. See https://bugs.launchpad.net/openstack-manuals/+bug/1269271. As a work around, you must manually set any multi valued options or the new value overwrites the previous value instead of creating a new option. The openstack-selinux package includes the policy files that are required to configure SELinux during OpenStack installation. Install openstack-selinux. # yum install openstack-selinux Upgrade your system packages: # yum upgrade # zypper refresh # zypper update If the upgrade included a new kernel package, reboot the system to ensure the new kernel is running: # reboot The Ubuntu Cloud Archive is a special repository that allows you to install newer releases of OpenStack on the stable supported version of Ubuntu. Install the Ubuntu Cloud Archive for Havana: # apt-get install python-software-properties # add-apt-repository cloud-archive:havana Update the package database, upgrade your system, and reboot for all changes to take effect: # apt-get update && apt-get dist-upgrade # reboot The Havana release is available only in Debian Sid (otherwise called Unstable). However, the Debian maintainers of OpenStack also maintain a non-official Debian repository for OpenStack containing Wheezy backports. Install the Debian Wheezy backport repository Havana: # echo "deb http://archive.gplhost.com/debian havana-backports main" >>/etc/apt/sources.list Install the Debian Wheezy OpenStack repository for Havana: # echo "deb http://archive.gplhost.com/debian havana main" >>/etc/apt/sources.list Update the repository database and install the key: # apt-get update && apt-get install gplhost-archive-keyring Update the package database, upgrade your system, and reboot for all changes to take effect: # apt-get update && apt-get dist-upgrade # reboot Numerous archive.gplhost.com mirrors are available around the world. All are available with both FTP and HTTP protocols (you should use the closest mirror). The list of mirrors is available at http://archive.gplhost.com/readme.mirrors.

The Debian OpenStack packages are maintained on Debian Sid (also known as Debian Unstable) - the current development version. Backported packages run correctly on Debian Wheezy with one caveat: All OpenStack packages are written in Python. Wheezy uses Python 2.6 and 2.7, with Python 2.6 as the default interpreter; Sid has only Python 2.7. There is one packaging change between these two. In Python 2.6, you installed the python-argparse package separately. In Python 2.7, this package is installed by default. Unfortunately, in Python 2.7, this package does not include Provides: python-argparse directive. Because the packages are maintained in Sid where the Provides: python-argparse directive causes an error, and the Debian OpenStack maintainer wants to maintain one version of the OpenStack packages, you must manually install the python-argparse on each OpenStack system that runs Debian Wheezy before you install the other OpenStack packages. Use the following command to install the package: # apt-get install python-argparse This caveat applies to most OpenStack packages in Wheezy.

On the controller node, install the messaging queue server. Typically this is RabbitMQ Qpid but Qpid RabbitMQ and ZeroMQ (0MQ) are also available. # apt-get install rabbitmq-server # zypper install rabbitmq-server # yum install qpid-cpp-server memcached The rabbitmq-server package configures the RabbitMQ service to start automatically and creates a guest user with a default guest password. The RabbitMQ examples in this guide use the guest account, though it is strongly advised to change its default password, especially if you have IPv6 available: by default the RabbitMQ server enables anyone to connect to it by using guest as login and password, and with IPv6, it is reachable from the outside. To change the default guest password of RabbitMQ: # rabbitmqctl change_password guest RABBIT_PASS Disable Qpid authentication by editing /etc/qpidd.conf file and changing the auth option to no. auth=no To simplify configuration, the Qpid examples in this guide do not use authentication. However, we strongly advise enabling authentication for production deployments. For more information on securing Qpid refer to the Qpid Documentation. After you enable Qpid authentication, you must update the configuration file of each OpenStack service to ensure that the qpid_username and qpid_password configuration keys refer to a valid Qpid username and password, respectively. Start Qpid and set it to start automatically when the system boots. # service qpidd start # chkconfig qpidd on Start the messaging service and set it to start automatically when the system boots: # service rabbitmq-server start # chkconfig rabbitmq-server on Congratulations, now you are ready to install OpenStack services!