How do I get files onto my vagrant ubuntu virtual box? - linux

I have installed a copy of ubuntu/trusty32 box on my vagrant setup on my laptop.
I now want to now be able to copy files from my laptop into the virtual ubuntu box that I created and see them in my browser. How can I do this?
Here is my Vagrantfile:
# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
# The most common configuration options are documented and commented below.
# For a complete reference, please see the online documentation at
# https://docs.vagrantup.com.
# Every Vagrant development environment requires a box. You can search for
# boxes at https://atlas.hashicorp.com/search.
config.vm.box = "ubuntu/trusty32"
# Disable automatic box update checking. If you disable this, then
# boxes will only be checked for updates when the user runs
# `vagrant box outdated`. This is not recommended.
# config.vm.box_check_update = false
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine. In the example below,
# accessing "localhost:8080" will access port 80 on the guest machine.
# config.vm.network "forwarded_port", guest: 80, host: 8080
# Create a private network, which allows host-only access to the machine
# using a specific IP.
config.vm.network "private_network", ip: "192.168.10.11"
# Create a public network, which generally matched to bridged network.
# Bridged networks make the machine appear as another physical device on
# your network.
# config.vm.network "public_network"
# Share an additional folder to the guest VM. The first argument is
# the path on the host to the actual folder. The second argument is
# the path on the guest to mount the folder. And the optional third
# argument is a set of non-required options.
# config.vm.synced_folder "../data", "/vagrant_data"
# Provider-specific configuration so you can fine-tune various
# backing providers for Vagrant. These expose provider-specific options.
# Example for VirtualBox:
#
# config.vm.provider "virtualbox" do |vb|
# # Display the VirtualBox GUI when booting the machine
# vb.gui = true
#
# # Customize the amount of memory on the VM:
# vb.memory = "1024"
# end
#
# View the documentation for the provider you are using for more
# information on available options.
# Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
# such as FTP and Heroku are also available. See the documentation at
# https://docs.vagrantup.com/v2/push/atlas.html for more information.
# config.push.define "atlas" do |push|
# push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME"
# end
# Enable provisioning with a shell script. Additional provisioners such as
# Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
# documentation for more information about their specific syntax and use.
# config.vm.provision "shell", inline: <<-SHELL
# sudo apt-get update
# sudo apt-get install -y apache2
# SHELL
end
I can confirm that when I call 192.168.10.11 in my browser, I can see the default Ubunti holding page - I just need to be able to add my own files.
Can anyone help?

SYNCED FOLDERS
Synced folders enable Vagrant to sync a folder on the host machine to the guest machine, allowing you to continue working on your project's files on your host machine, but use the resources in the guest machine to compile or run your project.
By default, Vagrant will share your project directory (the directory with the Vagrantfile) to /vagrant.
Read the basic usage page to get started with synced folders.
refer: SYNCED FOLDERS

Related

nameservers update differently with openconnect and openconnect-gnome in ubuntu 18.04

This seems to be a new issue with network-manager-openconect-gnome in Ubuntu 18.04+
I install sudo apt install network-manager-openconnect-gnome to get gnome integration with opeconnect and Cisco AnyConnect Compatible VPN (openconnect)
As an aside (which may actually be relevant) I do this to get *.local addresses to resolve:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf as per systemd docs
Move dns before mdns4_minimal in /etc/nsswitch.conf
If I connect to the VPN with openconnect through the gnome network manager, VPN addresses (sites for work) do not resolve. Regular sites continue to work as expected.
If I connect to the VPN with openconnect on the command line with sudo openconnect vpn.mycompany.com, VPN addresses (sites for work) do resolve. Regular sites continue to work as expected.
I thought I would check to see if there were any differences between /etc/resolv.conf with each of these VPN connection methods and sure enough, there is one:
openconnect on the command line (working):
##VPNC_GENERATED# -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.10.10.10
nameserver 10.10.10.11
search broadband mycompany.com
openconnect gnome integration (not working):
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.1.1
nameserver 10.10.10.10
nameserver 10.10.10.11
search broadband mycompany.com
If I remove (or comment out) the nameserver 192.168.1.1, which is the difference in content between the working and not working files... everything works as expected. I can resolve addresses within the company and regular sites work as expected.
This does not happen with Fedora. Everything works out of the box. I'm not sure why the network-manager-openconnect-gnome package works differently or if there's a way I can make it work without either
Editing the file by hand.
Using the openconnect tool from the command line and keeping a terminal open running that command.

