The first problem is that there are several enormous assumptions embedded in the argument which are never acknowledged much less addressed. Here are a few of them, in my opinion.
]]>
In addition, you want to group your nodes into reasonable groups! So let's say you have project/environment/type attributes which describe each node (like, for example, myapp-staging-app).
]]>
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.
]]>
[IP ADDRESS] apt-get update returned 100, expected 0
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.
]]>
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).
]]>
/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.
]]>
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.
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.
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.]]>
Two of them have cover art in iTunes. The rest do not. Huh?
If I look at them in Calibre, they all have cover art. Furthermore, something odd - if I go back into iTunes and look at one of the ones whose cover art shows up in the 'Summary' section of Get Info and in the cover view, although the cover shows up in the 'Summary' section there's nothing in the 'Album Artwork' section. I cannot copy or paste the cover in the 'Summary' section (they're greyed out, and I tried).
Going back to the ePubs as it was saved to disk by calibre, I can compare a working ePub and a non-working ePub. They both have cover art in their folders, and both are jpgs. Opening them in preview shows both of them are identically sized; both are using the same (RGB) colorspace. They look identical. But one of them imports when you drop the folder of the ePub on iTunes, and one does not.
If I paste the cover art into the non-working ePub's 'Album Artwork' pane in iTunes, it shows up as having a cover, and that cover shows up in the Album Artwork pane. The one which worked originally still doesn't have anything there.
So if I had to hazard a guess, I'd say there is still something screwy with iTunes' ePub import function; something which screws up some cover art. Great. I don't want to have to go manually re-fix all my cover art on my 200+ books.
]]>
]]>
Please, please let this not suck.
Oh please.
So far, so good.
]]>
However, I have recently discovered that he surfaced briefly in 2008 - to announce that he'd completed a sequel to Emergence, named Tracking. It was apparently serialized in Analog between July and October of 2008.
But that's the only place it exists.
So I guess I need to start hunting Analog back issues...
]]>
The Problem:
The Blu-ray player, when connected to the Pioneer via HDMI and optical digital audio, won't work in 1080p resolution. When we connected the player (a Sony) it went through a 'quick setup' wizard. At boot and during that process, it was configured for what looked like low res - 480? - while it tried to figure out how to set itself. It reached the 'resolution' phase and announced that it would try to autodetect the proper resolution - and then the picture vanished ('No Signal' on the TV) and the Pioneer amp started flashing the message 'NO SUPPORT' on the amp's frontpanel. After 30 seconds, the picture came back (still low res) and the Blu-ray player asked if we'd seen the test page. We said 'no.' Rinse and repeat; the Blu-ray for some reason kept trying and failing to sync up.
After eventually forcing it to break out of the 'quick start' configuration wizard, we found that it was set to the lowest possible resolution, which did work. So we started trying to manually set it to higher resolutions. Eventually, we determined that while it would display 1080i, any attempt to set the player to 1080p would cause the 'NO SUPPORT' message.
Diagnosis:
This seemed stupid. We were talking about a Pioneer Elite amp, and a Samsung LNT5271f TV - both of which most assuredly would handle 1080p. As a test, I connected the Blu-Ray directly to the TV. It worked fine - so the problem was definitely with the amp. The *other* HDMI devices connected seemed to work fine; the Playstation 3 on another input seemed to work. But the Blu-ray just wouldn't work.
The Solution:
Well, long story short(er). It turns out that the Pioneer lets you manually assign specific video inputs to a particular function - so for example you can select the 'BD' (BluRay Disc) function, and then specify that the amp should switch to 'HDMI-1' and 'Digital Audio-3' (for example) when set to this function. We had done just that, and set it to 'HDMI-1' and 'Digital Audio 3' or some such.
The problem, however, is that although the amp will let you select and use the various video inputs individually, they aren't as independent as you might think. The problem: We had component video cables plugged into 'Component-1' for the cable box - and apparently, that trailing '-1' means that those inputs share some part of the signal path. The fact that component video was plugged into - let's call it Circuit 1, meant that Circuit 1 was limited to the maximum resolution of the component video - which was 1080i.
So we moved the Blu-Ray player to HDMI-4, which had no other devices plugged into that circuit ("-4") and voila, everything worked fine.
Annoying. No mention of this limitation in the manual that I could find, or on the internet. So hope this helps someone.
]]>