Search Results

Search found 84 results on 4 pages for 'vagrant'.

Page 1/4 | 1 2 3 4  | Next Page >

• "vagrant up" fails with "NS_ERROR_CALL_FAILED" error [on hold]

  - by TahitiPetey

  I am following the basic "Getting Started" guide: http://docs.vagrantup.com/v2/getting-started/index.html I ran vagrant init <etc> followed by vagrant up, but it fails with "NS_ERROR_CALL_FAILED" error. Then by enabling debug logging with VAGRANT_LOG=debug vagrant up, I get the following error output: ERROR vagrant: /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/providers/virtualbox/driver/base.rb:316:in `execute' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/providers/virtualbox/driver/version_4_2.rb:165:in `import' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/providers/virtualbox/action/import.rb:15:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/builtin/handle_box_url.rb:72:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `block in run' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/util/busy.rb:19:in `busy' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `run' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/builtin/call.rb:51:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/warden.rb:34:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/builder.rb:116:in `call' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `block in run' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/util/busy.rb:19:in `busy' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/action/runner.rb:61:in `run' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/machine.rb:147:in `action' /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run' INFO interface: error: There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["import", "/Users/me/.vagrant.d/boxes/precise32/virtualbox/box.ovf"] Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Interpreting /Users/me/.vagrant.d/boxes/precise32/virtualbox/box.ovf... OK. 0%... Progress object failure: NS_ERROR_CALL_FAILED My system setup info: Vagrant 1.2.2 VirtualBox 4.2.14 (Also tried 4.2.10, same error) Mac OSX 10.8.3

  Read the article

• vagrant and puppet security for ssl certificates

  - by Sirex

  I'm pretty new to vagrant, would someone who knows more about it (and puppet) be able to explain how vagrant deals with the ssl certs needed when making vagrant testing machines that are processing the same node definition as the real production machines ? I run puppet in master / client mode, and I wish to spin up a vagrant version of my puppet production nodes, primarily to test new puppet code against. If my production machine is, say, sql.domain.com I spin up a vagrant machine of, say, sql.vagrant.domain.com. In the vagrant file I then use the puppet_server provisioner, and give a puppet.puppet_node entry of “sql.domain.com” to it gets the same puppet node definition. On the puppet server I use a regex of something like /*.sql.domain.com/ on that node entry so that both the vagrant machine and the real one get that node entry on the puppet server. Finally, I enable auto-signing for *.vagrant.domain.com in puppet's autosign.conf, so the vagrant machine gets signed. So far, so good... However: If one machine on my network gets rooted, say, unimportant.domain.com, what's to stop the attacker changing the hostname on that machine to sql.vagrant.domain.com, deleting the old puppet ssl cert off of it and then re-run puppet with a given node name of sql.domain.com ? The new ssl cert would be autosigned by puppet, match the node name regex, and then this hacked node would get all the juicy information intended for the sql machine ?! One solution I can think of is to avoid autosigning, and put the known puppet ssl cert for the real production machine into the vagrant shared directory, and then have a vagrant ssh job move it into place. The downside of this is I end up with all my ssl certs for each production machine sitting in one git repo (my vagrant repo) and thereby on each developer's machine – which may or may not be an issue, but it dosen't sound like the right way of doing this. tl;dr: How do other people deal with vagrant & puppet ssl certificates for development or testing clones of production machines ?

  Read the article

