I recently started experimenting with Vagrant (v1.5.1), Puppet (v3.5.1) and VirtualBox (v4.3.10) to replace my MAMP environment. I used the config.vm.synced_folder method in Vagrant to share a folder of websites with the virtual machine.
Since a few directories, like caching and user uploads, need to be writable by Apache, I figured I’d use Puppet to set those permissions, but regardless of where I specified that requirement, it never took effect — and Puppet did try:
Notice: /Stage[main]/Ryse_apache/File[/var/www/domains/domain.com/www/htdocs/wp-content/cache]/owner: owner changed 'vagrant' to 'apache' Notice: /Stage[main]/Ryse_apache/File[/var/www/domains/domain.com/www/htdocs/wp-content/cache]/group: group changed 'vagrant' to 'apache'
I found out that this was a limitation with VirtualBox and how it shares folders.
Now, Vagrant does have additional options that can be set when sharing a folder that allow you to specify the owner and group, but the problem is that Puppet installs Apache, and since the folders are shared before the Puppet provisioner runs, the Apache user does not yet exist.
This is the error you get:
Failed to mount folders in Linux guest. This is usually because the "vboxsf" file system is not available. Please verify that the guest additions are properly installed in the guest and can work properly. The command attempted was: mount -t vboxsf -o uid=`id -u apache`,gid=`getent group apache | cut -d: -f3` /var/www/domains /var/www/domains mount -t vboxsf -o uid=`id -u apache`,gid=`id -g apache` /var/www/domains /var/www/domains
Let’s look at a few solutions on how to allow Apache to write to the folders it needs to, and which solution I ended up implementing. If you have a different permissions problem, you might still be able to tweak one of the solutions below, since they broadly cover an array of issues.
There are a lot of great resources out there with regard to the Heartbleed (CVE-2014-0160) vulnerability, but let’s look at what this means specifically for anyone who operates their own VPS.
We’ll determine whether this bug directly applies to you, if you are affected, how to recover from the vulnerability, and what to do after the vulnerability has been patched.
WordPress 3.8.2, a security release, came out yesterday. Now, if you’re already on WordPress 3.8, your WordPress installation will most likely automatically update, but if you are using Git to manage WordPress as a submodule, and have auto-update disabled, you have to do that manually.
That said, it’s still super easy to do. It definitely outweighs not having a version control system.
Let’s look at the Git commands required to update WordPress from 3.8.1 to 3.8.2. Note that this will work for updating any version.
I’m working on updating several WordPress sites. Part of each site’s update includes converting the WordPress core and all frequently used plugins to Git submodules. While many recommend staying away from submodules all together, I’ve been using them for a while now and never had any issues, that is, until today. Luckily, it’s nothing severe, and in my case, pretty straight forward to fix (once you know the solution), but because the error didn’t make any sense, I’ve decided to document it here.
The main problem is that I’m unable to checkout the master branch after adding the submodules on the develop branch. Git complains with the following error:
error: The following untracked working tree files would be overwritten by checkout
That said, let’s look at the problem in detail and how we can solve it.