The Angry Dome

Some background: I've deployed a central syslog-ng server at work, and I'm looking to use the nifty frontend, Logzilla (formerly known as php-syslog-ng). Unfortunately, Logzilla now requires MySQL 5.1, which isn't provided by RHEL/CentOS 5. This means I have to go rogue and run a non-standard MySQL build.

There are several ways to approach this problem (install from source, install the upstream RPMs), but from my perspective the "rightest" way is to track the current Fedora MySQL RPM and rebuild it for RHEL. This provides a proper RHEL-style name and dependency tree, and it packages all the fixes that Red Hat is going to put into their version.

So, here's how to do it.

Building MySQL 5.1

1) Ensure you can build RPMs as a normal user, since building as root is bad mmk. Dag explains how to go about this.

2) Download the latest SRPM from the latest Fedora source repo. As of the time of this writing, that means mysql-5.1.45-2.fc13.src.rpm from Fedora 13.

3) Grab the build requirements. This is going to heavily depend on what you've already got installed, but I needed to do:

yum install rpm-build autoconf automake gperf imake libtermcap-devel libtool ncurses-devel readline-devel

4) Install the RPM (note - the md5 signature signature mechanism seems to have changed, you must use the --nomd5 flag here, and you cannot directly rpmbuild the f13 srpm):

rpm --nomd5 -ivh mysql-5.1.45-2.fc13.src.rpm

5) Build the RPMs:

rpmbuild -ba [yourhomedir]/redhat/SPECS/mysql.spec

Hopefully, it'll build successfully. The RPMs will be in your [yourhomedir]/redhat/RPMS/ directory. But there's one little problem...

What about libmysqlclient.so.15?

If you tried to yum up to the RPM you just built, depending on what you've got installed you might get some nasty errors about a missing libmysqlclient.so.15. Looks like that library version has been deprecated in 5.1, oh noes!

You've got a couple of options here. You could just copy that library from your old install and do some ugly --force hacky stuff to install the new RPMs. It'll work, but it's nasty. You could also rip out those RPMs that require that library and rebuild *them*, but that's time consuming and means you've got even more stuff that's diverging from upstream. Of course, if you don't actually *use* any of those packages, you could ditch them entirely.

The approach I took was to build a shim RPM that provides *just* this library. I can't take credit for the idea, it turns out somebody had already come before me.

1) Download the spec file for this library from Remi Collet, the original creator.

2) Patch it for RHEL using my patch file, or just download my spec file directly.

3) Get the CentOS or RHEL mysql source rpm from the current repository (which is at the time of this writing CentOS 5.5).

4) Install the srpm (no need to --nomd5 this time!)

rpm -ivh mysql-5.0.77-4.el5_5.3.src.rpm

5) Build the new RPM:

rpmbuild -ba mysqlclient15-remi.spec

This should spit out a sweet new RPM.

Yum it up

yum --nogpg install mysqlclient15-5.0.77-1.x86_64.rpm mysql-libs-5.1.48-2.x86_64.rpm mysql-5.1.48-2.x86_64.rpm mysql-devel-5.1.48-2.x86_64.rpm mysql-server-5.1.48-2.x86_64.rpm

And, voila! MySQL 5.1 with no dependency issues! You could even write a little shell script to pull updates and build the RPMs automatically.

