Category Archives: Random

n00b-alert-3: Setting up Symfony2

Now that we have our development stack in place, we are going to install Symfony2, which is the PHP framework we will be using to develop our new system.

Installing Git

For version control, collaboration and backup of our codebase, we will be using Git, with our repositories hosted at GitHub. As I am working on Windows, I have chosen to use Git Extensions. Download and install this. Then we’re good to clone our respository from GitHub.

Clone repository

Find the respsitory and then copy the SSH URL from near the top of the page. Paste this into the Repository to clone field. Then select the Destination folder and also the subdirectory which we want to create for the repository. If there are any submodules which are referenced from the base repository, make sure that “Initialize all submodules” is checked, so we can pull all of them down from GitHub too.

Load SSH key

In order to authenticate with GitHub, we need to generate a public/private key with PuTTYGen and then upload the public key to the SSH Keys section of our GitHub account settings. Save the Private key locally then use this in the “Load SSH Key” part when importing the repository.

Now click the clone button to pull all the code down from GitHub and complete the local cloning of the repository.

Download Symfony2 dependancies with Composer

As part of our stack, the webserver running Zend Server has the basic Symfony2 framework installed. However, this is not much use, without all of the dependencies which make it fully functional.

If Symfony2 is not installed, go and follow the instructions on their download page. Download without vendors, so that we can have more fine grained control here with our dependancy management later on.

Log into the webserver via SSH:

As you can see we then need to run a Composer update in order to bring everything up to date:

Now we’re ready to start using (learning) Symfony2.

n00b-alert-2: Provisioning the Development Servers with Chef Solo

Following my previous post about setting up the ability to spawn multiple *nix (Ubuntu) development VMs with Cygwin, VirtualBox and Vagrant, this tutorial is for Chef Solo, to provision the VMs with their databases, servers and programming environments we need. Although this is essentially a duplicate post of Dan’s, I find it best to put everything down myself, to help re-inforce the steps.

Setting up the Chef library

According to Dan, Chef will try to load all the cookbooks, regardless of whether it uses them or not. Therefore to keep things lean, it is best to only use the relevant cookbooks at a project level. To facilitate this, I will create a Chef library which I can then copy and paste the relevant cookbooks from into each project.

Now, there isn’t much in here, so I am going to set up my first project and use this to configure Chef Solo. Thereafter, I will copy these files across into the Chef Library, so that when I create further projects, I can take the Chef files I want from the library.

Creating the first Chef project

The Vagrantfile has now been made and we are ready to copy over the Chef files that we need from the Library. Although these files are currently empty, we will propogate them and then copy them back into the Library. When making future instances, we only need to copy them across from the Library to the Project and off we go. By copying across the files, we preserve the directory structure, to avoid us getting lost.

At this point is is probably best to import the project folder into your IDE, in my case Aptana. I can then edit the config files from the comfort of the IDE and not the command line.

Configuring Vagrant

Configuring Chef

Firstly the recipe we will be using. In this case, we are using it to install Zend Server.

Next we need to configure the Role that our server will be using, in this case we are calling it WebServer. Although the name is generic, we can here specify which webserver we wish to set up, currently Zend Server, which installs with Apache2. Should we wish to completely change the web server completely, we only need to add a new recipe for the new server and then change the configuration of the Role.

Now everything is configured for a basic PHP webserver using Zend Server.

Booting the VM

Cd to the directory with the Vagrant file

We hit a problem

Oh dear, something went wrong. Upon investigation it is the nightmare to understand first two execute codes in the recipe. We need to use not_if instead of only_if:

The logic is as follows:

If zend cannot be found in list of apt-keys (i.e. grep returns 0) then run the command in the line above to wget and add the key. Grep returns nothing, i.e. 0 / false and the not_if only runs if it evaluates to false / true, whereas the only_if runs on true. Our error was saying if the Zend Key can be found, try to download it – this is obviously the opposite of what we want.

Ditto for the source of Zend server, but this is by grepping the apt sources list.

The confusion was the double negatives, but all now makes sense.

Re-provisioning the VM

As the VM is already running, we do not need to restart it, instead we can re-provision it, following the changes to our recipe.

If this gives you any trouble, then you may need to destroy the VM completely and then boot it again:

Now we can log in via SSH via the port 2222 forwarded to localhost.

Default username and password is vagrant.

