In circles I travel in, there has been a lot of recent talk about passwords, encryption and reversible hashes. There’s also the constant discussion about password management applications such as 1Password, LastPass, and KeyPass. These programs and browser extensions keep the random strings we should be using as passwords in order. Finally, there are sites like Dropbox, who sent me an email this afternoon claiming that my password wasn’t as secure as they’d like and that I should update it to be something stronger.

Recently, passwords have been stolen from some Internet services. This is a problem because many people use the same password on multiple services, which is unsafe.

Apparently, they had a security breach and are trying to update things. It would have been better if the email had said as much… grrr. Anyway, even though I use mostly unique passwords for services, and I leave it to a password managment program to keep track of, I’m going to stop even doing that. I’m not longer going to be satisfied with LastPass suggesting 14 character strings of line noise. I’m moving over the magic of uuidgen. This has two benefits – whenever I find a password that’s not long enough, I’ll know it’s old and needs to be changed, and it will give me a consistent level of security and randomness to my passwords to keep them from being brute forced.

A break from the Graphite posts for a little while – I’m recovering from being sick, and it’s really hard to focus on tech writing when under the weather. The next few days are going to be a catch up on my other projects and some comments on OS X and where I’m going technology-wise over the next 18 months, and then I’ll get back to Graphite.

Don’t worry – I’ll link the posts together as I have in the past with other series posts so it’s easy to get from one to the next.

Looks like my trusty MacPro1,1 isn’t going to see Mountain Lion, at least not for awhile. Apple has decided to cut support for 32-bit EFI machines, which leaves me and the MacPro1,2 users out in the cold. I could try and use the hacintosh tools to boatload the 64-bit kernel anyway, which would likely work, but the video card in my machine is old enough that there aren’t 64-bit drivers for it. Which means getting a new video card for the 6 year old machine.

Money I could be putting towards a new iMac, an SSD (or three), a new bit of camera gear, brewing supplies, travel or home wireless improvements. Looks like this is going to wait.

Once I have a new iMac and the wife gets her new machine next year sometime, this MacPro will become a TimeMachine server, or a VM host, or something. We’ll see.

I do a lot with Nagios and the data it generates. I use it to establish baselines for application performance and network traffic, as well as to help predict future needs for hardware expansion (or reduction, as the case may be). There’s nothing like being able to turn off a service because nobody uses it, even when a small but vocal set of users insist it’s vital.

“Never mess with the people who hold the data. You won’t win.”

To translate data into a useable form, and do it in a way that management can easily explain the data to other parts of management on campus, you need a graphing engine. Today, we’re going to talk about Graphite.

I came across Graphite shortly before it was linked out of the SysAdmin Advent Calendar, and have fallen in love with it. It takes time-series data and stores it away for future use and cross referencing. The network protocol it uses is very simple, and can be implemented in less than a dozen lines of straightforward perl or python. Graphite itself is a django webapp, a network listener/relay/caching engine called carbon, and a round-robin style database backend. Carbon is the data management engine that writes incoming data to disk and allows data to be read back off the disk in a fairly efficient manner. You can manage data redundancy with carbon (sending data streams to multiple storage server), adjust retention granularity, and manage disk subsystem utilization rates. Whisper, on the other hand, is the data storage framework that carbon uses, to overcome some limitations of the venerable (and amazing) RRDTool. The primary advantage from where I sit it that Whisper allows for data to be inserted out-of-order into a database file, which is a huge saving grace for someone like me who wants to backfill or merge databases.

One the features about this system is that it’s written almost entirely in python. This presents a challenge for our environment: packaging. For the same reason we don’t use CPAN for production systems, we also don’t use the Python equivalent of sudo python setup.py install. Not only do we need our servers to be easily replicated on the current version of the packages we use, they need to be installed in a way that lets us track what files belong to what package, as well as manage what dependancies are in play. When you have a python package that relies on MySQL being installed, for example, it needs to just work at install time. This limited our deployment of python related tools… until I found the build dist subcommands – in our case invoked by running _python setup.py bdistrpm. It nicely takes the tarball, creates a buildable RPM out of it, and leaves the SPEC file in the right place so it can be tweaked for our environment. This lets us tie it into our mockbuild system and load it into our many internal Yum repositories, which gives us easy, repeatable and harmonious package installation for python packages.

The next task is configuration. I’m not going to cover setting up Django, integrating it into apache, or doing the SSO work to make it run harmoniously with an internal authentication system. Those are covered ad nauseam on Stack Exchange, and if you aren’t tall enough to ride that ride, you really need to catch up.

I posted awhile ago about not being able to trust RunKeeper’s calorie numbers. I was wrong, and I’ll explain why I was confused with the numbers I was seeing and what you have to do to make the numbers reflect reality. Before I get into it, keep in mind that the numbers are an estimate. Every time you get better data about the physical activity, the better the estimate about calories burned will be, but it will never be totally accurate.

