In 1998 and 1999 I was working for a consulting company doing largely Windows desktop support. I wanted very much to advance my career to the point where I was working on servers and complex infrastructures, and to that end I pursued the Microsoft Certified Systems Engineer certification. I acquired various training materials, and studied hard. My employer paid for the exams, and I passed each of the five tests on the first try. I was delighted with my accomplishment.

Unfortunately, my employer never moved me up, preferring instead to bill me out to clients as a supremely qualified desktop support specialist. It wasn't all bad, of course, because I was assigned to a team that traveled throughout Europe converting a client's setup from Novell to Microsoft. Still, it would have been nice to use professionally that which I had studied for.

Of course, looking back, the late 90s were the time when Microsoft certifications were extremely easy to acquire. It was possible to earn advanced certifications without ever actually using the technologies involved. Indeed, I was living proof: I passed the various Windows Server exams without ever using Windows Server products professionally.

Eventually my MCSE certification expired. I didn't think much of it. It hadn't done much for me, professionally, and I began to view certifications in general with a fair amount of disdain. If you can successfully do something, your work record should speak for itself. You ought not need a certification to demonstrate that you can do a specific job or excel with a specific technology.

Of course, a certification may be a deciding factor between two otherwise similarly qualified candidates. I don't know that that should always be the case, but I know that it often is. And a certification of any kind can help impress hiring managers enough to at least get an interview, from which one's interpersonal skills and work experience should then carry you through.

In the years since my MCSE expired, I began using Linux -- at first personally and then, much to my delight, professionally. I've used Linux at every job since I left that consulting company. I never really thought much about obtaining any of the various Linux certifications, mostly because my previous experience with certifications had been such a non-starter. But also because I have acquired a healthy body of professional Linux experience to which I can point. In addition, I've been a long-time member of the Central Ohio Linux User Group, and have participated in and contributed to numerous open source projects.

I was somewhat surprised, then, when my employer sent me to RH255 - Red Hat System Administration III with RHCSA and RHCE Exams. The training itself was modestly useful. I entered the class already knowing the bulk of what was presented, but I did pick up a few useful tricks, and it was certainly useful to learn the official "Red Hat Way" for a few things. Most useful of all was getting prepared for the two tests I took on the last day of training.

Had I simply taken the exams without the class, I'm certain I would have failed. It's not that I didn't know the material, but rather I wouldn't have been prepared for the testing environment. I wouldn't have been prepared for the kinds of tasks I was asked to perform. Sure, I could have figured them all out given sufficient time, but the exams only afford about two hours each to complete the objectives.

I'm happy to report that I passed both EX200 and EX300, so I am officially a Red Hat Certified Engineer!

We had friends over for dinner and games the other night. Upon reviewing the selection of games we had suggested, one of our friends commented on how violent our games were. We had chosen Werewolves, a family favorite, and Guillotine (thanks, Owen, for introducing us to this one!) as our top picks for the evening.

Werewolves, also known as Mafia, is a story-telling game that revolves around a pair of eponymous werewolves that systematically slaughter residents of a small village every evening. The villagers in turn enact mob justice by day on suspected werewolves. Sometimes the villagers get it right and kill a werewolf, but more often than not they get it wrong and kill an innocent villager. The game has a number of permutations to account for groups of different sizes, and we've found the game to be extraordinarily fun at various family get-togethers. I'm often asked to be the moderator for our games in large part because I know -- and can succinctly explain -- the rules of the game to new players. I don't usually mind, because it's fun to watch the group dynamics evolve through multiple game sessions, as well as watch long-time players adapt their strategies with new players in the mix.

Guillotine is a card game that uses the French Revolution as a backdrop, and the objective of the game is to collect the severed heads of various French nobles. It sounds much more gruesome than it is. The cards are cute, and the action is entirely family-friendly. It's a big hit in our house, which makes it a bit of a rarity: we often have a hard time settling on a game because our individual tastes vary so much. Strategy games appeal to the boys, while more social games appeal to the girls. Anything involving a lot of calculations or resource management is preferred by the boys, as are slower to develop games, while faster, more casual games are generally preferred by the girls. Guillotine strikes a very nice sweet spot: the game mechanics are easy to understand, and allow for both casual and cut-throat playing styles.

This weekend we played Bullets and Barbecue, an a la carte murder mystery game. It was a little contrived, and our younger players had some difficulty with the role playing aspects, but on the whole we found it to be very enjoyable. We found the game at a thrift store for $2 so it provided an awful lot of bang for the buck. I've looked for similar games, but the prices seem considerably higher than I'm willing to pay for a one-play-only game. Are there any user-generated murder mystery party games available? I'd love to find some!

Other games we enjoy that have overt or subtle violent contexts include Munchkin (in all its forms), Small World, Talisman, and Axis & Allies.

We're not an entirely violent lot, though. Quelf is probably the game that has provided us all the most entertainment of late, and it's one we can all agree to play pretty quickly. It's silly, and requires players to do any number of ridiculous tasks, and we end up with a couple good belly laughs each time we play.

Feel free to suggest other games we should try: we're always interested in playing new games!

Puppet is "an enterprise systems management platform" that can be used to control the configuration of many servers, in theory substantially reducing the management effort of systems administrators. We use Puppet at work, and I was recently tasked with migrating the Puppet service to a new server. The actual migration was easy enough, thanks to a tip from a Puppet user I know.