(Side note - be sure to back up your database before upgrading! My upgrade went smoothly, but that's no guarantee that yours will!)

I've been a long time fan of Solaris the technology, and I've been running OpenSolaris for personal use for several years now. I've tried hard to explain to people the merits of what I view as an exceptional but lesser known OS, with minimal success. The OpenSolaris community never really took off the way I (or Sun, probably) had hoped; Sun never really treated community members as first class citizens, and the "real" work on OpenSolaris all came from inside of Sun.

Well, I guess Oracle had enough of all this mess, and they've shot the OpenSolaris project right in the head. OpenSolaris as a product is completely dead, and the nightly builds and code repositories are closing up shop. The CDDL will be used (to some extent) for bits of Solaris code, but that code won't be released until *after* Solaris releases ship, which is a stark contrast to the more open approach Sun took with OpenSolaris.

As a pre-emptive strike against this potentiality, key community members have already spooled up the Illumos project, a fork of OpenSolaris with the proprietary bits replaced by open source software.

Oracle's decision to keep the repositories closed until after release forces Illumos's hand a bit; they no longer have the luxury of simply rebuilding a free Solaris derivative and keeping it up to date with the latest efforts from inside Oracle. Now, they have to choose: do they accept a huge lag and spool up a post-release open source derivative, or do they fork proper and kiss Oracle goodbye forever?

I have to say, the latter option is much more attractive, and it's not entirely out of the realm of possibility either; the Illumos main page now shows a brief response which seems to imply they're moving in this direction. Illumos is a real community project; if OpenSolaris's woes were really, as many of us felt, due mainly to Sun's handling of the community, this represents a tremendous opportunity to address those issues and build a healthier and more vibrant community than OpenSolaris ever had. Oracle is even helping out by scattering former Sun engineers to the wind; how many of those engineers will want to keep working on the OpenSolaris code base as a labor of love? Are there enough of them interested in continuing the work that they started at Sun as a community project? Will they ultimately make Illumos even *better* than Solaris?

Solaris proper is rapidly dying to me. I'm not the customer Oracle wants, and they've made it abundantly clear that they have no interest in having me. They want big enterprise customers with big Oracle database deployments, and screw you open source and startup hippies, your pockets aren't deep enough to even think of playing that game. Well, so be it. But Illumos is providing an opportunity for all of us hippies and startups to rally around a new project, with a new community, that we may finally be a real part of. I think the possibility really is there, and Illumos could become the open source success that OpenSolaris only dreamed of becoming.

Am I sad to see things go this way? A bit, yes, but it's also a huge burden lifted: now we know the real score. There's no more begging Oracle for table scraps that may never come, it's either do or die by the efforts of the community alone. Whichever way that goes, at least there's nobody left to blame.

I won't lie, I've mostly lurked in the shadows of the OpenSolaris community, justifying my lack of participation with an observation that participation was pointless anyway. Why would I even bother when the community was really just an afterthought to Sun? Well, I (and people like me) are being called on that bluff; if we don't step up and contribute now, it's all over for real.

I asked Alix of arixystix.com to make a Plants vs Zombies Snow Pea for me (as a gift to my wife). He came in today, and he's totally rad; check him out!

From

I don't usually go to many live concerts (maybe 3 or 4 a year), so it's a bit of an oddity that two of my favorite bands have been in town within the past two weeks, and I've managed to see both of them.

First up: My Morning Jacket.

From My Morning Jacket

This is a band I've been watching for the past couple of years; their first performance on Austin City Limits piqued my interest with songs mostly from 2005's "Z," and their later performance featured songs from 2008's "Evil Urges." I found the latter to be especially impressive, and afterward I went back through their earlier albums to find solid but... well, rather less interesting music. This is a band that has evolved and improved with each album, so in a way I found their back catalog a bit of a disappoint.

Anyway, they're on tour, and their RDU stop was in the Koka Booth Amphitheatre in Cary. I've now seen three concerts in that venue, and my feelings about it are... mixed.

MMJ's performance itself was stellar, as I expected it would be having seen them execute two nearly flawless performances on ACL. They started off a bit slow with their "classic" material, ramping up to a pretty beefy set that included probably half of the songs from Z or Evil Urges. Jim James is quite a showman, flaunting a cape worn in several odd manners throughout the show; if his voice wasn't so completely out of this world, you might imagine the cape trick to be a bit bizarre, but somehow it all seems to work.

Unfortunately, a couple of things about the concert bothered me. For one, this place was filled with drunks. I mean, EVERYWHERE. There were 20ish kids all over the place; smoking pot, drinking, talking loudly in that I'm-too-drunk-to-modulate-my-voice manner, tripping over each other, and paying absolutely no attention to the band. Why are you guys here? Is MMJ so popular that people who don't care about the music show up just for street cred?

I think part of the issue may be Koka Booth itself. Our "seats" were rather lousy, being stuck back in the lawn. It's not as bad as the cheap seats at Walnut Creek (which are so far away you can't even *see* the performers without looking at the giant TV), but they're a long way away. And while Koka Booth is an attractive stage, their audio was very, very quiet to my ears; a fact that effectively amplified the noise of the crowd in comparison to the music. Some venues crank the volume till your ears bleed, and I'm not asking for that, but... maybe if it was just a bit louder, these kids wouldn't be so distracting.

