hashbangcode / vlad

Vlad - Vagrant LAMP Ansible Drupal

Vlad - Vagrant LAMP Ansible Drupal

A Drupal development platform in a box, with everything you would need to develop Drupal websites.

See full project documentation at vlad-docs.readthedocs.org/.

This includes the following technologies:

• MySQL
• Apache2
• PHP
• Varnish
• Git
• Drush
• Drush commands: Coder & Site Audit
• Munin
• Xdebug
• Ruby
• Sendmail
• Mailcatcher
• Memcached
• Redis
• Adminer
• XHProf
• Solr (Version 4)
• Node.js
• ImageMagick
• PimpMyLog
• AberdeenCloud Command Line Tools
• Pantheon CLI (aka Terminus)

Many of these items can be turned on and off via a settings file.

Dependencies

To get started with Vlad you need to install the following components:

• A virtual machine - The system that runs virtual machines. Examples include VirtualBox, VMware & Parallels.
• Vagrant - The virtual machine manager.
• Ansible - A provisioning tool.
• Sudo Password - The sudo password is required for some actions during the setup process.

Documentation

Read the documentation at http://vlad-docs.readthedocs.org/.

Contribute to the documentation on the Vlad Documentation repository.

Vlad can be extended with a custom playbook.

Vlad has a notice board located at https://vladnotices.wordpress.com. Important notices regarding additional features, new releases and any changes that users should be aware of will be posted there.

Change log

See the change log in the documentation.

vlad's Issues

Error on 'vagrant destroy' if box is not 'up'

Got this error on vagrant destroy today:

#!shell

$ vagrant destroy
==> vlad: Running triggers before action...
==> vlad: Executing command "ansible-playbook -i host.ini --ask-sudo-pass playbooks/local_destroy.yml"...
sudo password:
The command "ansible-playbook -i host.ini --ask-sudo-pass playbooks/local_destroy.yml" returned a failed exit code. The
error output is shown below:

...no output gets printed :D

