Posts Tagged ‘Bash’

Simple bash variable security with OpenSSL

November 17th, 2010 No comments

Lets say you have a script that requires a number of variables to operate such as a database connection that requires a server, username and password. It’s usually a good idea to keep all this config in one place but dumping this in a plain text file is usually a bad idea.
The example below allows you to place application level config into a decently encrypted file and keep it all behind one master password.
To do all this we need two files. The first is obviously the encrypted variable config itself. The second is your script file which needs to decrypt the config file and perform whatever action is needed.

In this example I’m going to assume we are connecting to a remote database. Most protocols require three pieces of data to pull this off: a server, a username and a password. We are going to store these three pieces of data in a file called config.plain, encrypt this file (making config.aes), extract its variables and finally connect to our remote database.

I’m going to use the following example config.plain file:


So we need to encrypt our config.plain file and turn it into config.aes (AES being the encryption standard we are using). The following example is cheerfully swiped from the example given over at Tombuntu.

>openssl aes-256-cbc -a -salt -in config.plain -out config.aes

So if we wanted to reverse this and decrypt the config.aes file on the command line we could run:

>openssl aes-256-cbc -d -a -salt -in config.aes

NOTE: For some reason the OpenSSL CLI doesn’t obey the Unix standard of specifying ‘-‘ as a file name to output to the console. Omitting the ‘-out’ argument will instead output to STDOUT.

Putting it all together

The config.plain example file:


The config.aes file (same as above but after encryption using the password ‘password’):


The actual script file which does the decryption and performs the final actions on the data.
We are going to accept the master password from the command line (so we would run the below as ‘script password’ – assuming our script was called ‘script’ and the password was ‘password’). This is not the most secure method available since you can see the launch method of all applications running on the system using ‘ps’. If you want more security I would instead store your password in a system variable and use that instead of reading from the command line. If you wish to do this you can simply strip out all the lines that do error checking and use ‘KEY’ as a system variable to store the master password.

# USAGE: script 
# Do something with the associated config.aes script in a reasonably secure way
# Example config.plain content:
# Command to encrypt config.plain -> config.aes
# openssl aes-256-cbc -a -salt -in config.plain -out config.aes

# Do some housekeeping to check we launched with the requisite number of arguments
if [ "$#" -ne 1 ]; then
	echo "USAGE: $0 "
	exit 1

# Import the variables from our decrypted stream
STREAM=`openssl aes-256-cbc -d -pass "pass:$KEY" -a -salt -in config.aes`
if [ "$?" -ne 0 ]; then
	echo "Invalid password specified to decrypt configuration file. Aborting."
	exit 1
source <(echo "$STREAM")

echo "Server: $SERVER"
echo "Username: $USER"
echo "Password: $PASS"
Categories: HowTo's Tags:

Last.FM submissions with Audacious

June 9th, 2010 5 comments

Some time ago the good folks behind my favorite media player Audacious decided to abandon in-built support for Last.FM submissions.

The reasoning behind this seems to be that the Last.FM API was becoming a little too much to maintain which I suppose is fair enough in its quest to remain just a music player i.e. not a screen-hogging iTunes clone like so many others.

Heres how to put Last.FM support back into Audacity.

I’m going to assume you are a sensible person and using a Debian based system rather than Fedora. If you are one of these hat loving deviants, substitute ‘yum’ for apt-get below and feel free to voyage though the countless pains required to get Yum to actually do its job.

Installing LastFMSubmitD

I’m not sure on the capitalization of the daemon process LastFMSubmitD so that might be the wrong name entirely.

Anyway, first install pretty much the only component we need:

apt-get install lastfmsubmitd


For some reason the daemon does not get proxy details right. This is easily fixed by opening /etc/init.d/lastfmsubmitd in your favorite editor and inserting the following line somewhere near the top (I put it after the ‘GROUP=’ line which should be the last bit of the daemon config area).
If you have no idea what a proxy is or why you should be doing this you can probably skip this section.

export http_proxy=""

Parse Audacious output

Dump the following script somewhere you can find it. For this example I will use /home/user/bin/scrobble

if [ ! -x '/usr/lib/lastfmsubmitd/lastfmsubmit' ]; then
	echo "LastFMSubmitD does not appear to exist on this machine"
	echo "You can install it using Apt or Yum"
	exit 1
if [ "$#" == 0 ]; then
	echo 'Usage: scrobble " - " ""'
	exit 1

ARTIST=${1%% - *}
SONG=${1##* - }
LENGTH=$[ $2 / 1000 ]
echo "ARTIST = [$ARTIST]"
echo "SONG = [$SONG]"
echo "LENGTH = [$LENGTH]"

/usr/lib/lastfmsubmitd/lastfmsubmit --artist "$ARTIST" --title "$SONG" --length "$LENGTH"

Pointing Song Change at your script

First make sure you have the Song Change plugin enabled in Audacious first.

Now point the command Audacious is to run when starting a new song at the script in the following way:

/home/user/bin/scrobble "%s" "%l"

All done. Now any tracks played via Audacious will be passed to the script which will parse the incoming song title into a format that the LastFMSubmitD daemon can use.

Categories: Fixes Tags: , ,

Trash with Bash

March 4th, 2009 6 comments

One of the regrettably unavoidable aspects of the Unix shell like environments is the impedance between what a user says and what a user means. While this is present in all computing environments the sheer power of Unix based command lines make a potential mistake catastrophic.

Who amongst us has not at some point done something like:

> rm * .tmp


> rm *>tmp

The former makes the mistake of a space between the dot and the ‘tmp’ part and the latter the accidental holding down of the shift key while pressing the intended full stop.

While searching for an alternative for the I-have-done-this-too-many-times-and-now-its-embarrassing approach of nuking everything with the ‘rm’ command its time i did something about it.

Inserting the following in your ~/.bashrc file will remap the ‘rm’ command to a slightly safer move-to-trash like behavior. Its not comprehensive but it has saved my life on more than one occasion.

# Trash support by Matt Carter /dev/null

Now the command ‘rm’ moves files into ~/.trashcan. You can also use the command ‘rm!’ when you really mean delete immediately and the utility command ’emptytrash’ to clean everything out.

Categories: HowTo's Tags: ,

Zapping processes in Bash

January 24th, 2009 No comments

The following is a handy little script I wrote which politely asks a collection of matching processes to exit. After a second the process is forcibly killed.

This command is designed as a drop-in replacement for the slightly cryptic pgrep and pkill commands.

zap() {
	# Usage: zap [SIGNAL|-NUMERIC|shoot] 
	case "$1" in
		shoot|-0) SIGNAL='SHOOT';;
		term|-15) SIGNAL='TERM';;
		kill|-9) SIGNAL='KILL';;
		hup|-1) SIGNAL='HUP';;
	if [ "$SIGNAL" != '' ]; then
	PROCS=`ps ax -eo pid,comm | fgrep "$1"`
	for DATA in $PROCS; do
		if [ "$MODE" -eq 0 ]; then
			if [ "$SIGNAL" == 'SHOOT' ]; then
				echo -n "Shooting #$PID - $CMD..."
				kill $PID
				sleep 1
				kill -9 $PID
				echo "Shot"
				echo -n "Killing #$PID - $CMD..."
				kill $SIGNAL $PID
				echo "Killed"

To install it simply dump the above text inside your existing ~/.bashrc file.

Usage is quite simple:

To politely kill all processes (then force-killing if it still does not die) containing the string ‘gnome’:

zap gnome

To just kill-forcefully:

zap -9 gnome
Categories: HowTo's Tags: