A TileMill server with all the trimmings

Recently, I set up a server for a series of #datahack workshops. We used TileMill to make creative maps with OpenStreetMap and other available data.

The major pieces required are:

• TileMill, which comes with its own installer, and is totally self-sufficient: web application server, Mapnik, etc.
• Postgres, the database which will hold the OSM data
• PostGIS, the extension which allow Postgres to do that
• Nginx, a reverse proxy, so we can have some basic security (TileMill comes with none)
• OSM2PGSQL, a tool for loading OSM data into PostGIS

I’ve captured all those bits, and their configuration in this script. You’ll probably want to change the password – search for “cow”.

 

#!/bin/bash

# This script installs TileMill, PostGIS, nginx, and does some basic configuration.
# The set up it creates has basic security: port 20009 can only be accessed through port 80, which has password auth.

# The Postgres database tuning assumes 32 Gb RAM.

# Author: Steve Bennett

wget https://github.com/downloads/mapbox/tilemill/install-tilemill.tar.gz
tar -xzvf install-tilemill.tar.gz

sudo apt-get install -y policykit-1

#As per https://github.com/gravitystorm/openstreetmap-carto

sudo bash install-tilemill.sh

#And hence here: http://www.postgis.org/documentation/manual-2.0/postgis_installation.html
#? 
sudo apt-get install -y postgresql libpq-dev postgis

# Install OSM2pgsql

sudo apt-get install -y software-properties-common git unzip
sudo add-apt-repository ppa:kakrueger/openstreetmap
sudo apt-get update
sudo apt-get install -y osm2pgsql

#(leave all defaults)

#Install TileMill

sudo add-apt-repository ppa:developmentseed/mapbox
sudo apt-get update

sudo apt-get install -y tilemill

# less /etc/tilemill/tilemill.config
# Verify that server: true

sudo start tilemill

# To tunnel to the machine, if needed:
# ssh -CA nectar-maps -L 21009:localhost:20009 -L 21008:localhost:20008
# Then access it at localhost:21009

# Configure Postgres

echo "CREATE ROLE ubuntu WITH LOGIN CREATEDB UNENCRYPTED PASSWORD 'ubuntu'" | sudo -su postgres psql
# sudo -su postgres bash -c 'createuser -d -a -P ubuntu'

#(password 'ubuntu') (blank doesn't work well...)

# === Unsecuring TileMill

export IP=`curl http://ifconfig.me`

cat > tilemill.config <<FOF
{
  "files": "/usr/share/mapbox",
  "coreUrl": "$IP:20009",
  "tileUrl": "$IP:20008",
  "listenHost": "0.0.0.0",
  "server": true
}
FOF
sudo cp tilemill.config /etc/tilemill/tilemill.config

# ======== Postgres performance tuning
sudo bash
cat >> /etc/postgresql/9.1/main/postgresql.conf <<FOF
# Steve's settings
shared_buffers = 8GB
autovaccuum = on
effective_cache_size = 8GB
work_mem = 128MB
maintenance_work_mem = 64MB
wal_buffers = 1MB

FOF
exit

# ==== Automatic start 
cat > rc.local <<FOF
#!/bin/sh -e
sysctl -w kernel.shmmax=8000000000
service postgresql start
start tilemill
service nginx start
exit 0
FOF

sudo cp rc.local /etc/rc.local

# === Securing with nginx
sudo apt-get -y install nginx

cd /etc/nginx
sudo bash
printf "maps:$(openssl passwd -crypt 'incorrect cow cell pin')\n" >> htpasswd
chown root:www-data htpasswd
chmod 640 htpasswd
exit


cat > sites-enabled-default <<FOF

server {
   listen 80;
   server_name localhost;
   location / {
        proxy_set_header Host \$http_host;
        proxy_pass http://127.0.0.1:20009;
        auth_basic "Restricted";
        auth_basic_user_file htpasswd;
    }
}

