If you’re using AWS CloudFormation you might have come across clouds-aws. If not you might want to have a look at it on GitHub.

It makes managing CloudFormation stacks from the shell fairly easy. It keeps a local representation of the stack as a Template (JSON or YAML) and a YAML-file holding the parameter values for the stack.

Until now an update to an existing stack had to be performed in the dark, meaning that there was no possibility to dry-run or predict a stack update before going for it without a safety net other than the built-in rollback capability.

The new feature introduced in 0.3.8 brings now change sets to the game allowing to stage a stack update and inspect the changes in detail before actually executing the change.

To get clouds simply run pip install clouds-aws. You can then dump an existing stack with clouds dump <stack name>, then edit the stack and create a new change set with clouds change create <stack name> <change name> which will print out an overview of the changes.

If you need more detail you can inspect the full detail AWS API returns for the change you can describe the change in either YAML or JSON format: clouds change describe --yaml <stack name> <change name>.

When everything is to your liking you execute the change with clouds change execute --events <stack name> <change name>. The –events in this example will poll for stack events until the stack reaches a stable state.

If you ever need to combine all first pages of a bunch of PDF files into a single file you can use this script. Comes in handy to prepare train tickets for turning them in for tax returns. They come with two pages one of which is only the TOS which I don’t want to print to save the environment and resources.

I’m forced to use GoCD for deployments and stumble across limitations when using it more often than not.

Last thing that made me quite a headache was automatic locking of pipelines. In general this is a good idea. When the pipeline is triggered it is locked to prevent parallel execution which is a good thing when the pipeline deploys a stack of stuff in some cloud environment and you don’t want races of competing pipeline runs.

However if the pipeline errors prematurely the it stays locked. Until somebody bothers to unlock it in the UI. This is very possible in most cases as the pipelines have several steps that might break. I already included cleanup of debris but haven’t been able to unlock it automatically. That is until I had an idea for which I will most probably go to system engineering hell. But since I found quite a few instances of people asking how it can be done on the Interwebs I thought I share it anyway.

The solution is to issue an API call to the GoCD server as last step in the failure case. Unfortunately this can’t be done directly as the pipeline is still running and therefore unable to unlock itself. The GoCD server will respond with an error stating the pipeline must not have active tasks to be unlocked. The answer is atd. It really shouldn’t be – but it works.

The first line removed any port number from the $GO_SERVER_URL which happens to have a non-default port in my case which is different from the port on the reverse proxy.

The at command schedules the API call after a minute to unlock the pipeline at a time when it is finished and the server allows unlocking again.

Disclaimer: Don’t try this at home. For educational purposes only. ;-)


  • Python 3
  • Pip 3

$ brew install python3

Pip3 is installed with Python3


To install virtualenv via pip run:

$ pip3 install virtualenv


Creation of virtualenv:

$ virtualenv -p python3

Activate the virtualenv:

$ source /bin/activate

Deactivate the virtualenv:

$ deactivate

Adding a subscription to an SNS topic in CloudFormation is easily done with a few lines:

But that’s actually not enough. While creating a subscription in the AWS Console is a single step it implicitly creates a Lambda permission for SNS to invoke the function. This needs to be added as a separate resource in CloudFormation:

This will allow SNS to successfully invoke the function.

If you send a JSON message to your SNS topic that will be encapsulated in the event sent to Lambda (as JSON) and you will have to unpack it in your function like in this example for node.js runtime:

I just had the need to check a record on all NS servers of a zone to see whether they had been updated with the new zone config and returned the correct IP addresses for the name.

In the CLI this is quite a considerable amount of typing. That’s why I created a small script for it:


I’m currently two days into the Advanced Architecting on AWS class and am looking forward to taking the AWS Certified Solutions Architect – Professional Level exam later this month. Since I noticed there is quite some interest in this certification I want to use this blog post to discuss the sample exam questions you can download from AWS. If you haven’t figured them out for yourself you might want to try them first before continue reading as this post is a huge spoiler.

Continue reading

Today I updated to OS X 10.10.4. I was really happy when I read through the change notes despite the fact that I actually shouldn’t have been as there were also a dozen or so fixes for possible unauthenticated remote code executions in several components of the system.

But I was happy because it was promised that they had fixed an issue which could lead to the system to stop responding under certain conditions. One of them was your computer being connected to a directory service. Check – my computer is member of an Active Directory domain. So I know some of those certain conditions.  Like trying to connect my Mac to the Internet via my Windows Phone’s WiFi Internet sharing. Or trying to login to my non-directory account first after boot without having logged in as directory user. Or sometimes when waking up from sleep. And some other conditions I could not find a pattern for. This can really be a pain especially when being somebody who is doing on-call duty and needs to be able to rely on the computer to actually work when servers are burning.

I cannot tell if the update works. I hope it does but my hope is limited though. And this is why I’m writing these lines. Because I just witnessed another thing that adds into why my fate in OS X is declining:


Maybe I should start looking at Linux again…

I wonder what’s going on lately. Some bot-net is trying to brute force its way into my blog since a couple of days. Usually I couldn’t care less – I’m using a secure password and the default user is disabled. But it makes my security plugin flooding my inbox and I’m starting to get really annoyed by that.

Here is what I did to put an end to that. I added a few lines to the .htaccess to put an HTTP auth in front of the login and some more lines to deny access to the password file which lives in the document root so it is automatically included in the nightly backups:

The attacker has quite a bit of resources at hand. So far I didn’t see any multiple occurrences of IP addresses in the logs.

In the second episode of my µC adventures I’m not losing any time and directly approach the thing that I started tinkering with electronics in the first place.

The device I’m going to build is supposed to measure the water level in out rain water tank. And of course the measured level needs to be submitted to a server on the Internet via WiFi which is the main reason why I’m using the ESP8266.

After browsing the Internet for a few minutes I figured the best way to go would be with using capacitance to measure the water level. I wanted to have high resolution so any solution that would involve using conductivity of the water (which I found used in quite a few project write-ups online) is out of the equation.

Continue reading