Ubuntu 16.04: Changing PHP Versions

I was making some changes to a web server recently that I figured I would make a super short blog tutorial about!

Changing From PHP 5.6-7.0

The same instructions will work for pretty much any version of PHP you would like to install or change from. Just change the version of PHP in the commands and you’re good to go.

Firstly, you’ll need to add the public PHP repository. Then you’ll need to update your packages. Then you need to install PHP. I’ve included both versions in case you’re switching one way or the other. It won’t matter if you have both installed, we’ll only be referencing one by the end.

sudo apt-get-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.0 php5.6 php5.6-mysql php7.0-mysql php-gettext php5.6-mbstring php-mbstring php7.0-mbstring php-xdebug libapache2-mod-php5.6 libapache2-mod-php7.0

Once everything has run its course, you can start disabling and enabling which module is being used in Apache2.

sudo a2dismod php5.6; sudo a2enmod php7.0; sudo service apache2 restart

As we all know, there are two versions of PHP that run: Apache2 and CLI. To change the CLI version fo PHP, you’ll have to run the following command.

sudo update-alternatives --set php /usr/bin/php7.0

This means when you run php -v you’ll see PHP 7.0 as your PHP CLI version.

That’s it! Super simple stuff!

Let’s Encrypt The Internet! Installing Free TLS Certificates On Ubuntu 16.04

Why should we install security certificates?

I’m a big proponent of protecting data and encrypting communication on the internet regardless of the source or destination. There are just some things that shouldn’t be shared, and it’s the same reason why all envelopes aren’t made entirely of transparent plastic (recycling aside).

This doesn’t just protect your “data” but the transfer of secure information like your credit card numbers and passwords. You should always be cognoscente of the sites you’re sending your data to, and whether you would be okay sharing that information with a perfect stranger.

Note: most people still like to refer to these certificates as SSL certificates. This is referring to an old and obsolete protocol that used to be used for encryption. The new version, and widely accepted standard today is the TLS encryption protocol. At the time of writing this blog, I’ve successfully installed a TLS 1.2 certificate using Certbot with a strong key exchange (ECDHE_RS with P-256), and a strong cipher (AES_128_GCM) according to the security audit in Google Chrome. (Ctrl+Shift+I > Security tab).

Things you’ll need before moving forward.

I’m going to make the assumption that you’ve taken the time to set up your Ubuntu server and install Apache on it. Specifically that you’ve properly configured your (one or more) domains in separate Virtual host files that specify the ServerName.

Let’s get encrypting!

Firstly, you’ll want to add the Certbot repository to your list of software repositories. To do this, run the following command.

sudo add-apt-repository ppa:certbot/certbot

Once that’s finished running its course, you’ll want to pull the latest version of all of your software repositories.

sudo apt-get update

Finally, you can install the Certbot client using the following command.

sudo apt-get install python-certbot-apache

Ubuntu will then take a few moments to install the required software and the client on your system. You’re finally ready to install your TLS certificate on your server.

TLS how to install it! (hah, encryption pun)

This step is actually exceedingly easy. I was very pleased at how simple it was to install, and I think you’ll really enjoy it too.

To run the Certbot installation script and install your certificate into your Virtual Host in one shot, run the following command.

sudo certbot --apache -d yourdomain.com

You can add more domains to this single certificate by specifying multiple domains. Just flag on another -d www.yourdomain.com and you’re flying!

The installation script will walk you through a few questions regarding an administrative email address, accepting their terms of service, and whether or not all traffic will be going through HTTPS or not. It’ll look something like this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):support@[redacted]

Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree in order to register with the ACME server at https://acme-v01.api.letsencrypt.org/directory
(A)gree/(C)ancel: a

Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about EFF and our work to encrypt the web, protect its users and defend digital rights.
(Y)es/(N)o: y
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for [redacted]
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate for [redacted] to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether HTTPS access is required or optional.
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

Congratulations! You have successfully enabled https://[redacted]

You should test your configuration at:

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/[redacted]/fullchain.pem. Your cert will
   expire on [redacted]. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again with the
   "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

