On IRC – and other online communities – it is common to use a “pastebin” service to share snippets of code, logs, and other material, rather than pasting them directly into a conversation. These services will typically return a URL that you can share with others so that they can see the content in their browser.

One of my favorite pastebin services is termbin.com, because it works from the command line using tools you probably already have installed. Termbin runs the fiche service, which listens for TCP connections on port 9999, reads any content that you provide, and then returns a URL. For example, if I wanted to share my iptables configuration with someone I could just run:

In this article, we’re going to ask Gnocchi (the OpenStack telemetry storage service) how much memory was used, on average, over the course of each day by each project in an OpenStack environment.

Environment

I’m working with an OpenStack “Pike” deployment, which means I have Gnocchi 4.0.x. More recent versions of Gnocchi (4.1.x and later) have a new aggregation API called dynamic aggregates, but that isn’t available in 4.0.x so in this article we’ll be using the legacy /v1/aggregations API.

You can list iptables rules with rule numbers using the --line-numbers option, but this only works in list (-L) mode. I find it much more convenient to view rules using the output from iptables -S or iptables-save.

You can augment the output from these commands with rule numbers with the following awk script:

#!/bin/awk -f

state == 0 && /^-A/ {state=1; chain=$2; counter=1; printf "\n"}
state == 1 && $2 != chain {chain=$2; counter=1; printf "\n"}
!/^-A/ {state=0}
state == 1 {printf "[%03d] %s\n", counter++, $0}
state == 0 {print}

This will produce output along the lines of:

I’ve just refreshed the version of Pelican used to generate this blog, along with the associated themes and plugins. It all seems to be working, but if you spot a problem feel free to drop me a line.

I find myself working with Raspbian disk images fairly often. A typical workflow is:

• Download the disk image.
• Mount the filesystem somewhere to check something.
• Make some changes or install packages just to check something else.
• Crap I’ve made changes.

…at which point I need to fetch a new copy of the image next time I want to start fresh.

Sure, I could just make a copy of the image and work from there, but what fun is that? This seemed like a perfect opportunity to learn more about the device mapper and in particular how the snapshot target works.

The other day on #ansible, someone was looking for a way to safely shut down a Nova server, wait for it to stop, and then start it up again using the openstack cli. The first part seemed easy:

- hosts: myserver
  tasks:
    - name: shut down the server
      command: poweroff
      become: true

…but that will actually fail with the following result:

TASK [shut down server] *************************************
fatal: [myserver]: UNREACHABLE! => {"changed": false, "msg":
"Failed to connect to the host via ssh: Shared connection to
10.0.0.103 closed.\r\n", "unreachable": true}

This happens because running poweroff immediately closes Ansible’s ssh connection. The workaround here is to use a “fire-and-forget” asynchronous task:

I was recently working on a project in which I wanted to drive a simple piezo buzzer attached to a GPIO pin on a Raspberry Pi. I was already using the RPi.GPIO module in my project so that seemed like a logical place to start, but I ran into a few issues.

You drive a piezo buzzer by generating a PWM signal with the appropriate frequency. The RPi.GPIO module implements PWM via software, which is tricky on a non-realtime system. It’s difficult to get the timing completely accurate, which results in sounds that are a little wobbly at best. Since I’m simply generating tones with a buzzer (rather than, say, controlling a servo) this is mostly just an annoyance.

At $JOB we often find ourselves at customer sites where we see the same set of basic problems that we have previously encountered elsewhere (“your clocks aren’t in sync” or “your filesystem is full” or “you haven’t installed a critical update”, etc). We would like a simple tool that could be run either by the customer or by our own engineers to test for and report on these common issues. Fundamentally, we want something that acts like a typical code test suite, but for infrastructure.

I use Gmail extensively for my personal email, and recently my workplace has been migrated over to Gmail as well. I find that for my work email I rely much more extensively on filters and labels to organize things (like zillions of internal and upstream mailing lists), and that has posed some challenges. While Gmail is in general fairly snappy, attempting to apply an action to thousands of messages (for example, trying to mark 16000 messages as “read”, or applying a new filter to all your existing messages) results in a very poor experience: it is not possible to interact with Gmail (in the same tab) while the action is running, and frequently actions will timeout.

I’ve been thinking about logging in the context of OpenStack and containerized service deployments. I’d like to lay out some of my thoughts on this topic and see if people think I am talking crazy or not.

There are effectively three different mechanisms that an application can use to emit log messages:

• Via some logging-specific API, such as the legacy syslog API
• By writing a byte stream to stdout/stderr
• By writing a byte stream to a file

A substantial advantage to the first mechanism (using a logging API) is that the application is logging messages rather than bytes. This means that if you log a message containing embedded newlines (e.g., python or java tracebacks), you can collect that as a single message rather than having to impose some sort of structure on the byte stream after the fact in order to reconstruct those message.