zool 0.1.0

data/LICENSE

@@ -0,0 +1,20 @@
+Copyright (c) 2010 Pascal Friederich
+ 
+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,96 @@
+Zool
+=================
+zool (which is named after Zuul, "The Gatekeeper", from the movie [Ghostbusters](http://en.wikipedia.org/wiki/Ghostbusters)) is a gem to manage authorized_keys files on a set of n servers.
+It comes with a command-line client named zool which gives you access to the common tasks.
+
+The command-line client
+-----------------------
+
+the command-line client currently supports 3 commands:
+
+* fetch<br>
+  fetches the authorized_keys files from a file (defaults to /etc/hosts) or a list of hosts (see zool -h for more info), splits them up, removes duplicates and saves them to a .pub file in the keys (will be configurable... later...) directory.
+  It tries to generate the name of the keyfile by parsing the key for a someuser@somehost value at the end of the key. It only uses the someuser value to generate the keyfile name. That may become configurable later
+  You can specify a user / password for the fetch and setup tasks. See zool -h for details.
+* setup<br>
+  this task creates the keys directory, fetches the keys and naively creates a simple version of a zool.conf. That will experience some overhaul for sure because it is only capable to create server directives for every server and isn't smart enough to group keys.
+  You can specify a user / password for the fetch and setup tasks. See zool -h for details.
+* apply<br>
+  reads the zool.conf and distributes the keys to the servers specified in the configuration file. <br>
+
+The zool.conf
+---------------
+
+The zool.conf describes which keys should be deployed to which servers. It supports group, role and server directives.
+
+    [group devs]
+      members = peter, paul, danny
+    
+    [group sysadmins]
+      members = tony, frank
+    
+    [role app]
+      servers = 10.12.11.1, 10.12.11.2
+      keys = &devs, tony
+      user : my_deploy_user
+      password : mypassword
+
+    [server 10.11.1.4]
+      keys = &sysadmins
+      user = adminuser
+
+The members are specified as the name of the keyfile containing the key, without the succeeding .pub extension.
+A _group_ groups several keys, a _role_ groups several _servers_. A server, well, is a single server. (*Note*: you can have servers in several groups and even in an additional server directive at once)
+Roles and servers can have multiple _keys_. The keys can be supplied like in the _group_ directive or if you want to reference to a groups keys, by prepending a _&_ (if you would want to reference the group _devs_ you would use _&devs_).
+You can specify the user/password to use to connect to servers / roles.
+
+*NOTE* Currently the first appearance of a server in the key file sets its user/password. So it is not possible to have multiple key configurations with a different user for a single server. That might change soon!
+
+Security?
+----------
+When zool creates a authorized_keys file on a server, it always creates a backup of the existing one (it uses `authorized_keys_timestamp` as the backups filename).
+It also opens a backup connection to the server before uploading the keyfiles and tries to open another one after uploading them. If it fails to open another conncetion it uses the backup connection to restore the original keyfile.
+See how it looks like if that happens:
+
+*In the logfile*
+
+    INFO -- : Fetching key from 13.11.2.200
+    INFO -- : Trying to connect to 13.11.2.200 to see if I still have access
+    WARN -- : !!!!!! Could not login to server after upload operation! Rolling back !!!!!!
+    INFO -- : Trying to connect to 13.11.2.200 to see if I still have access
+    INFO -- : Backup channel connection succeeded. Assuming everything went fine!
+
+*At the command-line*
+    
+    NOW pray to the gods... 
+    Going to deploy to 13.11.2.200
+    Uploading...   [FAIL]
+    Could not connect to a Server after updating the authorized_keys file. Tried to roll back!
+    Error after uploading the keyfile to 13.11.2.200
+
+Known issues
+------------
+
+__Bugs / Issues__
+
+* numbering of "similar" keys is only done when generating the key files. when writing the config files it uses the unnumbered version all the time
+* tests on the fallback mechanism are not present 
+
+__Feature Todos__
+
+* generating the config from a serverpool / hostfile is pretty dump at the moment. is doesn't use the groups and roles directives, instead stupidly adds server directives with the appropriate keys. That could be made smarter...
+* if keys are in subfolders, the subfolders could automatically act as usable groups, with the folder name as reference
+
+__DONE__
+
+* allow customizing the user for server/role directives
+
+Running the tests
+=================
+
+To run the cucumber features you need to have an ssh server running on your machine and your own public key in your authorized_keys file.
+The tests use your authorized_keys file only to login to _localhost_ and fake authorized_keys and key files for testing.
+
+Copyright
+---------
+Copyright (c) 2010 Pascal Friederich. See LICENSE for details.

data/Rakefile

@@ -0,0 +1,57 @@
+require 'spec/rake/spectask'
+require 'cucumber/rake/task'
+
+Cucumber::Rake::Task.new do |t|
+  t.cucumber_opts = "--format progress"
+end
+
+task :default do
+  %w(spec cucumber).each do |task|
+    Rake::Task[task].invoke
+  end
+end
+
+desc "Run all specs"
+Spec::Rake::SpecTask.new('spec') do |t|
+  t.spec_files = FileList['spec/**/*_spec.rb']
+end
+
+begin
+  require 'jeweler'
+  Jeweler::Tasks.new do |s|
+    s.name = "zool"
+    s.summary = "Library and command-line client to manage authorized_keys files"
+    s.description = "Zool allows you to manage authorized_keys files on servers. It comes with a command-line client 'zool'. The configuration can be done in a pyconfig/gitosis like configuration file. See README.md for further details"
+    s.email = "paukul@gmail.com"
+    s.homepage = "http://github.com/paukul/zool"
+    s.authors = ["Pascal Friederich"]
+    s.version = ["0.1.0"]
+    s.files.exclude 'vendor', 'spec', 'features', '.gitignore', 'Gemfile'
+    s.test_files.include 'features/**/*'
+    s.test_files.exclude 'features/tmp'
+    s.add_dependency 'net-scp',   '>=1.0.2'
+    s.add_dependency 'net-ssh',   '>=2.0.17'
+    s.add_dependency 'net-scp',   '>=1.0.2'
+    s.add_dependency 'net-ssh',   '>=2.0.17'
+    s.add_dependency 'treetop',   '>=1.4.3'
+    s.add_dependency 'polyglot',  '>=0.2.9'
+    s.add_dependency 'highline',  '>=1.5.1'
+
+    s.add_development_dependency 'builder',          '>=2.1.2'
+    s.add_development_dependency 'columnize',        '>=0.3.1'
+    s.add_development_dependency 'cucumber',         '>=0.5.3'
+    s.add_development_dependency 'diff-lcs',         '>=1.1.2'
+    s.add_development_dependency 'fakefs',           '>=0.2.1'
+    s.add_development_dependency 'json_pure',        '>=1.2.0'
+    s.add_development_dependency 'linecache',        '>=0.43'
+    s.add_development_dependency 'rake',             '>=0.8.7'
+    s.add_development_dependency 'rspec',            '>=1.2.9'
+    s.add_development_dependency 'ruby-debug',       '>=0.10.3'
+    s.add_development_dependency 'ruby-debug-base',  '>=0.10.3'
+    s.add_development_dependency 'term-ansicolor',   '>=1.0.4'
+    
+  end
+  Jeweler::GemcutterTasks.new
+rescue LoadError
+  puts "Jeweler (or a dependency) not available. Install it with: gem install jeweler"
+end

data/Readme.md

@@ -0,0 +1,96 @@
+Zool
+=================
+zool (which is named after Zuul, "The Gatekeeper", from the movie [Ghostbusters](http://en.wikipedia.org/wiki/Ghostbusters)) is a gem to manage authorized_keys files on a set of n servers.
+It comes with a command-line client named zool which gives you access to the common tasks.
+
+The command-line client
+-----------------------
+
+the command-line client currently supports 3 commands:
+
+* fetch<br>
+  fetches the authorized_keys files from a file (defaults to /etc/hosts) or a list of hosts (see zool -h for more info), splits them up, removes duplicates and saves them to a .pub file in the keys (will be configurable... later...) directory.
+  It tries to generate the name of the keyfile by parsing the key for a someuser@somehost value at the end of the key. It only uses the someuser value to generate the keyfile name. That may become configurable later
+  You can specify a user / password for the fetch and setup tasks. See zool -h for details.
+* setup<br>
+  this task creates the keys directory, fetches the keys and naively creates a simple version of a zool.conf. That will experience some overhaul for sure because it is only capable to create server directives for every server and isn't smart enough to group keys.
+  You can specify a user / password for the fetch and setup tasks. See zool -h for details.
+* apply<br>
+  reads the zool.conf and distributes the keys to the servers specified in the configuration file. <br>
+
+The zool.conf
+---------------
+
+The zool.conf describes which keys should be deployed to which servers. It supports group, role and server directives.
+
+    [group devs]
+      members = peter, paul, danny
+    
+    [group sysadmins]
+      members = tony, frank
+    
+    [role app]
+      servers = 10.12.11.1, 10.12.11.2
+      keys = &devs, tony
+      user : my_deploy_user
+      password : mypassword
+
+    [server 10.11.1.4]
+      keys = &sysadmins
+      user = adminuser
+
+The members are specified as the name of the keyfile containing the key, without the succeeding .pub extension.
+A _group_ groups several keys, a _role_ groups several _servers_. A server, well, is a single server. (*Note*: you can have servers in several groups and even in an additional server directive at once)
+Roles and servers can have multiple _keys_. The keys can be supplied like in the _group_ directive or if you want to reference to a groups keys, by prepending a _&_ (if you would want to reference the group _devs_ you would use _&devs_).
+You can specify the user/password to use to connect to servers / roles.
+
+*NOTE* Currently the first appearance of a server in the key file sets its user/password. So it is not possible to have multiple key configurations with a different user for a single server. That might change soon!
+
+Security?
+----------
+When zool creates a authorized_keys file on a server, it always creates a backup of the existing one (it uses `authorized_keys_timestamp` as the backups filename).
+It also opens a backup connection to the server before uploading the keyfiles and tries to open another one after uploading them. If it fails to open another conncetion it uses the backup connection to restore the original keyfile.
+See how it looks like if that happens:
+
+*In the logfile*
+
+    INFO -- : Fetching key from 13.11.2.200
+    INFO -- : Trying to connect to 13.11.2.200 to see if I still have access
+    WARN -- : !!!!!! Could not login to server after upload operation! Rolling back !!!!!!
+    INFO -- : Trying to connect to 13.11.2.200 to see if I still have access
+    INFO -- : Backup channel connection succeeded. Assuming everything went fine!
+
+*At the command-line*
+    
+    NOW pray to the gods... 
+    Going to deploy to 13.11.2.200
+    Uploading...   [FAIL]
+    Could not connect to a Server after updating the authorized_keys file. Tried to roll back!
+    Error after uploading the keyfile to 13.11.2.200
+
+Known issues
+------------
+
+__Bugs / Issues__
+
+* numbering of "similar" keys is only done when generating the key files. when writing the config files it uses the unnumbered version all the time
+* tests on the fallback mechanism are not present 
+
+__Feature Todos__
+
+* generating the config from a serverpool / hostfile is pretty dump at the moment. is doesn't use the groups and roles directives, instead stupidly adds server directives with the appropriate keys. That could be made smarter...
+* if keys are in subfolders, the subfolders could automatically act as usable groups, with the folder name as reference
+
+__DONE__
+
+* allow customizing the user for server/role directives
+
+Running the tests
+=================
+
+To run the cucumber features you need to have an ssh server running on your machine and your own public key in your authorized_keys file.
+The tests use your authorized_keys file only to login to _localhost_ and fake authorized_keys and key files for testing.
+
+Copyright
+---------
+Copyright (c) 2010 Pascal Friederich. See LICENSE for details.

data/bin/zool

@@ -0,0 +1,156 @@
+#!/usr/bin/env ruby
+require 'rubygems'
+require 'lib/zool'
+require 'optparse'
+require 'highline'
+
+class ZoolClient
+  VALID_COMMANDS = %w(fetch setup fake apply)
+  
+  def initialize
+    @hl = HighLine.new
+    @options = {
+      :keys_dir => 'keys',
+      :hosts_file => '/etc/hosts',
+      :hosts => [],
+      :config => 'zool.conf',
+      :user => 'root',
+      :prompt_for_password => false
+    }
+
+    parse_opts
+    command = ARGV[0]
+    abort(@parser.to_s) unless VALID_COMMANDS.include?(command)
+    self.send(command)
+  end
+  
+  def fetch
+    pool = read_hostsfile
+    dump_keyfiles(pool)
+  end
+  
+  def fake
+    puts @options.inspect
+  end
+  
+  def apply
+    begin
+      configuration = Zool::Configuration.parse(File.read(@options[:config]))
+    rescue Zool::Configuration::ParseError => e
+      exit_with_help("Error parsing the configuration file. Error was: #{e.message}")
+    end
+    $stdout.puts "NOW pray to the gods... "
+    $stdout.puts "Going to deploy to #{configuration.servers.keys.join(",")}"
+    $stdout.print "Uploading..."
+    begin
+      configuration.upload_keys
+    rescue Net::SSH::AuthenticationFailed => e
+      $stdout.puts "   [FAIL]"
+      $stdout.puts "Error connecting to a server with the user '#{e.message}'"
+      exit 1
+    rescue Zool::Server::ConnectionVerificationExecption => e
+      $stdout.puts "   [FAIL]"
+      $stdout.puts "Could not connect to a Server after updating the authorized_keys file. Tried to roll back!"
+      $stdout.puts e.message
+      exit 1
+    end
+    $stdout.puts "   [DONE]"
+    $stdout.puts "Go check if everything is fine!"
+  end
+
+  def setup
+    unless File.directory?('keys')
+      $stdout.print "Creating keys directory..."
+      FileUtils.mkdir('keys') 
+      $stdout.puts "  [DONE]"
+    end
+    
+    pool = read_hostsfile
+    $stdout.print "Fetching keys from servers and writing config to zool.conf..."
+    config = Zool::Configuration.build(pool)
+    File.open('zool.conf', 'w+') do |file|
+      file.puts config
+    end
+    $stdout.puts "  [DONE]"
+    dump_keyfiles(pool)
+  end
+
+  def method_missing(method, *args)
+    exit_with_help("That command isn't supportet!")
+  end
+  
+  private
+    def dump_keyfiles(pool)
+      $stdout.print "Writing keyfiles..."
+      pool.dump_keyfiles
+      $stdout.puts "  [DONE]"
+    end
+
+    def parse_opts
+      @parser = OptionParser.new do |o|
+        o.banner = "Usage: zool [options] command"
+        o.separator("")
+        o.separator("Valid commands: #{VALID_COMMANDS.join(', ')}")
+        o.separator("")
+        o.separator("Input Options:")
+
+        o.on("--hosts host1,host2,host3", Array, "A comma separated list of hostnames to use (when using fetch or setup)") do |hosts|
+          @options[:hosts] = hosts
+        end
+
+        o.on("--hostfile FILENAME", String, "The file to take the hosts from. Defaults to /etc/hosts (is ignored if the --hosts option is provided)") do |hostefile|
+          @options[:hosts_file] = hostefile
+        end
+
+        o.on("-u USER", "--user USER", String, "The username to use to connect to the servers (defaults to root)") do |user|
+          @options[:user] = user
+        end
+
+        o.on("-p", "Prompt for the users password") do |p|
+          @options[:prompt_for_password] = p
+        end
+
+        o.on("-h", "--help", "This help screen" ) do
+          puts o
+          abort
+        end
+      end
+      
+      @parser.parse!(ARGV)
+    end
+
+    def read_hostsfile
+      if @options[:hosts] == [] 
+        hosts_source = "hostfile #{@options[:hosts_file]}"
+        begin
+          hostfile = File.read(@options[:hosts_file])
+        rescue Errno::ENOENT
+          exit_with_help("File #{@options[:hosts_file]} not found or invalid")
+        end
+      else
+        hosts_source = "supplied list #{@options[:hosts].join(', ')}"
+        hostfile = @options[:hosts].join("    dummyname\n")
+        hostfile << "    dummyname\n"
+      end
+      
+      password = if @options[:prompt_for_password]
+        @hl.ask("Enter your password:  ") { |q| q.echo = false }
+      else
+        ''
+      end
+
+      $stdout.print "Reading hosts from #{hosts_source}..."
+
+      pool = Zool::ServerPool.from_hostfile(hostfile, :user => @options[:user], :password => password)
+      $stdout.puts "  [DONE]"
+      exit_with_help("no Valid servers found") if pool.servers == []
+      pool
+    end
+
+    def exit_with_help(msg)
+      reason = "\n    #{msg}\n\n#{@parser}\n"
+      abort(reason)
+    end
+end
+
+ZoolClient.new

data/features/config_parser.feature

@@ -0,0 +1,67 @@
+Feature: Setting up server/key configurations in a config file
+  In order to easily manage which keys should be deployed to which server
+  As a whatever i have no idea srsly
+  I want to write a config file which gets parsed correctly to a working server/serverpool/key setup
+
+  Scenario: a config file with groups, servers and roles
+    Given the server "13.9.6.1"
+    And the server "13.9.6.2"
+    And the server "13.9.6.3"
+    And the local keyfiles
+      | name | key                      |
+      | key1 | ssh-rsa key1== foobar    |
+      | key2 | ssh-rsa key2== something |
+      | key3 | ssh-rsa key3== snafu     |
+      | key4 | ssh-dsa key4== bazz      |
+    And the config
+    """
+    [group devs]
+      members = key1, key2, key3
+
+    [role app]
+      servers = 13.9.6.1, 13.9.6.2
+      keys = &devs, key4
+    
+    [server 13.9.6.3]
+      keys = key2
+    """
+    When I parse the config and run the upload_keys command
+    Then the following keys should be on the servers
+      | server     | key                      |
+      | 13.9.6.1  | ssh-rsa key1== foobar    |
+      | 13.9.6.1  | ssh-rsa key2== something |
+      | 13.9.6.1  | ssh-rsa key3== snafu     |
+      | 13.9.6.1  | ssh-dsa key4== bazz      |
+      | 13.9.6.2  | ssh-rsa key1== foobar    |
+      | 13.9.6.2  | ssh-rsa key2== something |
+      | 13.9.6.2  | ssh-rsa key3== snafu     |
+      | 13.9.6.2  | ssh-dsa key4== bazz      |
+      | 13.9.6.3  | ssh-rsa key2== something |
+
+    Scenario: creating a new config file from a serverpool
+      Given the following hosts
+        """
+          13.9.1.41      preview_server
+          13.9.1.42      edge_server
+          10.53.1.41      production_server
+        """
+      And the following keys are on the servers
+        | server     | key                                                   |
+        | 13.9.1.41 | ssh-rsa key1== Adem.Deliceoglu@PC-ADELICEO            |
+        | 13.9.1.41 | ssh-rsa key4== abel.fernandez@nb-afernandez.local     |
+        | 13.9.1.41 | ssh-dss key2== christian.kvalheim@nb-ckvalheim.local  |
+        | 13.9.1.42 | ssh-rsa key3== lee.hambley@xing.com                   |
+        | 10.53.1.41 | ssh-rsa key5== pascal.friederich@nb-pfriederich.local |
+      When I build the config from scratch
+      Then I should have the following config
+        """
+        [server 13.9.1.41]
+          keys = adem_deliceoglu, abel_fernandez, christian_kvalheim
+        
+        [server 13.9.1.42]
+          keys = lee_hambley
+      
+        [server 10.53.1.41]
+          keys = pascal_friederich
+        
+        """