The Angry Dome

Shooting The Moon

Jeremy — Mon, 01 Mar 2010 09:27:58 -0500

Here's the moon, a waxing gibbous from Saturday night; read on for details.

My gear: Sony A700, Minolta 500mm f/8 Reflex (a fixed aperture catadioptric lens), tripod.

I found getting good shots more difficult than I had expected. I'm relatively new to photography and while I understand the basics, trying to shoot the moon pretty much causes all those automatic bells and whistles on your camera to become useless.

For starters, the metering system isn't very useful; if you leave it on matrix or center weighted with a lens of this length, it's going to blow out highlights badly due to all the black in the frame. Spot metering is closer to right, but it's still sketchy. The best technique I found so far is going full on manual exposure.

I found that the best results were with shutter speeds in the 1/125 range at ISO 200 (at least, this was the best when the moon was about halfway between the horizon and directly above - it should put off more light the higher it is in the sky). Incidentally, this isn't far off from the "sunny 16" rule, which makes perfect sense when you think about it; the moon is not a source of light in and of itself, rather it's reflected sunlight, so it's logical to use the calculation based on a sunny day. Sunny 16 underexposes by about 2-3 stops in my tests, due to the impact of atmosphere.

Now 1/125 second is going to be difficult to handhold with a 500mm lens. When hand holding, you need the ISO jacked up to around 1600 or better to get shutter speeds high. I try to avoid going that high if I can, so I used a tripod and longer exposure.

Automatic white balance is equally sketchy. It actually did OK sometimes, but it was hit or miss. You either need to set the WB manually, or just plan on fixing it in post processing (I chose the latter).

Now, depending on how accurate your exposure is, you have some work to do in software. The JPEG engine on my A700 did a really poor job with contrast, so I used RAW. I use ufraw and the GIMP; at 1/125 second all I really needed to do was bring up the black point to enhance contrast on the moon's surface. If you underexpose (as I did in this sample) you have to bring the white point down as well.

I had to use the GIMP and ufraw for this since Picasa's contrast adjustments were inadequate. "Auto contrast" is a disaster, but worse is that Picasa "guesses" some initial EV values when using RAW, and those guesses were already clipping highlights. It's not even possible to bring these back down to proper levels within Picasa!

I also applied some unsharp mask (.4 as the value) in the GIMP. I think I'm hitting the limitations of the lens in terms of resolving power, and it just can't fill the A700's entire 12MP sensor. This is another good reason to try and avoid high ISO, as USM will sharpen noise if it exists.

So anyway... that's shooting the moon! It's not hard when you know how to do it, but it took me a bit of time to learn.

Schneier on Airline Security

Jeremy — Thu, 31 Dec 2009 09:37:53 -0500

I rarely use this site to simply post links, but Bruce Schneier has an excellent article on the security theater of the TSA and other governmental organizations. As he says:

When people are scared, they need something done that will make them feel safe, even if it doesn't truly make them safer. Politicians naturally want to do something in response to crisis, even if that something doesn't make any sense...

Our current response to terrorism is a form of "magical thinking." It relies on the idea that we can somehow make ourselves safer by protecting against what the terrorists happened to do last time.

Schneier is one of the most respected experts in security - electronic or otherwise - and when somebody of his stature speaks out on these issues it gives me some hope that change might be possible.

Not much, mind you.

Google Chrome has no Master Password

Jeremy — Thu, 17 Dec 2009 16:52:15 -0500

I've been using Chrome recently, since they've finally released betas for both OS X and Linux.

By and large, it's a great product. It's fast, lightweight, and it has a very minimal UI. I'm nearly ready to throw firefox away and switch for good (in fact, I have switched on my netbook, where Chrome's advantages are paramount).

I'm not switching on my primary system, though. Why? Well, it turns out that Chrome has no facility to store passwords and encrypt them with a master password.