Setting the ip of a RHEL box from a Vagrant script

I have a RHEL image already preconfigured, I don't know how it was originally setup.
By default, it is configured with a local network interface on the ip 192.168.50.50. What I am trying to do is configure its ip from the Vagrant script.
This doesn't seem to do anything:
config.vm.network "private_network", ip: "192.168.50.10"
This does change the ip:
sudo nmcli con mod bond0 ipv4.addresses 192.168.50.10/24
service network restart
But after that apparently Vagrant doesn't automatically detect the ip to connect to, so I need to add:
config.ssh.host = LOCAL_IP
But here's the problem: on the first time, the ip is the default one (.50.50). So I can't already set config.ssh.host to my desired ip. If I omit the config.ssh.host line, it runs the first time but not after, and vagrant ssh fails as well.
Is there a way to set the box ip without editing the Vagrant script between the first and second vagrant up?
Edit: Result of vagrant up --debug command: http://pastebin.com/BTccc4NT
Edit: The problem was that the Vagrant file from the default box (on Windows, it's at C:\Users\user\.vagrant.d\boxes\nameofbox\virtualbox\Vagrantfile) itself had this line:
config.vm.network "private_network", ip: "192.168.50.50", auto_config: false
hum, its weird, it creates 2 interfaces
DEBUG network: Normalized configuration: {:adapter_ip=>"192.168.50.1", :auto_config=>false, :ip=>"192.168.50.50", :mac=>nil, :name=>nil, :netmask=>"255.255.255.0", :nic_type=>nil, :type=>:static, :adapter=>2}
INFO network: Searching for matching hostonly network: 192.168.50.50
INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "list", "hostonlyifs"]
......
DEBUG network: Normalized configuration: {:adapter_ip=>"192.168.50.1", :auto_config=>true, :ip=>"192.168.50.10", :mac=>nil, :name=>nil, :netmask=>"255.255.255.0", :nic_type=>nil, :type=>:static, :adapter=>3}
INFO network: Searching for matching hostonly network: 192.168.50.10
INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "list", "hostonlyifs"]
so on on adapter2 you have 192.168.50.50 and on adapter3 you have 192.168.50.10
The possible reason for this is that the box you're using has a specific Vagrantfile which defines already a network on the static address.
I am not fully familiar with windows but on mac, the box definition is under ~/.vagrant/boxes/<yourbox>/<theprovider>/Vagrantfile (note this is not the Vagrantfile from your project, this is really a Vagrantfile which will be applied to any VM built from this box); check the file and remove the network configuration if you see it
As documented the Vagrantfile are merged from the different locations
At each level, settings set will be merged with previous values. What this exactly means depends on the setting. For most settings, this means that the newer setting overrides the older one. However, for things such as defining networks, the networks are actually appended to each other. By default, you should assume that settings will override each other. If the behavior is different, it will be noted in the relevant documentation section.
so by default Vagrant will create additional network interface and will not replace the one coming from the box Vagrantfile.

Timeout while waiting for the machine to boot!! Vagrant-Virtualbox

