hashicorp / vagrant Goto Github PK

Vagrant is a tool for building and distributing development environments.

License: Other

Ruby 70.51% Shell 2.25% Emacs Lisp 0.01% JavaScript 0.05% HTML 0.25% PowerShell 0.86% Makefile 0.11% Dockerfile 0.02% Go 16.06% Nix 0.05% Vim Script 0.01% C 0.02% MDX 9.81% HCL 0.01%

vagrant ruby automation virtualization hacktoberfest

vagrant's Introduction

Vagrant

Website: https://www.vagrantup.com/
Source: https://github.com/hashicorp/vagrant
HashiCorp Discuss: https://discuss.hashicorp.com/c/vagrant/24

Vagrant is a tool for building and distributing development environments.

Development environments managed by Vagrant can run on local virtualized platforms such as VirtualBox or VMware, in the cloud via AWS or OpenStack, or in containers such as with Docker or raw LXC.

Vagrant provides the framework and configuration format to create and manage complete portable development environments. These development environments can live on your computer or in the cloud, and are portable between Windows, Mac OS X, and Linux.

Quick Start

Package dependencies: Vagrant requires bsdtar and curl to be available on your system PATH to run successfully.

For the quick-start, we'll bring up a development machine on VirtualBox because it is free and works on all major platforms. Vagrant can, however, work with almost any system such as OpenStack, VMware, Docker, etc.

First, make sure your development machine has VirtualBox installed. After this, download and install the appropriate Vagrant package for your OS.

To build your first virtual environment:

vagrant init hashicorp/bionic64
vagrant up

Note: The above vagrant up command will also trigger Vagrant to download the bionic64 box via the specified URL. Vagrant only does this if it detects that the box doesn't already exist on your system.

Getting Started Guide

To learn how to build a fully functional development environment, follow the getting started guide.

Installing from Source

If you want the bleeding edge version of Vagrant, we try to keep main pretty stable and you're welcome to give it a shot. Please review the installation page here.

Contributing to Vagrant

Please take time to read the HashiCorp Community Guidelines and the Vagrant Contributing Guide.

Then you're good to go!

vagrant's People

Contributors

Stargazers

Watchers

Forkers

adamhjk bmabey anaisbetts allanca lastobelus juhat wadey jeroenvandijk littleidea drnic joevandyk bixu ankopainting mscottford mdub rubiojr dreamcat4 asquera bnmrrs michaelbearne masterzen pjstadig lstoll tolbrino bpo atalanta philips sfeley zaitrarrio golive l15n charles-dyfis-net vishvananda thbar nixme stevenjenkins aglarond josephholsten tail jeffmccune hedgehog jasherai mhorbul ody ramonvanalteren gammons morepanda eugeneoden timdumol ichilton bwalding elasticdog mmrobins auser patcoll roidrage th34ut0m4t0r wfarr jwinter bodepd alanshields bitprophet danielwhelansb bspaulding tswicegood aabes nstielau mlinderm svenfuchs ajburton daniel-cloudspace kr regularfry theaboutbox wantful dax pelletier xdissent tobych brianloveswords nickcanz vishnuatrai everton lmars blahutka hosh ambethia srlindsay bakotaco darrin-wortlehock sjl sdboyer ticean dctrwatson kevin1024 vstone kami reinh hh jbrown

vagrant's Issues

Can't compile on Ubuntu 9.10 64b REE 1.8.7 because of tarruby - any ideas?

Get errors when trying to compile tarruby. Googled but found nothing about it.

