Red Hat Summit in Review

Despite my best intentions of blogging every day at Red Hat Summit, time got away from me, as it often does at these events. There’s always 3 things going on, and it’s hard to find a moment between that first cup of coffee, and stumbling into bed at the end of the night.

I spent almost the entire event working the RDO booth in the Community Central section of the expo hall. While traffic wasn’t as heavy as at OpenStack Summit, it was still pretty constant.

In the swag department, I had our “what does RDO stand for” tshirts, and TripleO QuickStart USBkeys.

IMG_20160629_122305

Several things stood out to me from this audience.

First, I was delighted to hear story after story of companies that use RDO in the test/dev/lab environment, and use Red Hat OpenStack Platform in their public/production environments. This is what I really want to see happening, so it’s very gratifying when I get anecdotal evidence that it is happening. Now, if I can only convince those folks to follow up with case study writeups for the user stories page.

Second, from people who were not quite as familiar with either RDO or OpenStack, if there was a consistent thread in the questions, it was confusion as to the overlap between oVirt (or Red Hat Enterprise Virtualization), OpenStack, and OpenShift, and when one might use one vs. the others. This looks like a good opportunity for some blog posts around what the overlap is, what the distinctions are, and what recommendations are for using one or another.

Brian and I did an OpenStack vs oVirt comparison talk at last year’s Red Hat Summit, but I don’t believe we ever wrote it up anywhere. And OpenShift has the added confusion of having a similar name, which gets people kind of mixed up before they even consider the feature set.

IMG_20160702_114227

And, finally, the week was yet another reminder that I work for the best company in the world, with the best coworkers. I feel sorry for the rest of you.

 

Convert an Apache httpd password file to dbm

If you have a textfile password file, and you want to convert it to a dbm database for use with mod_authn_dbm, this can be done as follows:

htdbm -cbp passwords.dbm bogus bogus
awk ‘BEGIN { FS=”:” }; {system (“htdbm -bp passwords.dbm ” $1 ” ”  $2)}’ passwords
htdbm -x bogus

This assumes that the file `passwords` is your existing password file, and that you wish to create a dbm database `passwords.dbm`

The -b flag says that the passwords will be provided on the command line. The -p flag says not to encrypt the password – because it’s already encrypted.

This feature used to be available in the `dbmmanage` utility, as an `import` argument, but that utility is no longer included in the httpd packages for the Fedora/CentOS and Debian/Ubuntu Linux distro families, so we have to make do with htdbm.

I’m stashing this here for posterity, since I just spent a half hour getting the awk syntax right.

The first line creates a starter dbm with a single bogus entry, and the third line cleans up that bogus entry.

All right thinking people

In the midst of a Facebook conversation someone (a “friend” of a “friend”) said that all right thinking people thought a certain thing, while the rest of the world were ignorant savages. (I’m paraphrasing, but the phrase “most right-thinking people” was definitely used.)

This got me thinking about a topic that has crossed my mind a lot during this particularly presidential campaign circus.

Long ago (ie, pre-Facebook) one would surround oneself with like-thinking people. You’d have a few dozen friends that agreed with you about everything, and the rest of the world were ignorant savages, and life was good. You knew that all right-thinking people agreed with you, but you were also aware that the majority of the world was ignorant savages.

Then came Facebook. You have a few hundred carefully curated “friends”, most of whom are people that have similar worldviews to yourself. They, in turn, have the same. You now have somewhere north of 10,000 people that you hear from every day, most of whom agree with you on most topics.

So far, so good. This is the same as it was pre-Facebook, except that the numbers are much bigger, giving you the impression that everyone in the world agrees with you, except for that wingnut Larry who is a friend of a friend of a friend and says *CRAZY* things. All right-thinking people agree with you, and there’s a tiny minority of morons clinging to their tribal gods.

Meanwhile, Donald Trump has the nomination for the Republican candidate for President, so something must be wrong with your math.

 

Ode to Box 1 (of 2)

IMG_20160611_101704You taunt me,
box 1 of 2.
What, and where
is box 2?

Is there even a box 2?
Is there any relation
between the utterly random
assortment of junk in you
to the cornucopia
which is box 2?

Ah, box 1
half of an unknown whole,
kept, I think, only to wait
for your long lost sibling,
languishing, somewhere,
waiting for you.

 

Endnotes

Endnotes

She didn’t want
to send invitations.
Why invite people you know aren’t going to come.
Seems a waste.
So her Daddy’s daughter.

It’s traditional,
says Mere,
People like to know.

She didn’t send invitations.

And now she sits,
easy to find with her purple hair,
in a mob of her classmates

awaiting a short walk,
a slip of paper,
the endnotes of this chapter
that she doesn’t really need to tell her
that the next one has started.

Almost spring

Almost spring

The final creme brulee crust of ice
clings valiantly to the surface of the swimming pool,
but vanishes at the lightest touch of the fingers

I pretend it’s warm enough
to be outside in bare feet,
pretend not to shiver when
the water gets on my neck.

Pretend it will be
warm again some day.