server {
   listen $IP:20008;
   server_name localhost;
   location / {
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:20008;
        auth_basic "Restricted";
        auth_basic_user_file htpasswd;
    }
}


FOF

sudo cp sites-enabled-default /etc/nginx/sites-enabled/default
sudo service nginx restart

echo "Australia/Melbourne" | sudo tee /etc/timezone
sudo dpkg-reconfigure --frontend noninteractive tzdata

								

			

Forget trying to remember your servers’ names!

I run lots of Linux servers. I create them, install some stuff, mess around with them, forget them, come back to them…and forget my credentials. My life used to look like this:

$ ssh -i ~/steveko.pem steveb@115.146.83.268
Permission denied (publickey).
$ ssh -i ~/steveko.pem sbennett@115.146.83.268
Permission denied (publickey).
$ ssh -i ~/stevebennett.pem steveb@115.146.83.268
Permission denied (publickey).
$ ssh -i ~/steveko.pem ubuntu@115.146.83.268
Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-26-generic x86_64)
...

This got really tedious. You can’t memorise many IP addresses, so you’re constantly referring to emails, post-its or even SMSes. Then you rebuild your server, the IP address changes, and you’re lost again.

And because some of the servers are administered by other people, I can’t always choose my own user name, so more faffing around.

So, here’s my solution:

A naming convention for servers

Give each server a name. Ignore the actual hostname of the server, or what everyone else calls it. My convention goes like this:

<infrastructure>-<project>[-<purpose>]

Examples:

• nectar-tugg-dev: A development server for the TUGG project, running on NeCTAR Research Cloud infrastructure.
• rmit-microtardis-prod: A development server for MicroTardis, running on RMIT infrastructure.
• nectar-tunnelator: A side project “tunnelator” running on NeCTAR Research Cloud infrastructure. Small projects only have one server.

The key here is minimising what you need to remember. If I’m doing some work on a project, I’ll always know the project name and whether I want to work on the prod or dev server. Indeed, it’s an advantage to have to specifically type “-prod” when working on a production machine.

Put all IP addresses in /etc/hosts.

When I create a server, or someone tells me an IP, I immediately give it a name, and store it in /etc/hosts. The file looks like this:

##
# Host Database
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost 
fe80::1%lo0 localhost
115.146.46.269 nectar-tunnelator
136.186.3.299 swin-bpsyc-dev
...

This has the huge advantage that you can also put those names in the browser address bar: http://nectar-tunnelator

If a server moves location, just update the entry in /etc/hosts, and forget about it again.

Put all access information in ~/.ssh/config

The SSH configuration file can radically simplify your life. You have one entry per server, like this:

Host latrobe-vesiclepedia-dev
 User steveb
 IdentityFile /Users/stevebennett/Dropbox/VeRSI/NeCTAR/nectar.pem
 Port 9022

Notice how we don’t need to spell out the IP address again. And by storing the access details here, we can connect like this:

$ ssh latrobe-vesiclepedia-dev

So much less to remember. And because it’s so easy to connect, suddenly tools like SCP, and SSH tunnelling become much more attractive.

$ scp myfile.txt latrobe-vesiclepedia-dev
$ ssh latrobe-vesiclepedia-dev sudo cp myfile.txt /var/www

In reality, it gets even simpler. Most of my NeCTAR boxes are Ubuntu, with a login name of “ubuntu”. The “nectar-” naming convention proves valuable:

Host nectar-*
 IdentityFile /Users/stevebennett/Dropbox/VeRSI/NeCTAR/nectar.pem
 User ubuntu

That means that any NeCTAR box using that key and username doesn’t even need its own entry in .ssh/config:

$ ssh nectar-someserver

Anonymous longitudinal surveys with LimeSurvey

A researcher at the Australian Research Centre in Sex, Health and Society (ARCSHS, pronounced “archers”) carries out surveys that are both:

• anonymous: personal details are not collected, and steps are taken to avoid being able to identify participants; and
  
