Creating and Deleting OpenStack Pacemaker IP Addresses

October 4, 2016October 4, 2016 / Christopher Paquin / Leave a comment

You can use the steps below if you need to change managed IP resources, for example, if you need to re-IP your RHEL OSP Overcloud endpoints.

In this example, we are changing a managed VIP from one IP to another.

First, we get a good look at the resource that we want to delete. Here we are going to delete the resource ip-99.239.203.25. This resource starts the VIP, 99.239.203.25.

# pcs resource show ip-99.239.203.25
Resource: ip-99.239.203.25 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=99.239.203.25 cidr_netmask=32
Operations: start interval=0s timeout=20s (ip-99.239.203.25-start-interval-0s)
stop interval=0s timeout=20s (ip-99.239.203.25-stop-interval-0s)
monitor interval=10s timeout=20s (ip-99.239.203.25-monitor-interval-10s)

Now let’s actually delete it.

# pcs resource delete ip-99.239.203.25
Attempting to stop: ip-99.239.203.25…Stopped

Now lets create the replacement VIP

# pcs resource create ip-99.239.203.10 ocf:heartbeat:IPaddr2 ip=99.239.203.10 cidr_netmask=32 op monitor interval=10s

Now, let’s take a good look at it.

# pcs resource show ip-99.239.203.10
Resource: ip-99.239.203.10 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=99.239.203.10 cidr_netmask=32
Operations: start interval=0s timeout=20s (ip-99.239.203.10-start-interval-0s)
stop interval=0s timeout=20s (ip-99.239.203.10-stop-interval-0s)
monitor interval=10s (ip-99.239.203.10-monitor-interval-10s)

Now we need to check to make sure that the VIP started on one of our OpenStack controllers.

# pcs status | grep 99.239.203.10
ip-99.239.203.10 (ocf::heartbeat:IPaddr2): Started ctrl01

For good measure, let’s make sure we can ping it.

# ping 99.239.203.10
PING 99.239.203.10 (99.239.203.10) 56(84) bytes of data.
64 bytes from 99.239.203.10: icmp_seq=1 ttl=64 time=0.781 ms
64 bytes from 99.239.203.10: icmp_seq=2 ttl=64 time=1.21 ms

RHEL 7 Two-Factor SSH Via Google Authenticator

June 28, 2016November 13, 2018 / Christopher Paquin / 11 Comments

In this post, I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2

Installation Steps

The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.

# yum -y install autoconf automake libtool

Now, we are going to install Git.

#yum -y install git

One more dependency to knock out. Install pam-devel as shown below.

# yum -y install pam-devel

Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root

# git clone https://github.com/google/google-authenticator.git
Cloning into ‘google-authenticator’…
remote: Counting objects: 1435, done.
remote: Total 1435 (delta 0), reused 0 (delta 0), pack-reused 1435
Receiving objects: 100% (1435/1435), 2.32 MiB | 0 bytes/s, done.
Resolving deltas: 100% (758/758), done.

Now change directory as shown below and run bootstrap.sh.

# cd /root/google-authenticator/libpam

# ./bootstrap.sh

Now run the following commands to finalize the module installs.

# ./configure

#make

#make install

Assuming that you do not run into any errors, the following modules will be installed.

/usr/local/lib/security/pam_google_authenticator.so
/usr/local/lib/security/pam_google_authenticator.la

Continue reading →

Red Hat OpenStack Technical Preview Features

April 12, 2016December 4, 2018 / Christopher Paquin / Leave a comment

According to this page, a Technology Preview is a feature that is currently unsupported, may not have complete functionality, and are not suitable for deployment in production. However, Red Hat provides these features and makes them available to the customer as a courtesy with the primary goal of exposing the feature to a wider audience.

I am quite often asked by my clients, which features are in tech preview for each release. Instead of spending time looking these things up each time I figured I would document them here.

How to Determine Installed OpenStack director Version

March 24, 2016June 12, 2017 / Christopher Paquin / Leave a comment

Trying to determine that version of Red Hat OpenStack director that is installed on an Undercloud Controller is not as straight forward as one would hope.

I have created the simple table below that you can use to determine your installed director version via the installed version of the openstack-tripleo-heat-templates rpm.

Minimum RPM Version	Release Date	director Version
openstack-tripleo-heat-templates-0.8.6-123.el7ost	UNK	7.3.1
openstack-tripleo-heat-templates-0.8.6-94.el7ost.noarch.rpm	2015-12-16	7.2
openstack-tripleo-heat-templates-0.8.6-71.el7ost.noarch.rpm	2015-10-05	7.1
openstack-tripleo-heat-templates-0.8.6-45.el7ost.noarch.rpm	2015-07-30	7.0
openstack-tripleo-heat-templates-0.8.14-11.el7ost.noarch	2016-04-20	8.0
oopenstack-tripleo-heat-templates-2.0.0-41.el7ost.noarch	??	9.0
openstack-tripleo-heat-templates-5.2.0-15.el7ost.noarch	??	10.0
openstack-tripleo-heat-templates-6.0.0-10.el7ost.noarch	??	11.0

Hopefully, in the near future, we will see an rpm similar to redhat-release-server (the rpm that create /etc/redhat-release) included in future OSP director updates. Until then, this table should be of some assistance.

Related Bugzillas

https://bugzilla.redhat.com/show_bug.cgi?id=1295512

https://bugzilla.redhat.com/show_bug.cgi?id=1085625

Secondary Method – Updated 9/20/2016

You can also run the following command on your overcloud

[root@tpacpuictrl0 nova]# nova-manage –version
2015.1.3

Now cross reference this info with this webpage.

https://wiki.openstack.org/wiki/Releases

CEPH: How to Restart an Install, or How to Reset a Cluster

August 18, 2015August 18, 2015 / Christopher Paquin / Leave a comment

Hey, are you installing CEPH in your test lab and you screwed it up, or something has gone wrong with your test cluster and you want to start over? Well, the instructions on how to do this are below.

Note that most of this process is actually well documented, but I added in a few extra steps good to run if you want to start from scratch without having to reinstall an OS.

First remove all CEPH rpms from your CEPH hosts, this includes Monitor nodes and OSD nodes. Note that I am in /root/ceph-deploy on my monitor/admin server. If you have separate admin and monitor nodes then run these commands from your admin node.

# ceph-deploy purge mon01 osd01 osd02 osd03

Now purge all config files.

# ceph-deploy purgedata mon01 osd01 osd02 osd03

Now remove all keys

# ceph-deploy forgetkeys

Now delete any remaining files or keys from /root/ceph-deploy, if there are any files in here that you may want to keep, just copy them to /root.

# rm -rf /root/ceph-deploy/*

Now remove Calamari. Note: that in my test lab I am running Calamari on my one MON node which also happens to be my admin node, so I run this command there

#yum remove ceph-deploy calamari-server calamari-clients

You can now start over. I am installing Red Hat Ceph 1.3, so I am using the instructions here.

You might also want to uninstall salt from your servers. If that’s the case just look for any of the packages below and rip them out. Your versions will vary.