It's been a busy few months at Gazzang working on the next release of our big data encryption solution, Gazzang zNcrypt. Check out the press release that went out this morning announcing general availability. Much like zNcrypt 2.0 for LAMP, which launched our products into applications beyond database encryption, we anticipate that zNcrypt 3.0 will bring zNcrypt into more complex and larger multi-hundred-node big data environments.

The solution was built with large scale deployments in mind and offers more options for securing Big Data. zNcrypt has already shown fantastic results on Big Data platforms like Hadoop, Cassandra and MongoDB, but as with any software there is always room for improvement. Feedback from customers, partners and engineers were key toward enhancing the features and capabilities in this latest release.

A few of the new features you will find in zNcrypt 3 are:

• zTrustee-based key server, with additional security layers and smart policies to protect the encryption keys. zTrustee has APIs in shell, Python. C and Java allowing users to have more programmatic control of the keys for tighter integration into their security processes.
• Added block level encryption for better performance and the capability to take advantage of Intel AES-NI hardware encryption acceleration when available in the hardware. During configuration, zNcrypt users can now choose between file level or block level encryption.
• Multiple master key and encryption mount points per server. This capability adds flexibility to define different key policies for different user groups for data segregation as well as better scalability by allowing to add encrypted storage volumes without downtime or moving encrypted data to larger volumes.
• Automated license activation, it is no longer required to have a license key and activation up front. We have moved from the traditional product key way of software licenses to a more innovating and scalable automated license activation. You can use your DevOps tools of choice to install zNcrypt using standard apt / yum package managers without contacting Gazzang.

If you already are a Gazzang zNcrypt customer and are interested in upgrading, please contact support@gazzang.com. If you are new to zNcrypt, we invite you to try it now by contacting sales@gazzang.com. It has never been easier for anyone to trial zNcrypt.

Over the past few years I have seen an avalanche of servers and applications migrating to Amazon EC2. One of the cornerstones of Gazzang is the fundamental premise that the cloud is only as secure as you make it. With so many companies starting to take advantage of Big Data to run analytics jobs, have better data points from large data sets and make informed or even automated decisions based on data fluctuations, these systems are now also following their peers to the cloud.

Building a large dedicated multi-hundred node Big Data platform in the cloud is an expensive proposition, so it was logical that Amazon would build a Big Data as Service solution. Many Big Data jobs have demand peaks and valleys, and this elastic nature of resource utilization is a perfect candidate for "elastification" by Amazon. Elastic Map Reduce (EMR) provides users a very simple interface either via a graphical UI or api calls to launch large complex Hadoop Clusters for big data analytics.

Amazon offers many security features like Virtual Private Clouds (VPCs), AWS Identity and Access Management (IAM), secret keys, api keys, VPN connectivity, security groups, NAT, Internet Gateways, SSL load balancers, AWS Java SDK and security classes. Unfortunately there is no one size fits all in terms in security. Data encryption might be vital for one organization, while another might view SSL certificate management as their security lynchpin, so when it comes to securing your Amazon servers, users need to tailor security to fit their needs.

To address the growing security needs of EMR users, Gazzang is planning to offer a unique Elastic Map Reduce Solution Pack. This solution package will bundle our existing products along with new scripts and java classes that allow users to secure their EMR jobs.

The Gazzang EMR solution pack includes:

• Gazzang zNcrypt to transparently encrypt data on the Hadoop Data nodes, so it is never stored on disk in cleartext
• Gazzang zTrustee to store the master encryption keys to encrypt/decrypt the data as moved to and from S3 and EMR and ultimately consumed in a reporting engine or transactional database
• Customized Hadoop Java classes to perform the secure key retrieval and streamed data encryption/decryption
• Amazon EMR bootstrap scripts to install and configure the zNcrypt software

The EMR solution pack is a great step towards securing your EMR jobs, complying with data at rest encryption requirements for HIPAA-HITECH, PCI-DSS and many other regulations. The solution pack can then be further extended with the many APIs in shell, python, java and C to further meet custom requirements suited for our customers.

For more information on this solution pack, please contact sales@gazzang.com