The problem I had was that when I recorded a walk, run or bike ride, the calorie count would change drastically after saving the activity. This is because the mobile app does it’s own best-guess about the calorie count based on distance and pace, but knows little about terrain. Once the app sends the data up to the RunKeeper servers, the caloric burn rate for each segment of the trip is weighted based on the severity of the slope through the path taken. This means it’s a lot more accurate than it was, and gets you closer to a true number.

However, be careful. I’ve found that the GPS data RunKeeper saves isn’t terribly accurate. The same walking loop that I take at lunch is usually recorded at 5+ miles, and there’s a huge variation every day. Looking at the actual recorded walking path, it would appear that I’m teleporting around and walking through solid walls, houses, and other obstacles. All of these count towards my distance and my calories burned. This is a huge problem, but I’m not sure how much RunKeeper can do to fix the data Apple is giving them from Location Services. :(

My work around until this gets better is to go to the RunKeeper site and manually add the path I’m walking. As I almost never deviate from that path more than about 18 inches side to side, and I’m walking at the edge of the road, it’s safe to use the “stick to roads” option in their editor. Once you are done, you can change the input type in the mobile app from “GPS” to “Manual”, and pick your saved route. Incidentally, my 5+ mile walk is really a 4.2 mile walk, looking at the road data. I’m also burning 300 or so “less” calories a day, but what it means is I’m getting better data than I was before. Better data is more accurate data, and lets me plan my meals better.

So, again, sorry for dissing on RunKeeper. Now that I know how it works, it makes a lot more sense what it was doing, and my trust has been restored.

I’ve decided to re-purpose my trusty Pelican 1450 case into a bike pannier. The difficulty of course is setting up a system that allows for quick attachment/release of the pannier without compromising the security or stability of the case or the bike. I looked at a lot of different options, including just using bungie cords to tie the case down to the rack on the back of my bike. None of them were really satisfactory. I was about to drill holes in the bottom the case and attach it directly to the bike rack, when I came across the Midnight Mods article on using Pelican cases as bike panniers. The lynchpin of the whole setup was a set of Arkel Cam-Lock Hooks, which allow the cases to be attached and removed from the bike quickly, while still providing a very secure connection with the bike.

I ordered the cam-locks on Thursday, the 28th of June, and I got them this afternoon. This evening, after a trip to the hardware store, I went to work drilling holes, threading bolts and attaching the system to the back to the case I have. It went pretty fast – faster than I thought it would go with my 3 and a half year old helping me. After a few minutes adjusting the location of the cams on the rails to make the case lock to the right part of the rack, and the case is rock solid.

Tomorrow on the day off, I’m going to load 20 lbs of bricks into it and see what happens when I ride down a bumpy slope. If it stays on, and doesn’t kill me, I’ll prepare to load the laptop, iPad and the rest into the case. Wish me luck!

UPDATE:

The panniers work perfectly, and the cam-locks hold everything together better than I could have expected. I loaded 4 oversized red bricks into the pannier this morning, and took off around the neighborhood. Bouncing up and off curbs, over storm drain grates, and over dirt paths, the pelican case stayed locked to the bike. I did add an additional elastic bungie around the outside of the case, to keep the bottom of the case secure to the bottom of the bike.

I even got the placement correct, and my heel doesn’t come into contact with the front of the case in normal riding! I’m so very happy with Arkel, Pelican and Midnight Mods right now.

John Siracusa made a number of good points about the buying habits of computer users on the most recent episode of Hypercritical. He commented about how most users never upgrade their machines, and they will vote with their wallets to get machines that are less upgradeable but more reliable, lighter or have longer battery lives. I pretty much agree with this, and I find it interesting that I’m buying myself an iMac whenever Apple upgrades them, not a Mac Pro or a hackintosh. The last 4 computers I’ve purchased were all pro-grade towers, in which it’s easy to add hard drives, expansion cards, RAM, etc. During my ownership of those machines, I added a 3dfx video card to one of them and an IDE card to another. The only other upgrades I’ve added were RAM and hard drives.

I’ve been overbuying my computers in a really bad way.

Looking at that it’s easy to see that I’m not one of those users who needs the infinitely expandable and upgradeable machine. My storage needs are handled by my OpenSolaris file server, which means I want less drives in everything else that I own so I can use the reliability and recoverability of ZFS in as many cases as possible. I don’t need more network cards, video cards, etc. And RAM is still upgradeable in the iMac. If it’s not in the next revision, but I get SSDs for the price of hard drives, I’m ok with that. And I’m OK with buying a machine every 3 years instead of every 6, as long as the machine is ¹⁄₂ the price.