I occasionally need to be able to secure my traffic while I’m out and about. I’ve written the following script to automate Ubuntu desktop to configure and connect to a remote ssh host for system-wide proxying.
Let me know if you have any trouble with it.
There are now scripts for setting up Drupal 8 as well as GravCMS! Add the appropriate one to the vagrant.local.yml file for an automatic setup.
Behat tests can be initiated right from PHPStorm, saving a lot of hassle, as well as simplifying access to tests for less technical users. Behat v3.3 does come pre-installed via composer and is found at /usr/local/bin/behat. If you wish to use your own version of Behat, you’ll need that path later. At Bryn Mawr, we have behat as part of our repository, so we use that path instead of the default /usr/local/bin/behat one.
Here’s some things you’ll need to have before starting:
You should now be able to run behat tests in the vagrant box right from PHPStorm.
Happy Testing!
I found Codiad to be limited in its capability, but I wanted to find another free IDE to use with the project. I came across Netbeans. After a little wrangling, the RV project has a new IDE option!
I removed Codiad from installing and have left it up to the end user whether or not to add an IDE.
In order to get Netbeans installed, the script found at [Projectroot]/bootstrapscripts/CentOS/netbeans81.sh should be called from within the VM. This installs netbeans to the [Projectroot]/apps/netbeans81 folder, as well as pre-configures it with many settings. The script is already suggested in the local.vagrant.yml.example file under the IDE category.
To run netbeans, you have a few options:
Since the application is installed to the [Projectroot]/apps directory, you can manually run the application by finding the appropriate executable under the [Projectroot]/apps/netbeans81/bin directory. Please note that the host machine requires Java 8 or similar equivalent (e.g. openjdk 1.8) installed. This will not come pre-configured for the vagrant project. If you wish, you can extract and copy the configs from the [Projectroot]/buildFiles/configs folder and move them to your host’s user home directory.
If you choose to run Netbeans from the vagrant box, you must connect with a remote X session and then run:
$ netbeans
A remote X window session can be initiated by either using the ssh flag -X
$ ssh -X vagrant@website.vbox.local
or you can configure a Putty session using the instructions here, coupling it with XMing on Windows.
SSH keys are sometimes required for steps throughout the project. Make sure that you have created the key, and that it exists on your host at ~/.ssh/id_rsa. On Windows, I highly recommend that Putty is used for ssh-ing into RV instead of using git-bash/ PHP-Storm. Putty offers a one-time pass-phrase login via Pageant that carries over to other machines via agent forwarding.
The server should auto-connect without prompting for a password/ passphrase.
Rampant Vagrant comes with XDebug installed and enabled in the guest OS by default with the IDE key of “vagrant”. With a tradeoff of performance, we are able to remotely debug our code in a tool such as PHPStorm. We’ll be configuring PHPStorm and Firefox to connect to a debugging session on the vagrant box.
First, get an instance of the RV project up and running. Also, open up PHPStorm on the host machine. I’m using the latest version of PHPStorm, 2016.3.2 as of writing this.
Save a new PHP file called debugTest.php within the public_html folder of the project with the following content:
<?php
/**
* Test debugging functionality.
*/
echo "Beginning of Program";
$test = array(
"a",
"b",
"c",
);
unset($test[2]);
echo "End of Program";
Within PHPStorm, Click on File->Settings and select the PHP servers. I configured mine in this way:
I added a new server and named it “Vagrant Server”. The Host is the hostname of our vagrant box, which for this project is “website.vbox.local”, and we’re using port 80. You’ll want to also map the absolute path on the server, using “/vagrant/public_html” to map to your project’s public_html folder.
After saving the server configuration, select the Run menu and then Edit Configurations. Create a new PHP Remote Debug configuration with the following settings:
The Server name should match the same one we just created. Set the Ide key to ‘vagrant’. Then click Run->Debug ‘Remote Xdebug’.
Open debugTest.php within the IDE and add some breakpoints by either selecting a line and pressing Ctrl+F8 or clicking just to the right of a line number. A breakpoint is noted by a red circle on the left side.
In the Firefox browser, install the extension EasiestXDebug. After installing the extension, click on its options and set the Ide key to match ‘vagrant’. 
Click the button in the browser to enable debugging.
Visit http://websiter.vbox.local/debugTest.php in the browser. The php file can now be stepped through. If you make a breakpoint at each line, you’ll note the temp array start with 3 elements and then loses the last array element as the unset command executes.
Perhaps the single-most helpful thing I learned about while at the DrupalCampPA was Behat. Behat is a behavioral driven testing framework that lays out tests in English that are then translated to PHP and other commands. A simple test might look like the following:
Feature: Listing command In order to change the structure of the folder I am currently in As a UNIX user I need to be able see the currently available files and folders there Scenario: Listing two files in a directory Given I am in a directory "test" And I have a file named "foo" And I have a file named "bar" When I run "ls" Then I should get: """ bar foo "
The basic structure of a behat test is to define the overall feature in a storytelling context:
The rest of the test consists of steps that a user takes (thus the behavior-driven name), which is written in “regular” language.
As websites become more complex, it is increasingly difficult to test all features manually. Behat tests provide an automated way of ensuring that features work as intended with each upgrade. It’s a great safety net to the deployment process.
If you’re on an AD bound, Windows machine, your home property may be pointing to your network home drive. This presents all sorts of issues, not the least of which is slow performance since the virtual machine will essentially be running across the network. To fix this, we can force the HOME variable to point to your local workstation:
You’ll need to log out and back in in order to have the changes fully apply. Open a Git bash window and cd to “~” without quotes. If you list the files, you should be looking at the ones on your local machine vs. the ones on your home directory.
Our production environment isn’t available off-campus to SSH, but we do have an SSH proxy for other services. Using a VPN was possible for Windows and Macs, but there wasn’t a client for Ubuntu. After a small discussion with our networking engineer, he suggested the following option:
ssh -t <proxy server> ssh <production server>
The “-t” option performs the following (from the ssh man page):
Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when imple‐menting menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
To make drush utilize a proxy server, edit the aliases.drushrc.php file to contain the following:
//Production
$aliases['prod'] = array(
.
.
'remote-user' => username,
'ssh-options' => '-At username@<proxy server> ssh -A',
.
.
.
);
The first “-At” option passes along the ssh-agent key to the proxy server, using username to login to the proxy server. The second portion then logs into the production server via the proxy server.
Sql-sync’s and rsync’s can now be performed as normal.
By default, CentOS 6 doesn’t colorize its git output. As part of the developerSuite.sh configuration, I followed this stackoverflow post and created a .gitconfig file at /home/vagrant with the following:
[color] ui = true