One of the very nice features of zNcrypt 2.4 is something called profiles. Profiles are a simple way of extending the security of the Access Control Lists (or ACLs) that zNcrypt already has.

Let's suppose for example that you wanted to encrypt something, but the program you wanted to be able to access that data uses Java. You can't very well allow plain Java to have full access to your data, because that would mean every program that uses the Java Virtual Machine (or JVM) would automatically have access to your data. The trick until now was to create a secure java binary and protect access to it, but profiles allow you to be much more specific in terms of what the allowed command must look like.

So what is a Gazzang zNcrypt profile and how are they created? One dictionary definition of profile is "an analysis representing the extent to which something exhibits various characteristics" (from http://nces.ed.gov/pubs2009/metadata/ch3_profiling.asp). In our case, it's the list of characteristics of a process that defines it in detail, We will dive into those characteristics in a bit. But first lets look at how we capture a process' characteristics.

First of all, the command to create a profile is:

    ezncrypt-profile -p <pid> 

This means you need the process id in order to profile something. Suppose that the data you are protecting is Cassandra (which depends on Java) and that you had encrypted /var/lib/cassandra using the category @cassandra. If you look for the primary process accessing Cassandra, you'll see something like this:

    115       2889 21.6 81.2 1400140 827944 ?      SLl  13:37   0:06
jsvc.exec -user cassandra -home
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/../ -pidfile
    /var/run/cassandra.pid -errfile &1 -outfile
/var/log/cassandra/output.log -cp
/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-

    <24 lines clipped>

    -Dcom.sun.management.jmxremote.port=7199
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
     org.apache.cassandra.thrift.CassandraDaemon

This might seem scary, but in reality it allows us to create a very specific profile that allows Java to access our encrypted data, but only when the characteristics of the Java program look as defined. First we create the profile:

    ezncrypt -p 2889 > 2889.profile

Then you create the ACL like this:

    ezncrypt-access-control -a “ALLOW @cassandra * /usr/bin/jsvc”
--profile=2889.profile

It's that simple.

So, what does a profile look like and what is its format?
Structurally the file is simply a JSON formatted file with a handful of lines in it:

    $ cat 2889.profile
    {
    "uid":"115",
    "comm":"jsvc",
    "cmdline":"jsvc.exec -user cassandra -home
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/../ -pidfile
    /var/run/cassandra.pid -errfile &1 -outfile
/var/log/cassandra/output.log -cp
/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-

    <24 lines clipped>

    -Dcom.sun.management.jmxremote.port=7199
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
org.apache.cassandra.thrift.CassandraDaemon"
    }

The first line means that only the user with UID 115 (in this case user cassandra) can be running the process. The second one means the accessing agent has to be named jsvc. The third line requires the command line to be exactly what is shown after cmdline (which in this case is 29 lines of command line parameters. If even one of those things isn't true, access will be denied.

If that doesn't give you enough granularity, the profile command also has the ability to include the group id (-g), the current working directory (-c), and the open file descriptors (-f, each of which shows up as a separate key-value pair). This should give almost anyone the tools to be able to really lock down scripts/programs that access your data under Java (or perl) without the need for keeping a separate copy of the binary.

Or if it's too fine grained, you can remove key-value pairs from the profile. For example you might remove the user id line when you add the group id or remove one of the file descriptor lines that isn't material to you.

Oh, and one more thing. After you add the ACL, the file you pulled the profile from becomes irrelevant. You can alter it, delete it, etc. and the ACL isn't affected. It was read in at the time, but once the ACL is created, the file is no longer looked at (so it doesn't become a liability). Of course, the best practice would be to delete it.

All the previous blogs in this Chef cookbook series have been leading up to using zNcrypt to encrypt BigData. In this blog we will see how with Chef we can easily install MongoDB and use zNcrypt to encrypt and protect Mongodb data.

The mongodb recipe is divided into 4 basic steps:

1. Setup the mongodb deb/rpm repositories from 10gen
2. Assemble the mongodb-10gen packages
3. Install the mongo packages
4. Setup zNcrypt with with mongodb using the ezncrypt and ezncrypt-access-control commands

In the first section of the recipe we use the apt cookbook to setup the 10gen apt repository for mongodb.

 # use the apt cookbook
 include_recipe "apt::default"
 # Add the 10gen repo, ubuntu debian
 apt_repository "10gen" do
  uri "http://downloads-distro.mongodb.org/repo/ubuntu-upstart"
  distribution "dist"
  components ["10gen"]
  key "http://docs.mongodb.org/10gen-gpg-key.asc"
  action :add 

In this second section we call apt::default to update apt and setup the list of packages to be installed.

 include_recipe "apt::default"
 %w{mongodb-10gen}

Then to install the package(s) we simple iterate over the list of packages and call the install action

# loop to install packages
mongo_packages.each do |mongo_pack|
  package mongo_pack do
    action :install
  end
end

With mongodb now installed, the last step is to encrypt the mongodb data files, which by default are in /var/lib/mongodb and setup the zNcrypt ACL. As you can see below we re-use the data bag (we created in the prior blog) to retrieve the passphrase which is required to make any ACL updates and passed to the ezncrypt-access-control command.

# Mongo is installed, we proceed to set up the encryption
# the path here is hardcoded, if it does not match yours edit here
acl_rule1="/usr/bin/mongod"
acl_rule2="/bin/mkdir"

# before anything we stop mongodb
# create the ACLs
passphrase=data_bag_item('license_pool', 'license1')['passphrase']
passphrase2=data_bag_item('license_pool', 'license1')['passphrase2']
script "create ACL" do
 interpreter "bash"
 user "root"
 cwd "/tmp"
 code <<-eoh service="" service_name="" stop="" ezncrypt-service="" start="" ezncrypt-access-control="" -a="" allow="" mongodb="" acl_rule1="" -p="" passphrase="" -s="" passphrase2="" acl_rule2="" ezncrypt="" -e="" data_dir="" eoh="" end="" pre="">

Using Chef and the zNcrypt cookbook most of the configuration work is done for you to install MongoDB with transparent data encryption. To run this recipe on your chef client, just download the zNcrypt cookbook and add the zncrypt::default and zncrypt::mongodb recipes to the run list of your chef-client.

Chef attributes, much like data bags, are useful to setup configuration variables using ruby for your recipe or cookbook. Let's review the current file structure of our zNcrypt cookbook, the attributes/default.rb file listed below contains the attributes for zNcrypt configuration.

|-- attributes
|   `-- default.rb
|-- CONTRIBUTING
|-- LICENSE
|-- metadata.rb
|-- README.md
`-- recipes
    |-- activate.rb
    |-- configdirs.rb
    |-- default.rb
    `-- zncrypt.rb

Attributes are very easy to setup, in this example we setup default values for the zncrypt_mount and zncrypt_storage attributes, these values can be modified programmatically or edited directly in the file to provide the desired values for your environment.

# setup the mount point for zncrypt
default['zncrypt']['zncrypt_mount'] = '/var/lib/ezncrypt/ezncrypted'
# setup the storage directory for zncrypt
default['zncrypt']['zncrypt_storage'] = '/var/lib/ezncrypt/storage'

Using these attributes is simple, in the code below we pull the attribute into a variable to construct the "ezncrypt-configure-directories" command.

# pull the directory configuration from the data bags
zncrypt_mount = node['zncrypt']['zncrypt_mount']
zncrypt_storage = node['zncrypt']['zncrypt_storage']
config_dirs = "-m #{zncrypt_mount} -s #{zncrypt_storage }"
case node['platform_family']
when "rhel","fedora"
opt = '-l'
when "debian"
opt = '-a'
end

script "config dirs" do
 interpreter "bash"
 user "root"
 code <<-eoh ezncrypt-service="" stop="" ezncrypt-configure-directories="" config_dirs="" opt="" eoh="" end="" pre="">

Now that we have setup our data bags and attributes let's quickly review our default.rb recipe to see how we call the new configdirs and activate recipes:

# installs zncrypt
include_recipe"zncrypt::zncrypt"
# configures the directories using the configuraiton from the databag
include_recipe"zncrypt::configdirs"
# activates the license using the data bag 
 include_recipe"zncrypt::activate"

In Part I of this blog we went over some tips and basic steps to creating a new Chef Cookbook. In Part II of this series we explored in detail the zNcrypt cookbook and recipe to perform a basic installation of zNcrypt. In this edition we will use chef data bags to activate the zNcrypt installation.

Data bags are very useful to pass configuration information to recipes using json. For zNcrypt, we will use a data bag to pass license/passphrase information to the cookbook. There are two basic ways to setup a data bag, you can use the knife command or you can setup the data bag programmatically.

knife data bag create BAG [ITEM] (options)

In our zNcrypt cookbook we will not use knife commands but rather setup the data bag programmatically. Let's review how we do this in the default.rb recipe. We start with a data_bag('license_pool') command to check if the data bag exists, if this call fails the "rescue" section will setup the new data bag.

|# check if the data bag exists, use a begin / rescue to handle the exception
begin
 # check if there is a license pool already and skip creating
 data_bag('license_pool')
rescue

Here in the rescue section of the code, we will use the OpenSSL cookbook to generate a strong password, then setup a license and activation code for each of the servers in our environment. See the openssl cookbook for more information on how to use the secure_password https://github.com/opscode/cookbooks/tree/master/openssl

|# check if the data bag exists, use a begin / rescue to handle the exception
begin
 #include the secure password from openssl recipe
 ::Chef::Recipe.send(:include, Opscode::OpenSSL::Password)

 # create a data bag for licensing pool
 license_pool = Chef::DataBag.new
 license_pool.name('license_pool')
 license_pool.save
 # create json for data bag item for each node
 ubuntu = {
   # use the node name as the id
   "id" => "ubuntu",
   # set your product key provided by Gazzang
   # this license will auto reset every hour, if your first registrationi
   # fails try again in an hour or contact sales@gazzang.com
   "license" => "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
   # set your activation code provided by Gazzang
   "activation_code" => "123412341234",
   # random passphrase
   "passphrase" => secure_password,
   # random passphrase
   "passphrase2" => secure_password,
 }
 databag_item = Chef::DataBagItem.new
 databag_item.data_bag('license_pool')
 databag_item.raw_data = ubuntu
 databag_item.save

Now that we have setup the data bag, let's see how it will be used in our cookbook to activate zNcrypt in the activate.rb recipe. We will use the Chef "node.name" attribute to select the license that matches the server. We can then construct the string to pass as argument to the ezncrypt-activate command.

# check if there is a license pool otherwise skip activation
 data_bag('license_pool')
 license=data_bag_item('license_pool',"#{node.name}")['license']
 activation_code=data_bag_item('license_pool',"#{node.name}")['activation_code']
 # we also need a passhprase and second passphrase, we will generate a random one
 passphrase=data_bag_item('license_pool',"#{node.name}")['passphrase']
 passphrase2=data_bag_item('license_pool',"#{node.name}")['passphrase2']
 # build the arguments to the activate command
 activate_args="--activate --license=#{license} --activation-code=#{activation_code} --passphrase=#{passphrase} --passphrase2=#{passphrase2}"
 script"activate zNcrypt"do
  interpreter"bash"
  user"root"
  code<<-eoh codemkdir="" var="" log="" ezncrypt="" ezncrypt-activate="" activate_args="" eoh="" end="" lt="" pre="">

One problem with this example is that the data bag stores the encryption password in clear text. In future blogs we will see how we can use Chef encrypted data bags to protect the encryption password.

As you can see data bags are a very useful method to pass configuration to cookbooks. Another method to pass configuration information to cookbooks is using Chef Attributes. Please read the next blog to see how we will use Chef Attributes to setup the zNcrypt configuration directories.

Now that we have walked through some basic tips on creating a cookbook in Part I, let's walk through the zncrypt cookbook to learn how you can use it to quickly and easily install zncrypt.

See https://github.com/gazzang/cookbooks

Let's look at the basic structure of the zncrypt cookbook: see https://github.com/gazzang/cookbooks/tree/master/zncrypt

|-- CONTRIBUTING 
|-- LICENSE 
|-- metadata.rb 
|-- README.md `
-- recipes 
 |-- default.rb `
 -- zncrypt.rb

CONTRIBUTING: contains basic information on how to contribute to this open source project 
LICENSE: contains the license information, in this case Apache 2 metadata.rb: ruby file contains metadata about the cookbook 
README.md: readme information following .md formatting recipes 
 default.rb: the default recipe, for zncrypt cookbook, it is used to call the zncrypt recipe 
 zncrypt.rb: this has all the logic to install zncrypt

Let's start by analyzing zncrypt.rb

# # Cookbook Name:: zncrypt 
# Recipe:: zncrypt 
# 
# Copyright 2012, Gazzang, Inc. 
# 
# Licensed under the Apache License, Version 2.0 (the "License"); 
# you may not use this file except in compliance with the License. 
# You may obtain a copy of the License at 
# 
# http://www.apache.org/licenses/LICENSE-2.0 
# 
# Unless required by applicable law or agreed to in writing, software 
# distributed under the License is distributed on an "AS IS" BASIS, 
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 
# See the License for the specific language governing permissions and 
# limitations under the License. 
#

We start off by setting up yum and apt to use the gazzang repository and gazzang gpg key

casenode['platform_family'] 
when"rhel","fedora" 
# use the yum cookbook 
include_recipe"yum::yum" 
# Add the Gazzang gpg key and repo, redhat centos fedora 
yum_key"RPM-GPG-KEY-gazzang"do 
url"http://archive.gazzang.com/gpg_gazzang.asc" 
action:add end 
yum_repository"gazzang"do 
repo_name"gazzang" 
description"RHEL $releasever - gazzang.com - base" 
url"http://archive.gazzang.com/redhat/stable/$releasever/$basearch" 
key"RPM-GPG-KEY-gazzang" 
action:add 
end 
when"debian" 
# use the apt cookbook 
include_recipe"apt::default" 
# Add the Gazzang gpg key and repoi, ubuntu debian 
apt_repository"gazzang"do 
uri"http://archive.gazzang.com/#{node['platform']}/stable" 
distributionnode['lsb']['codename'] 
components["main"] 
key"http://archive.gazzang.com/gpg_gazzang.asc" 
action:add 
end 
else 
Chef::Application.fatal!("Your distro is not yet supported/tested, patches welcome!") 
end

zNcrypt depends on dkms, since it is not included in CentOS we will need to download it from a repository

|-# zNcrypt requires dkms to dynamically compile the zNcrypt kernel nodule 
# in most distributions the package is included in the repo 
# on CentOS it may need to be preinstalled, we will use RPM forge 
ifplatform?("centos") 
# use the yum cookbook to add the RPM-GPG-KEY 
yum_key"RPM-GPG-KEY.dag.txt"do 
url"http://apt.sw.be/RPM-GPG-KEY.dag.txt" 
action:add 
end 
# there may be a better way to install using yum_repository, but this works 
script"install dkms rpm for CentOS"do 
interpreter"bash" 
user"root" 
cwd"/usr/local/src" 
code<<-EOH 
wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm 
rpm -ivh --force rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm 
EOH 
end
end

Now that all the repos are setup, we will iterate over the package installations for kernel headers, dkms, ezncryptfs and ezncrypt

|# assemble the packages 
zncrypt_packages=casenode['platform_family'] 
when"rhel","fedora" 
%w{kernel-devel kernel-headers dkms ezncryptfs ezncrypt} 
when"debian" 
uname=%x(uname -r) 
%W{linux-headers-#{uname}dkms ezncryptfs ezncrypt} 
end 
# loop to install packages 
zncrypt_packages.eachdo|zncrypt_pack| 
packagezncrypt_packdo 
action:install 
end 

The metadata.rb has some boilerplate attributes, defines dependancies and supported operating systems

maintainer "Gazzang, Inc." 
maintainer_email"eddie.garcia@gazzang.com" 
license"Apache 2.0" 
description"Installs/Configures zNcrypt" 
long_descriptionIO.read(File.join(File.dirname(__FILE__),'README.md')) 
version"0.0.2" 
%w{ apt yum }.eachdo|cb| 
dependscb 
end 
%w{ debian ubuntu centos redhat fedora }.eachdo|os| 
supportsos 
end 
recipe"zncrypt::default","Installs and configures zNcrypt" 

Lastly the default.rb in this cookbook is a one liner that uses the zncrypt recipe to install zncrypt.

include_recipe"zncrypt::zncrypt"

If you are looking to install zncrypt with chef all that is needed now is to download the zncrypt cookbook, upload to your repository and add the recipe to your node role or runlist.

 # git clone git@github.com:gazzang/cookbooks.git 
# knife cookbook upload zncrypt 
# knife node run_list add ubuntu recipe[zncrypt:default]

When all is done you can run chef-client on a node, which if it has zncrypt in its run_list or role will install zncrypt.

# sudo chef-client

Part III will expand the zncrypt cookbook to use data bags for license activation, configuration and generation of encryption keys.

Happy Cooking!

DevOps can be be defined in a couple ways: it's the intersection between Development (Software Engineering), Quality Assurance and Technology Operations processes, or the application of software development methodology to IT. You may agree with one of these two definitions, or perhaps you're more of a NoOps fan. Regardless, if you are looking to improve the deployment of applications you will want to read on.

If you're reading this blog, then you're probably already familiar with the open source project called "Chef". The following blog offers a few tips for creating your own "cookbook". A cookbook, as you may know, is a collection of the resources you need to automate your IT infrastructure. The first, in a short series of blogs will build on each other from Chef tips, to securing you data using zNcrypt with Chef, to a full blown Big Data deployment with Chef and zNcrypt.

There are plenty of great examples on creating your own Chef cookbook on the Opscode website, so this blog will quickly touch on a few tips that are not mentioned in most samples.

1) The easiest way to get started with your own cookbook is to sign up for a free trial of Hosted Chef server http://www.opscode.com/hosted-chef/ (no credit card required).

2) Use one of the Chef repositories for your distribution to install the Chef client

     Ubuntu or Debian use http://wiki.opscode.com/display/chef/Installing+Chef+Client+on+Ubuntu+or+Debian

     Red Hat and CentOS use http://wiki.opscode.com/display/chef/Installing+Chef+Client+on+CentOS

3) Once the Chef client is installed, how do you create a cookbook?

     # knife cookbook create mycb

     This simple knife command creates all the files for a stub cookbook named "mycb"

4) Most cookbooks are Apache licensed. If you would like to contribute your cookbook to open source, Apache 2 license is a good option see http://www.apache.org/licenses/LICENSE-2.0.html

5) Chef cookbooks use Ruby language. If you need to brush up, checkout one of the many tutorials on the web http://www.ruby-lang.org/en/documentation/quickstart/ (Ruby in 20 mins)

6) When possible use the case statement vs if statements. Some programmers would argue the performance overhead of a "case" vs an "if", for cookbooks go for code readability

     case node['platform_family']

     when "rhel","fedora"

          # do something for RedHat, CentOS, Fedora

     when "debian"

          # do something for Ubuntu, Debian, ...

     end

7) As seen above take advantage of "platform_family" vs using "platform". This will save you from listing out all the platforms

      if platform?("centos")

8) When installing packages, get all the dependencies together before installing, then loop in the installs, this will keep it easier to read and debug your logic

      mycb_packages.each do |mycb_pack|

        package mycb_pack do

          action :install

        end

     end

9) Take advantage of the many existing recipes and use them in your cookbooks, don't reinvent the wheel http://community.opscode.com/cookbooks

     zncrypt recipe uses the yum and apt cookbooks

     http://community.opscode.com/cookbooks/apt

     http://community.opscode.com/cookbooks/yum

10) To use existing cookbooks you will download them using git and then upload to your repository

     # cd chef-repo/cookbooks

     # git clone git://github.com/opscode-cookbooks/apt

     # knife cookbook upload apt

11) Edit your cookbooks metadata.rb to add other cookbook dependencies

     %w{ apt yum }.each do |cb|

          depends cb

      end

12) Use ruby -c to check the syntax on your recipe before you try to load it

     # ruby -c mycb.rb

OK, let's say you have added all your logic to your cookbook, created your recipe, tested it on your local machine and ready to share it with others

12) Edit your cookbooks README.md to add information about your cookbook, see other cookbooks as a reference

13) You will want to store your cookbook under version control, if you contributing it to opensource you can use github

      # git clone git@github.com:myorg/cookbooks.git

      # git add mycb

      # git commit -m 'Adding mycb cookbook'

14) Use knife to upload your cookbook to your repository

      # knife cookbook upload mycb

15) Use knife to upload your cookbook to the community site and share with others

      # knife cookbook site share mycb Category

16) Login to the community site to edit your cookbook http://community.opscode.com/cookbooks

This is a short a quick intro to creating a new cookbook, see Part II for information on the zncrypt cookbook to secure your data at rest with encryption.

Contrary to the title, what I am about to blog about are technologies of the past. Just think, not too long ago an 8 track tape, a Commodore 64, a Polaroid camera or a wristwatch with red LEDs to display the time were all bleeding edge technologies. Today all these items are obsolete, yet sometimes return in style labeled as “retro” or “vintage”. However, not all technology becomes obsolete. Every now and then a technology comes along that is here to stay, a technology that changes how we live our lives. The light bulb, refrigerator or the automobile are technologies that we can no longer part with in our daily lives.

Is the Cloud one of these technologies that will eventually be referred to as vintage or retro, or one of these technologies that is here to stay? Well, that is one I will reserve for a future blog. Let’s return to the topic at hand, technologies that have changed our society. Many of these technologies revolve around how we communicate, the telegraph, the telephone, am/fm radio, the television, cell phones, email, text messaging, Facebook.

Yes, Facebook is a life changing technology, it can unite total strangers to meet and dance in a flash mob, or gather in a protest against oppressors of liberty and freedom. It has changed how we communicate with our children. While visiting her grandmother my young daughter wrote on my wall “I miss you” and I “Liked” it. FB changed how we share photos with our parents, how companies market products to consumers, and how we reconnect with friends from our past. Technologies that revolve around how we communicate seem to be the ones that better endure the test of time. Communication is so important to us all.

At the same time communication unites people with one voice, it can also let an individual’s voice stand out in the crowd and share an opinion with the world. I recently saw the movie The King’s Speech. For those that know me personally, you can see how I relate to that story. I have my own challenges speaking before an audience. Between the funny therapy session scenes in the movie, lies the real message of the film; a man must face his communication challenges to deliver a historic speech- where Britain declares war on Nazi Germany. During that time in history, radio signals, speakers and microphones were all bleeding edge technologies. Yet all these technologies are ones we still use today, only now they are tucked away in that cell phone or that laptop that also broadcasts this blog post.

This is the first of a series of blogs about bleeding edge technologies. I found it appropriate to take a quick look into technology of the past before diving into technologies of the future. Stay tuned at Gazzang for more bleeding edge technology.

War Games becomes reality

The thought of hackers positioning themselves as a foreign country and threatening an act of war on the US that triggers a military counter attack is no longer just a nice plot line from a movie like War Games. The Department of Defense released yesterday its Strategy for Operating in Cyberspace. Rumors that a cyber-attack could be considered an act of war under this new policy, and thus empowering the US military to counter attack with military force, has created some controversy. Consider the latest news that the DoD lost 24,000 files to “foreign intruders” and speculated that this attack could be supported by a foreign government. Under this new policy, this could lead to counter measures that involve mobilizing troops and millions of dollars of heavy artillery. But what if this threat is just another sophisticated hack to mislead the US DoD into believing they are under attack from a foreign government or organization? It is not good form to show up with guns blazing when in reality the attack was a well-disguised intrusion from teenagers in their parents’ basement. According to an article in the Washington Post, the Defense Department lost 24,000 documents to “foreign intruders” in in what appears to be one of the most damaging cyber-attacks to date on the US military, a top Pentagon official acknowledged Thursday.

Watch this alarming video: US defense secrets stolen in cyber attacks.

Initiative 5 of the DoD Strategy for Operating in Cyberspace outlines a strategy that will help public and private sectors improve their cyber security. Investment in cyber security technology will promote education and increase research and development in the IT Security sectors. Cyber-crime is indeed a threat to all nations. Gazzang has developed software to help organizations protect their data. At a minimum organizations should be encrypting sensitive data. When organizations deploy ezNcrypt from Gazzang, even if they lose thousands of files to hackers, those files will be encrypted, and when combined with strong and secure encryption keys, will render the stolen files useless.