OSS

You are currently browsing articles tagged OSS.

Recently a couple of open source software (OSS)-related announcements have passed through my Inbox, so I thought I’d make brief mention of them here on the site.

Mirantis OpenStack

Last week Mirantis announced the general availability of Mirantis OpenStack, its own commercially-supported OpenStack distribution. Mirantis joins a number of other vendors also offering OpenStack distributions, though Mirantis claims to be different on the basis that its OpenStack distribution is not tied to a particular Linux distribution. Mirantis is also differentiating through support for some additional projects:

  • Fuel (Mirantis’ own OpenStack deployment tool)
  • Savanna (for running Hadoop on OpenStack)
  • Murano (a service for assisting in the deployment of Windows-based services on OpenStack)

It’s fairly clear to me that at this stage in OpenStack’s lifecycle, professional services are a big play in helping organizations stand up OpenStack (few organizations lack the deep expertise to really stand up sizable installations of OpenStack on their own). However, I’m not yet convinced that building and maintaining your own OpenStack distribution is going to be as useful and valuable for the smaller players, given the pending competition from the major open source players out there. Of course, I’m not an expert, so I could be wrong.

Inktank Ceph Enterprise

Ceph, the open source distributed software system, is now coming in a fully-supported version aimed at enterprise markets. Inktank has announced Inktank Ceph Enterprise, a bundle of software and support aimed to increase adoption of Ceph among enterprise customers. Inktank Ceph Enterprise will include:

  • Open source Ceph (version 0.67)
  • New “Calamari” graphical manager that provides management tools and performance data with the intent of simplifying management and operation of Ceph clusters
  • Support services provided by Inktank; this includes technical support, hot fixes, bug prioritization, and roadmap input

Given Ceph’s integration with OpenStack, CloudStack, and open source hypervisors and hypervisor management tools (such as libvirt), it will be interesting to see how Inktank Ceph Enterprise takes off. Will the adoption of Inktank Ceph Enterprise be gated by enterprise adoption of these related open source technologies, or will it help drive their adoption? I wonder if it would make sense for Inktank to pursue some integration with VMware, given VMware’s strong position in the enterprise market. One thing is for certain: it will be interesting to see how things play out.

As always, feel free to speak up in the comments to share your thoughts on these announcements (or any other related topic). All courteous comments are welcome.

Tags: , , ,

A short while ago I posted an article that described how to use Puppet for account management. In that article, I showed you how to use virtual user resources to manage user accounts on Puppet-managed systems. In this post, I’m going to expand on that configuration so that we can also manage the initial account configuration files, and do so in the proper order.

One of the things the configuration in my first post didn’t handle was the Puppet configuration of the files in /etc/skel and making sure those files were in place before the user accounts were created. As a result, it was possible that the user account could be created on a system before the /etc/skel files were updated, and then that user account would have “unmanaged” copies of the initial configuration files. Further Puppet agent runs wouldn’t correct the problem, because the files in /etc/skel are only copied over when the account is created. If the account has already been created, then it’s too late—the files in /etc/skel must be managed before the accounts are. To fix the issue, you have to ensure that the resources are processed in a specific manner. In this post, I’ll show you how to manage that.

There are two parts to extending the Puppet accounts module to also manage some configuration files:

  1. Add a subclass to manage the files.
  2. Create a dependency between the virtual user resources and this new subclass.

Let’s look at each of these.

Adding a Subclass

To add a subclass to manage the configuration files, I created config.pp and placed it in the manifests folder for the accounts module. Here’s a simplified look at the contents of that file:

This is pretty straightforward Puppet code; it creates a managed file resource and specifies that the file be sourced from the Puppet master server. The full and actual accounts::config subclass that I’m using has a number of managed file resources, including files in /etc/skel, but I’ve omitted that here for the sake of brevity. (The other file resources that are defined look very much like the example shown, so I didn’t see any point in including them.) The config.pp also uses some values from an accounts::params subclass and some conditionals to manage different files on different operating systems.

To really put the subclass to work, though, we have to include it elsewhere. So, in the accounts module’s init.pp, we add a line that simply states include accounts::config. However, the problem that occurs if you stop there is the problem I described earlier: Puppet might create the user account before it places the file resources under management, and then the user account won’t get the updated/managed files.