• Authenticate to VM using vagrant up

  - by utrecht

  Authentication failure during Vagrant Up, while vagrant ssh and ssh vagrant@localhost -p2222 works I would like to execute a shell script using Vagrant at boot. Vagrant is unable to Authenticate, while the VM has been started using vagrant up: c:\temp\helloworld>vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'helloworld'... ==> default: Matching MAC address for NAT networking... ==> default: Setting the name of the VM: helloworld_default_1398419922203_60603 ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat ==> default: Forwarding ports... default: 22 => 2222 (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: Error: Connection timeout. Retrying... default: Error: Authentication failure. Retrying... default: Error: Authentication failure. Retrying... default: Error: Authentication failure. Retrying... default: Error: Authentication failure. Retrying... ... After executing CTRL + C it is possible to authenticate to the VM using vagrant ssh and ssh vagrant@localhost -p2222 Vagrant file I use the default Vagrantfile and I only changed the hostname: # -*- mode: ruby -*- # vi: set ft=ruby : # Vagrantfile API/syntax version. Don't touch unless you know what you're doing! VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| # All Vagrant configuration is done here. The most common configuration # options are documented and commented below. For a complete reference, # please see the online documentation at vagrantup.com. # Every Vagrant virtual environment requires a box to build off of. config.vm.box = "helloworld" ... Vagrant version c:\temp\helloworld>vagrant --version Vagrant 1.5.1 Question How to authenticate to VM using vagrant up?

  Read the article

• Puppet Directory and File ownership ignored

  - by Phil Sturgeon

  Puppet seems to be lying to me, which is not very nice. I am trying to set some files and directories included in /vagrant/src to be 666 and 777, and set the ownership group to the correct Apache user (using the PuppetLabs Apache module). Output from Puppet says yes. [default] Running provisioner: Vagrant::Provisioners::Puppet... [default] Running Puppet with /tmp/vagrant-puppet/manifests/default.pp... stdin: is not a tty No LSB modules are available. warning: require is a metaparam; this value will inherit to all contained resources warning: notify is a metaparam; this value will inherit to all contained resources notice: /Stage[main]//File[/vagrant/src/addons/]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/addons/]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/addons/]/mode: mode changed '0755' to '0777' notice: /Stage[main]//Package[curl]/ensure: ensure changed 'purged' to 'present' notice: /Stage[main]//File[/vagrant/src/system/cms/config/]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/config/]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/config/]/mode: mode changed '0755' to '0777' notice: /Stage[main]//File[/vagrant/src/system/cms/config/config.php]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/config/config.php]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/cache/]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/cache/]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/system/cms/cache/]/mode: mode changed '0755' to '0777' notice: /Stage[main]//File[/vagrant/src/uploads/]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/uploads/]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/uploads/]/mode: mode changed '0755' to '0777' notice: /Stage[main]/Apache/Service[httpd]/ensure: ensure changed 'stopped' to 'running' notice: /Stage[main]//File[/vagrant/src/assets/cache/]/owner: owner changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/assets/cache/]/group: group changed 'vagrant' to 'www-data' notice: /Stage[main]//File[/vagrant/src/assets/cache/]/mode: mode changed '0755' to '0777' notice: Finished catalog run in 2.29 seconds Output from ls -lah says no: $ ls -lah /vagrant/src/ total 36K drwxr-xr-x 1 vagrant vagrant 510 2012-07-03 00:11 . drwxr-xr-x 1 vagrant vagrant 340 2012-07-03 08:08 .. drwxr-xr-x 1 vagrant vagrant 136 2012-07-03 00:11 addons drwxr-xr-x 1 vagrant vagrant 102 2012-07-03 00:11 assets drwxr-xr-x 1 vagrant vagrant 510 2012-07-03 07:45 .git -rw-r--r-- 1 vagrant vagrant 1.3K 2012-07-03 00:11 .gitignore -rwxr-xr-x 1 vagrant vagrant 1.4K 2012-07-03 00:11 .htaccess -rwxr-xr-x 1 vagrant vagrant 8.8K 2012-07-03 00:11 index.php drwxr-xr-x 1 vagrant vagrant 442 2012-07-03 00:11 installer -rwxr-xr-x 1 vagrant vagrant 2.8K 2012-07-03 00:11 LICENSE -rw-r--r-- 1 vagrant vagrant 1.1K 2012-07-03 00:11 phpdoc.dist.xml -rw-r--r-- 1 vagrant vagrant 3.3K 2012-07-03 00:11 README.md drwxr-xr-x 1 vagrant vagrant 204 2012-07-03 00:11 system -rw-r--r-- 1 vagrant vagrant 42 2012-07-03 00:11 .travis.yml drwxr-xr-x 1 vagrant vagrant 102 2012-07-03 00:11 uploads Whats up with that? My entire config can be found here.

  Read the article

• How to restore Linode to Vagrant VM?

  - by Iain Elder

  I'm trying to set up a Linux development environment so I can safely make changes to my website without breaking the live site. Linode hosts my live site. A simple solution would be to host my development server on Linode as well, but I want to avoid doubling my hosting costs. The cheapest way I see is to use Vagrant on my Windows workstation to host my development environment. After I attempt to restore the backup to Vagrant and reboot the VM, I can no longer ssh into the Vagrant host. It's probably because by restoring the backup I overwrite some special Vagrant configuration, but I'm not sure how to avoid that. How do I make this approach work? If my approach is fundamentally wrong, can you suggest an alternative? Creating the backup On the Linode I used these commands to create a compressed copy of the entire filesystem, while ignoring things that shouldn't be included in the backup: $ sudo rsync -ahvz --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/backup/*} /* /backup/2 $ sudo tar -czf /backup/2.gz /backup/2 The backup file is called 2.gz because this is thesecond backup. The first backup is called 1.gz. I use WinSCP to copy the backup file to my Windows workstation. Setting up the Vagrant host I need a Vagrant box that matches my Linode operating system (Ubuntu 12.04.3 LTS, kernel 3.9.3). I selected the closet match from vagrantbox.es: Ubuntu Server Precise 12.04.3 amd64 Kernel is ready for Docker (Docker not included) On my workstation I ran these commands to add the box and initialize and boot an instance: $ vagrant box add ubuntu-precise http://nitron-vagrant.s3-website-us-east-1.amazonaws.com/vagrant_ubuntu_12.04.3_amd64_virtualbox.box $ mkdir linode-test $ cd linode-test $ vagrant init ubuntu-precise $ vagrant up Now Vagrant is running a machine with SSH on port 2222. The operating system version is the same. The kernel version is 3.8.0. Sounds close enough. Restoring the backup With WinSCP I copied the backup file 2.gz to /home/vagrant/2.gz on the Vagrant box. With PuTTY I connected via ssh to my new Vagrant box: On the box move the backup to the filesystem root. $ sudo mv 2.gz / Extract the archive to the filesystem root: $ sudo tar -xvpz -f 2.gz -C / --strip-components=2 (I discovered I need to use strip components because all files in the archive have the prefix backup/2/. I'll fix this for the next backup.) After the tar command completes, I log out of the box. Testing the backup When I try to log in again, it doesn't let me log in as vagrant with a password any more. It does let me log in as iain, my user on the live Linode, with a password. That surprised me because I disabled password authentication on my live Linode. I figured that I have to restart the ssh service for the change to take effect. Instead of restarting just ssh, I chose to restart the whole system. Now I can't even get to the login screen. PuTTY says "connection refused" when I try to connect. What went wrong?

  Read the article

• Vagrant / puppet workflow

  - by slim

  I'm new to puppet and vagrant, but I'm developing my own Puppet manifests intended to set up a vagrant box. That is, the puppet manifest is in my Vagrant directory on the host machine, and vagrant is invoking puppet -- there is no puppet server. The thing is, my workflow is: while(not working as desired) { vagrant destroy amend manifest vagrant up } ... and this means quite a lot of waiting around. What's a better way to work?

  Read the article

• Vagrant-aws not provisioning

  - by SuperCabbage

  I'm trying to spin up and provision an EC2 instance with Vagrant, it successfully creates the instance up and I can then use vagrant ssh to SSH into the it but Puppet doesn't seem to carry out any provisioning. Upon running vagrant up --provider=aws --provision I get the following output Bringing machine 'default' up with 'aws' provider... WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.9.1 [default] Warning! The AWS provider doesn't support any of the Vagrant high-level network configurations (`config.vm.network`). They will be silently ignored. [default] Launching an instance with the following settings... [default] -- Type: m1.small [default] -- AMI: ami-a73264ce [default] -- Region: us-east-1 [default] -- Keypair: banderton [default] -- Block Device Mapping: [] [default] -- Terminate On Shutdown: false [default] Waiting for SSH to become available... [default] Machine is booted and ready for use! [default] Rsyncing folder: /Users/benanderton/development/projects/my-project/aws/ => /vagrant [default] Rsyncing folder: /Users/benanderton/development/projects/my-project/aws/manifests/ => /tmp/vagrant-puppet/manifests [default] Rsyncing folder: /Users/benanderton/development/projects/my-project/aws/modules/ => /tmp/vagrant-puppet/modules-0 [default] Running provisioner: puppet... An error occurred while executing multiple actions in parallel. Any errors that occurred are shown below. An error occurred while executing the action on the 'default' machine. Please handle this error then try again: No error message I can then SSH into the instance by using vagrant ssh but none of my provisioning has taken place, so I'm assuming that errors have occured but I'm not being given any useful information relating to them. My Vagrantfile is as following; Vagrant.configure("2") do |config| config.vm.box = "ubuntu_aws" config.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box" config.vm.provider :aws do |aws, override| aws.access_key_id = "REDACTED" aws.secret_access_key = "REDACTED" aws.keypair_name = "banderton" override.ssh.private_key_path = "~/.ssh/banderton.pem" override.ssh.username = "ubuntu" aws.ami = "ami-a73264ce" end config.vm.provision :puppet do |puppet| puppet.manifests_path = "manifests" puppet.module_path = "modules" puppet.options = ['--verbose'] end end My Puppet manifest is as following; package { [ 'build-essential', 'vim', 'curl', 'git-core', 'nano', 'freetds-bin' ]: ensure => 'installed', } None of the packages are installed.

  Read the article

• Can't SSH into a Vagrant Virtual Machine

  - by Christopher Ickes

  Local Vagrant machine installed at ip address 10.0.0.23 and hostname lamp-vm. Using vagrant ssh I can connect just fine and do everything I need. This creates an ERROR - ssh vagrant@lamp-vm -v -v and I get debug1: connect to address 10.0.0.23 port 22: Connection timed out ssh: connect to host lamp-vm port 22: Connection timed out My etc/hosts file contains 10.0.0.23 lamp-vm. My .ssh/config file looks like Host lamp-vm User vagrant IdentityFile ~/.ssh/vagrant I have tried the ssh command with and without the -i /path/to/.sh/identity_file as well. How do I connect to my Vagrant Virtual Machine using SSH?

  Read the article

• Vagrant with VMware ESXi Provider

  - by Adam

  I am attempting to work with Vagrant and the vagrant-vsphere plugin to deploy machines to my VMware ESXi server. Has anyone had any luck in getting this to work? I realize that vagrant-vsphere is still 0.0.1 though and there are bound to be bugs. Specifially, Vagrant and vagrant-vsphere appear to fail during the vsphere connection, however, SSH and CLI access is enabled and the vSphere powershell is able to connect without an issue. INFO warden: Calling action: # ERROR warden: Error occurred: VagrantPlugins::VSphere::Errors::VSphereError The hostd log file on the ESXi server shows the Vagrant doing an SearchIndex query.

  Read the article

• FreeBSD with Vagrant - don't know how to check guest additions version

  - by joelmaranhao

  On Mac OS X 10.9.3 Picked a box from the VagrantCloud Init the vagrant box $ vagrant init chef/freebsd-9.2-i386 A `Vagrantfile` has been placed in this directory. You are now ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant. List the files $ ls -al -rw-r--r-- 1 joel staff 4831 Jun 5 17:17 Vagrantfile Vagrantfile content VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "chef/freebsd-9.2-i386" end Starting my virtual box leads to Errors $ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Box 'chef/freebsd-9.2-i386' could not be found. Attempting to find and install... default: Box Provider: virtualbox default: Box Version: >= 0 ==> default: Loading metadata for box 'chef/freebsd-9.2-i386' default: URL: https://vagrantcloud.com/chef/freebsd-9.2-i386 ==> default: Adding box 'chef/freebsd-9.2-i386' (v1.0.0) for provider: virtualbox default: Downloading: https://vagrantcloud.com/chef/freebsd-9.2-i386/version/1/provider/virtualbox.box ==> default: Successfully added box 'chef/freebsd-9.2-i386' (v1.0.0) for 'virtualbox'! ==> default: Importing base box 'chef/freebsd-9.2-i386'... ==> default: Matching MAC address for NAT networking... ==> default: Checking if box 'chef/freebsd-9.2-i386' is up to date... ==> default: Setting the name of the VM: freebsd92-i386_default_1401982167145_49633 ==> default: Fixed port collision for 22 => 2222. Now on port 2201. ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat ==> default: Forwarding ports... default: 22 => 2201 (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2201 default: SSH username: vagrant default: SSH auth method: private key default: Warning: Connection timeout. Retrying... default: Warning: Connection timeout. Retrying... ==> default: Machine booted and ready! Sorry, don't know how to check guest version of Virtualbox Guest Additions on this platform. Stopping installation. ==> default: Checking for guest additions in VM... default: The guest additions on this VM do not match the installed version of default: VirtualBox! In most cases this is fine, but in rare cases it can default: prevent things such as shared folders from working properly. If you see default: shared folder errors, please make sure the guest additions within the default: virtual machine match the version of VirtualBox you have installed on default: your host and reload your VM. default: default: Guest Additions Version: 4.2.16 default: VirtualBox Version: 4.3 ==> default: Mounting shared folders... default: /vagrant => /Users/joel/Code/anybots/operations/robot/freebsd92-i386 Vagrant attempted to execute the capability 'mount_virtualbox_shared_folder' on the detect guest OS 'freebsd', but the guest doesn't support that capability. This capability is required for your configuration of Vagrant. Please either reconfigure Vagrant to avoid this capability or fix the issue by creating the capability. Note that I have recently installed the latest version of VirtualBox, but somehow I can't find the Guest Additions.

  Read the article

• Unable to connect to Postgres on Vagrant Box - Connection refused

  - by Ben Miller

  First off, I'm new to Vagrant and Postgres. I created my Vagrant instance using http://files.vagrantup.com/lucid32.box with out any trouble. I am able to run vagrant up and vagrant ssh with out issue. I followed the instructions http://blog.crowdint.com/2011/08/11/postgresql-in-vagrant.html with one minor alteration. I installed "postgresql-8.4-postgis" package instead of "postgresql postgresql-contrib" I started the server using: postgres@lucid32:/home/vagrant$ /etc/init.d/postgresql-8.4 start While connected to the vagrant instance I can use psql to connect to the instance with out issue. In my Vagrantfile I had already added: config.vm.forward_port 5432, 5432 but when I try to run psql from localhost I get: psql: could not connect to server: Connection refused Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? I'm sure I am missing something simple. Any ideas? Update: I found a reference to an issue like this and the article suggested using: psql -U postgres -h localhost with that I get: psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.

  Read the article

• Vagrant is creating files and folders in my project

  - by SERPRO

  Recently I updated Vagrant (v 1.6.3) and I noticed that in the folder of my project there are some new folders and files like: d20140610-11944-1j6n1cz/ d20140610-15421-1pkz3t8/ vagrant20140610-11944-p76ezc vagrant20140610-11944-p76ezc2 vagrant20140610-11944-yt3bhz vagrant20140610-11944-yt3bhz1 vagrant20140610-15421-mfqrig vagrant20140610-15421-mfqrig1 vagrant20140610-15421-y3r71a vagrant20140610-15421-y3r71a2 vagrant20140610-15421-y3r71a2.lock most of the files are empty, others have text like this: source "https://rubygems.org" source "http://gems.hashicorp.com" gem "vagrant", "= 1.6.3" group :plugins do gem "vagrant-login", nil, {} gem "vagrant-share", nil, {} end The directories have a file named config with this this info: BUNDLE_PATH: "/home/user/.vagrant.d/gems" Is this some kind of debug option? how can I disable it?

  Read the article

• Vagrant ssh fails with VirtualBox

  - by lukewm

  vagrant up fails when it gets to the ssh part: myterminal$ vagrant up [default] VM already created. Booting if its not already running... [default] Running any VM customizations... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- ssh: 22 => 2222 (adapter 1) [default] -- db2: 30003 => 30003 (adapter 1) [default] Cleaning previously set shared folders... [default] Creating shared folders metadata... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] Failed to connect to VM! Failed to connect to VM via SSH. Please verify the VM successfully booted by looking at the VirtualBox GUI. Then when I subsequently try and connect using vagrant ssh or vagrant reload or similar, I get this: myterminal$ vagrant reload [default] Attempting graceful shutdown of linux... SSH connection was refused! This usually happens if the VM failed to boot properly. Some steps to try to fix this: First, try reloading your VM with `vagrant reload`, since a simple restart sometimes fixes things. If that doesn't work, destroy your VM and recreate it with a `vagrant destroy` followed by a `vagrant up`. If that doesn't work, contact a Vagrant maintainer (support channels listed on the website) for more assistance. Please help! I'm really stumped. Kind regards, Luke

  Read the article

• Vagrant - Failed login, ssh not set up

  - by motleydev

  This question is two fold because somewhere in my attempts to solve the problem, I created a new one. First: I was trying to vagrant up using a Vagranfile based on the standard hashicorp/precise32 box. Everything worked up until default: SSH auth method: private key where it would eventually time out. Enabling gui in the Vagrantfile showed that the machine never actually logs in. I can use the standard user/pass and log in from that point but the vagrant up process still remains at that prior status. Here's where my understanding might be a little dim. I've tried setting auth method from the insecure_pass_key to my root ~/.ssh/id_rsa or whichever one I wanted to use. I'm not entirely sure where to put a copy of the public key or my authorized keys file. I've got a .vagrant.d folder in my user dir (I'm on OSX) which seems to contain the box images. I've got a .vagrant folder in my directory with the Vagrantfile which seems to contain the specific machine I am building off of. I've tried pouring over the docs and forums but I seem to be missing a key concept here. And Now: After a host of tips/tricks such as rolling back by VirtualBox install, uninstalling/reinstalling Vagrant and VritualBox several times, when I try to run vagrant ssh-config with a Vagrantfile based on the same hashicorp/precise32 it says that the box is not enabled for SSH. Specifically, this error: The provider for this Vagrant-managed machine is reporting that it is not yet ready for SSH. Depending on your provider this can carry different meanings. Make sure your machine is created and running and try again. Additionally, check the output of `vagrant status` to verify that the machine is in the state that you expect. If you continue to get this error message, please view the documentation for the provider you're using. So now I am slightly up a creek. Any help would be appreciated if not just clarifying a concept. Some pertinent info: I'm on OSX Maverics Due to the fact I'm running a dual HD system with system files on one HD and user files on another, my permissions are a little wonky and VBoxManage will only let me run commands via Sudo - not sure if it's pertinent - but maybe. I have no idea what I'm doing. That part is perhaps more important.

  Read the article

• Veewee, Vagrant, Puppet, Erlang and RabbitMQ

  - by Tobias

  I am kinda stuck with a problem I am trying to wrap my head around for days now. Here is what I am doing: By using Veewee, I am creating a VirtualBox image and then I create a Vagrant box from it. See here, here Finally I run puppet from Vagrant to install RabbitMQ, see here. Veewee, Vagrant and VirtualBox all run on MacOS X 10.7.4. The vagrant box itself is CentOS 6.2. This worked fine for quite some time until I was recreating the VirtualBox image a couple of days ago. During installation of the rabbitmq-plugins during my puppet run I now get the following error: /Stage[main]/Rabbitmq/Exec[rabbitmq-plugins]/returns: erlexec: HOME must be set My RabbitMQ puppet configuration can be found on my GitHub repo for that project, but here is the most important part: $version = "2.8.7" $url = "http://www.rabbitmq.com/releases/rabbitmq-server/v${version}/rabbitmq-server-${version}-1.noarch.rpm" package{"erlang": ensure => "present", } package{"rabbitmq-server": provider => "rpm", source => $url, require => Package["erlang"] } exec{"rabbitmq-plugins": path => "/usr/bin:/usr/sbin:/bin", command => "rabbitmq-plugins enable rabbitmq_management", require => Package["rabbitmq-server"] } My additional repositories, e.g. epel, are defined in veewees postinstall.sh right at the top of the file. Finally, this is what I get when I do '/etc/init.d/rabbitmq-server status' [{pid,2834}, {running_applications,[{rabbit,"RabbitMQ","2.8.7"}, {ssl,"Erlang/OTP SSL application","4.1.6"}, {public_key,"Public key infrastructure","0.13"}, {crypto,"CRYPTO version 2","2.0.4"}, {mnesia,"MNESIA CXC 138 12","4.5"}, {os_mon,"CPO CXC 138 46","2.2.7"}, {sasl,"SASL CXC 138 11","2.1.10"}, {stdlib,"ERTS CXC 138 10","1.17.5"}, {kernel,"ERTS CXC 138 10","2.14.5"}]}, {os,{unix,linux}}, {erlang_version,"Erlang R14B04 (erts-5.8.5) [source] [64-bit] [rq:1] [async-threads:30] [kernel-poll:true]\n"}, {memory,[{total,24993120}, {processes,10328496}, {processes_used,10321296}, {system,14664624}, {atom,1175905}, {atom_used,1143841}, {binary,17192}, {code,11416020}, {ets,766168}]}, {vm_memory_high_watermark,0.4}, {vm_memory_limit,205851852}, {disk_free_limit,1000000000}, {disk_free,7089795072}, {file_descriptors,[{total_limit,924}, {total_used,4}, {sockets_limit,829}, {sockets_used,2}]}, {processes,[{limit,1048576},{used,131}]}, {run_queue,0}, {uptime,6}] Sources in the web suggest, that I have to set HOME. Of course I was logging into the box if HOME was set, for user vagrant it was '/home/vagrant' and for root it was 'root'. As always, any hints/ideas/suggestions/assumptions are more than welcome. Thanks a lot! Cheers, Tobi

  Read the article

• vagrant fails to bring up additional adapter for centos vm using virtual box provider

  - by Anadi Misra

  this is in continuation of the question asked here about host only adapter on dhcp I upgraded to vagrant 1.6.3 and the updated Vagrantfile to following setting for multiple adapters # add additional adapter for inter machine networking dev.vm.network :private_network, :type => "dhcp", :adapter => "2", :netmask => "255.255.255.0" it goes through creating adapters but then fails bringing up the mic on vm Anadis-MacBook-Pro:full-stack-env anadi$ vagrant up Bringing machine 'full-stack-env' up with 'virtualbox' provider... ==> full-stack-env: Clearing any previously set forwarded ports... ==> full-stack-env: Clearing any previously set network interfaces... ==> full-stack-env: Preparing network interfaces based on configuration... full-stack-env: Adapter 1: nat full-stack-env: Adapter 2: hostonly ==> full-stack-env: Forwarding ports... full-stack-env: 22 => 4223 (adapter 1) full-stack-env: 8080 => 8090 (adapter 1) ==> full-stack-env: Running 'pre-boot' VM customizations... ==> full-stack-env: Booting VM... ==> full-stack-env: Waiting for machine to boot. This may take a few minutes... full-stack-env: SSH address: 127.0.0.1:4223 full-stack-env: SSH username: vagrant full-stack-env: SSH auth method: private key full-stack-env: Warning: Connection timeout. Retrying... full-stack-env: Warning: Connection timeout. Retrying... full-stack-env: Warning: Remote connection disconnect. Retrying... ==> full-stack-env: Machine booted and ready! ==> full-stack-env: Checking for guest additions in VM... ==> full-stack-env: Setting hostname... ==> full-stack-env: Configuring and enabling network interfaces... The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! ARPCHECK=no /sbin/ifup eth 2> /dev/null Stdout from the command: Device eth does not seem to be present, delaying initialization. Stderr from the command: how ever when I log in to the environment I see two network interfaces as expected Anadis-MacBook-Pro:full-stack-env anadi$ vagrant ssh Last login: Wed Jun 4 12:54:47 2014 from 10.0.2.2 [vagrant@full-stack-env ~]$ ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:BD:39:57 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:febd:3957/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:511 errors:0 dropped:0 overruns:0 frame:0 TX packets:360 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:54574 (53.2 KiB) TX bytes:46675 (45.5 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:A3:86:C9 inet addr:172.28.128.3 Bcast:172.28.128.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fea3:86c9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1360 (1.3 KiB) TX bytes:894 (894.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) I am bit confused here on why it is trying to add another mic (eth2)? In the VM I used for creating this vagrant box, I had added two NICs already.

  Read the article

• Vagrant reporting VirtualBox guest additions out of date

  - by DTest

  Fairly new to Vagrant, so bear with me if I don't understand the process. I downloaded a CentOS box off http://www.vagrantbox.es/ Started it up running VirtualBox 4.2.4 and got this message: [default] The guest additions on this VM do not match the install version of VirtualBox! This may cause things such as forwarded ports, shared folders, and more to not work properly. If any of those things fail on this machine, please update the guest additions and repackage the box. Guest Additions Version: 4.0.8 VirtualBox Version: 4.2.4 So I used the vbguest plugin to update the guest additions, then repackaged the box as suggested. Having replaced the old box and loading it up I get the same message about guest additions being outdated, but vbguest reports that they are up to date (the automatic vbguest update is disabled in my Vagrantfile): Vagrant::Config.run do |config| config.vm.box = "centos56_64" config.vbguest.auto_update = false config.vbguest.no_remote = true end And the commands: dtest$ vagrant up [default] Importing base box 'centos56_64'... [default] The guest additions on this VM do not match the install version of VirtualBox! This may cause things such as forwarded ports, shared folders, and more to not work properly. If any of those things fail on this machine, please update the guest additions and repackage the box. Guest Additions Version: 4.0.8 VirtualBox Version: 4.2.4 [default] Matching MAC address for NAT networking... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant dtest$ vagrant vbguest --no-install [default] Detected Virtualbox Guest Additions 4.2.4 --- OK. [default] Virtualbox Guest Additions on host: 4.2.4 - guest's version is 4.2.4 Since they appear to be updated after an install, I could ignore the message. But is it possible to get rid of it?

  Read the article

• Vagrant synced folders aren't case sensitive

  - by lvmisooners

  For our web stack, we are moving from a Windows Server to CentOS. To facilitate development, we're utilizing Vagrant to run CentOS VMs locally. We're using Vagrant's Synced Folders feature to allow devs to use their favorite IDEs on their host machine, but we're finding that one key feature is missing from this setup: file system case sensitivity. The synced folder inside the VM apparently takes on the properties of the host's file system, so if I'm developing from a Windows machine, or even OSX, the file system isn't case sensitive. This is a big issue, as our production servers will be pure CentOS, and its file system will be case sensitive. Case sensitivity is one of the main reasons we wanted to have a local VM. We want to prevent "It works on my machine!" Some workarounds we've considered or tried: Use lsyncd to sync from the vagrant share to a location within the VM that is case sensitive updating files on the host doesn't seem to generate the events in the VM that lsync listens to Make a case-sensitive partition on the host (Doesn't work for Windows) Use samba this may be an option, but we haven't vetted it yet. Is there a better way? Note that we have developers using Windows, OS X, and Ubuntu, and the solution needs to work everywhere.

  Read the article

• Vagrant up doesn't load chef configs and doesn't keep an error log

  - by la_f0ka

  I'm trying to set up a vagrant box and I'm running with all sort of troubles. Right now I'm getting a strange error message where it states there's a stack trace file with more info, but that file is no where to be found. This is the error: stdin: is not a tty [Sun, 16 Sep 2012 18:31:47 +0000] INFO: *** Chef 0.10.0 *** [Sun, 16 Sep 2012 18:31:48 +0000] INFO: Setting the run_list to ["recipe[apt]", "recipe[openssl]", "recipe[apache2]", "recipe[mysql]", "recipe[mysql::server]", "recipe[php]", "recipe[php::module_apc]", "recipe[php::module_curl]", "recipe[php::module_mysql]", "recipe[apache2::mod_php5]", "recipe[apache2::mod_rewrite]"] from JSON [Sun, 16 Sep 2012 18:31:48 +0000] INFO: Run List is [recipe[apt], recipe[openssl], recipe[apache2], recipe[mysql], recipe[mysql::server], recipe[php], recipe[php::module_apc], recipe[php::module_curl], recipe[php::module_mysql], recipe[apache2::mod_php5], recipe[apache2::mod_rewrite]] [Sun, 16 Sep 2012 18:31:48 +0000] INFO: Run List expands to [apt, openssl, apache2, mysql, mysql::server, php, php::module_apc, php::module_curl, php::module_mysql, apache2::mod_php5, apache2::mod_rewrite] [Sun, 16 Sep 2012 18:31:48 +0000] INFO: Starting Chef Run for natty.talifun.com [Sun, 16 Sep 2012 18:31:48 +0000] ERROR: Running exception handlers [Sun, 16 Sep 2012 18:31:48 +0000] ERROR: Exception handlers complete [Sun, 16 Sep 2012 18:31:48 +0000] FATAL: Stacktrace dumped to /tmp/vagrant-chef-1/chef-stacktrace.out [Sun, 16 Sep 2012 18:31:48 +0000] FATAL: NameError: wrong constant name Chef-symfony2Console Chef never successfully completed! Any errors should be visible in the output above. Please fix your recipes so that they properly complete. And this is what my vagrantfile looks like: Vagrant::Config.run do |config| config.vm.box = "ubuntu-1104-server-i386" config.vm.network :hostonly, "33.33.33.33" config.vm.forward_port 80, 8000 config.vm.share_folder "symfony.tests", "/var/www/symfony.tests", "data", :nfs => true config.vm.provision :chef_solo do |chef| chef.cookbooks_path = ["../my-recipes/cookbooks", "site-cookbooks"] chef.add_recipe "apt" chef.add_recipe "openssl" chef.add_recipe "apache2" chef.add_recipe "mysql" chef.add_recipe "mysql::server" chef.add_recipe "php" chef.add_recipe "php::module_apc" chef.add_recipe "php::module_curl" chef.add_recipe "php::module_mysql" chef.add_recipe "apache2::mod_php5" chef.add_recipe "apache2::mod_rewrite" chef.add_recipe "Symfony" chef.json = { :mysql => { :server_root_password => 'root', :bind_address => '127.0.0.1' } } end end

  Read the article

• Public static ip for vagrant box

  - by Numbata

  I have server (Debian Squeeze) with 1 ethernet card and 2 public static IPs (188.120.245.4 and 188.120.244.5). What I want: Setup virtual box (Ubuntu) with access via static IP (188.120.244.5). What I was trying: config.vm.forward_port - good idea: setup interface "eth1:1" with 188.120.244.5 on host-machine, and add to Vagrant file "config.vm.forward_port = hmm..?" config.vm.network :hostonly, "188.120.244.5" - not working. Was created new interface on host-machine with ip "188.120.244.1". Of course 188.120.244.1 IP isn't mine and I can't access my server via this IP. config.vm.network :bridged - I'm confused how this works :) What I have now: Not working configuration. Debian-host-machine# cat Vagrantfile Vagrant::Config.run do |config| config.vm.define :gitlab do |box_config| box_config.vm.box = "ubuntu" box_config.vm.host_name = "ubuntu" box_config.vm.network :bridged box_config.vm.network :hostonly, "188.120.244.5", :auto_config => false end end Debian-host-machine# ifconfig eth1 Link encap:Ethernet HWaddr 00:15:17:69:71:bb inet addr:188.120.245.4 Bcast:188.120.247.255 Mask:255.255.248.0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 vboxnet0 Link encap:Ethernet HWaddr 0a:00:27:00:00:00 inet addr:188.120.244.1 Bcast:188.120.246.255 Mask:255.255.255.0 Ubuntu-virtual-machine# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:ee:8d:0c inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 eth1 Link encap:Ethernet HWaddr 08:00:27:45:71:87 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 How I can access virtual box via public static IP from network? I'm using Oracle VM VirtualBox Manager 4.1.18 and Vagrant version 1.0.3. Thanks in advance for your feedback.

  Read the article

• Vagrant VM Fails to Boot

  - by Rob Wilkerson

  I have a Vagrant environment that requires me to forward port 80 so I bring it up under sudo on an OS X machine. This has always been fine until I recently upgraded to Vagrant 1.2.2. Now it fails to boot. [default] Waiting for VM to boot. This can take a few minutes. [default] Failed to connect to VM! Failed to connect to VM via SSH. Please verify the VM successfully booted by looking at the VirtualBox GUI. Because I'm running under sudo, the machine never gets added to the Virtualbox GUI, but that's always been the case for this environment. I don't get any indication that there was a problem with the additions -- a potential source of this error, from what I've read. I can bring things up just fine if I change to using port 8080 on the host machine. I can't use the app, but the VM itself loads up and provisions nicely. As far as I can tell, the only thing that's changed is: I upgraded my Vagrant version I updated the project's Vagrantfile to use v2 syntax. Anyone have any idea what I might be missing? I thought I'd be able to find this pretty easily, but it's quickly becoming a very real problem.

  Read the article

• Vagrant (Virtualbox) host-only multiple node networking issue

  - by Lorin Hochstein

  I'm trying to use a multi-VM vagrant environment as a testbed for deploying OpenStack, and I've run into a networking problem with trying to communicate from one VM, to a VM-inside-of-a-VM. I have two Vagrant nodes, a cloud controller node and a compute node. I'm using host-only networking. My Vagrantfile looks like this: Vagrant::Config.run do |config| config.vm.box = "precise64" config.vm.define :controller do |controller_config| controller_config.vm.network :hostonly, "192.168.206.130" # eth1 controller_config.vm.network :hostonly, "192.168.100.130" # eth2 controller_config.vm.host_name = "controller" end config.vm.define :compute1 do |compute1_config| compute1_config.vm.network :hostonly, "192.168.206.131" # eth1 compute1_config.vm.network :hostonly, "192.168.100.131" # eth2 compute1_config.vm.host_name = "compute1" compute1_config.vm.customize ["modifyvm", :id, "--memory", 1024] end end When I try to start up a (QEMU-based) VM, it boots successfully on compute1, and its virtual nic (vnet0) is connected via a bridge, br100: root@compute1:~# brctl show 100 bridge name bridge id STP enabled interfaces br100 8000.08002798c6ef no eth2 vnet0 When the QEMU VM makes a request to the DHCP server (dnsmasq) running on controller, I can see the request reaches the controller because of the output on the syslog on the controller: Aug 6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPDISCOVER(br100) fa:16:3e:07:98:11 Aug 6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPOFFER(br100) 192.168.100.2 fa:16:3e:07:98:11 However, the DHCPOFFER never makes it back to the VM running on compute1. If I watch the requests using tcpdump on the vboxnet3 interface on my host machine that runs Vagrant (Mac OS X), I can see both the requests and the replies $ sudo tcpdump -i vboxnet3 -n port 67 or port 68 tcpdump: WARNING: vboxnet3: That device doesn't support promiscuous mode (BIOCPROMISC: Operation not supported on socket) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vboxnet3, link-type EN10MB (Ethernet), capture size 65535 bytes 22:51:20.694040 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:20.694057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:20.696047 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311 22:51:23.700845 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:23.700876 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:23.701591 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311 22:51:26.705978 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:26.705995 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 22:51:26.706527 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311 But, if I tcpdump on eth2 on compute, I only see the requests, not the replies: root@compute1:~# tcpdump -i eth2 -n port 67 or port 68 tcpdump: WARNING: eth2: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 02:51:20.240672 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 02:51:23.249758 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 02:51:26.258281 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280 At this point, I'm stuck. I'm not sure why the DHCP replies aren't making it to the compute node. Perhaps it has something to do with the configuration of the VirtualBox virtual switch/router? Note that eth2 interfaces on both nodes have been set to promiscuous mode.

  Read the article

• Can Vagrant point to a directory of Puppet manifests for execution?

  - by SeligkeitIstInGott

  I am using Vagrant to jump start some initial Puppet config and am confused on how to include/run multiple manifests (other than just site.pp) in the puppet execution workflow without making the extra manifests into modules and including them that way. In the puppet manifests directory that I point Vagrant to (see below) I have two manifests that I want executed: site.pp and hierasetup.pp. config.vm.provision "puppet" do |puppet| puppet.manifests_path = "puppet_files/manifests" puppet.module_path = "puppet_files/modules" puppet.manifest_file = "site.pp" puppet.options = "--verbose --debug" end Currently I am having site.pp be the manifest that calls hierasetup.pp. My site.pp looks like this: File { owner => 'root', group => 'root', mode => '0644', } import "hierasetup.pp" include jboss But I get this error about the deprecation of "import": Warning: The use of 'import' is deprecated at /tmp/vagrant-puppet-1/manifests/site.pp:33. See http://links.puppetlabs.com/puppet-import-deprecation (at grammar.ra:610:in `_reduce_190') According to the referenced URL under "Things to try instead" it says "To keep your node definitions in separate files, specify a directory as your main manifest". Further this puppet doc on main manifests says: "Recommended: If you’re using the main manifest heavily instead of relying on an ENC, consider changing the manifest setting to $confdir/manifests. This lets you split up your top-level code into multiple files while avoiding the import keyword. It will also match the behavior of simple environments." It appears that Puppet can reference an entire directory instead of just a specific manifest file, such that I would expect that Vagrant would make a provision for this and allow me to drop the "puppet.manifest_file = "site.pp" line and point to the parent directory instead in which all the *.pp files there will be executed. However removing that line in Vagrant merely generates a complaint about an expected "default.pp" in its stead: puppet provisioner: * The configured Puppet manifest is missing. Please specify a path to an existing manifest: /some/path/puppet_files/manifests/default.pp So: Firstly, do I understand the "new" (non-import) way of calling multiple manifests correctly, in that a directory is to be pointed to in which all the *.pp files inside it will be executed? And secondly, has Vagrant "caught up" with this new change to accommodate the referencing of directories in conjunction with Puppet's deprecation of "import"? Update: Thanks to Shane the issue with #2 (Vagrant's code not being caught up to allow pointing to puppet manifest directories) was reported on Vagrant's GitHub issue tracker site and has since been patched: https://github.com/mitchellh/vagrant/issues/4169

  Read the article

• Updating a staging server (from a CI server) in a Vagrant box with Chef

  - by Tomas Brambora

  I'm using Vagrant + Chef (chef_client provisioner) to create & provision a staging environment for my server. And I have a Jenkins job set up that is run every time I push to my 'develop' branch. In the Jenkins job, I would like to update & rebuild the source code of the server in the staging box and restart it. I have already written the cookbooks that install the dependencies, configure the db etc. But I'm not sure how to run only the update & rebuild & restart stuff from the cookbooks. I understand I could always tear down the whole box and rebuild it, but provisioning the box is a lengthy process so I would like to do that as little as possible. I split my server cookbook into 3 recipes: dependencies, db_setup and server. What I want to run in the my Jenkins job is the "server" recipe only. But I dont' understand how can I do that... If I specify the run_list on my Chef server, then I lose the ability to provision the whole box from scratch. Basically, I would like to be able to tell Vagrant from the command line what recipes Chef should run. Is that possible somehow? Cheers!

  Read the article

• Vagrant doesn't detect chef-solo unless re-installed

  - by nightowl

  I am using Vagrant to test my Chef recipes in Amazon AWS, and I am encountering an irritating issue: I initially assumed that Vagrant would install chef itself (as it does when using Virtual Box as the provider) but it seems that this needs to be done using the cloud-init script. However, even after I successfully installed the chef gem via cloud-init I was still getting the following error: The chef binary (eitherchef-soloorchef-client) was not found A quick google of this error suggested three probable causes: Chef had failed to install It had installed, but the directory was not in the $PATH environment variable It had installed and in the $PATH but with incorrect permissions I logged in and double checked; chef-solo and chef-client were installed; The path variable for the user, sudo and root all included /usr/local/bin and permissions were all fine. I managed to solve this problem by uninstalling and reinstalling the gem using sudo gem install chef. I don't understand why this should resolve the issue and it is a bit of a problem if I have to ssh into a test box and manually install the gem every time. Does anyone have any suggestions why this might be happening?

  Read the article

1 2 3 4  | Next Page >