[automateit] AccountManager incorrectly determining driver availability when AutomateIt is invoked from Ubuntu firstboot.sh

[Jamie Jamison]

I'm using AutomateIt 0.91104 on a system running Ubuntu Karmic and
it's great. The only problem I've run into so far has to do with
invoking recipes that use AccountManager from scripts run from the
firstboot.sh file in virtual machine created with Ubuntu's vmbuilder
command. I have a very basic firstboot.sh script that downloads and
executes a shell script that does the following:

1) Installs ruby and rubygems 1.3.6 from rubyforge (not the version
available via apt-get)
2) Downloads and installs AutomateIt 0.91104
3) Checks out a Subversion repository containing an AutomateIt
project.
4) Invokes automateit on a recipe called master.rb with the command

automateit -p /var/automateit/myproject /var/automateit/myproject/
master.rb

The master.rb recipe looks at an argument fed to the bootstrap shell
script or a tag value for the system hostname defined config/tags.yml
and invokes another recipe that calls the recipes necessary to build
the system.

#
# master.rb
#
# Master build recipe. This automateit recipe checks the value of the
tags in config/tags.yml
# and builds and configures the host depending upon how it is tagged.
#
# If no tags are set for the host install the default set of packages
and configurations.
#
invoke 'basic-packages.rb'
#
# Configure the server based upon tag value
#
if tagged?("webserver") then
invoke 'webserver.rb'
elsif tagged?("hudson_ci") then
invoke 'hudson-ci.rb'
elsif tagged?("development") then
invoke 'development.rb'
end #if tagged?

The problem I'm running into is with the development recipe. The
recipe looks like this

#
# Master recipe for building a development system running aspen and
snowbell. This builds a
# development host
# Where the aspen and snowbell trees are checked out This recipe
# does not allow for multiple separate builds on a host. Hosts are
tagged in config/tags.yml as to
# which tree they are working on and the appropriate tree is checked
out.
#
invoke 'basic-packages.rb'
invoke 'config-dev-packages.rb'
invoke 'config-gems.rb'
invoke 'install-java6.rb'
invoke 'config-jruby-jgems.rb'
invoke 'install-apache2.rb'
invoke 'config-postfix.rb'
invoke 'config-mysql.rb'
invoke 'config-sphinx.rb'
invoke 'config-aspen-snowbell-dev.rb'
invoke 'config-pure-ftpd.rb'
invoke 'config-passenger.rb'
invoke 'config-logrotate.rb'

When invoked as part of the boot process in the Ubuntu /root/
firstboot.sh script everything runs fine until the config-aspen-
snowbell-dev.rb recipe is invoked. This recipe creates the users for
our internal application, creates workspace directories and checks out
the software tree for each user. When this recipe is invoked from
firstboot.sh it fails as soon as it tries to create the new aspen and
snowbell users with the following error.

=> invoking config-aspen-snowbell-dev.rb
=> invoking /var/automateit/myproject/recipes/config-aspen-snowbell-
dev.rb
=> Driver AutomateIt::AccountManager::POSIX is available
=> Driver AutomateIt::AccountManager::Etc isn't available
Raw backtrace:
!! AutomateIt error trace:
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:206:in `driver_for': can't find driver for method
'has_user?' with arguments: ["aspen"] (NotImplementedError)}
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:154:in `dispatch_to'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:126:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager.rb:55:in `has_user?'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager/posix.rb:133:in `send'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager/posix.rb:133:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager/base.rb:34:in `_add_user_helper'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager/posix.rb:16:in `add_user'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:156:in `send'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:156:in `dispatch_to'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/plugin/
manager.rb:126:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
account_manager.rb:42:in `add_user'
/var/automateit/myproject/recipes/config-aspen-snowbell-dev.rb:25:in
`invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `each'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `invoke'
/var/automateit/myproject/recipes/development.rb:16:in `invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `each'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `invoke'
/var/automateit/myproject/recipes/master.rb:18:in `invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `each'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:406:in `invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
interpreter.rb:389:in `invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/
root.rb:15:in `invoke'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/lib/automateit/cli.rb:
39:in `run'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/bin/automateit:123
/usr/lib/ruby/1.8/optparse.rb:791:in `initialize'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/bin/automateit:35:in
`new'
/usr/lib/ruby/gems/1.8/gems/automateit-0.91104/bin/automateit:35
/usr/bin/automateit:19:in `load'
/usr/bin/automateit:19

