shedd / duckpan-vagrant Goto Github PK

The DuckDuckGo repos have dependencies compiled in dist.ini - I'm somewhat unfamiliar with Perl dependency management techniques, but this seems to be used for http://dzil.org

However, the DuckPAN installation doesn't seem to use this information to ensure dependencies are installed. When I sync one of the DDG zeroclickinfo repos into the Vagrant box (I tested zeroclickinfo-spice and zeroclickinfo-goodies so far), I hit Perl dependency issues that I need to resolve manually.

Seems like there should be a better way!

An issue with Module::Data (http://cpansearch.perl.org/src/KENTNL/Module-Data-0.007/Changes) blocked successful creation of the Vagrant environment. This was initially difficult to diagnose - it presented itself as a generic Chef error:

[2013-11-20T06:18:55+00:00] DEBUG: Re-raising exception: TypeError - can't convert nil into String
/opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:96:in `+'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:96:in `format_line'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:70:in `recipe_snippet'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:63:in `loop'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:63:in `recipe_snippet'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_inspectors/resource_failure_inspector.rb:43:in `add_explanation'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/error_mapper.rb:72:in `resource_failed'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/formatters/base.rb:157:in `resource_failed'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/event_dispatch/dispatcher.rb:29:in `resource_failed'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/event_dispatch/dispatcher.rb:29:in `each'
  /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/chef-10.14.2/bin/../lib/chef/event_dispatch/dispatcher.rb:29:in `resource_failed'

Only by patching Chef to avoid the nil error were we able to see that the issue was in fact an error with Module::Data:

! Installing Module::Data failed. See /home/vagrant/.cpanm/work/1384929078.27801/build.log for details. Retry with --force to force install it.
! Installing the dependencies failed: Module 'Module::Data' is not installed
! Bailing out the installation for App-DuckPAN-0.132.
---- End output of su -l vagrant -c 'bash -l -i -c "perl duckpan-install.pl"' ----
Ran su -l vagrant -c 'bash -l -i -c "perl duckpan-install.pl"' returned 1

Need to look into caching or otherwise stabilizing the dependencies for the environment to avoid these types of intermittant failures.

When you run vagrant up, it fails and this is outputted repeatedly:

==> default: Resolving duckpan.com (duckpan.com)... 66.228.41.215
==> default: Connecting to duckpan.com (duckpan.com)|66.228.41.215|:80... failed: Connection timed out.
==> default: Retrying.
==> default: 

As discussed on #DuckDuckGo on Freenode:

<mikedep333> Hi, is http://duckpan.com/ down?
<mikedep333> The DuckDuckHackVM, which I develop, automatically tries to download http://duckpan.com/install.pl in order to update DuckPAN every time you boot it. I cannot access it from my host OS either.
<mikedep333> hmm, it looks like that URL should be changed to .org: https://github.com/duckduckgo/p5-app-duckpan#installing-duckpan-locally
<mikedep333> I've been meaning to update the DuckDuckHack VM anyway with at least the Ubuntu OS and DuckPan updates (since December 2014)
<moollaza> mikedep333: where are you seeing duckpan.com?
<moollaza> You're correct that it's .org
<mikedep333> moollaza, https://github.com/mikedep333/duckpan-vagrant/blob/duckduckhack-vm/cookbooks/duckduckhack-vm/files/default/usr/local/bin/update-duckpan.sh#L54
<mikedep333> & line 60
<mikedep333> I last tested the VM in December 2014.
<moollaza> Hmm I don't remember us ever having that domain. AFAIK it's always been .org
<mikedep333> moollaza, either way, the solution is the same. I need to update the VM.
<moollaza> Yup. Please fix when you can ☺
<mikedep333> will do

This issue is ultimately causing DuckPAN to fail to install:
jonathanstowe/TermReadKey#7

If I ssh in with vagrant ssh, it does not occur. So it is some properly of the Chef/Vagrant shell that seems to be causing it.

Ubuntu 14.04.1 LTS, following the readme, stuck at step 5.

$ vagrant plugin install vagrant-berkshelf --plugin-version=2.0.1
Installing the 'vagrant-berkshelf --version '2.0.1'' plugin. This can take a few minutes...
/usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:153:in `gather_dependencies': Unable to resolve dependencies: vagrant-berkshelf requires celluloid (~> 0.16.0.pre), celluloid-io (~> 0.16.0.pre); berkshelf requires addressable (~> 2.3.4), berkshelf-api-client (~> 1.2), buff-config (~> 1.0), buff-extensions (~> 1.0), buff-shell_out (~> 0.1), cleanroom (~> 1.0), faraday (~> 0.9.0), minitar (~> 0.5.4), retryable (~> 1.3.3), ridley (~> 4.0), solve (~> 1.1), thor (~> 0.19), octokit (~> 3.0), celluloid (~> 0.16.0), celluloid-io (~> 0.16.1) (Gem::DependencyError)
    from /usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:267:in `install'
    from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:65:in `block in call'
    from /usr/share/vagrant/plugins/commands/plugin/gem_helper.rb:42:in `block in with_environment'
    from /usr/lib/ruby/1.9.1/rubygems/user_interaction.rb:40:in `use_ui'
    from /usr/share/vagrant/plugins/commands/plugin/gem_helper.rb:41:in `with_environment'
    from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:52:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/plugins/commands/plugin/action/bundler_check.rb:20:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:69:in `block in run'
    from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in `busy'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:69:in `run'
    from /usr/share/vagrant/plugins/commands/plugin/command/base.rb:17:in `action'
    from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:27:in `execute'
    from /usr/share/vagrant/plugins/commands/plugin/command/root.rb:56:in `execute'
    from /usr/lib/ruby/vendor_ruby/vagrant/cli.rb:38:in `execute'
    from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:484:in `cli'
    from /usr/bin/vagrant:127:in `<main>'

Right now, Vagrantfiles are a mix of configuration of the guest machine being built + personal local configuration.

As in this commit setting up a synced folder - d215961 - it would be nice to be able to have the specific path extracted out to environment variables or other external configuration.

Then we could have a env_config.yml.example file checked into the repo, making it easy to separate personal configuration from configuration of the guest machine.

The existing DuckPAN VirtualBox image uses Perlbrew (http://perlbrew.pl/) to manage its Perl installation (https://github.com/duckduckgo/p5-app-duckpan#ddh-vm-breakdown). Seems like this is a smart setup for installing and maintaining Perl. Not sure if this is worth converting.

A user reported this issue:
http://www.listbox.com/member/archive/197814/2014/12/sort/time_rev/page/1/entry/3:7/20141216115156:D6203160-8543-11E4-9E01-82B128BEBCD2/

Upon further investigation, this is a bug in ridley, a dependency of berkshelf (and therefore vagrant-berkshelf):
berkshelf/ridley#285

There are 3 ways in which the MAC address can be changed.

1. The user clones the VM.
2. The user exports the VM as a .OVF/.OVA, imports it, and chooses to change the MAC address while importing.
3. The user goes into the VM's settings and clicks the button to generate a new MAC address. (Users often click this by accident.)

When this happens, Ubuntu 12.04's udev detects the NIC as a new NIC, and assigns it the name eth1 instead of eth0. There is no config defined for eth0, so it is not used. In turn, vagrant ssh cannot even work. To fix it, the user would have to use recovery mode or a live CD.

Anyway, I already have a fix ready. I will submit a pull request shortly. It is based on this advice:
http://askubuntu.com/questions/240632/how-to-disable-udev-net-rule-generation

Hi,

I ran bundle install and then i found:

The bundle currently has ridley locked at 1.5.3.

I opened Gemfile and i saw

gem 'ridley', '~> 1.7.1'

I think you need to update your Gemfile.lock to the repository.

I'm getting this error when I first ran vagrant up. Not quite sure what the problem is. I'm using OS X 10.9.1

The dependency installation added in 3eb5efb should be included in #8

Remove the git reference to the DMG cookbook fork in Berksfile once chef-boneyard/dmg#14 is merged

Hi, not sure what wrong I have done but I think I'm doing follow instruction on README every steps and now I'm struggling with running 'vagrant up' the error is

..
any idea to fix it? Thanks!

Switch to a base box with an updated version of Ruby and Chef, or add recipes to perform these updates

I have often come across interesting Vagrant setups for testing components. The original source repo for this project - https://github.com/L2G/duckpan-vagrant - was one such example. (Another example was redis-failover-test which I was playing with and fixed some issues on: swhitt/redis-failover-test#2 ) However, I often find these Vagrantfiles extremely fragile and broken.

I have been looking to see if it might be possible to use TravisCI or similar to perform CI on Vagrantfiles.

Unfortunately, that doesn't appear to be possible currently: http://omerkatz.com/blog/2013/6/15/travis-ci-does-not-work-when-you-package-vagrant-boxes-as-a-build-step-yet

Since CircleCI is based on LXC, I thought they might be a potential alternative that could work, but apparently this is outside of their capabilities at present, as well: https://twitter.com/shedd/status/400823678448844801

To really get this setup, one option seems to be a (apparently buggy & nascent) Jenkins plugin: https://wiki.jenkins-ci.org/display/JENKINS/Vagrant+Plugin

Reported to our upstream, the Ubuntu project.
https://bugs.launchpad.net/ubuntu/+bug/1354839
It's being worked on by a Canonical employee.

The problem is that the kernel (3.8) has not been receiving any more security updates for days.

We should still stick with the cloud-images.ubuntu.com boxes while the problem gets fixed because the files.vagrantup.com boxes lack months/years worth of security updates for the entire OS, unless a user manually updates the OS.

Berkshelf (http://berkshelf.com/) seems to be the preferred way to manage Chef cookbook versions, instead of holding the cookbooks locally. Much like using Bundler for Rubygems.