/home/aemadrid/ruby/ee-1.8.7-2010.01/bin/ruby extconf.rb
checking for epkg... no
checking for mkencap... no
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strlcpy... no
checking for strsep... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for AIX... no
checking for an ANSI C-conforming const... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for unistd.h... (cached) yes
checking whether sys/types.h defines makedev... yes
checking for major_t... no
checking for minor_t... no
checking for dev_t... yes
checking for socklen_t... yes
checking for uint64_t... yes
checking for mode_t... yes
checking for off_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for nlink_t... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for working basename... no
checking for libgen.h... (cached) yes
checking for working dirname... no
checking fnmatch.h usability... yes
checking fnmatch.h presence... yes
checking for fnmatch.h... yes
checking for working POSIX fnmatch... yes
checking for lchown... yes
checking whether makedev expects three arguments... no
checking for working snprintf... yes
checking for strdup... yes
checking for strftime... yes
checking for strlcpy... (cached) no
checking for strmode... no
checking for strsep... (cached) yes
checking for gzread in -lz... yes
configure: creating ./config.status
config.status: creating listhash/libtar_listhash.h
config.status: creating listhash/libtar_list.c
config.status: creating listhash/libtar_hash.c
config.status: creating listhash/libtar_list_new.3
config.status: creating listhash/libtar_hash_new.3
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating libtar/Makefile
config.status: creating doc/Makefile
config.status: creating config.h
for n in lib libtar doc; do
( cd $n && make all ) || exit 1;
done
make[1]: Entering directory /home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/lib' gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o append.o append.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o block.o block.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o decode.o decode.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o encode.o encode.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o extract.o extract.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o handle.o handle.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o libtar_hash.o ../listhash/libtar_hash.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o libtar_list.o ../listhash/libtar_list.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o output.o output.c output.c: In function ‘th_print_long_ls’: output.c:129: warning: incompatible implicit declaration of built-in function ‘free’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o util.o util.c util.c: In function ‘int_to_oct_nonull’: util.c:153: warning: field width should have type ‘int’, but argument 4 has type ‘size_t’ util.c:153: warning: field width should have type ‘int’, but argument 4 has type ‘size_t’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o wrapper.o wrapper.c wrapper.c: In function ‘tar_extract_glob’: wrapper.c:37: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:49: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:52: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c: In function ‘tar_extract_all’: wrapper.c:88: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:91: warning: incompatible implicit declaration of built-in function ‘free’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o strlcpy.o ../compat/strlcpy.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o basename.o ../compat/basename.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o dirname.o ../compat/dirname.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o strmode.o ../compat/strmode.c ar rc libtar.a append.o block.o decode.o encode.o extract.o handle.o libtar_hash.o libtar_list.o output.o util.o wrapper.o strlcpy.o basename.o dirname.o strlcpy.o strmode.o ranlib libtar.a make[1]: Leaving directory/home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/lib'
make[1]: Entering directory /home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/libtar' gcc -g -O2 -I.. -I../lib -I../listhash -I../lib -I../compat -c -o libtar.o libtar.c libtar.c: In function ‘gzopen_frontend’: libtar.c:94: warning: cast from pointer to integer of different size libtar.c: In function ‘usage’: libtar.c:271: warning: incompatible implicit declaration of built-in function ‘exit’ gcc -g -O2 -o libtar libtar.o ../lib/libtar.a -lz make[1]: Leaving directory/home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/libtar'
make[1]: Entering directory /home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/doc' make[1]: Nothing to be done forall'.
make[1]: Leaving directory `/home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/doc'
checking for zlib.h... yes
checking for main() in -lz... yes
checking for bzlib.h... yes
checking for main() in -lbz2... yes
creating Makefile

make
gcc -I. -I. -I/home/aemadrid/ruby/ee-1.8.7-2010.01/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H -DHAVE_BZLIB_H -Ilibtar/lib -Ilibtar/listhash -fPIC -g -O2 -c tarruby.c
tarruby.c: In function ‘gzopen_frontend’:
tarruby.c:92: warning: cast from pointer to integer of different size
tarruby.c: In function ‘bzopen_frontend’:
tarruby.c:146: warning: cast from pointer to integer of different size
gcc -shared -o tarruby.so tarruby.o libtar/lib/libtar.a -L. -L/home/aemadrid/ruby/ee-1.8.7-2010.01/lib -Wl,-R/home/aemadrid/ruby/ee-1.8.7-2010.01/lib -L. -rdynamic -Wl,-export-dynamic -lbz2 -lz -lrt -ldl -lcrypt -lm -lc
/usr/bin/ld: libtar/lib/libtar.a(append.o): relocation R_X86_64_32 against `dev_match' can not be used when making a shared object; recompile with -fPIC
libtar/lib/libtar.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [tarruby.so] Error 1

Add ability to create stub vagrant_main cookbook

Add the ability to the vagrant binary to generate a vagrant_main cookbook. This can either be a separate command or an option to the 'init' command. It would be really awesome if the default recipe for vagrant_main contained comment blocks that describe the available options.

ctrl-c during import causes zombie VirtualBox processes

This is a known issue. DO NOT SIGINT (CTRL-C) DURING VM IMPORTS.

Not quite sure how to fix this yet, but we're aware of the problem. A solution if this happens:

Open up the activity monitor or process list on your system and force quit all VirtualBox processes: VBoxSvc, VirtualBox, VBoxManage. Then try vagrant up again and it should work.

Support for default options in 'vagrant init'

I propose the support of a ~/.vagrantrc file, which is parsed when running commands.

This file, of whatever format (yaml, ruby or otherwise), would store default options that might show up. Right now, in particular, it would be very handy for specifying the default box made, i,e.

YAML:
default_base_box: debian_lenny

Ruby:
Vagrant::Config.run do |config|
config.vm.default_box = 'debian_lenny'
end

Base box documentation needs update to include `vagrant package` command

Currently the documentation at http://vagrantup.com/docs/base_boxes.html gives you instructions for packaging a new base box by using tar by hand.

http://vagrantup.com/docs/boxes.html briefly mentions creating boxes and shows using the vagrant package command. I think the base_boxes.html page should be updated to reflect the use of this command rather than manual tarring.

running vagrant-box in a directory with a Vagrantfile, help is printed

if you run 'vagrant-box' in a directory with a 'Vagrantfile' in it, the vagrant-box help message is displayed, as if the parameters were incorrect. This isn't a huge problem, it's just a bit confusing.

For example, if '~/vagrant/bar/Vagrantfile' existed:
~/vagrant/foo $ vagrant-box add foo ~/dl/base.box

[INFO 03-15-2010 19:37:32] Vagrant: Creating home directory since it doesn't exist: /home/conor/.vagrant

[INFO 03-15-2010 19:37:32] Vagrant: Creating home directory since it doesn't exist: /home/conor/.vagrant/tmp

[INFO 03-15-2010 19:37:32] Vagrant: Creating home directory since it doesn't exist: /home/conor/.vagrant/boxes/

...

~/vagrant/bar $ vagrant-box add bar ~/dl/base.box

NAME
vagrant-box - manage boxes

VERSION
0.1.4

Usage:

...

Chef-solo provisioner unable to find and execute roles.

Chef-solo can't find role files in cookbook directories, since it has a separate configuration setting for the role directories.

I created a patch that fixes this issue at http://github.com/allanca/vagrant/commit/b730689e5be471a4cfee13f0a0d3de867e2cc318

It provides a new chef provisioner attribute for the chef role_path, shares the folder, and passes the path to solo.rb.

