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

Password Aging and Authentication in RHEL7

As I posted in a previous note, the password policy in RHEL 7, and most other linux distributions, is handled by the dynamically-configurable PAM (Pluggable Authentication Modules) system. However, there are a number of other tools implemented in securing the RHEL system. One such tool is the shadow password suite. The shadow suite creates an additional layer of abstraction for the system's login passwords, by removing the account passwords from the /etc/passwd file to a separate file /etc/shadow;while maintaining the unobstructed use of the rest of the accounts system. The Linux Documentation Project explains it: the password is stored as a single "x" character (ie. not actually stored in this file). A second file, called ``/etc/shadow'', contains encrypted password as well as other information such as account or password expiration values, etc. The /etc/shadow file is readable only by the root account and is therefore less of a security risk.
According t…
Read more