Lesser-known but extremely handy Linux tools

Kristóf Kovács has a fantastic post about some lesser-known Linux tools that can really come in handy in different situations.

If you haven't tried dstat (I hadn't until I saw Kristóf's post), this is a great one to try. You can keep a running tally on various server metrics including load average, network transfer, and disk operations.

Here is some sample output:

----total-cpu-usage---- ---paging-- ---load-avg--- ------memory-usage----- -net/total- ---procs--- --io/total- ---system-- ----tcp-sockets----
usr sys idl wai hiq siq|  in   out | 1m   5m  15m | used  buff  cach  free| recv  send|run blk new| read  writ| int   csw |lis act syn tim clo
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|1314B  180B|  0   0   0|   0     0 |  70    80 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|1779B 1004B|  0   0   0|   0     0 |  84    78 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M| 904B  362B|1.0   0 1.0|   0     0 |  75    86 | 13   9   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  386M|2203B 1559B|  0   0   0|   0     0 | 180   127 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  386M| 260B  130B|  0   0   0|   0     0 |  53    66 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|  52B  114B|  0   0   0|   0     0 |  54    77 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|2271B  872B|  0   0   0|   0     0 |  94    79 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|  52B  130B|  0   0   0|   0     0 |  54    74 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|1126B 1254B|  0   0   0|   0  24.0 |  80    87 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.07 0.25 0.25| 866M  249M  537M  387M|1030B  130B|  0   0   0|   0     0 |  88    82 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M| 578B  114B|  0   0   0|   0     0 |  53    64 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M|1597B  890B|  0   0   0|   0     0 |  85    79 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M| 552B  114B|  0   0   0|   0     0 |  63    77 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M|1624B 1254B|  0   0   0|   0     0 |  81    75 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M| 478B  114B|  0   0   0|   0     0 |  67    73 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M| 418B  114B|  0   0   0|   0     0 |  59    74 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M|1265B  874B|  0   0   0|   0     0 |  82    73 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M| 758B  114B|  0   0   0|   0     0 |  60    80 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M|1236B 1255B|  0   0   0|   0  4.00 |  93    79 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.06 0.24 0.25| 866M  249M  537M  387M|  52B  130B|  0   0   0|   0     0 |  71    70 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.05 0.23 0.25| 866M  249M  537M  387M| 214B  114B|  0   0   0|   0     0 |  55    73 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.05 0.23 0.25| 866M  249M  537M  387M|1201B  890B|  0   0   0|   0     0 |  80    80 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.05 0.23 0.25| 866M  249M  537M  387M| 108B  114B|  0   0   0|   0     0 |  53    66 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.05 0.23 0.25| 866M  249M  537M  387M|1344B 1254B|  0   0   0|   0  10.0 | 119    85 | 13   7   0   0   5
  0   0 100   0   0   0|   0     0 |0.05 0.23 0.25| 866M  249M  537M  387M| 172B  130B|  0   0   0|   0  8.00 |  80    82 | 13   7   0   0   5

Learn more about dstat on Dag Wieërs' site.


Performance and redundancy boost for icanhazip.com

It's been a few years since I started a little project to operate a service to return your IPv4 and IPv6 address. Although there are a bunch of other sites that offer this service as well, I've been amazed by the gradually increasing traffic to icanhazip.com.

Here's a sample of the latest statistics:

  • Hits per day: 1.8 million (about 21 hits/second)
  • Unique IP addresses per day: 25,555
  • Hits per day from IPv6 addresses: 1,069 (a little sad)
  • Bandwidth used per day: ~ 400MB

The site is now running on multiple Cloud Servers at Rackspace behind a load balancer cluster. In addition, the DNS records are hosted with Rackspace's Cloud DNS service.

This should allow the site to reply more quickly and reliably. If you have suggestions for other improvements, let me know!


Getting a Technical Job at Rackspace

You've probably noticed that the blog has slowed down a bit recently. Part of the slowdown is due to an uptick in work required to get OpenStack Nova and its related software up and running at Rackspace for Cloud Servers and another part of it is a severe case of writer's block. I threw out some questions on Twitter about the topics people would like to see covered in some new posts and a commonly requested topic was employment at Rackspace.

Boromir - One Does Not Simply Get a Job at RackspaceFirst things first, getting a job at Rackspace isn't easy. We don't intentionally make the process difficult. It's just that the work we do is unique and demanding.

We work in a fast-paced, extremely dynamic team-centric environment. While some people in the company work in extremely small teams or sometimes all by themselves, that's pretty few and far between. We look for people who can survive and flourish in this atmosphere and we look for people who can do it all while working as a team. Even with all of this hustle and bustle, we still remember why we're doing it: the pursuit of Fanatical Support for our customers.

