bebox 0.0.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: b2686461b25f6cddf91684fc202769d79fc89863
+  data.tar.gz: fac186b3c4af1096e307c23fa5c26a2752763d22
+SHA512:
+  metadata.gz: afbfa11267c24b44bd88cdbc14a5d83f9c36e8db23d72a9109ea483a0442a39829a1f5b0b7f92cdb270c2ce9719a50a2ad1c66e7344e1a61774fd4c2e19c13e3
+  data.tar.gz: 73eb634c5c82c13a392d2c5d45cbc6615204eb6aca6feaa6710849ce5c9cf22947d17991d34cac8602946101069dea94998f831d1c9f0644d55ad54c7853cba4

data/.gitignore

@@ -0,0 +1,78 @@
+# Compiled source #
+###################
+*.com
+*.class
+*.dll
+*.exe
+*.o
+*.so
+
+# Packages #
+############
+# it's better to unpack these files and commit the raw source
+# git has its own built in compression methods
+*.7z
+*.dmg
+*.gz
+*.iso
+*.jar
+*.rar
+*.tar
+*.zip
+*.box
+# OS generated files #
+######################
+.DS_Store
+.DS_Store?
+._*
+.Spotlight-V100
+.Trashes
+Icon?
+ehthumbs.db
+Thumbs.db
+
+#Rails specific stuff
+.DS_Store
+config/database.yml
+*.log
+tmp/
+*.sql
+*.sqlite
+*.sqlite3
+.rvmrc
+public/system
+public/spree
+/public/system*
+.idea/
+public/uploads
+.sass-cache/
+.bundle/
+.jhw-cache/
+boxes/
+
+## UNIX TEMP FILES
+*~
+
+# Vagrant
+.vagrant
+Vagrantfile
+boxes_recreate.sh
+
+# Hiera Development Environment
+puppet/hiera/data/server1.development.test.yaml
+puppet/hiera/data/server2.development.test.yaml
+puppet/hiera/data/server3.development.test.yaml
+puppet/hiera/data/vagrant.yaml
+puppet/hiera/data/development.yaml
+puppet/hiera/data/new_production.yaml
+
+# Gem generation
+pkg/
+
+# Spec tests
+spec/support/config_specs.yaml
+
+# Local
+TODO
+.project
+.timetracker-project

data/Gemfile

@@ -0,0 +1,3 @@
+source 'https://rubygems.org'
+
+gemspec

data/Gemfile.lock

