Vagrant

This is not an organized tutorial or an overview. This is just
a brain dump that lists some approaches to run Vagrant
under Cygwin on Windoz that I used over time.
You may learn a lot, if you did not do Vagrant and Cygwin.
My primary goal is to take the fear from trying Vagrant.
If you follow the instructions, you will not be surprised or stuck
since I provide a lot of details. If you are an expert,
do not bother reading by this point. If you liked it,
make a link to it on your site, or mention it in some blog, so
more people have a chance to read this thing.

This write-up is specifically for using Vagrant and
VirtualBox with Cygwin and Windows7. The keyword here
is Cygwin, a Unix type environment under MS Windows.
I love
Cygwin since it helps me keep my sanity when
I work on Windoz (I worked mostly with Unix/Linux).
It can help you too, if you think that Linux/Unix
is a better development environment than Windoz.
VirtualBox is a software that runs a Virtual Machine
inside your host operating system (here Windoz).
The Vagrant
is the tool that lets you interact with VirtualBox
in a consistent way through simple command line instructions.

Vagrant is hyped a lot, but it is extremely useful.
It was released in 2010 and is still under active development
and hard to chase.
You could call Vagrant a Virtual Machine Manager.
It provides you with an easy way to run a Virtual Machines
of your choice inside the host operating system, like running
a Linux guest inside Windozhost. It also provides
an easy (easier, this stuff is not easy) way to configure
them. There are some competitors, but Vagrant gives you a lot
of flexibility to create tailored
and highly customized guest systems
(this is called provisioning).
Moreover, you can run several of these guest systems inside your
host machine (of course, you will need memory and processor power)
and mimic your production environment, like database server, web server,
code repository, etc.) with their respective versions of operating
systems, installed software and custom packages.
It is especially useful to model accurately
your production environment within your Desktop PC. You do not
need a separate development servers, development databases,
etc., and compete with
other members of your team for resources. You cannot mess up anything
inside your company servers (unless you try really hard), and if something
did not work, you can easily destroy these guest systems and start
from scratch. You can run these things
inside your laptop and work from home without being affected
much by the speed or security of the network.
Of course, creating the fairly accurate
rendition of your existing production environment may
require some practice and experience with the
provisioning frameworks like
Puppet
and/or Chef.
Learning these things is a good investment, since creating a
box, after you provisioned it, takes
minutes, and you can modify the current box
by tweaking a few lines.
After writing the recipes (provisioning scripts) that create the guest
boxes each time in exactly the same way, you can share it
with your team.
Of course, you can also modify the boxprovisioned by someone else.
But you can start modestly.

You do not have to be an eagle to run Linux inside your Windoz,
since the default Vagrant installer comes preconfigured with the
Ubuntu guest that will run within the
Windozhost and you can be up and
running within an hour (they say minutes, but trust me, an hour).
Yes, you could do it without Vagrant
but you would really have to know intrinsics of the utility
(in our case the VirtualBox from Oracle) that runs
these guestVirtual Machines on your host.

Vagrant and Cygwin

Not so long ago, the Vagrant, Cygwin
and Git did not play together,
since Vagrant was installed with Ruby Rails and
Git was also installed on Windows with Ruby Rails.
And you had a problem with using them from Cygwin. I am not
a great admirer of Ruby and its siblings. This environment
is quite unstable since there are too many cooks. But maybe
there is no other alternative at this point (but IMHO there is: Java).
The problem is that Windoz is a strange Operating System.
The file paths are represented in Cygwin and the Windoz
differently.
The guys who developed Unix were savvy computer scientists, and they
knew that directories on the disk need to be organized as topological
tree. This structure is easy to traverse back and forth and can be
efficiently searched with a binary search. The people
who hacked the MS-DOS and Windoz out of the CP/M were para-legal
students and came up with disk drive letters (remember the,
A:, B:, C:. Everyone knows A, B, C...
so it seemed familiar to them). Now they are stuck with the backward
compatibility and inefficient file system.

I like Cygwin
(http://www.ccl.net/cca/software/UNIX/cygwin/index.html)
since I am forced to work on Windoz PCs when doing contracts and
Windows is (in my humble opinion) the
most terrible environment for software development. Maybe
Windows for Dummies is great, but for software developers
that develop software for real operating systems, it is a nightmare.
Moreover, the User Interface is for aliens with 3 hands (I was an alien
in a sense of the US Immigration Laws, before I became a US Citizen,
but I never had 3 hands...) and my fingers hurt. I am sure people are getting
the carpal tunnel from using Windows. The X-Window interface
(see: Project Athena for some history and to realize
that it could have been better) was created to be optimal.
The Windoz interface was created to be different, not
better. Marketeers will swamp us with trash,
and the uninformed public will buy
the trash. It is not only Windows... Remember triple clicks with one-button
mouse from Apple? They will do anything to be different and claim that
they discovered something new. And we will buy the crud. Amazing...

Before I installed Vagrant and VirtualBox, I installed
emacs on Windows7 using the HOWTO at:
http://www.claremontmckenna.edu/pages/faculty/alee/emacs/emacs.html.
While I have Cygwin installed and I have emacs there,
I have to shut Cygwin down when I am installing new Cygwin
packages. it is not a good idea to install
new packages for Cygwin when it is running, and the otheremacs is good to have.

Initial Installation

My idea how to approach the Cygwin/Windoz path disparity is
to realize that when you work under Cygwin, you have essentially
two HOME directories. One is obviously the Cygwin's Unix-like
$HOME directory for each user. It is usually placed
under top /home directory. In my case, it is
/home/jkl that on the Windows is located in
C:\cygwin64\home\jkl, since I installed Cygwin
under C:\cygwin64
(you can read my notes on Cygwin installation at:
http://www.ccl.net/cca/software/UNIX/cygwin/index.html).
But Windoz also has a pseudo
HOME that is called. USERPROFILE and
in my case it is located at C:\Users\jkl. Many programs
that run under Cygwin, but were designed primarily for Windoz
get confused, since they look at HOME and
USERPROFILE and do not know what to do. So generally
for those confused creatures, I create links from the Cygwin$HOME directory to the $USERPROFILE directory.
So they can take any of them and will end up in the right place.
You will see it in action soon. The people at Windoz did not offer
Unix type links for a long time, but gave us shortcuts.
Note, shortcuts are not links. Very different things...
shortcuts
were good for Windoz, since they were incompatible with other operating
systems and it helped Windoz sale ("See... It runs on Windows
but does not run on Apple or Linux"). But their finally gave up.
Obviously, if they want to have Windows in the enterprise,
they have to provide some interoperability. So there are
three type of links in Windoz:
soft links (for files and directories), hard links
for files and hard links for directories -- that they call
junctions. They are still different from Unix links
(especially in the context of what can you link with what, and
what is a local partitioin and what is not), but they
are close.
The links are created with the DOS mklink
command within the elevated command prompt (yes,
"Who controls the language, controls the people", read some Orwell
http://en.wikipedia.org/wiki/Politics_and_the_English_Language).

Before installing anything I created directories from Cygwin
in my USERPROFILEWindoz directory. Just typed the following
in the Cygwin's terminal in my Cygwin's $HOME directory:

Then got the elevated command prompt
(which can be translated from the MS New-speak
to: Windows terminal with administrator privileges)
(this is what you do: [Start] -> [All Programs] ->[ Accessories]
-> [Command Prompt], right-click on [Run as administrator]).
Then created junctions, i.e., directory hard links.
In the Elevated Windows Command Prompt that appeared, I typed:

At this point you may ask yourself Does this guy know that you can
create links under Cygwin? The guy knows, but he wants the
nativeWindozjunctions since the VirtualBox
runs on Windoz, not on Cygwin. Why? Because Cygwin may change
its linking methods on the next update, while the Windoz will keep them
compatible with the current software for backward compatibility
reasons.

Before, when I installed my Cygwin, I also created junction
for the Program FilesWindoz folders, namely, in the
Command Prompt window with Admin privileges, I typed:

This simplifies my life a lot under Cygwin (these darned
spaces in file and directory names), since I do not have
to put the stuff inside double quotes in my scripts and

cd /cygdrive/c/Program_Files/Oracle

will work without quotes.

Next, I added the following Environment Variables to Windows (
[Start] -> [Control Panel] -> [System and Security] -> [System],
click on [Advanced system settings], click on
[Environment Variables].
I added them for the root (which is my user that
has admin privileges on Windows) and also to the
System variables in the dialog below below. This is what you should
see:

I know that this is redundant, but Windows and Cygwin have strange ways.

If you are at it, you may want to edit all the
environment variables that have Program Files
and Program Files (x86) to
Program_Files and Program_Files_x86, respectively
(provided that you ran the mklink commands on them as
described above).

You will pretty soon have to change the VAGRANT_LOG=info
to VAGRANT_LOG=warn, since the amount of logging that appears on your
console is unbearable. It is good when you are trying to learn stuff,
but for routine use, this is very annoying.
Vagrant is run in the so called Project Directory. The name
comes from the fact that this is a directory that you will share
between the host and the guest VM (Virtual Machine) and
it is usually the files that you work on for some project.
You will be pushing this diectory to a git repository
(like github) and you will be pulling and fetching the
new stuff from the git repository (or Subversion
or ClearCase).
This is a directory where you will run the vagrant init
and vagrant up commands soon (and a lot of other commands
after you RTFM (Read The Fricken
Manual at:
http://docs.vagrantup.com/v2/cli/).
We will talk about it later.
BTW, the Vagrant people now promise
that I do not have to add Vagrantbin directory to
the Windoz%PATH% since installation process does it.
But, make sure you look at this in the Environment Variables, and that
you fix the damned Program Files with a space embedded.

I created my Project Directory for the default box that comes with
Vagrant installation as:

$ mkdir /cygdrive/c/cygwin64/home/jkl/vagrant_ubuntu

Before installing VirtualBox and Vagrant I rebooted the machine
to make sure that Windoz Environment Variables are known to the Windoz
processes, among them Cygwin.
After reboot I checked that the environment variables show up within
Cygwin:

They will usually download to your WindozDownloads
folder, though I usually save the stuff in a different directory.
When you right click on the VirtualBox installer
VirtualBox-4.3.20-96997-Win.exe and choose [Install]
you are you greeted with the Window:

Then you can choose the installation directory. I left it at default:

Left the Setup unchanged:

Then I got a warning about Network Connections

And finally, I could click on [Install]:

And the installation began:

after I entered my Administrator password.
The last screen asks me to start VBOX after installation. I said
No (this once), since I need to edit something.

Then I started the VirtualBox from the
[Start] -> [All Programs] -> [Oracle VM VirtualBox] ->
[Oracle VM VirtualBox]. The first screen is not interesting:

but the deeply hidden magic happens:
the VirtualBox creates its default configuration directory
on its first run. In my case it was in C:\Users\jkl\.VirtualBox.
I can look at the files through the soft link in Cygwin:

I hate the space in the directory name for defaultMachineFolder
since I would need to use quotes to cd to it. So
I want it to be VirtualBoxVMs. They warn you not to
edit the file by hand (since you can mess up the whole thing
if you do not know XML),
so I used the utility that comes with VirtualBox.
Before I can use it, I need to add the directory with
VirtualBox to the PATH.
I went to the Control Panel... Environment Variables
(you know the drill...), selected Path
under System Variables, then [Edit] and appended the
;C:\Program_Files\Oracle\VirtualBox\
since this is where
the VirtualBox keeps its wares on my physical box.
I also created a VirtualBoxVMs directory in the C:\Users\jkl\

$ mkdir /cygdrive/c/Users/jkl/VirtualBoxVMs

and the MS Windozjunction for it in my Cygwin's
$HOME directory using the
Elevated Command Prompt.

Installing Vagrant

Time to install the Vagrant.

I downloaded Vagrant installer file from the official download page:
https://www.vagrantup.com/downloads. At the time
of this writing it was 1.7.1.
Right clicked on vagrant_1.7.1.msi
in Windoz Explorer and clicked on [Install]:

Accepted the MIT license.
Then changed the default directory from C:\HashiCorp\Vagrant\
to just C:\Vagrant

Then clicked on [Install] that was warning me that I need to enter
the admin password: at some point.

After the progress bar reached its destination, I clicked on
[Finish]

The Vagrant told me that I must restart my computer.

What could I do... I obliged.
After Vagrant is installed
you can also see it in the WindozControl Panel:

So, once again, let refresh our memory where we are at this point.
In my Cygwin's xterm I typed:

The VagrantFile uses simple Ruby syntax.
Some people love Ruby
but I cannot understand why. I personally hate languages that do not use
blocks and you are a hero when you squeeze everything on one line.
Languages like this remind me
of Basic or Fortran 2. Among younger people
they encourage competitions on code obfuscation.
They often think that If I write a code that nobody else can understand,
I am a great programmer! The truth is, that at least for me, you are
a lousy programmer if you do this.

If you wonder what this script thing is, it is a Unix
utility that sends the screen output to a file in the
current directory, namely typescript. Very useful...
Do a man script on it...
The link What vagrant up spewed was created using it.
Now... What really happened is that our guest
Virtual Machine should be running now.
Let us go to VirtualBox box from the Windoz[Start] menu:

Note that the command vagrant init
above (that listed the Virtual Box name
as hashicorp/precise32)
told the vagrant up to download the box
if it cannot be found locally on the computer. If you look at the output of the
vagrant up you will see the stuff being
downloaded. You will also see that the directory
VirtualBoxVMs is no longer empty:

Big VM1!!! file, 1GBytes big...
This is not the box that was downloaded, however. It is
essentially a pseudo hard drive of the VM (Virtual Machine)
that is currently running under the control of
the VirtualBox. The box, i.e., the file that was retrieved
by Vagrant and contains
the Ubuntu image to be run, is actually smaller:

If you want to know what password I chose, it was vagrant,
the same as for the user vagrant. Unsafe? Yes, but at the
same time, the user vagrant can become a root through
sudo. So why bother: my memory is good but short.
Now I can actually su to root
on my VM:

It is now time to read the original Vagrant docs
https://docs.vagrantup.com/v2/getting-started/#.
There are very easy to understand that worries me a bit, since
there are no easy things in this world, and devil is in the details.
They say that you should have a directory on the
guest that corresponds to the
directory on the host system where you typed your vagrant up
command. Indeed, if you do:

that looks familiar.
And this is the same directory that I have on the host,
i.e., ~/vagrant_ubuntu (or
/cygdrive/c/cygwin64/home/jkl/vagrant_ubuntu/ or
C:\cygwin64\home\jkl\vagrant_ubuntu. If you type in
another Cygwin's xterm:

you will get a similar result, beside the fact that Cygwin's
shows the New York time while the virtual Ubuntu shows ZULU
and I will need to change a TZ there.
The files created/modified on either end are visible instantly to the
host and to the guest. In short, the
/vagrant directory on the running VM corresponds
to the Project Directory on the host, i.e., the
directory where you typed the vagrant up.

So, as you see, the Apache Web server was installed and is running
in the VM. However, since the port forwarding was not activated yet,
I cannot access this page with the browser on the Windoz host.
It is served by apache on VM, but ports from VM are not automatically
forwarded to the host OS, or you would have a total mess and
lots of conflicts. I would need to set up
either the port forwarding (easy and more or less safe)
or do the bridging (more complex and can open security holes).
The basic difference is that the port forwardingkinda exports
TCP ports from the VM to the host OS and the host does also the
Network Address Translation (NAT), while bridging would assign
the VM an IP Address and it would exists on the network like a separate
machine that you can log into from other machines, not necessarily the
host machine. Sometimes bridging is exactly what you need,
but for the newbies the port forwarding is safer since they
are not creating a new IP addresses on the local network and the
security guys will not come and shoot you on spot.

You can also check that the VM can eat all your disk space on the
host OS:

The /vagrant partition that mirrors the
directory where you typed your vagrant init can be
filled with lots of data. It is just a mount, and this disk-space
exists on the host, not on the guest inside the box.
In fact, the VM can fill up
the whole disk on your host OS (the size above corresponds to my
C: drive on Windoz). When I type the same command in the
Cygwin's xterm:

The Vagrant deployed guest behaves
differently than the default
procedure of installing the VM with the Oracle VirtualBox.
The Oracle VirtualBox asks you (by default)
to create a Virtual Disk
and specify the maximum size, and it then creates
a big file on your host that serves a pseudo hard drive
for your guest. Of course, the VirtualBox
allows you to do the same what Vagrant does,
but you would have to take care of many detauls.

The good practice is to log out (ie., end the ssh
connection) with your VM
before you want to shut the VM down, or before you want to shut down your
host computer. If you do not do it, you may have problems starting it later.
At least, this was my experience a few years ago. Maybe they made it
fool proof by now, but I still keep things on the safe side.
You can either do ^D (CTRL/D) in your ssh
terminal, or you can type exit.

While you can shutdown the VM from the VirtualBox
console, I usually do it with
the vagrant halt
in the Cygwin's directory where I started the VM
with the vagrant up (i.e., where the Vagrantfile
for the running VM was created).

Adding another virtual machine

I decided to install another Virtual Machine. I created a directory
under Cygwin to have the latest CendOS (CentOS 7)
running as guest:

$ mkdir vagrant_centos7
$ cd vagrant_centos7

Looked at
https://atlas.hashicorp.com/boxes/search.
This is where you can search for boxes.
I entered centos 7 in the search field at the top.
Then picked up the first one that came out:
vStone/centos-7.x-puppet.3.x Centos 7.x - 64bit - Puppet 3.x .
But I really should not, and should read more about the thing
(what you can
do by clicking on the link:
vStone/centos-7.x-puppet.3.x
where you get more information).

$ pwd
/home/jkl/vagrant_centos7
$ vagrant init vStone/centos-7.x-puppet.3.x
WARN environment: No local data path is set. Local data cannot be stored.
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.
$ vagrant upOutput from vagrant up.

The box did not start by itself and had a lot of errors
as you can see in the link above
Output from vagrant up.

I scrolled down and clicked
[I Agree] since it is a personal and educational
use. But then another thing happened:
The extension Pack can only be installed as Admin.

So I did [File] -> [Exit] in the VirtualBox
and reopened it as Admin (i.e., [Start] ->
[Oracle VM VirtualBox], and right-clicked, and
chose [Run as administrator].
Note that none of my Virtual Machines were running. It probably should not
affect the running machines (since it is only a console), but
who knows... It installed it now.

Clicked on [OK] and tried to start the Centos 7 guest again
by clicking on the
[Start] green ->
at the top.
Now, another surprise... It did not want to start it, since it was aborted
before. So I went to my directory and typed:

$ vagrant up

again. No luck. It bitched...

C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/bin/vagrant:174:in `'
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["showvminfo", "6b53bf55-0995-409c-abf3-7851becf7be2"]
Stderr: VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server
execution failed (extended info not available)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running
or failed to start.

In desperation and in a disruptive mood I typed:

$ vagrant destroy

It took it a lot of time to destroy and then it failed

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["showvminfo", "6b53bf55-0995-409c-abf3-7851becf7be2"]
Stderr: VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server
execution failed (extended info not available)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running
or failed to start.

Rebooted the Windoz, and started from the empty directory
(just did ls -la and then rm each file
and repeated the whole procedure like above

The extensions need to be re-setup for the new kernel.
If I forgot to mention it, be sure that I had run the init.d
script below, when I saw the problems with mounting /vagrant.
You can do it as many times as you need. I will give another example
with another box later in this brain dump.

Seems like we are back in business.
While there is a lengthy discussion about the error:
https://github.com/mitchellh/vagrant/issues/3341
you may always try first to rebuild the extensions after
updating the kernel. Time to install the Apache:

Seems like selinux was not a problem, and I should have seen
it right away, since Apache responded -- I could access the page, and selinux
did not block me. The
reason was different. Usually there was some page under DocumentRoot
in older distributions, but this time there was nothing under
/var/www/html/. So I created a test page:

Obviously, I would like to see this page in the browser on my
Windozhost. We will get to it. Patience... We will also
play with X11 to be shown on the host. Before we do it, I need one
more piece for X11 when I will be playing with it:

We usually start with a base box -- a minimal installation of the
operating system with only basic packages installed. It is usually
a prototype of your future system.
You need
to provision this minimal box by adding additional packages
and by creating directories and changing configuration of the
installed packages.
Initially, you go to the directory (a Project Directory)
that will contain your new Vagrant project.
You will then run a Vagrant's init command, sayvagrant init precise64 http://files.vagrantup.com/precise64.box
It will initialize a new project directory
with a configuration named precise64
and will import a specific box located at the URL provided.
The URL can be an http: in the World Wild Web or
a file: if you downloaded the box already and have it on your
local disk..
The box will be downloaded and stored by Vagrant on your system
where it can find it later. You will be referring to the
box by the name you gave it on the 1st init.

The Vagrant will also create a special Vagrant configuration file
in the project directory, called Vagrantfile.
It will look for this file when you will be starting your
guestVirtual Machine. This file contains
the information how to configure your Virtual Machine and
how your host should interact with it. The
Vagrantfile is written in Ruby language for some reason.
It contains the information about the name of your box and where to get
it, if it is not yet downloaded.

So let us get yet another box. We go to:
https://atlas.hashicorp.com/boxes/search.
I searched for CentOS, sorted by downloads,
and picked up the
nrel/CentOS-6.5-x86_64 Minimal CentOS 6.5 x86_64 base box.
I clicked on link on the left to see details.

Assuming that you placed the file in the
/home/jkl/vagrant_centos_6.5_boxes,
you can use it in the vagrant init command as:
vagrant init nrel/CentOS-6.5-x86_64 file://C:/cygwin64/home/jkl/vagrant_centos_6.5_boxes/CentOS-6.5-x86_64-v20140504.box. For example:

and picked up the box to download and try. Note, since
I am using VirtualBox
(rather than VMWare or some other environments) I am only for a look-up for
boxes to run within VirtualBox) smallhadroncollider/centos-6.5-lamp

Created a URL for box retrieval (for some reason, they keep it secret
and do not give you a direct link to the box):

Since wget
saves a file under the original name in the original url given
I renamed the file to centos-6.5-lamp.box
after download was completed

$ mv virtualbox.box centos-6.5-lamp.box

If you used a browser to download this box file, your file will be
named as centos-6.5-lamp.box since browser renames the
file to the name in the 302 Redirect.
I saved the file to my directory with the box file collection
named: vagrant_centos_6.5_boxes. Then I used this box
saved on my local disk to create a guest under Vagrant.

$ mkdir vagrant_contos_6.5-lamp# Yes, I meant centos, but left it as is
$ cd vagrant_contos_6.5-lamp
$ pwd
/home/jkl/vagrant_contos_6.5-lamp
$ vagrant init vagrant_contos_6.5-lamp \
file://C:/cygwin64/home/jkl/vagrant_centos_6.5_boxes/centos-6.5-lamp.box
WARN environment: No local data path is set. Local data cannot be stored.
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.

and you can see the output
[here]. Now I have 4 boxes running:
Note that each box has its own port for SSH and the vagrant remaps
the original port in Vagrantfile
to the next one that is still not used:

Again, we have a problem with the VirtualBoxExtensions
after upgrading the kernel. Again, there is a problem
mounting /vagrant
directory to represent Project Directory,
i.e., on the /home/jkl/vagrant_contos_6.5-lamp on
the host. What I wanted to say is that the
/home/jkl/vagrant_contos_6.5-lamp directory
cannot be mounted as /vagrant inside the guest
virtual machine.

If you wonder what is the bk command, it is a small script
that I find handy. I keep it in my ~/bin or
even in /usr/local/bin. It just copies the file given as argument to
a file with timestamp appended. Here it is... Use it of loose it...

Now if I point my browser on the host to
http://localhost:12080/ I get:

This box after kernel update had a problem with
mounting Project Directory as /vagrant on the guest.
Before you start messing with this, it is prudent to check that
you have latest jsongem installed, since
Vagrant still uses this thing for some things.

The mount command on the guest depends
on the uid and gid of the user vagrant.
Since this is done during provisioning of the box, different
people give different ids for this user. I saw a 1000
and in our case it is 501. You can check it with these
commands:

id -u vagrant
501id -g vagrant
501getent group vagrant
vagrant:x:501:

when you are logged into the guest. So for the case of
our vcentos_6.5-lampbox the hostProject directory is mounted inside the guest as:

mount -t vboxsf -o uid=501,gid=510 vagrant /vagrant

and you would get an error like:

/sbin/mount.vboxsf: mounting failed with the error: No such device

if VirtualBox extensions are not synced with the kernel.
You need to check if the extensions are used.
See if you have the /opt/VBoxGuestAdditions-Version directory.
For the current box:

See that the port forwarding is now done and the
folder are mounted. There is one more small thing that is
annoying. The guest runs a ZULU time, while
my host runs the EST. The way to fix it, is to link
the proper time zone to the /etc/localtime on the guest.

Now would be a good time to create a few links to a vagrant
directory. Say, I want to use this box to develop a Web site.
The default directory configured with the out-of-the box Apache
where the pages and CGI scripts go, namely:

Then in the Firefox I used the
URL http://localhost:12080/cgi-bin/the_time_is_now to look
at it:

Now, since I put some sweat to make this box updated, it would be good to
save the thing. Note, I am not creating a new box, but I want to
save the current state of the modified box, so when I do
vagrant destroy than I can start afterwards
from the version that worked last,
rather than resume from scratch with the original version that I downloaded
from the internet.

Since yum usually caches the downloaded packages, I want to
delete the cached rpms and other stuff, since it will make the
box smaller. This will not affect future
yum update beside reloading a few files
from the internet.

Now I am theoretically ready to create an updated box
with the Vagrant's vagrant package
command.
Use the vagrant package --help to learn
about the options. The stuff on the Vagrant's Web site
is kinda obsolete and not detailed enough.
The VirtualBox tells me that the VM that is running is:

The project directory has the hidden .vagrant directory
with the information about the current VM:

The UUID Universally Unique Identifier is an important piece
if I wanted to create the box outside the Project Directory as
it is specific for each virtual machine. In our case it is:
2260ead0-7e51-4893-b17d-19c046e83ef7.
I think I double checked everything and now I can stop my VM.

You can only create a box immediately after you up / halt the
machine and in its Project directory, at least it is my experience.
So in the project directory of my freshly halted VM I typed
a command to see what happens (I need to add more arguments later)

$ vagrant package --output /tmp/mynewbox.box
C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:153:in
'action': wrong number of arguments (2 for 1) (ArgumentError)
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:83:in 'package_vm'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:72:in 'block in package_target'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/plugin/v2/command.rb:226:in 'block in with_target_vms'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/plugin/v2/command.rb:220:in 'each'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/plugin/v2/command.rb:220:in 'with_target_vms'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:70:in 'package_target'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:44:in 'execute'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/cli.rb:42:in 'execute'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/environment.rb:301:in 'cli'
from C:/Vagrant/embedded/gems/gems/vagrant-1.7.1/bin/vagrant:174:in '<main>'

Frankly, I did not expect this... Of course, I looked at the command line
and I could not find anything wrong. It was as simple as it can be.
But times have changed since my young age. IBM rushed
the IBM PC with a faulty architecture to the market in 1981 to kill
better offerings from Apple (remember Lisa? It was a pretty
good computer for that time) and other companies. Then IBM signed the
radiculously legally flawed agreement with MicroSoft to deliver
something that will run this thing. And the race to
deliver fast, quick, and dirty software began. The good old fashoined
companies that refused to take part in this race went belly up
(remember DEC?). If you
do not push crap to the market as soon as possible, you are dead.
So I do not blame the Vagrant people for relasing buggy software.
They have to chase the bugs and inventions in Windoz and if
they paid attantion to quality, they would be wiped out.

Note that on the --output option I specified the local
file in the Project Directory. Somehow, from my experience,
whatever else you specify there will get Ruby confused
since Ruby gets very disoriented under Cygwin.
It was supposed to run everywhere but it is buggy and has
problems with Unix paths (I also tried Windoz
paths like C:\\cygwin64\\tmp\\somefile.box) under Cygwin.
It is not big deal, since it is easy to move the file elswhere once
it is created.

The vagrant package did not copy the stuff from the box,
to the host. I probably had to do it with the explicit instructions
in the Vagrantfile but forgot. For the time being, I will just
copy the stuff from the previous directory
in Cygwin's xterm:

So I tried to look at the Web page
http://localhost:12080/cgi-bin/the_time_is_now
again, and it seems to work now
and even shows the right time:

This brain dump starts to look like a book. So... What else
I can share here?. The X11 and ssh.
We were logging into the VM by using the command:
vagrant ssh. What happens is that
Vagrant has its own ssh and logs into the
VM without a password to a vagrant user account.
When they provision the machine, the place the public key
of Vagrant into the /home/vagrant/.ssh/authorized_keys
file on the guest. You can look at this public key by
looking into the authorized_keys file. But my Cygwin
also has its own public key and I should be able to login
to the guest with the Cygwin's ssh and its
public key.

So what I need to do is to append my Cygwin's
id_rsa.pub above to the authorized_keys
file on the guest. You can do it with an editor or
by using Unix shell:cat my_cygwins_id_rsa.pub >> authorized_keysWARNING:
When you are doing this, make sure that you made a backup
of authorized_keys and you are also logged into
your guest on some other terminal. If you mess up your
authorized_keys file on the guest you will not be
able to log into it with vagrant ssh. You have
been warned. Also, the .ssh/authorized_keys need to have
restrictive permissions. After editing do:
chmod 600 .ssh/authorized_keys.
The ssh will not work on the file if anyone but the user
can read it. My
/home/vagrant/.ssh/authorized_keys file on the guest
looked like:

If you can do it, you did not mess up the authorized_keys file
on your guest. You can relax. If it does not work,
copy the backup authorized_keys over your mess-up
and see if you can still get in with vagrant ssh
on some other terminal. I will try to log in from the Cygwin.

But do not copy it, since it is a fake. Now, in case you did not do it
before (I did not...
Oh... No... You need to create updated box again...). you need
to install some yum packages on guest.
You should do it when you are logged in to the guest:sudo yum install xterm xclock xauth
or, if you want a full X11 environment (~100MBytes), dosudo yum groupinstall "X Window System"
On the Cygwin side add the following to the
Vagrantfile in your Project Directory
between the lines Vagrant.configure(2) do |config|
andend
Just cut and paste the following:

The easiest way to show the X11 applications from your
guest on your host is to do the ssh X forwarding.
There are many ways of doing this, but simply adding an -X
option on the command line will do it.

and you should see the xterm and xclock
that are displaying in your
X-Cygwin X server on your Windoz host.

The white stuff comes from guest and the other
stuff is from Windoz (the green xterm
is from Cygwin which
is also Windoz)

Conclusion

If you think it is nonsense, let me know, so I correct it or scrap it.
If you think that it was useful, share it with others on the blogs or
add a link to your site. I will read it again one day, and maybe add some
stuff, but it got much too long, and too quickly.