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

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 yo
Read more

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
Read more

RHEL 7 and CentOS 7 syslog Rate Limit

https://access.redhat.com/solutions/1417483 In RHEL 7 there is rate-limiting both in systemd-journald and in rsyslog's imjournal module Lower Ratelimit Interval Lower the interval for rate-limiting and increase the burst level in order to minimize the possibility of losing log messages when the threshold is reached for the specified number of messages logged within the specified interval. Rate-limiting is specific to each process, so there's usually no reason to change this. It is also inadvisable to disable this feature entirely! grep -i rate /etc/systemd/journald.conf #RateLimitInterval=30s #RateLimitBurst=1000 RateLimitInterval=10s RateLimitBurst=3000 grep -i rate /etc/rsyslog.conf #$imjournalRatelimitInterval 600 <--default $imjournalRatelimitInterval 300 $imjournalRatelimitBurst 30000 journal corruption journalctl --verify journalctl --force
Read more