I mention this limitation not because it's overly interesting from a technical perspective, but because I find the Chrome team's process of repeatedly punting on bugs fairly amusing. Firefox's master password feature is certainly no panacea - indeed, if you care about security greatly, you would never store passwords at all - but it's better than nothing. It prevents casual access to stored passwords, and allows a user to be fairly certain that if they forget to lock their workstation a passerby will not then be able to immediately harvest all their credentials.

But reading through the comments in the Chrome bug tracker, it's clear that the engineers completely discount this use case. They claim (rightfully, of course) that an attacker with physical access to a system would then have the ability to gain much of the information stored therein (via a keylogger or other mechanisms) regardless of whether the browser utilized a master password.

They're right, but they're missing the point. Sure, physical access makes it possible for an attacker to gain information by compromising system integrity, but in the real world this isn't the person you're most likely to need protection from. The encrypted password file, combined with a master password, provides nearly complete protection from the most likely enemy: an attacker of opportunity who would casually grab your credentials if it was easy enough, but is not willing to risk detection by manipulating your system.

Chrome on Linux currently stores passwords plaintext on the filesystem, without any encryption. How this is deemed superior to Firefox's master password feature - which encrypts stored passwords using 3DES in CBC mode - is beyond me.

The old saying goes that an illusion of security can be worse than no security at all, which is the argument that the Chrome engineers use to downplay the utility of this feature. But Firefox's mechanism provides more than a simple illusion - it really does make it exceptionally difficult for an attacker to get your passwords, even if they have acquired the file. Contrast with Chrome's technique of providing no security at all, and I'm still going to cast my lot with Firefox on systems where I store passwords.

T-Rex plus T-Rex

Jeremy — Thu, 15 Oct 2009 10:04:51 -0400

I find Dinosaur Comics to be one of the funnier things I've seen on the internets. It's great, and you should read it.

In homage, or something, I've been generating a random 2-panel combination of comics. It's actually sometimes quite funny, and I'm posting the best results to a wordpress blog.

Anyway, check it out!

Left 4 Dead

Jeremy — Fri, 01 May 2009 09:53:18 -0400

I finally got a chance to play Left 4 Dead multiplayer last night, and man... it's a lot of fun.

In some ways the game reminds me of Serious Sam - fast, furious, straightforward. L4D has a bit more depth to it, but it also has a of purity of concept that just makes it work so well. There's no fluff here, no needless complexity - you and 3 buddies simply kill zombies, and lots of them.

The awesome B-movie horror styling and the cheesy one-liners from the characters are just icing on the cake.

L4D is on sale for $23.99 for the next few days. If you don't already own it, you should pick up a copy.

The Wire

Jeremy — Wed, 22 Apr 2009 14:00:36 -0400

It is with great restraint that I describe "The Wire" as merely "the best thing I've ever seen on television." It's tempting for me to call this the greatest cinematic work I've ever experienced, period, but I need a bit more time to contemplate that.

Here is the story of Baltimore, of the War on Drugs, of America. The characters of "The Wire" range from obsessive to idealistic to sadistic to almost completely amoral, but one thing ties them together: they are all cogs in a machine that is utterly immutable.

"The Wire" is massive in scope, and plays out more like a series of 5 season-long movies. Individual episodes never stand on their own, and almost nothing is thrown away - seemingly minor characters and events will continue to echo throughout the course of a season. You cannot miss an episode of this series and you cannot watch it out of order.

The violence in the Wire is visceral, but not gratuitous. The street language used is amazingly colorful and entirely credible. The sets used are often actually in Baltimore, and the extras are often actual residents. Everything about the show feels real, in a way that I've never really seen from another TV program.

As the creators have noted, the main character of the series is really the city of Baltimore. The ensemble cast wends its way through the various organizations that infect the City: the gangs, the dock workers, the police, the politicians, the educators, the press. All of these systems are equally dysfunctional, and their systemic dysfunction ultimately infects the lives of their inhabitants.

It's easy to understand why "The Wire" was never widely accepted. It is not only much more complex than other shows, it's also horrifically bleak in a way that is almost never seen on American television. Please, please do not let that deter you - if you do not see this show, you'll be missing out on something truly incredible.

