gsandie online notebook

Sometimes you may want to change where you install something to with make. Setting the DESTDIR environment variable can achieve this:

$ mkdir /tmp/test_install
$ make install DESTDIR=/tmp/test_install

It will then get installed with any PREFIX you’ve set into the DESTDIR.

When in doubt have a look in the Makefile.

Once on the instance:

$ curl http://169.254.169.254/latest/meta-data/

Then query further based on the list returned.

E.g: 

$ curl http://169.254.169.254/latest/meta-data/hostname/
ip-10-235-49-118.eu-west-1.compute.internal

This is also how user-data is returned. 

More at: http://docs.amazonwebservices.com/AWSEC2/2008-08-08/DeveloperGuide/index.html?AESDG-chapter-instancedata.html

I had a bunch of files I needed to remove the BOM from to keep some ruby stuff happy:

http://en.wikipedia.org/wiki/Byte-order_mark

Turns out this is pretty simple to do with vim:

$ file foo.txt
foo.txt: UTF-8 Unicode (with BOM) English text, with very long lines, with CRLF, CR line terminators
$ vim foo.txt
:set nobomb
:wq
$ file foo.txt
foo.txt: UTF-8 Unicode English text, with very long lines, with CRLF, CR line terminators
$

Use FIGNORE - see man bash.

They can be downloaded here:

http://download.virtualbox.org/virtualbox/

This will save me time in the future :)

My last post didn’t tell the whole picture on replicated chef setups. You need to have the couchbds set to do bidirectional replication. This ensures that status updates are applied to all nodes, amongst other stuff :)

Starting a work project to replicate the chef servers. I’ve done some POC in the lab, now to out it in practice.

Notes, thoughts, ramblings are below:

• start off with a clean and fresh chef server, setup knife and your repo


• use git for the repo


• use couchdb 0.11


• config couch to bind to a remotely accessible ip, not strictly needed, but could be handy



• add a couchdb_url (check syntax) and set to the ip/port that couch is on (else failure will occur!!)




• rinse and repeat the above on a second box



• use ntp on both!!

At this state you have two working chef instances. Remember that the chef bootstrap install will define a random admin password that is set in the server.rb

• on your second machine remove the client.pem and validate.pem files



• copy the validate.pem from machine one onto machine two (you need this to register machine two as a client)




• make sure you have curl installed



• create a file with the following json:

{“source”:”http://:”,”target”:”http://:”,”continuous”:true}

• setup replication by feeding the json to couch:

$ curl -d @json-file -H “Content-Type: application/json” http://:/_replicate

• replication should now be working, you can test it by hitting http://:/_utils you’ll get the web interface




• ensure your repo is available on both of the hosts - outstanding task is to sort out automatic pulls to the slaves when there is an update on the master

You should now be able to register a client against the master and then update that master against the master or the slave.

Still need some further testing and work on getting the repos being synced out. Also need to setup git/svn gateways as most the debs are using svn.

Bootstrap installs of a chef server are a joy. I figured I would give it a bash in a basic debian install.

Some notes - mostly my thoughts before I forget (TODO: organise):

• start with a base net-installed system and upgrade it to testing
• install build-essential I forgot at first and had to mess about with packages like make g++
• you’ll need libopenssl-ruby
• get all the ruby gems and rubydev packages
• malformed json and no -j flag to chef-solo will cause you a headache!!