To test the webserver, open http://10.0.0.2/ or if port forwarding is set up http://127.0.0.1:port (in our case 8081).

Configuring Apache2

Now edit the recipe to include:

finally to get it to work:

Now via my IDE, I can change my index.htm under the app folder, and it will change when I refresh the website http://10.0.0.2/ we can see the changes.

Filling the library

Finally, we can copy back the Recipes and Roles into the Chef Library we made earlier. If we wish to expand on these recipes, without affecting other instances, we can then take copies of these when we make new projects. Alternatively if we wish to just use them straight out of the box, we can symlink to these directories from the new projects. By symlinking we can easily re-provision multiple instances without the need to edit each of the recipes.

n00b-alert-1: Running Multiple Development Environments on Windows with Cygwin, VirtualBox and Vagrant

Technology seems to be moving so quickly; far too quickly for me to follow. Thanks to Dan, I’ve been able to ignore the evaluation of new shiny things, as he is keen to do this, whereas I am not. Occasionally he shows me something which raises my interest, even gets me excited. In this instance, it is the latter. Over the last few months Dan has tried and tested many different things, to see what suits our requirements best and we’ve now settled upon a number of things, which I will have to learn on my own following his departure in a week’s time. Therefore this last week is my crash course.

What we’re doing

I have in fact done this twice at home already, but a couple of weeks later trying to do it from my work PC is like starting from scratch. Therefore, Dan has invited me to his blog, to write some tutorials of my own, essentially for my own future consumption. This first one is about setting up multiple Virtual Machine instances for development purposes on my local PC.

What we need

Why Cygwin?

This could all be done via Windows, using CMD where necessary. However, as our server environments are *nix and as it’s what I am most familiar with from the command line, it is best to do this via Cygwin, to practice commands regardless of whether I am running these as Dev VMs or later down the line when rolling out to production.

Installation

  • Install Cygwin
    • I included the following options (use the search, rather than scrolling through the list):
      • nano
      • All SSL libraries – not sure which I need, but they don’t take up much disk space, so I included them all. Obviously I’ll be a little more conscious of what I am installing on the production box
      • All SSH libraries – ditto
    • I then set these alias in my ~/.bashrc file:
      • pico=nano – to use pico even though not installed
      • vagrant=vagrant.bat – to avoid typing the .bat which is necessary on Win but not *nix

      Then to refresh the profile run:

  • Install Oracle VirtualBox with default settings
  • Install Vagrant with default settings

Config

From here on we are in the Cygwin shell. I will run all the project folders from my D Drive, so I am making a folder there to store all my user project files. Then initialise Vagrant.

Testing the installation

Run through the Vagrant tutorial from this page, in order to re-familiarise myself with the Vagrant basics as well as testing that everything works correctly.

SSH from Cygwin

When trying to SSH into the new VM, as we are on Windows, we can either:

  1. Use PuTTY, by generating a PPK with PuttyGen
  2. Use the Cygwin shell SSH
    • Firstly chmod the insecure_private_key file to 700 – otherwise it will not import
       

      Thus mine is

    • SSH into the shell

      As you can see we’re in:

Upon success

That’s it for the moment. The next tutorial will be to learn provisioning the development instances with Chef Solo – Chef Server will be later down the line for the production servers.

A great end to the month

Holding the stockade!I went to Apocolypse for some airsoft this weekend and had probably one of the best ending battles I’ve had whilst playing the game, Which is odd for this site.

Normally they have really good morning games and dire afternoon games but at this event it completely switched. The morning game was poor, we (playing Chechen terrorists) had to get out with our hostages, but limited to having one hostage leaving our HQ every 15 minutes which made it very easy for the opposing teams to keep us at bay. the real problem with this game was that the hostages were paying players that mostly did nothing for half the day.

After some lunch things became interesting, we now had to get a dirty bomb into the stockade, which we managed and set us up for the final game, holding the stockade till either the bomb went off or the one person assigned with disarming it does so.

This final game was long, we were mostly surrounded (only behind us was clear) and cover was limited. Several times the other team tried to get behind us to clear the area but we mostly held them off and the few that did make it were not carrying automatics, so the areas were easy to recover.

I was moving between areas (wherever there was action) and even got a few fancy slides in without falling over, one of them putting me in the right place to take out a sniper only to be hit by friendly fire after the kill.

It was an intense battle and definitely made up for the poor morning game.