* This is the same review I placed on Amazon
** Yes, it's even better than Futurama, although it couldn't be more different

Fallout 3

Jeremy — Wed, 31 Dec 2008 09:16:11 -0500

Wow, what a surprise this game was.

I played Fallout 2 way back when, and enjoyed it a great deal. I was shocked that anybody would be making a sequel at this point - the old games were turn based, isometric RPGs. Classics. And it's really hard for me to imagine continuing that tradition now.

Fallout 3 succeeds, in part, by not being bound by this tradition. Bethesda realized that that old style gameplay had no place in today's market. Even though war never changes, video games do.

So they ripped out the turn based combat, got rid of the 3rd person view. This is a first person, action RPG. It's almost at times like playing a straight up shooter. This is, as they say, Obvlivion with guns.

And man, is it awesome.

It's easy to romanticize the earlier games. They earned a lot of praise, and rightfully so - when they were released, they were the cream of the crop. Such a compelling and bizarre retro-apocalyptic setting, such freedom to explore the world and interact with it as you will. The player could do and be whatever he wanted. There was nothing else quite like it.

Some of this is lost in Fallout 3. As the 3d environment now becomes more complex, as every line is now voiced by talented actors, the player's options dwindle a bit. But my god - the second you exit Vault 101 and survey the crushed world from a "scenic overlook," you know it really was all worth it.

SPECIAL is still around, underneath it all. While the game plays like a shooter, the dice are still rolling behind the scenes. Skills and perks matter, especially in VATS, which pauses the action of the "action RPG" and turns it into pseudo turn-based combat, if only in brief spurts. VATS is genius. The best of both worlds.

The glue that holds this all together, the common thread, is that this world really feels like Fallout. Everything feels right - the crazy perks, the retro sci-fi artifacts, the bizarre humor... everything is in place. If they'd screwed this up, it wouldn't have worked. But they didn't. They took the world the first games gave us that distant 3rd person view of, and they placed us right in the middle of it.

The game takes itself a bit more seriously, but it has to. There are elements here that wouldn't have worked otherwise. Wandering through a disintegrating building, listening to audio recordings of a man's slow degeneration into a mindless ghoul. Descending into a failed Vault, uncovering the disastrous experiments that lead all of the inhabitants to their doom. Stumbling across a supermarket filled with raiders, with the corpses of hapless wastelanders strung up on chains.

At times, in the darkest caverns of the Fallout 3 world, you truly feel terror. At times, it feels like you're playing The Road.

The game works on almost all levels. It has its quirks, but it's impossible to care too much about them - there are way more hits than misses. If you play it straight through, sticking to the main plot, you can probably burn through the game in 8-10 hours. But don't do that - take your time, and revel in the horrific glory of the wasteland. You won't be disappointed.

New Car

Jeremy — Mon, 29 Dec 2008 09:42:37 -0500

I just bought my first new automobile, a 2009 Volkswagen GTI. This is also the first time I've financed any purchase outside of my mortgage (excepting tricks like using store financing solely to get discounts).

It's hard to claim that I really needed a new car, since the Integra still functions as basic transportation and since Annie's '06 Civic is a great vehicle for everyday use. Still, every month that passes makes the Integra more frustrating to operate - it's 16 years old, and both the exterior and interior are starting to show that age.

Mechanically, though, she's great. Clocking over 185,000 miles, but running like a dream. That's Honda for you.

Anyway, I said to myself, "Self, you can have a nice thing every now and then, even if you don't strictly need it. You've never owned a new car in your life, and right now you can grab the dealers by the balls and walk away with a good price."

This, mind, is after months of obsessive research. I've wanted to replace the Integra for a while, and I've been scouring the internets for a worthy successor. I honestly didn't expect that at the end I would be *buying* such a thing - I really just wanted to know what I should be lusting after.