Another thing to keep in mind is that there's no true secret for making it through the application process. There's no magic combination of skills or "silver bullet" that will scoot you through. Every candidate is reviewed individually for each position. There have been several times at the end of an interview where we've gotten together and said: "Wow, this candidate is solid, but they're just not right for this position. Let's find the right spot and see if there's a spot open." We look for the right candidate for the right position at the right time.

One of the best ways to get ahead in the screening or interview process is to do a little homework about Rackspace and the products we offer. Much of this is covered in a post I wrote in 2011. You'll go into the interviews with more confidence and it will be much more obvious that you're really interested in the position.

Don't be discouraged if the process takes a little longer than you expected. When I was hired in 2006, I went through two phone pre-screens and then three back-to-back interviews in person. Things have changed a little since then and I've heard of some candidates receiving two to three pre-screens via telephone and then one or two interviews in person. The additional screening and interviews may be due to Rackers trying to find the right fit for a particular applicant. As I said previously, we look for the right fit for each applicant. We may consider you for a different position than you applied for if we feel like your skill set or personality fits that role better.

A very common question is what to wear to a Rackspace interview. It's confusing to know exactly what's expected since we have Rackers in the building wearing everything from suits to flip-flops. This is where you really have to go with your gut. Interviewing for a customer-facing sales position while wearing a hoodie and shorts is probably going to bring a suboptimal result. Keep in mind that there's really nothing negative about overdressing (but keep your tuxedo in the closet, seriously). I wore a shirt and tie for my interviews in 2006 but my tie got caught in the car door and was shredded. After a lot of cursing, I took off the tie and decided to wing it with my dress shirt. Nobody ever said a word about it.

Remember to be flexible during the interviews. You might be asked to draw a solution on a whiteboard or think through a really complicated situation. Roll with it and keep your confidence up. When you don't know something, admit it, but then talk about how you'd research an answer.

There's one last thing to keep in mind and it's really critical. If you're ever asked about how you would solve a problem or how you solved a problem in the past, don't divulge any information which is confidential or proprietary to your current company. Just tell the interviewers that you've solved the solution in the past but you'll need to keep things vague to maintain confidentiality. We will definitely understand and we will encourage you to maintain that confidentiality.

Leave your comments if you have any! I'll be glad to answer any questions you have.


