2014 – Year in Review

What an exciting year it was for me! I haven’t had time to really sit down and write a retrospective, but I figure I should probably get around to it before 2015 gets too far off the ground.

It was certainly a busy year. Back in May, I proposed to my wonderful fianceé Sarah, and since then there’s been a lot of wedding planning happening. It’s kept me on my toes trying to make sure that everything’s in order and ready to go for that! Both Sarah and I are extremely excited for the wedding, which is coming up this June.

I spent a lot of the early and middle parts of the year writing a lot of code. Between relaunching my personal site, developing MyLeaf, and working on all of the fun projects like MaltSwap and zabbixweb, I didn’t have a chance to take a step back and reevaluate what exactly my focus was. Fortunately, I was also doing a lot of PHP-related stuff at work, and that was where my wake-up call finally came from. I took the opportunity to refocus and work more on the systems side of things for a while. That said, though, I still want to keep doing development – just more casually than what I was doing before.

My move back into systems led to a lot of opportunities, not just in my main job but also elsewhere. I recently took on another systems job with a local startup, and have been really involved in designing continuous integration and server infrastructure. It’s been a lot of fun, and I’m looking forward to being part of that for a while yet.

That whole thing has really gotten me to the point where I’m passionate about systems again. There was quite some time where I was a lot more interested in code, and it’s good to get back to really enjoying servers and infrastructure. Not to say that my time coding was not time well spent – not only was I pretty productive, but I also learned a lot that I’ve been able to translate back into the systems side of things, especially recently writing some shell scripts to help move us towards true continuous integration.

As many of my readers know, I’ve been reading a lot for a very long time. I’ve made a point recently of making sure I take some time every day to get in some book time, and it’s been really a great way to wind down before bed. Similarly, I’ve been getting on the exercise bike every day as well. It’s all about forming the habit, really: once I got into the routine of getting home and hopping on the bike immediately rather than getting home and hopping on the computer immediately, it became really easy, and I’ve been feeling so much better in general since I started. That bike’s been great value-wise for me, especially considering all it cost me was fifty bucks and a drive out to Grand Island.

Recently, there’s been a nice spurt of development on zabbixweb! If you have time to check it out or throw in some improvements, that’d be pretty awesome.

Anyway, other than that, things haven’t been too eventful. Sarah’s back down for a visit now, which is very exciting. We’re doing a lot of wedding planning, including some shopping this month for various important things. Should be a blast.

I’m hoping to have some news on MaltSwap as well as another new project coming up in the next month. I’ll be sure to keep you all posted.

Quick thanks

Hey, some of you may have noticed the blog was down over the weekend. Thanks to the person who let me know – not sure who you are, but you’re awesome.

It shouldn’t go down again. I was missing a DNS entry after migrating to my new (awesome) DNS provider, Hover, and just had to add it back in.

I’m working on another blog post and am hoping to have it up this week sometime.

Installing Varnish 3 on CentOS 7

Oddly, there isn’t a lot of information on installing Varnish 3 on CentOS 7. There’s well-written instructions on the Varnish site for CentOS 5/6, but for 7, it seems like you’re stuck with Varnish 4 (from the epel-release repository), especially if you’ve searched around and found forum threads like this one.

I did some digging, though, and it turns out Varnish 3 actually does have packages for CentOS 7 – there just isn’t any documentation on how to install them. I played around a little and found something that worked, though. So far, I haven’t experienced any problems installing via the following:

yum install gcc
 rpm -i https://repo.varnish-cache.org/redhat/varnish-3.0/el7/x86_64/varnish/varnish-libs-3.0.6-1.el7.centos.x86_64.rpm
 rpm -i https://repo.varnish-cache.org/redhat/varnish-3.0/el7/x86_64/varnish/varnish-libs-devel-3.0.6-1.el7.centos.x86_64.rpm
 rpm -i https://repo.varnish-cache.org/redhat/varnish-3.0/el7/x86_64/varnish/varnish-3.0.6-1.el7.centos.x86_64.rpm

You do need to install the packages in this order, as Varnish depends on having gcc and the libraries in place.

You may need to adjust the Varnish config and point the pidfile to varnishd.pid instead of varnish.pid in /etc/rc.d/init.d/varnish. If you do, remember to run systemctl daemon-reload and kill all of the active varnish processes before starting the Varnish service again.

Excitement and anxiety