The GTI was in a close fight with the Civic Si (which is a close relative of the now defunct Integra). Both vehicles had almost everything that lead me to the Integra to begin with: good gas mileage, fun to drive, nice (but conservative) appearance, compact size (but still able to seat 4 comfortably, 5 in a pinch).

Ultimately, 2 factors tipped the scales in the GTI's favor: first, it's not another Civic (and as much as I do love the Civic, I don't think we need two of the things), and second, I fell in love with the hatchback (which allows the GTI to cram more cargo and passenger volume into a vehicle that's actually shorter than the Civic).

My dealership experience was not at all what I expected. I had done such extensive research on the process that I was ready for a major undertaking: I armed myself with all the information I could find, and I used Edmunds to get an idea of what to expect. I was ready for a fight.

On a whim, though, I decided to try the Edmund's service to automatically get quotes from area dealerships via email. Nothing to lose from that, and it would at least give me a good baseline to start from.

Much to my surprise, one guy came in well under the rest (with a price that was well under both Edmund's FMV as well as invoice), and when I shopped the price around the other dealers (with one exception) basically told me they couldn't touch it. I went out to the lot (dragged the guy in on Saturday, when he doesn't even normally work) and tried to drive him down a bit further, but he wasn't budging at all on the price of the car beyond throwing in a couple of extras at cost. I honestly didn't expect anything different, though, given the way other dealers responded to that first quote.

In retrospect, I think I could have done marginally better with the single dealership that was able to match the price, but I don't think it would have been *much* better - a few hundred at most - and the dealer I went with has a better reputation and is more convenient to me. That's worth a few hundred bucks, I think.

Anyway, I'll put up a picture when I get around to it. So far I've got only minimal buyer's remorse, but we'll see how I feel after I start making those hefty payments...

Adventures in drive failures

Jeremy — Tue, 23 Dec 2008 14:11:09 -0500

I swear, my luck with hard drives is really rotten. I just lost the OS drive in my MythTV box, and that marks the second time in as many years (and the 3rd time total).

It shouldn't be surprising. I've got 8 drives in always-on systems, and I was sure to lose another eventually. It's just too bad it wasn't one from the RAIDz array.

Anyway, the last time I lost the primary (and at the time only) drive in my MythTV system, I responded by rebuilding the thing with RAID 1. It chugged along happily for a while with no issue.

At some point, I picked up a small form factor bare bones kit to replace the massive Dell tower that I had been using. In moving to the smaller kit, I was forced to sacrifice the second drive.

Of course, now, I pay the price.

Luckily, the price isn't that high. When I set up my RAIDz array a while back, I offloaded all of the actual media files onto that and exported them via NFS. A drive failure in the mythtv system itself doesn't cause me to lose any of those.

At the same time, I also configured bacula to back up everything else "important" to the raidz pool as well, and I rsync those backups to an external drive. This works remarkably well, and until now I've had no cause to use it.

I noticed the drive failure last night, when I tried to upload a newly ripped CD. I didn't have time to do anything then - I just hit the gentoo website and started downloading the latest live CD (since god knows where I put my old one) and told bacula to restore everything to the local filesystem.

This morning, I got up a bit early and swapped out the failed drive with the one that used to be its mirror. I briefly considered trying to recover a bootable system from the outdated mirror, but quickly thought better of it; the data was really stale and would have to be replaced anyway. Might as well just nuke it from orbit and do a bare metal restore.

Once I had the live CD booted, it was pretty straightforward to recover from there. The bacula restore job had finished the night before, so all I had to do was partition the replacement drive and rsync the backup over from the Solaris box.

Unfortunately, I had failed to backup the boot partition. Not a big problem, but I had to go back in and recreate that, building a new initrd and creating a new grub.conf. I also failed to create /dev/console and /dev/null on the actual / partition, which caused boot to fail until I went back and did so. Lessons learned there.

I also lost my large "scratch" partition. I tend to keep a collection of useless junk around, and in this case I had already decided that these things were acceptable losses in a recovery scenario. In a way, it's actually nice to have this cleaned out.

The total time from cracking the case to having the system fully running with the prior night's backup was approximately 3 hours. I know I'm probably not going to see 3 9's on my DVR, but that's not a bad turnaround time from my perspective.

Systems administration with puppet

Jeremy — Mon, 06 Oct 2008 13:36:54 -0400

I'll confess to being a bit late to the game on picking up puppet, but now that I've finally jumped in I'm completely hooked. Put simply, puppet is a piece of software, written in ruby, which allows machines to pull configuration information from a central "puppetmaster."

First, a little background, and an explanation of why I've fallen in love with the idea of such a system.

Why I use puppet

I currently manage a relatively small environment. I have about 15 physical servers and about a dozen xen guests. I'd long assumed that puppet - or its spiritual predecessor, cfengine - would be a poor fit in my situation. After all, I'm not managing seas of identical boxes - most of these machines have several unique aspects which they do not share with anything else.

I had assumed that all of the true commonalities would be taken care of at kickstart/jumpstart time, and that modifications to these commonalities would be few and far between. If they needed to change, I would change them manually. Not a big deal.

Except that's not how it works in practice. You just can't keep everything the same manually when you're dealing with more than one machine, and at some point you will want to change things everywhere and you will mess up. So, when I tweaked my system config to use kerberos for pam authentication instead of LDAP, I changed it on the kickstart, and I changed it everywhere I remembered - but I missed some boxes.

And you know what? I didn't even realize this until I moved this config into puppet.

It goes beyond this, though. It's not only about making sure the commonalities are preserved across machines and that changes are kept in sync. Even in situations where you really do have a unique configuration - something that only matters in one place - you very well might need to duplicate the setup later. There are so many little things that are easy to do without thinking much about - all the countless permission management and account creation and directory creation tasks that you do now, that you sure as hell won't remember in 5 years. This is especially true if you're not even working there and some other guy needs to replicate your work.

Puppet gives you the chance to codify all of this, and combined with subversion or git you actually have a change control mechanism for server state. Need to add a mail alias? Who cares if you don't think you'll need it elsewhere - put it in puppet and check it in to svn. Now you have both the recipe needed to recreate this configuration elsewhere, but also a record of the change and (if you comment in your svn commit) the reason why it was changed.

The puppet language itself is so concise that it's easy to see what you've done, even if you failed to document it anywhere. In effect, the mere act of making a change now becomes documentation. That's incredibly powerful.

As well, puppet often forces you to do things the right way. Puppet is really good at managing things - as long as you do the right things. A prime example here is in package management - puppet can easily ensure that you have the appropriate RPM (or sun pkg, or debian apt, or gentoo emerge, etc) packages installed as defined in your puppet configuration. Simply add the definition to puppet, and the package will be installed.

Now, this is great, until you run into a piece of software that hasn't been packaged - say, a perl module. In the past, it would be really tempting to just fire up CPAN and let it do whatever the hell it is that CPAN does, installing the perl module wherever it sees fit. But puppet knows nothing of CPAN - if you use CPAN, you work against puppet. The "right way" is (and always has been) to build RPMs (or whatever your native package is) and maintain your own repository, but puppet practically forces you to do this. Once you start trusting puppet for everything, you start doing everything in a way that's more maintainable and predictable as a side effect - and that makes you better at your job.

That, in a nutshell, is why I use puppet. Now, onto how I use it.

Puppet guts

My initial assumptions about puppet were that it was basically a dumb configuration file repository - that you throw confs in the puppet master and they get slurped down by the clients, potentially modified by some templating mechanism where a config needs to vary slightly across multiple environments. Indeed, this is a supported (and sometimes necessary) way of distributing configuration information to puppet clients, but after digging in a bit more I realized that there's usually a better way.

Puppet goes beyond the simple "fileserver with templates" paradigm to, effectively, provide an abstraction layer that can describe aspects of a UNIX system in its own dialect. Configuration information is primarily written using the "puppet language," utilizing special "types" which are ruby classes capable of mapping the puppet language into raw configuration details needed by systems. Where these types are inadequate, one can do other lower-level tricks, like directly executing UNIX commands or inserting raw data directly into files.

This is a bit cumbersome to describe, but the following example should help make this more apparent:

service { [ "stunnel" ]:

  enable => true,

  ensure => running,

  subscribe => File[stunnelconf],

}

The "service" type comes with puppet, and it's an abstraction of - surprise - services. It takes many potential arguments, but in my case I'm calling it on a service named "stunnel" and defining "enable" as "true", "ensure" as "running", and "subscribe" as "File[stunnelconf]". In this context, that means that I want the service enabled on boot, that the service should be running (or made to run if it's not) when puppet runs, and that when the "File" resource named "stunnelconf" changes the daemon should be restarted (thus if the configuration changes you need not do a manual restart).

The magic in this is that "service" is smart enough to handle a wide array of different mechanisms for launching and monitoring states of services. On CentOS machines, the puppet "service" type will manage the service with a combination of calling init scripts and running the redhat-specific "chkconfig" mechanism. On a Solaris 10 box, however, this same type would manage stunnel through the SMF system, calling the svcadm utility (or possibly hooking directly into the API - I'm not sure). The beauty here is that the puppet "service" type knows all of this, and the wildly different systems are presented to you as exactly the same construct in the puppet language. I no longer need to care about the differing underlying mechanisms - I tell puppet I want the service turned on, and it does all of the actual work for me.

Things that can be managed with the included puppet "types" include user accounts, groups, yum repositories, packages, file permissions, cron jobs, mail aliases... well, there are quite a few of them, and the puppet type reference goes into great detail on their capabilities.

Now, it would be nice to have native types for every resource, but understandably there are many occasions where no type is available. You could create your own puppet type in ruby to handle such a situation, but this would take a chunk of time and it might not be worth the extra effort.

Luckily, the puppet language itself gives you enough tools to abstract configuration elements through the use of templates and the included "file" type. It's not quite as powerful as writing your own full-fledged type, but it's also much more straightforward and much easier to implement.

As an example, here's a snippet of how I pull in my snmp config:

file {"/etc/snmp/snmpd.conf":

  content => template("snmp/snmpd.conf.erb","snmp/$snmpextra.erb"),

  mode => 0644,

  alias => snmpconf,

}

That "$snmpextra" thing is a puppet variable. In my case here, I have a base snmpd.conf.erb file, which is an ERB template that contains my most basic snmp config. However, I also have an optional additional template which is appended if the $snmpextra variable is defined. In this way, I can keep one "master" configuration, but I can add additional local configurations as needed. Note that the ERB templates themselves can contain ruby code that inserts text based on puppet variables or facts, but they need not do so - they could be a simple configuration file copied directly from a working config.

In case you're wondering what a "fact" is, it's a snippet of system information provided by puppet's "facter" helper utility. Just as puppet types can abstract configuration directives, facter is a standalone utility that's used to abstract the gathering of system metadata. Whenever puppet is run, facter collects a series of "facts" about a system, and these facts can be used to make decisions in the puppet language or within ERB templates.

So, for example, here I check for the $operatingsystem fact and include a different class based on that fact:

class legato::client {

  case $operatingsystem {

    centos:  { include legato::client::centos }

    solaris  { include legato::client::solaris }

  }

}

Note that, in the puppet language, a "class" is not like a "class" in object oriented programming - rather, it describes a bundle of configuration directives, and you can apply them with the "include" statement. In this snippet, I pull in the legato::client::centos class for centos machines, and the legato::client::solaris class for Solaris machines. In cases where there is no native puppet type, you can manage operating system specific details in this way.

Conclusion

That's the basic gist of what puppet can do and how I use it, but there are many details that are documented on its excellent wiki, which you really should read if you're interested in the software. I highly recommend it, even if you're only dealing with a handful of systems - I've come to rely on puppet, not only to help me to get things done, but also to make sure I do them the right way.