Archive for the ‘Uncategorized’ Category.

« Previous Entries
Next Entries »

Simple git example (local repository)

October 10, 2011, 11:25 pm

0. Configure your information:

git config --global user.name "Mr User the user"
git config --global user.email "[email protected]"

You can also configure an editor:

git config --global core.editor 'vim'

1. Create a repository

mkdir testproject
cd testproject
git init

2. Commit a file

touch testfile
git add testfile
git commit

3. Making a release branch

git branch RB_1.0 master

While you’ve created a release branch, you’re still currently on the master branch. So if you make a change here:

touch testfile2
git add testfile2
git commit

That file will NOT be in the release branch (RB_1.0).

4. Switching between the master branch and the release branch.

Unlike, SVN which stores different branches in different directories, git uses a command to switch your directory between branches. Slightly confusingly this command is called “checkout”.

git checkout RB_1.0

If you want, you can make changes to RB_1.0, they wont be refected elsewhere.

touch rb1file
git add rb1file
git commit

5. Releasing

Create a tag:

git tag 1.0 RB_1.0

List all tags:

git tag

6. Merging

Merge changes from RB_1.0 on to master:

git checkout master
git rebase RB_1.0

7. Delete a branch

It seems to be git practice to delete branches, you can always branch from the tag.

git branch -d RB_1.0

8. Creating a tarball

git archive --format=tar --prefix=testproject1 1.0 > ~/testproject1.tar

9. Changing a file!

This may be slightly different than you were expecting. You can’t just edit the file and type “git commit” rather, you need to add then commit. For example, after editing testfile:

git add testfile
git commit

Git creates commits in two stages like this. The first add “stages” the change and commit commits it. You can do multiple adds before the commit. The idea is to let you get everything organised before finally performing the commit.

Notes on git

There are no version numbers. A revision is identified by its hash.

master is like trunk in SVN/CVS.

checkout, doesn’t really mean checkout. It mean switch between branches.

You can also branch from tags the same way you branch from master.

Tags: , ,
Category: Uncategorized  |  1 Comment

Brain Wave Synchroniser

October 9, 2011, 9:12 pm

I saw this Brain Wave Synchroniser in the Oxford Museum of the History of Science today. It’s an early ancestor of machines like the brain machine. It was manufactured in 1965 by Schneider Instruments. The whole area of brainwave entrainment seems to be more active than I realised. There’s some more information about the device here and here. I particularly like the fact that it can be used for “group induction”. The full advert reads as follows:

The Brain Wave Synchronizer

Thirty years of research have been put into this amazing unit. WHAT THIS UNIT DOES FOR YOU:

* Lessen Resistance
* Increase Suggestibility
* Reduce Induction Time to seconds.
* Deepen Hypnosis to the level you select.
* Use for Altered States of Consciousness instantly.
* Induces Healing States. Programs Mind state & MUCH MORE!!

HOW IT WORKS:

The principle of photic stimulation has been known since 1934, but it wasn’t until the work of Sidney Schneider on Radar Systems in World Ware II that its relation to hypnosis was discovered. Schneider noticed the effect that mathematically timed and shaped light pulses had on the Radar operators and applied the theory to develop the Brain Wave Synchronizer. The goal was to produce the rate of the natural brain rhythm. Whe the pattern of the light is tuned tot he subject’s own frequency, repose to hypnotic induction is rapid, easy and effective! Because of its automatic functions. The Synchronizer gives the beginner the same advantage as the professional hypnotist! The uses are unlimited! Other machines cost hundreds more and give much less results. This is the “STATE OF THE ART” model for the serious researcher or trance inducer. Why waste hours getting to “higher States” of consciousness. DO IT ALMOST INSTANTLY AND GET TO STATES MUCH DEEPER THAN YOU COULD WITHOUT THIS DEVICE.

* Single frequency control cover the four major brain ranges
* 30 minute electronic timer
* Wired remote control will Start, Stop, Tune and Time, up to 10 feet.
* Can be used for individual or group induction.
* Safe and very easy to use. No attachment to subject.
* No moving parts. ALL Photo-Electronic
* Range 1-30 pulses er second in 4 ranges: Delta, Theta, Alpha, Beta. Comes with complete instructions and one year factory service warranty.
* Audio tape instructions available for $10.00 extra.

Member Price: $480.00 & $18.00 S&H Non-Member Price $498.00 & $18.00 S&H

Category: Uncategorized  |  1 Comment

using ssh to run commands remotely

October 9, 2011, 12:02 am