I got the distinct impression that the real fans were close to the stage, where they got both a good view and, presumably, better companionship.

The net result was a bittersweet experience; as much as I loved seeing James and the crew live, and as awesome as the band was, I couldn't help but be disappointed by the environment. I'm pretty much resolved to never sit in the cheap section at Koka Booth again.

Technology is a marvelous thing. At its best, it enables people to express themselves, to do things that had once been impossible or impractical; but as it does so, the wizards of the old domain find that their arcane knowledge loses value dramatically.

Consider, if you will, the photographer.

Initially, photography was a purely technical exercise, which required not only technical expertise but the possession of costly and cumbersome machinery. There were very few wizards, and everything they did was magic.

As the 20th century progressed, things began to change. 35mm cameras were available in a (relatively) affordable form, and the value proposition shifted. Operating and owning the machine was no longer an impenetrable barrier to entry; people could actually do so in their own homes. They could capture photographs of their own lives.

Of course, there was still magic to it: even though a home user could afford to take photos, the costs were still significant, and the technical skill required to operate consumer-grade devices was still decidedly non-trivial. Technology had facilitated the notion of an "amateur photographer," but an "amateur photographer" was, himself, still something of a wizard.

For the utter non-wizard, there arose "point and shoot" and instant cameras. Anybody who wanted to take a picture was eventually able to do so; but, even so, these devices were still cumbersome, and for any larger prints one still needed at least an amateur wizard.

In parallel to the proliferation of photographic equipment developed a new notion: that of photography as art. It's undeniable that some people have a gift in this respect, some special capacity to capture a specific moment, framed a certain way, optimally composed to elicit a certain response. Entire schools of study were devoted to this art form, and the photographer became more than a technical wizard, he also became viewed as an artist.

It's astounding, then, to watch the extent to which technology has changed the equation. It is true that every advance in the film era (and there were many) opened the gates a little wider, but the real revolution has come from the digital age.

I own a Sony A700, which is a fully digital SLR. This is a device that would have been completely unfathomable 15 years ago, and the notion of such equipment as a mass market consumer product would have been equally unfathomable as recently as 7 years ago. Think about how significant this is: within a mere 15 years, we've gone from something that was almost unimaginable at any cost, to something that almost any middle class enthusiast can find a way to afford.

The readily available Digital SLR has effectively killed photography as technical wizardry. Gone are the physical machinations inherent to film processing. Gone is the wait between capture and development. Gone is the limitation of sharing an image only through a physical object. Even gone is the required expertise and ridiculously specialized equipment required to create images which can be printed at poster quality.

Compared to what came before, this machine is so magical that anybody who touches it becomes a wizard.

I feel a bit for the purely technical career photographer, who strikes me as the equivalent of a gas station attendant as self-serve fuel pumps are developed. His specific form of wizardry is devalued, and his craft has become a commodity. The truly exceptional photographers (who have a knack for consistently finding a powerful image) will always remain in demand, but just being a guy with a camera who knows how to use it is no longer enough to make a living.

