Creating your own base box for vagrant is a great thing to do, you get to undestand exactly what is on that box and to choose exactly what base OS you use.

After all one of the big draws of vagrant is keeping your dev environment close to what production looks like - and for that you need to know what is in the base box.

When I first started using vagrant I wrote a post How to build a Centos 6 base Box for vagrant whcih details the manual steps needed. At the time I was busy learning puppet, vagrant and related tools - veewee was just one tool too many and a manual build seemed the best way to get my head around what a base box was.

While the base box isn’t something I have needed to repeat much, it is beneficial to update the base image from time to time and here veewee is brilliant. It also makes shareing the reponnsbibility for the base box within a team easy.

Here’s what I did

In this case to turn on comments in all posts for this blog

All files that don’t have comments at the start of a line get “comments: true” inserted on the 5th line

I’ve been running this blog (or some version of it) for almost 10 years now.

I write to help clarify my own thoughts, or to note down technical details of a task that I have struggled to figure out. I often found myself coming back and have saved many hours of trying to figure out the same thing again a year or more later.

I’ve exported this site from Drupal using wget to create a static html version like

wget  --mirror -p  -e robots=off --base=./ -k -P ./ http://localhost/

Then rsync to the server and use mod rewrite to retain the paged links like frontpage?page=4

We often work on large websites with strict change control practices and scheduled release cycles. Sometimes we also hand over the systems to the client for production and don’t have direct access ourselves.

Some bugs have a nasty habit of only occurring in production, this may be due to high load, odd/old browsers, changes in data, or just because test scenarios don’t cover every eventuality.

What this means is that when we have a bug in production we can only understand it through the error logging we have already built into the system. If we need to put in place additional logging we usually lose the chance of actually fixing the bug for another release cycle.

To use google plus comments on your site all you need to do is insert the following code on the page where you want the comments to appear

url should be the full url to the page, then any comments in google plus with this url will appear to any user who can see them (ie public comments or those from people in the viewers circles).

If you have a gmail account, you get a google plus account with it, many of end of with several of each. For mail this is usually what you want but for plus with it’s circles you usually just want one account and to split post by circle. Fortunately there is a way to redirect one account to another.

This way anyone looking for you at the account you don’t really use or looking you up via an alternate email gets redirected to your active account.

A few days ago I was notified by my ISP that my server was “emitting a UDP-based denial of service attack”, as a result the VM had been rebooted and taken off the network.

With console access I was able to verify there was a problem, and the ISP was able to give me a clean VM, with my old system available as a mount, in read-only mode

I have a site which requires users to be logged in, but the pages are not customised. I was playing with a way to cache the content in varnish while still doing an access check. This method uses an access check pages (test.php below) which then uses ESI to load the real, cacheable content.

I’ve tried it in a dev env, I’m not yet sure if we’ll use this in production.

Varnish config

I find a lot of clients use skype

For me the biggest frustration is the limited search

But it turns out the data is stored using sqlite - and so you can search using sql directly on the sqlite db files.