Repro: Create a Vagrantfile with configuration like

config.vm.provisioner = :chef_solo
config.chef.cookbooks_path = ["chef/cookbooks", "chef/site-cookbooks", "chef/roles"]
config.chef.run_list = ["role[base]", "role[web]"]

chef/roles should contain base.rb and web.rb, two roles that point to recipes in the two cookbook directories.

Expected: Role files should be found and executed.

Result:
Chef uses the default role directory /usr/chef/roles to search for the role files and finds nothing. This is the error message.

[INFO 03-29-2010 16:35:05] Vagrant: /usr/lib/ruby/1.8/chef/run_list.rb:137:in expand': undefined methodrecipes' for nil:NilClass (NoMethodError)
from /usr/lib/ruby/1.8/chef/run_list.rb:119:in each' from /usr/lib/ruby/1.8/chef/run_list.rb:119:inexpand'
from /usr/lib/ruby/1.8/chef/compile.rb:131:in expand_node' from /usr/lib/ruby/1.8/chef/compile.rb:65:inload_attributes'
from /usr/lib/ruby/1.8/chef/client.rb:376:in converge' from /usr/lib/ruby/1.8/chef/client.rb:103:inrun_solo'
from /usr/lib/ruby/1.8/chef/application/solo.rb:191:in run_application' from /usr/lib/ruby/1.8/chef/application/solo.rb:183:inloop'
from /usr/lib/ruby/1.8/chef/application/solo.rb:183:in run_application' from /usr/lib/ruby/1.8/chef/application.rb:57:inrun'
from /usr/bin/chef-solo:25

Add note under “Your First Vagrant Virtual Environment” that it should be done in a subdir.

A tiny documentation enhancement: I ran the four commands in the “Your First Vagrant Virtual Environment” section of http://vagrantup.com/ in my home folder, thinking vagrant would create virtual machines in some central place.

It got really confused because .vagrant/ (the directory) and .vagrant (the file) were clashing.

I know… my bad: I realized once I watched the video what I'd done wrong… but a little note might help.

No such file or directory script/vagrant-ssh-expect.sh

Hello,

I've been trying to test vagrant with an empty rails application.
The up works well, I get

[INFO 03-10-2010 16:24:23] Vagrant: VM booted and ready for use!
[INFO 03-10-2010 16:24:23] Vagrant: Mounting shared folders...
[INFO 03-10-2010 16:24:23] Vagrant: -- vagrant-root: /vagrant

But when it's started and that I try to access the ssh, I get the following error :

[INFO 03-10-2010 16:24:48] Vagrant: Reloading configuration to account for loaded box...
/usr/lib64/ruby/gems/1.8/gems/vagrant-0.1.4/bin/../lib/../lib/vagrant/ssh.rb:12:in `exec': No such file or directory - /usr/lib64/ruby/gems/1.8/gems/vagrant-0.1.4/bin/../lib/../lib/vagrant/../../script/vagrant-ssh-expect.sh vagrant vagrant localhost 2222 (Errno::ENOENT)
    from /usr/lib64/ruby/gems/1.8/gems/vagrant-0.1.4/bin/../lib/../lib/vagrant/ssh.rb:12:in `connect'
    from /usr/lib64/ruby/gems/1.8/gems/vagrant-0.1.4/bin/../lib/../lib/vagrant/commands.rb:75:in `ssh'
    from /usr/lib64/ruby/gems/1.8/gems/vagrant-0.1.4/bin/vagrant-ssh:26:in `cloaker_'
    from /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:114:in `call'
    from /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:114:in `call_parser_run_block'
    from /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:74:in `run'
    from /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:16:in `run'
    drom /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:8:in `run'
    from /usr/lib64/ruby/gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary.rb:85
    from /usr/bin/vagrant:19

I'm running on Gentoo and I have the stable (published gem) version installed.

have a way to connect to the virtualbox 'console' instead of sshing in

this is useful in some circumstances

Minor errors in website vagrantup.com

I was following the 'Getting Started' guide and other online information and came across a handful of minor mistakes. I'm not sure where the static site files are kept, so I could not correct them by forking the project. Feel free to move this issue elsewhere if it's not appropriate for this repo.

Why

Each project depends on its own libraries, message queue systems, databases, framework, and more each with their own versions.

Boxes

Beginning running the following command so it can begin downloading while box installation is covered in more detail:

Link to vbox download seemed to be down, but http://download.virtualbox.org/virtualbox/3.1.4/ worked for me

Boxes

(the name of in the example is 'getting-started')
Note that the box is given its own name, in this case “rails.”

Packaging

(I see the mac address of the VM is what the example lists, but there is no 'more info' after this sentence)
And finally, we need to add in the MAC address of the virtual machine so the internet access will work on any machine (more on this later).

an ubuntu lucid base would be nice :)

Vagrant doesn't support JRuby/IronRuby - uses C JSON library

Vagrant uses a JSON library that uses a C extension, so installing it under JRuby or IronRuby is impossible. Since Vagrant only uses JSON for reading config info (i.e. performance doesn't matter), using a pure Ruby JSON library (or YAML) would have no negative effect and would enable Vagrant to work with other Ruby implementations

[Documentation] config.chef.enabled no option anymore

Probably something you have thought of yourself, but just for others that are on edge

config.chef.enable = true

should become

config.vm.provisioner = :chef_solo

(when you want to use :chef_solo)

Give better names to the boxes

When you open the Virtualbox app and look at the list of boxes and when you look into virtualbox.xml in /Library/VirtualBox (on OS X) you'll find names like vagrantbase, vagrantbase_1, vagrantbase_2

It would be nice if these boxes would be named more distinctively. My suggestion would be to use the name of the directory the VagrantFile is in and maybe even use a configuration setting.

vagrant package --include Vagrantfile

--include Vagrantfile is an optional parameter, but not including a Vagrantfile leaves me with a broken configuration.

Vagrant should be either robust for boxes without a Vagrantfile or complain on the lack of a Vagrantfile.

need a command to start the vm without running the provisioner i.e. chef

I don't want chef to re-run every time I start my vm. Another command to start it without running chef would be great!

Helper script for working with chef solo cookbooks

This is something that I am working on for myself, but I thought it might be useful to others as well. Perhaps bundled with vagrant?

`cookbooks sources <command>`

Description: Manages the places that cookbooks will be retrieved from. Default opscode github repository.

Commands:

list - display the configured sources
add - add a source to the list, with optional position
remove - remove a source from the list
clear - remove all of the sources
promote - move a source up in the list
demote - move a source down in the list

Implementation Notes:

Sources can be github repositories or local folders

`cookbooks list`

Description: Lists all of the cookbooks that are installed

`cookbooks search <search string>`

Description: Search the configured sources for cookbooks

`cookbooks add <cookbook name> [options]`

Description: Install a cookbook and all of its dependencies

Options:

--link - if the cookbook is found in a local folder, create a symbolic link instead of coping the folder
--exclude-dependencies - overrides the default behavior to include dependent cookbooks

`cookbooks remove <cookbook name>`

Description: Remove an installed cookbook

`cookbooks stub <cookbook name>`

Description: Generates a cookbook of the given name, and creates an empty default recipe

vagrant-status command

To provide information like the size on disk, suspend/up/halt/down status, installed cookbooks, last access et al.

Support chef-server

In addition to the current chef-solo support, support building vagrant boxes from a chef-server.

Add no-color option to help

Add no color option to vagrants help output. I use vim as a pager and vim doesn't understand the shell color codes.

Vagrant doesn't work with ruby 1.9.1?

Trying to run

 vagrant box add base http://files.vagrantup.com/base.box

on an Ubuntu Karmic box running ruby 1.9.1p243 doesn't work. It requires ftools which has been renamed in 1.9.1 (it's now called 'fileutils'). Error returned is:

 /var/lib/gems/1.9.1/gems/vagrant-0.1.3/lib/vagrant.rb:8:in `require': no such file to load -- ftools (LoadError)
