For The Love of Coffee!

Greetings,

 

I apologize in my latency for getting videos up for my most recent posts. I have been fairly swamped between studying for Linux + and working. All this work and studying is only possible due to my best friend in the entire world…yup, you guessed it…Coffee!! In this lighthearted post, I will cover a few of my favorite coffee making methods and a few of my favorite coffee blends. I’m eager to see what kind of coffee preparation methods and coffee blends the rest of you in the caffeinated IT world use, please comment with your own methods and blends.

 

It’s All About That Grind

One of the most surprising things in my journey to becoming an ultra caffeinated coffee snob is the incredible difference the grind makes. When I refer to the grind I not only refer to how fine or course the grind is, but also the method in which the coffee is ground. There are fundamentally two different kinds of grinders out there…the blade grinders and burr grinders. Blade grinders are your standard coffee grinders with a flat blade that essentially chop the coffee over and over again into a grind. While these are fairly effective at grinding, there are a couple of things they don’t do so well. If you’ve ever tasted the difference between chopping cilantro with a knife vs crushing it with a mortar and pestle, you’ll know where I’m going with this. The longer you grind with a blade grinder, the hotter the coffee gets, which can lend a burnt taste to your grounds. Additionally the consistency in the grind provided by blade grinders is moderately inconsistent. Enter the burr grinder.

Burr grinders are a familiar site in most coffee shops, we’ve all seen the large grinders with the large bean hoppers. There are much smaller versions available for home use, both in electric and hand grind options. Burr grinders function by crushing the coffee either between 2 conical cogs (similar to an old school pencil sharpener) or by crushing the bean against a flat surface with a grinding cog. The result is that the beans are crushed in a way that provides a consistent smooth grind without the heat of a blade grinder, and with the flavor that can only be unlocked by pulverizing a bean through crushing rather than chopping away at it. At a previous job, I tried a blind taste test with a few of my coworkers, giving them the same blend of coffee one prepared with a blade grinder and one with a burr grinder. The results were overwhelming, most of them thought the burr ground coffee was a completely different blend. If you don’t believe me, try it yourself, I’m sure you’ll never go back.

 

Favorite Brewing Methods

There are countless methods of brewing coffee, many of which I have never tried but hope to someday, including the siphon brew methods. Personally I am a super busy person always in a hurry and looking for the strongest cup of Joe I can get my hands on. My preferred methods tend to be an espresso maker or the good old french press. I’d be interested to hear what others are using for their prep methods.

 

Top 3 Favorite Coffee Blends

  1. Ravensbrew Dead Man’s Reach:  Hands down my favorite coffee blend. This wonderful brew was recommended by another coffee loving IT colleague, and certainly the best I’ve run across in a long time. Dead man’s reach is a very dark brew coffee that’s extremely aromatic, packs a nice caffeine kick and never ceases to satisfy. This coffee is great every way I’ve made it, and goes great with cream or black.
  2. Kicking Horse Hoodoo Joe: Kicking Horse coffee has been a long time favorite of mine. I think I have had nearly every blend of coffee these guys produce. I have yet to find a coffee of theirs I don’t like. One of my favorite things about Kicking Horse in general is that all of their coffee is really low in acidity, which is fantastic, because no one likes acidic coffee on an empty stomach. Hoodoo Joe is the absolute darkest Kicking Horse coffee out there. This blend is a shade grown dark roast coffee that’s aromatic and has a nice full body flavor
  3. Sleepy Monk: Of course hailing from the Pacific Northwest I am inclined to plug a local favorite. Sleepy Monk is a local coffee roaster on the Oregon coast, this is by far one of the strongest coffees I’ve ever had both in flavor and punch…Seriously, this one will blow your hair back if you’re not ready for it. Anytime I travel to the coast, I’m always keen to stop at the little road side stands that use Sleepy Monk coffee, this is a nice way to keep awake on the ride home after a long day at the beach.

 

Hopefully I will be finished up with Linux + in the next couple of weeks and will get back on track with posting more regularly. Thanks for hanging in there with me. I look forward to your comments regarding your favorite coffees, preparation methods, and what sort of grinding methods you’ve used.

Monitoring Your Servers for Free (Part 4)

It has certainly been a month of monitoring blog posts over here! I have been running a little behind schedule thanks to this chest cold I caught, however I’m on my way to recovery and with a little coffee and determination we’ll get back to it! This post will be the epic conclusion of our monitoring your servers for free series. For this demonstration we will use the Turn Key Linux virtual appliance for Observium built on top of Debian Wheezy. If you’d like to install Observium on your RHEL or CentOS server, instructions can be found at http://www.observium.org/wiki/RHEL_Installation

 

 

Download & Deploy TurnKey Linux Observium Virtual Appliance

To download the appliance visit http://www.turnkeylinux.org/observium. You will have several choices as to what format you want to download the appliance in. If you are using Hyper-V I would recommend using the ISO, however since I will be using VMware ESXi 5.5 we will download the OVA template. Once it’s downloaded to your local machine follow the steps below:

  1. Unzip the OVA template
  2. Open vSphere client and click File>Deploy OVF Template
  3. In the Deploy OVF Template wizard click Browse and point to the OVF template you unzipped
  4. Proceed through the remaining steps in the wizard customizing as appropriate for your environment
  5. Power on the Turnkey VM and open the console
  6. Proceed through the setup wizard for the virtual appliance

 

Prepare Windows Servers for Observium