• longitudinal: participants are contacted at intervals to answer similar questions. Questions often refer to previous answers given by the participant.

It’s a tricky combination, not well supported by most survey software. Here’s a solution, using LimeSurvey, that doesn’t require modifying any code. These instructions are aimed at people with no familiarity with LimeSurvey.

Quick summary:

1. The survey is carried out in not anonymous mode. Anonymity is maintained through an external email redirection service.
2. Additional attributes are added on to token tables for follow-up rounds.
3. Answers from each survey are transferred to the additional attributes through Excel manipulation

Survey hosting

LimeService is a very cheap way to host LimeSurvey, and removes the burden of server administration.

Anonymous email addresses

Participants must not sign up for the survey using their actual email address. Instead, they should go to a third-party email forwarding site like http://notsharingmy.info. For the participant:

1. Click on a link
2. Enter their email address, click “Get an obscure email”
3. Copy the generated email address into the survey registration form.

(Note: as of January 2013, notsharingmy.info is unreliable. I’m working on another solution.)

About tokens

This solution relies heavily on LimeSurvey’s “tokens” which are explained badly in the interface. Enabling tokens just means you want to track information about individual participants: individual adding them to the list, inviting them, keeping track of who completed the survey or who needs another reminder. We also add “additional attributes”: the participants’ previous answers.

1. Set up the initial survey

1. Create a new survey:  
2. Fill out the Description, Welcome Message, End Message.
3. Create the first question group.
4. Create some questions.
5. Set these survey “general settings”:
   1. Tokens > Allow public registration? Yes
   2. (Optional) Modify the registration text as described below in “Avoiding personal information”
6. Activate the survey. You’ll be asked if you want to initialise tokens:
   
   Yes, you do.
7. Publicise the URL, and get lots of responses. Great.

Avoiding personal information

By default, LimeSurvey collects from each self-registering participant their first name, last name and email address. For a truly anonymous survey, you may wish to avoid collecting their name.

1. Under Global Settings, choose Template Editor:
   
   
2. As the warning points out, editing the default template isn’t a great idea. Let’s make a copy called “no_name_collecting”:
   
3. Now, edit the copy. Select “startpage.pstpl”, then add  this code just before the “</head”> line:

   ...
   <script>
   $(function(){
   $("[name=register_firstname]").parent().parent().hide()
   $("[name=register_lastname]").parent().parent().hide()
   });
   </script>
   </head>

   

    

4. Next, you might want to change the registration message, to direct people to create an anonymous email address. On the “Register” screen,
   select “register.pstpl”.
5. In the code, replace {REGISTERMESSAGE1} and {REGISTERMESSAGE2} with any text or HTML you like.

2. Export responses and tokens

1. Export the responses as CSV
   
   
2. Export the tokens as CSV:
   
   
   

3. Create follow-up survey

The first survey was a success, and there are now lots of entries in the tokens table and the responses table. More in the former than the latter, because some people will sign up and not answer any questions.

1. Copy the first survey. (Click the + button, like starting a new survey first.)
   
   
2. You’ll probably want to remove some irrelevant questions and groups, so do that.
3. Now add one “additional attribute” for every response that you want to refer to from the initial survey. In Token Management:
   The other fields don’t matter. Leave them blank.
4. Next, you may want to use these attributes in some questions. Let’s say you want to ask “Last time you did this survey you were 42. How old are you now?”
   In the question text, click ‘LimeSurvey replacement field properties’ then select the extended attribute:The text then looks like this:
   
5. You can get fancy and set that value as the default for the question. Instructions on how to do this.
6. Repeat this for each question, wherever those extended attributes are needed.

4. Transfer previous responses to the follow-up survey

1. Download the token table for this survey. It will have no data, but the headers will be useful.So far, you have created a way to hold answers from previous surveys for each participant. But you haven’t actually put those answers in there. Time for some Excel magic. You want to create a token table for the follow-up survey, using bits from the three CSV files you’ve dowloaded so far.:
   1. Tokens table for initial survey. (Containing the email addresses people signed up with.)
   2. Responses for initial survey.
   3. Tokens table for follow-up survey (containing the additional attributes).