Deployment systems like Chef are great, but sometimes it’s useful to have an ad-hoc method for running commands on remote systems. ssh is great for this, in part because it’s already present on most systems.

To follow these examples it’s best to have passwordless authentication setup, otherwise you’ll end up having to enter your password lots of times (you are read about this here).

Running a command on a single remote system is trivial with ssh. You can just do the following:

ssh myusername@remotecomputer mycommand

For example, if you were trying to download an install a tar ball:

ssh [email protected] wget http://exegensis.com/package.tar.gz
ssh [email protected] tar xzvf package.tar.gz
ssh [email protected] tar xzvf ./package/install.sh

Which would run three commands on the remote host to download the package, untar it and run an install script.

However with a bit of bash magic you can use ssh to run the same command on multiple systems (here valis tyrellcorp polsvr1). For example:

for i in valis tyrellcorp polsvr1; do
  ssh pkdick@$i wget http://exegensis.com/package.tar.gz;
  ssh pkdick@$i tar xzvf package.tar.gz
  ssh pkdick@$i tar xzvf ./package/install.sh
done

Which would run the same install process as above on servers called valis tyrellcorp and polsvr1.

It’s a hacky solution compared to using a real deployment system, but it can be useful at times. Particularly for quick fixes.

Category: Uncategorized  |  Comment

Simple Chef Example

October 7, 2011, 10:22 pm

Chef is a tool for the automated deployment of servers, workstations and services. The idea is pretty neat in that once you’ve built your scripts you can tell Chef “I want a new Redhat server running apache, it needs to have Ruby etc. and my web app installed” and Chef will go away and figure everything out and do it.

I’m just learning to use Chef and I wanted to put together a simple example. Getting Chef installed on Ubuntu 10.04 was harder than I expected! The install process here has a LOT of redundant steps. At some point I’ll try this again on a clean server and correct this.

So here’s the process to run an example simple Chef “recipe”. It uses chef-solo, which is a serverless version of Chef.

1. Install Chef. On Ubuntu I did the following. I had some issues during install, and some of the following packages may not be required, but this is exactly what I did:

sudo apt-get install chef ruby-dev build-essential ruby-gems1.9.1 libxml2-dev libxslt1-dev ruby1.9.1-dev
sudo apt-get install libopenssl-ruby1.9.1
sudo apt-get install ruby-gems
sudo apt-get install libmixlib-log-ruby
sudo gem install net-shh net-ssh-multi fog highline # THIS PROBABLY ISN'T REQUIRED
sudo gem install chef                               # THIS PROBABLY ISN'T REQUIRED
sudo gem install knife-ec2
sudo gem install mixlib-authentication
sudo apt-get install libhighline-ruby1.9.1
sudo apt-get install ruby-full
sudo gem install json
sudo gem install highline

2. Create a chef-solo config file and place it in ~/solo.rb (note, you must use the full path to your home directory here):

file_cache_path "/home/YOURUSERNAME/chef-solo"
cookbook_path "/home/YOURUSERNAME/chef-solo/cookbooks"

This just tells Chef where to store cached files and where your “cookbook” lives.

You need to create these directories for Chef:

mkdir chef-solo
mkdir chef-solo/cookbooks

3. Use knife to create a new “cookbook” a “cookbook” is where your “recipes” (install scripts) go. For some reason, knife isn’t anywhere on the path…

/var/lib/gems/1.9.1/gems/chef-0.10.4/bin/knife cookbook create MYCOOKBOOK -c ~/solo.rb

4. Create you recipe file, create a new file called:

~/chef-solo/cookbooks/MYCOOKBOOK/recipes/myrecipe.rb

With the following contents, edit YOURUSERNAME and YOURUSERGROUP accordingly:

if platform?("redhat", "centos", "fedora")
  # code for only redhat based systems.
  file "/tmp/rpm_based" do
    owner "YOURUSERNAME"
    group "YOURUSERGROUP"
    mode "0755"
    action :create
  end
end

if platform?("ubuntu", "debian")
  # code for debian based systems
  file "/tmp/deb_based" do
    owner "YOURUSERNAME"
    group "YOURUSERGROUP"
    mode "0755"
    action :create
  end
end

5. Create a JSON run specification. Create a new file called ~/this.json with the following contents:

{
  "run_list": [
    "recipe[MYCOOKBOOK::myrecipe]"
  ]
}

6. Run the recipe!

chef-solo -c ~/solo.rb MYCOOKBOOK -j ./this.json

This very simple example recipe just checks if the server is running a debian based distribution or a redhat one and writes a file to /tmp accordingly.

Category: Uncategorized  |  1 Comment
« Previous Entries
Next Entries »