Calgary RHCE

A linux and open source technology blog.

Connect

Making email a little more secure

By Leave a Comment

Every so often I try to make an effort to increase the security surrounding the technology I use. Its usually after I read a notable CVE bulletin, or hear of the latest hack. I’ve been wanting a more secure solution to webmail for the longest time, but knew I didn’t have many options if I enjoyed using webmail clients. They’re just so darn convenient. After enabling two-factor authentication on everything I could, I still was looking for a better solution for encrypted email. I like the project mailpile, but they’re not as far along yet in features for my needs. (Consider donating if you value secure email!) I ended up going back to a local mail client (Thunderbird), which I’ve connected to my webmail accounts, and downloaded the Enigmail add-on for OpenPGP encryption and digital signing.

Once I installed the add-on, it was pretty easy to get started. There’s a setup wizard that will either create you a new PGP/GPG2 key, or you can select to use an existing key already:

enigmail-wizard

I selected advanced, and picked an existing GPG2 key I have already. It imported it in one step, and I was ready to go. Next, a test email to myself to test enabling a digital signature (I had to manually accept my own key as “trusted” once I received the mail):

And writing an encrypted mail was just as easy:

The Enigmail plugin makes it easy to add others to your GPG circle of trust, and GPG2 encrypted email is a now click away.

Filesystem benchmarking

By Leave a Comment

Once in a while I need to do some I/O benchmarking. Either when creating a baseline for a before and after performance tuning comparison, or just because I want to see how fast my new SSD/M.2 really is. The tool I find myself going to over the years has been iozone. I like it because it easily does a myriad of tests that I don’t need to create or think about how to simulate myself, and it’s easily installed on any linux distro. It also outputs the test data into a format that is easily imported into a spreadsheet. I recently added a couple SSDs to my workstation, and finally got around to benchmarking them.

IOzone has a slew of pre-built tests you can run, but I typically just do 5 (read, random read, write, random write, and stride read). From the iozone help:

Within each test you can also specify the record size, and file size to be written. This is my usual test syntax:

… and so on as it goes through all of the test scenarios. At the end, I’m given a nicely formatted spreadsheet that’s easy to make graphs from:

iozone graph output

Looking at my read stats, at the peak, I’m getting just over 20 GB/sec. However, the average seems to be about 12-14 GB/sec. Not too shabby! (I’ve got a few SSDs in a RAID1 array). Full test details are in a spreadsheet on github.

 

Installing OpenStack – setting up a virtual lab environment

By 1 Comment

When talking TripleO, there’s two concepts introduced called the “undercloud”, and the “overcloud”. These are essentially the labels for each OpenStack environment when referring to “OpenStack on OpenStack” (TripleO). The undercloud is the OpenStack server that manages and deploys the more publicly consumable overcloud servers that make up the OpenStack environment that we’re after. Confused yet? 🙂 Marcos Garcia does a good job of illustrating this in a blog post:

undercloud-vs-overcloud

To start with our OpenStack deployment, we’ll first start with setting up the undercloud server.  We’re basically going to run through the recommended 10 node deployment in the Director installation guide. I’m using the latest RHEL7.2 as my OS, and have created a VM with the following specs:

  • 16 GB RAM
  • 8 vCPUs
  • 80 GB disk
  • 2 NICs, (one for a provisioning network, one for an external network)

I’ll be using libvirt/KVM to set this up. I’ve created a linux bridge on my physical server, then have created a libvirt network on top of that. This network will be my provisioning network, and the linux bridge on it’s own will act as the external network for my OpenStack environment. We’re basically going with a single NIC deployment for simplicity sake, and are simulating trunking all the networks through this NIC, each with respective subnets. Don’t worry about that for now, more on that later. Make sure DHCP is disabled on the provisioning network:

(Or if you’re a GUI person):

virtual-network

While that covers the undercloud VM, let’s now create the overcloud VMs. We’re going to be using 3 controllers, 3 computes, and 3 ceph storage nodes for our deployment. They’ll have the following specs:

  • Controller: 1 vCPU, 6 GB RAM, 40 GB disk, 2 NICs (first NIC is on the provisioning network, second is on the linux bridge)
  • Compue: 4 vCPU, 6 GB RAM, 40 GB disk, 1 NIC (provisioning network)
  • Storage: 1 vCPU, 6 GB RAM, 40 GB disk (OS), 8 GB disk (simulate ceph journal SSD), 100 GB disk (ceph osd), 1 NIC (provisioning network)

The reason we’re using 3 of each node is that it gives you true high availability with the controllers, as well as as much of a simulation of real world compute and software-defined-storage functionality. On your physical server, you want to make sure that virtualization extensions are enabled in the BIOS, and on your compute nodes you either inherit the host’s CPU characteristics, or you manually enable nested virtualization. This isn’t necessary for the overcloud deployment itself, but it is necessary to create an instance inside the OpenStack environment.

To enable nested virtualization, on both the hypervisor and compute nodes set this value in/etc/modprobe.d/kvm.conf

To see if nested virtualization is enabled:

Once your undercloud VM is installed with the latest RHEL, you can continue with the steps in Chapter 4 of the install guide. Setup the stack user, create two directories, validate the hostname is set, register your system, enable the proper repos, update and reboot:

Then, install the director (TripleO) packages:

The undercloud.conf file is where we make the configuration settings for the undercloud openstack environment. You can read through the guide for more details, but my undercloud.conf file looks like this. I’ve copied the default in, and grep’d out my changes. With my network gateway the first IP of my provisioning network (172.16.108.1), I’ve set that, as well as the undercloud server IP (172.16.108.2), and the remaining settings you can read. An important setting to note is the local_interface is set to the provisioning NIC on my VM (eth0 in this case, eth1 is my external linux bridge network):

Now that we’ve specified the undercloud’s configuration, we can run the install command that will install and setup the undercloud OpenStack software. Before we do this, I recommend taking a snapshot of the VM for easy rollback capability. You might decide later that you’ve made a configuration mistake, or that you want to redeploy from scratch. Regarding the overall networking layout, essentially what we’re deploying is this:

openstack-network

Nic 1 on each node is essentially acting as a trunk, carrying all the types of traffic in the OpenStack environment that aren’t on the external network. In an actual production deployment, you may want to separate these out further into their own physical networks, bonds, VLANs, etc. But for our purposes, everything is going to be on one NIC, in the 172.16.108.0/24 subnet. Because we’re using a virtual environment, we’re also omitting the IPMI network. Our node out-of-band management is going to be handled by the pxe_ssh driver. With this driver, the undercloud uses virsh to control the power management of our VMs.

Finally, after several minutes, you should see a successful installation complete message:

Congratulations, TripleO has been installed and configured. We’re ready to start the configuration of the overcloud nodes. Next post, I will get into the heat templates required to do this, and some notable configuration items in them.