To fix that, we create a dependency.

Creating a Dependency

Before running into this situation, I was pretty familiar with creating dependencies. For example, if you were defining a class for a particular daemon to run on Linux, you might use the Puppet package-file-service “trifecta”, and you might include a dependency, like this (entirely fictional) example. Note in this example that the file resource is dependent on the package resource, and the service resource is dependent on the file resource (as denoted by the capitalized Package and File instances):

(My apologies if my syntax for this fictional example isn’t perfect—I didn’t run it through puppet-lint.)

The problem in this particular case, though, is that I didn’t need a dependency on a single file; I needed a dependency on a whole group of files. To further complicate matters, the files on which the dependency existed might change between operating systems. For example, I might (and do) have different files on RHEL/CentOS than on Ubuntu/Debian. So how to accomplish this? The answer is actually quite simple: create a dependency on the subclass, not the individual resources.

So, without the dependency, the code to define the virtual users looked like this:

With the dependency, the code to define the virtual users looks like this:

The only difference between the two (other than changes in the comments at the top) is the addition of the require statement, which creates a dependency not on a single resource but instead to an entire subclass—the accounts::config subclass, which in turn has a variety of file resources that are managed according to operating system.

It’s such a simple solution I can’t believe I didn’t see it at first, and when it was pointed out to me (via the #puppet IRC channel, thanks), I had a “Duh!” moment. Even though it is a simple and straightforward solution, if I overlooked it then others might overlook it as well—a problem that hopefully this blog post will help fix.

As always, I welcome feedback from readers, so feel free to weigh in with questions, clarifications, or corrections. Courteous comments are always welcome!

Tags: , , ,

In this third post on using Mock to build RPMs for CentOS 6.3, I’m going to show you how to use Mock to build RPMs for Libvirt 1.0.1 that you can install on CentOS. As you’ll see later, this post builds on the previous two posts (one on using Mock to build RPMs for sanlock 2.4 and one on using Mock to build RPMs for libssh2 1.4.1).

Here’s a quick overview of the process:

  1. Set up Mock and the environment.
  2. Install prerequisites into the Mock environment.
  3. Build the Libvirt RPMs.

Let’s take a closer look at each of these steps.

Setting Up Mock and the Environment

The first phase in the process is to set up Mock and the environment for building the RPMs. Fortunately, this is relatively simple.

First, activate EPEL. My preferred method for activating the EPEL repository is to download the RPM, then use yum localinstall to install it, like this:

wget http://fedora.mirrors.pair.com/epel/6/i386/\
epel-release-6-8.noarch.rpm
yum localinstall epel-release-6-8.noarch.rpm

(Note that I’ve line-wrapped the URL with a backslash to make it more readable. That line-wrapped command actually works just as it is in the shell as well.)

Next, you’ll need to install Mock and related RPM-building tools:

yum install fedora-packager

Third, create a dedicated user for building RPMs. I use “makerpm” as my username, but you could use something else. Just make sure that the name makes sense to you, and that the new user is a member of the mock group:

useradd makerpm -G mock
passwd makerpm

From this point on, you’ll want to be running as this user you just created, so switch to that user with su - makerpm. This ensures that the RPMs are built under this dedicated user account.

The final step in setting up Mock and the build environment is to run the following command while running as the dedicated user you created:

rpmdev-setuptree

Now you’re ready to move on to the next phase: installing prerequisites into the Mock environment.

Installing Prerequisites Into the Mock Environment

One of the great things about Mock is that it creates an isolated chroot into which it installs all the necessary prerequisites for a particular package. This helps ensure that the package’s dependencies are managed correctly. However, if you are trying to build a package where dependencies don’t exist in the repositories, then you have to take a few additional steps. When you’re trying to build libvirt 1.0.1 RPMs for use with CentOS 6.3, you’ll find yourself in exactly this situation. Libvirt has dependencies on newer versions of sanlock-devel and libssh2-devel than are available in the repositories.

Fortunately, there is a workaround—and here’s where those other posts on Mock will come in handy. Use the instructions posted here to build RPMs for sanlock 2.4, and use the instructions here to build RPMs for libssh2 1.4.1.

Once the RPMs are built (and they should build without any major issues, based on my testing), then use these commands to get them into the isolated Mock environment (I’ve line-wrapped here with backslashes for readability):

mock -r epel-6-x86_64 --init
mock -r epel-6-x86_64 --install \
~/rpmbuild/RPMS/sanlock-lib-2.4-3.el6.x86_64.rpm \
~/rpmbuild/RPM/sanlock-devel-2.4-3.el6.x86_64.rpm \
~/rpmbuild/RPMS/libssh2-1.4.1-2.el6.x86_64.rpm \
~/rpmbuild/RPMS/libssh2-devel-1.4.1-2.el6.x86_64.rpm

This will install these packages into the Mock environment, not onto the general Linux installation.

Once you’ve gotten these packages compiled and installed, then you’re ready for the final phase: building the libvirt RPMs.

Building the Libvirt RPMs

As in my earlier post on compiling Libvirt 1.0.1 RPMs for CentOS 6.3, this final step is almost anti-climactic. That’s good, though, because it means you’ve done all the previous steps perfectly.

First, fetch the source RPM from the libvirt HTTP server:

wget http://libvirt.org/sources/libvirt-1.0.1-1.fc17.src.rpm

Next, move the source RPM into the ~/rpmbuild/SRPMS directory:

mv libvirt-1.0.1-1.fc17.src.rpm ~/rpmbuild/SRPMS

Finally, run Mock to rebuild the RPMs:

mock -r epel-6-x86_64 --no_clean ~/rpmbuild/SRPMS/libvirt-1.0.1-1.fc17.src.rpm

Note that the --no-clean parameter is required here to prevent Mock from cleaning out the chroot and getting rid of the packages you installed into the environment earlier.

This command should run without any errors or problems, and produce a set of RPMs (typically) found in /var/lib/mock/epel-6-x86_64/results. You can then take these RPMs and install them on another CentOS 6.3 system using yum localinstall.

Testing the RPMs

To verify that everything worked as expected, I tested the RPMs using these steps:

  1. Using a clean CentOS 6.3 VM (built using the “Minimal Desktop” option), I used yum groupinstall to install the Virtualization, Virtualization Client, Virtualization Platform, and Virtualization Tools groups. This installed version 0.9.10 of libvirt.

  2. I then installed the updated version of libvirt using yum localinstall. I had to specify the dependencies manually on the command line; I anticipate that had I been using a real repository, this would not have been the case. The updated libvirt, sanlock, and libssh2 packages all installed correctly.

  3. I started the libvirtd service (it worked), and ran virsh --version. It returned version 1.0.1.

I imagine there might be more comprehensive/better ways of testing the RPMs that I built, but they seemed to work fine on my end. If anyone has any other suggestions for how we can double-check to ensure the packages are working correctly, feel free to speak up in the comments below. I also welcome any other corrections, suggestions, or questions in the comments. Courteous comments are always welcome.

Tags: , , , , ,

As with the related post on using Mock to rebuild sanlock 2.4 for CentOS 6.3, this post might seem a bit odd. Don’t worry—I’ll tie it into something else very soon. In this post, I’ll show you how to use Mock to build RPMs for libssh2 1.4.1 for use with CentOS 6.3.

The information in this post is based on information found in two other very helpful pages:

Using Mock to test package builds
How to rebuild a package from Fedora or EPEL for RHEL, CentOS, or SL

I tested these instructions on a newly-built CentOS 6.3 VM, installed using the “Minimal Desktop” option. I haven’t tested it on other RHEL variants or other versions, so keep that in mind.

First, you’ll want to activate EPEL. You’ll do that by downloading the RPM and using yum localinstall to install it. You can also use rpm to install it directly from the URL, but I prefer using yum localinstall. I’ve line-wrapped the EPEL URL with a backslash for readability.

wget http://fedora.mirrors.pair.com/epel/6/i386/\
epel-release-6-8.noarch.rpm
yum localinstall epel-release-6-8.noarch.rpm

Once EPEL is installed, then install Mock and related tools:

yum install fedora-packager

This will download and install Mock and related tools such as rpmbuild.

Next, create a user under which you’ll run all these commands, and make sure this account is a member of the mock group:

useradd makerpm -G mock
passwd makerpm

From here on, you’ll want to be running as this user you just created, so switch to that user with su - makerpm.

The first step while running as the user you created is to setup the RPM build environment:

rpmdev-setuptree

Now that the directory structure is created, use wget to download the source RPM for libssh2 1.4.1-2 from the Fedora 17 release repository (the URL is line-wrapped here for readability):

wget http://dl.fedoraproject.org/pub/fedora/linux/releases/17\
/Everything/source/SRPMS/l/libssh2-1.4.1-2.fc17.src.rpm

Move the source RPM to the rpmbuild/SRPMS directory:

mv libssh2-1.4.1-2.fc17.src.rpm ~/rpmbuild/SRPMS

And, finally, rebuild the RPMs with mock:

mock --rebuild ~/rpmbuild/SRPMS/libssh2-1.4.1-2.fc17.src.rpm

Assuming everything completes successfully (it did on my CentOS 6.3 VM), then you’ll end up with a group of RPMs found in /var/lib/mock/epel-6-x86_64/results (the exact directory will vary based on OS version and build; I was using 64-bit CentOS 6.3). You should then be able to install those RPMs onto a CentOS 6.3 system using yum localinstall and the prerequisites will be managed properly.

Have fun!

Tags: , ,

The topic of this post might seem a bit strange, but it will all make sense later. In this post, I’ll show you how to use Mock to build RPMs for sanlock 2.4 for use with CentOS 6.3.

The information in this post is based on information found in two other very helpful pages:

Using Mock to test package builds
How to rebuild a package from Fedora or EPEL for RHEL, CentOS, or SL

I tested these instructions on a newly-built CentOS 6.3 VM, installed using the “Minimal Desktop” option. I haven’t tested it on other RHEL variants or other versions, so keep that in mind.

First, you’ll want to activate EPEL. You’ll do that by downloading the RPM and using yum localinstall to install it. You can also use rpm to install it directly from the URL, but I prefer using yum localinstall. (Note that the URL for the EPEL RPM is line-wrapped here for readability.)

wget http://fedora.mirrors.pair.com/epel/6\
i386/epel-release-6-8.noarch.rpm
yum localinstall epel-release-6-8.noarch.rpm

Once EPEL is installed, then install Mock and related tools:

yum install fedora-packager

This will download and install Mock and related tools such as rpmbuild.

Next, create a user under which you’ll run all these commands, and make sure this account is a member of the mock group:

useradd makerpm -G mock
passwd makerpm

From here on, you’ll want to be running as this user you just created, so switch to that user with su - makerpm.

The first step while running as the user you created is to setup the RPM build environment:

rpmdev-setuptree

Now that the directory structure is created, use wget to download the source RPM for sanlock 2.4-3 from the Fedora 17 update repository (the URL is line-wrapped here for readability):

wget http://dl.fedoraproject.org/pub/fedora/linux/updates\
/17/SRPMS/sanlock-2.4-3.fc17.src.rpm

Move the source RPM to the rpmbuild/SRPMS directory:

mv sanlock-2.4-3.fc17.src.rpm ~/rpmbuild/SRPMS

And, finally, rebuild the RPMs with mock:

mock --rebuild ~/rpmbuild/SRPMS/sanlock-2.4-3.fc17.src.rpm

Assuming everything completes successfully (it did on my CentOS 6.3 VM), then you’ll end up with a group of RPMs found in /var/lib/mock/epel-6-x86_64/results (the exact directory will vary based on OS version and build; I was using 64-bit CentOS 6.3). You should then be able to install those RPMs onto a CentOS 6.3 system using yum localinstall and the prerequisites will be managed properly.

Enjoy!

Tags: , ,

In previous articles, I’ve shown you how to compile libvirt 0.10.1 on CentOS 6.3, but—as several readers have pointed out in the comments to that and other articles—compiling packages from source may not be the best long-term approach. Not only does it make it difficult to keep the system up-to-date, it also makes automating the configuration of the host rather difficult. In this post, I’ll show you how to rebuild a source RPM for libvirt 1.0.1 so that it will install (and work) under CentOS 6.3. (These instructions should work for RHEL 6.3, too, but I haven’t tested them.)

Overview

The process for rebuilding a source RPM isn’t too terribly difficult, assuming that you can get the dependencies worked out. Here’s a quick look at the steps involved:

  1. Create a set of build directories for source RPMs.
  2. Download the source RPM and install all prerequisites/dependencies onto the system.
  3. Rebuild the source RPM for the destination system.

Let’s take a look at each of these steps in a bit more detail.

Create the Build Environment

The CentOS wiki has a great page for how to set up an RPM build environment. I won’t repeat all the steps here (refer to the wiki page instead), but here’s a quick summary of what’s involved:

  1. Install the necessary packages (typically you’ll need the rpmbuild, redhat-rpm-config, make, and gcc packages). You might also need certain development libraries, but this will vary according the source RPMs you’re rebuilding (more on that in the next section).
  2. Create the necessary directories under your home directory.

I’ll assume that you’ve followed the steps outlined in the CentOS wiki to set up your environment appropriately before continuing with the rest of this process.

Download the Source RPM and Install Prerequisites

The libvirt 1.0.1 source RPMs are available directly from the libvirt HTTP server, easily downloaded with wget:

wget http://libvirt.org/sources/libvirt-1.0.1-1.fc17.src.rpm

You can just download the source RPM to your home directory. Before you can build a new RPM from the source RPM, though, you’ll first need to install all the various prerequisites that libvirt requires. Most of them can be installed easily using yum with a command like this:

yum install xhtml1-dtds augeas libudev-devel \
libpci-access-devel yajl-devel, libpcap-devel libnl-devel \
avahi-devel radvd ebtables qemu-img iscsi-initiator-utils \
parted-devel device-mapper-devel numactl-devel netcfg-devel \
systemtap-sdt-devel scrub numad libblkid-devel

There are two dependencies, though—sanlock and libssh2—that require versions newer than what are available in the CentOS/EPEL repositories. For those, you’ll need to recompile your own RPMs. Fortunately, this is pretty straightforward. The next two sections provide more details on getting these prerequisites handled.

Building an RPM for sanlock

To build a CentOS 6.3 RPM for version 2.4 of sanlock (the minimum version needed by libvirt 1.0.1), first use wget to download a Fedora 17 version of the source RPM. I’ve wrapped the URL with a backslash for readability:

wget http://dl.fedoraproject.org/pub/fedora/linux/updates/17/SRPMS\
/sanlock-2.4-3.fc17.src.rpm

Next, install an prerequisite library using yum install libaio-devel.

Finally, use rpmbuild to rebuild the sanlock source RPM:

rpmbuild --rebuild sanlock-2.4-3.fc17.src.rpm

This process should proceed without any problems. The resulting RPMs that are created will be found in ~/rpmbuild/RPMS/x86_64 (assuming you are, as I am, using a 64-bit build of CentOS).

Building the RPMs, however, isn’t enough—you need to install them so that you can build the libvirt RPMs. So install the sanlock-devel and sanlock-lib RPMs using yum locainstall (do this command from the directory where the RPMs reside):

yum localinstall sanlock-devel-* sanlock-lib-*

That should take care of the sanlock dependency.

Building an RPM for libssh2

To build a CentOS 6.3 RPM for version 1.4.1 of libssh2 (libvirt 1.0.1 requires at least version 1.3.0), first download the source RPM using wget (I’ve wrapped the URL here for readability):

wget http://dl.fedoraproject.org/pub/fedora/linux/releases\
/17/Everything/source/SRPMS/l/libssh2-1.4.1-2.fc17.src.rpm

(That’s a lowercase L in the URL just after SRPMS.)

Once you have the source RPM downloaded, then just rebuild the source RPM:

rpmbuild --rebuild libssh2-1.4.1-2.fc17.src.rpm

Then install the resulting RPMs using yum localinstall:

yum localinstall libssh2-1.4.1-* libssh2-devel-*

That takes care of the last remaining dependency. You’re now ready to compile the RPMs for libvirt 1.0.1.

Build the Libvirt RPM

This part is almost anticlimactic. Just use the rpmbuild command:

rpmbuild --rebuild libvirt-1.0.1-1.fc17.src.rpm

If you’ve successfully installed all the necessary prerequisites, then the RPM compilation process should proceed without any issues.

Once the RPM compilation process is complete, you’ll find libvirt 1.0.1 RPMs in the ~/rpmbuild/RPMS/x86_64 directory (assuming a 64-bit version of CentOS) which you can easily install with yum localinstall, or post to your own custom repository.

I hope this post helps someone. If you have any questions, or if you spot an error, please speak up in the comments below. All courteous comments are welcome!

Tags: , , , ,

It’s no secret that I’ve been spending time over the last few months working with a number of open source technologies like KVM, Open vSwitch (OVS), and libvirt, all building up to a focus on how these pieces fit together as part of OpenStack. To help strengthen my OpenStack skills, I picked up a copy (actually my wife Crystal bought me a copy) of Kevin Jackson’s OpenStack Cloud Computing Cookbook, a book that I’ve been working my way through. So far, it’s been great—I highly recommend it.

Now I have the opportunity to help five lucky readers win a copy (either electronic or print) of OpenStack Cloud Computing Cookbook, courtesy of Packt Publishing. Sweet, eh?

It’s pretty easy to be entered to win. Here’s how:

  1. First, head over to the book’s web site at Packt Publishing. Read through the description of the book. You can even download a copy of Chapter 3 as a sample chapter for you to read.

  2. Once you’ve read through the description of the book, post a comment here on this site telling me what you find most interesting about the book. That’s it!

Five lucky winners will be selected to receive their choice of either an electronic copy of the book or a print copy of the book. Please note that winners from the US and Europe can choose from either print or electronic versions of the book; winners from all other areas are limited to the electronic version only.

The deadline to post your comment and be entered to win is January 15, 2013. Winners will be notified via e-mail, so be sure to use a valid e-mail address when you post your comment.

Good luck!

Tags: ,

A short while ago, I talked about how to add client-side encryption to Dropbox using EncFS. In that post, I suggested using BoxCryptor to access your encrypted files. A short time later, though, I uncovered a potential issue with (what I thought to be) BoxCryptor. I have an update on that issue.

In case you haven’t read the comments to the original BoxCryptor-Markdown article, it turns out that the problem with using Markdown files with BoxCryptor doesn’t lie with BoxCryptor—it lies with Byword, the Markdown editor I was using on iOS. Robert, founder of BoxCryptor, suggested that Byword doesn’t properly register the necessary handlers for Markdown files, and that’s why BoxCryptor can’t preview the files or use “Open In…” functionality. On his suggestion, I tried Textastic.

It works flawlessly. I can preview Markdown files in the iOS BoxCryptor client, then use “Open In…” to send the Markdown files to Textastic for editing. I can even create new Markdown files in Textastic and then send them to BoxCryptor for encrypted upload to Dropbox (where I can, quite naturally, open them using my EncFS filesystem on my Mac systems). Very nice!

If you are thinking about using EncFS with Dropbox and using BoxCyrptor to access those files from iOS, and those files are text-based files (like Markdown, plain text, HTML, and similar file formats), I highly recommend Textastic.

Tags: , , , ,

About a week ago, I published an article showing you how to use EncFS and BoxCryptor to provide client-side encryption of Dropbox data. After working with this configuration for a while, I’ve run across a problem (at least, a problem for me—it might not be a problem for you). The problem lies on the iPad end of things.

If you haven’t read the earlier post, the basic gist of the idea is to use EncFS—an open source encrypting file system—and OSXFUSE to provide file-level encryption of Dropbox data on your OS X system. This is client-side encryption where you are in the control of the encryption keys. To access these encrypted files from your iPad, you’ll use the BoxCryptor iOS client, which is compatible with EncFS and decrypts the files.

Sounds great, right? Well, it is…mostly. The problem arises from the way that the iPad handles files. BoxCryptor uses the built-in document preview functionality of iOS, which in turn allows you to access the iPad’s “Open In…” functionality. The only way to get to the “Open In…” menu is to first preview the document using the iOS document preview feature. Unfortunately, the iOS document preview functionality doesn’t recognize a number of files and file types. Most notably for me, it doesn’t recognize Markdown files (I’ve tried several different file extensions and none of them seem to work). Since the preview feature doesn’t recognize Markdown, then I can’t get to “Open In…” to open the documents in Byword (an iOS Markdown editor), and so I’m essentially unable to access my content.

To see if this was an iOS-wide problem or a problem limited to BoxCryptor, I tested accessing some non-encrypted files using the Dropbox iOS client. The Dropbox client will, at least, render Markdown and OPML files as plain text. The Dropbox iOS client still does not, unfortunately, know how to get the Markdown files into Byword. I even tried a MindManager mind map; the Dropbox client couldn’t preview it (not surprisingly), but it did give me the option to open it in the iOS version of MindManager. The BoxCryptor client also worked with a mind map, but refuses to work with plain text-based files like Markdown and OPML.

Given that I create the vast majority of my content in Markdown, this is a problem. If anyone has any suggestions, I’d love to hear them in the comments. Otherwise, I’ll post more here as soon as I learn more or find a workaround.

Tags: , , , , ,

Spurred to action by a brief mention at the bottom of a blog post, I began digging into the use of patch ports to connect multiple Open vSwitch (OVS) bridges. In this post, I’ll show you how to connect two separate OVS bridges using a patch port, and then we’ll explore some possible use cases for this functionality.

You’ve seen me use the ovs-vsctl set interface <interface name> type=... syntax several times; I provided some insight on what it’s doing in this post. Basically, what we’re doing with this command is manipulating the OVS configuration database. This is how we configure internal interfaces that can be plumbed with an IP address (for use in Layer 3 routing with OVS). In this article, we’re going to use this command again, but this time we’re going to set type=patch.

I’d not seen any references to patch ports before before running into this blog post, where patch ports receive a brief mention at the end of the article. So, I did a little digging, and finally found the manpage for the OVS configuration database (visible by running man 5 ovs-vswitchd.conf.db from a system with OVS installed). In that manpage, it describes patch ports as “a pair of virtual devices that act as a patch cable.” A patch port only has a single option, and that single option is the name of the patch port at the opposite end.

Graphically, you can think of patch ports like this:

To create a patch port, it’s quite easy. This group of commands will create a patch port:

You would repeat these commands for each bridge you want connected to another bridge. To connect two bridges, you would repeat them twice—once for the first bridge (specifying the patch port on the 2nd bridge as the peer), and again for the second bridge (specifying the patch port on the 1st bridge as the peer). Or, as the manpage puts it:

That is, the two patch interfaces must have reversed name and peer values.

Once you’ve run through the commands, running ovs-vsctl show will reveal a configuration that would look something like this (obviously your bridge names, port names, and interface names will vary):

Let’s review this a bit:

  • The bridge ovsbr2 contains a port and interface named patch2-0, with a peer set to patch0-2. Note that ovsbr2 has no physical uplinks.
  • Likewise, the bridge ovsbr0 has a port and interface named patch0-2, whose type is patch and whose peer is set to patch2-0. Note that, just as the manpage stated, the two patch ports have reversed name and peer values—this creates the connection between the two bridges. This bridge has a bond with two interfaces that take it to the outside world.

With this configuration, I can start up a guest domain attached to ovsbr2—which has no physical uplinks—and gain connectivity to the outside world via the patch ports that connect it to ovsbr0 and its uplinks.

The next natural question (at least, it was the next natural question for me): how many levels of connected OVS bridges can you build? It turns out the answer is 5 (as described here).

OK, this is interesting (sort of), but what sort of uses does this have? Well, I’m still exploring that myself, and I’d love to hear from readers as to how they might see this functionality utilized. Here are two examples of which I know:

  • In the original post that sparked this work, the author used a separate OVS bridge (or datapath) for OpenFlow testing. So, one bridge that had no uplinks was connected to an OpenFlow controller and had a patch port to an externally-connected bridge. Thus, he could perform OpenFlow testing with some guests, while leaving other guests (on the other bridge) unaffected.
  • One other use case I saw was around XenServer integration. (I apologize but I can’t find the link where I saw it now—if any readers have it, please share it in the comments.) Basically, patch ports were used to connect an integration bridge that is manipulated/managed by XenServer to an external bridge that managed all the connectivity to the outside world. This is similar to the first example, but in this case it’s not OpenFlow that’s involved but XenServer instead.

I’ve racked my brain for other potential use cases, but they seem to be escaping me at the moment. If you have other use cases, feel free to share them in the comments. Likewise, if there are technical errors or corrections, please share those in the comments as well. Courteous comments are always welcome and encouraged.

Tags: , , ,

« Older entries