OpenStack Installation on RHEL7 System

There's a simple "Get Started" Guide on the redhat website, which briefly outlines how to get a sample OpenStack system up and running in 5 steps.  The first, easily overlooked step is to start by installing a "minimum-install" version of RHEL7 on a physical system.  If you've already set up and configured a system that you're using for everyday tasks and/or work functions, be aware that the installation will repeatedly fail with errors due to incompatible options, missing dependencies, etc. 

Provided that you've followed the consequent steps in the guide to register the system and enable the pertinent repositories, the next step is to install and run the packstack script:

# yum install openstack-packstack

# packstack --allinone

This is a rather lengthy python script that uses some puppet modules to install the necessary software components and configures the system as the OpenStack All-in-One server.  According to the packstack documentation, "It can be used to install each Open‐ Stack service on separate servers, an 'allinone' server, or any combination of these." Expect to wait a while for the script to finish running, meanwhile crossing your fingers that it completes successfully; otherwise, check the error output along with the error log that'll be specified in the output. 

If the packstack script finishes successfully, move on to the next step in the Guide and go to the OpenStack dashboard in your web-browser; the packstack exit status will provide the necessary instructions on how to get to the dashboard. 
Alternatively, if the script failed with errors, read on for some common troubleshoot procedures in the next section.


packstack Troubleshooting of Common Installation Errors

If you've failed to heed the advice provided in Step 1 of Red Hat's Get-Started Guide you're likely to experience failures in the packstack script. There are a number of bugs reported about the OpenStack installation script; though, a large percentage of them are, ultimately, stemming from users attempting to install OpenStack on an existing system with incompatible software packages and configurations. As frustrating as it may be, the packstack script is written so that existing software and their configurations are not forcefully erased, overwritten, or otherwise replaced. Therefore, one can also perceive it as being a safe, rather than an indiscriminately reckless approach.

According to the relevant bugs, as well as my own experience troubleshooting the installation on an existing non-"minimal-install" RHEL7.2 host, there are a few common problems that arise in this scenario. The first problem will manifest itself if the user has an existing MariaDB server installation.

MySQL Server Dependents

First, packstack may return the following error if there are installed software packages that depend on the existing MariaDB instance: 

Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.44-1.el7_1.x86_64'
 returned 1: error: Failed dependencies:
 mariadb-server is needed by (installed) akonadi-mysql-1.9.2-4.el7.x86_64
The relevant bug for this is 1268868.
The workaround for this is to remove the dependency first, e.g. akonadi-mysql or akonadi: 
# yum remove akonadi
Take care to notice if any other packages are pulled in to be removed, especially if you have a KDE Desktop Environment installed. Then, proceed as you wish, either cancel the procedure or use a different DE :D.

MySQL root Password

Next, packstack may exit with an error complaining about missing permissions if your mysql server's (MariaDB) root user is denied access without a password; in other words, you need to remove the SQL-root user's password: 

# mysqladmin -uroot -p password
This will prompt you for the current password for the mysql-root user, then the prompt will ask for the NEW password. To remove the password, simply leave the NEW password prompt empty and hit Enter. This is, obviously, a security concern; so, if you have a useful, important database already set up, think carefully before you proceed with the prvious workaround.

Apache Web Server Modules

There are potential compatibility issues with certain apache modules that packstack complains about, resulting in a non-zero exit status. Specifically, the NSS apache module, mod_nss, will cause packstack to fail. The relevant bug is Bug-1257352 on bugzilla, which is closed as NOTABUG as explained there. The workaround is to remove mod_nss package: 

# yum remove mod_nss
Alternatively, one can tell the apache server not to load the module, either by commenting out the lines in the file /etc/httpd/conf.d/nss.conf or by moving the file to a different location, temporarily.

PHP Apache Configuration

Similarly, /etc/httpd/conf.d/php.conf will cause a problem and needs to be (re)moved or otherwise indicate to the apache web server not to load the offending file, options, module.

Summary of Potential packstack Offenders

  • MariaDB
    • Software dependent on MariaDB (e.g. Akonadi)
    • root@localhost w/out password
  • Apache modules (e.g. mod_nss)
  • PHP (/etc/httpd/conf.d/php.conf)

Popular posts from this blog

Password Policy in RHEL 7

In Red Hat Enterprise Linux 7, the pam_pwquality PAM module replaced pam_cracklib, which was used in Red Hat Enterprise Linux 6 as a default module for password quality checking. It uses the same back end as pam_cracklib.
The code was originally based on pam_cracklib module, and the module is backwards compatible with its options.

The pam_pwquality module can be customized and configured in the file /etc/security/pwquality.conf. The possible options in the file are: difok Number of characters in the new password that must not be present in the old password. (default 5)

minlen Minimum acceptable size for the new password (plus one if credits are not disabled which is the default). (See pam_pwquality(8).) Cannot be set to lower value than 6. (default 9)

dcredit The maximum credit for having digits in the new password. If less than 0 it is the minimum number of digits in the new password. (default 1)

ucredit T…
Read more

Centos 7 pulseaudio

Image
Centos 7 doesn't come with an option for `awesome-wm` installation.  Therefore, the only way to make use of this light-weight tiling manager one has to enable Fedora 19 repo or build the package from source.  For the Fedora 19 repo approach, see:

https://gist.github.com/ILMostro/1909a50e1858d0ee7e10

To use without GDM, GNOME's display manager, and without gnome services, one has to be aware of certain shortcomings that the gnome-services provide by default.  One such shortcoming is the lack of built-in Sound and Volume management.  Never fret, though, as there is a solution; namely, the PulseAudio-focused tools pavucontrol and pavumeter.  These packages are available from the "nux-desktop" repository available at at http://li.nux.ro/repos.html .
nux-desktop My unofficial, as-is, not for profit RPM repositories for EL (RHEL, CentOS, ScientificLinux etc): These repos may or may not be up to date or behave the way you expect them to; use them at your OWN RISK!

Some of…
Read more

wpa_supplicant and wifi in RHEL 7

If you have a desktop environment set up in Red Hat Enterprise Linux 7, chances are that you might have GNOME installed as it is the "default".  NetworkManager is pulled in as a dependency package of GNOME and it's integrated into gnome-shell in the top panel as a widget.  While NetworkManager is a great tool as it consolidates many different networking tools and facilitates the network configuration for many different use-cases, there might be instances where its broad reach becomes an obstacle rather than a benefit to system administrators.  One such instance is when dealing with network bridging.

Recently I was trying to set up a network bridge on my laptop, as it's equipped with a wifi adapter and an ethernet adapter, in order to dedicate the ethernet interface to a virtual machine in Red Hat 7--or at least to "share" it.  Bridged networking (also known as physical device sharing) is used to dedicate a physical device to a virtual machine. 
So, since w…
Read more