@@ -0,0 +1,163 @@
+PATH
+  remote: .
+  specs:
+    bebox (0.0.1)
+      active_attr (= 0.8.3)
+      colorize (= 0.6.0)
+      gli (= 2.10.0)
+      highline (= 1.6.21)
+      progressbar (= 0.21.0)
+      tilt (= 2.0.1)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    actionpack (4.1.0)
+      actionview (= 4.1.0)
+      activesupport (= 4.1.0)
+      rack (~> 1.5.2)
+      rack-test (~> 0.6.2)
+    actionview (4.1.0)
+      activesupport (= 4.1.0)
+      builder (~> 3.1)
+      erubis (~> 2.7.0)
+    active_attr (0.8.3)
+      activemodel (>= 3.0.2, < 4.2)
+      activesupport (>= 3.0.2, < 4.2)
+    activemodel (4.1.0)
+      activesupport (= 4.1.0)
+      builder (~> 3.1)
+    activesupport (4.1.0)
+      i18n (~> 0.6, >= 0.6.9)
+      json (~> 1.7, >= 1.7.7)
+      minitest (~> 5.1)
+      thread_safe (~> 0.1)
+      tzinfo (~> 1.1)
+    aruba (0.5.4)
+      childprocess (>= 0.3.6)
+      cucumber (>= 1.1.1)
+      rspec-expectations (>= 2.7.0)
+    awesome_print (1.2.0)
+    binding_of_caller (0.7.2)
+      debug_inspector (>= 0.0.1)
+    builder (3.2.2)
+    childprocess (0.5.3)
+      ffi (~> 1.0, >= 1.0.11)
+    coderay (1.1.0)
+    colorize (0.6.0)
+    columnize (0.8.9)
+    coolline (0.4.3)
+    cucumber (1.3.14)
+      builder (>= 2.1.2)
+      diff-lcs (>= 1.1.3)
+      gherkin (~> 2.12)
+      multi_json (>= 1.7.5, < 2.0)
+      multi_test (>= 0.1.1)
+    debug_inspector (0.0.2)
+    debugger (1.6.6)
+      columnize (>= 0.3.1)
+      debugger-linecache (~> 1.2.0)
+      debugger-ruby_core_source (~> 1.3.2)
+    debugger-linecache (1.2.0)
+    debugger-ruby_core_source (1.3.2)
+    diff-lcs (1.2.5)
+    diffy (3.0.4)
+    erubis (2.7.0)
+    factory_girl (4.3.0)
+      activesupport (>= 3.0.0)
+    ffi (1.9.3)
+    gherkin (2.12.2)
+      multi_json (~> 1.3)
+    gli (2.10.0)
+    grit (2.5.0)
+      diff-lcs (~> 1.1)
+      mime-types (~> 1.15)
+      posix-spawn (~> 0.3.6)
+    highline (1.6.21)
+    hirb (0.7.1)
+    i18n (0.6.9)
+    jazz_hands (0.5.2)
+      awesome_print (~> 1.2)
+      coolline (>= 0.4.2)
+      hirb (~> 0.7.1)
+      pry (~> 0.9.12)
+      pry-debugger (~> 0.2.2)
+      pry-doc (~> 0.4.6)
+      pry-git (~> 0.2.3)
+      pry-rails (~> 0.3.2)
+      pry-remote (>= 0.1.7)
+      pry-stack_explorer (~> 0.4.9)
+      railties (>= 3.0, < 5.0)
+    json (1.8.1)
+    method_source (0.8.2)
+    mime-types (1.25.1)
+    minitest (5.3.3)
+    multi_json (1.9.2)
+    multi_test (0.1.1)
+    net-ssh (2.9.1)
+    posix-spawn (0.3.8)
+    progressbar (0.21.0)
+    pry (0.9.12.6)
+      coderay (~> 1.0)
+      method_source (~> 0.8)
+      slop (~> 3.4)
+    pry-debugger (0.2.2)
+      debugger (~> 1.3)
+      pry (~> 0.9.10)
+    pry-doc (0.4.6)
+      pry (>= 0.9)
+      yard (>= 0.8)
+    pry-git (0.2.3)
+      diffy
+      grit
+      pry (>= 0.9.8)
+    pry-rails (0.3.2)
+      pry (>= 0.9.10)
+    pry-remote (0.1.8)
+      pry (~> 0.9)
+      slop (~> 3.0)
+    pry-stack_explorer (0.4.9.1)
+      binding_of_caller (>= 0.7)
+      pry (>= 0.9.11)
+    rack (1.5.2)
+    rack-test (0.6.2)
+      rack (>= 1.0)
+    railties (4.1.0)
+      actionpack (= 4.1.0)
+      activesupport (= 4.1.0)
+      rake (>= 0.8.7)
+      thor (>= 0.18.1, < 2.0)
+    rake (10.3.1)
+    rspec (2.14.1)
+      rspec-core (~> 2.14.0)
+      rspec-expectations (~> 2.14.0)
+      rspec-mocks (~> 2.14.0)
+    rspec-core (2.14.8)
+    rspec-expectations (2.14.5)
+      diff-lcs (>= 1.1.3, < 2.0)
+    rspec-mocks (2.14.6)
+    serverspec (1.6.0)
+      highline
+      net-ssh
+      rspec (~> 2.13)
+      specinfra (~> 1.11)
+    slop (3.5.0)
+    specinfra (1.12.0)
+    thor (0.19.1)
+    thread_safe (0.3.3)
+    tilt (2.0.1)
+    tzinfo (1.1.0)
+      thread_safe (~> 0.1)
+    yard (0.8.7.4)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  aruba (= 0.5.4)
+  bebox!
+  factory_girl (= 4.3.0)
+  jazz_hands (= 0.5.2)
+  rake (= 10.3.1)
+  rspec (= 2.14.1)
+  serverspec (= 1.6.0)

