Building MIQ on RHEL 6.5

Does anyone have a step by step list for building MIQ on a RHEL 6 box?

This is what I used to get manageiq started:

First make sure you have the following channel enabled:

As root Build the miqbuilder user

useradd miqbuilder
passwd miqbuilder

Download and install the epel package

yum -y install epel-release-6-8.noarch.rpm

miqbuilder should be set to use sudo

sudoedit /etc/sudoers

Add the line to /etc/sudoers:  miqbuilder ALL=(ALL) ALL

yum -y install git
yum -y install libxml2-devel
yum -y install libxslt libxslt-devel
yum -y install postgresql-server postgresql-devel
yum -y install memcached

Start memcached

service memcached start
chkconfig memcached on

Initialize the db

service postgresql initdb

edit /var/lib/pgsql/data/pg_hba.conf, comment out everything and add the following line:
local all all trust

edit /var/lib/pgsql/data/postgresql.conf and add listen_address '*'

Start the db

service postgresql start

Log in as postgres generate the databases and the user.  Then assign the
Development database vmdb_development to evm

su - postgres
for i in test production development;do createdb vmdb_$i;done
psql -c "create role evm login password 'smartvm'"
psql -c "alter database vmdb_development owner to evm"

Ctrl-D Out to root again. Log in as miqbuilder

su - miqbuilder

I use rvm for development environment

\curl -sSL | bash -s stable
source ~/.profile
rvm install 1.9.3

CTRL-D out and log back in as miqbuilder. This will allow the rvm environment to load.

su - miqbuilder
rvm --default use 1.9.3

Install the bundler we will be using

gem install bundler -v '1.3.5'

Get rid of the new version of bundler because we can only use version 1.3.5

gem uninstall -i /home/miqbuilder/.rvm/gems/ruby-1.9.3-p547@global bundler -v '1.6.2'

Clone the ManageIQ repo.

cd manageiq/vmdb
bundle install --without qpid

Some places don’t allow the of git:// so you may have to…

git config --global url."https://".insteadOf git://

###Why does this next part have to be done???

cd ..
vmdb/bin/rake build:shared_objects
cd vmdb

This again to install

bundle install --without qpid

Edit the config/ file.  Add the evm user for the vmdb_develeopment database.

Initialize the database and start the service.

bin/rake db:migrate
bin/rake evm:start

Access manageiq at <IP_ADDRESS>:3000


Thanks! Those steps worked great!

Shouldn’t that be listen_addresses = '*'?

The “–without qpid” is due to a recent issue which people were having building the qpid gem - not sure exactly what the issue was.


I understand about the –without qpid

I dont understand why the below is not built during the first bundle install --without qpid

If you don’t go back down one directory and don’t ../rake build:shared_objects, then if you try the bin/rake db:migrate, you get an error. To correct it I need to do the following to build that and then it works. Why?

I also had an issue with the first rvm install - it installs sudo but behind the scenes, and it blocks waiting for the user to enter a root password we haven’t set at this point.

It’s strange, because sudo is installed, I use it to become root beforehand. The way I got around it was to set a root password in a root prompt with passwd, and re-enter that password in the “rvm install” terminal.

I figured this out - it is because sudo was getting updated. So updating sudo to the latest version should be a prerequisite before running rvm the first time.

And, to answer your question, I have no idea why you might need to run it a second time. Not a very good answer, but…

<code> </code> is inline, not a block (compare to the defaults of <span> vs. <div> or <strong> versus <p>).

Since this site supports Markdown, the best way to mark code inline is with backticks and codeblocks blocks is with GitHub style code fences comprised of backticks.

Inline code

`code here` (you can still use <code> </code> for this, but backticks are easier and cleaner, so they’re preferred when writing Markdown.

Code blocks

Code block example:

your code here

You can (usually) specify the language too, such as

echo "hello world"

This is rendered as:

echo "hello world"

…but specifying the language is optional, and there will often be a “best effort”.

Noteworthy: Four spaces

It’s also worth noting that adding four spaces in front of text without having it following a list item will indicate that it’s to be preformatted as well.

However, It doesn’t support syntax highlighting and looks a bit uglier. (See the first two blocks as examples of this. That’s how I showed a block in a block.)

So, instead of using four spaces in front of each line, you should try to use the backtick code fences.

Sounds like setting up a dev environment is pretty non-trivial. Do you know if anyone has looked into setting up vagrant [1] for the miq project?


Hi Chester,

Have a look at the “Installing and deploying from source” page linked from Community on the site.

There is a Kickstart file linked from there which automates much of the work for you.


Would people object to a Docker image with ManageIQ + PostgreSQL 9.3?

If not, how hard and fast is the Ruby 1.9.3 requirement?

I think that’d be great! I don’t know what kind of constraints there would be on performance. @Fryguy, @jrafanie, do either of you have any insight into how easy/difficult it would be to dockerize ManageIQ?

@mikaelhg ruby 1.9.3 is what we currently run and test against. Ruby 2.0/2.1 should not be difficult to get to but we have to update/audit any gems that break on 2.0, such as default_value_for. Ruby 1.8.7 was unsupported by upstream a long time ago and we make no effort to maintain compatibility since 1.8.7-> 1.9.3 is a huge change.

Regarding docker, I’m not opposed to it if we can provide reliable images. I have no background with docker but nearly everything we do to produce images in the 3 flavors is found here

The entire manageiq/build directory contains everything we use to produce these images although the above base kickstart is 99% of what you’d need.

Imagefactory, the tool we use to produce the appliance images appears to have support for docker through plugins so I’d imagine it’s very possible:

Started the work at - getting the dependencies working, then the app.

That qpid_messaging 0.20.2 gem is a pain in the ass to package.

If you need to patch it to get your own RPMs built, why not provide the gem as a Git repository that actually builds?

Note, the qpid package specifically was a pain to get working as I had to package the needed qpid client devel package which was not available on centos. I packaged them and some other ruby gem packages and use them in the kickstart here:

Is it important to have the explicit dependency to the Qpid gem, from a Red Hat product management sense, or would a dependency to a generic AMQP 1-0 gem work just as well?

@blomquisg might be able to answer your question better.

I think there were problems with a general approach because of incompatibilities in AMQP protocol support. For example RabbitMQ is based on AMQP 0.9 and Qpid is based on AMQP 0.10, but Qpid does not support anything backward compatible to 0.9. At least that’s the way it was last time we checked.

Hi @mikaelhg,

tl;dr, @Fryguy’s right, incompatible versions of AMQP require us to have separate gems for Rabbit and Qpid support.

AMQP support is tricky when we have to support more than one implementation. Since we’re talking to OpenStack’s AMQP service, we have to be able to deal with multiple AMQP implementations. For the moment we support RabbitMQ and QPid.

Unfortunately with AMQP, the protocol is not exactly backwards compatible between versions. In fact, both implementations (RabbitMQ and Qpid) go out of their way to explicitly restrict incompatible versions. And, since Rabbit implements 0.9 and QPid implements 0.10, the two implementations are incompatible.

This means that there’s no simple AMQP gem that can be used. In fact, you may find a gem called “amqp”, but it’s actually only supporting Rabbit’s implementation and will not work with Qpid.

As it stands, the qpid_messaging gem is the only gem that provides current Ruby bindings for the Qpid AMQP implementation.

Regarding AMQP 1.0 support, the problem here is OpenStack support for AMQP 1.0. Until OpenStack supports AMQP 1.0, we’re stuck supporting disparate implementations of AMQP.

Hope that helps.

Oh yay, I got it right :smile: