I will try to explain how my choice for Microsoft Windows as OS on my machine collided somewhat with the decision we made at Enrise to start using Vagrant for our virtual devboxes, and how I set up my pc to overcome these collisions and be able to work to my satisfaction.
Out with the old, in with the new!
Enrise’s strength is in developing complex Web and API projects, with not only a web and database server to support projects, but various caching mechanisms, other storage backends, and queue handlers as well.
Until recently we used to develop on a standardized Virtualbox environment which could support multiple projects side to side, but as more and more of the above mentioned tools come into play, sometimes this would mean e.g. having to switch the Varnish or Memcached configuration for different projects we would work on.
Besides that, whenever a new developer joined a devteam, he or she had to setup their own Virtualbox environment which could easily cost a day’s labour labor. (Exporting / importing Virtualboxes proved to be as time consuming as setting up the project again, because of personal changes done to or personal data on the Vboxes.)
Because of above reasons, we decided to start using Vagrant, which is basically automated setup of Virtualbox machines combined with a automated configuration / installation process within that vbox to tailor it to the needs of a specific project. This means that once configured properly, every project has its own environment that’s up and running in minutes, so no more fiddling around with switching settings between projects, and no more wasted days setting up development environments.
Vagrant on Windows
While Vagrant works really great in POSIX compliant OSes like Linux or MacOS due to their mature terminals and command line tools, on the OS from Redmond things were not so great.
What I wanted to achieve was to work just like I would have been able to if I was running Linux on my machine, so my requirements were:
- A proper terminal (Bash) environment, with a git PS1 helper, support for colours, etc.
- The ability to run the funtoo keychain project as a background process which enables me to push and pull code to and from github without having to supply a password every time I do so.
- Fast git status and git diff command execution
- Resizing the terminal window just the way Putty works
Because we decided at Enrise to include the Vagrant config within our project source, this means working with Vagrant cause the source code of projects to be on the host OS, in my case Windows 7 Professional x64, and it seemed these were options to pick from:
- Installing GitBash which provides the Git commandline tools on Windows from within a Bash environment
- Mounting the same Windows directory to both the Vagrant Vbox and a separate virtual Linux box on which I have a proper tool setup
- Migrate to Linux or get a Mac
- Setup a Cygwin environment with the tools I want
Exploring my options
GitBash
This option turned out to be a pain, because GitBash runs in a small Windows CMD window which is unable to resize beyond a rather small width, and has no proper copy/paste support. Using Windows PowerShell instead somewhat solved the resizing issues (the terminal itself still isn’t resized, only the window it’s in) although I seriously doubt I would have been able to fix other nuisances things like a keychain (actually, there is an option called plink which integrates with Putty / Pageant but this turned out to be pretty slow)
Mounting twice
Making the source directory (which is located in Windows) available to both the Vagrant box and a separate Linux box via mounts seemed to work just fine, as this provided me with proper tools and a proper terminal, but once I started running the commands git status or git diff it turned out this setup was way too slow for everyday use. I like coffee and all (every developer does, right?), but getting a fresh cup every 15 minutes just because I had to wait to see my changes is a bit too much even by my standards. A colleague warned me about this twice, but then again I believe Christopher Columbus was warned (and more than twice) that he would fall off the end of the earth before he left on his great journey to find India, and instead found America, so I had to try it anyway. I also tried running a NFS server on my Windows machine and mounting that from within the Linux box my tools were on, and although it was much faster than vboxfs, it still was too slow for me to work comfortably.
Switching to Linux or getting a Mac
Switching to a different OS the minute one encounters obstacles probably means I would be switching every week. No OS is perfect and although I can live most of the OSes out there, Windows has never let me down and enables me to use nice software like Adobe Photoshop or Foobar2000 audio player out of the box. So, this idea was quickly discarded.
Cygwin
Even though Cygwin isn’t officially supported as far as I know, I decided to give this a try, as it might meet the requirements I stated above. After some fiddling, it turned out to be best solution I have seen so far, and actually works to my full satisfaction! In the section below I will go into detail on how I set up the various tools involved.
The setup
Cygwin
First of all, I needed Cygwin on my Windows box, so i grabbed it from the official site.
After installation I quickly found out that a few things were not to my liking:
- I missed my beloved Gentoo style bash config
- A proper package manager was missing, too
- ‘vagrant up’ and ‘vagrant ssh’ would not work on Windows
Gentoo style bash config
This was quickly fixed by copying over the bashrc and .bashrc from a Gentoo box I was running.
The home dir of your user resides in C:\cygwin\home, it’s easy to access the Cygwin filesystem from Windows.
A proper package manager
Cygwin does not have an internal package manager, therefore packages you would like to install require starting up setup.exe again, selecting the required package, and installing it by finishing the Cygwin installation process. A nice little project exists however, that decides it wants to do things differently. It is called apt-cyg, can be found at http://code.google.com/p/apt-cyg/ and gives us the power of maintaining packages in our Cygwin environment via a command line package manager similar to apt-get.
The procedure to install apt-cyg is described on site as installing Subversion, then exporting the source code into a directory.
I feel however that you should decide whether you would like to have Subversion as a package on your Cygwin installation because you use it, or have since moved on from this great software that served us well for many years but I feel is now deprecated to its successor git/github.com.
There is a simple way of circumventing the installation of Subversion, which is running the following commands from your Cygwin terminal:
$ cd /usr/local/bin/
$ wget
$ chmod + x apt-cyg
Pat yourself on the back, for you now have installed a working cygwin installation and a proper package manager to maintain it. Just type apt-cyg to try it out!
Fixing vagrant up and vagrant ssh
Vagrant refused to run, instead it showed following error message:
/cygdrive/c/Program Files (x86)/Vagrant/vagrant/bin/vagrant: line 42: /cygdrive/c/Program: No such file or directory
This to me looked that a script was being run with some variables, one of which is the (unescaped!) path to vagrant, which results in ‘/cygdrive/c/Program’ instead of ‘/cygdrive/c/Program Files (x86)/vagrant’.
The fix turned out to be easy. In the file noted in the error message was this line:
${EMBEDDED_DIR}/bin/ruby ${VAGRANT_EXECUTABLE} $@
Encapsulating the variables with double quotes solved the problem, as ruby now interpreted the complete path a single argument:
"${EMBEDDED_DIR}/bin/ruby" "${VAGRANT_EXECUTABLE}" "$@"
After this, I could successfully run the command ‘vagrant up’ and my Vagrant box appeared \o/
Next up: vagrant ssh. Vagrant detected I was running Windows, which, at least to Vagrant, can’t possibly have a commandline ssh client, thus Vagrant showed the message I should use Putty to connect.
I found this patch on Github which solves the issue by doing a proper SSH check, but at the time of writing the stable release version of Vagrant is 1.0.5, which does not have this fix yet.
Luckily it is possible to just grab the fix from the Pull Request and apply it to the installed version of Vagrant, after which I was able to not only do ‘vagrant up’, but ‘vagrant ssh’ as well.
Other tools and configuration
Because the way we setup Vagrant within projects, the code needs to be on the host OS.
Therefore, I decided the project sources would be stored in the My Documents folder, in a directory named Projecten (Dutch for Projects).
From the Cygwin terminal, this is accessible via /cygdrive/c/Users/svessen/Documents/Projecten/. Since I don’t like to type long paths over and over again, I created a symlink to my home dir called projects, so I can just ‘cd projects’ and be in the projects folder within My Documents.
All I then really needed was some software like funtoo keychain, git and vim, luckily this was super easy thanks to apt-cyg!
Conclusion
After setting the default Cygwin window size and transparency (which is pretty nice) I found a system that met my requirements in every way:
- A proper terminal (Bash) environment, with a git PS1 helper, support for colours, etc.
- The ability to run the funtoo keychain project as a background process which enables me to push and pull code to and from github without having to supply a password every time I do so.
- Fast git status and git diff command execution
- Resizing the terminal window just the way Putty works
So if you are running Windows as host OS and want to be able to develop with virtualboxes using Vagrant, I can really suggest running the above mentioned setup.
If you have found a better / different way of working with Vagrant on Windows, let me know in the comment box below!