2. Copy all the rows of tokens from the initial survey to the follow-up survey. Don’t copy the header row:Make sure you retain the additional attribute fields (attribute_1 etc.) They should be blank.
3. Notice that these tokens have already been “completed”. Clear out the invited and completed fields. Set the remindercount field to 0 and usesleft field to 1:
   
4. Now, copy columns from the participant responses table into attribute fields, one by one, as appropriate. Make sure the IDs line up correctly.
5. Save the file (“followup-tokens.csv” if you like). Now import it into your follow-up survey.

5. Activate the follow-up survey

Whew. You’re now ready to launch.

1. Activate the survey.
2. Send out invitations. Under “Token control”:
3. The default email template is pretty gross, so clean it up a bit before you send:
4. Each participant receives a custom URL which logs them in without requiring any username and password.

You can then repeat this process for each subsequent iteration.

Windows red cross errors scam

We have noticed many red cross errors!

I just received an interesting phone call, apparently from a group of Indian scammers. It went roughly like this. (Phrases in bold are things I jotted down during the call)

• Hello, I’m Caroline from the Computer Technical Department at Windows Best Help [or Windows Based Help, perhaps]. We’re calling to alert you that for the past four weeks you’ve been receiving red cross errors, which mean you’re subject to internet viruses, and hackers that are trying to break into your computer. Your address is [my address], correct?

Throughout this, I give non-committal “mmm, yes” responses.

• We’re connected through the Global IT Server. This just an awareness call, nothing to do with telemarketing.
• Now, go to the home page of your browser.
• Now press Windows-R, and type “cookies“. [Actually, long description of how to find the Windows key, and spelling out "cookies" in radio code. The first "o" was orange, the second was Oscar.]

• Now, do you see all those files and folders? All the work you’re doing is stored in those files as a double coded check up.

I’m calling from the Computer Technical Department at Windows Best Help. This has nothing to do with telemarketing!

At this point, she transferred me to her “technical supervisor”. He gave me his name, but I didn’t quite catch it – something like Armin. I asked where they’re based – Kolkata.

• Are you in front of your computer now? [I admitted that, no, the phone was in a different room.]
• But I believe that you told Caroline that you were typing the commands and could see the results? [Interesting...I had led her to believe that. Is their operation so small that he listens to the whole conversation?]

Some confusion followed, where I offered to go and run the command for real. I told him to hold the line for a minute, while I went and did it. When he came back, the line was dead. Oops.

I’ve heard of this scam before, but it was entertaining to see it in operation. Too bad I didn’t get to see where it led.

What I learned at e-Research Australasia 2012

1. Waterfall development still doesn’t work.
2. Filling an institutional research data registry is still a hard slog.
3. Omero is not just for optical microscopy.
4. Spending money so universities can build tools that the private sector will soon provide for free ends badly.
5. Research data tools that mimicking the design of laymen’s tools (“realestate.com.au for ecologists“) work well
6. AURIN is brilliant. AuScope is even more brilliant than before.
7. Touchscreen whiteboards are here, are extremely cool, and cost less than $5000.
8. AAF still doesn’t work, but will soon. Please.
9. NeuroHub. If neuroscience is your thing.
10. Boring, mildly offensive after-dinner entertainment works well as a team-building exercise.
11. All the state-based e-Research organisations (VeRSI, IVEC, QCIF, Intersect, eRSA, TPAC etc.) are working on a joint framework for e-research support.
12. Cytoscape: An Open Source Platform for Complex Network Analysis and Visualization
13. Staff at e-Research organisations have much more informed view of future e-Research projects, having worked on so many of them.
14. If you tick the wrong checkbox, your paper turns into a poster.
15. People find the word “productionising” offensive, but don’t mind “productifying”.
16. CloudStor’s FileSender is the right way for people in the university sector to send big files to each other.