They even offer up an easy way to renew your certificate when it eventually expires! Fantastic!

I have to renew this thing every few months?!

Yep! These free certificates will expire every 90 days. There are technical reasons why they would want you to renew your certificate, like renewing your encryption keys to reduce the risk of decryption. Other than that, it’s nice to automate auto renewal, so you never have to think about this again (almost).

We’ll be using our handy-dandy cron to manage our renewal.

sudo crontab -e

This will prompt you to select a text editor. Vim is my preferred, so I select 3. Add the following line at the bottom of your file to schedule your task to run every day at 4:15am.

15 4 * * * /usr/bin/certbot renew --quiet

:wq to write/quit in Vim and you’ll see a friendly little installation message.

You can opt to run the renewal script less frequently, but since it checks and only updates certificates set to expire in less than thirty days, you won’t be wasting very many precious CPU cycles.

Lastly, since we installed the certificate with the --apache flag, it’ll automatically reconfigure the Apache server every time it renews. This means less server maintenance and downtime!

Final Thoughts

Encryption used to be a very painful process, and even though cPanel and WHM made it easier than before, it was never a simple or pleasant process. I would spend at best 20 minutes to an hour waiting for email verifications, installations, and whatever else these Certificate Authorities required to get everything up and running. With Certbot and Let’s Encrypt, I was encrypting and serving an existing Apache site in less than five minutes.

Overall, I’d have to say I’m very happy with the process. I’m even happier about the cost, time, and effort savings. Now… if they’d only release a logo or badge of some sort for sites that want to promote the use of their services… How am I supposed to let other people know how awesome you are without a sticker on the back of my laptop and the bottom of my website!? 😉

– Cole

Prevent XML-RPC Brute Force Attacks – WordPress on Ubuntu 16.04


In my foray into cloud hosting, I’ve noticed that a few of our servers started to peak in their CPU usage more than what normal web traffic would cause(2-5% and 10-30% on our t2.medium and t2.small AWS EC2 servers respectively). After looking at the Apache2 logs, I found that there was a significant number of hits trying to look for combinations of phmyadmin, db, sql, and many other url keywords. This is obviously bothersome, but we’re all secure, so it didn’t cause much of an issue.

What did cause worry was the sheer number post requests to the /xmlrpc.php file. The IP addresses appear to be located in russia, and there were a handful different IP addresses that all had very similar origins. I’ve obscured the starts, but the IP range was ***.***.204.7-12. There is obviously enough traffic to blip our CPU usage on the medium server and enough to task the small server in a big way. To be more exact, there were ~78,000 requests in the log originating from those IP addresses over the past few days.

Why Is This Happening To Me?

There are many reasons hackers would like to gain access to your hosting server. One of the major reasons may be to steal resources to mine or farm bitcoin or some other cryptocurrency.

XML-RPC allows for very efficient brute force hacking, as it allows for hackers to check many username/password combinations in one single request. This is all at the cost of giving developers access to remote procedure calls.

XML-RPC Solution: Apache2 Deny From All

As I don’t use WordPress mobile, or other applications/plugins that require external access, I’ll be disabling access from external addresses.

The simplest solution to blocking this type of traffic on an Apache2 server is to simply deny access to the /xmlrpc.php file itself. To do this, you just have to add a few lines to your site configuration files in Apache2.

