Install WordPress and NGINX on Raspberry Pi

I have been evaluating the idea of spinning up a Digital Ocean VM for my web hosting as a cost effective alternative to shared web hosting. Digital Ocean requires you to know how to understand operating systems, I just happen to be the right guy for the job. I wanted to field test my future setup on my Raspberry Pi to get an idea of how much time it is going to take and what I can do to tune it for maximum performance. All of my sites have been converted to WordPress, my desire was to build a LEMP (Linux Engine-X, MySQL and PHP) stack to accommodate this setup. Continue reading “Install WordPress and NGINX on Raspberry Pi”

Password Strength

Password Strength

I came across this epic cartoon over at xkcd regarding the strength of  passwords. The conventional line of thought is a minimum of 8 characters with a mixture of caps and special characters.

As computing power increases, passwords that are or a certain length are trivial to crack, assuming the right conditions are present.

Since not all systems are designed the same on the internet. A basic defense is to use a different password on every site that you have an account on. Without going into too many gory details, many websites do not follow best practices in how they store passwords. There are sites on the internet that store passwords in a database in plain human readable text. There are sites out there that do not lock users out after a certain amount of attempts, which paves the road for a never ending brute force attempt.


I stumbled upon a bit of awesome today. While I have been learning to code through sites such as Code Academy and Treehouse, I have had a real tough time finding ways to apply those skills that I learned without feeling completely overwhelmed. I stumbled upon Codewars, a site that trains coding through tackling real problems. Continue reading “Codewars”

Liferay Enterprise Tomcat 6 Upgrade for Linux

We recently ran into an issue with our Liferay Enterprise install where the version of Tomcat they had bundled in was falling behind security wise. Currently Tomcat 6.0.29 is available and their bundle is currently holding fast at 6.0.18. When we first set out to install Liferay for use with some internet applications, it was my original intent to start off with a separate installation of Tomcat that we maintain and install the Liferay components on top of that. The consultant that was working with us strongly discouraged that so despite my gut feeling I made the mistake of giving in to the our customer’s demands to get the project underway and installed the bundle. Liferay is pretty well integrated with the various bundles that they support so this is not just a simple drop in and replace upgrade of Tomcat. Word from another department integrating it with JBOSS encountered a similar struggle.

At some point in time, if you began using the bundle, you should have unzipped/untar’d it to a given location, for our servers we used /opt. For simplicity sake, I will just state that liferay is rolled out to a directory called “liferay” beneath /opt. Your directory may be “liferay-portal-5.2.3-ee-sp4” or something to that effect. Beneath /opt/liferay, you should have 4 directories, “deploy”, “ee”, “data” and the tomcat directory encoded by default with the specific version number that was bundled with your install.  For the purposes of this update will refer your current directory of the bundled Tomcat install $TOMCAT-OLD and the one you want to upgrade to $TOMCAT-NEW.

Download the latest version of Tomcat 6 here:

Stop the current running version of Liferay/Tomcat.

Unzip apache-$TOMCAT-NEW to the same directory as your Liferay bundle “/opt/liferay” then rename to the same naming convention (removing “apache-“).

Edit $TOMCAT-NEW/conf/
Search for the line:

Replace the line with this:

Edit $TOMCAT-NEW/conf/server.xml
change each instance of


(three instances, one of which is commented out)

Copy from $TOMCAT-OLD/bin to $TOMCAT-NEW/bin

Delete all contents of $TOMCAT-NEW/webapps

Copy the contents of $TOMCAT-OLD/webapps to $TOMCAT-NEW/webapps

Create directory $TOMCAT-NEW/lib/ext

Copy the contents of $TOMCAT-OLD/lib/ext to $TOMCAT-NEW/lib/ext

Create directory $TOMCAT-NEW/conf/catalina/localhost

Copy the contents of $TOMCAT-OLD/conf/catalina/localhost to $TOMCAT-NEW/conf/catalina/localhost

Review the $TOMCAT-OLD/bin/, you may have custom environmental variables. This is a sample chunk of what gets moved to $TOMCAT-NEW/bin/

and append with

(Be sure to make sure all instances of $TOMCAT-OLD have been replaced with $TOMCAT-NEW).

Test the new install of tomcat by running

If you are starting Tomcat automatically, copy the new over to /etc/init.d/ and the existing symlinks from the proper run levels will be updated as well.

If you have any issues with this process, please feel free to comment below.

Virtuemart 1.1.5 class jfactory not found for Joomla 1.0.15

In a recent effort to migrate an overdue Joomla 1.0.x installation to Joomla 1.5, I hit a snag where the Virtuemart shopping cart needed to be upgraded to be compatible with the migration script. In doing so, this broke the shopping cart checkout on my Virtuemart 1.1.5 instance.

When a user fills their shopping cart with products, then proceeds to the checkout it dumps to a completely blank screen with this error:

Fatal error: Class ‘jfactory’ not found in /var/www/xxx/administrator/components/com_virtuemart/html/checkout.index.php on line 28

Searching around, I did not find too much help with this one other some related posts with other Joomla components which were considered “compatible” with Joomla 1.0.x. This error occurs when the Virtuemart code attempts to use a component that comes with Joomla 1.5 called “jfactory”.

Carefully looking at the jfactory portion of the code, it becomes a bit more clear. It first fills the $lang variable, then uses that to concatenate a variable for $name. Which, for most of us is simply going to end up as “english”. I looked for a way to install jfactory on the 1.x.x Joomla site and I did not find squat.

What I simply ended up doing is removing the $lang and $name lines, and simply removed the if/else clause to force it to use English. The code should end up like this:

I hope you can breath a sigh of relief as I did when this end up working properly to allow orders to start flowing again.