One can lament the plight of the technician photographer, but society as a whole clearly wins in this bargain. The notion of "photography as art" is now not only nearly universally recognized, but is also nearly universally accessible, and we currently witness the creation of photographic images the likes and volume of which would have been just as unimaginable as my camera 20 years ago. Artists no longer must emerge as a subset of the small pool of technical wizards, but from the massive pool of... well, virtually everybody who can post a picture online.

The notion of photographer as a technician is nearly dead, but the photographer as an artist? He's more alive than ever; and he is everybody.

I'm using Google Chrome more and more. In addition to my earlier gripe about password saving, there are various other perplexing design decisions. To me, none is more odd than Chrome's menu icons.

For Linux or Windows builds, Chrome/Chromium has no traditional "File/Edit/Tools/Whatever" menu headers, and instead uses a couple of icons on the toolbar:

Google apparently hates the old style menu bar, and rightfully so, since it steals valuable screen real estate from the in-browser apps that it thinks are the future of computing.* Google decides they want nothing to do with it in Chrome, but instead of creating something new (like MS has done with its "Ribbon"), they take those same old menu items and bury them into two "toolbar menus" represented by icons: a "rectangle with a triangle in the upper right corner" icon, and a "wrench" icon.

Right there, some alarm bells are going off. What is a rectangle icon? Is that the page? A document? What the hell is a wrench for? I've never used a wrench on a computer (well, there was that one time...). Based on its usage in other applications I can guess it means advanced settings or... something... right?

(Incidentally, Sun servers have a "wrench" light on them, which indicates they need... an oil change, I guess?)

So, say you're a user staring at a Rectangle menu and a Wrench menu. Under which menu would you expect to find "Developer" menu options? Under which menu would you expect to open a new tab? (I'm aware that you can cheat by looking at my screenshot. Feel free, if that makes you feel better).

Answer: New tab is under wrench, developer is under rectangle. Clear as mud, right? Never mind that "wrench" normally means something like "tinkering" or "settings" or "change oil," and that the "rectangle" menu kinda looks like an empty document. We're in the google world now, it makes perfect sense!**

Of course, all those nasty menu items must go somewhere, and it's not exactly obvious where "somewhere" should be. Google probably figures they can just give the user a couple of obscure icons and let them work it out by the process of elimination. This is probably a valid assumption, but it doesn't make the icons themselves any less perplexing.

Bottom line: apparently, Google has solved the problem of incoherent menu bars - with incoherent toolbars. So... yay?

* To be clear, I'm no File/Edit/Tools/Whatever menu apologist. That's a dated UI paradigm that doesn't map well to many modern real world scenarios; for example, Firefox's "File" menu contains such gems as "Work Offline." What does that have to do with a file? And why is "Print" in the file menu of a web browser? I'm printing a web page, not a file, right? Why is "Find" in an "Edit" menu? I'm not editing anything!

** In case you're curious, these icons actually do represent logical groupings, but good luck guessing what they are by icon alone. The "rectangle" menu contains actions limited in scope to the current document (well this is, actually, a lie - for example the "zoom" options impact all chrome processes - however this is the way the menu is conceived). The "wrench" option is a sort of "Meta" menu, responsible for managing chrome as a whole.

One of puppet's design goals is to be legible and useful to non-programmers. This is a laudable objective; not all sysadmins know how to write code, or are interested in doing so. However, this sometimes makes it necessary to... work around the limitations of the language.

Prime annoyance to myself: concatenating arrays for use in templates.

There's only one way in puppet language to concatenate arrays, and that's using the += operator on an array that was defined in a higher scope. Since puppet variables are immutable by design, this itself is actually a bit of chicanery: the += operator expands the variable from a higher scope, appends the data on the right side of the operator to that, and creates a new variable in the current scope with the same name as the one from the higher scope.

Sound confusing? Well, it is a bit. Here's an example of what it looks like:

$sshusers = [ "bob", "sally" ]
class ssh::accounts {
$sshusers += [ "tim", "thelma" ]
}

Within the scope of the ssh::accounts class, "sshusers" will be created as a new local variable, which expands to [ "bob", "sally", "tim", "thelma" ], and can no longer be modified. The original "sshusers" variable in the higher scope has not been modified.