Build it? Wait for someone else to build it?

And a thought that hit me after the conference: although a dominant message over the last few years has been “the data deluge is coming! start building things!”, there are sometimes significant advantages in waiting. e-Research organisations overseas are also building data repositories, registries, tools etc. In many cases, it would pay to wait for a big project overseas to deliver a reusable product, rather than going it alone on a much smaller scale. So, since we (at e-Research organisations) are trying to help many researchers, perhaps we should consider the prospect of some other tool arriving on the scene, when assessing the merit of any individual project.

A pattern for multi-instrument data harvesting with MyTardis

Here’s a formula for setting up a multi-instrument MyTardis installation. It describes one particular pattern, which has been implemented at RMIT’s Microscopy and Microanalysis Facility (RMMF), and is being implemented at Swinburne. For brevity, the many variations on this pattern are not discussed, and gross simplifications are made.

This architecture is not optimal for your situation. Maybe a documented a suboptimal architecture is more useful than an undocumented optimal one.

The goal

The components:

• RSync server running on each instrument machine. (On Windows, use DeltaCopy.)
• Harvester script which collates data from the RSync servers to a staging area.
• Atom provider which serves the data in the staging area as an Atom feed.
• MyTardis, which uses the Atom Ingest app to pull data from the Atom feed. It saves data to the MyTardis store and metadata to the MyTardis database.

Preparation

Things you need to find out:

1. List of instruments you’ll be harvesting from. Typically there’s a point of diminishing returns: 10 instruments in total, of which 3 get most of the use, and numbers #9 and #10 are running DOS and are more trouble than they’re worth.
2. For each instrument: what data format(s) are produced? Some “instruments” have several distinct sensors or detectors: a scanning electron microscope (producing .tif images) with add-on EDAX detector (producing .spt files), for instance. If there is no MyTardis filter for the given data format(s), then MyTardis will store the files without extracting any metadata, making them opaque to the user.
   

   Details collected for each instrument at RMIT’s microscopy facility.

3. Discuss with the users how MyTardis’s concept of “dataset” and “experiment” will apply to the files they produce. If possible, arrange for them to save files into a file structure which makes this clear: /User_data/user123/experiment14/dataset16/file1.tif . Map the terms “dataset” and “experiment” as appropriate: perhaps “session” and “project”.
4. Networking. Each instrument needs to be reachable on at least one port from the harvester.
5. You’ll need a staging area. Somewhere big, and readily accessible.
6. You’ll eventually need a permanent MyTardis store. Somewhere big, and backed up. (The Chef cookbooks actually assume storage inside the VM, at present.)
7. You’ll eventually need a production-level MyTardis database. It may get very large if you have a lot of metadata (eg, Synchrotron data). (The Chef cookbooks install Postgres locally.)

RSync Server

We assume each PC is currently operating in “stand-alone” mode (users save data to a local hard disk) but is reachable by network. If your users have authenticated access to network storage, you’ll do something a bit different.

Install an Rsync server on each PC. For Windows machines, use DeltaCopy. It’s free. Estimate 5 minutes per machine. Make it auto-start, running in the background, all the time, serving up the user  data directory on a given port.

Harvester script

The harvester script collates data from these different servers into the staging area. The end result is a directory with this kind of structure:

user_123
        TiO2
            2012-03-14 exp1
                run1.tif
                run2.tif
                edax.spc
            2012-03-15 exp1
                anotherrun.tif
                highmag.tif
user_456
...

You will need to customise the scripts for your installation.

1. Create  a staging area directory somewhere. Probably it will be network storage mounted by NFS or something.
2. sudo mkdir /opt/harvester
3. Create a user to run the scripts, “harvester”. Harvested data will end up being owned by this user. Make sure that works for you.
4. sudo chown harvester /opt/harvester
5. sudo -su harvester bash
6. git clone https://github.com/VeRSI-Australia/RMIT-MicroTardis-Harvest
7. Review the scripts, understand what they do, make changes as appropriate.
8. Create a Cron job to run the harvester at frequent intervals. For example:
   */5 * * * * /usr/local/microtardis/harvest/harvest.sh >/dev/null 2>&1