I have gentoo(linux) host machine. On which, I have Virtualbox 4.3.28 and vagrant 1.4.3 installed(these are the latest available version for gentoo).
On vagrant up, the Ubuntu 14.04 gets launched. I'm also able to ssh to Ubuntu. But then as soon as it gets launched I get the following error. Below is my Vagrantfile and output error.
P.S I have created Ubuntu 14.04 base box from scratch
-----------Vagrantfile-------------
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "Ubuntu"
config.vm.boot_timeout = "700"
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
end
-----------Output in terminal------------
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
**
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period. This can
mean a number of things.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.**
Any solution to fix this problem?
P.S I have created Ubuntu 14.04 base box from scratch
That could be the missing piece - When you package a box, you need to run a few commands as explained below
It is very common for Linux-based boxes to fail to boot initially.
This is often a very confusing experience because it is unclear why it
is happening. The most common case is because there are persistent
network device udev rules in place that need to be reset for the new
virtual machine. To avoid this issue, remove all the persistent-net
rules. On Ubuntu, these are the steps necessary to do this:
$ rm /etc/udev/rules.d/70-persistent-net.rules
$ mkdir /etc/udev/rules.d/70-persistent-net.rules
$ rm -rf /dev/.udev/
$ rm /lib/udev/rules.d/75-persistent-net-generator.rules
Can you make sure to run the command above before packaging the box.

Setting up a local.host alias for localhost on windows

I'm trying to setup everyauth for my node app. Although I've reached a step that I have no idea how to accomplish.
It's asking to setup local.host as an alias for localhost, but it references some linux folders, I'm using windows.
Here's the exact instructions I'm stumped on.
Important - Some OAuth Providers do not allow callbacks to localhost, so you will need to create a localhost alias called local.host. Make sure you set up your /etc/hosts so that 127.0.0.1 is also associated with 'local.host'. So inside your /etc/hosts file, one of the lines will look like: '127.0.0.1 localhost local.host'
(source here)
How do you accomplish this on windows?
This can be done by editing you hosts file. Open notepad++ (or notepad) as admin. Then hit open, and select C:\Windows\System32\drivers\etc\hosts. You will see:
# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# ...
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
::1 localhost
And add this line at the end:
127.0.0.1 local.host
Save and you're done
Regarding the answer (Add the entry to your HOSTS file)
This does not work entirely on Windows 10, Windows Server 2019. You CAN PING the new alias (ping local.host), but it you try to use it in windows explorer (\local.host), you get a login prompt that will always fail. Check the EVENT viewer and you will see:
Audit Failure ... A privileged service was called. . . .
C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe
Service Request Information: Privileges: SeTcbPrivilege
I've found no way around this.
So the answer is technically correct, but may not work in all cases.

Synced folders lost when rebooting a Vagrant machine using the Ansible provisioner