data/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) <year> <copyright holders>
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -0,0 +1,372 @@
+
+Bebox
+=====
+
+Introduction
+------------
+
+Bebox is designed to meet provisioning goals for small to medium environments (maybe even big ones) while using [Puppet (opensource)](http://puppetlabs.com/puppet/puppet-open-source), and without the need for a Puppet Master. This project is intended for teams that tipically use two repositories for each project: the "app" repo and the "provisioning" repo. This project centers its efforts in trying to organize how these "provisioning" repos are constructed.
+
+Bebox was originally born from the necessity of automating the provisioning of environments in which [Rails](https://github.com/rails/rails) web applications could run, with the least amount of steps, and be able to reproduce the production setup every time. Please note that, even while this is the genesis for Bebox, it does not imply that it is specifically tailored for provisiong web applications, and we think it can ultimately be used pretty much in any scenario where Puppet is used without overwhealming complexity.
+
+Bebox's main concern is __organization__. It is generally a good idea to have conventions about how different source code files are placed and named and be able to use this to reduce the details required to understand a project while also providing automation in key places. These conventions may include things like from how to write modules, integrate them into the projects, a directory structure for the projects to follow, how to have a replicated “development/test” environment into virtual machines, etc.
+
+NOTE: For the moment, Bebox assumes that the remote machines' OS is Debian based.
+
+Bebox development is based on awesome tools on their own, and essentially based on the following:
+
+* Written in Ruby and distributed as a gem
+* It has a very nice CLI based on a commandline tool framework called [GLI](https://github.com/davetron5000/gli)
+* Uses [Puppet (opensource)](http://puppetlabs.com/puppet/puppet-open-source) for provisioning machines, and its the main component that the Bebox workflow aims to organize.
+* Uses [vagrant](http://www.vagrantup.com/) for setting up a similar development/test environment in accordance to the remote machines real setup.
+* Uses [Capistrano](http://capistranorb.com/) for automating the tasks to be executed on remote/vagrant machines.
+
+Workflow
+--------
+
+Bebox’s workflow is comprised of the five (5) phases explained below:
+
+###Project creation phase
+
+In this phase, the project skeleton is created, just like when a rails app is created. Keep in mind we are generating a "provisioning" repo skeleton and much of the logic behind bebox is put directly into the generated code so it can be tuned.
+
+###Environment definition phase
+
+Any number of environments are defined. By default, the 'vagrant', 'staging', and 'production' environments are present. You an create any number of environments you need. The 'vagrant' environment is special as it is designed to run in virtual machines hosted in the local machine.
+
+###Node allocation phase
+
+For each environment, there can be any number of nodes. The nodes for every environment are configured. A node represents a machine or server, a node's critical attributes are only it's hostname and ip address.
+
+###Prepare phase
+
+In this phase, all nodes are equipped with a set of base packages and tools via Capistrano which sole purpose is to help install Puppet. Also, very importantly, each node gets a Puppet opensource standalone installation. In order for Capistrano to be able to connect and install this in each node, a set of keys must already be present as authorized_keys in the remote servers, Bebox reminds of this step, and will possibly help do this semi-automatically in the future (requires user input because of boostraping from a root password). You will notice that Puppet installer files are bundled with Bebox, to use a fixed Puppet opensource version. This was necessary to ensure a particular Puppet version to avoid breaking things.
+
+###Provisioning phase
+
+Once Puppet is installed, we can use it to provision anything we want. The provisioning phase is the last phase of the project and consists (currently) of four steps. This steps has a clear separation of concerns which we have chosen based on practical experience, however this is the default and you can add or remove any number of steps, but we recommend at least to stick with the first two.
+
+Steps were created to run sequential puppet runs and apply multiple manifests in order. Although this may seem strange, Puppet's non-deterministic manner is something that is not suitable every time and having only one manifest to pack everything into can create some trouble with dependant modules.
+
+Also, the idea of steps helps in visualizing/imagining layers of configuration.
+
+Coming back to the steps, the four default steps that have been put into Bebox's projects by default are:
+
+####Fundamental step (0-fundamental)
+This step only provides a 'puppet' user, which the following steps use to install everything else (instead of using root). This is done to have all environments as similar as possible. In the 'vagrant' environment, the main user is 'vagrant', but this could also be 'root' or something else, so this ensures that a single user (other than root) for making changes via Puppet is created.
+
+####The user layer step (1-users)
+Based on practical experience, this next step should be the one responsible for setting system users, so that they exist prior to any service level provisioning.
+
+####The service layer step (2-services)
+This step is what you would have in your regular puppet provisioning repo (except for the users of course). We follow the roles and profiles scheme (links to read about [here](http://www.craigdunn.org/2012/05/239/) and [here](http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/)) and install the majority of the functional services, web, database, etc.
+
+####The security layer step (3-security)
+This step configure some packages to provide a minimal security in the system (fail2ban, ssh access, iptables).
+
+
+NOTE: Probably many people would think this is not advisable, so there is always the possibility of having only one step, one run, one manifest for Puppet to run in this phase.
+
+How to Use
+----------
+###Installation
+
+Pre-requisites
+
+* rbenv
+* ruby version >= 1.9.2 (ruby 2.1.0 recommended)
+* vagrant (tested using vagrant 1.6.3)
+
+####Build bebox gem
+This commands clone the project and generate the bebox gem file:
+```
+git clone https://github.com/jairodiaz/bebox
+cd bebox
+gem build bebox.gemspec
+```
+This creates a *bebox-0.0.1.gem* file.
+
+
+####Install bebox:
+
+In the directory where you want to install bebox do:
+
+    gem install BEBOX_GEM_PATH
+
+Where BEBOX_GEM_PATH is the route to the *bebox-0.0.1.gem* file created previously.
+
+###Bebox project creation (Project creation phase).
+
+To create a new bebox project do:
+
+    bebox new PROJECT_NAME
+
+In console appears a simple wizard to configure a vagrant box for the project. The vagrant box can be downloaded automatically with the wizard or linked with an existent local *.box file.
+
+This creates a subdirectory named *bebox-[PROJECT_NAME]* with the initial skeleton of application. To access new bebox commands (much like Rails does) cd into the newly created bebox project:
+
+    cd bebox-[PROJECT_NAME]
+
+###Manage Environments (Environment definition phase).
+Then you can add/remove/list environments. By default: the production, staging and vagrant environments are already created.
+
+To add an environment:
+
+    bebox environment new ENVIRONMENT
+
+To remove an environment:
+
+    bebox environment remove ENVIRONMENT
+
+To list environments:
+
+    bebox environment list
+
+###Manage Nodes (Node allocation phase).
+If you have at least one environment you can add/remove/list nodes.
+
+To add a node:
+
+    bebox node new
+
+Then in the console a simple wizard appear asking the node parameters.
+
+To remove a node:
+
+    bebox node remove
+
+Then in the console a simple wizard appear for selecting the node to remove from the available nodes.
+
+To list nodes:
+
+    bebox node list [--environment ENVIRONMENT] [--all]
+
+Without options it list nodes for the default *ENVIRONMENT* that is **vagrant**. If you provide the *ENVIRONMENT* flag it list nodes for that environment or if the *--all* switch is set list all nodes for all environments.
+
+
+###Prepare Nodes (Prepare phase).
+If you have nodes configured then you can prepare them.
+
+To prepare them:
+
+    bebox prepare [--environment ENVIRONMENT]
+
+It will prepare all nodes that are not prepared. If you have nodes already prepared (For example you add a new node after prepare previous nodes), a wizard appear to ask if you want to re-prepare them. It will not prepare nodes that you don't want to re-prepare.
+
+By default if an *ENVIRONMENT* is not specified the default will be **vagrant**.
+
+Also if the nodes are in the vagrant environment you can up/halt the vagrant machines:
+
+**Take in account that this phase would take some time while it download and configure the base packages in all the nodes to be prepared.**
+
+For vagrant nodes already prepared you can stop/start the vagrant machines with:
+
+    bebox vagrant_halt
+
+    bebox vagrant_up
+
+###Puppet (Provisioning phase)
+
+If you have nodes prepared you can provision them step-by-step. All steps can be applied without restrictions. If you want to configure the provisioning we encourage to use the roles and profiles pattern thath we implement through a special set of commands (See parts below).
+
+At project creation a set of default roles, profiles and hiera data are configured for the nodes in the steps (0, 1 and 3), but you could re-configuring in any moment. The step-2 need to be configured completely.
+
+
+To provision the nodes:
+
+    bebox apply [STEP] [--environment ENVIRONMENT] [--all]
+
+
+The STEP option must be one of: *step-0*, *step-1*, *step-2*, *step-3*
+By default if an *ENVIRONMENT* is not specified the default will be **vagrant**.
+The *--all* switch allows to run all steps in order without specify the STEP option.
+
+**We recommend to configure the roles, profiles and hiera data previously to apply any step.**
+
+####Manage roles
+
+To add a role:
+
+    bebox role new ROLE
+
+To remove a role:
+
+    bebox role remove ROLE
+
+
+Then in the console a simple wizard appear for selecting the role to remove from the available roles.
+
+To list roles:
+
+    bebox role list
+
+**We recommend to use our default roles (fundamental, users, security) for steps (0, 1, 3), but you can edit or delete them under your own risk**
+
+####Manage profiles
+
+To add a profile:
+
+    bebox profile new PROFILE [-p PATH]
+
+This command creates a file structure for the profile with templates that you need to edit for the profile do something.
+The structure is like:
+
+    ── profiles/
+        └── <category1>/
+            └── <category2>/
+                ...
+                └── <categoryN>/
+                    └── <profile-name>/
+                        ├── manifests/
+                        │   └── init.pp
+                        └── Puppetfile
+
+The *categories (category1, category2, ... categoryN)* are set if the argument *-p PATH* is passed; and are useful better organization of profiles.
+
+For example:
+```
+bebox profile new iptables -p basic/security
+```
+would create the profiles directories structure:
+```
+    ── profiles/
+        └── basic/
+            └── security/
+                └── iptables/
+                    ├── manifests/
+                    │   └── init.pp
+                    └── Puppetfile
+
+You need to modify the init.pp file adding usual puppet calls to classes, resources, modules, hiera.
+You need to modify the Puppetfile to set the modules that the manifest file will use.
+Also you need to modify the hiera data that the manifest will use (See Hiera part below).
+
+To remove a profile:
+
+
+    bebox profile remove
+
+
+Then in the console a simple wizard appear for selecting the profile to remove from the available profiles.
+
+To list profiles:
+
+
+    bebox profile list
+
+**We recommend to use our default profiles (fundamental, users, security) for steps (0, 1, 3), but you can edit or delete them under your own risk**
+
+**Important: Remember that you need to write/edit the puppet code for the profiles to work (specially step-2 that has no defaults); also you have to write/edit the Puppetfile template created to add modules that your profile use; additionally if you call hiera data from a profile you need to add them in the hiera/data/<data>.yaml file in the structure created (see Hiera part below)**
+
+
+####Associate roles and profiles
+
+This add/remove a profile to a role.
+
+To add a profile to a role:
+
+    bebox role add_profile
+
+Then in the console a simple wizard appear for selecting the role and profile to add.
+
+To remove a profile from a role:
+
+    bebox role remove_profile
+
+Then in the console a simple wizard appear for selecting the role and profile to remove.
+
+To list profiles configured in a role:
+
+    bebox role list_profiles ROLE
+
+####Associate nodes and roles
+
+This change the role associated with a specific node.
+
+To set the role for a specific node:
+
+
+    bebox node set_role [--environment ENVIRONMENT]
+
+Then in the console a simple wizard appear for selecting the node and role to set.
+By default if an *ENVIRONMENT* is not specified the default will be **vagrant**.
+
+
+###Hiera
+
+If you use hiera data from your profiles, you can add them to the appropiate file in the file structure shown below:
+
+    ── puppet/
+        └── steps/
+           ├── 0-fundamental/
+           ├── 1-users/
+           ├── 2-services/
+           ├── 3-security/
+               ├── hiera/
+               │   └── data/
+               │   │   └── [node].yaml
+               │   │   └── [environment].yaml
+               │   │   └── common.yaml
+               │   └── hiera.yaml
+               ├── manifests/
+               │   └── site.pp
+               ├── modules/
+               └── Puppetfile (Automatically generated by Bebox in every 'apply')
+
+Each of he <number>-<step-name> corresponds provisioning steps phase. For example **0-fundamental** correspond to **step-0** option.
+
+To add hiera data you need to edit any of the **[node].yaml**, **[environment].yaml**, **common.yaml**.
+[node]: correspond to the hiera file for the node hostname (Ex. node0.server1.com.yaml).
+[environment]: correspond to the hiera file for the node hostname (Ex. vagrant.yaml, production.yaml).
+
+
+Development
+-----------
+
+To use the project in development mode, you need to do this:
+
+* Clone bebox from the repository.
+
+    git clone ssh://git@codescrum.repositoryhosting.com/codescrum/bebox.git
+
+* Run bundle to install
+
+    bundle install
+
+* Generate the gem package
+
+    rake package
+
+* Make a tmp directory inside bebox folder
+
+    mkdir tmp
+    cd tmp
+
+* Execute the project creation command preceded by **bundle exec**
+
+    bundle exec bebox new PROJECT
+
+* Enter to the project created
+
+    cd PROJECT
+
+* Add to the **Gemfile** the line
+
+    gem 'bebox', :path => "BEBOX_PATH_IN_YOUR_PC/pkg"
+
+* Execute any project commands preceded by **bundle exec**
+
+    bundle exec bebox environment
+
+Tests
+-----
+
+Before running any tests you need to configure the IP address for the vagrant machine. To do this create the file *spec/support/config_specs.yaml* from the *spec/support/config_specs.yaml.example* and configure a local newtwork IP free address to use.
+
+By project's nature the specs must be run in order. To do this all specs has a 'Test XX:' naming convention. If you want to run all tests in order we have a ordered_phases_spec.rb file than you can run with.
+
+    rspec spec/ordered_phases_spec.rb
+
+Maybe it would take a large time because it creates a vagrant machine and do a basic provision downloading packages and installing them in the machine.
+
+**Important: You need to have the [ubuntu-server-12042-x64-vbox4210-nocm.box](http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-server-12042-x64-vbox4210-nocm.box) in the bebox root folder to run the tests**

data/Rakefile

@@ -0,0 +1,8 @@
+require 'rake/clean'
+require 'rubygems'
+require 'rubygems/package_task'
+
+spec = eval(File.read('bebox.gemspec'))
+
+Gem::PackageTask.new(spec) do |pkg|
+end

data/bebox.gemspec

@@ -0,0 +1,40 @@
+# Ensure we require the local version and not one we might have installed already
+require File.join([File.dirname(__FILE__),'lib','bebox','version.rb'])
+spec = Gem::Specification.new do |s|
+  s.name = 'bebox'
+  s.version = Bebox::VERSION
+  s.author = 'Codescrum'
+  s.email = 'team@codescrum.com'
+  s.homepage = 'http://www.codescrum.com'
+  s.licenses    = ['MIT']
+  s.platform = Gem::Platform::RUBY
+  s.summary = 'Create basic provisioning of remote servers.'
+  s.description = <<-EOF
+    Bebox is a project born from the necessity of organizing a way to deal with the provisioning of remote servers.
+    Bebox is based on puppet and much like another quite known project Boxen,
+    the idea is to have a good agreement on how to manage a puppet repo for a remote environment.
+    It is also a good idea to have a standard approach on dealing with the provisioning problem,
+    including how to write modules, integrate them into the projects,
+    a directory structure for the projects to follow,
+    how to have a replicated 'development/test' environment into virtual machines, etc.
+  EOF
+  s.files = `git ls-files`.split("\n") - ['.ruby-version']
+  s.require_paths << 'lib'
+  s.has_rdoc = false
+  s.rdoc_options << '--title' << 'bebox' << '--main' << 'README.rdoc' << '-ri'
+  s.bindir = 'bin'
+  s.executables << 'bebox'
+  s.required_ruby_version = '>= 1.9.2'
+  s.add_development_dependency('rake', '10.3.1')
+  s.add_development_dependency('aruba', '0.5.4')
+  s.add_development_dependency('rspec', '2.14.1')
+  s.add_development_dependency('jazz_hands', '0.5.2')
+  s.add_development_dependency('serverspec', '1.6.0')
+  s.add_development_dependency('factory_girl', '4.3.0')
+  s.add_runtime_dependency('gli','2.10.0')
+  s.add_runtime_dependency('active_attr', '0.8.3')
+  s.add_runtime_dependency('tilt', '2.0.1')
+  s.add_runtime_dependency('highline', '1.6.21')
+  s.add_runtime_dependency('progressbar', '0.21.0')
+  s.add_runtime_dependency('colorize', '0.6.0')
+end