Stephen’s Octo Blog

I like to Tinker

Use Varnish With Nginx and Ubuntu

Feels like I haven’t updated this blog in a while, so I’ll add a tutorial that I learned about a bit ago when trying to address speeds with Drupal.

For starters this was done on an Ubuntu VM. From this website, follow the tutorial to install Varnish:

apt-get install apt-transport-https
curl | apt-key add -
echo "deb precise varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list
apt-get update
apt-get install varnish

Edit this file: /etc/default/varnish, under ALternative 2, configure the beginning port :6082 to be :80 like below:

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Next edit the file located at /etc/varnish/default.vcl. Change to port to from 80 to 8080 like below:

backend default {
    .host = "";
    .port = "8080";
    .connect_timeout = 60s;
    .first_byte_timeout = 60s;
    .between_bytes_timeout = 60s;
    .max_connections = 800;

Now the next step would be to edit the port used by nginx. Each server(it you have it configured that way) would need to be switched from 80 to 8080. The location of my config files are /etc/nginx/sites-available.


If you’re using this on a vagrant and have ports forwarded, for example I use homestead for laravel, you will need to change the forwarded port from 8000 to 8080, otherwise it won’t work properly, and nginx will likely not show your sites.

Finished, now test:

To test, you can run varnishstat, and that should give you data live as you access the domain affected by varnish.

Notifications Using Gulp-Notify on Vagrant With Terminal-Notifier

I’ve been looking using grunt/gulp for automation of my different tasks, such as css/js minification, and image manipulations so when I found out about automating tests for phpunit, I decided to give a try.

Note: I haven’t really seen anything relating to this other than this, but I couldn’t quite get it to work using his bash script, so I ended up a making a few adjustments to his.

I develop using a Vagrant VM, so while installing most of this stuff on the host machine will work fine, I want it to be mostly kept to the VM. The tests are also running against the VM’s databases, not the local machine, so it makes more sense to keep dev separate from the Host Mac OSX.

[1] Install terminal-notifier

I used homebrew, so I just ran update and installed terminal-notifier:

brew update && brew install terminal-notifier

This added terminal-notifier to my applications folder, it also linked the app to my $PATH, which allows me to call it from the terminal.

[2] Install Vagrant-Notify

I will be using terminal-notifier for this, since it’s the stock notification app for Mac. This piece was a bit weird when initially installing. It worked best for me when I installed the plugin with the Vagrant vm off, it will give me an error about ruby running if the machine was already running. Killing the rogue ruby task with activity monitor would fix this as well.

From inside the folder with your Vagrant:

vagrant plugin install vagrant-notify

This piece will require another file called notify-send, preferably saved in usr\local\bin

terminal-notifier -appIcon "$2" -title "$4" -message "$5"

Make sure this file has no extension and is executable. sudo chmod +x /usr/local/bin/notify-send

This is the part where I couldn’t quite get it to work like in the tutorial I included, so I ended up moving around the numbers that were being submitted to the script from gulp. These are the numbers that worked for me, YMMV. I believe the gulp-notify sends more by default now.

[3] Install Gulp, and dependencies

Used NPM for this on my Vagrant VM, since this is where gulp will be called:

npm install gulp --save-dev
npm install gulp-notify --save-dev
npm install gulp-phpunit --save-dev

[4] Create Gulp File

I gathered this from a couple of different gulp.js files.

Note: Can be edited from host or guest machine, since in my case the gulp file will be at the base of my project folder.

[5] Check that it works

You can run gulp, or you can use gulp test

Which should return a notification of some sort. This will likely not be the best way to address phpunit tests, especially since currently there are only 3 tests. That’s not a lot, but if the project was much bigger, say 30-40 tests, I can see this being a dumb idea. I’ll likely not use this for larger projects, or at least implement a count that only runs the tests every so often.


The difficult part about this was getting the script to return the proper notifications. It initially wouldn’t give the message, and instead was using the default img that is included with the script. I ended up moving the numbers around and that seemed to address the issue.

Force Regeneration on Jekyll Watch

I noticed that after migrating dev work to my new Vagrant vm, jekyll doesn’t seem to want to regenerate posts whenever I make a change and try to preview it. The simple change I found from a stackoverflow post is instead of calling just jeykll build –watch, use jekyll build –watch –force_polling.

I replace the this line in the rakefile:

jekyllPid = Process.spawn({"OCTOPRESS_ENV"=>"preview"}, "jekyll build --watch")


jekyllPid = Process.spawn({"OCTOPRESS_ENV"=>"preview"}, "jekyll build --watch --force_polling")

Both generate rake watch and rake preview use this line, so make sure to replace both. This seems to have solved my issue with rake preview/watch. The question also has an answer suggesting that vagrant uses a special driver for the file syncing between guest and host machines, making the regeneration not work properly, so that’s something to keep in mind.

Fetching Upstream Changes

I found this very useful in merging changes for Octopress, granted I ended up having to wipe the entire project out anyways.

git remote add upstream

This way I’m able to fetch anything that happens to the master of octopress by simply running

git fetch upstream

If I want to go ahead and merge:

git merge upstream/master

I can’t tell if there’s a difference between using https:// or git://, so I’m sticking to what github uses as an example.

Start Nginx at Launch on Mavericks Mac OS

Update 1/5/15:

Fixed a typo, it should be “sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons“ not “sudo cp /usr/local/opt/nginx/*.plist /Libary/LaunchDaemons“

Also added chown for file, in case it doesn’t have proper permissions.

For the longest time I couldn’t get the piece to work, but I finally figured it out using launchctl as a somewhat basis for troubleshooting. I used homebrew to install nginx which is easier and works for the most part. First the instructions on how to install nginx using homebrew:

brew update && brew install nginx

Next what you want to do is have launchctl start nginx automatically for you. You can do this in several ways, but I’ll cover two:

Option 1 - Symbolic link

For this option you will symbolic link the .plist file included with nginx to have launchctl launch nginx using the proper permissions. Then use launchctl to list the resulting loaded file.

The link you’ll need to use is something along these lines:

sudo ln -sfv /usr/local/opt/nginx/*.plist /Library/LaunchDaemons

Homebrew places a symbolic link of the nginx folder inside opt making it easier for symbolic links, at least in my opinion anyways. The reasoning to remember for this is:

Option 2 - Just copy it to the folder

sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons

Bonus - Ensure proper file permissions:

sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.nginx.plist - Credit to Burak

The reasoning behind this:

  1. /Library is the system Library folder, rather than the user ~/Library folder. It’s used because it needs system access, and it’s easier for all users to access it.
  2. Sudo is used because nginx needs root permissions. Especially if you opt to change the default port from 8080 to 80.

Next what you want to do is have launchctl load the file for you automatically:

sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

  1. You need sudo for this since it’s in the system Library.
  2. You need to use the -w option, otherwise it won’t load.

To troubleshoot the file loading use this:

sudo launchctl list | grep 'homebrew'

You should get a list that shows homebrew.mxcl.nginx

If all else fails:

Option 3 - Just load it when you need it

If you don’t care about automatic use the normal commands for it:

sudo nginx -s stop - Stop Nginx sudo nginx - Start Nginx sudo nginx -s reload - Reload Nginx

This actually took me a bit to figure out, so I decided to make a post for future reference.

Homebrew and PHP 5.5.11 Snag

Upgrading Notes

I updated from 5.5.8 to 5.5.11 today. After the upgrade, I noticed that anything using fpm/php had stopped working with nginx, I was getting a Bad Gateway Error. Checking my console I noticed fpm had spewed out a few errors since the update time, indicating that it wasn’t working. I tried running php-fpm from the command line, and it started right up with no problems, all my php sites worked after that. This gave me the impression that something with my plist file, the file for starting php automatically, wasn’t working correctly. That’s when I decided to make a note of this in an article.

In other words:

If you are upgrading from 5.5.8 to 5.5.11 using the command brew upgrade be aware that the .plist file used in .11 might be spelled differently than what’s in .8. This, depending on how your environment is setup could break your php-fpm, and possibly php. Make sure to swap out the file names by running these commands first:

launchctl unload ~/Library/LaunchAgents/homebrew-php.josegonzalez.php55.plist && rm ~/Library/LaunchAgents/homebrew-php.josegonzalez.php55.plist
ln -sfv /usr/local/opt/php55/*.plist ~/Library/LaunchAgents && launchctl load homebrew.mxcl.php55.plist

Additional Notes:

  • This affects you if you symlink the .plist files to ~/Library/LaunchAgents, or if you cp them as well, since the file is a different name.

  • My plist prior to 5.5.11 was always a variant of this: homebrew-php.josegonzalez.php5x.plist. After the upgrade it’s now named homebrew.mxcl.php55.plist.

Fords on Fourth Car Show

I went to a local car show called Fords on Fourth yesterday. Here are some of the photos I took. Lots of mustangs really, but here’s some of them. More of them are located here in my Tucson Album: Album: Tucson

Gist Test

I wanted to try posting gists as a test. It seems to work fairly well, but for some reason I was having problems with it not finding it resulting in a 301 error.

Here’s a codeblock example:

Meh - hello.rb
puts "Hi!" unless sad

RVM Missing on Mac

Turns out that I messed something installing dotfiles, which is the only thing I can think of at the moment that would cause this. What happened was the Mac I’m using didn’t notice that I had ruby and rvm installed in my home folder, so it started using the version of ruby installed in Homebrew. That meant something had altered my .bash_profile so I decided to check it out.

I checked my bash_profile, which originally that’s where the link for rvm was installed.

The three locations are either ~.bashrc, ~.bash_profile, or ~.profile, either of these three would need to be checked.

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

This appeared to solve my issue and I was able to get back to using ruby.

Update: I was having another issue where rvm kept using the system installed ruby version. I set the new version 2.1.1 to be default, which seems to have resolved my issue. It was pretty annoying.

I tried setting it again using this command:

rvm get stable --auto-dotfiles

It temporarily works, closing the terminal appears to reset it back to the original issue. So I tried setting a default with RVM using:

rvm use 2.1.1 default

This solved my issue, and instead of using the local copy, it uses the .rvm version. However here is what’s shown if I echo $PATH:


As you can see dotfiles still shows up in from which actually made me realize, I was using .path as an older alternative to try and get dotfiles to work, so I ended up removing that piece which solved my $PATH issue. Echoing $PATH now shows the proper order:


How to Remove MySQL Installation on Mac

Note: Original article from 2012, I don’t use MAMP anymore, I use a vagrant/local mysql installation via homebrew.

I don’t know if this is important anymore, the original article I linked to is broken, but here’s the original commands:

sudo rm /usr/local/share/mysql
sudo rm -rf /usr/local/share/mysql*
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
edit /etc/hostconfig and remove the line MYSQLCOM=-YES-
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm -rf /var/db/receipts/com.mysql.*

This is for when MAMP is used for your web server purposes. It might work for overall mysql installations(mysql is under the share folder after all), but it’s been a while since I’ve used MAMP. I’m going to make it a point to actually update my articles in the future.

Tip: Use this command to find everything related to mysql.

sudo find / | grep -i mysql