sudo vim /etc/apache2/sites-available/*yoursitehere*.conf

Your VirtualHost configuration should look something like the example below after adding the bolded lines.

#Some stuff
    <files xmlrpc.php>
      order deny,allow
      deny from all
      # you can allow from your own IPs using the following line
      # allow from ###.###.###.###

Finally restart Apache2 and you’re on your way to preventing hackers from eating up your server availability.

sudo service apache2 restart

XML-RPC Solution: Security Plugins

Note: This may be a better solution for those of you who wish to use applications that require XML-RPC to function properly.

There are some security plugins that will either deny access to the file, blog IPs that are abusing the service, or will disable XML-RPC altogether. Jetpack is one of those security plugins that will aid in blocking brute force attacks. WordFence and it’s firewall are really great for blocking IP addresses that are abusing your servers with irrelevant traffic.


If you do decide to utilize a security plugin, keep in mind that their scans and extra filtering procedures may have an adverse effect on your servers speed and responsiveness as well. This is sometimes a necessary evil, but you should plan ahead accordingly.

Blocking access to certain system files may prevent you from accessing certain features. However, you may find your site security more important than whatever feature that may be.

After having denied access to the file, we’re back down to our low utilization on the t2.medium server of <1%. I’m glad to see my CPU Credit Balance stabilize!

Hardening Apache2 on Ubuntu 16.04 LTS with Vim and Vigour!

There really isn’t much that’s more important than securing your web server when launching a website. Most of your development tasks are completed (hopefully), your designs are wonderful, and your designers are excited to finally get this project off their plate. So how do we go about securing our web server after launch?

Today, I’ll be talking specifically about the Apache2 web server. The particular flavour of Linux OS that I’ll be addressing is Ubuntu 16.04 (Debian also) considering it seems to be one of the most frequently used web servers today. There are some minor file location differences with RHEL/CentOS/Fedora, though not major. There are other tutorials addressing the particulars floating around. So I won’t include them here.

I’ll be using my favourite command line text editor Vim, but feel free to replace any vim command with nano if you’re more familiar with. I’ll include some basic information to help you through using Vim if you’re unfamiliar.

Shut-out Server Specification: Hide Your Server Version and OS Details

When hitting a server display page like a directory listing or a 404, you may notice that there exists a small colophon reading your servers version, IP, and Port. You can get rid of this tidbit of revealing data by changing some code in your Apache2 configuration files.

Type sudo vim /etc/apache2/apache2.conf to edit the file.

You may quickly notice a nice little message describing that your configuration file has been split for simplicity at the top. Always read documentation!

# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See http://httpd.apache.org/docs/2.4/ for detailed information about
# the directives and /usr/share/doc/apache2/README.Debian about Debian specific
# hints.
# Summary of how the Apache 2 configuration works in Debian:
# The Apache 2 web server configuration in Debian is quite different to
# upstream's suggested way to configure the web server. This is because Debian's
# default Apache2 installation attempts to make adding and removing modules,
# virtual hosts, and extra configuration directives as flexible as possible, in
# order to make automating the changes and administering the server as easy as
# possible.

# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
# /etc/apache2/
# |-- apache2.conf
# | `-- ports.conf
# |-- mods-enabled
# | |-- *.load
# | `-- *.conf
# |-- conf-enabled
# | `-- *.conf
# `-- sites-enabled
# `-- *.conf
# * apache2.conf is the main configuration file (this file). It puts the pieces
# together by including all remaining configuration files when starting up the
# web server.
# * ports.conf is always included from the main configuration file. It is
# supposed to determine listening ports for incoming connections which can be
# customized anytime.
# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
# directories contain particular configuration snippets which manage modules,
# global configuration fragments, or virtual host configurations,
# respectively.
# They are activated by symlinking available configuration files from their
# respective *-available/ counterparts. These should be managed by using our
# helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See
# their respective man pages for detailed information.
# * The binary is called apache2. Due to the use of environment variables, in
# the default configuration, apache2 needs to be started/stopped with
# /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not
# work with the default configuration.

The actual file will be located in a separate configuration folder. Press esc to enter command mode and type :q or :q! if you accidentally changed the file to exit the file in Vim.

Type sudo vim /etc/apache2/conf-enabled/security.conf to edit the file containing security features.

Look for the string ServerSignature by typing /ServerSignature in Vim command mode (press esc at any time to enter command mode). You can use the arrow keys or h,j,k, and l to move your cursor left, down, up, and right respectively in command mode.

press i to enter text edit mode. This is the mode that you will be most familiar with when typing using a keyboard. Press esc to go back into command mode.

Change the following variables as follows:

ServerSignature Off
ServerTokens Prod

Once you’re done editing the file, enter command mode (esc) and type :wq to write the file and quit. If you’ve messed up the file, feel free to :q! to forcefully quit the file and ignore all changes as :q may not do the job alone. Typing u in command mode will undo any changes you’ve recently made as well, if that suits you better.

Once you’re back in the Ubuntu command line, restart the server by typing sudo service apache2 restart

Now when you visit the same 404 or directory listing page, you won’t be seeing that server signature! Congrats on completing step one!

Disable Detailed Directories: Hide Directory Listing and Files

Your Apache2 server will want to list out all the directories and files if you don’t have a base index.html or index.php (or other if specified in Apache2) in your directory. You can hide this functionality by adding a simple line of code to your apache2.conf file.

Type sudo vim /etc/apache2/apache2.conf to edit the base configuration file and hide directories from all sites located in your web folder.

Type /Directory /var/www/html to find the code you need to edit. It should be a block that looks like this:

<Directory /var/www/html>
 AllowOverride All

Just below AllowOverride All you’ll want to add Options -Indexes. You should end up with this.

<Directory /var/www/html>
 AllowOverride All
 Options -Indexes

Once you’ve changed your code, :wq out of the file and restart your server with sudo service apache2 restart. Once you hit a directory, you’ll now find a message forbidding you from accessing that folder. Congrats on completing step 2!

Write Where We’re Willed: Web Server File Permissions

Web servers are left open to hackers when using open file permissions (777 or -rwxrwxrwx / drwxrwxrwx). It’s important to make sure that your web server is given proper permissions to access and write directories, without opening them to hackers and visitors.

One simple way to do this is to disable write and execution tags where applicable in the permissions for folders and files. Permissions use binary triplets to turn on and off permissions. First, the base ten digit is converted to binary, and those positions turn on and off file and folder features.

To change all directories within your web folder to 755 (rwxr-xr-x):

find /var/www/html -type d -exec chmod 755 {} \;

To change all files within your web folder to 644 (rw-r--r--):

find /var/ww/html -type f -exec chmod 644 {} \;

These permissions not only work well for statically built websites, but also for content management systems like Magento and WordPress.

Updating Ubuntu: Specifically Apache2

Updating your server, and specifically updating Apache2 is very important. You’ll want to make sure you’re updating regularly to make sure the most important security patches have been applied.

Firstly you’ll want to update your package information by using sudo apt-get update

If you’d simply like to install updates for Apache2, just type sudo apt-get install apache2. You should be returned a message that looks something like the following.

Reading package lists... Done
Building dependency tree
Reading state information... Done
apache2 is already the newest version (2.4.18-2ubuntu3.3).
0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded.

As you can see, I have 21 packages that are not upgraded on my server. If you’d like to update all of these packages, you can type sudo apt-get upgrade.

If you’d rather view the packages that need updating and install them one by one (using a command similar to the one for apache2), you can do so by typing sudo apt-get upgrade --dry-run or /usr/lib/update-notifier/apt-check -p for a simpler return.


These are only a few of the many ways you can harden your Apache2 web server. I’ll be adding to and maintaining this list as time passes, but there are a few extra things you’ll want to be sure to check out.

HTTPS and SSL Certificates

You’ll want to make sure that you’re installing SSL Certificates on all of your sites. Whether they’re extended validation or self signed, this can help keep traffic encrypted, and your users feeling safe. There are many other reasons to install SSL, a big reason is that Google promotes sites that use it more than ones that don’t (for obvious reasons). With tools like Lets Encrypt there really is no reason not to install a cert on all of your servers.

Firewalls Firewalls Firewalls

Personally, I like to host on AWS where their console and security features allow for very strict access to your cloud network infrastructure. If you don’t have access to such strong security measures on your own personal server, you’ll want to ensure that you take advantage of the firewall tools available in Ubuntu.

If you have any questions, make sure you comment below!

Cole Speelman

Installing, Configuring, and Maintaining MySQL on Ubuntu 16.04 LTS

This will be a relatively short informative blog regarding how to setup and secure an installation of MySQL on Ubuntu.

MySQL Server Installation

Firstly, update your package library and install your MySQL server.

sudo apt-get update
sudo apt-get install mysql-server

You’ll be prompted to create a root password during the installation. Make sure it’s a complicated password that you’ll remember, because you’ll be needing it.

MySQL Server Configuration

You’ll want to be sure to harden security on your MySQL installation by running the security script.

sudo mysql_secure_installation

This will prompt you to enter your root user password that you created during installation.

Firstly, the setup will ask if you would like to install a VALIDATE PASSWORD PLUGIN that can test passwords and improve security. If you’re the only one administering databases and are diligent about using great passwords, you opt-out.

Second, it will ask if you’d like to change the root password. If you’re having second thoughts about your password strength, you can change it now.

Third, it will ask if you would like to remove anonymous users. I typically use applications like WordPress and Magento, so I always have database users created out of the gate. I opted to remove anonymous users, but you may decide to run this script again before launching your site and remove them at a later date.

Fourth, it will ask if you would like to disallow root user remote access. I strongly suggest enabling this, especially considering that we’ll have phpMyAdmin installed shortly, removing any need for this.

The last two questions are to remove the test database, and to reload the privilege table, both of which I answered yes, as I won’t be needing the test database, and the privileges are important.

Server Status

To check the status of MySQL server you can run the sudo service mysql status command. If the server is not running, you can start it with sudo service mysql restart or sudo service mysql start.

Reset MySQL Root Password

You may find yourself in the situation that you have forgotten your root password. This recently happened to me after I jumped into a server that I had not maintained in quite some time (it was development, don’t worry).

The first step to resetting your password is to gain access to the terminal (ssh is typically what I use). Once you’re in, you’ll want to stop the MySQL service.

sudo service mysql stop

Once you’ve stopped running your server, you’ll need to prep the next command by creating a folder for it to access.

sudo mkdir /var/run/mysqld
sudo chown mysql: /var/run/mysqld

You can start the server with a few options that I’ll explain.

sudo mysqld_safe --skip-grant-tables --skip-networking &

The --skip-grant-tables flag turns off the need for authentication, and the --skip-networking flag turns off the ability to access the database remotely (important when authentication is disabled).

Once you’ve run the server, enter the mysql command line tool, and change the password.

sudo mysql

For MySQL 5.7.6 and later:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewPassword';

For MySQL 5.7.5 and earlier:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('YourNewPassword');

Then you’ll need to reboot your MySQL server.

#Shut down MySQL
sudo mysqladmin -S /var/run/mysqld/mysqld.sock shutdown

#Start the MySQL service normally.
sudo service mysql start

From there on out, you can use whatever you set as YourNewPassword to access root functionality.


MySQL is fun. Don’t get bogged down with the basics! With this basic installation information, you’ll be well on your way to working with databases and enjoying all that relational databases have to offer!

Cole Speelman

My Favourite Stock Photo Sites

I’m sure it’s not just me that finds it incredibly hard to find relevant stock photos. For those of you in perpetual search of good stock images, look no further.

This is a list of my current favourite stock photo sites with a Creative Commons Zero license (CC0) images.


This site is usually the first site I visit when I go on the search. You may need to create an account to download the highest resolution image, but it’s not the type of account that will land you on a spam list. This site has my personal seal of quality.

IM Free

Lots of great stuff here. A little more than stock photos is offered here. The site includes many items including templates and icons. What more could you want from a site giving you free stuff! Stop complaining!


Ten new stock photos every. My favourite feature on this site would be the collections. This feature makes it that much easier to find a consistent set of free images for you to use. Bravo Unsplash… Bravo.


This site features an awesome layout and great navigation. The images are super vibrant and are really quite eye catching. Quality is definitely king on this site. I’ve used it many a time and am thankful for its existence.


I saved the best for last. I absolutely love this site. Some of the images leave me completely incredulous while others are just plain bizarre or creepy. It’s great fun taking a look through when you’re bored. Thank you Ryan McGuire.


(Added 8/11/2017) My front-end designer just brought this site to my attention! It’s got a great source of photos and really cut and dry licensing. Thanks Erin!

The Value Of Good Web Design

I came across an article on one of my favourite blogs/websites and thought I’d share. I encourage everyone who reads this to continue on and read the original article as well.

I, Website

I was having a conversation with a friend recently about the value of being unique in video game creation. The conversation led me to think about how I evaluate different things in my life. I found myself asking questions I may not have thought to ask myself when making assessments. Should we value unique idea more than ideas that are recycled? What if the execution of the recycled is better than the original? Should we give appreciation to those that create, or those that revolutionize?

Our conversation and the above article made me think about the way programmers create in modern society. We live in a world where open source affords us the incredible ability to steal ideas and cheat our way through solutions, but find ourselves contributing to the community instead. We find dedicated communities that build amazing solutions to problems that we all have, and are all able to share in the value of a finished project.

That left me to think about how we build websites (or anything with code, really). Are we stealing every time we use a code snippet or open source project? Should our work be devalued for using an existing solution to supplement one of our own? Where do we draw the line, as developers, in saying that something is built from scratch? Can we consider anything built from scratch?

As we build better creation tools, higher level programming languages, abstracted development processes, scratch becomes farther and farther from where we started. For example, tools like Sass and Less allow us to create CSS programmatically and save time. Does this mean the final product has a lesser value because we were able to complete it with greater ease and in less time? Should we assign it a greater value, considering the extra time and effort that went into learning the tools? The answer seems pretty simple when it comes to investing time into learning another language, but where does that answer land when we look at website building tools like Squarespace?

I’ve seen web developers go from writing lines of HTML, CSS, and JavaScript for hundreds of dollars to dragging and dropping widgets for thousands.

I guess it all comes down to the end result.

What’s in a name? That which we call a rose
By any other name would smell as sweet.

Fun Lorem Ipsum

I think it’s safe to say that anyone developing or designing has used Lorem Ipsum at some point. Lorem Ipsum, to break it down to its basic use, is dummy text. It helps developers/designers see what real content in an area would look like. This helps when you’re looking to change line-height, font sizes, font faces, or many other options. It also helps developers create sections that flow with the amount of content that will be input.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed sodales maximus ipsum, vitae sodales orci luctus a. Vestibulum feugiat bibendum ex, sed elementum dolor bibendum faucibus. Sed non metus nibh. Donec at feugiat felis. Integer at nisl libero. Sed congue dignissim dignissim.

As you can see, it can be quite boring. So, a few good people decided to spice things up a bit. Here’s a few of my personal favourites, and their links for you to use.

Samuel L. Ipsum (censored for content, sorry)

Look, just because I don’t be givin’ no man a foot massage don’t make it right for Marsellus to throw Antwone into a glass mother******’ house, ******’ up the way the ****** talks. Mother****** do that **** to me, he better paralyze my ***, ’cause I’ll kill the mother******, know what I’m sayin’?


Pabst pitchfork salvia, craft beer heirloom gochujang four loko pickled. Cronut sartorial kickstarter YOLO green juice, seitan biodiesel. Quinoa four dollar toast cornhole knausgaard plaid cred. Ethical keytar pickled, gluten-free wolf vinyl art party tacos butcher master cleanse typewriter austin.

Cupcake Ipsum

Cupcake ipsum dolor. Sit amet dessert jelly-o powder cake lemon drops halvah gummies. Sweet bonbon halvah powder sweet muffin. Cookie croissant pudding pudding. Topping brownie icing chupa chups sugar plum bear claw. Sweet roll sugar plum cookie candy canes dragée donut bear claw.

Bacon Ipsum

Bacon ipsum dolor amet shoulder corned beef pork chop porchetta swine prosciutto frankfurter ball tip venison cow. Alcatra spare ribs frankfurter beef ribs pork cow. Ground round swine tri-tip, pig kielbasa short loin beef hamburger. Shankle porchetta pork capicola salami leberkas biltong short loin.


Hello World

I’ve finally decided that I would like to have a blog.

Why a blog? Mainly, I’d like to resolve and track problems while having a recorded set of instructions that I can visit when the problem eventually turns up again. Partially, I’m getting tired of all the nonsense on social media, and would like a more intellectually stimulating outlet to air my thoughts.

That leaves me with the task of writing my first blog and setting the tone for future blogs to come. To that, I say what I’ve been conditioned to output on any primary run.

Hello World!