from /var/lib/gems/1.9.1/gems/vagrant-0.1.3/lib/vagrant.rb:8:in `block in <top (required)>'
from /var/lib/gems/1.9.1/gems/vagrant-0.1.3/lib/vagrant.rb:6:in `each'
from /var/lib/gems/1.9.1/gems/vagrant-0.1.3/lib/vagrant.rb:6:in `<top (required)>'
from /var/lib/gems/1.9.1/gems/vagrant-0.1.3/bin/vagrant-box:14:in `require'
from /var/lib/gems/1.9.1/gems/vagrant-0.1.3/bin/vagrant-box:14:in `<top (required)>'
from /var/lib/gems/1.9.1/bin/vagrant-box:19:in `load'
from /var/lib/gems/1.9.1/bin/vagrant-box:19:in `<top (required)>'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary.rb:67:in `load'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary.rb:67:in `load_subcommand'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:71:in `run'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:16:in `run'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:8:in `run'
from /var/lib/gems/1.9.1/gems/git-style-binaries-0.1.11/lib/git-style-binary.rb:85:in `block in <top (required)>'

vagrant private key permissions

SSH fails when the default key in the gem isn't set to read write and execute by the owner.

vagrant hides VBoxManage output

I was walking a teammate through a vagrant install and we ran into an issue at vagrant up'. Specifically in the part of the command that corresponds tovboxmanage import <path_to_file.ovf>'

The issue was related to low disk space on his computer. But we would have gotten it fixed much faster had we been fed the output of the `vboxmanage import' command. I'm not sure what the best way to fix this is. But I feel that hiding this information is a major pain point when things go wrong. For example, the 0%......100% ticker helps give immediate confidence that anything is happening.

Sun VirtualBox Command Line Management Interface Version 3.1.6
(C) 2005-2010 Sun Microsystems, Inc.
All rights reserved.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/iMac4/.vagrant/boxes/freshplanet_development/box.ovf...
OK.
Disks:  vmdisk1 21474836480 -1  http://www.vmware.com/specifications/vmdk.html#sparse   vagrantbase.vmdk    372798976   -1  <NULL>
Virtual system 0:
 0: Suggested OS type: "Ubuntu"
    (change with "--vsys 0 --ostype <type>"; use "list ostypes" to list all possible values)
 1: Suggested VM name "vagrantbase_1_2"
    (change with "--vsys 0 --vmname <name>")
 2: Number of CPUs: 1
    (change with "--vsys 0 --cpus <n>")
 3: Guest memory: 360 MB
    (change with "--vsys 0 --memory <MB>")
 4: Network adapter: orig NAT, config 2, extra type=NAT
 5: CD-ROM
    (disable with "--vsys 0 --unit 5 --ignore")
 6: IDE controller, type PIIX4
    (disable with "--vsys 0 --unit 6 --ignore")
 7: Hard disk image: source image=vagrantbase.vmdk, target path=/Users/iMac4/Library/VirtualBox/HardDisks/vagrantbase_2.vmdk, controller=6;channel=0
    (change controller with "--vsys 0 --unit 7 --controller <id>";
    disable with "--vsys 0 --unit 7 --ignore")
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully imported the appliance.