So there you have it. That's how you append arrays in puppet. And that's the *only* way you can append to arrays in puppet.

At first, it might not be evident just how limiting this is. But consider the case that you have a lot of groups of users, defined in variables, and you want to use them all as elements in a single array:

$sysadmins = [ "bob", "sally" ]
$users = [ "tim", "thelma" ]
$dbas = [ "kip", "jim" ]

This is where things get nasty.

So, we know our += trick, but that can only combine *two* arrays at a time, so the only way to get all that junk into a single array is to chain += to get the mega-array we want. We now have a construct like this:

$sysadmins += $users
$dbas += $sysadmins
$sshusers = $dbas

Well, that works, but what if we want to get at only the DBAs for another template or definition? What if we want one definition that uses $sysadmins and $dbas, but another that uses $users and $sysadmins?

Basically, += does make this technically possible, but it makes it ugly. Wouldn't it be better if we could combine an arbitrary number of arrays in a single statement?

As far as I know, while there is no way to concatenate more than two arrays in puppet, you can still combine them into a single variable, like so:

$allusers = [ $dbas, $users, $sysadmins ]

All right, so this should trigger some warning bells. In a normal language, allusers would be an array which contains 3 other arrays. In puppet, though, there's not really a notion of nested arrays anywhere within the DSL itself; using $allusers as a variable in puppet definitions will work as if all the nested arrays have been expanded into a single array, which is what we really want.

For all practical purposes, within puppet's DSL, arrays that contain multiple sub-arrays function as if they are a single array containing all elements of the sub arrays.

Notice a very important qualification in my statement: "within puppet's DSL." This works fine when you're working within the puppet configuration itself, calling definitions, realizing users, etc; but if you try to use such a combined array in a template, it suddenly turns into a nested array again.

I find this duality very confusing; within the DSL, my variable is, in every way that I can interact with it, a single array of 6 strings. But if I try to use this array in a template, all of a sudden it's composed of 3 nested arrays which are in turn composed of 2 strings each.

Here's an example. Say you'd like to construct an sshd_config "AllowUsers" line in a template, which grants access to all of our users. AllowUsers should look like so:

AllowUsers bob sally tim thelma kip jim

$sshusers = [ $dbas, $users, $sysadmins ]

And call an ERB template that looks like:

<% sshusers.each { |i| -%>
<%= i + " "-%>
<% } ->

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template ssh/sshd_config_new.erb: can't convert String into Array at /etc/puppet/modules/ssh/manifests/init.pp:79

Bottom line is: you cannot combine more than two arrays in puppet to form an array of strings for use in a template, except by chaining += statements.

You can sort of work around this in some ways. One option would be to pass multiple variables to your template and use conditionals in the ERB to handle them properly. Thus, you have users1, users2, users3,... - but that leaves us with a rather unfortunate hack. Sure, it's fine for a small number of entries, but how many do you want to support? Wouldn't it be better if we could just get a darn array of strings?

I came up with a nasty hack: embedded in my ERB, I declared a function to "flatten" these nested arrays. It drilled down into the sub-arrays, iterated over them, and dumped each individual item into a single new array, which it returns. I then called that function whenever I needed the raw array.

UPDATE: a commenter posts out a much cleaner option than my original hack job, so I'm updating the post here in case anybody else should need it (there's really zero reason to use my old method, so it's stricken from the record):

AllowUsers <%= sshusers.flatten.join(' ') %>

Now, what do I get:

AllowUsers bob sally tim thelma kip jim

Success! Thanks Jay and duritong for pointing out this solution!

I still feel like this is a bit of a hack; why can't I properly concatenate arrays in the DSL? Why are not-concatenated arrays treated as if they were concatenated in the DSL? The workaround here gets the job done, but to me it was not obvious at all what was going on; this behavior should at least be referred to in the documentation.

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

From Nature

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.

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.

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.