Symlink Support in Windows and Virtualbox

tl;dr: Setting up a VM with symlinks inside shared folders is now pretty easy!

I recently purchased a Windows machine with one of the primary goals being to increase PuPHPet's support for Windows OS. On the roadmap is Hyper-V support, but right now I am picking low hanging fruit.

Line Endings

The first thing I fixed was Window's pesky line endings messing up shell scripts. Bash would fall apart when attempting to run scripts that contained \r\n. This usually happened when a Windows user would edit a file using an editor that had not been configured to always use \n. A simple call to sed fixed this fairly quickly.

The next thing had been a thorn in my side for some time. Unfortunately, not having a Windows machine handy forced me to keep putting this off, until now.

Some packages like Apache on CentOS attempt to create symlinks in the /var/www directory. Since Windows doesn't have native support for Linux-style symlinks, this would fail and break provisioning.

The solution was not very easy to find, but thanks to some very helpful people I was finally able to get this working properly.

The first step is installing Polsedit - User Policies Editor. When you open it, look for Create symbolic links.

Polsedit "SeCreateSymbolicLinkPrivilege"

Double click the row, click Add User or Group... and look for your username in the list. Closing the app will automatically save your choices, and you'll need to reboot your machine.

You will only need to do this one time.

After rebooting, the only step you must keep in mind is to always run Vagrant via "Run as administrator". You can accomplish this by running cmd.exe (or, preferably, Cygwin) with administrator privileges.

That's it! The code that runs the magic is here.

In short:

  • Download Polsedit and add your user to the SeCreateSymbolicLinkPrivilege section
  • Always run cmd.exe with "Run as administrator".

Here's some proof!

Symlinks working on Windows host

Have fun, learn something!

Juan Treminio

Better SSL Security

PuPHPet recently changed the default openssl ciphers and protocols for https vhosts.

I recently had to renew the domain registration for, as well as the SSL certificate issued by COMODO.

I won't go into how maddeningly easy it is to mess up your certs, but after uploading them to the server and restarting Nginx, I ran several SSL tests against the domain [0] [1] [2] and noticed that the scores were B's or C's.

Apparently the server was getting dinged for supporting SSL 3.0 protocol, which has had some problems recently in the form of the so-called POODLE Attack.

After spending several hours reading up on SSL certs, and using Mozilla's SSL Configuration Generator I ended up with what you see in the commit link above.

After re-running the SSL testers, all scores came back as A's.

SSL 3.0 support is removed by default, and Mozilla's recommended ciphers have been set by default for all SSL-enabled virtual hosts on both Apache and Nginx.

The fields are not visible in the PuPHPet GUI. This is the case for several other features as well. The reasoning behind this decision is that somethings are best left as a default value to prevent users from accidentally creating bad servers. However, if you really want to change the values, you can find them inside all newly generated config.yaml files. Drag/dropping them into the GUI will also keep the chosen values.

With these changes, and the previously existing PuPHPet GUI, adding SSL to your website has absolutely never been easier, and for only $10/year for the basic COMODO cert, there's really not much of an excuse not to have one for all your sites!

Some registrars even provide a basic cert for the first year with the purchase of a domain. Namecheap charges $1.99.

Have fun learning something today!

Juan Treminio

PHP7 Support Added

Nightly builds of PHP7 were recently added to PuPHPet.

tl;dr: PHP7 now available for testing, but only for Ubuntu 14.04 x64 boxes.

The builds are taken from Zend PHP7 Nightly Builds page and hosted on PuPHPet's servers.

Ubuntu 14.04 x64 was easy enough to add support for.

RHEL seems to mean true RHEL, as I had problems attempting to get it running on CentOS 6.7 ( was not in any of the repos I use).

Debian 7.7 Wheezy also ran into problems, with outdated libraries. The libraries are in Jessie, but it seems that updating them would upgrade most of the system, basically turning the system into Jessie.


PEAR, PECL and apt/yum modules are obviously not working yet.

Thankfully the package comes with several modules already pre-baked in.

Derick Rethans is still working on getting Xdebug to work with PHP7, so you can't debug this yet.

Many third-party libraries that require PHP module be installed will problably not work. For example, MongoDB does not yet work with PHP7.

MySQL, however, is one of the baked-in modules and seems to work fine.

Final Thoughts

I believe that CentOS 7 will work with the RHEL version. However, each box requires generated for 3 different provisioners (Virtualbox, VMWare, Parallels) and takes several hours of babysitting to make sure everything goes smoothly. Then you have to consider that I would need to test all other packages available on to make sure everything is working well and the required time investment to getting CentOS 7 working rockets.

Debian Jessie is not out yet and I do not want to spend time on a non-stable distro just yet.

If you're simply looking to start working with PHP 7 in a hassle-free manner then I believe the Ubuntu distro will suffice. You can even deploy it to a public server using any of the Deploy Target options available on PuPHPet.

PHP internals would also love for you to test out each nightly build and begin reporting any and all bugs you may run across.

Have fun, learn something!

Juan Treminio