Previously, I wrote a short blog post on OpenStack director, the new Red Hat installer for Openstack 7 (kilo). That post can be found here, and includes a short video introduction and demo of the new installer – RHEL OSP director.
OpenStack director introduces the concepts of an undercloud and an overcloud. These concepts derived from TripleO, AKA, OpenStack on OpenStack. It’s a bit tricky at first viewing, but once you have worked through an install or two, it makes much more sense.
That being said… In this post, I am going to provide a few helpful links that can be used to help you get started with installing OpenStack director and your OpenStack overcloud.
First, below is the link to the official installation documentation. I have been following along with this guide, in addition to my internal notes, and have found the official documentation to be very useful.
In addition to the link above, I am including the link below which directs you to the download page of the images used to build your overcloud. You are going to need these to get started, as the above guide will tell you. I figured I would provide that link as well to help move the process along. Download all three tar files.
Setting a server’s hostname used to be as simple as running the ‘hostname’ command and adding a “HOSTNAME” entry in /etc/sysconfig/network. However things have changed quite a bit in RHEL7. Apparently, systemd now controls setting a server’s hostname. The ‘hostname‘ command no longer works to set your hostname, however the command is still available just to confuse you.
Now in RHEL 7 you use the command ‘hostnamectl‘. Below is an example of how it works.
Here I have logged into my a RHEL 7.1 VM. You can see that the system appears to have the hostname of node1.
[root@node1 ~]# hostname
node1
However upon further inspection, I find that this is not the case. Rather, the server has a static hostname of localhost.localdomain.
Unless you have been using Firewalld in the last few releases of Fedora, as some out there have, then you probably could probably use a few pointers to get you started on your way to configuring your Linux firewalls the “new-fangled fancy way”. This is especially the case if you plan on moving to RHEL7 anytime soon — as Firewalld is the default there. So put on your big boy (or girl) pants and say goodbye to your old friend IPTABLES.
provides a dynamically managed firewall with support for network “zones” to assign a level of trust to a network and its associated connections and interfaces. It has support for
1
IPv4
and
1
IPv6
firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly”
Wow, how fancy. So how do we use it? Well let’s take a stab at enabling HTTP access to our Fedora21 workstation.
First thing first, lets figure out what our default done is on our workstation.
Ok, thats a bit strange, in RHEL you should expect PUBLIC to be your default zone. Now that we know what zone we need to mess with let’s make sure that its applied to the proper interfaces.
First check to see if the errata is available to your local satellite server. To accomplish this log into your organizations satellite server and click on the “Errata” tab. Then on the left side of the page click on “Advanced Search”.
In the search box enter the RHSA number (Redhat Security Advisory Number) for the errata that you want to clone/update. In this example I am searching for RHSA-2014:1924, which is a Thunderbird security update.
If your search does not return any results, you will need to manually sync your local Satellite Server with Redhat.To accomplish this you need to ssh into your local satellite server and run the command shown below. Note that this does not update any packages/errata. This does update the list of availbile packages/errata.
/usr/bin/satellite-sync [root@myserver ~]# satellite-sync –email 10:08:09 Red Hat Satellite – live synchronization 10:08:09 url: https://satellite.rhn.redhat.com 10:08:09 debug/output level: 1 ….truncated….
Once you are able to locate the specific fix in via “Erratum Search” you may proceed to the next step. In this example, as I stated above, I am searching for RHSA-2014:1924.
Now that our local Satellite server is aware of our specific errata, click on “Clone Errata” on the left side of the page. Search the page “Errata Management” for the specific fix that you want to apply. Note that the “Errata Management”page does have built in search functionality — don’t ask me why — so you must search using your browser’s own page search function.
Once you have located the correct Security Advisory, put a check in the box and spend about 5 minutes scrolling down to the bottom of the page. Stop when your arm is tired, or once you locate the “Clone Errata” button. Obviously you want to click this.
Note that your newly added and updated errata/package may not become immediatley availible to install. You nay need to run the following commands to refresh/reload your repos.
Here is my small, crude, little Kickstart configuration and post install script that I have up and running in my lab at home. Don’t expect to find anything too fancy here, as this Kickstart was purposefully built to be small and to the point. Here, the point was to spin up a VM, run through a basic install of CentOS/Redhat Linux, and install VMware Tools along with a Puppet agent.
Note that this post assumes that you have a working Kickstart server.
First lets take a look at our kickstart file, CentOS-6.6-x86_64-minimal.ks
The section directly below kicks off our kickstart ks file. Here we set our root password (no that’s not my hash) and setup our network interface for DHCP. We do a tiny bit of disk partitioning, and setup very simple LVM. Then we choose our packages. As you can see my package list is not at all fancy, I just want to make sure that I have pretty much every package that might need for a lab VM.
[code language=”bash”]
# Kickstart file for RHEL 6 Minimal
# Small Disk
text
install
url –url=http://10.1.0.106/ks/loop/CentOS-6.6-x86_64-bin-DVD1
lang en_US.UTF-8
keyboard us
network –onboot yes –device eth0 –bootproto dhcp –noipv6
rootpw –iscrypted $6$X/4YYZPN$4Sv.khxXms8N8vRssR/Vl35w/m80FF5P6p7aX0D7EFfD9p734F6tU4kXdcSCoOjPiXLrVxqfKxxxxxxxxxxxq5551
firewall –disabled
authconfig –enableshadow –passalgo=sha512
selinux –permissive
timezone America/New_York
Now let me pause to point out the section below. This is the %pre script that I am using to prompt me for the VM hostname before the install begins. The hostname needs to be set before you install puppet on the VM, otherwise you are going to have to recreate your puppet certificates after you set properly set your hostname post install and reboot.
[code language=”bash”]
%pre –log=/root/ks_pre.log
#change to tty6 to get input
chvt 6
exec </dev/tty6 > /dev/tty6
#Prompt for hostname
echo "What is my hostname?"
read NAME
echo "NETWORKING=yes
HOSTNAME=${NAME}" > network
chvt 1
[/code]
Now we run a simple post install, along with a custom post install script. It is this script that will install Vmware tools and Puppet. Myself, I prefer keeping most of my code out of the actual Kickstart ks file, however you can always jam all your code into it if you like. You will just need to validate your syntax first, as I have not tested my config this way.
[code language=”bash”]
%post –nochroot
# bring in hostname collected from %pre, then source it
cp network /mnt/sysimage/etc/sysconfig/network
. /mnt/sysimage/etc/sysconfig/network
# force hostname change
/mnt/sysimage/bin/hostname $HOSTNAME
#Post Install
%post –log=/root/ks-post.log
cd /root
echo "Getting the post install script – if this takes a long time check network or path"
wget http://10.1.0.106/ks/scripts/centos-6-postinstall.bash
echo "Running the post install script"
/bin/bash centos-6-postinstall.bash
[/code]
Ok, so below is the post install script that I am calling in the section above. After a quick modification of my hosts file, I pull down the Puppet installer from my local Puppet server. Next we install the open source VMware tools packages, after creating the required yum repofile.
#Switch to the 6th console and redirect all i/o
exec < /dev/tty6 > /dev/tty6 2> /dev/tty6
chvt 6
# Lets make sure we know who the puppet server is before we get too far
echo "Adding hosts entry for puppet master"
echo "10.1.0.115 puppet puppet.lab.localdomain" >> /etc/hosts
## Update Via Yum – not doing this for now in order to save time
#yum -y update
# Install puppet from local puppet master
echo "Downloading and running Puppet installer"
curl -k https://10.1.0.115:8140/packages/current/install.bash | sudo bash
#Install Open Source VMware Tools
rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
#Minor grub.conf modifications
sed -i ‘s/rhgb quiet//’ /boot/grub/grub.conf
sed -i ‘s/hiddenmenu//’ /boot/grub/grub.conf
sed -i ‘s/timeout=5/timeout=10/’ /boot/grub/grub.conf
#Kick off first puppet run, for some reason I think you might need to do this twice.
sleep 5
echo "Running Puppet for the first time"
puppet agent –test
puppet agent –test
#Tell us we have reached the end
echo "We have reached the end of the post-install script"
[/code]
A couple of additional details to note about the post install script above. I like to modify the grub.conf so that I unhide the menu and increase the time out. I also like to make sure that we disable the Redhat graphical boot screen… I want to make sure its easy to catch any errors or miss-configurations in my kickstarts.
As many of you know, a very useful feature of Redhat Satellite is the ability to execute remote commands on a set of servers. You pick a set of servers and plug in your command and schedule the job. Most of the time these remote commands run just fine, however they can error out if the server is not configured to allow remote command execution. Let’s discuss how to fix this.
If remote command execution is not allowed, you will probably see an error similar to those shown below,
Local permission not set for action type script.run
or
Invalid function call attempted
Note that these two error messages usually mean the same thing. You need to enable remote command execution on the remote server.
First off you need to make sure that the command rhn-actions-control is installed. If it is not then we first figure out which rpm provides the command. You can do so with the command below
# yum whatprovides */rhn-actions-control
Now that we know what to install, lets install it.
# yum -y install rhncfg-actions
Now we enable remote command execution
# rhn-actions-control –enable-all
Now you should be able to reschedule your job against the server via the webUI.
This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however, then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.
So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.
The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,
Below is my stock /etc/pam.d/system-auth file
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.
[root@ip-172-31-21-28 pam.d]# cat system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.
Here is my small, crude, little Kickstart configuration and post install script that I have up and running in my lab at home. Don’t expect to find anything too fancy here, as this Kickstart was purposefully built to be small and to the point. Here, the point was to spin up a VM, run through a basic install of CentOS/Redhat Linux, and install VMware Tools along with a Puppet agent.