There’s been a lot of excitement in my life recently, especially when it comes to my upcoming wedding. Between favors, venue, food, music, the service itself, and everything else, it’s been a hectic few months of planning, but it’s been a lot of fun too. A lot of the prep’s done now, though, so getting a short bit of time to relax has been nice and hopefully will allow me to start working on some other projects that I’m looking forward to getting to grips with.

One other thing that I’m hoping to find some more time for is playing my violin again. I haven’t touched it in a while now, which I’m a little sad about – but there just hasn’t been time. At the very least, though, I have put together a nice list of things that I want to try when I can find the time – first on that list is the Mozart Concerto in A major, which I’ve listened to a lot recently. I’m really enamored of the third movement.

I know I don’t talk about music a lot on this blog, and I’m not honestly sure why I don’t – I absolutely love music in general, both listening to it and playing it. I think that might be something you see more here in the future, along with the tech stuff.

Anyway, the title of this post was “Excitement and anxiety”, and I swear there’s a good reason for that. I submitted Sarah’s I-129F back in September, and now that we’re coming up on November, I’ve watched the processing times at the relevant visa center (Texas) very closely to see when I’ll be receiving communication – and from the looks of it, it could be pretty soon. The reason this makes me a bit anxious is not because of the possibility of it being declined – something like 99.5% of applications get approved, so no worries there, really – but rather that there’s a lot of stuff that has to be done as soon as I get that notification. Letters to get written, documentation to get put together…yeah. Busy times. Definitely worth it at the end of the day, though.

Anyway, it’s going to be a very busy next couple of months. I’m looking forward to it, but at the same time I’m just going to have to make sure I’m not overwhelmed by all the stuff coming in. Either way, I’ll keep you all posted.

Zabbix web interface up on GitHub

Just a quick note that I’ve added the Zabbix frontend to a GitHub repository. There’s been a lot of interest in this frontend over the last week or so, and to that end I figured it’d be nice to have a place where we could all get together and work on improving it. Feel free to make pull requests and add issues, and we can have a way better Zabbix monitoring solution than what I originally released!

I’m really excited for a lot of the projects coming up for me in the near future. I’m currently starting to learn Laravel, and I’ll probably blog about that pretty soon. I haven’t forgotten about the other posts that I’ve promised, though!

Building a better Zabbix frontend

Recently, I ended up looking into Zabbix as a server monitoring solution. I was very impressed, but I felt that the reporting features left something to be desired; they were very robust, but it was hard to get all the information I wanted on one page.


Zabbix's bulky monitoring screens

Zabbix’s bulky monitoring screens

It was great for monitoring one server on a screen – giving me history of resource usage in pretty graphs and so on – but there really wasn’t a good way to get a view that would give me all of this information in a compact manner for all of the servers I wanted to monitor, at the same time. (Plus, some of the graphs are more than just a little misleading; look at that RAM usage graph! The bottom of the graph is 10 GB – what?!)

So, instead of struggling through Zabbix monitoring using a hilariously bulky system, I took a page out of Phyramid’s book. They used a Node.js server as their monitoring solution, with a prebuilt API client available on GitHub. I thought that was really freaking cool, but there were a few problems that prevented me from implementing an identical solution.


The biggest issue, of course, was that I wasn’t running a Node server, meaning that I couldn’t pull in the zabbix.js library. That meant I had to figure out how to talk to the Zabbix server myself. This was interesting for me, because it meant I had to learn a few different things. First, I had to figure out the Zabbix API itself, which was interesting – the documentation is extensive, but not exactly easy to understand, and the examples are fairly limited. Second, I had to put together something in JavaScript to talk to the API – something of a challenge, because I had no idea where to start with writing my own jQuery plugin. Other problems would arise as the project moved forward, of course, but these were the biggest things that came up immediately.

Learning the API turned out to be a lot easier than I expected. Basically, the only call I needed to actually make to the server was the host.get call. What this one did, when properly filtered, was give me all of the information I needed for every server that I had set up monitoring for, including a full inventory with current usage statistics as well as any errors or alerts associated with the server.

Getting the call to go to the server was a problem, though. My initial implementation of a Zabbix API client was basically just a modification of the Node.js library to make it work in a traditional environment. In fact, it was mostly just plain old JavaScript with a touch of jQuery to do an AJAX call. Was it good? No. But it worked.

