May 15, 2014

Development environment, etc.

I'm in the process of moving away from Windows as my main development platform and migrating to Linux. At the moment, I've got a composite environment consisting of a Windows host with Linux Mint running in a virtual machine.

The virtualization is provided by VirtualBox 4.3. It's great because directories in the host can be made accessible to and mounted by the guest. Moreover, the clipboard can be shared and enabled to be bidirectional.

However, for performance reasons, I'm starting with the following stack since things run a bit sluggish in the vm on my system. For source code editing, I intend to use Sublime Text 2 under Linux.

Windows 7
Apache  2.2
MySQL  5.6
PHP  5.4

Optimizely module:  7.x-2.14
Drupal 8 core:  8.0-alpha11
Drupal 7 core:  7.28

Installing Drupal 8 was very routine and similar to installing 7. But when you log in, you may get scary sounding messages highlighted in red about your version of Drupal no longer being supported and that you should update. Those messages are spurious. This is what you get for being on the bleeding edge. The "Modules" menu item is now called "Extend"; otherwise, the admin menu looks pretty familiar if you've been around the block a few times with D7.

drush 5.8 (for Windows) is not working with D8. There is mention of drush 7 for Drupal 8 for Linux, here:


  1. I'm not aware of the details but there's a few tricks to getting VM and Drupal to behave. The symptom of a mis-configuration is poor performance. Something about mounted files having to be constantly duplicated. I'll ask around and see what I come up with.

  2. ### Vagrant ssh-fs: Good times

    Vagrant's native file mount is slow. So is NFS (although it's a wee bit better). The best way to make Drupal run much faster is to run the code base inside Vagrant's native file system.

    There's a Vagrant plugin that can then mount that Vagrant-native directory to your host machine, so you can still work with the files directly.

    **We will eventually get this configured in Salt. Until then, follow these steps:**

    * `vagrant plugin install vagrant-sshfs`
    * `vagrant up`
    * `vagrant ssh`
    * Copy the whole file system mounted at `vagrant` somewhere else, for instance:

    `% sudo tar czf /var/www/vagrant.tgz /vagrant`

    `% cd /var/www`

    `% sudo tar xzf vagrant.tgz`

    `% sudo chown -R vagrant:vagrant vagrant`

    * `/var/www/vagrant/html` is now your docroot, so you need to edit httpd's vhosts file (`/etc/apache2/sites-available/default`) so that the two lines that refer to the docroot are updated:

    `DocumentRoot /var/www/vagrant/html`


    * Test that this is loading: `sudo service apache2 restart` and load in a browser.

    * Now, edit `/vagrant/Vagrantfile` so that this new directory is available on your local machine:

    Vagrant.configure("2") do |config|
    config.sshfs.paths = { "/var/www/vagrant" => "/path/to/my/local/mount" }

    * Note that `/path/to/my/local/mount` should not exist yet.
    * `vagrant halt ; vagrant up`
    * Verify that you can access the file mount now at `/path/to/my/local/mount`.

  3. @Dee, this is all very interesting, but I think the use of Vagrant is overkill for what I'm doing with this conversion. For the time being, I'm happy to run Drupal natively on the Windows host and use the Linux guest for less intensive tasks to access the host file system. However, if that should turn out to have problems, I'll revisit your comment with respect to running everything in the vm.

  4. You said "Vagrant" so I chimed in. Personally I'm often left wondering if the over head of keeping it running vs something like WAMP is worth it. I agree, focus on being productive as a developer, leave the sys ops stuff smarter people :)

    1. I love the concept of working in a virtual machine that can be easily rebuilt from a base configuration and for which you can take a snapshot, etc. There are a lot of potential advantages in general.

      However, my hardware resources are limited. I'm on a PC laptop that's four or five years old and only has 4GB of memory (that cannot be expanded). So it's not surprising that running three levels of OSes is sluggish. 8-D

      For this particular task of converting the module, the key variables are the differences between D7 and D8. So I don't see any advantages to working within a vm. It's Drupal itself that I have to grapple with.