Before we can begin reporting data to Observium, we must first ensure that we have enabled SNMP. This can either be done through server manager using the add roles/features wizard. In addition you will need to ensure that the hostname the servers you’re monitoring can be resolved Observium, this may require entries into your local DNS server if DNS entries do not already exist, or entries into the /etc/hosts on the Observium server.

  1. Install SNMP (see above)
  2. Restart the Server (the SNMP options needed aren’t active until after reboot)
  3. Open Services (run command: services.msc)
  4. Double click the SNMP service
  5. Click the Security Tab
  6. Add a community name (ie: Observe)
  7. Add the IP of the Observium server to the “Accept SNMP packets from these hosts” list
  8. Open a browser and navigate to your Observium server’s web page and login
  9. Under the devices menu choose add device
  10. Provide the hostname
  11. Choose SNMP v1
  12. Enter SNMP community name set in step 6 and click add device
  13. Wait a few minutes for Observium to begin collecting data on your new server

 

Monitoring Linux Servers and Cisco Equipment

While I typically use New Relic for Linux monitoring, Observium has published instructions for adding Linux servers. Additionally there are also instructions available for adding Cisco switches and firewalls. Again the gotcha here is that A records must exist in local DNS or entries must be created in /etc/hosts on the Observium server, as all devices are managed by hostname not by IP.

Linux: http://www.observium.org/wiki/NetSNMPd_Client_Configuration

Cisco: http://www.observium.org/wiki/Cisco_IOS_SNMP_Configuration

 

Video

Coming Soon!

Monitoring Your Servers for Free (Part 3)

As we have reached part 3 or 4 in our series on monitoring your servers for free, I would like to take a moment to highlight a few gotcha with Nagios before moving into our final section where we will setup graphical monitoring with Observium. At this point we’ve gone through building our a Nagios server, setting up contacts, monitoring printers, as well as monitoring both Windows and Linux servers. There are certainly a few issues you are bound to encounter on your journey with Nagios monitoring. These issues cost me hours of struggle, digging, testing, and ultimately coming upon a resolution. I would like to pay forward some of this effort in the hope that I can help save some poor soul out there the time, effort, untold amounts of silent cursing and coffee drinking.

 

Monitoring SQL Express

Chances are if you have been a Windows administrator for very long and have deployed and application server or two, you have undoubtedly had to setup at least one SQL Express database. The challenge of monitoring SQL Express with Nagios is that our friends at Microsoft have created a service name that contains a dollar sign (MSSQL$SQLEXPRESS). The challenge is that the $ character must be escaped using $ in order for Nagios to correctly read the service name. Use the following service definition below as reference for making SQL Express play nice with Nagios.

define service{

use generic-service

host_name host.example.com

service_description Service: SQL Server – SQLEXPRESS

check_command check_nt!SERVICESTATE!-d SHOWALL -l MSSQL$$SQLEXPRESS

}

Nagios localhost Warnings for HTTP

On your Nagios server you may encounter a yellow warning message regarding the HTTP service. The reason for this is that the NRPE client running on Linux servers is checking to ensure that apache is running and that it can locate and index file within the default docroot for apache. Resolving this issue on your Nagios server can be as simple as creating a blank file called index.html in the /var/www/html directory. A simple way to accomplish this is to use the touch command (ex touch /var/www/html/index.html

Once you create this dummy file you will need to restart apache (service httpd restart on RHEL or service apache2 restart on Debian variants) as well as the nagios service (service nagios restart).

 

Nagios Error When Rescheduling a Service Check (Error: Could not open command file ‘usr/local/nagios/var/rw/nagios.cmd’ for update!)

This and the SQL Express issue may very well be the most aggravating Nagios issues I encountered in my first deployment. However through being highly caffeinated and stubborn I did eventually find a solution. The root of the problem is that there is a permission setting that is getting flipped each time the Nagios service restarts. I have seen a few different fixes for this issue that both work. The first method I have seen corrects the problem at its root by correcting the broken permissions. However if this doesn’t resolve the issue for you, another alternative is to use a script that resets the permission each time the Nagios service runs. I recommend attempting the first method first as it is the more preferable fix, however if this doesn’t resolve your issue, try method two. Please note, terminal commands are in italics

Method 1:

#usermod -G nagios apache

#grep nagios /etc/group (ensure that the result shows that nagios is part of the apache group)

#service httpd restart (substitute apache2 instead of httpd on Debian based variants)

 

Method 2:

Alex Nogard’s blog lays out the methodology for creating a script that fixes the permission each time Nagios starts by adding the script into init.d/nagios. Please follow the link below for his instructions:

http://en.alexnogard.com/error-could-not-open-command-file-usrlocalnagiosvarrwnagios-cmd-for-update/

 

Automating NRPE Agent Deployment Through Puppet

Although outside the scope of this particular discussion, one way to automate deployment of NRPE throughout multiple web servers is to use puppet to facilitate this. I will perhaps visit this topic in later posts regarding Puppet Labs, however I will sum this point up quickly in a nutshell before we wrap up. If you have an existing Puppet infrastructure, you can simply have Puppet add the EPEL repo to each LAMP server, create an ensure installed statement to ensure that NRPE is installed, and finally push out a preconfigured nrpe.cfg that contains the correct server information for your Nagios server (located in /etc/nagios).

 

That brings me to the end of part 3 in our series on monitoring your servers for free. In the next installment, we’ll take a look at deploying Observium to give us graphical output for our servers. Til next time, may the coffee be endless and the uptime in your favor!