9. Test.

Atom provider

My boldest assumption yet: you will use a dedicated VM simply to serve an Atom feed from the staging area.

Since you already know how to use Chef, use the Chef Cookbook for the Atom Dataset Provider to provision this VM from scratch in one hit.

1. git clone https://github.com/stevage/atom-provider-chef
2. Modify cookbooks/atom-dataset-provider/files/default/feed.atom as appropriate. See the documentation at https://github.com/stevage/atom-dataset-provider.
3. Modify environments/dev.rb and environments/prod.rb as appropriate.
4. Upload it all to your Chef server:
   knife cookbook upload –all
   knife environment from file environments/*
   knife role from file roles/*
5. Bootstrap your VM. It works first try.

MyTardis

You’re doing great. Now let’s install MyTardis. You’ll need another VM for that. Your local ITS department can probably deliver one of those in a couple of hours, 6 months tops. If possible (ie, if no requirement to host data on-site), use the Nectar Research Cloud.

You’ll use Chef again.

1. git clone https://github.com/mytardis/mytardis-chef

2. Follow the instructions there.
3. Or, follow the instructions here: Getting started with Chef on the NeCTAR Research Cloud.
4. Currently, you need to manually configure the Atom harvester to harvest from your provider. Instructions for that are on Github.

MyTardis is now running. For extra credit, you will want to:

• Develop or customise filters to extract useful metadata.
• Add features that your particular researchers would find helpful. (On-the-fly CSV generation from binary spectrum files was a killer feature for some of our users.)
• Extend harvesting to further instruments, and more kinds of data.
• Integrate this system into the local research data management framework. Chat to your friendly local librarian. Ponder issues like how long to keep data, how to back it up, and what to do when users leave the institution.
• Integrate into authentication systems: your local LDAP, or perhaps the AAF.
• Find more sources of metadata: booking systems, grant applications, research management systems…

Discussion

After developing this pattern for RMMF, it seems useful to apply it again. And if we (VeRSI, RMIT’s Ian Thomas, Monash’s Steve Androulakis, etc) can do it, perhaps you’ll find it useful too. I was inspired by Peter Sefton’s UWS blog post Connecting Data Capture applications to Research Data Catalogues/Registries/Stores (which raises the idea of design patterns for research data harvesting).

Some good things about this pattern:

• It’s pretty flexible. Using separate components means individual parts can be substituted out. Perhaps you have another way of producing an Atom feed. Or maybe users save their data directly to a network share, eliminating the need for the harvester scripts.
• By using simple network transfers (eg, HTTP), it suits a range of possible network architectures (eg, internal staging area, but MyTardis on the cloud; or everything on one VM…)
• Work can be divided up: one party can work on harvesting from the instruments, while another configures MyTardis.
• You can archive the staging area directly if you want a raw copy of all data, especially during the testing phase.

Some bad things:

• It’s probably a bit too complicated – perhaps one day there will be a MyTardis ingest from RSync servers directly.
• Since the Atom provider is written in NodeJS, it means another set of technologies to become familiar with for troubleshooting.
• There are lots of places where things can go wrong, and there is no monitoring layer (eg, Nagios).

Getting started with Chef on the NeCTAR Research Cloud

Opscode Chef is a powerful tool for automating the configuration of new servers, and indeed, entire clouds, multi-server architectures etc. We now use it to deploy MyTardis. It’s quite daunting at first, so here’s a quick guide to the setup I use. You’ll probably need to refer to more complete tutorials to cover gaps (eg  OpsCode’s Fast Start Guide, the MyTardis chef documentation and this random other one.) We’ll use installing MyTardis as the goal.

1. Sign up to Hosted Chef. That gives you a place where Chef cookbooks, environments, roles etc will live.
2. Install Chef (client) locally.
3. Get the MyTardis Chef cookbook:

   cd ~/mytardis
   git clone https://github.com/mytardis/mytardis-chef

4. Make a directory, say ~/chef, and download the “…-validator.pem” and knife.rb files that Opscode gives you to there. The knife.rb file contains settings for Knife, like directories. Modify it so it points to ~/mytardis/mytardis-chef. Mine looks like this

   current_dir = File.dirname(__FILE__)
   log_level :info
   log_location STDOUT
   node_name "stevage"
   client_key "#{current_dir}/stevage.pem"
   validation_client_name "versi-validator"
   validation_key "#{current_dir}/versi-validator.pem"
   chef_server_url "https://api.opscode.com/organizations/versi"
   cache_type 'BasicFile'
   cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
   cookbook_path ["#{current_dir}/../mytardis/mytardis-chef/site-cookbooks", "#{current_dir}/../mytardis/mytardis-chef/cookbooks"]

5. You now need to upload these cookbooks and assorted stuff to Chef Server. This part of Chef is really dumb. (Why isn’t there a single command to do this – or why can’t knife automatically synchronise either a local directory tree or git repo with the Chef server. Why is one command ‘upload’ and another ‘from file’…? Why are cookbooks looked for in the ‘cookbooks path’ but roles are sought under ./roles/?)

   knife cookbook upload -a
   knife role from file ../mytardis/mytardis-chef/roles/mytardis.json

6. Get a NeCTAR Research Cloud VM. Launch an instance of “Ubuntu 12.04 LTS (Precise) amd64 UEC”. Call it “mytardisdemo”, give it your NeCTAR public key, and do what you have to (security groups…) to open port 80.
7. Download your NeCTAR private key to your ~/chef directory.
8. Now, to make your life a bit easier, here are three scripts that I’ve made to simplify working with Knife:bootstrap.sh:

   #!/bin/bash -x
   # Bootstraps Chef on the remote host, then runs its runlist.
   source ./settings$1.sh
   knife bootstrap $CHEF_IP -x $CHEF_ACCOUNT --no-host-key-verify -i nectar.pem --sudo $CHEF_BOOTSTRAP_ARGS

   update.sh:

   #!/bin/bash -x
   # Runs Chef-client on the remote host, to run the latest version of any applicable cookbooks.
   source settingsi$1.sh
   knife ssh name:$NECTAR_HOST -a ipaddress -x $NECTAR_ACCOUNT -i nectar.pem -o "VerifyHostKeyDNS no" "sudo chef-client"

   connect.sh:

   #!/bin/bash -x
   # Opens an SSH session to the remote host.
   source ./settings$1.sh
   ssh $CHEF_ACCOUNT@$CHEF_IP -i nectar.pem -o "VerifyHostKeyDNS no"

   (We disable host key checking because otherwise SSH baulks every time you allocate a new VM with an IP that it’s seen before.)With these, you can have several “settings…sh” files, each one describing a different remote host. (Or just a single settings.sh). So, create a “settings-mytardisdemo.sh” file, like this:

   # Settings for Ubuntu Precise NeCTAR VM running mytardis as a demo
   export CHEF_HOST=mytardisdemo
   export CHEF_IP=115.146.94.53
   export CHEF_ACCOUNT=ubuntu
   export CHEF_BOOTSTRAP_ARGS="-d ubuntu12.04-gems -r 'role[mytardis]'"

9. Now you have it all in place: A chef server with the cookbook you’re going to run, a server to run it on, and the local tools to do it with. So, bootstrap your instance:

   ./bootstrap.sh -mytardisdemo

   If all goes well (it won’t), that will churn away for 40 minutes or so, then MyTardis will be up and running.

10. If you change a cookbook or something (don’t forget to re-upload) and want to run chef again:

    ./update.sh -mytardisdemo

11. And to SSH into your box:

    ./connect.sh -mytardisdemo