VAGRANT SHARED FOLDERS DO NOT MOUNT - Windows 7 - Vagrant 1.7.4 - Ubuntu 12.04 precise64 - VirtualBox 5.0.10 with Guest Additions - django

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.

Related

Installed package disappear on Google Cloud VMS instance

so I have installed some python nltk libraries (pip3 install) and c++ libraries (via apt-get install package_name_xxxx) on two different VMS instances.
Python packages for nltk would disappear and require a reinstall after reboot or change of the vms instance (e.g., add memory, cpu core),
C++ libraries disappeared without rebooting or any change of the machine. I do not find anything in the systemlog, a reinstall with apt-get works fine. But I am trying to figure out why it happens.
Is your GCE instance a preemptible instance? this option restarts the instance once every 24 hours and could be the reason why you are missing some packages.
After about an hour of inactivity, modifications not within the $HOME directory are lost. This includes installed packages.
See Custom installed software packages and persistence and usage limits.

How to uninstall Redash

My current installation of Redash is somehow corrupted (installing it in a new PC worked fine so I know my local copy is broken), and I want to basically remove it fully and install it again.
I cannot find any documentation of how to uninstall it,
I don't find it installed as a service
I don't find it installed as a application
So how do I reinstall it???
Deleting the redash installation folder will uninstall the redash but if your installation executable is damaged then reinstalling it again alone might not help.
Check if you have any errors with your supervisor demon:
This supervisor demon is automatically started on port number 9001 on your local machine.
Go to http://127.0.0.1:9001/ and see if all the services/workers are up.
If there are any errors post back the log here.
Check if redash has created dir - /opt/redash/, Remove it if exists.
Run this bash for re-install - https://github.com/getredash/redash/blob/master/setup/ubuntu/bootstrap.sh

Vagrant + Chef: Error in provision "Shared folders that Chef requires are missing on the virtual machine."

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.

Cannot connect icecream (icecc) on Fedora

I can't manage to get an icecc daemon to connect to the local icecc-scheduler from any machine running Fedora 20.
I've had no issues setting this up on 5 different Ubuntu 14.04 machines, and each can run the scheduler with no issue. In fact, it appears to work out of the box with no additional config on Ubuntu - simple install and play.
In those cases on Ubuntu
sudo apt-get install icecc
sudo service iceccd start
And on one of the machines
sudo service icecc-scheduler start
Then simply setting the path and building like so
export PATH=/usr/lib/icecc/bin:$PATH
make -j16
This is all that is needed to get the distributed compile working on Ubuntu as far as I can see.
On Fedora installing and starting I use
sudo yum install icecream.x86_64
sudo systemctl start iceccd
And compiling with
export PATH=/usr/libexec/icecc/bin:$PATH
make -j16
This doesn't distribute the compile.
The icemon utility on the scheduler does not show any evidence of the fedora machine either and running a status on the iceccd service gives this error:
Jul 21 09:44:08 Fedora20 iceccd[4642]: [4642] 09:44:08: scheduler not yet found.
So far the only thing I've tried that might have been the issue is opening up the ports that the readme provides by adding them to the Zones->Ports part of Firewall Configuration , but this hasn't helped.
Maybe there is something I need to do on the Ubuntu schedular and daemons? Has anyone else had any luck with setting up icecream on Fedora 20?
For other future devs who might come here from google -
To get icecc working I edited the /usr/lib/systemd/system/icecc/iceccd-wrapper file by adding two arguments to the iceccd command.
-s <schedular> -m <number of jobs>
Then when running the following command
sudo systemctl start iceccd
The daemon starts up and is seen by the scheduler.
Remember the ports also need to be open!
Instead to editing either /usr/lib/systemd/system/icecc/iceccd-wrapper (like proposed by foips) or /usr/lib/systemd/system/iceccd.service itself, I found it more convenient to modify global icecream settings file /etc/sysconfig/icecream and set
# If the daemon can't find the scheduler by broadcast (e.g. because
# of a firewall) you can specify it.
#
ICECREAM_SCHEDULER_HOST="<scheduler>"
On Ubuntu 20.04 with ICECC 1.3.1 the config file is /etc/icecc/icecc.conf and the setting is called ICECC_SCHEDULER_HOST. You need to put the scheduler IP there.

Vagrant / Virtualbox, shared folder out of sync when there are many file-related operation

This is not about vagrant or virtualbox guest running slowly due to slow shared folder access, we know that can be resolved more or less by enabling nfs.
It's rather about mounted shared folder go out of sync when there are many file operations within the vm (enable nfs does not prevent it from happening) .
For example, when we are installing packages, like with php composer or node.js npm inside the vm, there is a certain probability that normal composer update or npm install will fail, and once it failed, only vagrant reload will help to restore the sync folder and allow the same command to pass without problem.
Such random failure only happens when executing on shared folder (nfs or not), so apt-get upgrade won't trigger the same problem as it runs within the vm folders.
Since the same sync problem does not appear when we run composer or npm from the host server, I am wondering what could have caused it and how do we go about debugging it?
Our vagrant setup and config:
if Vagrant::Util::Platform.windows?
config.vm.synced_folder "www", "/var/www", :extra => "dmode=777,fmode=777", :owner => "vagrant", :group => "vagrant"
else
config.vm.synced_folder "www", "/var/www", :extra => "dmode=777,fmode=777", :nfs => true
end
Guest: Ubuntu 12.04 LTS x64
Host: Windows 8, Mac OSX 10.8, Ubuntu 13 (yes, they all run into the same problem randomly)
Think we have more or less discover the source of problem:
Guest Addition version (4.1.x) that comes with our Ubuntu 12 LTS box does not match current Virtualbox version (4.2.x) installed on host machine. So file sync failed.
The easy fix:
run this command within vm sudo apt-get -y -q purge virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11 to remove old guest addition
install vagrant vbguest plugin so future update is taken care of automatically during up: https://github.com/dotless-de/vagrant-vbguest