Not the most helpful error ever :) I managed to figure out that it only occurs if you attempt to destroy a VM that is halted (rather than up). I'm not sure if this is a restriction of vagrant, ansible or vagrant-triggers or indeed if there's anything we can do about it (I'm more concerned with logging it here so that other people can find the solution if stuck).

Marking as "minor" as the workaround is to run vagrant up before running vagrant destroy.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/26
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-04T11:57:26.296

Allow Vagrant Cloud support

Vagrant Cloud (https://vagrantcloud.com/) is a neat new thing available with Vagrant 1.5+. Unfortunately, Apache within Vlad doesn't listen to the custom urls you set up (e.g. http://trying-porpoise-9354.vagrantshare.com/).

The box is seen but a 301 redirect is issued to port 8080. It would be good to listen for the vagrantshare.com domain within the main Apache vhost file to allow this service to work.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/31
• Originally Reported By: Philip Norton
• Originally Created At: 2014-04-12T13:49:11.695

Tweak MailCatcher install now that we're using RVM

http://mailcatcher.me/#how

From the above link:

Under RVM your mailcatcher command may only available under the ruby you install mailcatcher into. To prevent this, and to prevent gem conflicts, install mailcatcher into a dedicated gemset and create wrapper scripts:

#!shell

rvm default@mailcatcher --create do gem install mailcatcher
rvm wrapper default@mailcatcher --no-prefix mailcatcher catchmail

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/15
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-10T12:57:45.987

Install RVM as part of Ruby playbook

Currently, vlad will dish up whatever version of Ruby comes with Ubuntu. RVM (Ruby Version Manager) makes specifying a different Ruby version a whole lot easier.

This is currently recommended best practise in Omega 4 and other Drupal base themes that use gems (along with recommending bundler for gem management) in order to provide granular control of your environment (one the reasons we're using Vagrant & Ansible here, right?).

Admittedly, the advantages aren't as great when you're using a whole virtual box for the development of each site but I still think that RVM is a welcome addition purely for how much easier it would make it to specify the Ruby version for a project.

If there's a better way to specify which Ruby version is installed via Ansible then maybe RVM isn't really necessary. My Ansible knowledge is pretty thin so I'd definitely welcome input here.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/11
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-07T11:47:53.057

Testing

When releasing a new version of the box some form of testing is needed. It is possible for the box to build correctly but not have the correct stuff installed, as a recent drush error has demonstrated.

The testing can take two forms:

1. External resource testing - this would be making sure that things like www.drupal.local resolves to a correct page and that it returns a 200 response. This can be done with any testing framework really.
2. Installed programs testing - this would be running various commands to ensure that, for example, php is installed. This might take the form of running 'php -v' to ensure php is present but can also be seeing what daemons are running to ensure that apache is installed and configured correctly.

This internal testing can be done as an additional 'test' role in Ansible that runs certain tests.

One prerequisite would be to ensure that a test is only run if a particular piece of software has been installed. As a result a var file would need to be created that allows software to be turned on and off outside of the site.yml file. This might have something like:

mysql_install: yes

Which is then picked up by the mysql task.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/6
• Originally Reported By: Philip Norton
• Originally Created At: 2014-02-18T13:26:30.213

Create top level 'vlad' directory and move a bunch of stuff down into it

This came up in discussion on Skype today so here's an issue to track it.

To help with not making too much of a mess of people's project directories (and to help keep it that way) let's do the following:

1. Create a new directory called 'vlad' in the root of the repo
2. Move playbooks/ & example.settings.yml into vlad/
3. Amend codebase so that the above 2 changes don't totally break everything
4. Update all docs & wiki to reflect this change

This means that when a user creates settings.yml for the first time, they'll be creating it at vlad/settings.yml.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/30
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-07T18:56:54.068

Vagrant file syntax error (probably my fault)

Hi,

First, thanks for Vlad!

I followed all the setpup steps tonight and cloned down the vlad repo. When I ran vagrant up I saw the attached errors pop up:

I'm not sure if I've missed an install step or something, I've re-checked the steps I took and everything looks OK.

Any help is most appreciated!

Cheers

Tom

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/23
• Originally Reported By: Tom Metcalfe
• Originally Created At: 2014-03-19T22:52:24.753

Symlink from guest ~/docroot to /var/www/site/docroot

Running vagrant ssh and then cd /var/www/site/docroot/ is tedious. To me, this is begging for a symlink.

I can't decide whether I should just keep this in a custom playbook or whether we should add this to Vlad for everyone. If it is the latter, I'm not sure which playbook to add it to.

Thoughts?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/33
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-17T11:53:20.660

vagrant rsync-auto

Some background

I haven't had a play with this yet but it's something we should certainly consider for Vlad. Thoughts?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/36
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-24T10:51:34.745

Second vagrant shared folder

The notion of a second vagrant shared folder originally floated by Phil in issue #19 and I didn't want to lose sight of it, hence creating this issue.

Issue 19 deals with "deprovisioning" on vagrant destroy and among other things is an opportunity to make a last minute database dump to preserve config that could otherwise be unintentionally zapped. The current system gets the job done but could be improved: the db dump is saved to docroot/ which is likely your Drupal project and therefore likely in version control and therefore likely not where you want a db dump to suddenly appear.

Creating a second shared folder would allow us to improve on this and also do much more. E.g:

1. Save a db dump to a location outside of docroot/ but still available after the VM has been destroyed.
2. Optional auto import of a db dump on vagrant up.
3. Optional rsync of the entire Drupal private files directory if present (which could very possibly be located outside of docroot/), preserving the entire backup set (scheduled & manual) if using the backup_migrate module.

To kick off, I propose the following in terms of structure (I've suggested that the new shared folder is called 'aux'):

.
├── README.md
├── Vagrantfile
├── ansible.cfg
├── aux/
│   ├── README.md
│   ├── db_io/
│   │   ├── destroy/
│   │   │   └── README.md
│   │   └── up/
│   │       └── README.md
│   └── rsync/
│       └── README.md
├── docroot/ << (not in git)
├── example.settings.yml
├── playbooks/
└── settings.yml << (not in git)

Notes:

• Configure vagrant to sync aux/ with another directory named 'aux' within the VM. Exact location to be discussed but I'm leaning towards /var/www/site/aux as it places it right beside docroot - mirroring the setup on the host box.
• aux/db_io/ would contain db files to be imported on vagrant up and exported on vagrant destroy (dump files stored in subdirectories named respectively).
• aux/rsync/ would be used to store any files copied with rsync on vagrant destroy.
• README.md files added all over the place to aid with basic documentation and to ensure that this otherwise empty directory structure gets included in the Git repo.
• .gitignore would need some love in order to keep dynamic stuff out of Vlad's repo when developing & testing (e.g. dump files in aux/db_io etc)

If "aux" means something else that's very important within a Linux based web server then please let me know - I don't want to cause confusion and am open to ideas. A quick Google search suggests that it's probably OK.

Regarding the playbooks that would handle interaction with aux/, let's start by tweaking the current sql dump on destroy mechanism and then tackle the others later once we've had a chance to think it through more and get some of the above folder structure in place.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/29
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-06T15:37:23.769

How best to approach running a VM per project in local development.

In trying to figure out how best to use Vagrant in my local dev workflow I've hit the following quandary and would appreciate any input.

I'm aiming for a vm box per project in order to fully take advantage of what Vagrant has to offer. Vlad lets me specify a different host name per project with ease. So for example I create 2 VMs based on Vlad:

• project1.local
• project2.local

As it stands, each of these guest boxes will use the same IP address of 192.168.100.100 and therefore my hosts file will look a bit like:

• 192.168.100.100 project1.local www.project1.local adminer.project1.local xhprof.project1.local
• 192.168.100.100 project2.local www.project2.local adminer.project2.local xhprof.project2.local

Does this mean that I can't have both boxes running at the same time? If they're both using the same IP, how does each host know which box to map to?

If I'm on to something here, then I'd love to know how other people are doing it.

In my mind at present, I'd suggest adding the IP address as an optional parameter in Vlad's settings.yml and then using that as a variable in setting up the VM. I'm not sure if that's even possible.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/16
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-11T12:39:21.454

Find a better name

The name of this project is too functional (and long). Try to find a better name that is still descriptive of what it does.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/2
• Originally Reported By: Philip Norton
• Originally Created At: 2013-12-04T11:23:15.083

Not installing Varnish leads to site not being accessible in the browser

This had me chasing my tail for a fair old while. My new local project was built without errors, accessible via ssh but not accessible in the browser.

• is it the IP I've chosen?
• is it because I'm using .local as the domain?
• etc etc...

Adding :8080 to the end of the URL in the browser meant I could access the site and got me thinking it was port related.

Turns out it's because I haven't selected varnish for install via settings.yml - even though I don't want/need varnish installed. My short term workaround is to opt to install varnish regardless but thought I better post this as a bug.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/38
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-29T20:00:33.571

NFS error on Ubuntu

Hi,

I've got VLAD up and running on Ubuntu 12.04 LTS, but I am getting the following error when VLAD tries to setup the chared folder:

I've also attached it, in case the above isn't readable.

I installed the nfs kernel from these intructions:

https://help.ubuntu.com/community/SettingUpNFSHowTo

I wondered if there was any other steps I needed to take to get this up and running?

Cheers

Tom

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/27
• Originally Reported By: Tom Metcalfe
• Originally Created At: 2014-04-05T10:52:36.303

how to properly overwrite docroot directory

I'm working on a custom playbook for developing a pre-existing site, but with the latest version of Vlad I'm having trouble doing a git clone into the docroot directory using Ansible. I get the following error:

stderr: fatal: destination path '/var/www/site/docroot' already exists and is not an empty directory

I tried adding force=yes on the git command, but I still got the same error. Ultimately, I commented out the "post_task" entitled "Move default index.php file into docroot directory" and that worked. However, that seems like a hack.

Should there maybe be an option to disable the post_task that populated docroot or is there another option?

Thanks!

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/48
• Originally Reported By: Matt Vance
• Originally Created At: 2014-05-16T03:50:10.357

Add service tasks to an 'up' trigger in order to ensure services are started

Sometimes, when shutdown and restart a machine, I can't access Apache or Varnish and have to go into the box to start these services. This isn't a huge issue, but it should be easy to solve.

The current 'up' trigger in use is run too early to be used as the services it is starting won't exist when the box is first started as the provisioning step hasn't taken place. Another up trigger is therefore needed.

Here is an example of the contents of the playbook:

#!yaml
- name: Services | ensure Apache service is started
  service: name=apache2 state=started
  when: apache_install is defined and apache_install == "y"

The following services will need to be checked:

• Varnish
• Apache
• MySQL
• Redis
• Tomcat (for Solr)
• Munin
• Mailcatcher (slightly different approach needed as this isn't a service)

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/43
• Originally Reported By: Philip Norton
• Originally Created At: 2014-05-13T15:19:18.225

Include Vlad release number in repo

It would be very useful if we could include the tagged release number of Vlad in the repo somewhere so that when used on a project (quite possibly detached from Git) it's a simple affair to determine which version is being used.

If in agreement I see 2 things to consider:

1. Where should we put it? Often these things are in the root of a project. Vlad aims to make as little mess of the root as possible - perhaps it should be in /vlad?
2. Is there something clever we can do here where the Git tag is automatically added to a certain file? I'm thinking some kind of Git hook or perhaps BitBucket offers something that could be of use here?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/50
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-05-20T11:06:09.802

initial provisioning fails without Vagrant Triggers plugin

I had trouble with recent versions not completing the initial provisioning. I eventually tracked it down to the /etc/hosts file entries not getting created as expected on the host OS. It looks like the initial local setup is now only run if the Vagrant Triggers plugin is installed. The README file makes it sound like that plugin is only necessary for deprovisioning, but it looks like it's needed for provisioning as well.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/42
• Originally Reported By: Matt Vance
• Originally Created At: 2014-05-09T07:43:47.556

Vagrant triggers deprecation warning

Here's one we should probably get resolved before v1.0.

Currently, when I run vagrant up I get the following deprecation warning:

Bringing machine 'vlad' up with 'virtualbox' provider...
==> vlad: --------------------
==> vlad: DEPRECATION WARNING:
==> vlad: --------------------
==> vlad: The `:execute` and `:info` trigger options are deprecated
==> vlad: and will be removed in vagrant-triggers 0.4. Please upgrade
==> vlad: your Vagrantfile according to the new trigger DSL.
==> vlad:
==> vlad: More information on the project home page:
==> vlad: https://github.com/emyl/vagrant-triggers
==> vlad: Running triggers before action...

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/32
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-17T11:48:21.302

Consider replacing config files with "[config].example" versions in the repo

Whenever I git pull the vlad project it nukes my config with defaults (because the actual config files are in the repo).

Taking a leaf out of Drupal's book, what do you think about these changes:

• settings.yml > settings.example.yml
• Vagrantfile > Vagrantfile.example

Users would then be expected to copy/rename these files before making their own customisations.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/21
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-13T14:46:25.073

Add support for "deprovisioning" on vagrant destroy

Yes, deprovisioning is a word now :)

Initially discussed here.

Currently, Vagrant only provides support for Chef to run deprovisioning tasks on vagrant destroy. Vlad could use Vagrant Triggers to add this functionality in the short term.

Long term, it may be that we can use possible forthcoming support for the shell provisioner. Hopefully Ansible provisioner support will eventually be added (perhaps we should raise the issue?).

One of the main drivers for this kind of support is to better manage hosts added by vagrant (to help prevent multiple hosts all pointing at the same IP). There's also possible scope for running a last minute database dump to the shared folder, depending on when the hook is run (i.e. if it's before the virtual box is shut down).

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/19
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-12T23:56:26.270

Improve on playbooks/site*.yml files following conditional added to Vagrantfile

Catchy title right there.

So pull request #28 saw the addition of vlad/playbooks/site-custom.yml right beside site.yml. This is so that Vagrantfile can opt to run an alternative playbook if a required custom role file is missing (tasks/main.yml) - regardless of whether the user has opted to run the custom role.

The bugger is, site-custom.yml is only slightly different from site.yml and now we have to maintain a whole bunch of code in both files. This seems weighty and is in no way DRY.

Let's use this issue to discuss how we can improve on things.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/35
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-24T00:12:10.037

Issues with npm packages that use symlinks

I'm creating this issue as a note to self as well as to raise awareness.

Whilst adding Node.js support to Vlad I had a go at installing Grunt via npm. In short, it was a headache. It seems that Vagrant has some issues with Node packages that use symlinks (to do with the folder shared between host and guest boxes) and it throws a bunch of errors on install. I tried installing via Ansible with both shell & npm modules, I also tried installing after vagrant ssh - all routes resulted in errors and Grunt not installing.

For the record, this is how you should install grunt apparently:

#!shell

npm install -g grunt-cli

In Vagrant, this will throw a bunch of errors about access problems. Adding sudo seems to get round this but I understand that the use of sudo is bad form when installing packages so we probably shouldn't go there.

Googling around the issue of npm packages that use symlinks returns several posts advising that I add the --no-bin-links flag when using npm install. Sadly, this didn't work for me and it seems that this advice is mainly born out of users struggling with Windows as a host box (not our concern as Ansible currently means no Windows support for Vlad).

Another option that I've yet to try involves specifically configuring Vagrant to allow symlinks in the shared folder. I'll give this a whirl at some point and update this issue.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/18
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-12T10:48:21.733

Use bundler rather than prescribing gems at the VM level

I'm now pretty used to the way that Omega 4 & similar base themes do it these days in that I use bundler to handle the gem dependencies of a project.

http://bundler.io

It seems that a project (theme, module etc) is better placed to define its requirements in terms of Ruby gems than a VM is.

Bundler can allow for this via a 'Gemfile' within the codebase. For this reason, I'd recommend scaling back the 'CSS' Ansible playbook to only install rubygems, bundler and maybe rake. I'd also suggest renaming the playbook "gems" or "base-gems". If a theme requires Sass or Susy or whatever, it can grab it via 'bundle install'.

Whaddya think?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/10
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-05T17:39:35.141

Remove docroot/.gitignore ?

Installing Drupal in the docroot directory will replace the .gitignore file in there with Drupal's default .gitignore. When testing Vlad, this will be registered as a change in Git status.

Aren't the contents of docroot protected from ending up in Vlad version control by the root .gitignore file?:

line 49: docroot/*

Can we just remove docroot/.gitignore from the repo or am I missing something?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/25
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-01T01:38:43.375

Add comment to example.settings.yml - Boxname and Webserver Hostname shouldn't be the same

If you set your boxname to the firstpart of your webserver_hostname then when the box is provisioned you end up with two apache conf files for the same hostname. The result is the default host (/var/www) is matched and served from instead of /var/www/site/docroot.

It might be worth adding a comment in the example settings file to advise people to ensure the two names are unique?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/45
• Originally Reported By: Nic Rodgers
• Originally Created At: 2014-05-14T15:01:42.828

'aux' is a protected directory on Windows

Try and create a directory on Windows called 'aux' and it will tell you some confiusing messages about the directory already existing and being a file. This is because the name 'aux' on windows is a protected directory name.

I know that ansible doesn't work well under Windows and users won't be able to actually run vlad at all, but this doesn't stop them working on projects that contain vlad. It is now impossible to clone a project that contains vlad onto a Windows box.

For a more complete list of protected directory names see:
http://blog.onetechnical.com/2006/11/16/forbidden-file-and-folder-names-on-windows/

The name of 'aux' should therefore be changed to 'misc'.

This will require a couple of playbook changes as well.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/44
• Originally Reported By: Philip Norton
• Originally Created At: 2014-05-13T17:17:44.493

errors during [apache | Drush | install drush]

I'm new to Ansible, but I was able to get Vlad up and running a few days ago. I'm not sure what changed, but tonight when I tried running "vagrant destroy" and rerunning "vagrant up" I began getting the errors below. I also tried with a fresh clone of Vlad and I get the same errors with that too. Any ideas?

In case it might help, I'm running VirtualBox version 4.3.6, Vagrant 1.4.3, and Ansible version 1.4.4 with OS X as the host OS.

Thanks!

---

TASK: [apache | Drush | install drush] ****************************************
failed: [vlad] => {"changed": true, "cmd": ["pear", "install", "drush/drush"], "delta": "0:00:00.214855", "end": "2014-02-14 06:22:15.939076", "item": "", "rc": 255, "start": "2014-02-14 06:22:15.724221"}
stderr: PHP Notice: Array to string conversion in /usr/share/php/PEAR/REST/13.php on line 80
PHP Warning: Invalid argument supplied for foreach() in /usr/share/php/PEAR/REST/13.php on line 84
PHP Fatal error: Cannot use string offset as an array in /usr/share/php/PEAR/REST/10.php on line 263
stdout:
Notice: Array to string conversion in PEAR/REST/13.php on line 80

Warning: Invalid argument supplied for foreach() in PEAR/REST/13.php on line 84

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
to retry, use: --limit @/Users/matt.vance/site.retry

vlad : ok=44 changed=33 unreachable=0 failed=1

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/5
• Originally Reported By: Matt Vance
• Originally Created At: 2014-02-14T07:40:46.902

Wiki landing page using dev version of README - contradict's master branch README

I know, I know. That's why I've marked the issue as trivial :) Just wanted to raise it before it confuses someone.

I would just change it myself but I wasn't sure whether you were planning to tag a new master release soon, in which case wading in and changing the wiki would be pointless (because master & dev README would then match).

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/20
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-13T11:25:01.444

Install PECL uploadprogress library as part of PHP role

Vlad has uploadprogress support covered via APC but only one upload at a time is supported. The PECL uploadprogress library is the recommended choice for Drupal 7.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/39
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-29T20:42:30.724

Passing identities from host to guest (ssh-add)

This is something I've been trying to get sorted for a while now and today I finally figured out how to do it. As is often the case with these things, the answer was embarrassingly simple.

I've since added the necessary code to my own custom role repo but I think that this may be something to add to Vlad itself given how generic & useful it is. I envisage something that could still be toggled via settings.yml.

Let me know your thoughts and if you think it's a good idea too I'll put together a PR.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/37
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-29T13:16:14.830

Set up basic HTTPS

I wanted to test an API that used a callback to a HTTPS URL, but this isn't included in Vlad.

1. Add basic HTTPS support with an unsigned certificate.

2. Ensure Vagrant share URL's work with the this HTTPS port.

I'm not entirely certain that HTTPS will work over Vagrant share, so that might be worth a look into first :)

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/41
• Originally Reported By: Philip Norton
• Originally Created At: 2014-05-07T11:03:16.672

Test on different platforms.

Currently only tested on:

• Ubuntu 13
• OSx (Mavericks)

We need people with different systems to report on how this works for them. Windows users especially!

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/3
• Originally Reported By: Philip Norton
• Originally Created At: 2013-12-04T11:26:38.698

Add custom playbooks via 'custom' role

I keep finding the need to sprinkle in a little extra provisioning on vagrant up but it's often stuff that's either:

• too opinionated for a project as flexible as Vlad
• too specific to the project that I'm using it on to be useful to anyone else
• too private for a public repo

While there's likely a few ways to address these needs, I kept coming back to the idea of having a facility in Vlad to include custom playbooks without committing them back upstream. My solution has been to add an extra 'custom' Ansible role that potentially runs as the last role depending on whether it's been enabled via settings.yml (defaults to disabled). Add to this some tweaks to .gitignore and everything seems to work rather nicely.

I've also written some example playbooks/templates in playbooks/roles/custom/example (not ignored by Git) to give people a starting point for using this feature.

Everything I've done has been committed to a separate branch in my fork of Vlad: custom-role.

https://bitbucket.org/dbohea/vlad/src/e84a18bcd534627d100f54289499ddee4962eecf?at=custom-role

I'd like to offer this up as a pull request but thought you may want to check it over on my repo first - I didn't want to just suddenly create the pull request without explaining myself first :)

Let me know if/when you're happy to receive a pull request. Otherwise, let's discuss this further here.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/28
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-05T11:42:35.750

Add Elasticsearch

It would be great if we could use Elasticsearch as alternative to Solr. Some related info can be found at http://www.vmdoh.com//blog/using-elasticsearch-drupal-7-search

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/40
• Originally Reported By: Miloš Kroulík
• Originally Created At: 2014-04-30T00:22:42.496

"test root site is present" fails because of missing port

Using Vlad on Mac OS X 10.9 and all recent dependencies (fresh OS install).
At the end of the provisioning process "test root site is present" failed because it tried to contact "drupal.local" instead of "drupal.local:8080". Naturally, port 80 is unreachable.

Am I right in thinking that this part:

- name: Test | test root site is present
  local_action: command curl -I {{ webserver_hostname_alias }}

needs an http port like adminer has:

- name: Test | test adminer is present
  local_action: command curl -I adminer.{{ webserver_hostname }}:{{ http_port }}

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/7
• Originally Reported By:
• Originally Created At: 2014-03-01T17:31:38.732

"test apache site is present" failing on all attempts but one

I've only managed to get things running from "vagrant up" once (tested on 2 different systems, both Mavericks). Every other attempt has failed the following test (with the site still inaccessible):

TASK: [Test | test apache site is present] ************************************
failed: [vlad] => {"changed": true, "cmd": ["curl", "-I", "www.drupal.local:8080"], "delta": "0:00:05.029864", "end": "2014-03-05 11:41:11.129534", "failed": true, "failed_when_result": true, "item": "", "rc": 7, "start": "2014-03-05 11:41:06.099670", "stdout_lines": []}
stderr: % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0curl: (7) Failed connect to www.drupal.local:8080; Connection refused

FATAL: all hosts have already failed -- aborting

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/9
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-05T12:47:03.324

Add mailcatcher to server configuration

Instructions on how to install are here:

http://mailcatcher.me/

Makes debugging emails a lot easier and will stop the vagrant server sending out any emails that are probably not needed.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/1
• Originally Reported By: Philip Norton
• Originally Created At: 2013-11-19T16:11:09.583

Mailcatcher task always fails on vagrant up

It seems that the Mailcatcher task always fails on vagrant up. I always get this feedback in terminal:

TASK: [mailcatcher | MailCatcher | kill mailcatcher] **************************
failed: [vlad] => {"changed": true, "cmd": ["pkill", "mailcatcher"], "delta": "0:00:00.005628", "end": "2014-03-05 11:36:35.271339", "item": "", "rc": 1, "start": "2014-03-05 11:36:35.265711"}
...ignoring

I'm guessing from the "...ignoring" feedback that this isn't a problem?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/8
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-05T12:39:23.034

Failed creating symlink in initial provision with default config file

Hi, if I rename & use the example settings file, when I first varnish up it eventually fails with the following error:

#!txt

TASK: [apache | Apache | symlink www directory from home directory] *********** 
failed: [vlad] => {"failed": true, "item": "", "path": "/home/vagrant/www", "src": "/var/www/site/docroot", "state": "absent"}
msg: src file does not exist, use "force=yes" if you really want to create the link: /var/www/site/docroot

FATAL: all hosts have already failed -- aborting

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/Users/nic/site.retry

vlad                       : ok=80   changed=65   unreachable=0    failed=1   

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

Is this a problem with my installation (again!) or a problem for everyone?

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/47
• Originally Reported By: Nic Rodgers
• Originally Created At: 2014-05-14T18:31:25.929

First time 'vagrant up' doesn't seem to provision?

I'm just starting out with Vlad so this I could be doing something silly, but my expectations from the Usage section of the documentation is that after creating a settings.yml and issuing the command 'vagrant up', a new box will be created and provisioned with the specified software.

However when I do this, a new box is created. I can vagrant ssh to it, but none of the software is installed. If i run vagrant provision at this point, the software is installed correctly.

Unless I'm missing something, either the documentation is incorrect (need to add that you must run vagrant provision after first vagrant up) or the automatic provision should be happening, but isn't.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/46
• Originally Reported By: Nic Rodgers
• Originally Created At: 2014-05-14T15:05:40.505

local_destory.yml doesn't roll back edits to hosts file

Just tried vagrant destroy with vlad 0.7.1 (from a fresh vagrant up) and it didn't seem to roll back edits to my system's hosts file as suggested by dd93d6c.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/24
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-24T13:58:25.766

Add a 'scripts' directory to aux/

I think there's some sense in adding a 'scripts' directory to aux/

Any concerns or shall I create a pull request once we've resolved issue #30? I'd do it sooner but I'd rather not create unnecessary git merge headaches for anyone.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/34
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-04-17T16:29:37.117

Adminer test failing on clean vagrant up with default settings

When I try to vagrant up after this weekend's amends and I get the occasional failed adminer test:

#!shell

TASK: [Test | test adminer is present] ****************************************
failed: [vlad] => {"changed": true, "cmd": ["curl", "-I", "adminer.drupal.local:8080"], "delta": "0:00:05.122503", "end": "2014-03-10 10:14:00.580092", "failed": true, "failed_when_result": true, "item": "", "rc": 7, "start": "2014-03-10 10:13:55.457589", "stdout_lines": []}
stderr:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0curl: (7) Failed connect to adminer.drupal.local:8080; Connection refused

FATAL: all hosts have already failed -- aborting

It's tricky to reproduce - the only time I've managed to is if I try to vagrant up from a directory name that I've used to vagrant up from before. I have no idea what could be causing that or even it's just something wonky with my system. Either way, thought I'd better log it here in case you knew.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/14
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-10T12:24:09.321

Compass?

I'm needing to use Compass on my VLAD install. In earlier versions of VLAD, I think Compass was installed automatically, but it appears to have been removed in commit 9dffbaa. Before I add Compass to my custom playbook, I wanted to check and see if that's the preferred way I should be installing it now.

Thanks!

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/49
• Originally Reported By: Matt Vance
• Originally Created At: 2014-05-19T18:36:03.464

Memcache instalation

Hi,

any particular reason, why memache is not installed like this?

#!yaml

---
- name: install packages
  apt: pkg={{ item }} state=installed
  sudo: true
  with_items:
    - memcached
    - php5-memcache
  notify:
    - restart apache2

Current playbook will fail during second provision run, because pecl instalation.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/12
• Originally Reported By: Ján Koščo
• Originally Created At: 2014-03-07T14:26:04.926

Dependencies

Several of the roles defined in this project rely on other role being run before them. For example, in order to run the xhprof role you first need to have run the mysql and apache roles.

To solve this add dependencies to each role that needs one.

To continue the above example, the xhprof role would have a file located at roles/xhprof/meta/main.yml containing the following:

---
dependencies:
- { role: apache }
- { role: mysql }

The idea behind adding these is to stop people breaking their vlad boxes by selecting settings that don't work.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/13
• Originally Reported By: Philip Norton
• Originally Created At: 2014-03-10T09:16:11.858

Ideas, questions & the best way to communicate them

I'm loving Vlad so far and have really enjoyed contributing. I have a bunch more ideas about how to develop Vlad (as I'm sure you do too). I also have a few more questions about how best to work with Vlad and VM boxes in general. I also only have the BitBucket issue queue to communicate any of this :)

Would you be up for a chat on Skype sometime at your convenience? I completely understand if you'd rather not - you have no idea who I am. However, if you are up for it, give me a shout and we can arrange something: [email protected]

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/17
• Originally Reported By: Dan Bohea
• Originally Created At: 2014-03-11T15:31:29.259

Intermittent Ansible error on Vagrant Up

Intermittent error report after 'vagrant up'. No idea how to reproduce, or if this is to do with my install of Ansible. (this will not come as a surprise to you :-)

#!plain

[drupaldev] Machine booted and ready!
[drupaldev] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
cause things such as shared folders to not work properly. If you see
shared folder errors, please update the guest additions within the
virtual machine and reload your VM.

Guest Additions Version: 4.1.12
VirtualBox Version: 4.3
[drupaldev] Setting hostname...
[drupaldev] Configuring and enabling network interfaces...
[drupaldev] Mounting shared folders...
[drupaldev] -- /vagrant
[drupaldev] -- /tmp/vagrant-cache
[drupaldev] Exporting NFS shared folders...
Preparing to edit /etc/exports. Administrator privileges will be required...
[drupaldev] Mounting NFS shared folders...
[drupaldev] Configuring cache buckets...
[drupaldev] Running provisioner: ansible...
Traceback (most recent call last):
  File "/usr/local/bin/ansible-playbook", line 25, in <module>
    import ansible.playbook
  File "/Library/Python/2.7/site-packages/ansible/playbook/__init__.py", line 18, in <module>
    import ansible.inventory
  File "/Library/Python/2.7/site-packages/ansible/inventory/__init__.py", line 27, in <module>
    from ansible.inventory.script import InventoryScript
  File "/Library/Python/2.7/site-packages/ansible/inventory/script.py", line 25, in <module>
    from ansible import utils
  File "/Library/Python/2.7/site-packages/ansible/utils/__init__.py", line 29, in <module>
    from ansible.utils import template
  File "/Library/Python/2.7/site-packages/ansible/utils/template.py", line 21, in <module>
    import jinja2
  File "/Library/Python/2.7/site-packages/jinja2/__init__.py", line 33, in <module>
    from jinja2.environment import Environment, Template
  File "/Library/Python/2.7/site-packages/jinja2/environment.py", line 13, in <module>
    from jinja2 import nodes
  File "/Library/Python/2.7/site-packages/jinja2/nodes.py", line 18, in <module>
    from jinja2.utils import Markup
  File "/Library/Python/2.7/site-packages/jinja2/utils.py", line 520, in <module>
    from markupsafe import Markup, escape, soft_unicode
ImportError: No module named markupsafe
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

markbook-air:vagrant-ansible-drupal-dev mark$ 

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/4
• Originally Reported By: Mark Hope
• Originally Created At: 2013-12-10T22:15:44.404

Drush integration needs checking

Although drush installs and runs fine it isn't able to pick up the active site and so essentially doesn't work.

An example of this is when running drush cc all, it always returns 'drush cached cleared' even when applying the uri parameter.

---

• Bitbucket: https://bitbucket.org/philipnorton42/vlad/issue/22
• Originally Reported By: Philip Norton
• Originally Created At: 2014-03-14T22:21:52.467