Alexa, chapter 2

Since last I wrote, I’ve been experimenting with Amazon Echo skills.

Getting the skill working for personal use wasn’t very difficult. Having a skill published to the whole world is more involved, because you have to pass their certification testing.

I’m not quite there yet, and I’m not really sure what I’m doing wrong.My first attempts to address the problems found in the certification phase have led to this: https://github.com/rbowen/validate-echo-request-php

That’s a PHP function that handles the validation of the request certificate, timestamp, and various other things that are part of the request. However, apparently I’m not validating the certificate correctly just yet, as the latest feedback was:

1. The skill does not validate the signature for the incoming requests and is accepting requests with invalid signature specified. Please refer to the document that describes how to build your Alexa Skill as a web service (available via this link: https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/developing-an-alexa-skill-as-a-web-service ) for tips and requirements about validating the requests (and their signatures) sent to your web service.

Furthermore, I can’t find anywhere in the documentation what you’re supposed to return on failure, so perhaps that’s what I’m doing wrong.

On the other hand, all of the skills that I’ve written work just fine for me, in developer mode, I just can’t show them to anybody else.

 

Alexa, ask Fajita what’s for dinner

Several weeks ago I acquired an Amazon Echo. One of the most interesting things about this device, to me, was that I can write my own Echo skills, using the free skills kit.

This turned out to be both easier, and harder, than expected.

TL;DR: The code is at https://github.com/rbowen/fajita_echo

The biggest challenges were 1) that the docs are convoluted and incomplete, and 2) that the Echo doesn’t like SNI SSL vhosts. Details follow.

At a very simple level, when you say a certain thing to the Echo, it makes (can make) an HTTPS request to somewhere that you define, and then return a response. The request POSTs some JSON, and expects some specially-formatted JSON in response.

The Echo developer interface gives you a web-based config form to tell it where to POST your data, and what speech patterns should trigger this POST. This can be any web service of your creation, as long as it’s running HTTPS, not HTTP. Your service can also run on something called Lambda. I have no idea what that is.

Here’s how you do it:

  1. Register a developer account at https://developer.amazon.com/home.html and then go to https://developer.amazon.com/edw/home.html#/skills/list to create a new Alexa app.
  2. On the ‘Skill Information’ tab, point it to a web app endpoint running on an HTTPS server somewhere. This can be anywhere, and you can write it in any language you’re familiar with.

capture

 

 

 

 

3. On the ‘Interaction Model’ page, tell Alexa what phrases she should respond to. This is done in two steps.

a) First, tell it what actions, or ‘Intents’, your app will perform. For some reason, for this step you have to write a schema in JSON.

capture

 

 

 

 

 

b) Second, tell Alexa what phrases should trigger each of these actions by creating ‘Sample Utterances’. For example, to trigger my GetMenu action, I create a sample utterance of ‘GetMenu Whats for dinner’, which means what I will actually say is ‘Alexa, ask Fajita what’s for dinner’. (In my case, my skill is named “Fajita”, for reasons that I’ll explain at some point You just need a name for your skill that isn’t already taken by another skill.

4. On the SSL Certificate tab, indicate that you have a valid SSL cert.

5. On the ‘Test’ tab, you can start experimenting with your app. This will cause it to send JSON requests to your app, and tell you what comes  back. The format of the request and response are most clearly described (with examples) here: https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference.

See my example code at https://github.com/rbowen/fajita_echo/blob/master/echo.php to get an idea of what you can do. In my particular case, I have Alexa making a dinner recommendation, and, optionally, only returning vegetarian options.

Hurdles

The biggest problem in all of this was not the code, which was fairly easy, but the SSL setup. In short, it appears that the Amazon Echo doesn’t know about SNI. So, my server configuration, where I have several different HTTPS virtual hosts, each with its own SSL cert, doesn’t work. For a while, I thought it was because it didn’t like my Let’s Encrypt certificate, but this turned out not to be the case. As soon as I set my Echo app vhost to be the first, default SSL host, everything worked fine. This tells me that it’s just not making an SNI request. So, easy enough to fix, but this cost me a couple hours to hunt down.

The other, smaller problem, was that the documentation is thorough, but not laid out for a beginner. Finding the JSON format definitions, for example, took a great deal of hunting, as well as a lot of debug dumping of POST data. The links above should help bypass a little of that learning curve.

TODO

There’s several things I still want to do with my app.

  • Put the menu options in a database, rather than hard-coded
  • Provide an interface where someone can edit the menu options via the web, indicating whether a particular one is vegetarian or not
  • The interaction model provides the ability to give some variables in the sentence structure. Like, for example, I could ask for a menu suggestion “containing ginger”, and have “ginger” passed as an argument to my app. I’d like to play with this some.

Why Fajita?

An IRC channel where I spend a lot of time – #httpd on Freenode – has a helper bot named Fajita. I think of her as my personal assistant, and have long wanted to have some kind of voice interface to her in my home. Alexa is that, but Fajita will fill some of the talents that Alexa doesn’t have yet.

 

The Margin Is Too Narrow