Oh, The Losses … All Those Losses

It seems pirates have found the ultimate weapon to kill the music industry: copying music to /dev/null … all the time! 😆

Money Quote:

Last week, Sunde told TorrentFreak that he’d already made 120 million copies and “cost” the music industry $150 million in losses, at least by the music industry’s preferred accounting practices counting the dollar value of any copied song as lost revenue.

 

Ramen Code

The plaintiffs in Toyota’s Unintended Acceleration lawsuit had someone with knowledge in building embedded software had a look at Toyota’s source code:

possible bit flips, task deaths that would disable the failsafes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, thousands of global variables. The list of deficiencies in process and product was lengthy.

CFSSL FTW

After reading how CloudFlare handles their PKI and that LetsEncrypt will use it I wanted to give CFSSL a shot.

Reading the project’s documentation doesn’t really help in building your own CA, but searching the Internet I found Fernando Barillas’ blog explaining how to create your own root certificate and how to create intermediate certificates from this.

I took it a step further I wrote a script generating new certificates for several services with different intermediates and possibly different configurations (e.g. depending on your distro and services certain cyphers (e.g. using ECC) may not be supported).
I also streamlined generating service specific key, cert and chain files. 😀

Have a look at the full Gist or just the most interesting part:

You’ll still have to deploy them yourself.

Update 2016-10-04:
Fixed some issues with this Gist.

  • Fixed a bug where intermediate CA certificates weren’t marked as CAs any more
  • Updated the example CSRs and the script so it can now be run without errors

Update 2017-10-08:

  • Cleaned up renew-certs.sh by extracting functions for generating root CA, intermediate CA and service keys.

A Service Monitor built with Polymer

I tried to build a service monitor having the following features:

  • showing the reachability of HTTP servers
  • plotting the amount of messages in a specific RabbitMQ queue
  • plotting the amount of queues with specific prefixes
  • showing the status of RabbitMQ queues i.e. how many messages are in there? are there any consumers? are they hung?
  • showing the availability of certain Redis clients

Well, you can find the result on GitHub.
It uses two things I published before: polymer-flot and flot-sparklines. 😀

An example dashboard:

polymer-service-monitor screen shot

too long for Unix domain socket

If you’re an Ansible user and encounter the following error:

you need to set the control_path option in your ansible.cfg file to tell SSH to use shorter path names for the control socket. You should have a look at the ssh_config(5) man page  (under ControlPath) for a list of possible substitutions.

I chose:

Bottle Plugin Lifecycle

If you use Python‘s Bottle micro-framework there’ll be a time where you’ll want to add custom plugins. To get a better feeling on what code gets executed when, I created a minimal Bottle app with a test plugin that logs what code gets executed. I uesed it to test both global and route-specific plugins.

When Python loads the module you’ll see that the plugins’ __init__()  and setup()  methods will be called immediately when they are installed on the app or applied to the route. This happens in the order they appear in the code. Then the app is started.

The first time a route is called Bottle executes the plugins’ apply()  methods. This happens in “reversed order” of installation (which makes sense for a nested callback chain). This means first the route-specific plugins get applied then the global ones. Their result is cached, i.e. only the inner/wrapped function is executed from here on out.

Then for every request the apply()  method’s inner function is executed. This happens in the “original” order again.

Below you can see the code and example logs for two requests. You can also clone the Gist and do your own experiments.