Deploying Multiple files using Chef and Arrays

This post is one of a number of posts I’m making on nifty little tricks for Chef beginners.  These posts will try and detail solutions to common problems I found when learning Chef.  Hopefully I will save some people some time.

When I first started using Chef I would write the same lines of code over and over again to deploy files to a server.  This code would look something like the following:

cookbook_file "/etc/test/file1.txt"
   source "/my/files/file1.txt"

While this works for a few files it soon becomes unmanageable when you need to deploy more than a few.  The easiest way to keep your recipe nice and tidy is to create an array of the files and loop through the array performing the Chef action on the file that’s needed.  This will reduce the number of lines in your recipe and will be easier to maintain going forward.  This looks like this:

# Location of the files and templates within the cookbook
# the following location would translation to files/default/my/files

# Location to deploy to

# Array of the files that require to be deployed
file_array = [

# For each file in the array
file_array.each do |this_file|
   cookbook_file "#{etc_directory}/" + this_file do
      source "#{files_directory}/#{this_file}"

The inner code works with cookbook_file, template or anything else you may need to do multiple times.


Upgrading a BitSeed Node to Bitcoin Classic

I wanted to see if I could get my BitSeed Full Node running Bitcoin Classic.  It turns out that its easy to do.

Log in using the supplied username and password, then make sure you have all the prerequisite build software:

linaro@bitseed:~$ sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils

Some of the software may already be installed.  I’ve used my node for other things too, so I only needed libevent-dev, your mileage may vary.  Git clone the Bitcoin Classic GitHub repository:

linaro@bitseed:~$ git clone

Change directory to the newly created bitcoinclassic folder then run autogen, configure and make to build the software:

linaro@bitseed:~$ cd bitcoinclassic
linaro@bitseed:~$ git checkout v0.11.2.cl1.b1
linaro@bitseed:~/bitcoinclassic$ ./ && ./configure && make

Then get ready to perform the old-switcharoo by first changing back to your home directory:

linaro@bitseed:~/bitcoinclassic$ cd ~

Then stopping the current bitcoind process:

linaro@bitseed:~$ ./

Once its stopped, move the old Bitcoin Core software somewhere safe in case you decide to switch back:

linaro@bitseed:~$ mv bitcoin-cli bitcoin-cli.core
linaro@bitseed:~$ mv bitcoind bitcoind.core

Then move the new Bitcoin Classic software to your home directory:

linaro@bitseed:~$ mv bitcoinclassic/src/bitcoind .
linaro@bitseed:~$ mv bitcoinclassic/src/bitcoin-cli .

Finally, start the bitcoind processes, this time using Classic:

linaro@bitseed:~$ ./

Once its finished checking the blockchain you should be able to see your new software using ./

linaro@bitseed:~$ ./
 "version": 129900,
 "protocolversion": 70012,
 "walletversion": 60000,
 "balance": 0.00233482,
 "blocks": 396154,
 "timeoffset": 0,
 "connections": 15,
 "proxy": "",
 "difficulty": 120033340651.237,
 "testnet": false,
 "keypoololdest": 1434935723,
 "keypoolsize": 101,
 "paytxfee": 0.00000000,
 "relayfee": 0.00001000,
 "errors": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
device ip:
Mon Feb 1 15:05:59 UTC 2016

To switch back simply stop the bitcoind process and switch the binaries back:

linaro@bitseed:~$ ./

Once its stopped, move the new Bitcoin Classic software somewhere safe again:

linaro@bitseed:~$ mv bitcoin-cli bitcoin-cli.classic
linaro@bitseed:~$ mv bitcoind bitcoind.classic

Then move the old Bitcoin Core software:

linaro@bitseed:~$ mv bitcoind.core bitcoind
linaro@bitseed:~$ mv bitcoin-cli.core bitcoin-cli

Finally, start the bitcoind processes, this time using Core again:

linaro@bitseed:~$ ./

No warranties come with this guide!  Use it at your own risk!

EDIT: I forgot to include git checkout v0.11.2.cl1.b1, but I’ve I’ve revised the post to include this.


RHEL Linux VMware migration eth0 eth1 problems…

I’ve recently had an incident where a Red Hat Enterprise Linux server that had been migrated between two VMware clusters (in this case dev to live) had no network connectivity after the migration.  The server had lost eth0 and had gained an unconfigured eth1 instead.  After a little bit of research I found that this was because the UUID and the MAC address had changed on the virtual hardware making the ifcfg-eth0 configuration file invalid

The fix was fairly simple – remove the UUID from ifcfg-eth0, delete the udev rules for the the network card, correct the MAC address and restart the network service.

I wrote this simple script for others to use:


# Backup all files first
mkdir nic_change_backup
cp /etc/sysconfig/network-scripts/ifcfg-eth0 nic_change_backup
cp /etc/udev/rules.d/70-persistent-net.rules nic_change_backup
tar jcpvf nic_change_backup.tar.bz2 nic_change_backup
rm -rf nic_change_backup

# Remove the udev rule
# They are re-created on boot up
rm -f /etc/udev/rules.d/70-persistent-net.rules

# Fix the eth0 file
# This involves removing the UUID and
# updating the HWADDR with the MAC
# address of the new card.
grep -v UUID /etc/sysconfig/network-scripts/ifcfg-eth0 | sed '/HWADDR/c\'$(echo "HWADDR:$(echo "$(ip addr | grep ether | cut -d\  -f 6)" | tr '[:lower:]' '[:upper:]')") > /etc/sysconfig/network-scripts/ifcfg-eth0

# Restart networking, or in this case the server
shutdown -r now