gdickinson.co.uk

I am a frequent user of Puppet for system administration, and have given a couple of presentations on how to use Puppet in a security-focused shop. One of the things I’ve found is that revision-control of the puppet configuration via an SCM is a huge win and helps enormously in troubleshooting issues and rolling back errors. Since a large part of Puppet’s configuration is essentially an interpreted language with a real syntax, it makes sense to enforce valid syntax, either at commit-time or push-time, particularly since Puppet’s syntax is quite irritating and prone to error. Searching around, I couldn’t find anyone who had done this with Mercurial, since apparently Git or SVN are the weapons of choice in the Puppet community. Since I work at a Mercurial shop, I adapted this script. Here’s how to make it work:

1. Put this shell script somewhere world-executable:

   #!/bin/bash
   
   echo "Starting puppet syntax check"
   
   # Create a tempfile
   tempfile=`mktemp -t puppet_syntax`
   
   # Get a list of all modified files
   hg log -r tip --template "{files}\n" | sort | uniq > $tempfile
   
   # Walk through our list
   for line in $(< $tempfile); do
           # Check that it's actually a puppet file
           if [ `echo $line | grep -E "\.pp$"` ]
   		then
   		echo "Found puppet file $line"
   		hg cat -r tip $line | puppet --parseonly
                   if [ $? -ne 0 ]
   			then
                           rm -f $tempfile
                           echo "Puppet parse error found"
                           exit -1
                   fi
   		echo "Puppet file valid: $line"
           fi
   done
   rm -f $tempfile
   exit 0

    

2. If you use a central repository that you keep your code in, you’ll probably want to use Mercurial’s ‘pretxnchangegroup’ hook. Put this section in the hgrc file for the repo in question; you may need to add the file in /path/to/repo/.hg if it doesn’t exist:

   [hooks]
   pretxnchangegroup = /usr/local/bin/puppet-syntax-check.sh

3. That should be about it. Next time you push a changeset to your central repository, the script will be invoked. Note that only files that end in .pp will be syntax-checked. Your repository probably contains multiple sorts of configuration files which obviously won’t conform to the Puppet syntax. If the check fails, the central repository will roll back the transaction, and you’ll have to push a changeset which results in the ‘tip’ revision containing valid syntax.

This year at a holiday party Alex and I were at, a magician was making his way amongst the tables and performing some sleight-of-hand illusions as well as some classic mathematical card tricks. This afternoon, this video popped up in my Twitter feed:

Being almost done with finals for the semester I thought I’d take a few seconds and figure out how the trick works as a short exercise in reasoning.

First, some intuition: the trick works every time provided you follow the algorithm given. Therefore the three ‘chosen’ cards must be in the same place in the deck every time. This suggest the ‘cutting’ routine is for illusion only. The second half of the trick involves sequentially cards in odd ‘positions’ in the deck which suggests some relative primality.

Next, we prove to ourselves that the position of the chosen cards in the deck is deterministic. At the beginning we have four piles with sizes as follows:

We then add in the cards and cut the piles accordingly:

So, after we combine the four piles, but before we move four cards from the top to the bottom of the pile, we can tell by simplifying that the sequence of cards from bottom to top is:

If we count from the top to the bottom, after we have moved four cards from top to bottom, the three chosen cards will always be in positions 6, 22, and 38.

Now that we know what happens in the first half of the trick, we move onto the second part. It’s quite clear that the performer starts removing odd-positioned cards from the deck. So we need to show that positions 6, 22 and 38 have some special property that keeps them in the deck to the point where there are only three remaining cards. At first glance this seems unlikely. They are all even, to be sure, so they will pass the first round, but on second round, position 6 will be in position 3, so that card will get eliminated. Looking naïvely, there are of course positions that will survive four rounds of elimination, which are 16, 32, and 48, multiples of 2^4 or 16. These cards don’t occupy those positions.

It took me a moment to figure out what was going on here. Keeping the non-eliminated cards face down has the effect of reversing the deck, so the first card to be ‘kept’ will actually be in position 26 in the next round. When I worked the problem through a couple of times I dealt the cards to myself face-up to try and suss out which positions the chosen cards end up in. Of course, this breaks the trick completely.

Before the first pass, the chosen cards are in the following positions, and there are 52 cards in the deck.

After one round of elimination, with 26 cards in the deck

After two, with 13

After three with 6:

Finally after four eliminations and with three cards left:

Finally, then, the position p of a card after n rounds is given recursively by:

So that’s it. No magic, just some arithmetic.