I will lead with the summary: since the Heartbleed bug is a bug in OpenSSL's implementation of a partof the TLS protocol, no version or implementation of SSH is affected byHeartbleed because the SSH protocol is not built on top of TLS.

So, there's four things involved here:

• SSL aka TLS is the underlying network encryption protocol used for HTTPS anda bunch of other SSL/TLS things. Heartbleed is an error in implementing the 'TLS heartbeat' protocol extensionto the TLS protocol. A

In response to my previous entries on gatheringOS level performance metrics, people have left a number of commentsrecommending various systems for doing this. So now it's time toexplain my current decision about this.

The short version: I'm planning to use graphite combined with some stats-gatheringfrontend, probably collectd . We may windup wanting something more sophisticated as the web interface; we'llsee.

This decision is not made from a full and careful comparison of allof the available tools with respect

In light of the fact that the OpenSSL 'heartbleed' issue may have resulted in someone getting a copy ofyour private keys, there are least three possible reactions that peopleand organizations can take:

• Do an explicit certificate revocation through your SSL CA and geta new certificate, paying whatever extra certificate revocationcost the CA requires for this (some do it for free, some normallycharge extra).

• Simply get new SSL certificates from whatever certificate vendoryou prefer or can deal with and switch to them. Don't

I've written before that one of my projects is putting together something to gather OSlevel performance metrics. Today I want to write down what my goalsfor this are. First off I should mention that this is purely formonitoring, not for alerting; we have a completely separate systemfor that.

The most important thing is to get visibility into what's going onwith our fileservers and their iSCSIbackends, because this is the center of our environment. We want atleast IO performance numbers on the backends

I wrote yesterday about how Tiny Tiny RSS drastically mishandlesgenerating If-Modified-Since headers for conditional GETs , but I didn't say anything about what myresponse to it is. DWiki insists on strict equality checking between If-Modified-Since and the Last-Modified timestamp ( for goodreasons ), so Tiny Tiny RSS was basicallydoing unconditional GETs all the time.

I could have left the situation like that, and I actually consideredit. Given the conditional GET irony I wasnever saving any CPU time

Recently I looked through my syndication feed stats (as I periodicallydo) and noticed that the Tiny Tiny RSS program was both responsiblefor quite a lot of feed fetching and also didn't seem to ever besuccessfully doing conditional GETs . Mostthings in this situation aren't even attempting conditional GETs,but investigation showed that Tiny Tiny RSS was consistently sendinga If-Modified-Since header with times that were generally just abit after the actual Last-Modified timestamp of the syndicationfeed. For good reasons I

After going through all of the steps from yesterday's entry to move my mirrors from one disk toanother, I inadvertently discovered a vital additional stepyou need to take here. The additional step is:

• After you've taken the old disk out of the mirror and shrunk themirror (steps 4 and 5), either destroy the old disk's RAIDsuperblock or physically remove the disk from your system .I believe that RAID superblocks can be destroyed with the following(where /dev/sdb7 is

Suppose that you have a software RAID mirror and you want to migrate oneside of the mirror from one disk to another to replace the old disk.The straightforward way is to remove the old disk, put in the new disk,and resync the mirror. However this leaves you without a mirror at allfor the duration of the resync so if you can get all three disks onlineat once what you'd like to do is add the new disk as a third mirror andthen remove the old disk later.

One of the issues that I'm facing right now (and have been for a while)is that being uncertain can be a daunting thing. As sysadmins we dealwith uncertainty all of the time, of course, and if we were paralyzedby it in general we'd never get anywhere. It's usually easy enough toovercome uncertainty and move forward in small situations or importantsituations (for various reasons). Where uncertainty can dig in is indauntingly big and complex projects that are not essential.