In my Vagrant environment I have a guest Ubuntu Virtualbox with a LAMP with default settings.
I have my source code on the host machine in the same folder as my Vagrantfile. So on the guest Ubuntu I can access the files in the mounted /vagrant dir like this
/vagrant
/mysite
/index.php
/Vagrantfile
Now in my Apache config I add a line
Alias /mysite /vagrant/mysite
After reloading config and restarting apache I can go to localhost:8558/mysite/index.php and it works.
The problem is that when I reload Virtualbox with vagrant reload it starts Apache service before mounting the /vagrant folder. So Apache can't find the aliased dir and fails to start. i have to start it manually then
My question is - is there a way to delay Apache start so that it starts after the mounting?
Update: As a workaround I added script to the crontab that starts apache 30 seconds after the boot as described here. But I wonder if there is a better solution.
while upstart probably is a valid option, I had several issues using it with vagrant. I had to run several tasks that needed to be run as a privileged user, which I did not manage to get working with upstart.
Starting from version 1.6.0 (May 6, 2014), vagrant provides the option to run a specific provisioner every time, so also after booting a halted VM with vagrant up.
In your Vagrantfile, add:
# a file, eg after-boot.sh
config.vm.provision "shell", path: "after-boot.sh", run: "always"
# or just inline
config.vm.provision "shell", inline: "service apache2 restart", run: "always"
note the run: "always", this will force vagrant to run the provisioner always, obviously it works just as well with any other provisioning system like chef or puppet.
I would like to add a little to Zauberfisch's answer (Apache fails to start on Vagrant)
What needed to happen was this command needed to be run as a superuser AKA 'Sudo' so this was the command that was needed:
`config.vm.provision "shell", inline: "sudo service apache2 restart", run: "always"`
The reason why this didn't work for you without the sudo appears to be that Vagrant tries to run the command without /usr/sbin in PATH. For me, this worked just as well:
`config.vm.provision "shell", inline: "/usr/sbin/service apache2 restart", run: "always"`
If upstart is installed (as in Ubuntu), Vagrant emits "vagrant-mounted" event. See https://serverfault.com/a/568033/179583 to get the idea. In your script you can (re)start the Apache server.
Btw, I have a feeling that newer Apache versions just warn, but still start even if the doc root doesn't exist. The same with nginx.
Related
We have VirtualBox (using vagrant) env , by mistake made an entry in /etc/security/limits.conf [with out having a root shell open:( ] and now I am unable to ssh (the connections drops immediately).
Previously we had one such scenario (limits done by someone else) , was able to fix using vboxmanage guestcontrol copyto CLI and was able to overwrite limits.conf and then ssh was allowed, this time around the vboxmanage CLI also hangs
Tried to open the VM in GUI and went to console and tried few options , but could not get to single user mode.
Since you already tried vbox cli command and the commands hang, it means even virtualbox cannot access the system or get a shell to open.
In this case you will have to bring up a ubuntu VM and use the qemu-nbd module to fix this. The steps are given below.
Bring up a very simple ubuntu vm using hashicorp’s bionic64 on the same host machine by executing the following steps.
mkdir bionic
cd bionic
vagrant box add hashicorp/bionic64
vagrant init
Open the Vagrantfile and change the config.vm.box = "base" to config.vm.box = "hashicorp/bionic64"
Also mount the folder in the host where the .vdi file for the VM is located by adding the following to the Vagrant file by adding the following line(replace the file path with the correct one corresponding to your system. Here /nbd2 will be created on the ubuntu machine and will contain the files including the .vdi file.
config.vm.synced_folder "/home/topcat/VirtualBox\ VMs/your_vm", "/nbd2"
Now do vagrant up
Once the machine boots up
vagrant ssh #to ssh as vagrant
sudo su #to become root
apt-get update #This will refresh the apt cache
apt-get install qemu
modprobe nbd (to check if the module is loaded successfully. Will exit without any output if it is installed)
qemu-nbd -c /dev/nbd1 "/nbd2/box-disk001.vdi" - (Here change the path to whatever you gave in the config.vm.synced_folder property)
mkdir -p /mnt/vdi-boot
mount /dev/nbd1p1 /mnt/vdi-boot
cd /mnt/vdi-boot/etc/security (This folder will have all the files as it were in your VM)
touch limits.conf (if the file is already there, delete it)
chmod 644 limits.conf
chown root:root limits.conf
open the /mnt/vdi-boot/etc/security/nsswitch.conf file and check if the following three lines are present
passwd: files
shadow: files
group: files
umount /mnt/vdi-boot (unmounts the mounted path)
qemu-nbd -d /dev/nbd1 (disconnects from qemu-nbd)
Exit the VM and start the VM
Open another shell and try to ssh. It should go through fine this time.
Host OS: Windows 10
Vagrant: 2.2.4
VirtualBox: 6.0.6 r130049
When I run vagrant up, it prints this error message:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
setup
Stdout from the command:
Stderr from the command:
bash: line 4: setup: command not found
The machine can be booted normally and SSH from my host to Virtual machine is OK but the synced folder is not working. I know this may not be a critical issue but still feel frustrated as I use my host machine to develop codes and "sync" these codes so that they can be loaded in my virtual machine.
Any advice is highly appreciated.
ps: When I boot a full UI virtual machine (different from my above mentioned) from my VirtualBox directly, it seems OK to have a "sync" directory and the VBGuestAdditions can be installed without errors.
It is a bug in VirtualBox 6.0.6 and it still exists in 6.0.8. The solution is to downgrade your VirtualBox itself and the Guest Extensions to 6.0.4.
I have a vagrant box with CentOS7 running under KVM/QEMU (libvirt) on my Fedora 29 host. vagrant up works fine. vagrant ssh fails with:
/usr/share/vagrant/gems/gems/vagrant-2.1.2/lib/vagrant/util/safe_exec.rb:39:
in `exec': : Permission denied - /home/username/bin/sshPermission denied - /home/username/bin/ssh ( (Errno::EACCESErrno::EACCES)
The doc says: Vagrant will attempt to use the local SSH client installed on the host machine. However, which ssh correctly results in: /usr/bin/ssh. So why vagrant doesn't use it ?
The directory! /home/username/bin/ssh was included in the PATH env when the box was created and vagrant seems to have stored this information somewhere. Removing the directory from PATH didn't help. Only when I rename or remove the directory vagrant ssh does work.
Can anyone tell me where vagrant stored the wrong info ?
Edit: The Vagrantfile is nearly empty, only config.vm.box contained...
Guess I found the reason - seems to be a bug or strange behavior of the vagrant version 2.1.2 that I use:
I still had directory /home/username/bin in the PATH env. Vagrant seems to list all entries in all directories included in PATH to look for ssh and finds subdirectory /home/username/bin/ssh not realizing that this is a directory ...
After removing /home/username/bin the command vagrant ssh works as expected. So unless vagrant is improved I have to permanently rename my /home/username/bin/ssh directory ...
EDIT6: submitted an official path bug: https://github.com/mitchellh/vagrant/issues/7512
EDIT5: When I do vagrant destroy and vagrant up, everything works easily. But when I turn off the VM and turn it back on (you have to restart your PC some day), it won't work again. Either the sequence for vagrant up when the VM is created is bugged or VirtualBox is bugged. Destroying and rebuilding the VM is not the option, cause the DB migration and everything takes ~30 mins at least. Either way, DON'T USE VAGRANT ON WINDOWS 10.
EDIT4: I downgraded to Virtual Box 5.0.0.10, that fix the wrong path problem, but the error Command not in installer persists.
EDIT3: When I went into vagrant up --debug, I found out that it cycles. It gets into line
INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "8aaee3a3-806f-4
8ad-9928-91e2b7baba5d", "--machinereadable"]
and then it does
INFO subprocess: Command not in installer, restoring original environment...
The path to VM uses forwards slashes instead of backslashes. Is this a bug? Is there a way to manually set path to VM? I have put C:\Program Files\Oracle\VirtualBox in my PATH.
EDIT2: DON'T USE VAGRANT ON WINDOWS 10, it's bugged in many ways, also VM is not optimalized for win10 yet, you'll get bunch of issues that you won't be able to solve. Also tried the Otto from Hashicorp, not working either. Rip.
EDIT: okay, so when I do vagrant destroy and vagrant up, after 10 minutes of installation it works like a charm. But after I restart my PC or logout in any way, Vagrant is unable to connect to the VM, neither with a private key, nor with login/password. Is that a bug?
When I do vagrant up, VM starts properly, but Vagrant is unable to connect. All it says is Warning: Remote connection disconnect. Retrying...
When I try to connect via vagrant ssh, I get only ssh_exchange_identification: read: Connection reset by peer. When I check GUI of the VM, it is waiting for login, and when I login with defult login/password, it is working as intended, so the problem must be Vagrant not being able to connect to the VM.
I tried:
checking if my pc supports virtualization and checking if it is on
trying to connect with password instead of a key
configuring networking adapetrs
turning off firewall
clean reinstall
I am using Vagrant 1.8.1 and VirtualBox 5.0.20 on Windows 10.
This is my vagrant file:
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.provider :virtualbox do |vb|
vb.memory = 2048
vb.gui = true
vb.cpus = 2
end
config.vm.network :private_network, type: "dhcp"
config.vbguest.auto_update = false
config.ssh.insert_key = false
config.vm.provision :shell, path: "bootstrap.sh"
end
[Edit 17/06/2016]
The problem should be resolved with Virtualbox 5.0.22.
https://www.virtualbox.org/wiki/Changelog
https://www.virtualbox.org/ticket/15412
[Original answer below]
In contrast to my earlier answer I now don't think that I encounter the same problem as you have described here. However I still think that you encounter a different variation the problem.
As of feedback received from Virtualbox development https://www.virtualbox.org/ticket/15412 I learned that Virtualbox 5.0.20 includes changes to the NAT Forwarding Rules to address other bugs. When a VM is saved and started again, Virtualbox now removes the network cable for 5 seconds. This is supposed to trigger the DHCP client to request a new lease. This information in turn is then used by Virtualbox to infer the IP address and NAT should work.
In my particular case I encounter this problem with Ubuntu 16.04 as guest VM whereas with Ubuntu 14.04 it works. This indicates to me that the DHClient on Ubuntu 14.04 does request a new lease after the cable was disconnected by Virtualbox whereas this is not the case with Ubuntu 16.04.
In order to verify that you encounter the same problem, I wonder if you could run the below test and let me know.
Login to the Trusty VM console (i.e. the one that you get displayed when you run the VM in the foreground)
Install 'arping' (sudo apt-get -y install arping)
Create the below script 'sendARP.sh'
#!/bin/bash
IFACE=$(ifconfig | grep 'Link encap:Ethernet' | awk '{print $1}')
IP=$(ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1')
arping -c 1 -i $IFACE $IP
Make it an executable 'chmod +x sendARP.sh'
Save the Trusty VM (vagrant suspend)
Start your Trusty VM from saved state (vagrant up)
Login to the Trusty VM console (i.e. the one that you get displayed when you run the VM in the foreground)
Run the script 'sudo ./sendARP.sh'
Test whether you can connect via SSH from the remote location/ Virtualbox host
Bugs:
https://github.com/mitchellh/vagrant/issues/7306
https://www.virtualbox.org/ticket/15412
I recently tried to install a VM with vagrant but "vagrant up" always failed with the error:
Mounting NFS shared folders failed. This is most often caused by the NFS
client software not being installed on the guest machine. Please verify
that the NFS client software is properly installed, and consult any resources
specific to the linux distro you're using for more information on how to
do this.
NFS client was properly installed on my machine so I looked for other causes of errors and found a blogpost explaining that my /etc/exports might be corrupted. I restored exportsbak (which contains only commented examples), hoping that vagrant would reconfigure that file properly... but it doesn't, and the error is still there.
How can I force vagrant to regenerate that file or fix it? Thanks.
Just delete the file.
sudo rm -f /etc/exports
The file will be recreated during the vagrant up process.
I was not able to get nfs running on my Ubuntu, because I used the vagrant packages from apt (V 1.2.2)
I installed the latest Vagrant Version (1.5) from here: http://www.vagrantup.com/downloads
and nfs worked.
Check the NSF server is not installed, you can do…
dpkg -l | grep nfs-kernel-server
If it is not installed, install the required packages…
apt-get install nfs-kernel-server
apt-get install nfs-common
service nfs-kernel-server restart
sudo service portmap restart
mkdir -p /var/exports
Then in Vagranfile add line under #shared folders...
config.vm.synced_folder "www", "/var/www", :nfs => { :mount_options => "dmode=755","fmode=755"] }
When vagrant is starting it will ask for root password, to run it without root password you can edit /etc/sudoers and add following lines…
Cmnd_Alias VAGRANT_EXPORTS_ADD = /usr/bin/tee -a /etc/exports
Cmnd_Alias VAGRANT_NFSD_CHECK = /etc/init.d/nfs-kernel-server status
Cmnd_Alias VAGRANT_NFSD_START = /etc/init.d/nfs-kernel-server start
Cmnd_Alias VAGRANT_NFSD_APPLY = /usr/sbin/exportfs -ar
Cmnd_Alias VAGRANT_EXPORTS_REMOVE = /bin/sed -r -e * d -ibak /etc/exports
%sudo ALL=(root) NOPASSWD: VAGRANT_EXPORTS_ADD, VAGRANT_NFSD_CHECK, VAGRANT_NFSD_START, VAGRANT_NFSD_APPLY, VAGRANT_EXPORTS_REMOVE
if your host is Windows, then you need to install a vagrant plugin Vagrant WinNFSd.
$ vagrant plugin install vagrant-winnfsd