But, and here's what's driving me nuts, if, after this failure, I
login to the system and run that script manually with

sudo automateit -p /var/automateit/myproject /var/automateit/myproject/
recipes/config-aspen-snowbell-dev.rb

It runs without error, creating the new users, setting up their
workspace directories, etc. If I create a new virtual machine with
vmbuilder, log in to it and manually run the bootstrap script that
firstboot.sh runs this it also completes the system build without any
problems.

From looking at the error output the problem appears to be that the
AccountManager::Etc driver isn't available. AccountManager::Etc
contains the has_user? method which apparently is called by the
add_user method in the AccountManager::POSIX driver and for some
reason platform autodetection is failing in this one case when called
from firstboot.sh.

AutomateIt is properly detecting the system type and determining which
driver types are loaded for all of my other recipes. As you can see
from the output below when the master.rb recipe is invoked AutomateIt
determines that it's running on an Ubuntu/Debian system and loads the
appropriate drivers for PlatformManager, ShellManager and
AddressManager.

=> Driver AutomateIt::PlatformManager::Uname is available
=> Driver AutomateIt::PlatformManager::LSB is available
=> Driver AutomateIt::PlatformManager::Debian is available
=> Driver AutomateIt::PlatformManager::Gentoo isn't available
=> Driver AutomateIt::PlatformManager::FreeBSD isn't available
=> Driver AutomateIt::PlatformManager::SunOS isn't available
=> Driver AutomateIt::PlatformManager::OpenBSD isn't available
=> Driver AutomateIt::ShellManager::WhichUnix is available
=> Driver AutomateIt::ShellManager::WhichWindows isn't available
=> Loading project from path: /var/automateit/myproject
=> Loading project tags: /var/automateit/myproject/config/tags.yml
=> Loading project fields: /var/automateit/myproject/config/fields.yml
=> Driver AutomateIt::AddressManager::SunOS isn't available
=> Driver AutomateIt::AddressManager::Linux is available
=> Driver AutomateIt::AddressManager::BSD isn't available
=> Driver AutomateIt::AddressManager::OpenBSD isn't available
=> Driver AutomateIt::AddressManager::FreeBSD isn't available
=> Driver AutomateIt::PlatformManager::Darwin isn't available

When the recipes that use ServiceManager and PackageManager are
invoked they are also available to determine and load the proper
drivers. I'm using the following code to create the new users in the
config-aspen-snowbell-dev recipe

account_manager.add_user("aspen", :description => "\"Aspen User
\"", :home => "/home/aspen", :shell =>"/bin/bash")
account_manager.add_user("snowbell", :description => "\"Snowbell User
\"", :home => "/home/snowbell", :shell =>"/bin/bash")

The firstboot script is run with /bin/sh -e, the environment variables
it runs with are:

whoami = root
UPSTART_INSTANCE=
runlevel=2
UPSTART_JOB=rc
TERM=linux
PATH=/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=2
PREVLEVEL=N
UPSTART_EVENTS=runlevel
PWD=/
previous=N
VERBOSE=no

I can work around this by creating users with a shell command from
within AutomateIt, but I hate doing that because it defeats the whole
point of using AutomateIt. Any enlightenment on this subject will be
greatly appreciated.

Thanks,

Jamie Jamison












But if I log into the server and run the config-aspen-snowbell-dev.rb
recipe with

sudo

--
You received this message because you are subscribed to the Google Groups "AutomateIt" group.
To post to this group, send email to autom...@googlegroups.com.
To unsubscribe from this group, send email to automateit+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/automateit?hl=en.