I've installed a Vagrant + Virtualbox using Chef (+library chef). When I do vagrant up first time, cookbooks get loaded correctly. However, when I do provision afterwards (be it vagrant provision, vagrant reload --provision or vagrant up --provisionI get this error:
Shared folders that Chef requires are missing on the virtual machine.
This is usually due to configuration changing after already booting the
machine. The fix is to run a `vagrant reload` so that the proper shared
folders will be prepared and mounted on the VM.
I searched everywhere and the only solution given is to do vagrant reload --provision, this worked up up to Vagrant 1.3.1.
it seems like there is a bug with sync folders, this clears the cache and fixed it for me. (from your project directory)
rm .vagrant/machines/default/virtualbox/synced_folders
vagrant reload --provision
https://github.com/mitchellh/vagrant/issues/5199
EDIT: this should be fixed in vagrant 1.7.4
That's a fairly common issue with the Vagrant plugins for both Berkshelf and Librarian. Just get used to running that command.
The way to avoid it is to use something like Test-Kitchen instead of the Vagrant plugins. That isn't a drop-in replacement though.
Related
I'm using AWS Lambda, which involves creating an archive of my node.js script, including the node_modules folder and uploading that to their infrastructure to run.
This works fine, except when it comes to node modules with native bindings (using node-gyp). Because the binding was complied and project archived on my local computer (OS X), it is not compatible with AWS's (Amazon Linux) servers.
How can I cross-compile/install a node module (specifically, node-sqlite3) so when I upload it to another server arch it runs?
While not really a solution to your problem, a very easy workaround could be to simply compile the native addons on a Linux machine.
For your particular situation, I would use Vagrant. Vagrant can create virtual machines and configure them within seconds.
Find an OS image that resembles Amazon's Linux distro (Fedora, CentOS, others that use yum as package manager - see Wiki)
Use a simple configuration script that, when run by Vagrant on machine startup, will run npm install (optionally it might also remove the node_modules folder before to ensure a clean installation)
For extra comfort, the script can also create the zip file for deployment
Once the installation finishes, the script will shutdown the VM to avoid unnecessary consumption of system resources
Deploy!
It might require some tuning if the linked libraries are not at the same place on the target machine but generally this seems to me like the best and quickest solution.
While installing the app using Vagrant might be sufficient in some cases, I have found it necessary to build the app on Linux which is as close to Lambda's Amazon Linux AMI as possible.
You can read the original answer here: https://stackoverflow.com/a/34019739/303184
Steps to make it work:
Spawn new EC2 instance. Make sure it is based on exactly the same image as your AWS Lambda runtime. You can review Lambda env details here: http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html. In our case, it was Amazon Linux AMI called amzn-ami-hvm-2015.03.0.x86_64-gp2.
Install nvm and use it to install the same version of Node.js as on the AWS Lambda. At the time of writing this, it was v0.10.36. You can refer to http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html again to find out.
You will probably need to install git & g++ compiler on the EC2. You can do this running
sudo yum install git gcc-c++
Finally, clone your app to your new EC2 and install your app's dependecies:
nvm use 0.10.36
npm install --production
You can then easily download the node_modules using scp or such.
Same lines as Robert's answer, when I had to work on my MAC in a different OS I use vm ware like Oracle's free virtualizer VirtualBox to get a linux on my mac, no cost to me. Or sign up for a new AWS account, you get a micro for a year free. Use that to get your linux box, do whatever you need there.
AWS has a page describing how to deal with native NPM modules: https://aws.amazon.com/blogs/compute/nodejs-packages-in-lambda/
I'm a newer for the hyperledger and just studying it by following the tutorials on http://hyperledger-fabric.readthedocs.io. I am trying to build the first network using "first-network" in the fabric-samples. The ./byfn -m generate is OK. But after typing ./byfn -m up, I meet
/bin/bash: ./scripts/script.sh: No such file or directory
error and the process hangs.
What is going wrong?
PS: The OS is Windows 10.
Check to see if you have a local firewall enabled. Depending on your docker configuration, a firewall may prohibit the docker daemon from accessing share drives as specified in docker setup (windows).
Restart the Docker daemon after applying local firewall changes.
I was facing the same issue and could resolve it.
The shared network drive needs to be working for any directory on the local machine to be identified from the container.
Docker for example has the "Shared drive" usually c:\ under which all your byfn.sh paths shall be present. Second condition is you need to be running the byfn.sh script with the same user who was authenticated to share the drives on the container. Your password change on the windows environment could break the already existing shared drives with the containers, hence creating problems in starting them.
Follow these steps :
In your docker terminal check the path $HOME. Type the command echo $HOME.
Make sure that your fabric-samples folder is the same path as of the variable $HOME.
Follow the steps for generating your first network.
or try the below solution.
Follow these steps :
Go to settings of docker.
Click on reset credentials.
Now check if the shared drives include the required drives or not.
If not, then include them apply your changes and restart your docker and your bash where you were trying to start your network.
I know the question is old but i have faced the similar issue so i did the following
./byfn.sh -m generate
./byfn.sh -m up
i was missing .sh in both commands.
I'm following the old tutorials off of gettingstartedwithdjango.com.
This series is quite old and I'm new to Django which is why I hit that site in the first place. It became my first introduction to Vagrant. Because the series is old and there are now new versions of Django, Vagrant, etc, I've found just getting through the first tutorial was quite difficult. This was mainly just the gap between Django v1.4 and the current version 1.9 which is what I'm running, including some syntax differences in settings.py and also some discrepancies between the text errata and the video which I had to sort through. It's a pretty detailed exercise if you're completely new to all of this (which I am), so it was quite challenging, and I was thrilled when after probably 12 hours of solid effort I was able to get everything working as was being described in the video but using all new versions of software. Once I got it all set up and working, I halted my Vagrant VM for the night and when I turned it back up (vagrant up) the next morning, I found that the VM would no longer mount its shared folders, essentially rendering the Vagrant VM useless to me as I'm then unable to run code which resides on the host machine (I'm running Windows 7) from within the VM (which is accomplished via the VirtualBox shared folders feature).
Not knowing what was wrong, this prompted me to completely reinstall my Vagrant VM. I was able to get things redeployed successfully with about one hour worth of effort, backtracking through steps I had taken to successfully complete the first tutorial in the first place, in order to back to the same point where I started (before I did the previous vagrant halt). When reinstalling the Vagrant VM I noticed messages that my VirtualBox Guest Additions (4.2.0) did not match the version of VirtualBox I have installed (5.0.10), which I recalled seeing the first time but ignored because it also said this isn't usually a problem and should work (if it weren't for bad luck, I'd have no luck at all). Since for me it didn't work, this led me down a whole rabbit hole of posts from various websites including SO, which ultimately had me updating my Vagrant VM, downloading/mounting/building/installing a new version of VirtualBox Guest Additions, and reloading my Vagrant VM only to wind up in the same boat. Shared folders were still not working!
To be very specific, this is more or less what I tried based on information from many websites:
cd /home/vagrant
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install dkms build-essential linux-headers-generic
sudo apt-get install linux-headers-3.2.0-23-generic
# mounted VBoxGuestAdditions_5.0.10.iso to Vagrant VM
cd /media/cdrom
sudo sh ./VBoxLinuxAdditions.run
sudo reboot
sudo /etc/init.d/vboxadd setup
sudo reload
c:\VAGRANT\vagrant plugin install vagrant-vbguest
c:\VAGRANT\vagrant reload
I was utterly convinced this was going to resolve the issue but it didn't.
Then I found this gem:
http://ddelizia.blogspot.com/2011/02/how-to-share-folder-on-virtual-box-with.html
This shows how to, from within the Vagrant VM, mount the shared folders back to your Windows 7 host. To be specific, here's what I did when I found things were working again:
cd /vagrant
ls -la
<this yielded nothing>
sudo mount.vboxsf vagrant /vagrant # see your VirtualBox Shared Folders settings
cd ~ # /home/vagrant
cd - # /vagrant
ls -la
# this yielded the expected folders from my Win7 host
In the mount.vboxsf command above, the first vagrant (without the /) came from the Name column in my VirtualBox shared folders settings. This is essentially an alias which is used to refer to the actual path on the Win7 host, in my case: C:/VAGRANT. The second vagrant (with the /) in that command is the /vagrant folder on the Vagrant VM (linux).
Given that I spent most of today messing with this and I figure there are plenty of people who are going to run into this same or related problem, I thought I would try to help out and save you all a bunch of time. Good luck.
I'm using Vagrant to deploy chef scripts to an AWS server (and it mostly works awesome). I have set up a local rsync in my Vagrantfile to mirror my dev directory onto the server.
config.vm.synced_folder "../geoevents", "/vagrant/geoevents-repo"
And this syncs find on 'vagrant provision'. I'm wondering if there is an easier way that I can have vagrant only trigger that rsync, or to control how often rsync occurs?
Or, should I not be using rsync, but instead mount a shared file system?
Vagrant CLI now has two new commands, vagrant rsync and vagrant rsync-auto which can do the job.
Command: vagrant rsync
This command forces a re-sync of any rsync synced folders.
Note that if you change any settings within the rsync synced folders such as exclude paths, you will need to vagrant reload before this command will pick up those changes.
https://www.vagrantup.com/docs/cli/rsync.html
https://www.vagrantup.com/docs/cli/rsync-auto.html
https://www.vagrantup.com/docs/cli/non-primary.html
Currently, you can fit your needs with the following plugin:
https://github.com/cromulus/vagrant-rsync
By the way, most of the plugin features will be available in Vagrant 1.5 (currently in development).
The vagrant-rsync is deprecated as of Vagrant 1.5. One solution out there is vagrant-unison. You may also check out this discussion. What should also work is a vagrant reload.
I have a specific Vagrantfile for a lucid32 box that installs some pretty standard packages (PHP/MySQL/Apache), does some specific port forwarding and so on, I set it up, checkout a project from git and change some server configurations, I want to package this box for other developers on the team to use, so I use the command:
vagrant package boxname --output test.box --vagrantfile Vagrantfile
I get a test.box file, it notes in the packaging that it's adding my specific Vagrantfile, then I run:
vagrant box add boxname test.box
It appears in vagrant box list just fine, now when I create some test directory, and do vagrant init boxname followed by vagrant up
and then it provisions that box with the files from the checkout and everything, but does not setup the proper port forwarding,
and is in fact not using my Vagrantfile I packaged it with at all, but generated a new default one in that directory.
I noticed in ~/.vagrant.d/boxes/boxname it has the default Vagrantfile, along with the one I packaged in includes/_Vagrantfile
Is there any way I can get the specific Vagrantfile to be the one generated when I do vagrant init boxname?
This is actually all working as intended. Vagrant loads multiple Vagrantfiles (not just the one from vagrant init) when loading up, and the Vagrantfile packaged with a box is one of those. For more information, read about the "Vagrantfile Load Order" here: https://www.vagrantup.com/docs/vagrantfile/#load-order-and-merging
In a nutshell: Vagrant loads multiple Vagrantfiles in a specific order, and merges their configurations. The box Vagrantfile is loaded as part of this process prior to the root Vagrantfile (the one from vagrant init).
There is no way currently to make a skeleton Vagrantfile that is generated with vagrant init.
The configuration you put in the packaged Vagrantfile, such as port forwards, should be loading in properly, since when merging configurations, it should just append all the port forwards.
If this isn't happening, you should report a bug! But for the sake of a SO answer, this is how things are supposed to behave.
This code worked for me
vagrant package --output vagrant_example.box