Sony Bravia and Motorola DCX3400 (Comcast) DVR/Cable box (Gear)

Visiting my aunt who is recuperating from a medical procedure. I noticed she'd gotten herself a nice Bravia flatscreen...but after dicking around with it for a few minutes, I also noticed that it wasn't displaying HD. Wha? I checked her cable box - it's a Motorola DCX3400 and claims to be displaying HDTV. It's connected to her TV by *both* coax and an HDMI cable, but the TV claims there's only signal on the 'TV' input (coax). Uh?

A few seconds dicking around and I figure out how to get the setup menu on the box (turn it on, then turn it off using the frontpanel power button and within a couple seconds hit the 'MENU' frontpanel button). The menu comes up as the manual describes, but says it's *not* connected via HDMI.

No matter what I do, I can't get it to sync HDMI. The DVD player, plugged into the same port on the TV, comes right up. Finally, after 30 minutes, I acknowledge Geek Fail and call Comcast. After navigating the phone tree, I get a tech who actually seems clueful. He asks what kind of TV. I tell him. He says 'What model number?' Uh-oh. I give it to him. He tappity-tappitys on the knowledge base, and says, "Yep, sorry, I thought so. There are known issues with using certain models of Sony Bravia flat panels with our cable boxes - the HDMI just won't sync."

Great.

So if you have a Sony Bravia and are trying to get a Motorola DCX3400 cable box to work properly with it, forget it.

On the plus side, since the cable box will only output 1080i (or maybe 720p) anyway, you can just use component video+RCA stereo and get the same resolution.

Dealing with stale cached apt manifests in Chef-run apt transactions (Code)

I have a 'base' Chef recipe whose job is to do global basic bootstrapping tasks to EC2 slices. One of the first things that this recipe does on Ubuntu slices is update the apt caches using 'apt get update.' Without that step, it generally fails, because the AMIs I use don't have complete and up-to-date apt repo information in them.

Well, today, I ran the recipe on a new slice and it tanked. apt was exiting with status 100, and when I checked, it was producing the following error:

 IP ADDRESS apt-get update returned 100, expected 0

...and running apt-get update manually returned an error complaining that it couldn't update the repo information. It complained:

W: Failed to fetch  (the problem archive file): Hash Sum mismatch

The problem here, it turns out, is that the archive in question I was attempting to get updated manifests for had been updated - but the checksum (Hash Sum) for that archive had been *cached* by something in between my slice and the archive (likely some form of proxy). As a result, they didn't match, and bam.

The Fix: The fix came from here. Essentially, mod your apt-get command to include an option for 'no-cache', either during the call:

apt-get update -o Acquire::http::No-Cache

...or by putting the option into your apt config (see the post linked above for how-to).

Whew. Another day, another thing.

Chef cookbook attribute files (Code)

Learned today the hard way: Don't use set_unless in a Chef cookbook's attribute file unless there is a really good reason. And corollary: there's never a really good reason. At least, not that I've found.

Why? Here's what happened. I started hacking Chef recipes by looking at examples from the Opscode and 37Signals git repos, probably like many folks. In many of those examples, attributes are set using things like

set_unless[:cookbook][:varname] = "some_value"

The problem is that what set_unless means here is that whenever this cookbook is run, Chef checks to see if the variable in question already has a value...any value. If so, it skips the set statement. See where I'm going?

Yeah. So I had an attribute with a really long list in it that was going to be executed by a stanza in my main recipe file. To test it, I created a three-item list in the attribute file. It worked fine on my test node. So I changed the attribute to have the full 21-item list, and then re-upped the cookbook to the Chef server, and re-ran the client on the node. It diligently went and got the updated attribute file and downloaded it to the cache, then performed the chef run...with the same 3-item list.

Because I'd already set that variable on that node, the set_unless wouldn't fire. The only way I got this to work was to go replace the set_unless statements with plain ol' set statements. Then, when it ran, it happily overwrote all the variables with the new values.

Does this waste time/resources? Yes, but probably not as much as a set_unless_equals sort of test would (not that that test exists now).

Amazon EC2 ami manifests and architecture mismatches (Code)

So I'm muddling my way through various means of managing an AWS infrastructure. We're currently using Opscode's chef and their online SaaS implementation (experimentally). When using the chef tool 'knife' to boot up an EC2 server using one of our custom AMIs, I kept getting an error:

---cut---

/usr/local/lib/ruby/gems/1.8/gems/excon-0.1.4/lib/excon/connection.rb:67:in 
`request': InvalidParameterValue => The requested instance type's architecture 
(i386) does not match the architecture in the manifest for ami-xxxxxxxx (x86_64) 
(Fog::AWS::EC2::Error)

---cut---

...after mucking about for a bit, I have discovered that AMIs whose declared arch is x86_64 (and, presumably, whose arch2 is amd64) *cannot* be used to instantiate running instances whose type are m1.small or m1.large. This matters because while some DSL tools (*cough* chef *cough) have the means to specify and pass thru an instance 'flavor' to the EC2 toolset, they can't/don't/won't accept or pass thru an 'arch' value. So the error message is a bit of a red herring. In my case above, I changed the instantiation command from specifying '-f m1.large' to '-f m1.xlarge' and...voila, it worked.

Resolving an nginx and passenger problem (Code)

Was working on remote-configuring a server which runs a Ruby app using nginx and Phusion Passenger. Despite having everything configured properly (I was convinced it was, at least) I kept getting the following error on nginx startup:

Alert: could not send password to the passenger helper server: write() failed (32: Broken pipe)

nginx would refuse to start. It wouldn't even write anything to the error log. Argh.

To make a long story short, there were *two* reasons I was getting this error. Here they are, and here are the fixes.

Reason 1: Bad nginx.conf

In my nginx.conf, I was specifying the location of the passenger_root and of the passenger_ruby. In both cases, I had an incorrect path due to us having changed versions of ruby and the passenger gem - it had been updated, so its path changed.

Reason 2: Bad HelperServer

We (I) had installed nginx via the command passenger-install-nginx, included with the passenger gem. However, the version of passenger had been updated (from 2.2.5 to 2.2.14, as if it matters) and we (I) had not re-run that install process. I originally didn't think it mattered. However, apparently (and I'm not positive of this) there is a HelperServer that is compiled at install time which points to a particular passenger instance, so if you upgrade passenger, you need to rerun the passenger-install-nginx command. It won't stomp on any configs or anything.

Anyhow, after fixing those problems, whee, nginx and passenger started fine. I hope this helps someone, because I was looking for exactly this post frantically during the Google phase of debugging, and didn't find it. I found pieces of info, but not all of it.