## Vim Syntax Highlighting for Firewall Logs

Firewall logs are verbose, and utterly boring to look at. It’s hard to pick out the important parts, like what the IP or destination port was. If you use vim/gvim to view the logs, there’s a syntax file I put together to make them more readable. Get it from https://github.com/gburca/vim-firewall

Here’s a before/after image (click for the full size):

Vim syntax highlighting for firewall logs.

Categories: Uncategorized Tags:

## Monitoring files with vim

It turns out that monitoring a file with vim is harder than it should be. Scripts such as Tail-Bundle and WatchForChanges rely on vim’s CursorHold events which only trigger once. Unlike tail -f, they only work if you’re active in that vim session and pressing keys to cause CursorHold to re-arm.

tail -f works well, but lacks the syntax highlighting and other features from vim.

Some other options require 2 terminals, or 2 separate scripts.

The solution below is very similar to tail -f. The primary difference is that it only monitors a single file at a time.

#!/bin/bash

# Usage: vim-tail.sh <filename>
#
# This script turns vim into a tail -f equivalent, but with syntax
# highlighting and all the other goodies.
#
# A version of vim compiled with +clientserver is required.
# On Ubuntu 14.04, vim.tiny, vim.basic and vim.nox won't work.
# vim.gtk is compiled with +clientserver, so apt-get install vim-gtk
#
# Author: Gabriel Burca <gburca dash github at ebixio dot com>

# Pick one of: vim|view|gvim|gview, etc...
VI=vim.gtk

# A unique name for the server, in case we monitor multiple files.
NAME="TAIL"

doForever() {
# Give the vim server a chance to start
sleep 2

# Move to the end of the file
$VI --servername$NAME --remote-send '<C-\><C-N>:edit!<CR>G' > /dev/null 2>&1 || exit

while true; do
# This blocks until the file changes, or the timeout expires
inotifywait --quiet --quiet --timeout 10 --event modify "$1" # 0 = the file was modified # 2 = the timeout expired if (($? == 0 || $? == 2 )); then$VI --servername $NAME --remote-send '<C-\><C-N>:edit!<CR>G' > /dev/null 2>&1 || exit else exit 1 fi # It's possible for the file to be modified before we loop back to # inotifywait, but we'll pick it up on the next round. done } # Kick off the vim client script in the background coproc doForever "$1"

# Now start the server
$VI --servername$NAME --remote-silent "\$1"
# Nothing below here executes until the tail server exits.

Categories: Uncategorized Tags:

## DigiKam 4.10 on Ubuntu 14.04

These are the steps I found are required to install DigiKam v4.10 on Ubuntu. In my case I ran into problems with libavcodec (ffmpeg/libav) and issues stemming from the ffmpeg project fork. YMMV.

First install digikam:

add-apt-repository ppa:philip5/extra
apt-get update
apt-get install digikam


At this point everything should have worked nicely. Unfortunately digikam (version: 4:4.10.0-trusty~ppa3) wouldn’t start up. Running it from the command line showed that I was missing libavcodec.so.53. To confirm:

ldd /usr/bin/digikam | grep libavcodec


The normal solution to this would have been:

apt-get install libavcodec-extra-53


But life is not that simple. Ubuntu deprecated and removed libavcodec-extra-53 and claims libav-tools should be used instead. libav-tools however doesn’t include a libavcodec.so.53 file, so after a bit of hunting around, I decided to just build it from source. Here are the steps:

git clone git://source.ffmpeg.org/ffmpeg.git
cd ffmpeg
git checkout -b ver53 dd453f
./configure --prefix=/usr/local --disable-ffmpeg --disable-ffplay --disable-ffprobe --disable-ffserver --disable-avdevice --disable-swresample --disable-swscale --disable-postproc --disable-avfilter --enable-shared --disable-debug --enable-gpl --enable-x11grab
make
sudo su -
checkinstall
ldconfig


After this, digikam started up properly.

#### Notes:

gitk --all libavcodec/version.h shows that after the dd453f commit the libavcodec version changes to 54, so that’s why that commit was used.

Categories: Uncategorized Tags:

## Temperature sensor: TMP36, DHT22, and 10K Thermistor

Here’s a quick comparison of 3 different “low cost” temperature sensors:

This is how accurate they each claim to be:

Model Accuracy in °C Accuracy in °F
TMP36 ±2.00°C ±3.6°F
Thermistor ±0.45°C ±0.8°F
DHT22 ±0.50°C ±0.9°F

All the data below was collected with a BeagleBone Black which has a 12-bit ADC. The 10K thermistor was hooked up in a voltage divider configuration with a 1% 10K resistor. The DHT22 uses a thermistor inside as well, but has a digital output. Readings were taken every 3s over a 2 hour period.

The sensors are all positioned within 1/4″ of each other. The slow temperature drifts are from the house cooling and the furnace heating it back up.

Temperature

I used a running average filter with a window of 10 samples to clean up the noise a bit and these are the results.

Temperature – 30s running average

Finally, taking the 10K thermistor as ground truth, these are the differences observed. The TMP36 is consistently about 2°F lower than the thermistor, and the DHT22 is roughly 1°F higher even though it’s also using a thermistor inside. I don’t know how accurate the ADC inside the DHT22 is, so that might explain some of the difference.

Deltas between different temperature sensors.

In conclusion, when you hear someone say “I keep my thermostat at 67°F” and another guy responds “My wife would kill me if I did that. I keep mine at 73°F” they might both be keeping their temperature at 70°F. It just depends on what temperature sensor their thermostat is using, and how well it was calibrated.

Categories: Uncategorized Tags: