Automate manifest distribution to masterless puppet clients from an S3 bucket

At Ooyala, I managed our Macintosh fleet with puppet. The problem we ran into is that we have users in remote locations rarely need to connect to the VPN, and when their machines aren't on the VPN or corp network, they can't connect to the puppetmaster and don't receive any updates. This made me switch to masterless puppet for our Macs so that they could pull their manifests (and other files) from S3, so the remote users could get updates when they weren't working from one of our offices and weren't on the corporate network or VPN.

When I was looking for examples of how to implement masterless, I didn't find tools for automating distribution of manifests to the nodes, so I wrote Miyamoto.  I got Ooyala to allow me to open-source it before I left, and the source is at https://github.com/unixorn/miyamoto

Miyamoto automates creating debs or OSX pkgs that contain all your manifest files and then publishing them to an S3 bucket so your client nodes can download and install them.

Here are a few caveats:

• You lose the benefits of running a puppetmaster. No reporting, no dashboard, etc. While Miyamoto does write a json status file into the status subdirectory of your S3 bucket, you'll have to write something to scrape those files and convert them into something useful.
• I ripped out all the company-specific stuff in a two day period between documenting things for my replacement and doing some other last minute tasks. I'm pretty sure everything still works, but if you run into issues, let me know and I'll try to help.
• Currently Miyamoto only works with OS X and Debian based linux distributions. Redhat support should be trivial, but I didn't have time to work on that since Ooyala is an Ubuntu shop.
• Miyamoto assumes you're using a single git repository for your manifests, and that there are specific branch names you're consistently using for stable & testing. If you're not a git user or are using multiple repos, or don't use the same branch names when you release a new stable environment, you'll need to tweak the Rakefiles.
• Miyamoto also assumes you're willing to have a single set of AWS credentials that your nodes will use to download new manifests from a read only tree and write their statuses back to a specific directory in S3.

Creative Suite 5.5 refuses to accept a serial number to end trial mode

My wife recently upgraded to a MacBook Air, and when I went to install CS 5.5 on the MBA it accepted the serial number during installation but then would bring up the Adobe Application Manager screen when you started any CS application asking to either run in trial mode, or enter a serial number. And it wouldn't take the serial number that it had just accepted during installation. Yay!

So to spare anyone else the multiple chat sessions with Adobe support, with multiple escalations per session, here's how to fix it.

1. Quit all your CS applications
2. Open a terminal window.
3. sudo -s
4. cd '/Library/Application Support/Adobe/Adobe PCD'. You'll see a cache directory in there. Don't delete it like the tech support guy tells you to (Out of paranoia, I renamed mine instead), that'll trigger a message when you try to start a CS app telling you to reinstall CS.
5. cd cache - you'll find a file named cache.db rename it to cache_broken.db.
6. Open one of your CS applications. It'll ask you for the serial and this time, it'll accept it.