Sunday October 29, 2006

Everyone knows what a great product Movable Type is. But if you find yourself in care of a Movable Type deployment that nobody seems to be able to login to with superuser privileges, it may seem pretty hopeless; if you need to perform privileged operations, especially if the installation is backended by a sleepycat, er, Oracle BerkelyDB database, the data is somewhat opaque. AFAIK, MT doesn't seem to ship with any "break glass with this little hammer if the superuser was hit by a bus" contingencies and with BerkelyDB there's no SQL command prompt; in fact, the only way to dig into it is to write some code. So I was fiddling with just such a MT-3.33 installation; I had an account but not much in the way of privileges. After opening the BerkeleyDB files with DB_File, dumping contents with Data::Dumper and going through some of the MT libraries, I found what I was looking for. Here's the Perl I hacked up to grant myself superuser privileges:

#!/usr/bin/perl

use strict;
use DB_File;
use lib qw( /path/to/MT-3.33/lib );
use MT;
use MT::Serialize;
use MT::ConfigMgr;

my $serializer = MT::Serialize->new(MT::ConfigMgr->instance->Serializer);
my %hash;
tie %hash,  'DB_File', '/path/to/MT-3.33/author.db', O_CREAT|O_RDWR, 0666, $DB_BTREE or die $!;
my $data;
while (my($k,$v) = each %hash) {
    my $rec = $serializer->unserialize($v);
    if (${$rec}->{'name'} eq 'Ian Kallen') {
        $data = ${$rec};
        last;
    }
}
$data->{'is_superuser'} = 1;
my $frozen = $serializer->serialize( \$data );
$hash{'12'} = $frozen;
untie %hash;  

movabletype   perl   hack  

Thursday October 19, 2006

As I announced on the Technorati Weblog, we rolled out support for blog claiming with OpenID. I'm really proud of the work that Chris and the team have done to make this a reality. If you're not familiar with OpenID, here is one good place to start. Sure, I'm well aware of the concerns about phishy user interface vulnerabilities. The idea of logging in without a password may seem weird.

One weird thing, for new users, is that instead of logging into an OpenID-using site (like Zooomr) with a user name and password, you just give it your personal OpenID URL -- and no password. Then your browser pops over to your authenticating site (like myopenid.com) to verify that you want to use your persona on the new site. This is bound to initially confuse people, and since users may not be asked for a password, it can also appear to be less secure, although it is not.
ZDNet: OpenID has a potential cure for Website password overload - Rafe Needleman

Distributed identity ideas have been gestating for a long time while identity cathedrals have been built and fallen. If your blog is your voice, your URL can be your identity.

openid   technorati  

Whenever I look at page to page, post to post, blog to blog and domain to domain relationship statistics (and permutations across them) interesting things often emerge. Microsoft's Live Search recently released a linkfromdomain operator that can help dig into these linking relationships. For instance, linkfromdomain:arachna.com ruby returns the pages that I've linked to that have ruby in the text. Combined with the site operator, I can do a search of the pages I've linked to on Technorati with linkfromdomain:arachna.com site:technorati.com.

Looks like the blogosphere is noticing, within the last two days Technorati has seen 57 links to the linkfromdomain announcement blog post. Kudos to MSN's search team for a cool innovation.

One apparent problem with their crawls is javascript/flash-plugin handling, the site:youtube.com linkfromdomain:technorati.com SERP shows pages referenced from Technorati's most linked-to YouTube videos, however all of the SERP items have the text

Hello, you either have JavaScript turned off or an old version of Macromedia's Flash Player. Click here to get the latest flash player.

you can get a feed of that search with this link

search   livesearch   msn   technorati  

Wednesday October 18, 2006

This was on NASA's Astronomy Picture Of The Day site a few days ago, I haven't been able to close the browser tab with it... I just keep gazing at the surreality of it.

In the shadow of Saturn, unexpected wonders appear. The robotic Cassini spacecraft now orbiting Saturn recently drifted in giant planet's shadow for about 12 hours and looked back toward the eclipsed Sun. Cassini saw a view unlike any other. First, the night side of Saturn is seen to be partly lit by light reflected from its own majestic ring system. read on

saturn   nasa   cassini   eclipse  

Tuesday October 17, 2006

Between Google's extensive use of employee shuttles, their green data centers proposal last month and yesterday's announcement Google to Convert HQ to Solar Power, I'm really impressed with the ecologically conscientious initiatives they're taking! Personal note: the solar installation will be led by Energy Innovations, EI president Andrew Beebe is a friend from years ago who I've long lost touch with but I was very pleased to see his name associated to this project.

google   green   solar  

Saturday October 07, 2006

It's broadly appreciated how scaling up is usually driven by business demand, but the requirements for scaling down are rarely as appreciated. Questions about how web 2.0 business scale up abound these days. As the challenges of service growth and business plans stress technical infrastructure, startups try to squeeze everything they can out of their architecture with a number of widely accepted practices. However, scaling considerations for the other direction are oft neglected.

1. Isolated functional testing to mitigate the riskiness of change

   End-to-end testing that doesn't require duplication of production infrastructure is a strategic advantage. I know of a financial analytics system run by a large institution that is untestable. This system has cron jobs, data feeds and query systems built on top of Perl code going back at least a decade. The inputs and outputs are so convoluted, that the system is untestable. So if this code is making the bank that owns it tens of millions of dollars every day (it is!), what's wrong with that? Well, it could be probably be more profitable if it could be changed and optimized safely. As it stands, the folks maintaining the code don't really know what modifications might break the system and with income produced at that scale, who wants to risk it? So look at the systems you're working on now, think about the "scaling up" considerations you've made and ask yourself: Is a system testable in a developer's environment? Can they unit test? Can they perform functional tests? Do the tests require access to resources only available at the data center? Is "now" hardcoded to the present in your code? Using scaled down database, messaging, caching and application runtimes that have no dependencies on a connected network and production infrastructure should be considered up front in your design consideration.

2. Operational costs of vertical vs horizontal scaling

   If a system makes assumptions about the process space it runs in that allows for functionality to be accessed from other runtimes, bravo: you may be headed in the right direction of service oriented architecture and horizontal scaling. But can the application stack be collapsed? This is like the OMG-moment when folks first started running J2EE application tiers over remote interfaces and realized that they've ended up with so much complexity and overhead, they have no choice but to scale up. That complexity can have all kinds of expensive side effects with how effectively systems can be triaged when they ail.

3. Business agility or just changing your mind

   Businesses are run be people. People make mistakes. Wetware is imperfect. When you buy a long term commitment to a data center, you may be assuming liabilities that will outlive the business proof. Make sure the hardware footprint you're signing up for is one you can sustain it or you can get out of it. When you build gratuitous tiers, the costs of taking them out when it's time to consolidate functionality can be stifling. So ask yourself: If systems scaled up to meet business objective that aren't met, can you "retreat" from the scale-up offensive?

Every time I see a system that's hard to test, has sysadmins overwhelmed or are not meeting business objectives and has to be reeled in, I'm reminded of the importance of thinking about scaling in both directions. No, I haven't read the book yet but as someone burdened with too much stuff at home, I've got it on my list.

web 2.0   unit testing   functional testing   technical operations   system architecture   software