Why technical people should blog (but don't)

I originally wrote this post for the Rackspace Blog but I decided to post it here in case some of my readers might have missed it. Please feel free to leave your comments at the end of the post.


Sometimes people talk to me about posts I've written on my blog, or posts they wish I would write. At some point during the discussion, I'll almost always ask the person why they don't start up their own blog or contribute to someone else's. Very few people actually seem interested when I probe them about writing posts on technical topics.

My mother was always the one who told me (and her students) that everyone has a story. She said that writing could be therapeutic in ways you probably won't consider until you've written something that someone else enjoys. Just as software developers exist to write software for their users, writers exist to write stories for their readers. There's nothing that says technical people can't become excellent writers who inspire others to learn and share their knowledge with others.

The goal of this post is to encourage technical people to enjoy writing, write efficiently and feel comfortable doing it. I'll roll through some of the most common responses I've received about why technical people don't blog about what they know.

I don't think I'm really an expert on anything. I'm not an authority on any topic I can think of.

I'm leading off with this response because it's the most critical to refute. If you don't take away anything else from this post, let it be this: you don't need to be an expert on a topic to write about it.

You can find examples of this by rolling through some of the posts on my blog. I'd consider myself to be an expert on one, maybe two topics, but I've written over 450 posts in the span of just over five years. I certainly didn't write all of those about the one or two topics I know best.

Write about what you know and don't be afraid to do a little research to become an authority on something. A great example of this was my post, entitled "Kerberos for haters." I had almost no expertise in Kerberos. In fact, I couldn't even configure it properly for my RHCA exam! However, I did a ton of research and began to understand how most of the pieces fit together. Many other people were just as confused and I decided to pack all of the knowledge I had about Kerberos into a blog post. Positive and negative feedback rolled in and it was obvious that my post taught some readers, inspired some others and angered a few.

What a great way to lead into the next response:

What if I say something that isn't correct? I'll look like an idiot in front of the whole internet!

Been there, done that. Every writer makes errors and comes up with bad assumptions at least once. Readers will call you out on your mistakes (some do it delicately while others don't) and it's your duty to correct your post or correct the reader. I've written posts with errors, and I've gotten a little lazy on my fact-checking from time to time. As my middle school journalism teacher always reminded me, the most important part of a mistake is what you do to clean it up and learn from it.

In short: you'll make mistakes. As long as you've done your due diligence to minimize them and respond to them promptly, your readers should forgive you.

Speaking of errors:

I'm great at a command prompt but my spelling and grammar are awful. I write terribly.

This is easily fixed. If you're one of those folks who live the do-it-yourself type of lifestyle, pick up a copy of The Elements of Style by Strunk & White. There are free PDF versions online or you can borrow one from your nearest journalist. No matter the situation you're in, this book has details about where punctuation should and shouldn't be, how to structure sentences and paragraphs, and how to properly cite your sources (really vital for research posts).

Hauling around a copy of an ultra-dry reference book may not be your thing. If that's the case, find someone you know who has a knack for writing. You can usually find helpful folks in marketing or corporate communications in most big companies who will take your post and return it covered in red ink ready for corrections (thanks, Garrett!). I've even spotted some folks on Fiverr who will do this for as low as $5.

I'll wrap up with the second most common response:

I don't know who I'm writing for? What if I write about something simple and the really technical folks think I'm a noob? What if I write something crazy complex and it goes over most people's heads?

I've done both of these. Most Linux system administrators worth their salt know how to add and remove iptables rules, and they'd consider it to be pretty trivial work. Would it surprise you to know that out of over 450 posts, my post about deleting a single iptables rule is in the top five most accessed posts per month? I receive just over 11 percent of my monthly hits to this post. People are either learning from it or they can't remember how to delete the rule and they want to use the post as a quick reference. Either way, the post is valuable to many people even if I think it's the simplest topic possible.

On the flip side, I went nuts and wrote up a complete how-to for a redundant cloud hosting configuration complete with LVS, glusterfs, MySQL on DRBD, memcached, haproxy and ldirectord. I thought it would be valuable knowledge to a few folks but that it might sail over the heads of most of my readers. Again, I was wrong. The post is constantly in the top 10 most visited posts on the blog and I've probably received more feedback via comments, email and IRC about that post than any other. Once again, a post I thought would be mostly useless turned into a real conversation starter.

Let's conclude and wrap up. Keep these things in mind if you feel discouraged about writing:

  • Write about what interests you whether you're an expert on it or not
  • Don't be afraid to fail
  • Be responsive to your readers
  • Even if you think nobody will read your post, write it
  • Always ensure your voice shines through in your writing — this is what makes it special and appealing

mysql-json-bridge: a simple JSON API for MySQL

My quest to get better at Python led me to create a new project on GitHub. It's called mysql-json-bridge and it's ready for you to use.

Why do we need a JSON API for MySQL?
The real need sprang from a situation I was facing daily at Rackspace. We have a lot of production and pre-production environments which are in flux but we need a way to query data from various MySQL servers for multiple purposes. Some folks need data in ruby or python scripts while others need to drag in data with .NET and Java. Wrestling with the various adapters and all of the user privileges on disparate database servers behind different firewalls on different networks was less than enjoyable.

That's where this bridge comes in.

The bridge essentially gives anyone the ability to talk to multiple database servers across different environments by talking to a single endpoint with easily configurable security and encryption. As long as the remote user can make an HTTP POST and parse some JSON, they can query data from multiple MySQL endpoints.

How does it work?
It all starts with a simple HTTP POST. I've become a big fan of the Python requests module. If you're using it, this is all you need to submit a query:

import requests
payload = {'sql': 'SELECT * FROM some_tables WHERE some_column=some_value'}
url = "http://localhost:5000/my_environment/my_database"
r = requests.post(url, data=payload)
print r.text

The bridge takes your query and feeds it into the corresponding MySQL server. When the results come back, they're converted to JSON and returned via the same HTTP connection.

What technology does it use?
Flask does the heavy lifting for the HTTP requests and Facebook's Tornado database class wraps the MySQLdb module in something a little more user friendly. Other than those modules, PyYAML and requests are the only other modules not provided by the standard Python libraries.

Is it fast?
Yes. I haven't done any detailed benchmarks on it yet, but the overhead is quite low even with a lot of concurrency. The biggest slowdowns come from network latency between you and the bridge or between the bridge and the database server. Keep in mind that gigantic result sets will take a longer time to transfer across the network and get transformed into JSON.

I found a bug. I have an idea for an improvement. You're terrible at Python.
All feedback (and every pull request) is welcome. I'm still getting the hang of Python (hey, I've only been writing in it seriously for a few weeks!) and I'm always eager to learn a new or better way to accomplish something. Feel free to create an issue in GitHub or submit a pull request with a patch.



  • Welcome! I started this blog as a way to give back to all of the other system administrators who have taught me something in the past. Writing these posts brings me a lot of enjoyment and I hope you find the information useful. If you spot something that's incorrect or confusing, please write a comment and let me know. Drop me a line if there's something you want to know more about and I'll do my best to write a post on the topic.
    -- Major Hayden