Vagrant creates a development environment using VirtualBox and then provisions it using ansible. As part of the provisioning, ansible runs a reboot and then waits for SSH to come back up. This works as expected but because the vagrant machine is not being started from a "vagrant up" command the synced folders are not mounted properly when the box comes back up from the reboot.
Running "vagrant reload" fixes the machine and mounts the shares again.
Is there a way of either telling vagrant to reload the server or to do all the bits 'n bobs that vagrant would have done after a manual restart?
Simply running "sudo reboot" when SSH-ed into the vagrant box also produces the same problem.
There is no way for Vagrant to know that the machine is being rebooted during the provisioning.
If possible, the best would be to avoid rebooting here altogether. For example kernel updates should be already done when building the base box.
Another easy (but not very convenient) way is to handle it with log output or documentation, or with a wrapper script which invokes vagrant up && vagrant reload.
And finally, you could write a plugin which injects all the needed mounting etc. actions to Vagrant middleware stack after the provisioning, but you would still need to think how to let the plugin know that the machine has been booted. Other challenge is that this easily gets provider specific.
You should be able to add the filesystems to /etc/fstab to mount on boot.
Here's my example:
vagrant /vagrant vboxsf defaults 0 0
home_vagrant_src /home/vagrant/src vboxsf defaults 0 0
home_vagrant_presenter-src /home/vagrant/presenter-src vboxsf defaults 0 0
Your vagrant directory should have a .vagrant hidden directory in it, and in there you should find a path to the "synced_folders" file (in my case: /vagrant/.vagrant/machines/default/virtualbox/synced_folders).
That file should help you figure out what the labels are and their mount points:
{"virtualbox":{"/home/vagrant/src":{"guestpath":"/home/vagrant/src","hostpath":"/home/rkomorn/src","disabled":false,"__vagrantfile":true},"/home/vagrant/presenter-src":{"guestpath":"/home/vagrant/presenter-src","hostpath":"/home/presenter/src","disabled":false,"__vagrantfile":true},"/vagrant":{"guestpath":"/vagrant","hostpath":"/home/rkomorn/vagrant","disabled":false,"__vagrantfile":true}}}
It's not the easiest to read but, using python terminology, the labels appear to be the inner dictionary's keys, with / translated to _ (eg: the /home/vagrant/presenter-src key became the home_vagrant_presenter-src label).
I'm actually not sure why vagrant doesn't just use /etc/fstab for shared folders but I'm guessing there's a good reason.
Split your provisioners into two separate steps and use the vagrant-reload plugin as additional provisioner between.
Example Vagrantfile:
config.vm.provision "Step 1 - requires reboot", type: "shell", path: "scripts/part1.sh"
config.vm.provision :reload
config.vm.provision "Step 2 - happens after reboot", type: "shell", path: "scripts/part2.sh"
In case anyone else runs into this issue and finds this question like I did here's how I worked around the issue:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "..."
# create a shared folder for the top-level project directory at /vagrant
# normally already configured but for some reason it isn't on these boxes
# https://www.vagrantup.com/docs/synced-folders/virtualbox.html#automount
# http://www.virtualbox.org/manual/ch04.html#sf_mount_auto
config.vm.synced_folder ".", "/mnt/vagrant", id: "vagrant", automount: true
config.vm.provision "shell", inline: "usermod -a -G vboxsf vagrant"
config.vm.provision "shell", inline: "ln -sfT /media/sf_vagrant /vagrant"
# More settings omitted...
end
There's a few parts to this solution:
The first line assigns a specific id of vagrant to the shared folder. This is important because the automatic mount functionality in VIrtualBox uses /mnt/sf_<id> by default. It also mounts the folder at /mnt/vagrant to keep it out of the way. Ideally you'd pick a more obscure location that's present on all of your VMs or just document not to use it there.
The third line creates a symbolic link from the automatic mount location at /mnt/sf_vagrant to the usual place users expect the shared folder at /vagrant.
The second line adds the vagrant user in the virtual machine to the vboxsf group. This is necessary to access files inside /mnt/sf_vagrant because the guest utilities mount the folder with root:vboxsf ownership. They also set appropriate file and directory modes so it works fine in practice but you do need to be a member of the vboxsf group.
This solution has the following benefits:
The mount at /mnt/sf_vagrant is automatically mounted by the virtualbox guest utilities after a reboot so /vagrant should always be available.
It does not require installing plugins or using any outside tools.
It has the following drawbacks:
Potential for unexpected behavior if users find and use the /mnt/vagrant mount. That mount will only be present if the virtual machine was most recently booted / rebooted through the vagrant console client otherwise it will not be present.
It requires a relatively recent version of VirtualBox and Vagrant.
EDIT: Added -T option to ln to avoid the corner case where it creates /vagrant/sf_vagrant as a symlink.
I had a same issue. This is what I had in my /etc/fstab.
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
vagrant_data /vagrant_data vboxsf uid=1000,gid=1000,_netdev 0 0
vagrant /vagrant vboxsf uid=1000,gid=1000,_netdev 0 0
#VAGRANT-END
So if you see fstab entry is still there, all you have to do is run sudo mount -a to trigger mount again. Or you can copy this lines.

Resources