vagrant can' t connect to getting started virtual machine.

I am attempting to run through the getting started tutorial.

I am on os x, and there is some kind of ssh conflict with my private ssh key on this machine.
Note that the machine has my ssh key in os x's keychain.

The machine asks for my private ssh key over and over again, but doesn't seem to accept it either way, not that it would as the VM shouldn't have my public key anyway.

Program output:
http://gist.github.com/326739

Allow Key-Based SSH Authentication

The dependency on expect for SSH is one which bites a few users of Vagrant and a dependency we'd like to remove. The most obvious solution is key-based auth. This brings additional security for businesses wishing to use Vagrant as well.

vagrant-ssh fails but ssh cli succeeds

vagrant-ssh does not work for connecting to the vm, but it is accessible via

ssh -p 2222 vagrant@localhost

stack trace: https://gist.github.com/5107f77f7b1561f7de88

Shared folder names too long in some cases

I was having an issue with a Jaunty box I created using latest available kernel, and VBox additions for 3.1.6, where only one of the chef-solo shared folders was being mounted properly. A little bit of investigation showed that for whatever reason, the share names (vagrant-chef-solo-cookbooks-x and vagrant-chef-solo-roles-x) were being truncated, which caused the kernel to error on the others as duplicate filenames. This would only show up where multiple cookbooks, or cookbooks or a role path are used.

It didn't seem to occur on the Karmic base box, leading me to believe it's a bug with the VBox additions on the kernel in use.

However, it is something we can easily fix, so I'd like to propose a shortening of the names, like here: http://github.com/lstoll/vagrant/commit/17a35ab786b05c9c98457ca5f36ce9f36f808753

Chef error: Cannot find a cookbook named vagrant_main

Hi i'm getting a chef error with vagrant_main

Directory structure:
vgtest/
Vagrantfile
cookbooks/
vagrant_main/
recipes/
default.rb

Vagrantfile:

Vagrant::Config.run do |config|
  config.vm.box = "base"  
  config.vm.provisioner = :chef_solo
  config.chef.cookbooks_path = 'cookbooks'
end

default.rb:
require_recipe "apache2"

On creation I get this:

