Encrypting with the openssl in bash

With a bit of commandlinefu it becomes easy to encrypt and decrypt files with the strong 256 bit aes algorithm using openssl.

Add the following into your ~/.bashrc

# crypting functions
function encrypt {
  if [ -t 0 ]; then
    # interactive
    local fname="$1"
    shift
    openssl aes-256-cbc -salt -in "$fname" -out "${fname}.enc" $@
  else
    # piped
    perl -e 'use IO::Select; $ready=IO::Select->new(STDIN)->can_read();'
    openssl aes-256-cbc -salt $@
  fi
}
function decrypt {
  if [ -t 0 ]; then
    # interactive
    local fname="$1"
    shift
    openssl aes-256-cbc -d -in "$fname" -out "${fname%\.*}" $@
  else
    perl -e 'use IO::Select; $ready=IO::Select->new(STDIN)->can_read();'
    openssl aes-256-cbc -d $@
  fi
}

and source it to let changes take effect (source ~/.bashrc).

collectd-mod-exec Part 5

Part 1
Part 2
Part 3
Part 4

In this final part I'm publishing a real world example of the collectd-exec usage - weather info collecting script.
I'm using yahoo weather api to get weather information because it sends back very concise xml formatted text file which is only 2k in size. The weather info is updated once per hour so I've added special logic to retrieve it once per hour and feed same values in between.

collectd-mod-exec Part 4

Part 1
Part 2
Part 3

There is only one thing left to explain - how to get notified if some values go out of scope. As an example I'm going to send notification emails if CPU temperature reaches 57 degree Celsius. This could be implemented with only one additional if statement and this would work perfectly if I only had one script that sends notifications. It would become cumbersome if I needed to edit multiple scripts to change say an email address where my notifications are sent. In other words the collecting and notification logics shall be separated. To  do this one can use 'PUTNOTIF' statement that shall be sent to the script STDOUT - exactly the same way like 'PUTVAL' is sent. Documentation of the 'PUTNOTIF' arguments can be found on the collect-exec module documentation page. Additionally there shall be some logic added to send notification after some time out period otherwise emails would be sent after each $COLLECTD_INTERVAL which is by default 30 seconds. Updated tmpcollect.sh script is shown below:

collectd-mod-exec Part 3

Part1
Part2

I'll continue with the tmpcollect.sh script from the second part of this How-To. First of all I want to optimize it a bit. Running sed two times is not very performant and is also not necessary. Updated script is shown below:

collectd-mod-exec Part 2

Part1

My router SBC is equipped with two temperature sensors to monitor cpu and board temperatures. Executing 'sensors' command produces the following result:

root@Alix:~# sensors
lm86-i2c-0-4c
Adapter: CS5536 ACB0
temp1:       +36.0 C  (low  =  +0.0 C, high = +70.0 C)
                      (crit = +85.0 C, hyst = +75.0 C)
temp2:       +42.5 C  (low  =  +0.0 C, high = +70.0 C)
                      (crit = +85.0 C, hyst = +75.0 C)

With a bit of the script-fu I'm stripping temperature values and feeding them into the database:

collectd-mod-exec Part 1

Having some spare time I decided to write about powerful yet not well documented feature of the OpenWRT's luci-app-statistics plugin -- collectd-mod-exec module. This module allows collecting any type of data an external application could supply. In other words the module starts a user specified application which feeds collectd module with data. Principally having this module installed one could simulate all other collectd-mod-* modules.

IR control for your router

There are no buttons on my router but very often I need to start some task without accessing the shell. For example I want to switch wireless interface off if I don't need it and the problem here is that I cannot switch it on again wirelessly because wireless interface is off. So I thought I need some kind of a one button USB keyboard or mouse but there is no such thing. Second thought was to use some kind of IR receiver with a remote control. As far as I already have a universal remote control Logitech Harmony 885 I only needed an IR receiver that is supported by Linux. So I bought one manufactured by TechniSat for 15,20Euro with delivery (just google for - TechniSat USB IR receiver)

AVCLan (IEBus) sniffer and device emulator project

Purpose: to be able to simulate different devices attached to the IEBus.

Toyota uses the IEBus standard for internal equipment to communicate. As far as it is almost impossible to buy the IEBus driver IC it is possible to simulate it on a uController. The uController shall be fast enough to process the bus signal impulses that are less then 3 uSec. And at the same time the uController shall be fast enough to send received and processed data to the host computer in less then 120-130 uSec so the next message on the bus is not lost.

The uController of choice is pic18f2550. It contains the USB 2.0 module which supports full speed communication mode and can principally work up to 48MHz. It also contain 2 internal comparators that can be used to receive signal from the bus (though it was decided to use an external comparator to separate the uController from the bus). Device is supported by the PICmicro 18Cxx C compiler so it is possible to write the firmware in C. I'm using compiler version 2.40.

Complete schematic of the emulator is here.