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-184.108.40.206. This resource starts the VIP, 220.127.116.11.
# pcs resource show ip-18.104.22.168
Resource: ip-22.214.171.124 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=126.96.36.199 cidr_netmask=32
Operations: start interval=0s timeout=20s (ip-188.8.131.52-start-interval-0s)
stop interval=0s timeout=20s (ip-184.108.40.206-stop-interval-0s)
monitor interval=10s timeout=20s (ip-220.127.116.11-monitor-interval-10s)
Now let’s actually delete it.
# pcs resource delete ip-18.104.22.168
Attempting to stop: ip-22.214.171.124…Stopped
Now lets create the replacement VIP
# pcs resource create ip-126.96.36.199 ocf:heartbeat:IPaddr2 ip=188.8.131.52 cidr_netmask=32 op monitor interval=10s
Now, let’s take a good look at it.
# pcs resource show ip-184.108.40.206
Resource: ip-220.127.116.11 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=18.104.22.168 cidr_netmask=32
Operations: start interval=0s timeout=20s (ip-22.214.171.124-start-interval-0s)
stop interval=0s timeout=20s (ip-126.96.36.199-stop-interval-0s)
monitor interval=10s (ip-188.8.131.52-monitor-interval-10s)
Now we need to check to make sure that the VIP started on one of our OpenStack controllers.
# pcs status | grep 184.108.40.206
ip-220.127.116.11 (ocf::heartbeat:IPaddr2): Started ctrl01
For good measure, let’s make sure we can ping it.
# ping 18.104.22.168
PING 22.214.171.124 (126.96.36.199) 56(84) bytes of data.
64 bytes from 188.8.131.52: icmp_seq=1 ttl=64 time=0.781 ms
64 bytes from 184.108.40.206: icmp_seq=2 ttl=64 time=1.21 ms
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
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
Now run the following commands to finalize the module installs.
Assuming that you do not run into any errors, the following modules will be installed.
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 availbile 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.
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
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.
Secondary Method – Updated 9/20/2016
You can also run the following command on your overcloud
[root@tpacpuictrl0 nova]# nova-manage –version
Now cross reference this info with this webpage.
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.
Today, August 5th, 2015, RHEL-OSP 7 goes GA. Based on the OpenStack Community release “Kilo” and featuring a new installer, OSP-director.
Check out the Red Hat’s press release below.
Red Hat Enterprise Linux OpenStack Platform 7 Now Generally Available