$ vagrant reload
[INFO 04-07-2010 12:28:56] Vagrant: Provisioning enabled with Vagrant::Provisioners::ChefSolo
[INFO 04-07-2010 12:28:56] Vagrant: Forcing shutdown of VM...
[INFO 04-07-2010 12:28:56] Vagrant: Running any VM customizations...
[INFO 04-07-2010 12:28:56] Vagrant: Deleting any previously set forwarded ports...
[INFO 04-07-2010 12:28:57] Vagrant: Forwarding ports...
[INFO 04-07-2010 12:28:57] Vagrant: Forwarding "ssh": 22 => 2222
[INFO 04-07-2010 12:28:57] Vagrant: Clearing previously set shared folders...
[INFO 04-07-2010 12:28:58] Vagrant: Creating shared folders metadata...
[INFO 04-07-2010 12:28:59] Vagrant: Booting VM...
[INFO 04-07-2010 12:28:59] Vagrant: Waiting for VM to boot...
[INFO 04-07-2010 12:28:59] Vagrant: Trying to connect (attempt #1 of 10)...
[INFO 04-07-2010 12:29:04] Vagrant: Trying to connect (attempt #2 of 10)...
[INFO 04-07-2010 12:29:28] Vagrant: VM booted and ready for use!
[INFO 04-07-2010 12:29:28] Vagrant: Mounting shared folders...
[INFO 04-07-2010 12:29:29] Vagrant: -- vagrant-root: /vagrant
[INFO 04-07-2010 12:29:29] Vagrant: -- vagrant-chef-solo-0: /tmp/vagrant-chef/cookbooks-0
[INFO 04-07-2010 12:29:29] Vagrant: Beginning provisioning process...
[INFO 04-07-2010 12:29:29] Vagrant: Setting permissions on chef provisioning folder...
[INFO 04-07-2010 12:29:29] Vagrant: Generating chef JSON and uploading...
[INFO 04-07-2010 12:29:29] Vagrant: Uploading chef-solo configuration script...
[INFO 04-07-2010 12:29:29] Vagrant: Running chef-solo...
[INFO 04-07-2010 12:29:31] Vagrant: [Tue, 06 Apr 2010 19:29:30 -0700] INFO: Starting Chef Solo Run
: stdout
[INFO 04-07-2010 12:29:32] Vagrant: /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/cookbook_loader.rb:126:in `[]': stderr
[INFO 04-07-2010 12:29:32] Vagrant: : : stderr
[INFO 04-07-2010 12:29:32] Vagrant: Cannot find a cookbook named vagrant_main; did you forget to add metadata to a cookbook? (http://wiki.opscode.com/display/chef/Metadata): stderr
[INFO 04-07-2010 12:29:32] Vagrant:  (: stderr
[INFO 04-07-2010 12:29:32] Vagrant: ArgumentError: stderr
[INFO 04-07-2010 12:29:32] Vagrant: )
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/mixin/language_include_recipe.rb:40:in `include_recipe'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/mixin/language_include_recipe.rb:26:in `each'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/mixin/language_include_recipe.rb:26:in `include_recipe'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/compile.rb:145:in `load_recipes'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/compile.rb:144:in `each'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/compile.rb:144:in `load_recipes'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/compile.rb:54:in `initialize'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/client.rb:316:in `new'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/client.rb:316:in `converge'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/client.rb:110:in `run_solo'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/application/solo.rb:198:in `run_application'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/application/solo.rb:190:in `loop'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/application/solo.rb:190:in `run_application'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/../lib/chef/application.rb:57:in `run'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/lib/ruby/gems/1.8/gems/chef-0.8.6/bin/chef-solo:26
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/bin/chef-solo:19:in `load'
: stderr
[INFO 04-07-2010 12:29:32] Vagrant:     from /usr/bin/chef-solo:19
: stderr

Raise exception when VM import fails

If the import action fails (due to a failure from VBoxManage) the error won't be noticed until later when the vm that ends up being nil is used. For me this came up because the ovf file that was being imported was an old format, causing VBoxManage import to fail.

Simple patch that at least notifies the user is provided below here: http://gist.github.com/327522

Using multiple boxes at the same time

Currently when you run try to run two vagrant instances add the same time you'll fail (at least when you try 'vagrant ssh')

This is because vagrant always does a ssh into localhost:2222 even when there is already a vagrant instance running on that port. I'm not sure how to go about this, but it would be nice to be able to use multiple boxes at the same time.

`vagrant reload` doesn't run customizations on VM

I just noticed this bug. I'll fix it soon when I'm back on master.

Support for providing box type at initialization, i.e. vagrant init debian_lenny

The ability to provide the box type at initialization would save a trip into an editor and speed up the process.

vagrant init debian_lenny

Add support for multiple base_mac addresses.

Currently, we can set a MAC address on a vm through the Vagrantfile.

config.vm.base_mac = "080027429590"

It could be useful if Vagrant were able to set multiple base_macs, like

config.vm.base_mac[0] = "080027429590"
config.vm.base_mac[1] = "080027429591"
config.vm.base_mac[2] = "080027429592"
config.vm.base_mac[3] = "080027429593"

In creating base boxes, I may want to set up more than one network adapter, and the ability to set the MAC address of only one of them is a hindrance to using the other(s).

no way to "shutdown" vm without having your image deleted

Need to be able to also shutdown and startup without having the vm deleted or rerunning provisioning. Suspend and resume is awesome, but not everything.

Generate ~/.ssh/config entry for boxes

The "vagrant ssh" command is very handy. However, at times I like to use other commands via ssh (i.e. git over ssh or quick SCPs). It would be very handy if a "vagrant ssh-config" command existed that would either append or update an entry in my .ssh/config file. For example, for the default box something like the following would be added to the the config file:

Host vagrant
  HostName localhost
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  IdentityFile /gem_path/.gem/ruby/1.8/gems/vagrant-0.2.0/keys/vagrant

The above options are all derived from the options hash available to the current SSH command.

What do you think?

[Documentation] config.chef.enabled no option anymore

Probably something you have thought of yourself, but just for others that are on edge

config.chef.enable = true

should become

config.vm.provisioner = :chef_solo

(when you want to use :chef_solo)

documentation for vagrant reload is misleading

http://vagrantup.com/docs/provisioners/chef_solo.html

Once enabled, if you are building a VM from scratch, run vagrant up and provisioning will automatically occur. If you already have a running VM and don’t want to rebuild everything from scratch, run vagrant reload and provisioning will automatically occur.

The second sentence leads me to believe that vagrant reload will just attempt to connect to the instance and perform provisioning. However, it seems to force shutdown the VM, start it back up, connect, and then provision. Should the documentation be made more explicit?

Is it possible to get a vagrant provision command to simply connect and execute chef-solo? Does that even make sense to do? I'm new to Vagrant Chef, but I think the whole idempotent aspect of Chef would make this command useful.

Box adding via HTTP does not work in Windows

Screenshot: http://grab.by/35rf

Add a command to export a box as an ec2 image

Ability to share only specified folders, and provide a path to each

It would be nice to specify which folders get shared, and where they should be shared.

Something like the following. First arg is local path, second is full path on the guest.

config.vm.share_folder('apps', '/rails_applications')
config.vm.share_folder('vhosts', '/etc/apache2/sites-available')

If none are provided, the default behaviour of sharing everything in /vagrant continues through

Note the second shared folder overlaps a possibly already existing directory. If not currently possible, this should make the contents of the guest and host synced, not overriding anything.

The end goal is to be able to place something in [host]/vhosts and have it show up in the VM at the right location.

`vagrant ssh` fails on Windows

Just as the title says.

vagrant ssh keys and permissions

I'm not sure if this is a bug or not, but after running vagrant ssh I get this:

Warning: Permanently added '[localhost]:2222' (RSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/michaelguterl/.rvm/gems/ree-1.8.7-2010.01/gems/vagrant-0.2.0/keys/vagrant' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/michaelguterl/.rvm/gems/ree-1.8.7-2010.01/gems/vagrant-0.2.0/keys/vagrant
vagrant@localhost's password:

I solved this by chmod 600 /Users/michaelguterl/.rvm/gems/ree-1.8.7-2010.01/gems/vagrant-0.2.0/keys/vagrant

Adding a base box prefixed with the drive letter in windows fails

http://grab.by/35ny

In the above screen shot URI.parse is having trouble reconciling the drive letter.

Mac OS X: Must run VirtualBox at least once before running `vagrant up`

I downloaded and installed VirtualBox as the instructions asked. Then I installed the vagrant gem which pulled in a bunch of others. vagrant box add [...] and vagrant init both ran fine. However, running vagrant up resulted in an exception. I have pasted the call stack below. Since the exception was complaining about a missing path, I thought I would file up VirtualBox to see if everything was working. The only action I performed before closing the VirtualBox app was to fill out the registration form. I then tried running vagrant up one more time, and it worked.

My suggestion is to detect that this is going to happen, and display a more meaningful error message, or to include in the getting started instructions that VirtualBox has to be run once. Or, hey, both might not be a bad idea, either.

    sideswipe:va-avp vaderpi$ vagrant -e
    0.2.0
    sideswipe:va-avp vaderpi$ vagrant up
    /Library/Ruby/Gems/1.8/gems/virtualbox-0.5.3/lib/virtualbox/global.rb:112:in `config': The path to the global VirtualBox config must be set. See Global.vboxconfig= (VirtualBox::Exceptions::ConfigurationException)
        from /Library/Ruby/Gems/1.8/gems/virtualbox-0.5.3/lib/virtualbox/global.rb:76:in `global'
        from /Library/Ruby/Gems/1.8/gems/virtualbox-0.5.3/lib/virtualbox/vm.rb:137:in `all'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/vm/forward_ports.rb:6:in `prepare'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:86:in `send'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:86:in `execute!'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:85:in `each'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:85:in `execute!'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:84:in `each'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:84:in `execute!'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/actions/runner.rb:39:in `execute!'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/lib/vagrant/commands.rb:82:in `up'
        from /Library/Ruby/Gems/1.8/gems/vagrant-0.2.0/bin/vagrant-up:27:in `cloaker_'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:114:in `call'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:114:in `call_parser_run_block'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/command.rb:74:in `run'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:16:in `run'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary/autorunner.rb:8:in `run'
        from /Library/Ruby/Gems/1.8/gems/git-style-binaries-0.1.11/lib/git-style-binary.rb:85
        from /usr/bin/vagrant:19

Add support for creating derived images

Perhaps something like:

vagrant box derive base newbox

This could take care of copying the base image and disk. In order to conserve host disk space difference images (snapshots) could be used: http://www.virtualbox.org/manual/ch05.html#diffimages.

Cannot install on Ubuntu Karmic 64

Maybe somebody can solve it:
After sudo gem install vagrant , I get this message

ERROR: Error installing vagrant:
ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb
checking for epkg... no
checking for mkencap... no
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strlcpy... no
checking for strsep... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for AIX... no
checking for an ANSI C-conforming const... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for unistd.h... (cached) yes
checking whether sys/types.h defines makedev... yes
checking for major_t... no
checking for minor_t... no
checking for dev_t... yes
checking for socklen_t... yes
checking for uint64_t... yes
checking for mode_t... yes
checking for off_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for nlink_t... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for working basename... no
checking for libgen.h... (cached) yes
checking for working dirname... no
checking fnmatch.h usability... yes
checking fnmatch.h presence... yes
checking for fnmatch.h... yes
checking for working POSIX fnmatch... yes
checking for lchown... yes
checking whether makedev expects three arguments... no
checking for working snprintf... yes
checking for strdup... yes
checking for strftime... yes
checking for strlcpy... (cached) no
checking for strmode... no
checking for strsep... (cached) yes
checking for gzread in -lz... yes
configure: creating ./config.status
config.status: creating listhash/libtar_listhash.h
config.status: creating listhash/libtar_list.c
config.status: creating listhash/libtar_hash.c
config.status: creating listhash/libtar_list_new.3
config.status: creating listhash/libtar_hash_new.3
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating libtar/Makefile
config.status: creating doc/Makefile
config.status: creating config.h
for n in lib libtar doc; do
( cd $n && make all ) || exit 1;
done
make[1]: se ingresa al directorio /usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/lib' gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o append.o append.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o block.o block.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o decode.o decode.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o encode.o encode.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o extract.o extract.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o handle.o handle.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o libtar_hash.o ../listhash/libtar_hash.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o libtar_list.o ../listhash/libtar_list.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o output.o output.c output.c: In function ‘th_print_long_ls’: output.c:129: warning: incompatible implicit declaration of built-in function ‘free’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o util.o util.c util.c: In function ‘int_to_oct_nonull’: util.c:153: warning: field width should have type ‘int’, but argument 4 has type ‘size_t’ util.c:153: warning: field width should have type ‘int’, but argument 4 has type ‘size_t’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o wrapper.o wrapper.c wrapper.c: In function ‘tar_extract_glob’: wrapper.c:37: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:49: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:52: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c: In function ‘tar_extract_all’: wrapper.c:88: warning: incompatible implicit declaration of built-in function ‘free’ wrapper.c:91: warning: incompatible implicit declaration of built-in function ‘free’ gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o strlcpy.o ../compat/strlcpy.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o basename.o ../compat/basename.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o dirname.o ../compat/dirname.c gcc -g -O2 -I. -I.. -I. -I../compat -I../listhash -c -o strmode.o ../compat/strmode.c ar rc libtar.a append.o block.o decode.o encode.o extract.o handle.o libtar_hash.o libtar_list.o output.o util.o wrapper.o strlcpy.o basename.o dirname.o strlcpy.o strmode.o ranlib libtar.a make[1]: se sale del directorio/usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/lib'
make[1]: se ingresa al directorio /usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/libtar' gcc -g -O2 -I.. -I../lib -I../listhash -I../lib -I../compat -c -o libtar.o libtar.c libtar.c: In function ‘gzopen_frontend’: libtar.c:94: warning: cast from pointer to integer of different size libtar.c: In function ‘usage’: libtar.c:271: warning: incompatible implicit declaration of built-in function ‘exit’ gcc -g -O2 -o libtar libtar.o ../lib/libtar.a -lz make[1]: se sale del directorio/usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/libtar'
make[1]: se ingresa al directorio /usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/doc' make[1]: No se hace nada paraall'.
make[1]: se sale del directorio `/usr/lib/ruby/gems/1.8/gems/tarruby-0.1.5/ext/libtar/doc'
checking for zlib.h... yes
checking for main() in -lz... yes
checking for bzlib.h... yes
checking for main() in -lbz2... yes
creating Makefile

make
gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -DHAVE_ZLIB_H -DHAVE_BZLIB_H -Ilibtar/lib -Ilibtar/listhash -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -c tarruby.c
tarruby.c: In function ‘gzopen_frontend’:
tarruby.c:92: warning: cast from pointer to integer of different size
tarruby.c: In function ‘bzopen_frontend’:
tarruby.c:146: warning: cast from pointer to integer of different size
gcc -shared -o tarruby.so tarruby.o libtar/lib/libtar.a -L. -L/usr/lib -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-dynamic -lruby1.8 -lbz2 -lz -lpthread -lrt -ldl -lcrypt -lm -lc
/usr/bin/ld: libtar/lib/libtar.a(append.o): relocation R_X86_64_32 against `dev_match' can not be used when making a shared object; recompile with -fPIC
libtar/lib/libtar.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [tarruby.so] Error 1

Vagrant should allow to change the log level of Chef

For debugging purposes I really need to have control over the log level of Chef. I think the default log level of chef is info.

It would be nice to be able to control this level in vagrant e.g like:

config.vm.provisioner.log_level = :debug

Currently my hacked vagrant version looks like this

  def run_chef_solo
    logger.info "Running chef-solo..."
    SSH.execute do |ssh|
      ssh.exec!("cd #{Vagrant.config.chef.provisioning_path} && sudo chef-solo -l debug -c solo.rb -j dna.json") do |channel, data, stream|

Note the -l debug

I am willing to supply a patch for this. What are your opinions on this?

[Edge] Vagrant up does not run the chef recipes

'vagrant up' does not run the chef recipes. Only after a 'vagrant reload' the chef recipes are loaded.

I'm configuring chef with the following line:

config.vm.provisioner = :chef_solo

Here is the repository I had this problem with (you'll have to ignore the other problems): http://github.com/jeroenvandijk/rails_test_box

Vagrant does not start (failed to connect to VM)

Hello,

When I issue the vagrant up command, the VM does not start.

My setup:

OS: Ubuntu 9.10 x64
Ruby: ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]
gems: 1.3.5
Vagrant: 0.2.0

Here is the output:

[INFO 03-29-2010 17:13:13] Vagrant: VM already created. Starting VM if its not already running...
[INFO 03-29-2010 17:13:13] Vagrant: Deleting any previously set forwarded ports...
[INFO 03-29-2010 17:13:13] Vagrant: Forwarding ports...
[INFO 03-29-2010 17:13:13] Vagrant: Forwarding "ssh": 22 => 2222
[INFO 03-29-2010 17:13:14] Vagrant: Clearing previously set shared folders...
[INFO 03-29-2010 17:13:14] Vagrant: Creating shared folders metadata...
[INFO 03-29-2010 17:13:15] Vagrant: Booting VM...
[INFO 03-29-2010 17:13:15] Vagrant: Waiting for VM to boot...
[INFO 03-29-2010 17:13:15] Vagrant: Trying to connect (attempt #1 of 10)...
[INFO 03-29-2010 17:13:20] Vagrant: Trying to connect (attempt #2 of 10)...
[INFO 03-29-2010 17:13:25] Vagrant: Trying to connect (attempt #3 of 10)...
[INFO 03-29-2010 17:13:30] Vagrant: Trying to connect (attempt #4 of 10)...
[INFO 03-29-2010 17:13:35] Vagrant: Trying to connect (attempt #5 of 10)...
[INFO 03-29-2010 17:13:40] Vagrant: Trying to connect (attempt #6 of 10)...
[INFO 03-29-2010 17:13:45] Vagrant: Trying to connect (attempt #7 of 10)...
[INFO 03-29-2010 17:13:51] Vagrant: Trying to connect (attempt #8 of 10)...
[INFO 03-29-2010 17:13:56] Vagrant: Trying to connect (attempt #9 of 10)...
[INFO 03-29-2010 17:14:01] Vagrant: Trying to connect (attempt #10 of 10)...
[INFO 03-29-2010 17:14:06] Vagrant: Failed to connect to VM! Failed to boot?
=====================================================================
Vagrant experienced an error!

Failed to connect to VM! Failed to boot?
=====================================================================

I've also tried to SSH in manually, but it looks like the SSH server isn't online or the port isn't forwarded properly.

Thats about all info I can provide, because I don't see anything resembling a log file.

Thanks.

hashicorp / vagrant Goto Github PK

vagrant's Introduction

Vagrant

Quick Start

Getting Started Guide

Installing from Source

Contributing to Vagrant

vagrant's People

Contributors

Stargazers

Watchers

Forkers

vagrant's Issues

cookbooks sources <command>

cookbooks list

cookbooks search <search string>

cookbooks add <cookbook name> [options]

cookbooks remove <cookbook name>

cookbooks stub <cookbook name>

Recommend Projects

Recommend Topics

Recommend Org

`cookbooks sources <command>`

`cookbooks list`

`cookbooks search <search string>`

`cookbooks add <cookbook name> [options]`

`cookbooks remove <cookbook name>`

`cookbooks stub <cookbook name>`