While I was working with Puppet, I decided to make a couple of small improvements to the way we use it. The Puppet documentation recommends using version control for the Puppet files, and we'd been doing that but deploying the configuration from Subversion into /etc/puppet was an entirely manual process. I wanted to set up a Subversion post-commit hook so that simply checking new stuff into the repository would automatically get pushed to the live system.

The default location for the Puppet files is /etc/puppet. The Subversion repository we're using is stored on the same server, so I made a check-out of our files into /etc/puppet:

$ cd /etc/puppet
$ sudo svn co file:///usr/local/svn/puppet .

I checked out the Puppet repository onto my local workstation, so I can work on the files there, and then commit them back. That works fine.

So I set up the following post-commit hook for the Puppet repository:

#!/bin/sh
# update the local checkout of Puppet manifests
export HOME=/tmp
REPOS="$1"
REV="$2"
/usr/bin/svn up /etc/puppet

I access the repository from my workstation over https using Apache's mod_dav_svn, so the post-commit hook runs as the Apache user. This means the Apache user needs write access to /etc/puppet. That's an easy chmod. But even after that, the post-commit hook failed with a permission denied problem. So I chown'ed the files to Apache, but still no luck writing there.

The SELinux context on /etc/puppet is system_u:object_r:puppet_etc_t, and SELinux's audit log confirms that Apache, via httpd_sys_script_t, does not have permission to do the necessary operations inside /etc/puppet.

Through a series of iterations with ausearch -m avc -ts recent | audit2allow -r, I worked up the following SELinux policy module:

module local 1.0;

require {
type httpd_sys_script_t;
type puppet_etc_t;
class file { rename setattr unlink write };
class dir remove_name;
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t puppet_etc_t:file rename;
allow httpd_sys_script_t puppet_etc_t:file setattr;
allow httpd_sys_script_t puppet_etc_t:file unlink;
allow httpd_sys_script_t puppet_etc_t:file write;
allow httpd_sys_script_t puppet_etc_t:dir remove_name;

As root, I built and installed the module using these commands:

# checkmodule -M -m -o local.mod local.te
# semodule_package -o local.pp -m local.mod
# semodule -i local.pp

Now my post-commit hook works as expected: /etc/puppet is updated whenever I commit something to the repository from my workstation.

My questions are:

• is my policy too permissive?
• what alternatives might exist to this solution?
• are there any subtle gotchas that might cause trouble?

This is my first time writing an SELinux policy, so I wouldn't mind some feedback on it. I posted this same question to the Central Ohio Linux User Group mailing list, so check there for follow-ups, too.

We have a small collection of books in Josephine's room, and I've been trying to get into the routine of reading a few pages to her every night before bed. At just eight months old, she doesn't have the attention span to sit through all of even a Sandra Boynton book, and she's more often interested in trying to gnaw on the books than look at the pictures. Thank goodness the various board books we have were specifically designed for just such abuse, and Josie delights in trying to eat them. I know she also enjoys the warmth of my presence and the sound of my voice, so as we continue with the routine of reading before bed she'll start to listen to the tales rather than try to ingest them.

Last night I grabbed at random a book from Josie's bookshelf. I was surprised to see that it was My Go to Bed Book. It's an old, tattered book with the cover just barely hanging on. On the inside front cover is written "To Scott, from Mommy and Daddy - Christmas 1976".

The book I read to my daughter last night was the very same book my parents had read to me.

As I read the words, a part of my mind wandered off to ponder the relative value of physical books and e-books. I don't think there's any way an e-book released today would be readable three decades from now. One need only consider the examples of floppy disks or Zip disks to understand the relative impermanence of any specific piece of storage technology. Do we seriously think that today's Kindles and Nooks will work even ten years from now? And that's just the physical reader, and doesn't deal at all with the electronic format of e-books which will no doubt continue to evolve. Have you tried to open a WordPerfect document, lately?

I'm all for technological advancements, but I also think there's something very important about the legacy of physical objects. There's not the same sentimental value to an e-book as there is with a physical book. If the Go to Bed book avoids my daughter's teeth there's the very real possibility that she can read it to her kids, and share with them the fact that I had read it to her, and my parents had read it to me.

Would it mean anything to my grandkids to know that the antique Amazon Kindle on which they might read an e-book was the same once-shiny-and-new Amazon Kindle on which I read the same e-book?

Thirteen is my lucky number.

Sadly, I can't recall any specific time when thirteen actually paid off for me, but I've always felt that it was my number.

I have long rejected the traditional opinion that seven was a lucky number while thirteen was an unlucky one. Of course, my opinion on this matter was helped by the fact that I was born on the thirteenth day of the month.

For years, my dad told me I was born on a Friday the 13th, and so I'd held a very positive opinion of that day, contrary to the typical superstitions. When I learned to properly compute calendar events I learned that I was, in fact, born on a Thursday, which left me feeling a little disappointed. To this day, though, I feel like any Friday the 13th is my day, regardless of whether the month matches that of my birth. And when my birthday does fall on a Friday the 13th, I feel like it's an extra special treat.

I've never been particularly superstitious, and I wonder now whether my affinity for thirteen was a cause or a product of that.