My API call returned a bunch of data – quite a bit to sort through, to be honest. It was formatted kind of strangely, too. There were some properties on the top level of the JSON object that it returned, and others that I needed were in an ‘items’ array. Some of these required cycling through multiple entries to get results – like figuring out disk usage when there were multiple hard drives on the system.

The full response that I received from the Zabbix server

The full response that I received from the Zabbix server. So much data to parse through!

I wrote more JavaScript to handle that, naturally. By this time, I’d written more JavaScript than I had for anything I’d ever written before. The page itself was 95% JavaScript (mostly jQuery, to be honest) – the other 5% being the empty div tags that I put the data in! I was able to eventually get everything put together, though, and get it parsed into something usable. All that was left was to get it displaying nicely on the screen.

Displaying the Data

Now that I had all of my Zabbix data, I faced the challenge of actually making it look nice. I settled on a Bootstrap grid layout with meters showing the CPU and RAM usage, with separate text for disk capacities and network stats. Kottenator’s jquery-circle-progress plugin worked really well for the meters – my only frustration was no radial gradients, but at the end of the day that’s really more of a CSS limitation than anything else. It certainly wouldn’t stop me from recommending this plugin.

I wanted to use the meters for disk usage, too, but that just wasn’t an option – some of our servers only had one drive, while others had as many as four. Doing meters wouldn’t have fit nearly as nicely into the grid layout I had planned.

I finished off the first take on the layout with an alert system – whenever something went wrong, like the web service or the server being unreachable, that server’s grid area would flash red, a tornado siren sound would go off, and the screen would display whatever error message that Zabbix threw for that server instead of displaying the meters.

The original frontend design.

The original frontend design.

The first iteration of the display worked fairly well. The data displayed, at least. Unfortunately, it just took up too much real estate per server. I was trying to display the data on a TV hooked up to a Raspberry Pi, and could only fit 8 servers on the screen. It just wasn’t good enough. I had to improve the layout and make it more of an “at-a-glance” display, so I decided to make four major visual changes.


First, I condensed the “Disks” display into a Bootstrap collapsible accordion, meaning that I could just have a button instead of a long list. I went one step further, though – since disk usage is still pretty critical information, I decided it would be best to make sure that critically low disk space would still be visually represented. I used the panel-warning and panel-danger classes to change the color of the button whenever disk usage hit 75% or 90% respectively, and suddenly it became easy to spot potential issues from across the room.

Second, I condensed the text that was displayed for the operating system. Instead of displaying the raw string, I filtered the OS info that Zabbix gave me and output a human-readable string like “CentOS 6.5″ or “Win Server 2008 R2″. I also moved it right next to the name of the server, so everything would appear on one line.

I also swapped the Bootstrap theme to a sleeker, higher-contrast theme, which helped as well; it made it easier to see the board from across the room by providing a bigger difference between the white text and the black background.

Finally, I modified the jquery-circle-progress plugin so that all of the meters were no longer circles – instead, I made them semicircles. This was a bit of a challenge for me, but it both saved space and made the meters more intuitive.

The new Zabbix frontend with all of the changes.

The new Zabbix frontend with all of the changes.

Once I put all of these changes together, it turned out to be a very workable system. We’re now able to display up to 16 servers on the same screen, and it looks pretty beautiful to boot.

We’re currently in the process of getting this display put up on a large screen here in the office so that we can see immediately when a server or web service goes down. So far, it’s been working really well, and I’m excited to put it into production.

Interested in trying it out for yourself? I’ve made a version available for download; please credit me if you use it. If you’re sickened by the awful Zabbix library, check out jqZabbix on GitHub; it’s a much more solid Zabbix API client.

I’ve been doing a lot of cool tech stuff recently, so you’ll probably see more blogs in the same vein as this one soon; I’ve already got one planned for MyLeaf, a “what should I read next” application I built for a friend a month or two ago, as well as a preview of my next big project.

Quick update on installing Apache 2.4 and PHP 5.4 on CentOS 6.5

It seems like this has been a very popular post recently on my blog, looking at the site traffic. That’s really cool, but I want to point out that PHP 5.4 with FPM and Apache 2.4 are currently available on CentOS 7, which can be downloaded from the CentOS website.

Here are the directions for installing Apache 2.4 and PHP 5.4 with FPM on CentOS 7:

yum install httpd php php-fpm

…and that’s it.

If you need some sample virtual host or pool configs, you can still use the samples provided in my previous post.